Welcome to LinuxCNC.org

based on experience with Technix TEK6 servo amplifier closed loop controller it struck me that may be Mesa 5I20 might have a similar characteristic.

I am using Tek6 to control BLDC motors directly coupled to 5 mm pitch leadscrews driving XYZ axes.

Axes are supported by linear scales. Last week one of the servos died on me and had to be replaced.

While trying to adjust the loop it became obvious the newer version of TEK 6 was not as well behaved as the older version.

Talking to a very helpful designer ( Pete ) at Technix it became obvious that my understanding of a loop sample rate parameter was wrong.

The idea behind loop sample rate parameter is thait is adjusted to minimise numerical noise of the control loop.

By this I mean:

Axis runs slowly the numbers involved are a certain order of magnitude. Axis runs faster the numbers involved become larger for the same loop refresh time ( this is assuming constant refresh time)

TEK 6 has this parameter made available in order to ensure numerical noise ( associated with shorter than required loop refresh times ) is minimised. That is to say the loop is not relying on a single bit to provide the loop metrics.

My question is using mesa 5i20 and associated firmware is there a similar loop refresh parameter which might be used to optimise loop performance based on needed operating axis speeds and accelerations?


I appreciate this may be a bit exotic and relative to word length of the controller.

My Tek 6 based router runs at 300mm/s/s and a top speed of 200 mm/s whereas the 5i20 based laser runs at 2500mm/s/s and 6000mm/s soon to be pushed to 1200mm/s.

I am not exactly sure what you are referring to here but it sounds like he is talking about encoder quantization noise.

For a basic PID loop and simple encoder counter there are limitations with the calculation of velocity for the PID loop at low motor speeds (so the encoder count rate is small relative to the loop sample rate)

Imagine that you have a 2 KHz sample rate and a 500 line (2000 count) encoder. if the motor speed is exactly 1 RPS you would get 1 encoder count difference per sample but if you moved a little slower you would get a sequence of encoder count
differences like 1,1,1,1,0,1,1,1,1,0,1,1,1,1,1,0 etc if you moved a little faster than 1 RPS you would get differences like 1,1,1,2,1,1,1,2 etc. Since the D term of the PID loop is calculated from these count differences you will get a very noisy D term feedback signal. Notice that the noise magnitude in RPS is SAMPLERATE/ENCODER_COUNTS

So lower sample rates will reduce this noise (but also reduce the loop bandwidth making it harder to keep stable).

You can also low pass filter the velocity signal before sending it to the PID loop. This also reduces loop bandwith so is not the best solution

EMCs software and Mesa and Pico systems hardware encoder counters have a scheme to reduce this quantization noise so are much better than simple encoder counters at providing low noise velocity signals. They do this by time-stamping every encoder count edge.
The velocity is not calculated by delta_counts/sample period method used above but rather by delta_counts/delta_time where delta_time is measured between encoder quadrature edges. This results in a large (5-10 times for a good encoder) reduction in quantization noise.

To use this feature you must feed the velocity output of the encoder counter module to the PID loops feedback-deriv pin
this will make the PID component use this better velocity estimation instead of using simple position count differences with the quantization noise problems. (this improved PID component is in EMC 2.5)

All this to say EMCs software encoder, Mesa and Pico systems hardware encoders have a low sensitivity to high loop rates increasing control loop noise (when configured correctly)

Peter, Is there a time when this would not be desirable?
PNCconf does not connect the feedback-deriv pin.

I will add it I just would like to know if I should make it optional or not.

No, as long as you are using 2.5 or > (which has the improved PID comp)
Its always better to use the encoders velocity output (same goes for Resolver)
So connect the encoder (or resolver) velocity pin to the PID comps feedback-deriv

The PID comp does the default noisy D/DT of position for a velocity estimate
if feedback-deriv pin is unconnected (which is pretty clever)

Also forgot to say EMCs software encoder does this as well

How about when the command _is_ velocity (say a spindle) - still connect encoder velocity to pid command-deriv ?

No, that only works on a position loop.
(velocity is the time derivative of position)