Marlin: Feature: BLTouch Special Handling

[timeshell]

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

[timeshell]

@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

[timeshell]

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

[timeshell]

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.

[timeshell]

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.

[timeshell]

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.

[timeshell]

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.

[timeshell]

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.

[timeshell]

Specs here:

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

[thinkyhead]

[timeshell]

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.

[timeshell]

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.
https://github.com/MarlinFirmware/Marlin/pull/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.

[timeshell]

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.

[Sniffle]

and yes @timeshell the probe will not respond until an error state is resolved.

On Wed, Jun 1, 2016 at 12:45 AM, timeshell [email protected] wrote:

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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/3902#issuecomment-222898393,
or mute the thread
https://github.com/notifications/unsubscribe/AAN4fkyprB5RyP9CSCW2eRxBauZ9tIJ8ks5qHRxhgaJpZM4IpMqg
.

[thinkyhead]

the probe will not respond until an error state is resolved

Is there any error state that will not respond to M280 P0 S160, or is this "guaranteed" to resolve it?

There should probably be a retry limit.

Indeed. I have tried to emphasize that above: "Keep trying to enable it a few times, and fail…"

[timeshell]

It will resolve it, but if the pin sticks it will go into error again once a command to drop the pin is sent and is unsuccessful.

[thinkyhead]

@timeshell So Marlin might be able to suggest the problem is: "BLTouch stuck pin!"

[Sniffle]

that is correct from my experience as well, if the pin is stuck, M280 P0 S160 will resolve any error always but it will reoccur if the error was not fixed

[timeshell]

I would say yes, that would be a safe assumption.

[thinkyhead]

…but it will reoccur if the error was not fixed

Good to know. Is there a noticeable delay before the "fixed" error goes back into ALARM (or TRIGGERED) state?

[Sniffle]

between a half second and full second after it attempts to move the pin to what should be its last known position

[thinkyhead]

I see. Assuming this is a "rare" occurrence, I think it's safe to toss in a 1s delay after M280 P0 S160 before continuing, and re-checking the condition.

Seems a good idea to try to move the pin back up and back down in the process too, in case the stuck pin can be dislodged.

[Sniffle]

I'm still having a hard time wrapping my head around how you are checking its condition. because as I've demonstrated above, it doesnt act the way the documentation on indiegogo says it does, and this cant be verified until someone gets one from teh current indiegogo campaign and tests to see that it does indeed do as they say it does

and yes it is a rare occurance, in 3 months of use, it has happened once, unless i forced it into an error state to test it

[timeshell]

@Sniffle are you sure it tries to return to last known position? I would think a reset would put it back into a closed/pin up position by default. That being said, I don't know for sure.

[thinkyhead]

