Linear Encoder, PID and Backlash

bbsr_5a wrote: why is there a horrible jitter in the feedback
isn't the cable shielded
and or the connectors grounded

You have to remember the velocity feedback is coming from a linear encoder attached to the table, not the motor. The encoder provides pulses, not an analog speed signal like a tacho. As the velocity signal is calculated from the pulses the "noise" or jitter is unlikely to come from interference. If there was any interference generating additional pulses it would also have to affect the position feedback. Here is a trace of the position signal together with the velocity:

As you can see, the position signal is perfect whereas the velocity signal is noisy, so I conclude the noise is coming from the calculation.

I suspect the noise on the velocity signal is a combination of using a 5um resolution encoder on a low quality [Chinese] ACME lead screw. At the maximum speed of 14mm/sec the encoder signal produces only 2800 pulses per second, that's one pulse every 357us.
I'm not sure how often the velocity calc is performed, but, the low resolution encoder will produce very few pulses for a fast measuring system and therefore a 1 digit variation (as is usual in all digital measurement) is of significant magnitude and shows up as "noise" on the trace.

The encoder cable is shielded all the way to the Mesa 7i85S card and the shield is grounded on the Mesa card end.

Noise on hm2 encoder velocity signals at a constant speed is more likely caused
by actual motion variation and quadrature errors ( lack of perfect 90 degree offset between A and B )
than calculation. Velocity estimation is done by a delta_counts/deltaT calculation where deltaT is not the sample
period but rather the time between count changes. This eliminates the count sample time uncertainty in
velocity estimation but is still susceptible to quadrature errors. Sometimes you can improve
the quadrature accuracy by mechanical or electrical encoder adjustments.

PCW wrote: Noise on hm2 encoder velocity signals at a constant speed is more likely caused
by actual motion variation and quadrature errors ( lack of perfect 90 degree offset between A and B )
than calculation.

Many thanks for your authoritative answer.
My first suspicion is motion variation on the cheap Chinese made ACME screws as I have observed up to 80u variation in the lead screw pitch.
The linear encoders are no-brand cheapies, so quadrature errors are certainly possible.

The "noisy" velocity signal does not appear to be causing any problems as far as I can see so I'll leave it as is.
However, I will re-evaluate once I have fitted ball screws.

For what it's worth....
In my experience ( 9 different machines), there is no substitute for good mechanical components and near zero backlash.

Any update on this topic? My backlash on y axis is 0.6mm on old manual mill (Fritz Werner from the 80s) with trapezoidal threads. Idea here is small “research” how to implement different control strategies and to test how far it can go concerning backlash but without changing to ball screws. Currently axis is equipped with heidenhain linear encoder resolution of 0.5um and dc tacho directly coupled on dc motor shaft. Control loops are implemented on drive level. Until now tested positional loop using only linear encoder and dual loop using feedback from dc tacho and feedback from linear encoder. I have to tune it more but currently have some available info. There is a “lot” of friction(unequally distributed along the path). Friction is also different based on direction of travel. This might be handled with different set of gains based on direction. In both cases friction creates noise on velocity measurement especially when implemented dual loop(inner controller fighting against friction as its main purpose is velocity control and thus velocity is changing very fast and has lot of ripple). In both configurations velocity was measured with dc tacho. I didn’t do yet velocity estimation based on linear encoder. Currently closed loop with just linear encoder works better as it is easier to tune, lost motion is less then in dual loop and in the end of move motor reach position and not continuously hunting it(possibly due pid parameters and higher friction). When changing direction lost motion concerning backlash is 0.2mm and it lasts about 130mS( error is shape of triangle with peak in 0.2mm). I have to check for exact numbers concerning velocity and acc ramp. Didn’t start yet to test with diff acc ramps and diff max velocities. To my understanding smaller acc ramp and higher pid output should reduce this lost motion(backlash) as actual move should lag less from commanded( slow acc ramp should give more time for the move and higher pid output should shorten actual backlash move). Concerning dual loop move is more smooth but errors are little larger and motor is continuously hunting end position but in small boundaries depending of pid parameters (from -0.03mm to 0.03mm). Didn’t go yet in detail tuning dual loop. Maxon has some interesting things concerning dual loop implementation. If someone is interested it is in epos4 application notes. They say dual loop gives most benefits with an elastic drivetrain. Think that also in Galil paper about dual loop tests were done on system with big error introduced by compliance of belt and smaller error introduced by backlash.
I would like to hear opinons about this.I am wondering about how is backlash compensation implemented in linuxcnc engine. Is it done on the fly or all axes has to stop until backlash compensation is applied to current one which changed direction?
If it is done on the fly, for higher values of backlash shouldn’t be there any irregularities on produced part?
Also wouldn’t be the similiar
situation with linear encoders? In this case backlash compensation would be turned off but closed loop with linear encoders could hide some portion of backlash smaller or higher and there would be always lost motion more-less.
If it is implemented like in second case are acc ramps up and down respected concerning axes which has to stop and then start again?

I can't answer your questions on LinuxCNC engine details, but here is a brief description of the current status of this machine:

My BF20LV mill is producing acceptable results. Here are a couple of videos showing hole cutting:
Hole cutting video 1
Hole cutting video 2
Hole cutting involves two direction changes by each axis for every circular movement, so it's a good indication of backlash issues. There is no visual indication of an issue and the resulting hole is round to within 0.1mm.

Each axis has stepper motors driving ACME lead screws and linear encoders providing position feedback. No motor tacho, velocity is derived from encoder feedback. Backlash compensation is disabled in the INI file. Here is link to a current backup of all linuxCNC configuration files:
BF20 linuxCNC configuration

The current tuning provides an acceptable compromise between speed and stable operation. I can get the PID loop to oscillate by very small (< 0.5mm) moves at high speed. The PID oscillation will increase until a following error trips the axis.
However, PID loop oscillation is only an issue while the machine is not cutting as cutting load provides a large "damping" effect and prevents oscillation. Therefore PID oscillation is only an issue when using the pendant hand wheel to move the axis (by small distance) while not cutting.

Another compromise element of PID tuning is that the maximum speed is set much lower than what the motor and axis is capable.

A high PID gain is an issue when it comes to backlash but is necessary for accurate cutting, so the tuning is about finding the sweet spot which produces an acceptable result but doesn't trip the axis when reversing direction in normal operation.

As has been mentioned in other posts, there is no replacement for smooth slides and low/no backlash lead screws.
Whilst I'm in the process of fitting ball screws to this machine so I can overcome the issues listed in this post, the ACME setup has worked better than I expected and produced very accurate parts over last few months.