Open AndyEveritt opened 6 months ago
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
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.
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 https://github.com/Duet3D/RepRapFirmware/issues/949#issuecomment-1910428150, 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.
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 https://github.com/Duet3D/RepRapFirmware/issues/765
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.
I wonder if calling M98 P"homez.g"
would cause the same issue as G28 Z
Duet Forum Discussion Thread
internal discussion
Which Duet products are you using?
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?
Please upload the results of sending M122 in the gcode console.
Please upload the content of your config.g file.
Please upload the content of any other releveant macro files.
tpre0.g
maybehome.g
Details specific to your printer.
E3D Toolchanger
Links to additional info.
No response
What happened?
Expected result
Observed result
state.currentTool = -1
Steps to reproduce
T0
whenXYZ
are unhomed