Maximum Servo Thread Frequency?

I need very accurate sync of z axis to spindle speed to cut threads with less than 0.5 microns (SI units) helix error. The spindle is rotating at about 450 rpm and the pitch is 16 tpi, which gives me about 12 mm/s z axis velocity whilst threading.

With LCNC's standard 1 kHz servo frequency, the servo loop occurs every 12/1000 = 0.012 mm. I need 12/0.005 = 24 kHz for the servo loop to occur every 0.5 microns.

Do I need to switch to a faster controller such as the Delta Tau, so I can get this faster servo loop, or can I somehow use my Pico-Systems board in conjunction with LCNC to achieve this resolution?

What kind of spindle encoder do you have?

You have to remember that the machine isn't going stop-go-stop-go. It is calculating the velocity to cut the thread and then adjusting that velocity ever 1000 times a second..

sam

Normally LinuxCNC servo systems are run with velocity mode drives.
This means the drive itself runs the current (torque) and velocity PI loops
and LinuxCNC runs the position loop (with a velocity command output)

On most systems the nested control loops run at slower and slower frequencies
as you get closer to the controller.

For example on Fanuc's latest drives the current loop runs at 32 KHz, the velocity loop
at 16 KHz and the position loop (the part LinuxCNC typically does) at 4 KHz.

This means the drive itself runs the high speed loops and effectively does
interpolation between position way-points. This interpolation also means servo accuracy is not
limited to velocity/servoperiod but something much less, that is determined (in part) by how
closely the drive follows the velocity command between position way-points.

For this reason and the limited bandwidth of the mechanical drive system
(maybe 100 Hz at the most), there is little to be gained in increasing LinuxCNCs
position loop sample rate above a few KHz.

Ha!

Sam said the same thing in 10% of the words!

Thanks for your replies guys

The Pico-Systems board has encoder inputs and stepper pulse outputs - so does it handle the high speed current/velocity loops like the Fanuc control, keeping it outside of the lower speed LCNC servo loop?

Best wishes,
Richard

It really depends on your motor drive, but a step/dir motor drive is typically running in position mode
and all high speed loops run in the drive, LinuxCNC just reads the Z axis encoder or stepcount register
and outputs velocity commands to the stepgenerator hardware every 1 mS. This feedback loop
mainly just corrects for the minor timebase errors between LinuxCNC and the stepgen hardware.

llrjt100 wrote:

I need very accurate sync of z axis to spindle speed to cut threads with less than 0.5 microns (SI units) helix error. The spindle is rotating at about 450 rpm and the pitch is 16 tpi, which gives me about 12 mm/s z axis velocity whilst threading.

With LCNC's standard 1 kHz servo frequency, the servo loop occurs every 12/1000 = 0.012 mm. I need 12/0.005 = 24 kHz for the servo loop to occur every 0.5 microns.

Do I need to switch to a faster controller such as the Delta Tau, so I can get this faster servo loop, or can I somehow use my Pico-Systems board in conjunction with LCNC to achieve this resolution?

You don't say which Pico Systems product you are using. Some of them may be able to go to
4 KHz servo cycle if the latency of the computer is very low, the parallel port is fast (PCI plug--in
card instead of motherboard multi-I/O chip) and you are only running 4 axes.

But, you can estimate the error, using Halscope. First, make sure that you have enough Z travel
at the lead-in of the threading move for the Z axis to synch up to the spindle. Make sure
spindle doesn't slow down when the cutter enters the thread. Then, just look at following
error in user units (looks like mm for you). The hal pin would probably be pid.1.error
and you might use ppmc.0.encder.01.delta to trigger the Halscope trace.
See wiki.linuxcnc.org/cgi-bin/wiki.pl?PWM_Servo_Amplifiers for some
info on how to do this if you are not familiar with Halscope.

What you are concerned with is the peak-peak error during the threading portion of
the move.

Oh, now I see in your later post this is a Universal Stepper Controller, so you
are probably running open-loop. In this case, I would say .5 um is probably
a fantasy. You have no way to measure actual position, and the Z axis is moving
in discrete steps, not a smooth movement. Note that a stepper motor is maintained
somewhere within +/- 2 full steps. This is true, even with microstepping. It acts
like the leadscrew is connected by a spring, which is actually the magnetic force
in the motor. So, you just don't get extreme accuracy with stepper motors.
With servos, you can put ultra-high resolution encoders on the motor and
increase the accuracy of the motor's movement.

(You can ignore most of this last paragraph if your machine is not actually
driven by open-loop steppers.)

Jon

I'm using the Universal Stepper Controller open loop with a stepper on the Z axis at present - the stepper resolution is much worse than 0.5 microns, and I anticipate needing to change to a servo motor for increased resolution with a 40,000 ppr motor encoder and using a Renishaw RGH24 5 nm readhead for closed loop control. With the threading spindle speed at 100 rpm, the RGH24 will output at about 0.5 Mhz, so hopefully workable with the USC. It will be interesting to monitor the following error with this setup.

llrjt100 wrote:

I'm using the Universal Stepper Controller open loop with a stepper on the Z axis at present - the stepper resolution is much worse than 0.5 microns, and I anticipate needing to change to a servo motor for increased resolution with a 40,000 ppr motor encoder and using a Renishaw RGH24 5 nm readhead for closed loop control. With the threading spindle speed at 100 rpm, the RGH24 will output at about 0.5 Mhz, so hopefully workable with the USC. It will be interesting to monitor the following error with this setup.

With zero jitter and quadrature phase error, the USC is guaranteed to count encoders up to 500 KHz. (The digital filter samples at
1 MHz.) if you are getting 500 K counts/second at 100 RPM, it will lose track of the spindle somewhere between 100 and
200 RPM.

but, wait, I'm not sure I believe your calculations. 100 RPM is 1.6667 revs/second. Multiply that by 160,000 (assuming your
40K PPR is the same as an optical encoder with 40K lines) and you get 266667 counts/second. Still, if you want to
run at 1000 or 2000 RPM someday, the USC would not be able to count that. Spindle speed readout is a nice feature,
even if you never thread at those speeds. (Although I do rigid tapping at 1000 RPM all the time.)

Jon