Does not stop on probe contact during non-probe move

[rene-dev]

Here are the steps I follow to reproduce the issue:

1. launch simulator, turn on, home
2. command a non-continuous jog, turn feed down to slow it down.
3. trip probe: http://linuxcnc.org/docs/html/hal/tools.html#_simulate_probe

This is what I expected to happen:

stop moving

This is what happened instead:

continues to move, and crash into a possibly very expensive probe

It worked properly before this:

works in 2.7

Information about my hardware and software:

• I am using Debian 9
• I am running A binary I built myself

[rene-dev]

its more complicated than this: it does stop moving while jogging only if the machine is not homed.

[rene-dev]

its here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/control.c#L583 in JA world jogs are in teleop, not free. not sure how to abort teleop jog, and how to check if jogging is active. checking for (joint->kb_jjog_active || joint->wheel_jjog_active) doesnt work, because the axis is jogged, not the joint.

[jmelson]

OK, in my old 2.7 version, the behavior was that motion would stop if the probe CHANGED to tripped status during a jog move. Having the probe tripped at the START of the move would not inhibit motion. Makes sense, so you can jog off the probe, but you HAVE to be careful.

I'm pretty sure the behavior was the same for G1 moves, but have less experience with that.

Jon

[SebKuzminsky]

@jmelson did you intend to close the issue?

I think there's still some discussion to be had here and a decision to come to.

[jmelson]

On 12/05/2017 12:03 PM, Sebastian Kuzminsky wrote:

@jmelson https://github.com/jmelson did you intend to close the issue?

I think there's still some discussion to be had here and a decision to come to.

ACCK! Did I hit the wrong button? No, I did NOT intend to close the issue!

Sorry,

Jon

[Lcvette]

hey guys, i am experiencing the same issue, probe triggered during a non probing positioning move does not stop and causes a crash. I am assuming there was never a solution found for this or if there was it is not anywhere i have found while looking. this is a bad situation obviously and i assume as old as this is maybe a solution is somewhere just not where i have found? thanks in advance if you can direct me!

Chris

[jmelson]

On 10/10/2019 10:45 PM, Chris Polanski wrote:

hey guys, i am experiencing the same issue, probe triggered during a non probing positioning move does not stop and causes a crash. I am assuming there was never a solution found for this or if there was it is not anywhere i have found while looking. this is a bad situation obviously and i assume as old as this is maybe a solution is somewhere just not where i have found? thanks in advance if you can direct me!

My experience seems to be different. The one situation I find where you can crash is if the probe is ALREADY tripped, it will not error out, and allow you to deflect the probe more. Of course, in this case, LinuxCNC doesn't know if you are moving AWAY from the probe or more toward it.

But, there's a specific error message for "probe tripped in non-probing move" that will stop the machine. What version are you using? I am using a 2.6.x version on my production mill, and it seems to do the right thing there. (Yes, that is pretty old.)

Jon

[Lcvette]

I'm in testing on version 2.9 and 2.8 which are requirements of the probe_basic gui. I certainly could see the dilemma you posed on moving further towards a part when tripped. In this instance all the routines are prewritten and proceed to work but they have user parameters entered at the gui. If all parameters are correct there's no issue as tripped while positioning situation would never occur but if the entered to short of a stock x or y hint size this could cause a probe crash on a downward positioning move. Just looking for a way to let Linuxcnc know if probe is triggered during a non g38.n move that an error should be kicked out and stop movement.

On Fri, Oct 11, 2019, 10:51 AM jmelson notifications@github.com wrote:

On 10/10/2019 10:45 PM, Chris Polanski wrote:

hey guys, i am experiencing the same issue, probe triggered during a non probing positioning move does not stop and causes a crash. I am assuming there was never a solution found for this or if there was it is not anywhere i have found while looking. this is a bad situation obviously and i assume as old as this is maybe a solution is somewhere just not where i have found? thanks in advance if you can direct me!

My experience seems to be different. The one situation I find where you can crash is if the probe is ALREADY tripped, it will not error out, and allow you to deflect the probe more. Of course, in this case, LinuxCNC doesn't know if you are moving AWAY from the probe or more toward it.

But, there's a specific error message for "probe tripped in non-probing move" that will stop the machine. What version are you using? I am using a 2.6.x version on my production mill, and it seems to do the right thing there. (Yes, that is pretty old.)

Jon

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LinuxCNC/linuxcnc/issues/368?email_source=notifications&email_token=AJ7FXOHJSYTMXVNOU63UDTTQOCHIDA5CNFSM4EGOIBMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBAHYVI#issuecomment-541097045, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ7FXOCSG5KRHTOFCYXS4FTQOCHIDANCNFSM4EGOIBMA .

[ZincBoy]

I think I ran into this issue on 2.8.1 and found the following behavior:

On start of linuxcnc, the probe input would stop motion during a G1 move. This is correct the correct behavior.

