Twice now I have accidentally hit the Auto Bed Compensation button in the Duet Web Control when I have had a tool active, immediately resulting in a Z-axis crash. I've been lucky not to destroy my Z endstop (or worse) so far. Is there a way to prevent this from running when there is an active tool? I guess this is more a Duet/RepRapFirmware issue than a Toolchanger one but perhaps someone knows.
And unfortunately it looks like it did result in worse, I believe my Z leadscrew is now bent. Wonderful :-(
Put T-1 in the bed compensation script first? Then it should drop the tool off before performing the probing. Actually I just remembered the auto bed button just runs a GCODE command....hmm..
All leadscrews are probably bent a little. However, the coupling to the bed motion, from what I can see, mostly means that's not going to cause massive issues. How bent is it? If it's any consolation, I may have done the same thing, but while exploring maximum Z motion. Once you have a print bed installed, I really don't think you can safely get to 300, so in the end I've capped motion at 280, possibly even 275. Sadly not before running it into the ground too much and i think that may have slightly bent the leadscrew.
It is bent enough that I can visibly see the deviation under rotation. It also causes some loud squeeking near the upper part of the motion. This seems to reduce over time, presumably as things work their way back to normal. I probably should loosen everything up again though and re-tighten as I guess things may now be slightly misaligned. The shame is it really felt perfect when I first got it. That button is just way to easy to hit by mistake. I get that if I am manually inputting Gcode the it's my own fault but that thing is smack in the middle of the UI.
I think it's been addresses in newer versions of DWC anyway. Here's my layout for the Dashboard: And if I hit that button at the top right, it doesn't do anything except show a drop down: This is the version I'm using, in Dark Mode: https://github.com/chrishamm/DuetWebControl/releases/tag/2.0.0-RC7
Yes, same behaviour for me too. The new WebControl takes some getting used to initially, but I really like it now.
Thanks for the heads up. Looks like there is an official rather than RC release of 2.x.x now. Any reason you haven’t updated? I’ll definitely give it a go.
Official release is working fine for me, not noticed any bugs at all in the web control, be prepared for a major change in layout
I was working on the good old - if it ain't broke, don't fix it - model. That said, I succumbed and updated today.
I've managed twice to ram a tool into the bed, once by starting auto-compensation and once by hitting Z-home in Octoprint withe a tool mounted. Lucklily, the tool fell of in both cases without noticeable damage. I think there should be some safety measures to prevent this. But it will probably need an additional sensor to detect the presence of a tool and some firmware changes in addition. Still very new to the Duet (got the printer a week ago and it prints beautifully), so I need to learn a bit more...
As long as you haven’t restarted with the tool attached, Duet does know the tool is there so should be able to implement features to disallow certain commands when the tool is active. However when you get a problem and have to hit the emergency stop with a tool active it’s a pain to get off, the only way I know is to Home C and catch it.
Actually in my post over on the Duet forum @dc42 suggested adding T-1 to deployprobe.g which I am guessing would cover both bed compensation and homing cases. I won’t have access to my printer for a few days if someone else wants to give it a go.
Adding T-1 to deployprobe.g worked for bed leveling but not for homing z. Strangely even adding T-1 to the top of homez.g it still doesn't return the tool before homing. But homez.g does call the "Coupler - Unlock" macro which works so you won't get as hard of a hit.
I guess, T-1 is executed only, if all axes are homed. As soon as a homing command is active, the respective axis is considered not-homed until the command is finished successfully, so T-1 doesn‘t work within a homing script.
