Machine stall after tool length probing

Hi everyone

Sometimes the machine stalls when probing the tool length. Usually at the start of a program which is good so I can just rerun everything and it will be fine. But I kinda wanna know why this happens so I can trust the machine again

This is what I do:

Use MDI (or ngc program) to issue an "T1 M6" command
This calls the tool length measuring macro "messen.ngc"


I added some debug lines to see where exactly the program stalls.
1, 2, 3 -> stall

So the machine is stuck @ line 34  "G1    Z2.5  F500                (frei fahren)"

What is confusing me is when I check the machine status

It tells me the command is: "G38.2 Z-10  F25                 (messen fein)"
But the debug message "4" never shows which is before that command.
Also the status shows "current_line    34" which would be a different command (the one above).

Could it be that the probe is jumpy and that is cancelling line 34?
Is there a way can see if it stalled because of a bouncy probe?
(I'm using debouncing in hal already with a value of 3)

 

It's intriguing to read the rest of the output. It looks like execution is actually stalled at

And the reason that you see the numbers is:

To find where the system _really_ is you could try using an  M67  command and watch the output with a halmeter.

Though that doesn't really explain why the code should stall at the probe move. Is it possible that spindle-at speed is false, or feed-hold or adaptive feed are set to zero?


 

Hi,

I have the same problem with the same file (except positions).
I could create a minimal example to reproduce this behavior. My code stuck in line 21 exactly when probe is touched. 
see here:   .

I will check your listed pins. spindle-at-speed is definitly low. 

These are my signals at all G38.2 moves I do in upper .ngc file.
 

Any Idea?

LinuxCNC will wait at any feed move (G1, G2, G3) if spindle.0.at-speed is false (as it is here. Slightly confusingly Halshow has dark red for false and yellow for true)

It is usual for spindle.0.at-speed to be driven true if the spindle speed is zero (and commanded to be zero) so you need to look at the HAL logic driving that pin.

I set the spindle-at-speed 5 seconds after spindle relay is set.
And I reset the spindle-at-speed when spindle relay is not set.
LinuxCNC waits these 5s if there is a G0, G1 after M3, that is correct.

Does it make sense, setting spindle-at-speed in probing mode although spindle is not running? During probing the spindle must not run.

Why the first G38.2 in my test file are working? spindle-at-speed is here also false.

Yes, because you generally want to prevent moves if the spindle has been stopped but is still spinning.
I don't think that spindle-at-speed blocks G38.x moves (though I think it probably should). So I would guess that your code is stopping at the first G1.

You do have the option of setting at-speed permanently true if you don't actually have any spindle speed feedback.

But, otherwise, if you are using a timer, then it should be true 5s after spindle on and 5s (or maybe more) after off.

I tested following file:  
I wanted to test a G1 after a M3 command to force a wait for spindle-at-speed.
LinuxCNC stuck in Line 16.

Very strange.

Hm ok.
I need the feature that LCNC waits 5s until spindle relay switched on because the spindle has a external lock to prevent my fingers...
So how I have to configure it?
actual config:
relay-rrk-feedback => ladder timer TON 5s => spindle-at-speed

is this a solution:
on rising edge spindle.0.forward then reset ladder timer and spindle-at-speed then wait 5s and set spindle-at-speed
in hope that ther is no race condition.

But general I don't understand: If a M5 command was fired, why lcnc want to wait everywhere?

test_tasten.ngc works with G0 instead of G1.