Mesa 5I20 and loop sample time

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)

After some thought I think the question points to effects of

BASE_PERIOD =
SERVO_PERIOD =
TRAJ_PERIOD =

on the performance of 5i20 loop.

How do the above coefficients interact with the 5i20 servo loop and given certain performance parameters how to set above coefficients ?

From the manual:

BASE_PERIOD = 50000 - This is the "Base" task period (in HAL), in nanoseconds. This is the fastest thread in the machine.

Note
On servo-based systems, there is generally no reason for BASE_PERIOD to be smaller than SERVO_PERIOD. On machines with software step generation, the BASE_PERIOD determines the maximum number of steps per second. In the absence of long step length and step space requirements, the absolute maximum step rate is one step per BASE_PERIOD. Thus, the BASE_PERIOD shown above gives an absolute maximum step rate of 20,000 steps per second. 50,000 ns (50 us) is a fairly conservative value. The smallest usable value is related to the Latency Test result, the necessary step length, and the processor speed. Choosing a BASE_PERIOD that is too low can lead to the "Unexpected real time delay" message, lockups, or spontaneous reboots.


SERVO_PERIOD = 1000000 - This is the "Servo" task period (in HAL), in nanoseconds. This value will be rounded to an integer multiple of BASE_PERIOD. This value is used even on systems based on stepper motors.

This is the rate at which new motor positions are computed, following error is checked, PID output values are updated, and so on. Most systems will not need to change this value. It is the update rate of the low level motion planner.

TRAJ_PERIOD = 100000 - This is the "Trajectory Planner" task period (in HAL), in nanoseconds. This value will be rounded to an integer multiple of SERVO_PERIOD. Except for machines with unusual kinematics (e.g., hexapods) there is no reason to make this value larger than SERVO_PERIOD.


With a hardware card like the Mesa 5i20 the most import one is the SERVO thread as you probably don't need the BASE thread as the 5i20 is doing the fast work.

Lowering the servo period will make the calculations happen more often and allow less time for non realtime programs (eg EMC's screen controls)
calculating more often make the system more responsive to feedback. I believe its called bandwidth .
For most servo systems with velocity amplifiers, the 1KHz (1000000ns) period is recommend.
If using torque controlling amps, linear motors, or motor commutation with EMC for instance I have seen 5 KHz (200000ns) recommended

I'm sure someone more knowledgeable will add to this but what would help the most is:
What are you trying to improve?

Hello Cris,

Thanks for Your comments.

As I said, initially I came across this loop refresh coefficient in setting up a new ( old one failed) servo amp on a gantry mlil. The replacement unit i had in stock and hoped it would be a one for one change over.
That was not the case, the firmware had changed and this is when I was made aware of some of the effects of changing the loop refresh rate.

I am running some iron cored linear motors using meas5i20.
Machine is working fine. It could do with higher acceleration and of late the laser source was changed to a slightly higher output model.

So now I could do with increased velocity as well.

I think , judging from Your comments I could possibly reduce the servo period. ( this is in line with the experience with the other servo amp)

Presently the acceleration is set to 2500mm/s/s and velocity is set to 9000mm/min

The results are acceptable but I would like to increase acceleration and top speed somewhat. ( somewhat means speed up to 12000mm/min in line with the new laser capability and process energy density requirement and acceleration to a higher stable value)

So given above speed and acceleration and given that the axes use a 20 micron quadrature linear glass scales do You have a gut feeling for what the loop time or servo period ought to be.

Well the last six .. seven weeks have bee a dificult time.

I have had to replace the old Tek 6 step direction servo components with a combination of

5I20 / 7I33 cards along with AMC servo amps BE12A6. This was all to do with the differences in firmware between original Te 6 and current version on the spare unit I have.

The more recent units are optimised to work with at higher speeds ( encoder pulse rates) which triggered the original question at the start of this thread; what is optimum servo period and associated numerical noise in the control loop.

The new set-up is configured in the best of Mesa 5I20 tradition; PDM modulation at 6MHz clock rate feeding servo amps with secondary rotary shaft encoders CUI Inc AM 102 on the motors to close the velocity loop ( set to 2040 pulses per revolution) .
% micron linear encoders are used to close the Positional loop.

The whole set-up is quite stiff and nowhere near as hissy ( due to high derivative feedback required to stabilise a high proportional gain setting) as the previous set up.

It was also amasing to see the feed forward components come into play. There was not much joy due to FF0 coefficient but FF1 and FF2 nulled the following error quite happily at 600 mm/min velocity setting.

The axis move extremely smoothly and I expect great performance from the machine.

I have only one little problem to resolve on the X axis. The axis performance is a bit direction sensitive and I suspect the alignment of hall sensors is the next onion skin to peel.

The people at Anaheim Automation ( suppliers of the motors ) have advised to measure no load current of the motor and adjust the position of hall sensors to minimise no load current .

More on that as it develops.


For the time being thanks go to all kind and concerned members of the forum.