After calling a o-code function (from the MDI input or from python) the probe input would be ignored during a G1 move. It didn't seem to matter what was in the o-code, even an empty function would cause the issue. It seems that just calling the o-code caused the probe input to stop halting motion. The probe input would still work properly on a G38.x call. Linuxcnc had to be re-started before the probe input would stop motion again.

I did find a work-around in python. After calling self.command.mdi("o word function") and waiting for it to complete, call self.command.reset_interpreter(). The reset_interpreter() function seems to fix the issue and the probe input stops motion as expected on subsequent G1 moves. (command = linuxcnc.command)

[andypugh]

I found the code looking for something else just now: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/control.c#L620

Which runs if emcMotStatus->probing == False.

I can't find any direct link between that and a HAL pin to check the state to see if subroutine calls change something.

[ZincBoy]

I looked at this some more and was pulling my hair out trying to reproduce it but I found some other interesting behavior.

The ignoring of the probe pin depends on if an NGC file is loaded or has been run.

• If no NGC file is loaded, calling an O word function causes the probe pin to be ignored from then on.
• If an NGC file is loaded, calling an O word function does NOT cause the probe pin to be ignored. BUT running the NCG file causes the probe pin to be ignored during execution and after it has been completed.

The probe pin being ignored during NGC is concerning as I am planning to include probing in some of my code. It would still work during the G38 calls, but crashing would be much more likely.

After digging into the code a bit I added some debug printout to the values in the if statement on line 626 of control.c. Looking at tpQueueDepth and tpGetExecId I found the following behavior when the probe was tripped during motion:

No .ngc file loaded case all run in sequence: Startup: tpQueueDepth = 1, tpGetExecId = 0, motion would stop After calling O word: tpQueueDepth = 1, tpGetExecId = 1744, motion would NOT stop After loading a .ngc file: tpQueueDepth = 1, tpGetExecId = 0, motion would stop While running the .ngc: tpQueueDepth = 4, tpGetExecId = 6, motion would NOT stop After running the .ngc: tpQueueDepth = 1, tpGetExecId = 8, motion would NOT stop tpGetExecId never went back to zero after this.

With a .ngc file loaded to start but not run: After calling O word: tpQueueDepth = 1, tpGetExecId = 0, motion would stop While running the .ngc: tpQueueDepth = 4, tpGetExecId = 6, motion would NOT stop After running the .ngc: tpQueueDepth = 1, tpGetExecId = 8, motion would NOT stop After calling O word: tpQueueDepth = 1, tpGetExecId = 8, motion would NOT stop Loading but not running a different .ngc file: tpQueueDepth = 1, tbGetExecId = 0, motion would stop

It seems that the code was expecting tpGetExecId to go back to zero after programs were run so that it would only stop on MDI commands. The problem is that tpGetExecId does not get reset to zero unless a new program is loaded. Its value will vary depending on the file being run. My suggestion would be to remove the check on tpGetExecId altogether. That way probe transitions will stop motion in both MDI calls as well as .ngc programs.

[robEllenberg]

Great analysis! It makes sense to treat a probe trip outside of a probing as an error, and it would fix both problems at once to eliminate that check for the executing id like you suggested.

Rob

On Fri, Feb 26, 2021, 9:27 PM ZincBoy notifications@github.com wrote:

I looked at this some more and was pulling my hair out trying to reproduce it but I found some other interesting behavior.

The ignoring of the probe pin depends on if an NGC file is loaded or has been run.

• If no NGC file is loaded, calling an O word function causes the probe pin to be ignored from then on.
• If an NGC file is loaded, calling an O word function does NOT cause the probe pin to be ignored. BUT running the NCG file causes the probe pin to be ignored during execution and after it has been completed.

The probe pin being ignored during NGC is concerning as I am planning to include probing in some of my code. It would still work during the G38 calls, but crashing would be much more likely.

After digging into the code a bit I added some debug printout to the values in the if statement on line 626 of control.c. Looking at tpQueueDepth and tpGetExecId I found the following behavior when the probe was tripped during motion:

No .ngc file loaded case all run in sequence: Startup: tpQueueDepth = 1, tpGetExecId = 0, motion would stop After calling O word: tpQueueDepth = 1, tpGetExecId = 1744, motion would NOT stop After loading a .ngc file: tpQueueDepth = 1, tpGetExecId = 0, motion would stop While running the .ngc: tpQueueDepth = 4, tpGetExecId = 6, motion would NOT stop After running the .ngc: tpQueueDepth = 1, tpGetExecId = 8, motion would NOT stop tpGetExecId never went back to zero after this.

With a .ngc file loaded to start but not run: After calling O word: tpQueueDepth = 1, tpGetExecId = 0, motion would stop While running the .ngc: tpQueueDepth = 4, tpGetExecId = 6, motion would NOT stop After running the .ngc: tpQueueDepth = 1, tpGetExecId = 8, motion would NOT stop After calling O word: tpQueueDepth = 1, tpGetExecId = 8, motion would NOT stop Loading but not running a different .ngc file: tpQueueDepth = 1, tbGetExecId = 0, motion would stop

