Feature: BLTouch Special Handling

[GadgetNutt]

I just upgraded to 1.1.0-RC6 and the first two prints I had about an hour or so in seems could be triggering an event on the Z probe servo. I have not had this issue before so I'm looking for guidance on what is causing this. The probe is a BLTouch and aprox an hour into the print it seems to be getting triggered and it goes into an error condition. The probe should just remain in its up position during the print, but the pin is caused to drop. I don't know if it is the probe itself or 1.1.0-RC6 is somehow triggering the error condition by triggering the servo.

[Grogyan]

The BL Touch does not consume current to keep the pin retracted, ie Red LED stays on
I would suggest looking at other reasons as to why the probe goes into an error state, maybe because there is a MaxTemp trigger? This is what has happened to me, and have fixed the problem, where it was the thermocouple reading through the SPI that was getting the wrong reading.

Can you please elaborate on the problem, and also please include the configuration.h and configuration_adv.h files

[Sniffle]

BLTouch should not use the servo deactivation delay, this can cause the probe to run into issues. I've got 2 printers running with it and the only issue i have had is the pin needed to be removed and cleaned after close to 400 hours of printing.

[thinkyhead]

Perhaps we should add a new probe type (ulp!) named BLTOUCH and if it is selected, disable the SERVO_DEACTIVATION_DELAY in Conditionals.h. Otherwise it will be hard for users to discover this.

I assume, @Sniffle, that users should still leave DEACTIVATE_SERVOS_AFTER_MOVE enabled…?

(In older Marlin, SERVO_DEACTIVATION_DELAY was all you needed to get DEACTIVATE_SERVOS_AFTER_MOVE, but now if you only set DEACTIVATE_SERVOS_AFTER_MOVE it still disables the servo, but it does so with no delay. My understanding is that if you never deactivate the servo, it might overheat.)

[GadgetNutt]

@Grogyan why in the world would a error condition on the BLTouch be related to a MaxTemp issue? The BLTouch blinks its own LED when it is in error. This should be completely unrelated to MaxTemp.

@thinkyhead I like that idea. I'd personally think the BLTouch could become a big standard for 3D probing and deserves its own set of instructions. It could automagically then set the servo codes 10, 90 and add menu item for resetting the probe, and other related specifics for the probe. It should also test if the probe is enabled before doing a Z probe so no head crash occurs.

[Grogyan]

@timeshell I was getting clarification from you how the BL Touch is going into an error state.

BL touch could very well be the new defacto standard in the future when it comes to Bed Probing, over capacitive.
Not sure how you would encompass that sensor over others with simple defines in the configuration.h file. Perhaps this is something to look at going forward as there are so many different probes, it gets confusing to the novice what they need to set for their particular probe.

I haven't need to touch anything in the conditionals.h relating to the BL touch

[Sniffle]

@thinkyhead BLTouch probes should not use the servo deactivation delay or whatever it is called now that sends the probe to a low state to prevent twitching.

BLTouch uses an ATTiny (i think) chip to interpret servo pulses and a hall effect sensor to have the chip send a switch press. The pin is moved via an electromagnet that is switched on and off via the chip. By sending the probe to a low state you are effectively depowering the chip and making it lose its position. Should it randomly get a power pulse it will do its default power on routine which is to cycle the pin up/down 2 or 3 times before storing the pin. So low or no power is a bad idea for the bltouch.

That being said the interpreted angles by the chip and their actions are as follows.

• 10 - deploy probe light is off
• 90 - retract probe light is on (deploy/retract could be swapped. I'm pulling from memory. It's set as 10,90 in config)
• 120 - self test as far as i know cycles the pin endlessly until another command is given
• 160 - reset error state. If the bltouch is ever in a state that it knows it shouldn't be in. Ie the pin gets stuck and cant deploy the bltouch blinks until the problem is fixed or the error is cleared using the above angle with m280

Commands are given to the BLTouch using standard servo commands. e.g., M280 Px Sxxx

[GadgetNutt]

@Sniffle According to an email I received from ANTCLABS, this is the option that should be enabled for the BLTouch.

"And If you cut the the line, the magnetic force are being stronger..."

