System hangs repeatedly with certain combinations of operations

If I do the move without turning the spindle off it will wait for the spindle to reach speed and then proceed.
Do you think the issue might be with spindle_at_speed after the M5?

I'm not with the machine right now, so cannot run any tests (perhaps later today) but looking at the various hal state dumps I posted previously, spindle-at-speed seems to be showing false all the time, whether the next move works or not.
It does look like I need to check spindle-at-speed, but it doesn't seem like it is the deciding variable (at least not on its own)

This suggests to me that it may hang at the first G1 after the speed setting (M3 S10000)

• spindle.N.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.
•  

Hmmm, second time I'm writing this as the last one seemed to vanish. So sorry if it winds up as a double post

Running whilst monitoring spindle-at-speed
It starts off false
M3 S10000, stays false until reachin the correct speed, then goes true
M5 turns false, and stays false even when the spindle has wound down

It don't know if this is correct, or if M5 is conceptually setting a speed of zero, and therefore spindle-at-speed should be true when the spindle stops

That must be related to the source of your spindle-at-speed signal.

Maybe its always false at a zero speed, which will cause issues with
LinuxCNC if you try doing a cutting move (G1 etc) with the spindle off.

Do you need to do cutting moves with  the spindle off?

If so:

If you have a spindle encoder, you can generate a spindle-at-speed signal
by comparing the commanded spindle speed with the actual (from encoder)
spindle speed with the "near" hal component.

If you do not have a spindle encoder you could add some logic to force
spindle-at-speed true when the spindle is off (M5)

If I understand what I've just read correctly, G0 moves are full speed, whereas G1 are controlled?

This would explain why the tool change/probing code I used as the basis for mine uses G1 calls.

However if it is only the first feed move after the spindle start that matters then I may be able to work around it by making the first move a rapid one?

I'll have a look at whether there's a way to have a "true" value when it is stopped anyway.

Yes, G1 moves are controlled by the feed rate but G0 moves are at full machine speed
Also multi-axis G1 are coordinated but G0 moves are not.


You  could use some logic (say not + or components) or the lut5 component
in conjunction with your external spindle-at-speed signal to force  spindle-at-speed
true either when the spindle is on and the external spindle-at-speed is true or
the spindle is off.

A lut5 example might look like this:

setp lut5.0.function 0x0d
net spindle-on lut5.0.in-0
net ext_spindle-at-speed lut5.0.in-1
net spindle-at-speed lut5.0.out

A lut5 function value of 0x0d means it's output will be true either when in-0
(spindle-on) is false or if both in-0 (spindle-on) is true and in-1 (ext-spindle-at-speed)
are true.


man lut5