Unexpected behavior at end of gcode.

[martin]

Fortunately I was air-cutting, but just now at the end of a fairly lengthy program the Mega-V behaved in an unexpected way -- at the end of the program, rather than running back to zero as I'd expected, it slammed itself into the back right corner at maximum Z height (zero was front left corner, and not at max Z) and alarmed. Err, any ideas why?

...here's the end of the program, including some of the last cutting moves. Whole program is metric, incidentally. Near as I can tell, it completed that last G3, and then went bananas for some reason I'm not seeing.

G2 Y-4.54 Z1.34 J0 K2.54 F400

G1 Z5

X599.335 Y-16.51 F500

Z1.34 F400

G3 Y-13.97 Z-1.2 J2.54 K0

G1 Y-2

Y613.6 F500

G3 Y616.14 Z1.34 J0 K2.54 F400

G1 Z5

Z10 F500

G17

G28 G91 Z0

G90

G28 G91 X0 Y0

G90

M5

M30


Simulating in CAMotics doesn't show the unexpected moves, and Fusion360 doesn't simulate them either.

...any suggestions would be appreciated! I think it's a matter of wonky chaining between paths, but I still wouldn't have expected my G28 to go off in pretty much the opposite direction like that so I'm wondering if there's a UGS setting I'm missing somewhere odd.

[Bruce]

It's the G28 G91 Z0. If you haven't setup G28 before using it you can get erratic behavior. You can disable G28 in Fusion 360 in the post processor for the toolpath.

[martin]

Yep, this is definitely it (well, that and I forgot to run my work offset macro like I thought, so all the math was wrong; object lesson in maybe not relying on macros without some kind of absurdly obvious failsafe.)!

Friends don't let friends rely on macros rather that just editing the post-processor in the first place.