DEACTIVATE_SERVOS_AFTER_MOVE

[Sniffle]

I had issues when i first set mine up until i disabled that. But, if that's what antclabs says go for it... I'll leave mine disabled as the only issue I've had since disabling it is a dirty pin that needed to be cleaned.

[thinkyhead]

should also test if the probe is enabled before doing a Z probe

Well… if Marlin is explicitly enabling and disabling it, then we should already "know" when the probe is enabled.

[GadgetNutt]

In theory. However, when I first started playing with the disable features I seem to recall something wasn't working properly and I ended up get crashes. Since the BLTouch is able to report its pin position any way by a servo command, is an extra sanity check going to hurt? At worst it's a few extra lines of code. At best it can save someone some money.

[thinkyhead]

is an extra sanity check going to hurt?

So… After we enable it, ask it if it's really enabled. Keep trying to enable it a few times, and fail if it never enables. After disabling it, ask it if it's really disabled. Keep trying to disable it a few times, and fail if it never disables.

[GadgetNutt]

Before probing, ask it its current state, regardless if it has been enabled or disabled or whatever. I have had numerous occasions where In the middle of probing it goes into error or isn't working properly and it either crashes or on a G29 it just keeps lifting the Z repeatedly. It should check before each probe the status of the BLTouch so it can stop if it is error.

[thinkyhead]

ask it its current state

I see. So you're saying it might enable or disable itself without our knowledge.

[GadgetNutt]

See updated comment above.

[Sniffle]

How can it do that? It interprets signals and carries out commands the same as a servo does. The only thing it sends to the board is via the endstop. The servo code doesnt interpret the position of the servo it just sends pulses to the servo to make it move. If you prevent a normal servo from moving it just grinds the gears trying to move the number of pulses sent. Its in effect a dumb actuator with no communication between control board and chip. It just stores the last command sent so that it itself will know when it is in an improper state and gives a physical(blinking light) warning. By sending a check you are basically just sending a 2nd retract or deploy command which wont do anything unless the probe loses power at which point you are giving the probe power again sending it through its boot sequence of deploy/retract 2-3 times and then defaulting to a retracted position.

[GadgetNutt]

You query the Z ENDSTOP status on the probe. If the pin is up on the probe when it should be down, it is in error.

[thinkyhead]

I will have to read the datasheet and programming guidelines for this probe. I'm about to Google, but feel free to post any helpful links.

[GadgetNutt]

They post a lot of their information here:

https://plus.google.com/communities/109126963511513081214?iem=4&gpawv=1&hl=en-CA

[Sniffle]

Querying the endstop wont do you any good. Its a swipe across a hall effect sensor. The endstop is triggered via a pulse that is sent for, if i remember the documentation correctly, .5 seconds. @thinkyhead. My son is finally asleep ill go pull up what i can and post it.

[GadgetNutt]

Specs here:

https://plus.google.com/113792662927481823969/posts/femibaRv54Y?hl=en-CA

[thinkyhead]

[GadgetNutt]

From their Indiegogo page:

How to release the Alarm :

• Power ON after Power OFF
• Connect after Disconnect
• M280 P0 S160

How to get status of endstop using M119 :

• Power ON or Port Connect
• G28 or HOME
• M119:

x_max: TRIGGERED
y_max: TRIGGERED
z_min: TRIGGERED
z_max: TRIGGERED

• M280 P0 S10
• M119:

x_max: TRIGGERED
y_max: TRIGGERED
z_min: open
z_max: TRIGGERED

• M119 after ALARM:

x_max: TRIGGERED
y_max: TRIGGERED
z_min: TRIGGERED
z_max: TRIGGERED

[thinkyhead]

Hmm. So to deal with the ALARM, we should check the ZMIN endstop at the point when probing is about to start (immediately after moving to the "deployed angle" M280 P0 S10) and keep doing servo[servo_endstop_id[Z_AXIS]].move(160) (and delaying a moment) until the ZMIN endstop goes to "open" state.

[GadgetNutt]

A reset command may be required before trying to extend the pin. When it is in error state I don't believe it will respond until it is reset. This could be an endless loop so there should be a limited number of retries before aborting the print.

[G-Forge]

