DuetWebControl allows auto bed compensation with an active tool
-
I'm using the Duet2 Wifi in my E3D Toolchanger. One thing that has caused me trouble in DuetWebControl is that the button for Auto Bed Compensation.
Immediately triggers the measurement process with no confirmation or warning. Usually this is fine, however if you happen to have a tool active and your probe is on the gantry not the tool it will almost certainly result in a severe crash (as it will on the E3D Toolchanger) since the tool sits lower than the probe.
Unfortunately I've managed to hit that button twice now when I was trying to hit the down arrow for the dropdown and misclicked which triggered the measurement and as I had a tool active crashed the bed (and bent my Z-axis leadscrew in the process).
Is there a way to prevent this? From what I understand the button just triggers a G29 call so there is no script to edit to add a tool drop off command to. Obviously if I am manually entering Gcode I'm on my own but for a button that can be easily mis-clicked in the UI that triggers a process like this it feels like a confirmation would be a good idea, particularly if there is an active tool.
Or am I missing an easy way to prevent this?
-
I too have wanted g29 to behave like g32 does and call a seperate macro like bed.g instead.
I wonder if this would work.. for gcode commands that don't exist you can create a macro with the gcode as the name and when you call that gcode the macro gets executed. So I wonder if you created a macro called g29 it would call that instead. Then you can specify what you want to happen in there.
-
The issue with that approach is that you cannot pass parameters to macros. So it would only be useful for operations where the gcode doesn’t need any parameters.
-
It looks like DuetWebControl 2.x.x has partially addressed this by moving the G29 option into the menu itself, so it’s less likely to press accidentally now.
I think I should still throw up a confirmation if a tool is active though. I’ll definitely check things out in 2.x.x though since I haven’t been using it yet.
-
Could you solve this by having a deployprobe.g file that contains a T-1 command?
-
That sounds like the right solution. I will try it out when back at my printer. Is there a comprehensive list of all supported system .g files somewhere?
Would that then also solve the issue of homing Z doing the same thing? I would guess so, the only thing I am wondering is whether this works when using the endstop as the probe.
