Bug or security feature?

Phaedrux

It's a good idea to add something like the following to the end of config.g and/or the start of homeall/homez

; BLTOUCH PREP
;
G4 S1
M280 P3 S160 I1 		; Alarm Release and Push-Pin UP just in case it's in alarm and deployed
G4 S1
M402				; Retract probe just in case it's down

This makes sure the BLTouch is ready to go and with the addition of raising the Z axis slightly to give the pin enough clearance you should be able to home successfully without the additional power cycle.

Danal

Homing is an interesting thing. It should work, always, on every axis, no matter where the machine is when it powers up.

Writing a sequence of moves that makes that happen, without ever jamming the machine, is often not quite possible. So homing sequences are written to cover the majority of cases, and to be "good enough" for the edge cases.

Example: On any axis, with any switch or probe, it is possible that the axis will be pressed against the switch before homing starts. Therefore, the first move (probably) should be a very short move, a few mm, in the 'away' direction. Then make the first actual homing move, and so forth. But... what if... that axis is hard up against the OPPOSITE end? That very first small move will physically jam. Maybe that's OK if it is a small/short enough move.

And on and on... we could type paragraph after paragraph of scenarios.

So, now, let's bring the BLtouch into the picture. RETRACTING probe. Needs a certain 'clearance' to deploy. Going back to our 'first move should be away' above, an axis with a BLt should probably move AWAY from the BLt about 3 mm BEFORE it even tries to deploy. And that will work 99.9% of the time. It is literally what I would do to resolve your original question.

But...

That does leave the possibility that the bed is at the very max part of Z at power up, and that first 'away' move will jam it. Again, I'd still set it up that way, and just know the limitation.

Phaedrux

@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.

Danal

@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'.

Phaedrux

@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.

Danal

No Prob. I'm in the "add coffee get human" set myself.

drmaestro

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.

jumpedwithbothfeet

@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!

deckingman

@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

A Former User

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

arhi

@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 S160

would get it running ok. I switched to PP so can't test now, but according to my notes this was the solution for that.

Phaedrux

@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.