It seems that the code was expecting tpGetExecId to go back to zero after programs were run so that it would only stop on MDI commands. The problem is that tpGetExecId does not get reset to zero unless a new program is loaded. Its value will vary depending on the file being run. My suggestion would be to remove the check on tpGetExecId altogether. That way probe transitions will stop motion in both MDI calls as well as .ngc programs.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LinuxCNC/linuxcnc/issues/368#issuecomment-786988299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJHUPC745UE637W3VHJ2I3TBBKBRANCNFSM4EGOIBMA .

[ZincBoy]

I don't seem to be able to push to a branch in the repository but here is my proposed fix:

Replaces lines starting at 662

if(!GET_MOTION_INPOS_FLAG() && tpQueueDepth(&emcmotDebug->coord_tp)) {

// system is moving tpAbort(&emcmotDebug->coordtp); reportError(("Probe tripped during non-probe move.")); SET_MOTION_ERROR_FLAG(1); }

[andypugh]

@ZincBoy Have you tested the fix? You should be able to create a pull-request (anyone can). For a change to a single file you can edit is here on the web site and create a pull request. But in this case it is probably best to do the full fork, clone of the fork, change, compile and test, then make the pull-request. Or, if that is too much work, someone else might get round to it.

[ZincBoy]

I took a crack at creating a pull request. Hopefully it works. It was a nice distraction from cleaning the sump in my mill :)

[freisei]

since this commit (i think) some things seems to be no more possible.

There are situations where the probe is flickering. In my case its when the running tool drives into a laser beam to measure diameter. I go to laser with G38.2 - as soon as the probe-pin is triggered by the laser, G38.2 is left, but i cant avoid a kind of flickering the probe-pin because the next edge of the endmill will hit the laser.

When i want to get out the mill from the laser with a G0, i get a probe tripped error.

I think the only solution to fit all situations is to implement something like discussed there: https://github.com/bdring/Grbl_Esp32/issues/603

I can imagine there are many other situations where the probe is flickering, for example if the probe-switch is of low-quality or the machine is swinging.

[andypugh]

You could "gate" the probe signal using motion.motion-type == 5: http://linuxcnc.org/docs/2.8/html/man/man9/motion.9.html Though a debounce might suffice.

[freisei]

sounds good. I will try that. If there a are a couple more users which such requests, i think i would be better to implement this in linuxcnc instead of every such user brews its own a little hacky M-Code/Hal solution.

But thank you very much!

[ZincBoy]

I have gated my probe pin input by anding it with one of motion digital outputs (motion.digital-out-00). I do this as I need to select which of the three probing system inputs are active.

In my g-code I use a M64 p0 to turn on probing and M65 p0 to turn it off. This is also tied into the tool change and probing will always be active if tool 99 or tool 98 are loaded in my system.

I think that probing behavior is one of those things that will require some HAL logic in all but the trivial cases.

[freisei]

ive built the hal logic and can switch the probe-input to be only active on type-5-motion or not. Works so far.

The bad thing: it seems something is to slow.

On a G34.2 move with running spindle for some reason i get three pulses from type-5-probe-pin until linuxcnc decides G34.2 is over. It seems that the task that turns on watching for probe-interrupts is a little faster - so i get "Probe tripped during non-probe move."

Upper graph is probe-signal that only is active when motion.motion-type == 5. The lower one is dirctly from the probe.

OK, i can do debouncing now, but i think this is a bug or a kind of race condition which is better corrected somewhere else.

[andypugh]

I am thinking that a G38.9 to select the probe, and 0 for no-probe might be a way to do it. But that would be non-standard. RepRap used G38.n Pm to choose a probe, but that would be a bit odd as a way to disable the probe input.

[ZincBoy]

I was thinking G38.6 to enable probing and G38.7 to disable. Using G38.9 Pm with 0 being no probe would be a more elegant way to handle it.

I would still end up using the HAL for most of the logic though. The auto probe selection and power on based on tool number is very useful when manually probing.

[freisei]

i will create a component to match my needs. see here: https://forum.linuxcnc.org/24-hal-components/42321-new-component-probefilter-to-handle-probe-tripped-errors#206504

[freisei]

While creating the filter component i found that the probe-signals handling and erroring with "probe tripped during non-probe move." is buggy.

I've done a G38.2 F100 move.

As you can see in the scope-screen there are no motion-types other than 5 or 0. There is no type 2-move. But when motion.coord-error goes up, there are error-messages "probe tripped during non-probe move."

It seems that the error appears if the probe triggers the second time. And motion-type is still 5 because of deaccelerating. If i fasten up the G38.2 speed to F1000 the error appears many more times.

I've hacked a test-component to reproduce the beaviour.

https://github.com/freisei/probefilter/blob/b20485ef199d055864fec3c4bbe063c0ac01a829/probebugtest.comp

You only have to connect motion.probe-input and motion.motion-type. The test-component will fastly trigger the probe a while after a type-5 move is detected. Add the components function to a fast thread, or increase G38.2 F-speed to reproduce (or maybe even lower the accelerating-values of the machine)

Should i move this to a new issue?

Greets from bavaria. Freisei