Servo Thread Cycle Time vs Encoder Velocity Feedback

Hello, 

I have a speed loop (open) / position loop (PID closed loop) controlled spindle via StepGen (7i95). Everything so far is working. 

I was playing with the Servo Thread Cycle times and noticed (in speed loop mode - no PID), that my encoder.xx.velocity-rpm output changes quite a bit, based on Servo Thread Cycle times:

Commanded speed in rpm = 600 

1.) 1ms Servo Thread: encoder.xx.velocity-rpm = 600 rpm +/- 2 rpm (very stable)

2.) 0.5ms Servo Thread: encoder.xx.velocity-rpm = 600 rpm +/- 40 rpm (fluctuating quite a bit)

The spindle runs open loop, so I think the actual rpm does not change but the encoder reported velocity-rpm is quite different. Is this a normal behavior? Is there anything else I would need to change?

I am running Master 2.9-38xx. 

Thanks. 
-Markus


 

My guess is that at a 0.5 ms servo thread you have a large amount of jitter relative to
the servo thread time and perhaps even dropped (timed-out) packets.

You might try enabling the DPLL sampling of the encoder data and also check for dropped packets (halscope packet-error)

I did some more testing. Also tried my Lathe, that is running from the same PC. I was able to run 0.25ms Servo Thread with no strange encoder reading (7i76e).

I might need to check the Spindle Encoder cable going to the Servo Amp on my mill. Sounds like some sort of EMI.

Not sure if it still makes sense to try and enable DPLL sampling? Could you provide a link or example on how to do so?

Thanks.

I dont recall the names off-hand but its analogous to the
stepgen DPLL setup (and can share the same timer as the stepgen)

The encoder velocity calculations should be fairly resistant to
servo thread jitter even without the DPLL because they are calculated
from delta_counts/delta_time but delta_time is determined not by the
servo thread period but by the differences in encoder edge timestamps.

Lower servo thread rates will result in less velocity jitter simply because
the delta count difference is larger (at least with high res encoders with
multiple counts per servo period) but that would only be a 2 to 1 or so
difference with your 1 and .5 ms tests.

Another possibility with lower resolution encoders is that if you have
significant quadrature error (deviations from 90 degree phase shift),
the velocity estimation can get very jitterly when fewer than say 4 counts
occur between servo threads.

Imagine if you only get 1 count per servo period. If you had only 10% quadrature
phase error,  you could get a 20% difference in subsequent velocity estimates...
 

The testing so far was done in open loop mode - just the Servo Drive PID.

I used a "cheap" rpm tachometer with a contact pad and the speed there is spot on +/- 1 rpm, while LinuxCNC sees +/- 40 rpm, when I command e.g. 600 rpm. I guess the update rate on the tachometer is 1Hz, maybe 2Hz - so no real reference.

There seems to be some sort of interference, that throws the encoder counter off. I will try to hook up my Oscilloscope.

What resolution encoder do you have?

The spindle has a built-in 800/3200 count quadruple encoder.