Maximum Servo Thread Frequency?

More
19 Mar 2014 17:27 - 19 Mar 2014 19:46 #44976 by llrjt100
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?
Last edit: 19 Mar 2014 19:46 by llrjt100.

Please Log in or Create an account to join the conversation.

More
19 Mar 2014 20:12 #44977 by skunkworks
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
The following user(s) said Thank You: llrjt100

Please Log in or Create an account to join the conversation.

More
19 Mar 2014 20:22 #44978 by PCW
Replied by PCW on topic Maximum Servo Thread Frequency?
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.

Please Log in or Create an account to join the conversation.

More
19 Mar 2014 20:29 #44979 by PCW
Replied by PCW on topic Maximum Servo Thread Frequency?
Ha!

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

Please Log in or Create an account to join the conversation.

More
20 Mar 2014 00:16 - 20 Mar 2014 00:29 #44982 by llrjt100
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
Last edit: 20 Mar 2014 00:29 by llrjt100.

Please Log in or Create an account to join the conversation.

More
20 Mar 2014 00:46 #44984 by PCW
Replied by PCW on topic Maximum Servo Thread Frequency?
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.
The following user(s) said Thank You: llrjt100

Please Log in or Create an account to join the conversation.

More
20 Mar 2014 10:06 - 20 Mar 2014 10:07 #45004 by jmelson

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
Last edit: 20 Mar 2014 10:07 by jmelson.

Please Log in or Create an account to join the conversation.

More
20 Mar 2014 14:42 #45007 by llrjt100
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.

Please Log in or Create an account to join the conversation.

More
20 Mar 2014 22:59 #45013 by jmelson

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

Please Log in or Create an account to join the conversation.

More
20 Mar 2014 23:32 #45014 by andypugh

jmelson wrote: 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.


I have a resolver on the spindle of my milling machine. 20+ bits of resolution (at least 1 million counts per rev) and no trouble with tracking spindle speed up to 1500rpm (as fast as it goes, it isn't a fast spindle.). I think in theory the resolver interface could track up to 30,000 rpm. There are not many applications where you might prefer a resolver, but this is possibly one of them.

There are some rather reasonably priced ones on eBay too.
www.ebay.co.uk/itm/New-Tamagawa-Smartsyn...rksid=p2056016.l4276
As an example, which might not have a big-enough through-hole.

However, interfacing such a device causes some problems. I don't think that the obvious choice ( www.pico-systems.com/resolver.html ) will help as it converts to quadrature signals and you run into the same counting-rate limit. The only parallel-port based solution would be a switch to Mesa and the 7i43 / 7i49 combination, which is quite a costly option when you already have a set of control hardware.

There is no reason at all that you can't have two encoders on the same spindle, one for high-speed and one for low-speed use.

Please Log in or Create an account to join the conversation.

Time to create page: 0.112 seconds
Powered by Kunena Forum