BLTOUCH Less is as good, superseded by a new PR because of the new BLTOUCH V3.1

[ghost]

I would like to reduce the unneeded BLTouch activity on G28 and G34.

bltouch.init will do:

SET_5V_MODE (if this is even enabled)
RESET
STOW
DEPLOY
STOW

What is really only needed is:

RESET
STOW

This resets a SW mode, resets an alarm state and reliably stows the pin. In the future, as a next step I will add a check to see if the pin is really stowed, to refuse movement and avoid damaging something.

The SET_5V_MODE is set once at startup and doesn't ever get reset. You can rely on it being there. Unless a user has purposely turned it off (probably for testing) and then he also probably wants it to stay off and then test a G28 (for example). A power cycle or Marlin restart gets this back to configuration.h state.

The DEPLOY-STOW added sequence is used after detecting the failure of a DEPLOY or STOW from G28, G29, G34. It isn't needed at the beginning of such a command.

[ghost]

In endstops.cpp at the end of the M119 sequence, the following code would be even more appropriate:

  #if ENABLED(BLTOUCH)
    bltouch._reset_SW_mode();
  #endif

instead of

  #if ENABLED(BLTOUCH)
    bltouch._stow();
  #endif

It means adding a public

FORCE_INLINE static void _reset_SW_mode() { if (triggered()) _stow(); else _deploy(); }

in bltouch.h

Then the actual stowed or deployed state of the BLTouch pin would be duly reported by M119 and after the report, the probe would not be unconditionally stowed - the pin state would stay as it was when the M119 was issued.

[InsanityAutomation]

For the moment I would suggest leaving things as they are for at least a little while to get some more feedback with the overkill safe option. I would say we would want this with a high speed toggle, and suggest it's used primarily on Delta machines, with the rest of that code as we had already discussed. I'd like to have a sort of line in the sand to know that we have clearly defined methods of making this work on every board before we start trimming things out for timing and efficiency. given the massive number of people who have run into problems and the relatively few and comparison who will even notice the slight timing delay from this I don't think holding it for a while is unreasonable.

[ghost]

@InsanityAutomation By all means, I concur

We tried hard to think of everything, but as you know, nothing is ever perfect, therefore:

This PR collects open points only discovered after the merge, so that they can be contemplated commit by commit.

The commit concerning M119 is actually a bug and not cosmetic and can cause the BLTouch to go into ALARM, as has happened on my printer when I was testing this today. Didn't cause any lasting problems, though, it recovered. Just unclean and low prio, just like the rest.

nuff said.

[InsanityAutomation]

Fun will be next week when we see what yet another new version brings to the table!

[ghost]

LOL BLTouch is a moving target, it seems. But there is no hurry and I am optimistic that this time nothing will break, they are sure to have learned that. I hope.

They are putting up some more information (that was one of my criticisms):

Look:

So there is actually a separate discrete FET there and it's not only the ATTINY 2313A specs pulling the signal down. If we knew the type, we could even determine the lowest value for the external pull-up that we recommend on some boards.

And:

We need to discuss this a little on discord, if possible. I'd like to bring back the timing table I had in bltouch.h. I don't see the "ubiquitous" 500ms as being the best idea.

They also sanction probing in SW mode:

I would want to bring that back as an option perhaps.

I wonder when they will "sanction" the real high speed mode ( that's my favorite 💯 ):

Step 1 : Push-pin Down(M280 P0 S10)
Step 2 .. N-1 : Probing again and again (keep M280 P0 S10)
Step N : Push-pin Up(M280 P0 S90)

I understand now, why the pin comes down again "by itself" when triggered and the STOW is not done: It is because the DEPLOY (or SW-MODE) servo signal is STILL active while the downward move is taking place. Gonna play with that a little too. You know we never ever turn off our servo signal after sending commands, so the last command sent "is left standing".

Honestly, I don't think there is or will be an acute need to further optimize all this BLTouch handling, it's working ok as it seems. But there is still some room for improvement, as can be seen.

[thinkyhead]

Fun will be next week when we see what yet another new version brings to the table!

We will have to use our inside connections to get early access!

[Roxy-3D]

We will have to use our inside connections to get early access!

If I'm reading Paris's email correctly... She has already sent 2 BL-Touch v3.1 probes to me. And probably the same to Bob-the-Kuhn. If somebody needs one to test against... We should be able to provide the support.

[InsanityAutomation]

Tracking says ill have a package Monday as well!

[Roxy-3D]

Hopefully it is the 'updated v3.0' with the little circuit board labeled v3.1

[InsanityAutomation]

Hopefully it is the 'updated v3.0' with the little circuit board labeled v3.1

That would be great! Dont need yet another V3.0 floating around....

[Roxy-3D]

Yeah... Actually... It has to be more than that. The reason is Antclabs posted a schematic showing they added a MOS-FET to add some muscle to the 'Open Drain' mode. Now, there is a serious MOS-FET (external to the processor) doing the 'Open Drain' part of the electronics.

[Roxy-3D]

@FanDjango Did Paris send you a couple of BL-Touch v3.1 probes? Hopefully the answer will turn out to be "Yes."

[ghost]

@FanDjango Did Paris send you a couple of BL-Touch v3.1 probes? Hopefully the answer will turn out to be "Yes."

I dunno - I don't get any tracking or anything. Just suddenly arrives - about 5 days later than you guys.

Do you really anticipate major changes? I would think this is a version that consolidates the stuff/fixes that has accumulated in the past couple of weeks. And a good idea to have them tested by Marliners.

Anyhow, still need to support the V3.0 ones (and V2.x and others etc.), so nothing fancy new can be exploited.

The reason is Antclabs posted a schematic showing they added a MOS-FET to add some muscle to the 'Open Drain' mode. Now, there is a serious MOS-FET (external to the processor) doing the 'Open Drain' part of the electronics.

Please note that this appeared on their website suddenly, like an afterthought., but it is valid already for V3.0 (after Apr 5). As well as the timing diagram. Maybe a reaction to my emails asking for more information, but once again, I dunno. Many others may have been deluging them also with requests for more information.

I have just "broken" a BLTouch, I hope ANTclabs will forgive me. I can repair it but I would need to unwind the solenoid, bring out some slack, rewind it and the solder on the connections. That's for a rainy day.

Here are some pics:

You can see a H-bridge to drive the solenoid/pin in two directions. You can also see a FET driving the LED - and incidentally this is also driving the white output cable (I measured that, you can't see the trace). So how does one get "Open-Drain" out of that? If the LED cathode is connected to 3.3V then it's "sort of an open-drain". How do they switch to 5V mode? I don't know really and I have no intention to "reverse-engineer" this thing in any more detail. They've been cloned often enough already and that's just plain unfair.

The point is that even with their little diagram, the electrical characteristics of the output stage are still unclear - that's no way to build avionics, but for the purpose of interfacing with a 3d-printer, its ok, I guess.

[ghost]

Shucks, I broke something, typo and merged myself into myself. Feeling slightly woozy now 👎

[tpruvot]

"git rebase -i " and use "s" (squash) instead of pick, then git push -f 2.0.x-BLTOUCH-0509

[ghost]

Later I will. Stupid Windows GitHub Desktop and remote VNC so slow...

[ghost]

So, got off the plane, back on a sensible system. Now a mouse click and an enter-key goes where I want it to. Rebased, squashed.

[ghost]

New status after testing the BLTouch V3.1 - there will be some more changes to reflect new stuff, so I am closing this PR and opening up a consolidated new one.