Run-from-line and v.2.7.3

I'll have to try debugging next chance I get. Thanks for the example. But, again, I think it's not just a Z move. If I remove the G38.2 from the subroutine, I don't get the -Z move before executing the run-from line.

I have tried moving to the next needed position before run-from-line, but I still get the -Z move. In this case, what happens is that I get a somewhat coordinated move: As the Z is moving down, I also get a -X to about 185-187mm which is where the probe switch makes contact and then it returns to X250.000 as the torch raises. The Z does move after the probe, but since it's a coordinated move with X and my touchoff offset is almost 10mm, it takes a little distance before the torch tip actually gets off the material.

Yes - I am using M53 for feed stop control. If it doesn't cause a problem, I like implementing it this way instead of adding it to each code file - To me it's more of a system option as opposed to a job.

I am using Axis GUI, but didn't think to use the block-skip feature. Can it be turned off on-the-fly??

OK - I thought of adding the forward slash to all touchoff calls, then block, run-from-line, and then unblocking for the upcoming touchoff calls. This would not work.

what about a if/then based on a hal bit? (then have a skip button in a side panel.)

(maybe not well thought out)
sam

Just so we have this straight.
In your case you are...
Not switching between G90 and G91 during the program.
You are staying in one coordinate system (G54?)
You are not using offsets such as tool offsets.
Your probe is a straight Z down move.
There is no offset X.Y between the probe and the torch tip.
You are using M53.
When you stop a program and then run from line the Z makes a straight down Z move till the probe triggers, but no error code is generated, and then goes to the line requested location without lifting.
However if you move the machine to the next line requested location instead of a straight Z down move a X and Z coordinated move is made then a X and Z coordinated move is made to the requested location.
When you run the debug messages a debug before the G38 move a debug with the G38 move and a debug after the G38 move.

Rick G

I will answer the best I can.

I'm not knowingly/intentionally switch between G90 G91
I am staying in one coordinate system, G54
No tool offsets
My probe is expected to be straight down
Not sure what is meant with XY offset : probe & torch tip
I am using M53

When restarting using R-F-L, Z move is usually straight down, USUALLY successful probe switch trip and then Z moves up but coordinated with X and/or Y to line requested location. Exception is with posted test file(s) where unwanted probe move down is coordinated with a -X. I have had unsuccessful probes that error and stop. Not sure, yet, of the cause.

I need to run debug yet, but am attaching LinuxCNC status file from previous test file posted. I don't know if this helps in the mean time.

The unwanted G38.2 seems to only come from the external subroutine. For testing, if I replace the call to the subroutine in the main file with the contents of that subroutine, there is no unwanted probe move.


Probably the most significant point (in my opinion) is the unwanted action(s) do not occur while using v.2.7.0. Maybe 2.7.3 (and possibly earlier (2.7.1, 2.7.2?) have tightened up variables which allowed me to get away with while using 2.7.0. Or there is an unintentional bug.

Thank you...
Paul

Here are the results from debugging my G38.1

The test files used -
Main file:
and subroutine:
If I run as normal cycle, I get expected results. It rapids to X0.00 (if needed), Z moves straight down and resets to 0.00, Z moves up to 3.81mm, torch signalled to fire, Z moves straight down to 1.52mm, X moves to 150mm at 4000mm/m and then X continues from 150-250mm moving at 2000mm/m, Z moves straight up to 20mm, program end. Probe debug = 0.000000.

Complete program can be run multiple times with same results.

For this test, I let the program run to end and then started a run-from-line at G01 X150.000 F4000.0.

As expected, as Z moves down for the unwanted probe, I get X moving toward negative until the Z probe switch trips (X is now at ~193.557549)(not 150.000) and the machine moves X to 250.000 from 193.557549, Z moves up to 20mm. Probe debug = 0.000000. I can run-from-line multiple times with same, unwanted, results.

After running one or more run-from-line cycles and I am at the end of the program: If I start the cycle with a normal start, Z stays at 20mm, X moves from 250.000mm to 0.000mm, Z probes straight down, file runs as normal and probe debug 3051 = 193.557549 (and sometimes 193.662914) which is X position when run-from-line probe switch trips.

As said in an earlier post, this is happening with LinuxCNC v.2.7.3.

As expected, as Z moves down for the unwanted probe, I get X moving toward negative until the Z probe switch trips (X is now at ~193.557549)(not 150.000) and the machine moves X to 250.000 from 193.557549, Z moves up to 20mm. Probe debug = 0.000000. I can run-from-line multiple times with same, unwanted, results.

I take it you mean with the unwanted z move you get a "probe result 0.00000" not " Probe debug = 0.000000"

Which seems to indicate the z movement is left over from the sub file being called earlier, which it should not.
I wonder as a work around it you were to call another sub from the main program right after every test.touchoff sub,
perhaps a sub that does noting but print a different debug message? Perhaps that might clear the leftover move.

Rick G