#448 G81 Z position error causes tool crash

[Eric @ Montreal]

With latest version 2.7.1, G81 canned cycle is supposed to start with a preliminary motion where Z axis retracts to either the height indicated in the R parameter or the latest Z value if it is higher than the R parameter and G98 mode is in effect.

I found out the hard way (crash) that it does not work as supposed.

Here is a code snippet that shows the problem (faulty trajectory appears in Axis) :
G01 X0 Y0 Z0 F60
(G00 Z2)
G81 X3 Y3 Z1 R2
M30

The first G01 sets Z below R value, so, when executing G81, no matter if we're in G98 or G99, it should first retract to Z2, then move to the proper XY location while staying at Z2 and perform the canned drill cycle.
Instead, this code will retract to Z2, then do a 3 axis rapid to the G81 X Y location and the lower previous Z position (crashing the tool) before doing a weird inverted drill cycle going up to the intended Z position and finally retracting to R position.

Uncommenting the G00 Z2 command forces the expected behaviour.

The last free (beer) version of CamBam produces such code when alternating between spiral milling and canned cycles. I have attached the file that crashed on my machine (first crash at line 1477)

This bug could be a regression as I did not encounter that problem before upgrading to 2.7.

[Chris Radek]

This bug exists in 2.5, 2.6, 2.7; you are right that it should use the higher of the old Z and the R setting in the G98 case, according to

http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G98-G99-Set

The regression is

http://git.linuxcnc.org/?p=linuxcnc.git;a=commit;h=df5a469d7

[Sebastian Kuzminsky]

Try the proposed fix in the branch named 2.7-bug-448.

[Eric @ Montreal]

Thanks for the fast fix.
Not sure how / where to get this branch. I'd like to test it if you can point me to it. However, if you corrected the faulty code and excuting the sample works the same with or without the G00 Z2 line, it probably solved the bug.

Sample :
G01 X0 Y0 Z0 F60
(G00 Z2)
G81 X3 Y3 Z1 R2
M30

[Sebastian Kuzminsky]

With the "G0 Z2" commented out, the motion is now:

G1:

• feed to X0 Y0 Z0 at F60

G81:

• rapid to Z2 - this is the higher of the Z starting place (0) and R (2)
• rapid to X3 Y3 - the XY coordinates of the canned cycle
• feed to Z1 - bottom of the hole
• rapid to Z2 - and back out to R

If you're comfortable getting the source with git and compiling it yourself you can checkout the code from git.linuxcnc.org. Or you can try out a pre-compiled debian package of this code from the buildbot, it's in the "scratch" component, the package version number is "1:2.7.1~2.7.bug.448~8b98364". Instructions on how to get it are here: http://buildbot.linuxcnc.org/

[Eric @ Montreal]

Thanks. I tried it (on a VM, not the real machine) and it all seems good. (simulated) behaviour is as expected, both in G98 and G99 mode. Thanks a lot for the fast resolution of this dangerous bug.
Do you know when the fix will be in the main branch ?

[Eric @ Montreal]

After further testing, I found a behaviour that seems odd (not sure if this is the same bug or a new one).
here is the code :

G01 X0 Y0 Z2 F200
(G00 Z2)
G91 G98 G81 X4 Y5 Z-0.6 R-0.2 L3

G90 G00 X3 Y0 Z2
G91 G99 G81 X4 Y5 Z-0.6 R-0.2 L3

(G90 G98 G81 X3 Y3 Z1 R1.5)
M30

The first serie of holes (in G98 mode) retracts to Z=2 as expected between holes.

The second serie of holes (in G99 mode) retracts to Z=1.8 as expected, but then does the rapid to the next position increasing Z to 2 instead of staying at 1.8.

[Sebastian Kuzminsky]

Thanks for the test report. I pushed the fix to 2.7 last night, it will be in v2.7.1-16-g580c69c from the buildbot, and in 2.7.2 when i release that, maybe this weekend.

I also put the fix in 2.6, where it will be in v2.6.10-19-g3bac57d (and 2.6.11).

I will look into the retract issue you raised.

[Sebastian Kuzminsky]

Yeah, I see the too-high rapid between cycles in G99 mode... I guess there's more bugfixing to be done here.

[Sebastian Kuzminsky]

In 2.4 with G99, it does the retract up to R, and the traverse between G81 L cycles is done horizontally at the R level, which seems right.

In 2.5 (and probably all later branches) with G99, it still does the retract up to R, but then (if OLD_Z is higher) it ramps up from R to OLD_Z while traversing to the next hole location.

[Sebastian Kuzminsky]

I pushed a fix for this "traverse between canned cycle repeats" bug, it's in v2.7.1-22-g3ef729c and v2.6.10-24-g61d6c88 from the buildbot. Please take it for a spin and let me know if you see anything else amiss.

Thanks for the excellent bug reports, they made it easy to reproduce the problem.

[Eric @ Montreal]

I followed instructions on the buildbot and added both scratch-rt & scratch-sim repositories, but i only see the 2.6.10-2.6.bug448 you made earlier. Can't find where is v2.7.1-22-g3ef729c

[Sebastian Kuzminsky]

Both fixes are in 2.7 now, but I see I still still haven't updated the buildbot docs with the 2.7 info. Use the "master" deb source that's appropriate for your system, but with the string "master" replaced with "2.7".

[Sebastian Kuzminsky]

Ok, the buildbot front page now has the deb lines for 2.7.

[Eric @ Montreal]

Thanks. Tested, and it seems to behave very well, even when alternating between G98 & G99 modes. AFAIK, good to go for 2.7.2

Getting that kind of support really gave me one more reason to use LinuxCNC on my next router !

[Sebastian Kuzminsky]

Glad to hear it's working right for you now!