PID Tune Problem and Clarification

If you are using a linear encoder (glass scales), I am pretty sure you will need to turn off backlash compensation. Using backlash comp with the linear encoder will cause a following error equal to your backlash setting.

I'm already turning off the backslash when I'm enabling the PID because I want to use ONLY the glass scales to fix the shift.
But the scenario, after enabled the PID and turned off the backslash, on the direction change(not each one, but seems is randomic) losts from 0.002 to 0.004 at first and increasing it if I will continue the tests ( i have tested till to miss 0.100).

I saw that the glass scales output is a TTL and I read that with an encoder x4 I should able to not miss any steps but really seems that isn't so.
How can check and tune the glass scales output signals in order to understand if all is ok?

Am I on the right way?

Well, reading encoders with the parallel port is always going to be just a little bit sketchy. But it looks like your resolution is enough lower than your stepgen resolution that it should not be too much of a problem.

The order and location of how functions are added to the threads is important. It would be highly advisable to put all of your loadrt and addf lines of hal code in one place, at the beginning of your 1st hal file.
(not that this is necessarily causing your problem here.)

Other things to look at are electrical noise issues, causing lost or false steps in your encoder signals. Single ended TTL signals can be very susceptible to noise, especially if there are grounding or shielding issues.

Use hal scope to look at the A and B signals from the encoder. Do they look like they might have a noise issue? Does it look like there may be missed steps in the encoder signal? How about missed steps by the step motor?

I'm troubleshooting the issue and I will try to do the improvements that you have suggested.
How can I check if A and B signal have a noise issue?
I see with halscope that the A and B signals arrive fine but only those one that surely arrives...I only observed that someones are missing comparing the manual axis mesurement with the Linuxcnc results.
I think that it look like there may be missed steps in the PID encoder signal because if I exclude it the CNC is working as expected.

Here is a screen shot of a HalScope plot of some parallel port inputs, two of witch are the A-B inputs for a software encoder. In this shot it is fairly obvious that I have a serious noise problem. On the A and B inputs (the green and blue traces at the bottom) you can see both true pulses, the long ones, and the noise pulses, the short spikes for only 1 thread period or so that show up simultaneously on several input pins.