Z probe error (BLTouch) still starts printing

[BeosDoc]

I have a BLTouch probe and when I turned the printer on I didn't notice that it was blinking that it had an error. I selected a job to print. The Duet 3 gave an error about it but continued to print in mid air. It should have checked for any errors before it even starts to heat up the bed and nozzle or at least cancel, and shut off the heaters, when it went to home the z axis and couldn't.

I'm running Duet 3 (V1) with toolboard with firmware 3.2-beta4. Also the BLTouch is connected to Duet 3 and not the toolboard.

[Veti]

there is a grubscrew at the top of the bltouch. try adjusting that.

[BeosDoc]

@Veti It doesn't always have that problem, only errors once in a while. That's not the issue, its that the printer acts like everything is okay and starts printing the job even though it hasn't home Z axis

[BeosDoc]

It's in standalone mode no rPi

[Veti]

someone reported that to dc42 already.

but you should still adjust the grub screw.

[BeosDoc]

I did a search and didn't find anything regarding that. Thanks

Should pin one topic with current issues, help keep repeats down.

[GTech]

The same happens for other errors with the ZProbe. aka. ‘“Z Probe did not trigger during probe move” RRF logs the error and just continues as normal,
Happens on RRFv2 and v3 also happened to me with the BLTouch and a Pinda, a regular inductive probe and the differential IR Probe

Another scenario is when you do active bed levelling with multiple Z screws if one probe point fails, it continues with the other points and eventually starts to print.

[TypQxQ]

Same with inconsistent probes. I think it is supposed to just continue. As long as you have all axes homed it prints.
The solution is to check with conditional gcode that the probe was successful or else abort.

[GTech]

To be honest it is kinda counter intuitive, communication failures with a filament monitors, unrealistic readings from thermal sensors or a wiring fault on a NC switch are all handled in a way that tries to prevent damage, ZProbe errors seem to be the exception.
I understand, that it is complicated as most probes are constantly triggered during a print but it is not impossible.

RRF is aware that the ZProbe is a BLTouch (M558 P9) and a BLTouch reports errors by being constantly triggered. It would be nice I RRF could recognise when a BLTouch is in error mode and handle it appropriately.

The tips of those probe pins snap of rather easily and replacement pins cost a fortune, so much that I have given up on using a BLTouch in combination with a Duet board.

... well, just my 2 cents.

[OwenD]

@GTech
You can easily handle errors in your homing (or other) files using conditional g-code
I have this in homeall.g

if sensors.probes[0].value[0]=1000 ; if probe is in error state
		echo "Probe in error state- resetting"
		M280 P0 S160 ; reset BL Touch
		G4 S0.5
if sensors.endstops[2].triggered
	echo "Probe is already deployed - retracting"
	M280 P0 S80 ; retract BLTouch
	G4 S0.5

Whether you reset, abort or whatever is up to you.
You could even put similar in daemon.g if you want continuous checks.

If you're getting that many errors I'd be looking at the wiring.
About the only time I see one is if the printer starts with the nozzle at < Z=5mm or so as it hits the bed during POST of the BLTouch
The above handles that prior to G28 which also lifts Z 5mm to be sure of clearance.

My previous clone on the other hand was a different story.

[GTech]

It was always my fault with my macros not beeing resiliant enough.

Thanks for the script but my point was a different one,
With the BLTouch we have a sensor that is able to detect and report a malfunction, which i think is a good feature.

IMHO it would be good if RRF could make use of this and be enabled to recognize when a malfunction is reported and to respond..

There is already specialised code for the BLTouch so this would "complete" the current implementation and close the feedback loop.