@thinkyhead Can this be revisited if other BLTouch specific options are being added.
#3329

[thinkyhead]

@G-Forge Maybe. If a menu item is actually needed, we could add one. But since we can both (a) detect an ALARM condition and (b) automatically reset it, then we shouldn't need an option to manually reset it.

[GadgetNutt]

You can reset it assuming that the BLTouch is functioning correctly. If the pin is stuck, it will continue to return to a error condition. There should probably be a retry limit. At that point a manual reset may be required, perhaps even menus to manually extend and retract the pin to verify manually that it is working.

[Sniffle]

Just so it is known, this is copied directly from my octoprint output.

Send: M280 P0 S90
Recv: ok
Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: TRIGGERED
Recv: z_min: open
Recv: ok
[...]
Send: M280 P0 S10
Recv: ok
[...]
Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: TRIGGERED
Recv: z_min: open
Recv: ok

I know what the indiegogo says, and they may have modified it to be so, but
previous bltouch configurations do not act in the manner stated on the
indiegogo.

[GadgetNutt]

Actually, if the pin dropped and it went into error in the middle of a print, the ideal action would be to send a reset and a retract pin command to the BLTouch so that it would retract the pin, continuing the print rather than cancelling it.

[Grogyan]

If the probe is down in that error state (heaven forbid) and it is cleared, it could retrigger the alarm again if the clearance of probe to the bed isn't high enough to detect a proper alarm error state clearing

[GadgetNutt]

Resetting the BLTouch should retract the pin and clearance shouldn't be an issue. If it doesn't you have a much bigger problem and it will go into error again anyway.

[thinkyhead]

the pin can fall mid-print

Aha. So, not a bug. Let's make this a feature request then. Special handling for BLTouch.

[Grogyan]

@timeshell if this is a consistant issue, I suggest either/both adjusting the set screw so that the static magnetic field for the pin in the coil holds it firmly in place, or contact ANTCLABS about the issue.

@thinkyhead agree make it a Feature Request specifically for the BLTouch

[GadgetNutt]

Oh, now I understand what you're saying Grogyan. A reset should still fix that though as it retracts the pin.

[Grogyan]

@timeshell the BLTouch firmware should retract the pin on clearing the error.
The only time it wouldn't is as stated, the static magnetic field of the pin inside the coil is not strong enough to hold the pin in place. Adjusting the set screw should help, else contact ANTCLABS

[GadgetNutt]

Yes, the original issue has already been identified and dealt with with ANTCLABS. This issue appears to have moved into special handling of the BLTouch for electronic and mechanical error management.

[thinkyhead]

…if the clearance of probe to the bed isn't high enough…

Fortunately, since Marlin will (soon) know that it's dealing with a BLTouch, handling of the endstop triggering can be tailored a little for it.

For example, with ABORT_ON_ENDSTOP_HIT_FEATURE_ENABLED Marlin should double-check to make sure it's not just a screwy magnet by sending 160 to the BLTouch and re-testing the state.

And even without that option set, for BLTouch it should still send 160, at least once.

And perhaps, in the case of a BLTouch that can't be resolved, it could abort the print, print out "BLTouch error" and stop() to avoid running the probe pin into the print.

We already have flags for "ignore this endstop" – so endstops can already be logically enabled/disabled. For BLTouch it seems prudent to keep updating the Z_MIN state, regardless of the logical endstop state.

[jbrazio]

Fixed by #4336, if the issue still remains please open this issue again.

[GadgetNutt]

4336 is a partial implementation to what was discussed. This should remain open until all features are completed.

[jbrazio]

What features are missing ?

[GadgetNutt]

As far as I can tell, all the error handling logic discussed and special handling.

[thinkyhead]

#4839 adds basic handling of the BLTouch error state.

[GadgetNutt]

Incidentally, one of the reasons for the pin dropping appears to be an issue with poor connections between the connectors, especially on the brown/red/yellow wires. An intermittent connection, perhaps caused by wire movement could be at fault causing the BLTouch to go into error in the middle of a print. Being able to handle it in this case by resetting it and making sure the pin is up is very useful. Of course, the primary recommended course is going to be to make sure the wire connections are secure if you see this happening.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.