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

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.

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.

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.

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

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

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

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

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.

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

Could you point me at an example of how to create a realtime component?

Tony