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

frogandspanner wrote:

Yes - I can select a config. It was at that point that it fell apart as something had crept into my config file and crapped. I fixed that, but I note that I still get those messages, and suspect I always have - but not noticed them.

In looking I note strange lines like:

"treeclose /usr/share/doc/linuxcnc/examples/sample-configs/by_machine/tormach"

Yes I beleive I've seen it lots before (in 2.7?) and could ignore it.

frogandspanner wrote:

Let me summarise what I think it is I want to do:

1) spindle.0.at-speed - (bit, in) Motion will pause until this pin is TRUE

2) This does not prevent feed when speed changes as there is a race condition between that which detects that the spindle is at the commanded speed and that which has commanded the speed change. The feedback is outwith the linuxcnc realtime loops.

3) Ideal solution: motion could assert a pin to indicate, to components within the realtime loops, that a speed changed was commanded.

4) I am not up to speed [bad pun intended] to change linuxCNC.

5) My proposed solution, using invaluable help from this forum: bodge a realtime component that pulses a pin when a speed change is commanded, with a pulse length sufficient to cope with the time the external feedback system takes. This then inhibits table feed.

So far I have built the realtime component, plugged it in with timdelay, and using the Hal Configuration tool in linuxCNC, checked that I get a suitably pulsed pin.

There is no need to modify linuxcnc it's self.

I'm not arguing your idea of adding a pause on every speed change won't work -I'm sure it will.
I'm suggesting it won't work quite as well and that it was actually more work then the normal way of checking for up to speed.
It's not really important now that you have the component built, I'm just curious why you chose the way you did. - maybe I'm missing something.

Also I would watch out for trying inhibit-feed - if you use spindle override I'm pretty sure it would pause your feed everytime you adjusted it - even in the middle of a feed move.

Keep us posted on your progress

I am not interested in "up to speed", but am in "speed is to be changed". "Up to speed" is merely a cancelling of the command to change speed.

Originally this is what you said:

I wanted to have linuxCNC suspend table feed until the spindle was at speed.

Up-to-speed pauses before a feed command until the pin is true - usually connected so that the spindle speed must be in an acceptable speed window.

up-to-speed doesn't cancel a command to change speed - it makes motion wait till the command is honored.

Respectively:
you seem to making this harder then it needs to be.
Maybe you have a good reason - i just don't see it.

In the end, I just want you to be successful in any way you want to do it.

Chris

Let me return to my fundamental requirement:

1) I want no table feed until a changed spindle speed gets to speed.

2) That is achievable by not "spindle-at-speed", but that is provided by a system outwith the realtime loop, so is not a solution to the problem.

3) An alternative would be a signal within the realtime loop (e.g. "Change speed") which could be detected within the realtime loop to inhibit feed.

4) Without (3) it is necessary to simulate a non realtime version of (3).

5) The realtime part of linuxCNC operates using quasi-asynchronous logic (in that the synchronicity is not defined)

6) I need to raise a feed inhibit signal (e.g. as (2) above) each time there is a command to change spindle speed - effectively a not-'spindle at-speed' - until spindle is at speed.

7) "Spindle is at speed" is outwith the realtime loop

8) Spindle commanded speed change, in the realtime loop, is a singularity.

9) By now it should be convincing that (3) is the best solution, but one not open to me.

10) So: (not changedspeedcommanded ) + spindleatspeed =>inhibitfeed

I forgot to say that the reason I was asking about the scheduling in realtime loops was that my detector of commanded-spindle-speed-change can raise an inhibit pulse for a single loop only but if, before the next loop, the module/component that was to be inhibited intervened then all would be well - the single loop assertion would be detected, and inhibit feed beyond that loop until "spindle-at-speed" were asserted. This would not require pulse stretching.

Waiting for a spindle to come to speed before feeding has been programmed into linux for a long time.

I think you miss understand how spindle at speed works.

motion.spindle-at-speed is an input to motion that motion checks before starting a feed move (it's move specific then that but..)
It is the signal to motion that it is ok to feed now.

It is exactly the pin you need to control.
For instance if you added:
setp motion.spindle-at-speed true to your HAL file (and nothing else was connected to it) run a program it will start the spindle rapid to position before the feed and wait forever.

The component near is usually used to feed this pin. It usually compares the actual speed to the commanded speed and if inside a certain window sets the spindle-at-speed pin True so that motion will start feeding.

motion.spindle-at-speed is not an output.

motion.feed-inhibit is a pin more used for safety like an open door stopping motion. It's a big hammer that probably will do the wrong thing sometimes in this situation.

Chris

rereading your first post - you do seem to understand how spindle at speed works.

IMHO the only reason it didn't work as well as you hoped is because you did the comparison in userland.
If you do the comparison in realtime (ie using near) then it won't matter that the spindle feedback from the USB component is slow responding.

Chris

OK. Let me return to what I want to happen:

1) When[ever] the commanded spindle speed changes I want feed to suspend until
2) Spindle is at speed - indicated by a means/bit *external* to linuxCNC.
3) How do I do that?

From the feedback I have had I now think that my understanding is so far away from reality that I must give up all hope.
Tony

1) Are you sure that what you want? Don't you really only care that the spindle is at the right speed before it starts to feed?
What does it matter if it is accelerating to speed while rapiding for instance.

If you _really_ want it to wait every time spindle speed changes you are going to be in trouble for instance when you change spindle override. There is currently no way to detect S code changes only requested speed which is not always the same.

2) your USB component is capable of sending the actual speed in RPM or RPS isn't it?

Chris