Run-from-line and v.2.7.3
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??
Please Log in or Create an account to join the conversation.
I am using Axis GUI, but didn't think to use the block-skip feature. Can it be turned off on-the-fly??
I think so. This is the first time I have thought of a use for it
![:-) :-)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
I am using Axis GUI, but didn't think to use the block-skip feature. Can it be turned off on-the-fly??
No, you have to stop the running program to toggle block delete.
JT
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
No, you have to stop the running program to toggle block delete.
Ah, well, there goes that idea then...
Please Log in or Create an account to join the conversation.
- skunkworks
- Offline
- Moderator
-
- Posts: 376
- Thank you received: 150
(maybe not well thought out)
sam
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
The test files used -
Main file:
G21 (Units: Metric)
F1 S1
G00 X0.000
o<Test.TouchOff> call
G00 Z3.8100
M03 S1
G01 Z3.8100 F3002
G04 P0.2
G01 Z1.5240 F3001.0
G01 X150.000 F4000.0
G01 X250.000 F2000.000
M05
G00 Z20.000
M05 M30
and subroutine:
o<test.touchoff> sub
G38.2 Z-100 F3001.0 (debug, probe result #5061)
G10 L20 P1 Z0.000
G00 Z9.900
G10 L20 P1 Z0.000
o<test.touchoff> endsub
M2
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.
Please Log in or Create an account to join the conversation.
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"
(debug, probe result #5061)
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
Please Log in or Create an account to join the conversation.