@Sniffle Is that OctoPrint log showing the BLTouch output when it is in an ALARM condition? (And it's on the z_min plug, I assume.)

[timeshell]

Mine errors pretty regularly. I have the most current version as far as I know, they call it version C.

What steps did you do to produce that output? I'll go test right now.

[Sniffle]

@thinkyhead that is normal endstop reporting form normal operation. so at all times the endstop shows open. if you look at the documentation, there is a notation of 5ms and this is the pulse when the endstop is triggered.

@timeshell

M280 P0 S90
M119
M280 P0 S10
M119

[Sniffle]

so unless the magnet gets stuck in just the right spot to show endstop triggered, there is no way to know what state the bltouch is in

[thinkyhead]

@Sniffle It was my understanding, from previous comments, that if the BLTouch is in ALARM state, it will show as TRIGGERED, when it's not supposed to be (i.e., when not actually TRIGGERED).

[Sniffle]

give me a sec I'll go pull it down by hand and send it into an alarm state and do an M119

[thinkyhead]

unless the magnet gets stuck in just the right spot to show endstop triggered…

I see. But when it goes into ALARM state (not just stuck), does it also show as TRIGGERED?

[timeshell]

I'll check, just a sec.

[timeshell]

Yes it does show triggered when in error.

[thinkyhead]

Ok, so TRIGGERED is a signal for both ALARM state and MAYBE_STUCK state. But we can't test for a "stuck" probe. We can only know it is _either_ STUCK or ALARM.

[timeshell]

And when m280 p0 s160 is sent it resets pin to closed/up.

[timeshell]

If it is stuck it will go into alarm, so not really relevant.

[thinkyhead]

I see. So after 160 we need to send another 10.

[timeshell]

I think we should. Doesn't hurt even if it stays down. But so far my resets pulls the pin back up.

[Sniffle]

I can confirm, I just tested by hand that when in an alarm state that for me at least Z min was triggered

and now that makes sense for error checking,

[thinkyhead]

Ok. So I need to outline a procedure that we can "bolt onto" the current servo deploy/stow stuff in both homing and leveling, which after "servo deployment" takes a short pause, checks the state of the Z_MIN endstop, and if TRIGGERED, then goes into a routine to resolve the state. If the state can't be resolved, then we abort homing or leveling and stop() the printer, requiring M999 to reawaken.

[timeshell]

Ideally that should include checking the state at EVERY probe point along the way during auto levelling.

[Sniffle]

that sounds correct, I dont know that it would be useful for any other probe, so it could probably ifdefed to a bltouch specific probe safety define

[timeshell]

Interestingly, all this had nothing to do with the original report. :P

[Sniffle]

most likely that was due to servo deactivation delay being enabled because for normal servo probes its needed to prevent twitching... and twitches are power spikes that could have turned on the probe and makde it go through its startup routine

[thinkyhead]

Ideally that should include checking the state at EVERY probe point along the way during auto levelling

We have a flag now to stow the probe between points. With BLTOUCH I suppose it should just always enable that flag in probing.

[timeshell]

I wasn't using the deactivation features at all...

[Sniffle]

you may need to adjust your screw then, that controls the magnet strength if i remember correctly

[timeshell]

I thought about that. ANTCLABS is sending a new pin as they think the original pin may have a weak magnet.

[Sniffle]

thats a very possible cause as well

[timeshell]

Not following that stowing comment...

[thinkyhead]

Interestingly, all this had nothing to do with the original report. 😜

Productive, nonetheless. And through closer scrutiny the problem does appear to be something in the BLTouch itself, perhaps. But, if you use ENDSTOPS_ONLY_FOR_HOMING the trigger shouldn't bother Marlin or cause it to interrupt printing.

[timeshell]

Agreed

[thinkyhead]

Not following that stowing comment…

   * E/e By default G29 will engage the Z probe, test the bed, then disengage.
   *     Include "E" to engage/disengage the Z probe for each sample.
   *     There's no extra effect if you have a fixed Z probe.
   *     Usage: "G29 E" or "G29 e"

[timeshell]

I don't think I would change that action for the BLTouch, if I'm understanding it correctly. I think it runs the risk of false triggers if you change it. Again, still not sure I fully understand the applied action.

[thinkyhead]

change that action for the BLTouch

The effect of the E flag (for BLTOUCH) would be to send it a 90 _after_ every probed point, and send it a 10 _before_ every probed point. It sounds like it would be best to _always_ do it this way, so with BLTOUCH I propose that G29 E becomes the default, and an explicit G29 E0 would be required to do it the "usual" way.

[Sniffle]

if your going to check for every probe thats how it will have to be

it only adds an extra pin up/pin down motion that takes less than a second

[timeshell]

Don't you mean the inverse of that? 10 puts the pin down and 90 up. And yes, then I'd agree with that.

[Grogyan]

Back to the original post, I found that with my 2nd gen (the first gen of probes had known issues), slightly adjusting the set screw helps with uncerntities of states.
I often would like there to be a menu option to clear the error (M280 P0 S160), if and when it happens.

IF on the rare occasion during print the probe goes into an error state, sending a M280 P0 S160 will fix it.
Problem arises during the first few layers where the probe extended M280 P0 S10 is not high enough from the bed to avoid a retrigger, or worse catch on the print while we clear the error

[timeshell]

Why would you intentionally extend the probe in the middle of a print?

[thinkyhead]

@Grogyan Are you saying that the probe pin can accidentally fall down, and cause an ALARM (hence, TRIGGERED) state? In that case, either the (SD) print would abort (if ENDSTOPS_ONLY_FOR_HOMING is disabled) or we'd need to add extra code to detect the state and respond to it in a style befitting the BLTouch.

[timeshell]

That statement is correct. If not configured correctly, the pin can fall mid-print as was my original issue I reported. It should cause an alarm. I didn't know there was a way to stop the print automatically if that happened.

[Grogyan]

@timeshell If the probe is extended, for whatever the reason, clearing the error won't resolve ensuring that the probe is retracted.
I just simply stated that M280 P0 S10 is the code to extend the probe

@thinkyhead I've read on a couple of threads on G+ of where this has happened, because the set screw had not been set quite right for the static magnetic field to hold the probe up

[timeshell]

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

[timeshell]

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

[timeshell]

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

[timeshell]

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.

[timeshell]

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

[jbrazio]

What features are missing ?

[timeshell]

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.

[timeshell]

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.