G98 G73 Z retract during XY movement

[norrback]

g98 is a command that tells the cycle to go to the previous z-plane (if it is higher than then R retract plane) ... the counterpart would be g99 which only retracts to the R - plane. now since we can clearly see (from the gcode and video provided) that the drill cycle finishes at z-2 and not at z5 where it should, but it moves up to z5 during the XY reposition, so it clearly knows it's supposed to be up there.

G0 X-119 Y-182.5 Z15 Z5 G98 G73 X-119 Y-182.5 Z-16 R-2 Q0.5 F400 X-19 Y-32.5 X-119

Could not add video here.

[terjeio]

The G73 LinuxCNC specification states that the final Z is at the R position. BTW G73 is not classified as a canned cycle and the retract mode thus does not apply?

[norrback]

But the G98 should make it go to the old Z if it is above R.

This happens

[norrback]

My video of the possible issue

https://youtu.be/UhQNa-qiM2Q?si=csXA2nwdBLefG7v6

[terjeio]

But the G98 should make it go to the old Z if it is above R.

Not according to the G73 specification. Or is the specification incorrect?

[norrback]

Ah, now I see, the g73 is not included based on this spec. read too quick. In fusion360 simulation it goes to old Z, so I don't know whats correct.

And thanks for quick replays

[terjeio]

To complicate this the Fanuc dialect is different and returns to the previous Z if G98 is active. Others I have checked after a quick search either do not specify the return position or are ambiguous about it. It would be nice to know how LinuxCNC actually behaves...

[norrback]

Let's see if I find someone that could test

[Dietz0r]

To complicate this the Fanuc dialect is different and returns to the previous Z if G98 is active. Others I have checked after a quick search either do not specify the return position or are ambiguous about it. It would be nice to know how LinuxCNC actually behaves...

even then isnt grblhal missbehaving with the raise to z5 during the xy movement instead of staying in the r plane? btw: since g73 and the likes all repeat the op until you cancel it with g80 i was under the assumption it was a canned cycle or at least analog to them

i'll see if i can get a linuxcnc user to test that behaviour

[norrback]

This is the gcode in question and specially the line starting with G98...

(6.5mm_drill_corners) (T465 D=6.5 CR=0 TAPER=118deg - ZMIN=-16 - drill) G90 G94 G17 G21 G28 G91 Z0 G90

(Drill6) T465 M6 S4000 M3 G4 P2 G54 G0 X-119 Y-182.5 Z15 Z5 G98 G73 X-119 Y-182.5 Z-16 R-2 Q0.5 F400 X-19 Y-32.5 X-119 G80 G0 Z15 G28 G91 Z0 G90 G28 G91 X0 Y0 G90 M5 M30

[henrikssn]

I don't have access to my machine right now, but my understanding from the LinuxCNC source code is that it respects G98 plane when interpreting G73.

Source code is here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_cycles.cc#L979

[Dietz0r]

Just got it confirmed by a LinuxCNC user. g98 is followed. So it retracts to previous Z on LinuxCNC

[terjeio]

I have now committed refactored canned cycle code, I hope this is closer to how LinuxCNC works. A matching edge version of ioSender has also been uploaded.

Please report back if there are still issues.

[norrback]

thanks! and to the web builder it will arrive with next major grbl update? cannot get my head around building for grblhal2kest printnc board locally.

[terjeio]

The Web Builder has been updated already. I usually do that fairly immediately after a commit.