@dc42 - thanks for the pointer to move.limitAxes. This should help us a lot.
A little background on our work. We're developing our tfree.g, tpre.g and tpost.g macros fro tool changing. Our tools are all parked outside the soft-limit are of the machine. Our simplified approach for a tool change has been:
tfree.g -
G53 move to a position right in front of the parking spot for the tool.
allow movement outside soft limits
G53 move the tool to the parking position and call the macro to release it
G53 move to get back inside the soft limits
don't allow movements outside soft limits
tpree.g
G53 move to a position right in front of the new tool parking space
allow movement outside soft limits
G53 move the tool to the "grab" position and call the macro to lock it to the carriage
G53 move back to get just free of the tool parking posts (but still outside the soft limits)
don't allow movements outside soft limits
tpost.g
allow movement outside soft limits
heat the hot end
purge some filament
G53 move one (or more) times over a wiping thing
G53 move to get back inside the soft limits
don't allow movements outside soft limits
memory slot 2 relative moves back to the original tool location
Our current theory for root cause is the macro that locks the new tool in place is leaving the U axis beyond it's soft limit which is causing the last moves in tpost to be blocked. When we try another tool change immediately after, the first move (to the spot in front of the parking space) in tfree gets blocked, but the subsequent move into the parking space is not. That lets the tool move into the wrong location, resulting in lots of noise, sometimes broken parts, and a quick run to the power switch.