Effect of lengthening the servo thread period?

I'm using a Raspberry Pi 4 to drive a Mesa 7i96.   For unknown (as yet) reasons, I can't reliably run without errors unless I bump SERVO_PERIOD to 2000000 (i.e., 2ms).

What affect will this have on machine operation?  I sort of understand what's scheduled to run in the base thread, which of course is largely (completely?) irrelevant now that I have the Mesa.  But I don't have a good mental model for what runs in the servo thread, so I don't have a good understanding of what happens to operation/performance if it only runs half as often as usual.  Where would the difference show up?

Until recently my mill maxed out at about 40ipm, so absolute performance wasn't really a consideration.  I've upgraded to a machine capable of at least 80ipm using Grbl, and initial tests with LinuxCNC and the Mesa card indicate 100ipm may be fine.  So now I'm wondering if I need to start worrying more about that servo thread.

paul

Okay. I wasn't sure whether it could cause stuttering of some sort, if the commands to the Mesa weren't sent in time.

My naive mental image is that the Mesa service routine is called from the servo thread, and it sends multiple commands like "Step X +25 times and Y +10 times" during each call. And I assume the Mesa maintains a queue of such commands, and the servo thread needs to run often enough for that queue to never become empty prematurely.

So the answer might involve knowing how big a buffer the Mesa has for that queue, and whether the minimum execution time for a bunch of very quick commands in that queue is shorter than the servo period.

I meant to add:

But I'm more than happy with your answer!

With Mesa hardware (and most external hardware step/dir interfaces
or even EtherCAT drives), the velocity (step rate in this case) is updated
every servo thread.

This means that there is a constant velocity between updates. This constant
velocity means that that you will  have a small error (chord error) between a
desired curved path and the actual (linear interpolated) path.

This error is usually insignificant for most CNC machines at a 1 or 2 ms
servo thread period and typical CNC machine acceleration values.

For machines that are precise and fast (say with linear motors) you would likely
need  a faster than 1 KHz servo thread (or parabolic or cubic interpolation)

If you want to calculate the chord error here are some equations (at least for circles)

Chord error polygon vs circle =
R (1-cos(180/N))

R = radius
N = sides

R = Minimum Radius= V^2/A
N  = Sides = T_Circle/T_Sample

(a minimum radius circle at full speed is the worst case)

Using an example of 1 IPS (~25 mm/s) cutting speed and 40 IPS/S
acceleration (~ 1000 mm/s/s) and 2 ms servo thread,  the chord
error is about 0.00002" or 0.5 u.

If you increase the servo thread much longer you will start to have
issues on acceleration due to jumps between velocity steps, which
will limit your maximum acceleration setting.





 

Another way is to take a feedrate say 200 mm/min and divide that by 60 for seconds and 1000 for servo thread speed and you get 3.3 micrometers between position updates. 500 Hz servo thread gives 6.6 micrometers between position updates. No buffering, all real time.
I guess there are situations where this can make a difference, but normally not I would say.

PCW wrote:

With Mesa hardware (and most external hardware step/dir interfaces
or even EtherCAT drives), the velocity (step rate in this case) is updated
every servo thread.

This means that there is a constant velocity between updates. This constant
velocity means that that you will  have a small error (chord error) between a
desired curved path and the actual (linear interpolated) path.
 

Okay, that's interesting, and of course I have more questions.

First, does the Mesa know how many steps it should count?  Will the longer period introduce greater error in the length of each chord?  I.e.,  might it overshoot by 1ms worth of steps, vs. just 500ns worth of steps?   Or is the command to the Mesa really just "start moving at N steps/second"? (rather than "start moving at N steps/second, for 10500 steps")

Second, the chord error you describe would only occur for a curved path.  If the G-code is written completely using straight-line approximation (which of course introduces its own chord errors), it seems like the longer servo period wouldn't introduce any more error at all.  True?

In any case, it sounds like I can stop worrying about my 2ms servo period for the time being.

paul

For Mesa step generation (others are similar) LinuxCNC creates a local feedback loop
where at every servo thread invocation, LinuxCNC reads the current stepgen position
and then sets a new velocity based on the current commanded velocity and with a small
correction based on the current position error. That is, at every servo thread invocation,
LinuxCNC generates a new position. Based on that new position and the current stepgen position
a new velocity is calculated to meet that new position at the next servo thread invocation.

With Mesa hardware the precision of the control loop is 1/65536s of a step, so typically
the error between the commanded position and the stepgen position is never more than
a fraction of a step.

Here is a plot of stepgen error at:

10 ms servo thread
1 IPS cutting speed
5 IPS rapid
50 IPS/S accelration

Note that Velocity is in IPS  per division and error is in 20 uinch  (~0.5 u) per division

The residual noise in the error is caused by timing uncertainty in the position sampling.
This is about 2 usec at a 10 ms servo thread but about 400 ns at a 2 ms servo thread

 

Even the chord error is nothing to worry about as long as you do not have extreme
acceleration (say > 1G)

 

Thanks! That first paragraph was gold. My understanding of how the whole thing works just went *way* up!