Run-from-line and v.2.7.3

You are correct: probe result. I may have meant a short version of probe debug result. ?

So, I can't seem to get any response from an additional subroutine entered after the probe routine while run-from-line. I still get the unwanted probe. I can have Z moves-only in a subroutine that are ignored during a r-f-l. Only the G38.2 seems affected.

Paul

As it seems the phantom move is a left over from the sub's g38.2 move perhaps try...
Rick G

A possible correction from before:

When I said: "(X is now at ~193.557549)(not 150.000) and the machine moves X to 250.000 from 193.557549", I now observed that when X gets to 193.xxxxx and the probe switch trips, X moves to 150.000 at 4000mm/m before the torch skates across the cutting material from X150 to X250 at 2000mm/m. Just wanted to mention this for accuracy.

I tried my test with the Pre probe, Probe, Post probe subroutine.

Probe results from full cycle (Keyboard "R")
Pre probe Z: 0.000874
Probe result: 0.000000
Post probe Z: -8.407087

Observed: As expected - Rapid to X0, probe, X0 to X150 at 4000mm/m, then X150 to X250 at 2000mm/m, Z20.0

After running multiple full cycles getting the same results and the machine at the end (X250.000 Y0.000 Z20.000) I then selected line 10, G01 X150.000 F4000.0 and then run-from-line:

Pre probe Z: 0.000874
Probe result: 0.000113
Post probe Z: -8.407087

Observed: Coordinated move from X250.000 Z20.000 to X0.000 while Z moves to probe switch activation and then the program runs as programmed from that line (3) without running subroutine while Z0.001. If I remove the line: "G38.3 Z.01 F3001.0 (debug, Pre probe Z #5063)" from the subroutine, the r-f-l does its coordinated move from X250.000 Z20.000 to about X186.000 when Z probe switch trips and then X moves to 150.000 at 4000mm/m and then torch skates from X150.000 to X250.000 at 2000mm/m, then Z20.000.

What I noticed during this test with full Pre/Probe/Post subroutine while it was moving from X250.000 to X0.000 using run-from-line is that the Axis code display highlighted line 3, G00 X0.000. So I changed this line to G00 X50.000 on a hunch and sure enough, X moved from 250.000 to X50.000 while coordinated Z probe!

So run-from-line on line 10 is executing line 3. If I remove the line "G38.3 Z.01 F3001.0 (debug, Pre probe Z #5063)" and run-from-line , axis highlights line 4. I can move these lines up or down in the file, but still get same results: locks on line with G00 X0.000 or call to subroutine.


Returning to v.2.7.0 and running same test:

Full cycle -
Pre probe Z: 0.000874
Probe result: 0.000000
Post probe Z: -8.407087

Run-from-line -
Pre probe Z: (No results displayed)
Probe result: (No results displayed)
Post probe Z: (No results displayed)


If you actually read the above and made it this far - Thank you...

Paul

After upgrading from v.2.7.0 to v.2.7.3 and I run a file using the run-from-line feature, LinuxCNC is going into my touchoff subroutine (which is on a previous line from the r-f-l line) and trying to execute the G38.1 within the subroutine. Or at least in combination with other previous lines.

Also read it but not sure what the result was.
No question that you are not getting the expected results from run from line.

If I recall the biggest problem was that z dropped down and then dragged across the work piece sometimes moving it.
So does the modified pre probe, probe, post probe sub allow the machine to go to the correct location without dragging the tip across the work?

Rick G

The biggest problem with LinuxCNC v.2.7.3 is the probing when it has not been commanded to do it. The modified Pre/Probe/Post sub only helped me discover that LinuxCNC is also considering other lines prior to the run-from-line. So depending on code prior to the run-from-line can determine if I can salvage a job. It appears that I am not the only one who has noticed this. It might not be an ongoing problem for anyone else, but that doesn't mean it should be ignored, either. That's my opinion, at least.

When I don't want to scrap cutting material, I run v.2.7.0. That version does not produce the unwanted actions on the seemingly exact same code.

I think everyone agrees it is a bug. You might want to check if a bug report has already been filed. If not you may want to file one. The testing you have done should help find the problem.

In the mean time we were hoping to find a work around that might help you.

As most of the programs I run use subs and they are known to not work well with run from line I never use it. I find it safer to edit the file and reload it to complete the work.

Rick G