[Bug]: active tool not changed if home XYZ in tpre.g

[AndyEveritt]

Duet Forum Discussion Thread

internal discussion

Which Duet products are you using?

• Duet2-Wifi
• Duet2-Ethernet
• Duet Expansion Breakout Board
• Duex2
• Duex5
• Duet2-Maestro
• Maestro Dual Driver Expansion
• Duet3-6HC
• Duet3-3HC
• Duet3-1XD
• Duet3-1LC
• Duet3-Tool Distribution Board
• Duet3-Mini5+
• Duet3-Mini2+
• Raspberry Pi or other SBC
• SmartEffector
• Magnetic Filament Sensor
• Laser Filament Sensor
• PT100 Daughterboard
• Thermocouple Daughterboard
• PanelDue
• Other
• None

Firmware Version

3.5.0-rc3

Duet Web Control Version

3.5.0-rc3

Are you using a Single Board Computer (RaspberryPi) with your Duet?

• Yes I use a SBC.
• No I do not use a SBC.

Please upload the results of sending M122 in the gcode console.

M122 Report

Please upload the content of your config.g file.

Config.g

Please upload the content of any other releveant macro files.

tpre0.g

; tpre0.g
; called before tool 0 is selected

;Ensure no tool is selected
;T-1

;Set tool detect switch trigger
; M581 T2 P0 S0

; Check tool detect switch
;M98 tooldetectpre.g"

;if global.lastTool < -1
;    abort "Unknown tool loaded"

M98 P"scripts/maybehome.g" X1 Y1 Z1 C1 B1

;Unlock Coupler
M98 P"/macros/Tool Control/Coupler - Unlock"

M564 S0 ; allow movement outside the normal limits

var tool_x = -11.2
var tool_y = 216.5

var pickup_speed = 1000
var movein_speed = 5000
var movement_speed = 15000

;Move to location
G1 X{var.tool_x} Y{var.tool_y - 30} F{var.movement_speed}
;Move in
G1 Y{var.tool_y - 10} F{var.movein_speed}
;Collect
G1 Y{var.tool_y} F{var.pickup_speed}

;Close Coupler
M98 P"/macros/Tool Control/Coupler - Lock"

;WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
;if you are using non-standard length hotends ensure the bed is lowered enough BEFORE undocking the tool!
G91
G1 Z15 F1000
G1 Y-5 F1000
G90

; Check tool detect switch
;M98 tooldetectpost.g"

;Move Out
G1 Y{var.tool_y - 15} F{var.pickup_speed}
G1 Y{var.tool_y - 100} F{var.movein_speed}

; set Y max for this tool
M208 X-14:323 Y138

; apply the normal limits again
M564 S1

maybehome.g

if exists(param.X) && (!move.axes[0].homed)
    G28 X
if exists(param.Y) && (!move.axes[1].homed)
    G28 Y
if exists(param.Z) && (!move.axes[2].homed)
    G28 Z
if exists(param.C) && (!move.axes[4].homed)
    G28 C
if exists(param.B) && (!move.axes[3].homed)
    G28 B

Details specific to your printer.

E3D Toolchanger

Links to additional info.

No response

What happened?

Expected result

• Homes axis if required then selects tool

Observed result

• Homes axis correctly
• Picks up tool correctly
• RRF thinks it hasn't picked up tool
  • state.currentTool = -1

Steps to reproduce

• T0 when XYZ are unhomed

[AndyEveritt]

Also if the maybehome.g script is removed from the tpre and the same input sequence occurs. RRF thinks it has picked up the tool but no movement occurs. I would expect it to throw an error that insufficient axis homed

[AndyEveritt]

Further testing:

Homing any axis apart from Z within tpre seems to be ok.

Having G28 Z in tpre causes RRF to run tpre but not tpost. This is independent of if Z is homed or not before selecting the tool.

[dc42]

Homing within a tool change messes with the state machine, also on some machines (e.g. tool changer) it may be desirable to put T-1 in the homing files which would lead to infinite recursion if the tpre file uses G28. We should perhaps generate an error message if G28 is encountered in a tool change file. I think it's possible to home within a tool change file by calling e.g. homeall.g directly. So we should probably document this, and that G28 is not allowed in a tool change file.

…

On Thu, 25 Jan 2024 at 15:22, Andy Everitt ***@***.***> wrote: Further testing: Homing any axis apart from Z within tpre seems to be ok. Having G28 Z in tpre causes RRF to run tpre but not tpost. This is independent of if Z is homed or not before selecting the tool. — Reply to this email directly, view it on GitHub <#949 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUYI3BK7JEKO5DQOIIFR5DYQJ2DXAVCNFSM6AAAAABCKUKWGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJQGQZDQMJVGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- David Crocker, Duet3D Ltd.

[T3P3]

This also relates to any "abort" commands called from within a tool change macro or a macro that this calls. This is also invalid.

related to #765

[Mogatek]

Not solution to the situation, but possibly helpful:
I wrote my homeall.g file in a way that it accepts X, Y, Z parameters and homes only the given axes if has not been homed already, or homes everything if no params are given. Completely similar to @AndyEveritt's solution with the difference that it does not call G28 to "outsource the work" but does the actual homing directly. G28 is only ever executed when I press the home buttons on the GUI.

A config option to disable G28's behaviour of dropping the existing "homed" state as its first step would be an useful addition.

[AndyEveritt]

I wonder if calling M98 P"homez.g" would cause the same issue as G28 Z