What (hal pin?) tells me that spindle speed has changed? (Waiting for spindle)

More
14 May 2020 20:38 #167786 by frogandspanner
I have a Sieg SX2P mill which I have converted to CNC, using linuxCNC.

Recently I designed and built a spindle controller to read and set spindle speed, using feeback to maintain speed. I use a linuxCNC user mode module to communicate with the spindle controller over USB.

I wanted to have linuxCNC suspend table feed until the spindle was at speed. I read various articles on this forum, and at first decided to set motion.spindle-at-speed appropriately. Unfortunately, I set this in the user code, so there is a scheduling delay, and feed begins before software detects a commanded speed change and disable the spindle-at-speed bit, so feed runs to completion. (Note: I am using a comparison of set speed against actual speed to set the bit on, ignoring whether the spindle is disabled, so a disabled spindle results in spindle-at-speed being set).

I changed to using motion.feed-inhibit, and that is better - there is small feed until my module is scheduled and set the bit.

I can live with that as resulting feed is small, but I'd like to find a proper solution.

The question is: what HAL bit can be used to tell me that the spindle speed is being changed? Or, if there is no single bit, how can I generate a hal bit to indicate there is a change - then I could feed that into spindle-at-speed or feed-inhibit at higher priority than my module gets.

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

More
14 May 2020 22:19 #167789 by cmorley
Comparing requested speed to actual speed with the near component is the standard way to do this.

spindle at speed only check at specific times.
From the (2.8) docs:

spindle.0.at-speed - (bit, in) Motion will pause until this pin is TRUE, under the following conditions: before the first feed move after each spindle start or speed change; before the start of every chain of spindle-synchronized moves; and if in CSS mode, at every rapid to feed transition. This input can be used to ensure that the spindle is up to speed before starting a cut, or that a lathe spindle in CSS mode has slowed down after a large to small facing pass before starting the next pass at the large diameter. Many VFDs have an at speed output. Otherwise, it is easy to generate this signal with the HAL near component, by comparing requested and actual spindle speeds.

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

More
14 May 2020 22:28 #167791 by frogandspanner
I have tried generating that signal from my (loadusr) module, but the delay between it waking up and setting the necessary pin is slow compared with G-code being acted upon.
e.g. M3S2000
G1F100X100

will be acting upon the G1 before my software has a chance to compare the set and actual speeds. As a speed change is from spindle at-speed=T via F to T again, it is still at True when the interpreter comes across G1..., so the feed will complete when spindle-al-true goes false, then subsequently True again.

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

More
14 May 2020 22:41 #167792 by cmorley
Don't do the comparison in the user component, only use it to set the actual spindle speed pin, spindle.N.speed-in.

If that is not fast enough then you must have a very under powered computer, that doesn't leave enough time for the user thread or a very slow USB device.
How often does the spindle speed get updated by your USB device?

IIRC I use serial over USB to get speed feedback from my VFD at 9600 baud, and it seems to work fine for spindle-at-speed.

Chris

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

More
15 May 2020 00:52 #167799 by frogandspanner
The protocol from the Sieg power controller for the spindle motor sends about 1 packet per second of tacho information, and that is fielded by an Arduino nano, which then immediately sends the results as a 5 byte packet . I think that the majority of the latency is in the power controller tacho protocol.

Tony

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

More
15 May 2020 02:07 #167803 by cmorley
oh yes that is slow!
I think if you do the comparison in real time and just get the feedback from the USB, it will work much better.

Chris

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

More
15 May 2020 08:44 #167822 by bbsr_5a
Hi
the sieg Standard Spindle has a second Shaft tht can easy fit an Encoder to read real spindle speed
NO need for arduino
so get the Encoder REAL speed into the Linuxcnc HAL by PIN
and act on real speed in real time
Cost as max as 10USD

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

More
15 May 2020 11:12 #167832 by frogandspanner
It's the Sieg SX2P - with the high-torque motor.

I'm already out of pins on my parallel port, and am loath to fit an additional one, so an extra encoder is not an option.

I was hoping that LinuxCNC had a hal pin that was pulsed low when a spindle speed command was encountered. I suppose I could look at modifying the code to do that, but am reluctant. I know I could precede any speed change with an M5, but I can't guarantee that any CAM software I might use would do that.

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

More
15 May 2020 16:44 #167868 by cmorley
if you compared the requested speed with the USB based actual speed in a realtime component, I think it will work fine. As long as one of the signals is current the comparison works.

The problem with comparing it in the USB user space program means that both signals can be old and the output signal can be late.
I'm surprised it doesn't work a little better but using a realtime comparison would be better.

if you wanted to have a pin that was set high on each different RPM request, you could do that with a custom realtime component.

Chris

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

More
15 May 2020 18:51 #167886 by frogandspanner
Could you point me at an example of how to create a realtime component?

Tony

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

Time to create page: 0.111 seconds
Powered by Kunena Forum