Tool changes do not work in relative mode

poofjunior

Issue: Switching to relative mode followed by a subsequent move causes movements in a subsequent tool change to be offset by the amount moved in relative mode.

Test Case:
Conditions:

Machine is homed and moved to X=0, Y=0 Z=10.
Machine is in absolute mode
Machine starts with no tools loaded

Operation:

User Switches to relative mode with G91
User moves to location X=10, Y=10, Z=10 with G1 X10 Y10
User invokes tool change with T0

Behavior:

machine carriage tries to pickup tool in a location that is X=10, Y=10 mm offset from the location specified in the macro.

So here's my question: is this expected behavior? Should I prefix all my macros with G90 to ensure movements are absolute?

Heads-up: this behavior may be due to nature of my macros, which rely on creating restore points, but I would imagine that because machine state is pushed upon invoking a tool change macro, any behavior within a macro should behave identically regardless of what mode the machine is running.

Note that this does not happen if the machine is in absolute mode.

For completeness, here are my macros:

tpre0.g

; Runs after freeing the previous tool if the next tool is tool-0.
; Note: tool offsets are not applied at this point!

G1 R2 Z0             ; Restore Z position without tools mounted. Do nothing if no prior position was saved.
G0 X305 Y310 F17000  ; Rapid to the approach position without any current tool.
G60 S2               ; Save this position as the reference point from which to later apply new tool offsets.

tpost0.g

; called after firmware thinks Tool0 is selected
; Note: tool offsets are applied at this point!
; Note that commands preempted with G53 will NOT apply the tool offset.

G53 G1 Y335 F6000            ; Move to the pickup position with tool-0.
M98 P"/macros/tool_lock.g"   ; Lock the tool
G1 R2 Z0                     ; Restore prior position now accounting for new tool offset.
                             ; Restore Z first so we don't crash the tool on retraction.
G53 G1 Y310 F6000            ; Retract the entire tool.
G1 R2 Y0                     ; Restore Y position next now accounting for new tool offset.
                             ; Restoring Y next ensures the tool is fully removed from parking post.
G1 R2 X0                     ; Restore X position now accounting for new tool offset.

Finally, this is not invoked if we start with no tools loaded, but for completeness
tfree0.g

; Runs at the start of a toolchange if the current tool is tool-0.
; Note: tool offsets are applied at this point unless we preempt commands with G53!

G53 G0 X305 Y290 F10000      ; Rapid to the approach position with tool-0. (park_x, park_y - offset)
                             ; This position must be chosen such that the most protruding y point of the current tool
                             ; (while on the carriage) does not collide with the most protruding y point of any parked tool.
G53 G1 Y335 F6000            ; Controlled move to the park position with tool-0. (park_x, park_y)
M98 P"/macros/tool_unlock.g" ; Unlock the tool
G53 G1 Y310 F6000            ; Retract the pin.
;G1 Y290 F6000                ; Move to a safe place to save the position (with offsets applied but without the tool).
G60 S2               	     ; Save this position with tool offsets applied.
                             ; DSF will apply a "G1 R2 X0 Y0 Z0" immediately after this.

Thanks for taking a look!

poofjunior

Solved! Ok, answered my own question, hehe.

@poofjunior said in Tool changes do not work in relative mode:

Should I prefix all my macros with G90 to ensure movements are absolute?

Yes! If any tool change macro involves any movement, we should put the machine into a known mode for that macro only. The default behavior appears to be to both push the current mode and also to enter the macro in that mode. When the macro finishes, the behavior is to pop back the previous state. If the machine started in relative mode, invokes a macro that puts it in absolute mode, and then exits that macro, it will return to relative mode.

dc42

I guess there is a case for having all system macro files switch to absolute movement mode at the start. Maybe to relative extrusion too.

poofjunior

I don't think there's a huge need to be strictly in that direction.

If the documentation mentions that the prior machine state is both saved and set as the starting point upon entering a macro, then folks should be able to work from that. Knowing this now, in my case, from now on, I will prefix all my macros with G/M codes that enforce the machine state that I want to work from when entering the macro.