Bug or security feature?
-
@Danal said in Bug or security feature?:
move AWAY from the BLt about 5 to 8 mm BEFORE it even tries to deploy
That's excessive. It only needs to be equal or slightly more than the trigger height. Same goes for the dive height really. I use 3mm for instance.
To solve the zmax issue I have my max print height set 3mm shorter than the physical travel actually allows.
-
@Phaedrux said in Bug or security feature?:
@Danal said in Bug or security feature?:
move AWAY from the BLt about 5 to 8 mm BEFORE it even tries to deploy
That's excessive. It only needs to be equal or slightly more than the trigger height. Same goes for the dive height really. I use 3mm for instance.
3mm. Edited...
Concept still holds.To solve the zmax issue I have my max print height set 3mm shorter than the physical travel actually allows.
However that is set, the switch or BLt has to trigger... so it is still possible that the machine is sitting right at that 'triggered already' at power up. First move should still be 'away'.
-
@Danal said in Bug or security feature?:
However that is set, the switch or BLt has to trigger... so it is still possible that the machine is sitting right at that 'triggered already' at power up. First move should still be 'away'.
IF the BLtouch is triggered when my the bed is at Zmax I have bigger issues.Sorry, misread. Coffee still not fully in effect.
-
No Prob. I'm in the "add coffee get human" set myself.
-
The problem with BLTouch is that when the power is turned on, it performs a test/initialization movement by deploying and retracting the probe 2 times. If the Z height at this moment is lower than the deployment height, then you go into the error state I've mentioned and it can't be corrected by resetting BLTouch and also you can't solve it by any gcode because no g code is being used at that moment. In fact, if the behavior I have described in my original post (going up instead of down and not deploying) is the only way the problem is corrected afterwards, as if the Z height didn't increase, the problem would repeat itself, until the Z height is changed by manual intervention. That's why I sometimes miss the older firmwares where you were allowed to move the axes before homing them.
-
@drmaestro I’ve had this exact issue myself, I thought maybe adding to the end gcode in the slicer a z move to lower the bed post print might help, I’ve yet to implement it yet mind and it’ll still only be a work around!
-
@drmaestro said in Bug or security feature?:
.........................That's why I sometimes miss the older firmwares where you were allowed to move the axes before homing them.You can restore that behaviour by adding M564 H0 to your config.g file https://duet3d.dozuki.com/Wiki/Gcode#Section_M564_Limit_axes
-
can't recall not being able to reset mine, but suppose if you have a spare fan output you could wire the bltouch to that and hard reset it with M42
-
@drmaestro said in Bug or security feature?:
is lower than the deployment height, then you go into the error state I've mentioned and it can't be corrected by resetting BLTouch
Not sure this is also true for v3.
I had the issue of BLTouch going into "error state" during testing mostly cause it was "horizontal" and not "vertical" or sometimes even upside down and it would fail to init during power-on test.M280 P0 S160 M280 P0 S120 M280 P0 S160would get it running ok. I switched to PP so can't test now, but according to my notes this was the solution for that.
-
@drmaestro said in Bug or security feature?:
If the Z height at this moment is lower than the deployment height, then you go into the error state I've mentioned and it can't be corrected by resetting BLTouch and also you can't solve it by any gcode because no g code is being used at that moment.
The gcode I posted is exactly for this situation. Placed at the end of config.g for power on, and at the start of homeall/homez it's able to clear any error state. And if your homing file has a G1 H2 Z command to raise the Z by at least the trigger height of the BLTouch you're good to go.
