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

I have had almost total success.

I wrote a component that compared the commanded spindle speed with current speed of spindle, and fed this through timedelay to stretch the output (otherwise it would have been asserted for a single iteration of the servo loop). This is then fed into another component that forces a negative transition of its output (which connects to the motion.spindle-at-speed pin). The component is also fed by the spindle speed from the USB spindle controller, or rather the bit that tells that the spindle is at the set speed; this sets the output high.

I could probably have used already existing components to build what my second component does, but as it's almost 50 years since I messed with Quine-McCluskey and I'd make mistakes trying to build from virtual logic gates, and because I reckoned a specialised component would be less resource hungry, I have done it that way.

There is no problem when changing speed from non-zero - feed (non-G0) is inhibited. However, when I change the speed from zero there is a tiny feed glitch. I think this might be because my software counts a commanded stop that results in zero rpm the be spindle at speed. I'll make a special case of it and see if gets rid of the problem.

This has been a stiff learn. Thanks for advice.

Now to document what I've done.

Tony

I tried a special case of spindle-at-speed being FALSE when stationary, but that prevents jogging!

So back to where I was.

Let me summarise the problem I now have:

1) My resetting of motion.spindle-at-speed is done in the servo loop.
2) When spindle speed starts from zero I issue a command such as
M3S2000 G1F100X100
there is a very brief glitch of motion until my components disable
motion.spindle-at-speed.
3) It looks like there is a race condition between the G-code interpreter causing feed to initiate, and my resetting motion.spindle-at-speed to inhibit feed.

With my limited understanding of the intervals of linuxCNC I can't think of my next step in solving the problem. At present I'll live with it.

Tony

I'm glade you got something usable!

I wrote a component that compared the commanded spindle speed with current speed of spindle, and fed this through timedelay to stretch the output (otherwise it would have been asserted for a single iteration of the servo loop)

Why would this only be true for one loop? It should be true for as long as the commanded doesn't equal the actual.

spindle at speed should not have effect on jogging (I tested 2.8 to confirm).
(feed and jogging are mostly two different processes in linuxcnc)

again If it was mine I would write a component that does this logic:

if commanded is zero:
set spindle-at-speed False
else:
if commanded is within 100? RPM of actual:
set spindle-at-speed True
else:
set spindle-at-speed False

In this way it's not possible to feed until the actual is at the right speed.

If i thought I needed a time delay I would actually use the timedelay component as a base and add that logic to it.
But I would suggest it's not necessary (trial would confirm)

Chris

>spindle at speed should not have effect on jogging (I tested 2.8 to confirm).
> (feed and jogging are mostly two different processes in linuxcnc)

I'll have to do some more tests. Unfortunately gardening has priority for the next couple of days. A hectare of grass and brambles, and a small lawn mower. I must get a goat.

From further testing I have discovered that what I thought was a partial success was not.

I had thought that it was my resetting of motion.spindle-at-speed that was inhibiting feed. I then found that I had left in the setting of motion.feed-inhibit, and it was this that was inhibiting feed.

I deleted the signal feeding that pin, so that all I had was motion.spindle-at-speed to affect feed inhibiting. I placed a watch on that pin. Issuing a set spindle rotating and feed (G1) in one line, and saw that the pin did what I wanted - It went false then, when the spindle was at speed, went true. But it did not inhibit feed.

I deleted the signal connected to motion.spindle-at-speed, then set it to false manually, the issued the same command. Feed was inhibited, and when I manually set the pin to true feed began.

I assume that my setting of the bit is too late for the routine that determines whether feed should be inhibited. i.e. a race condition, and I can't think how to solve the problem.

Tony

I have gone back to the idea of setting spindle-at-speed false if the spindle is stationary. I have removed the feed-inhibit. All now seems to work perfectly - no slight feed as the spindle starts to spin.

Tony

Further checks reveal all is not well, and either I misunderstand, or there is a bug in linuxcnc (2.7.15).

My components and module reset the motion,spindle-at-speed when spindle speed changes, until that speed is achieved. I can see this by placing a watch on the bit.

If I issue commands (G1 moves) preceded by spindle speed changes (Sxxxx) that are themselves preceded by spindle mode commands (M3,M4) then feed is inhibited until the spindle is at speed. If, however, I change the speed without the M4/M4 command then feed is not inhibited even though motion.spindle-at-speed is reset.

Motion documentation says that "Motion will pause until this pin [spindle-at-speed] is true ... before the first feed moved after each spindle start or speed change...".

I read this to mean that feed will be inhibited whenever a speed change is made, with or without a preceding M3/M4.

1) Am I interpreting the documentation correctly?
2) Could there be a bug in Motion?
a) If so, what tests could I carry out?
3) What does an M3/M4 instruction do that makes Motion act differently to a reset spindle-at-speed?

Tony

1) Reading the docs, I think you could interpret them as you think.
2) Ether a bug or the docs are wrong.
Can you describe how you would use this behavior?
set speed, feed, speedchange, feed - seems a bit unusual, particularly on a mill.
I would expect set speed, feed, speedchange, rapid, feed.
Maybe you could try adding a rapid to see if it triggers.

3) m3/4 if a separate logic decision in the code which probably overrides other decisions.

I am not saying that I would use the behaviour (set speed, feed, speedchange, feed ), but I am trying to get things working for eventualities that might arise from generated G-code. I don't have any CAM software at present, so generate G-code by hand, or using some single software I have written.

I have been trying some more things, and get unexpected behaviour (this is using MDI in Axis):

1) If I issue an S command on one line e.g. s200<enter> then M3<enter> on the next line then the spindle spools up.
2) If I reverse the order, e.g.
M3
S200
then motion does not instruct the spindle to start.
3) As single line commands both
M3S200
S200M3
work.
4) Once the spindle is rotating an S command can be used to alter the speed, without an M3 command.
5) Stopping the spindle with M5 or S0 resets things so M3 needs to be used again.

(2) Seems to be contrary to the document at tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374, which states:

"It is OK to use M3 or M4 if the spindle speed is set to zero. If this is done (or if the speed override switch is enabled and set to zero), the spindle will not start turning. If, later, the spindle speed is set above zero (or the override switch is turned up), the spindle will start turning."

I'll try the G0 test when I'm with my mill - I don;t trust doing feeds over the network.

Tony

I can confirm the S needed before M3/4 issue. I am not positive why this is required.

I can confirm the setting S to 0 is equivalent to M5 - I had a patch to change that but it was not accepted into 2.8 -I'll add it to master in the future.

Chris