Sometimes my tool unload code just…stops

Not sure if this is the right category for this question, but I'm having an issue with my tool unload routine (attached). In response to T0M6, it positions the spindle in front of the tool fork, and is supposed to move downward to the fork level with G1, but it just…doesn't move. I have to click the STOP button in Axis, and then issue the T0M6 again, and then it continues without issue.

Any idea why it's stopping? I put a bunch of print statements in the code, and it prints `Unload tool: Lowering F1000`, but doesn't do anything more. Axis seems to think it's still running a program though, since I have to click the stop button.

My experience with variable programming is that sometimes the variables have logically different values than you think. At first glance, I would trigger the feed variable.
Maybe start with this sentence ..
G53 G1 F #<_ini[atc]speed_approach> Z #<_ini[atc]z_pocket>

Yeah, I print out the speed before that line. It prints:

Unload tool: Lowering F5000.0

Is this part of remap code?

Yes, in the sense that I remap M6 to invoke it.

github.com/JetForMe/router-table/blob/ma...auto_tool_change.ngc
github.com/JetForMe/router-table/blob/ma...c_subroutines/ut.ngc

This still happens to me, and it's happening with a new program I'm trying to write to vacuum the table (unload the tool, lower the spindle, move the dust collector shoe over the whole table).

I invoke it from a button in my Axis VCP, but it frequently stops mid-move. Is there some line I need to add to my subroutine to make it wait for the move to complete?

It will randomly stop on the G1 Z down move, or the G1 X move. Always seems to successfully raise the spindle and move to the start position.

My ngc is attached.

Can be tricky troubleshooting these things. Usually I liberally insert queuebusters (eg 'M66 L0 E0') to avoid premature ingestion of code lines by the read ahead.
Maybe try that right after 'G53 G1 X1245'

It may also help to insert debug printing like this (this will print to terminal):
;(print, your_parameter=#<your_parameter>)
Or this will print to the gui:
;(msg, your_parameter=#<your_parameter>)


This will give you an indication of where the execution actually fails.

On my machine, spindle.0.at-speed must be true to do a move with G1

It may also help to insert debug printing

I've got a print statement at the end of the Python routine that still gets called, even though the motion stops.

On my machine, spindle.0.at-speed must be true to do a move with G1

This would result in it not moving at all, but it moves an inconsistent amount and then stops.

The answer was given to me in another post, and it is to pass a longer timeout to the Python function wait_complete(), which, when passed nothing, defaults to 5 seconds.