MDI Commands

BigJohnT wrote:

If it stops at the G38... then you don't have the probe input connected correctly.

linuxcnc.org/docs/html/gcode/gcode.html#sec:G38-probe

JT

Yes,
how is it not connected correctly ?
This code works flowlessly from a file.

G21
g54
g10 l20 p0 z0
g38.2 z-10 f10
g10 l20 p0 z11.316
G0 z30 F30

But when hooked to a button... its stops when touching the plate.

-D

Problem solved

When issuing the MDI command by hand: 0100 call I discovered that
multiple triggers were stopping the sub.

For some odd reason, as a G-Code file... the exact same code DOES work. (??? timing is a bit different ???)

with the right debounce code in HAL... it all works great.

conclusion => IT'S A MUST TO USE DEBOUNCE with the PROBE....

Thanks for all the suggestions.

-Doron

p.s.
here is a snippet of my debounce code (sourced from Chris Radek via Rick).

....
loadrt debounce cfg=1
setp debounce.0.delay 100
addf debounce.0 base-thread
net deb-probe-in debounce.0.0.in <= parport.0.pin-13-in-not
net probe-in debounce.0.0.out
net probe-in => motion.probe-input
...

Hi all. My first post on the forum here.

I realize this topic is a bit old, but I wanted to share my experience in case someone else finds it helpful.

I'm running LinuxCnC 2.7.8 and have some experience with the issue the OP is describing.

I'll summarize my understanding as follows:
A.) Load probing program (using file -> open) and run as G-Code. The program runs as expected (I will refer to this as running by G-Code for the remainder of this post)
B.) Make a custom button in the axis gui whose sole purpose is to run the same program (just being controlled from clicking a button rather than file -> open) and then clicking the button to run the program. The program runs as expected up to a certain point, then abruptly stops prior to reaching the M30 command. (I will refer to this as running by button for this discussion)

I troubleshot this problem, and was able to develop a work-around. My thoughts/findings:
1.) The program runs correctly when ran by g-code, so I know my probe is working fine. Just for fun I tested the program 5 times in a row, and it worked every time.
2.) When ran by clicking the button, the program stops at the same line of code each time, and does not finish the program. I tested this multiple times and got the same result each time -> this is good information because if it behaved erratically it would be a much harder problem to diagnose.

Having tested items #1 and #2 I began removing code to see what happens when ran as g-code and then running the same code by button.

My thoughts/findings from the second round of testing:
3.) When ran as g-code, the program runs until it reaches M30 for all cases
4.) When ran as a button, for any program that contains a probe command, the code will execute up to, and including, the final probe command, and then terminate

An example g-code #1:
G0 X150
G38.3 F100 X200
G0 X150
M30

And the corresponding button code:
o<m308> sub
G0 X150
G38.3 F100 X200
G0 X150
M30
o<m308> endsub

When ran as g-code it executes as follows:
Rapid to X150
Probe towards X200
Once probe contact then Rapid (back) to X150

When ran by the button it executes as follows:
Rapid to X150
Probe towards X200
Once probe contact then terminate the program (i.e. do not Rapid back to X150)

So when running as g-code it works as intended, and when ran by the button it does not. This is problematic, as I would like to do other things after my final probe move (move the probe, compute centers, angles, distances, etc) so I set about finding a work around.

I tested the following:

An example g-code #2:
G0 X150
G38.3 F100 X200
G0 X150
G38.3 F100 X200
G0 X150
M30

And the corresponding button code:
o<m308> sub
G0 X150
G38.3 F100 X200
G0 X150
G38.3 F100 X200
G0 X150
M30
o<m308> endsub

(The above code is the same as g-code #1, except that I duplicated the probe and the rapid commands, so the probing happens twice.)

When ran as g-code it executes as follows:
Rapid to X150
Probe towards X200
Once probe contact then Rapid (back) to X150
Probe towards X200
Once probe contact then Rapid (back) to X150

When ran by the button it executes as follows:
Rapid to X150
Probe towards X200
Once probe contact then Rapid (back) to X150
Probe towards X200
Once probe contact then terminate the program (i.e. do not Rapid back to X150)

So now I'm getting somewhere. I've learned that when ran as a button the program will run up to and including the final probe command and then terminate, while running in g-code it runs until M30.

So now I can use the following work around:

As the absolute last command the program executes, immediately prior to M30, I add a "dummy" probe command, like so:

G-Code File "As-Intended":

....program code that I want to execute....
M30

"Modified" Code, So that it executes by button:

....program code that I want to execute....
G91
G38.3 F100 X0.0001
G0 X-0.0001
G90
M30

This switches to incremental mode (G91), does a small distance probe command, rapids back to where it started the probe command from (so the probe ends up in the same position it was before the "dummy" probe command) and then switches back to absolute mode (G90). I switch into and out of incremental mode so that the "dummy" probe command can be issued regardless of where the probe is without worrying about computing a nearby coordinate.

Note 1: If you do not want to move your X axis (or any of your "working" axes -> in my case I have a traditional 3-axes setup using XYZ) then you can add a 4th "dummy" axis. I didn't like the idea of having to move my X axis for this work around, so I switched my config files to where I am now running an XYZA machine. The A axis is configured as a linear axis, I have it set to auto-home with no switches during the homing sequence, and I gave it some allowed movement. Now my probe button runs like this:
....program code that I want to execute....
G91
G38.3 F100 A1
G0 A-1
G90
M30

The probe never makes contact during the A-Axis move, as its a "dummy" axis, but this workaround allows all my probe g-code to be run as a button. Note, if you are maxed out on axes (because you are using all of the available axes) then my recommendation is to figure out which axis can undergo a minimal amount of movement without damaging anything.

Note 2: I did not investigate the OPs solution of using debounce commands, since I knew that my probe was operating correctly and I couldn't see how that would solve the problem. That said, the debounce command is worth considering as it seems to have worked for him; I've just put forth an alternate work around in the event it helps someone in the future.