• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login

Tool changes do not work in relative mode

Scheduled Pinned Locked Moved
Duet Hardware and wiring
2
4
201
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • undefined
    poofjunior
    last edited by poofjunior 7 Jul 2020, 20:11 7 Jul 2020, 20:08

    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!

    1 Reply Last reply Reply Quote 0
    • undefined
      poofjunior
      last edited by 7 Jul 2020, 20:20

      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.

      1 Reply Last reply Reply Quote 0
      • undefined
        dc42 administrators
        last edited by 7 Jul 2020, 21:15

        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.

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        1 Reply Last reply Reply Quote 0
        • undefined
          poofjunior
          last edited by 7 Jul 2020, 23:00

          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.

          1 Reply Last reply Reply Quote 0
          1 out of 4
          • First post
            1/4
            Last post
          Unless otherwise noted, all forum content is licensed under CC-BY-SA