Marlin: [BUG] BLTouch v3.0 not working properly with marlin homing

[paulpenney]

Description

BL Touch new 3.0 units not working with marlin on homing. Probe responds to M codes for deployment, stowing, and shows no errors, but when it comes to levelling the probe doesn't seem to properly communicate that the Z endstop has been reached. Tried on three different 3.0 probes out of a batch of 100. Tried on old and new marlin builds and machines with existing BL touch 2.1 units that function fine with the same results.

Steps to Reproduce

1. Install BL Touch 3.0
2. Self test is OK and no flashing lights or errors.
3. Start homing G28.

Expected behavior:

Probe should hit bed and be sucked up, triggering the Z endstop.

Actual behavior: [What actually happens]

Probe deploys properly and Z lowers to meet bed. The probe touches the bed and sucks up into the unit as expected and glows red, but the Z axis continues to move downward as if it didn't recognize the action.

Additional Information

This is on the latest build of marlin.
Others on reddit report similar behaviour.
Tested three new units out of an order of 100.
Here is the new DATASHEET for the 3.0 BL touch, which hasn't made it to Antclabs website yet.
This has been tested on machines that we know work with a BL touch 2.1. We home successfully with the 2.1, swap it for the 3.0 unit, homing fails, go back to 2.1 and its fine. That machine runs with marlin 1.1.9. Also tested on CR10S pro with InfinityAutomations firmware with the same results. No wiring connection issues.

Archive.zip

[InsanityAutomation]

Are you able to deploy the probe, run M43 W and tap the pin with a finger and see if the input pulses at all? Your orders are much bigger than mine! I thought I got alot when I got 5!! lol

[paulpenney]

Are you able to deploy the probe, run M43 W and tap the pin with a finger and see if the input pulses at all? Your orders are much bigger than mine! I thought I got alot when I got 5!! lol

Unfortunately I am not - Requires Pins Debugging and unfortunately on the ender there is zero room for any more code, literally bytes away from maximum capacity on the memory. I don't have another testbed on me currently. Still awaiting a solution from Paris in S. Korea.

We are a pretty big shop with service and can burn through in a few weeks or so - people love the BL touch! I install probably at least one or two a day at the shop.

Here is a video of the behaviour. https://drive.google.com/file/d/1zcYgOuyuHnCjl3d1abK5lXgTjrE1WS-d/view?usp=sharing Just to reiterate - it will report a Z triggered on an M280 P0 S60.

[InsanityAutomation]

So first thought is the sensor itself having swapped polarity on signal (black / white) lines. But the line "it will report a Z triggered on an M280 P0 S60." mostly rules that out. Next thought is pulse width. Id need to get one to hook up to my scope to see if thats different, and potentially shorter causing the endstop noise filtering to ignore it.

[paulpenney]

So first thought is the sensor itself having swapped polarity on signal (black / white) lines. But the line "it will report a Z triggered on an M280 P0 S60." mostly rules that out. Next thought is pulse width. Id need to get one to hook up to my scope to see if thats different, and potentially shorter causing the endstop noise filtering to ignore it.

Oh yeah the connections are fine - swapping in a 2.1 unit works perfectly, and we've tested four 3.0 units in a row now.

Paris did respond saying "After v2.2, because we use ceramic resonator, so we don't accept too large error than before." - Not sure what it means. I hope they didn't decrease the pulse width because it was already tiny at 5ms I believe. Also: On these tests, endstop noise filtering is not enabled.

Attached her is a better copy of the manual for the V3.0
BLTouchGuideV30.pdf

[ghost]

Seems to me there are some changes from V2.2 to V3.0:
V2.2 Servo Timing:

V3.0 Servo Timing:

Although at first glance it looks downward compatible, I would consider playing around with the M280 commands on the V3.0 to see if EACH one works as expected (except the S140 one).
Especially the 5V Logic ZMIN (option) position makes me a little suspicious - what the heck is it for? Anyway, it seems to me you can set "OpenDrain" or "5V Logic" with these two new positions, so maybe one would need a single M280 Px S150 before using the probe, but that is the default, shouldn't be needed. Still worth a try, maybe.

[ghost]

aris did respond saying "After v2.2, because we use ceramic resonator, so we don't accept too large error than before."

Sounds like they might be more exacting on the incoming PWM ratio that determines the servo angle. As they have moved to an external resonator for the MCU of the BLTouch, they don't need such a big leeway in detecting the desired angles setting - and that also gives them two additional new positions to use for two new "commands" (at 140° and at 150°.). If Marlin is slightly "off", something might go wrong.

[ghost]

In both the 2.2 and the 3.0 datasheets, they state the pulse witdh for detection is 10ms.

[paulpenney]

In both the 2.2 and the 3.0 datasheets, they state the pulse witdh for detection is 10ms.

Thanks for all your insights above. I agree that it appears (without a scope to confirm of course) that the two new commands are causing some difficulty - as if not issuing one of those commands after an M280 Px S10 command doesn't arm the unit for sensing.

Can someone explain to me exactly how marlin activates the BL touch for sensing during homing? Looking at the code there are five definitions for PWM positions:

#define BLTOUCH_DEPLOY 10
#define BLTOUCH_STOW 90
#define BLTOUCH_SELFTEST 120
#define BLTOUCH_RESET 160
#define _TEST_BLTOUCH(P) (READ(P##_PIN) != P##_ENDSTOP_INVERTING)

How and in what order does marlin use these in the sensing process? If the bl touch is deployed (10), does pushing it up automatically trigger an endstop event? And what is the purpose of Reset (160).

[ghost]

Actually, after giving this some more thought, this:

The probe touches the bed and sucks up into the unit as expected and glows red, but the Z axis continues to move downward as if it didn't recognize the action

points toward the probe actually performing its actions correctly. But it is the passing on of the touch-event to the controller board that is failing.

My thoughts: Configuration of pull-up action of the output stage in the probe is missing or insufficient. Even though it works for a 2.2 probe, maybe you don't have a pull-up strong enough (The probe is normal-state LOGIC-LOW according to the datasheet). You could actually measure (and compare to V2.2) with a multimeter in qiescent state.

And they explicitly state the following in the new datasheet, as if it were of dire importance:

#define ENDSTOPPULLUPS // BLTouch Smart V3.0 and Later #

From your description I would assume they have modified the output stage, therefore also the new commands to allow selecting the desired configuration and thus obviating the resistors or the little circuit board trace to cut when selecting 3.3V or 5V logic. Open-Drain works across all voltages, I suppose YOU should use the 5V Logic setting OR better, you should make sure you have actually activated your pull-ups on that input-pin. Which you have, according to your config files.

It's funny though: Why is (a little but further down) your
#define Z_MIN_PROBE_ENDSTOP_INVERTING false

whilst on my machine:

#define Z_MIN_PROBE_ENDSTOP_INVERTING true

Aha! Maybe. So on your machine the endstops are COM to ground, NC to input pin. On my machine, 'tis normal OPEN (normal closed is better I know but WTH, catch wiring faults that way). In that case maybe you should use the 5V logic setting of the probe instead of open-drain-default, (means you are missing the 140° init command) or consider changing #define Z_MIN_PROBE_ENDSTOP_INVERTING to true for the V3.0.

Worth a try?

[ghost]

Can you try a manual M280 Px S140 and then try a G28 Z? ?

[ghost]

But try the S10 and S90 first, to confirm you have the right "x"

[ghost]

I understand that perhaps the S140 setting might be needed EVERY time you deploy, but maybe it is kept in that state until next RESET or power cycle. Actually one should ask the ANTCLABS people all these things
It seems that you have contact with them, ask them to read this thread.

[paulpenney]

Tried all of the above, I definitely am addressing the right pin as M280 10 and 90 work great, and 60 returns a Z triggered when I look at the pinstates. I tried both S140 and S150 before homing but no luck, I am guessing its not programmed to save state. They responded to us on Sunday but we haven't heard back from them yet - I'll direct them to this thread!

In the mean time - If I needed to insert those commands just after deployment for Z probing, any idea where that line of code might be? I can just insert a bltouch_command(140) wherever that is, but its a matter of finding it.

[InsanityAutomation]

Especially the 5V Logic ZMIN (option) position makes me a little suspicious - what the heck is it for?

Originally they had a solder jumper for 5v or 3.3v logic. Seems they replaced that with the angle command to avoid damage due to people soldering in order to be more compatible with some 32bit boards that are 3.3v instead of 5v logic for inputs.

Big question now is how we can get a couple of these in developers hands to mess with for awhile. perhaps the support rep can confirm vendors in the US these have been sent to that I may be able to get one from? Worst case, maybe someone can bring one to MRRF?

[paulpenney]

Especially the 5V Logic ZMIN (option) position makes me a little suspicious - what the heck is it for?

Originally they had a solder jumper for 5v or 3.3v logic. Seems they replaced that with the angle command to avoid damage due to people soldering in order to be more compatible with some 32bit boards that are 3.3v instead of 5v logic for inputs.

Big question now is how we can get a couple of these in developers hands to mess with for awhile. perhaps the support rep can confirm vendors in the US these have been sent to that I may be able to get one from? Worst case, maybe someone can bring one to MRRF?

You may be able to get one from antclabs themsevles if they can't figure it out - try giving them an email at their gmail, the address is on the datasheet attached to a post above.

[Bob-the-Kuhn]

it will report a Z triggered on an M280 P0 S60

This means the hardware is hooked up correctly.

The video shows that the Marlin software is not detecting the pulse from the BLTouch.

Long shot - Sometime enabling ENDSTOP_INTERRUPTS_FEATURE is helpful.

---

The basic BLTouch probing and homing sequences are the same:

1. Deploy probe.
2. Endstop code samples the probe input. This phase will be aborted if probing and Z get too low.
3. When two consecutive active samples are detected the BLTouch is considered to have been activated.
4. The probe is then stowed and the Z stepper(s) are stopped.
5. Depending on the options selected, the Z axis may be re-positioned and steps 1-4 redone.

---

Is there US stock of the new BLTouch?

A quick look on Amazon didn't show anything claiming to be V3.0

Anyone willing to part with a V3.0? I can use PayPal to cover the cost & shipping.

[InsanityAutomation]

Just sent an email out. Ill update here what I get back. So far, it sounds like we need to initialize the collector on startup and reset based on the state of the endstup pullup, and potentially add a config option to override and menu button to resend. From there, testing on it processing signals correctly needs to be performed.

[InsanityAutomation]

Long shot - Sometime enabling ENDSTOP_INTERRUPTS_FEATURE is helpful.

One of the first things I tried unfortunately. No cheddar.

I'm not sure if US stock of BL touches, it appears we are basically at the release stage for them - at first I thought they were fakes, no reference on the website at all, but we're in touch with Paris and she says they are legit and redesigned.

Dont you love being patient zero? lol Pretty bad to get hit with that qty of them as well...

[paulpenney]

I'm just playing around here and hacking away at code, but I have some results that may offer some clues into the cause of the issues with 3.0:

In Marin_Main.cpp at line 3133 / 3171

#if HOMING_Z_WITH_PROBE && ENABLED(BLTOUCH)
// BLTOUCH needs to be deployed every time
if (axis == Z_AXIS && set_bltouch_deployed(true)) return;
bltouch_command(60);
#endif

If I manually add in a BL touch 60 command (Test) it will actually correctly sense the endstop properly, although it acts jankier because I am sure the code isn't supposed to work this way. But either way, it is putting the Bltouch in a state to report the endstop properly to marlin and indeed it gets sensed. If I change these values to 140 or 150 though, all that happens is the plunger gets sucked up, stays sucked up, and the Z axis keeps dropping.

[Bob-the-Kuhn]

I was the one who came up with the basic system in use today to reliably interface to the BLTouch. I'm very familiar with the low level hardware and software and I have the tools needed to see what the hardware is doing.

There a 90+% probability I can have a test image available within 6 hours of getting my hands on a unit.

Once I have code that works on a couple of different CPUs I'll do a PR so that people can grab a copy and try it. Once we get feedback from several people then we'll move the changes into the bugfix branches.

@Roxy-3D - do you still have the direct contact info?

@paulpenney - are you willing to part with one of your units? If yes please send it to:
Bob Kuhn
1034 Wisteria Trail
Austin, TX 78753
[phone]

I can use PayPal to send you $$ to cover your costs and/or return it to you..

[Bob-the-Kuhn]

From my experience with the V2.0 units:

• The 3.3V/5V option just selects what voltage the output pulse will be.
• You still need to supply 5V to the unit to have reliable operation.. Running the unit at 3.3V will result in unreliable operation.

[paulpenney]

Bob, I would try Paris @ [email protected] to see if she can ship you one, I'm sure that she has a lot of stake in getting this integrated with marlin as well considering that a lot of her customer base is people upgrading enders, CR10s, D9s and all the other marlin-based printers

[InsanityAutomation]

As a quick update, antclabs did not respond to my email as of yet however another distributor who got hit with the same bundle of new sensors and is seeing the same problem is getting one over to me. I'll have it hooked up as soon as it gets here and hopefully have something working this weekend that we can merge giving everything that we've seen here. The aim will be to keep them plug and play with something that does not cause an issue with 2.1, and I have a bunch of those to swap back and forth however I will add a configuration option if needed. Given that these are being sold as direct replacements, there may be some merit to a run-time option if needed however I really hesitate to do that and hopefully I can find a way around it.

[paulpenney]

As a quick update, antclabs did not respond to my email as of yet however another distributor who got hit with the same bundle of new sensors and is seeing the same problem is getting one over to me. I'll have it hooked up as soon as it gets here and hopefully have something working this weekend that we can merge giving everything that we've seen here. The aim will be to keep them plug and play with something that does not cause an issue with 2.1, and I have a bunch of those to swap back and forth however I will add a configuration option if needed. Given that these are being sold as direct replacements, there may be some merit to a run-time option if needed however I really hesitate to do that and hopefully I can find a way around it.

UPDATE: We got a positive response from Antclabs. The pin C7 capacitor leading to the Z endstop needs to be removed from the board with pliers. Doing this solved the problem, at least for the Enders. This is not the ideal solution though, as it permanently modifies the board, so we're hoping there is a software solution that will crop up.

[paulpenney]

Or maybe its a resistor. Anyways its the bigger yellow component.

[ghost]

Removing a C7 capacitor. Hmmm. If removing it should help, it very probably (but not totally necessarily) is between ground and the output signal as a slight noise filter. WITH this capacitor, a 10ms signal might have less distinct rising and falling edges, thereby reducing the timeperiod in which the signal is above the logic 1 threshhold. Perhaps the samples that Marlin takes are then too far apart?

[ghost]

This reminds me of #13128 where the OP solved his noise problem by putting a small cap across the signal and ground. Works on that machine, but who knows how small that cap may be. Now ANTClabs have put a cap (same value or more?) on by default (did they read that thread?) and that seems to be detrimental for "normal" Marlin machines.

[ghost]

Could you post the original text of their reply and also post a foto of the V.30 PCB with the C7?

[InsanityAutomation]

I can measure the component with my lcr-meter and put a scope on it before and after to see what it does to the pulse width. I should get the part here sometime tomorrow, but I'll do a little bit of logic testing to see what I can do with it un-modified first.

[InsanityAutomation]

just a quick rig up to my scope, didn't really set up any triggering and this is an ancient analog scope without logging anyway. Definitely seeing the curve on the pulse. Overall length appears to be the same however the slope on front is definitely cutting into the duration.

[Bob-the-Kuhn]

I still don't see the problem.

Looks like about a 2mS rise time. If it's still a 10mS pulse then we should have 8mS at logic 1 which is well above the 5mS Marlin is designed to catch.

Strange - the pulse height is only 2V. I would expect more. What happens if you put a 1K pullup on it?

[ghost]

If the unit is in "Open-Drain" Mode per default, shouldn't the configured pull-up of the input-port-pin "pull it up" further?
Alternatively, would a switch to 5V mode, via 140° servo make the situation better?

[InsanityAutomation]

Pull request is up! I dont have a 3.3v logic level board here to verify 100% with, but looks to work plug and play between versions now. Added menu items and everything.

[ghost]

So it actually was necessary to utilize the new BLTouch V3.0 mode commands. Sheesh, they sure risked it not working on a huge percentage of the printers out there (MARLIN pre todays bugfix vers), what got into them?

[juliandroid]

I've received BLTouch 3.0 yesterday, but I was expecting actually 2.2 (it wasn't published on the Antclabs site). However I saw that latest firmware 1.60.7 (Creality CR10S-Pro) is not stable - and it was mentioned on their official video as counterpart to their BLTouch kit for Creality printers.

Today, I've checked and they don't show 1.60.7 as downloadable version, but 1.60.71 instead. It is interesting to know whether they fixed the same issue or whether their stability issue was something else.

@InsanityAutomation Could you please confirm that this new commit should be enough to fix the issue with homing?

[Roxy-3D]

@paulpenney @FanDjango Can you give me your shipping addresses? Antclabs would like to send the people in this thread a Bl-Touch v3.0 to help insure their probe is well supported. @Bob-the-Kuhn (I already have your address!)

There are two easy ways to get me your address without posting it publicly here. You can join www.3dprintboard.com and send me a private message with it. Or... You can bring up Discord, join the Marlin server, and send me a private message there.

[ghost]

@Roxy-3D: I sent you a discord as requested

[paulpenney]

@Roxy-3D I sent you a PM on the 3d Printing Forum.. your name there is simply "Roxy"? Thanks again,

Paul

[Roxy-3D]

Thank You. I've sent everybody's address to Antclabs. I'm guessing it will take several weeks for the v3.0 Probes to arrive.

[CWSpear]

Dang... looks like I might be another "victim" of issues with BLTouch v3.0. As seen in the pic, that means I've got 3.0, yeah?

I bought it off Amazon: https://www.amazon.com/gp/product/B076PQG1FF

I am pretty sure my issues are the same as @paulpenney, but my observation was slightly different:

He wrote,

Probe deploys properly and Z lowers to meet bed. The probe touches the bed and sucks up into the unit as expected and glows red, but the Z axis continues to move downward as if it didn't recognize the action.

I would say that mine continues gets stowed (sucked up), but then redeploys ~half a second later and then stows again when it hits the surface. It's at _this_ point that it registers the Z endstop or whatever and stops going down. So it won't drill into the bed indefinitely. I can hold down the plunger as its testing and it will definitely stop. but it's like it takes half a second of it being unable to fully deploy for it to register.

[CWSpear]

This thread is a bit technical for me... is there a (temporary?) fix to get the v3.0 sensors to work correctly that someone could sum up?

[ghost]

@CWSpear: Official fix according to the vendor for now seems to be to remove a capacitor (see above). Not recommended, can damage the hardware and difficult to undo.
Next recommended possible fix: Use the newest bugfix-2.0 download to get the V3.0 support (add the needed config statements). This means downloading, modifying the configuration files accordingly and uploading to your printer. @InsanityAutomation has got this working and it wouldn't be committed if it weren't worth trying 🥇

Consider the new parms for the V3, as they stand currently:

/**
 * The BLTouch probe uses a Hall effect sensor and emulates a servo.
 */
//#define BLTOUCH
#if ENABLED(BLTOUCH)
  //#define BLTOUCH_DELAY 375   // (ms) Enable and increase if needed

  // BLTouch V3.0 and newer smart series
  //#define BLTOUCH_V3
  #if ENABLED(BLTOUCH_V3)
    //#define BLTOUCH_FORCE_5V_MODE
    //#define BLTOUCH_FORCE_OPEN_DRAIN_MODE
  #endif
#endif

You would want to activate the define for BLTOUCH_V3 and then for your case probably choose the BLTOUCH_FORCE_5V_MODE (or choose nothing, it should default to that in Marlin).

---

I am still trying to get a V3.0 here somewhere through normal channels (out of curiousity) but no chance. I still find it difficult to believe that the normal pre-BLTouch V3.0 Marlin does not work with the probe when pin-pull-ups are enabled. If it needs the new BLTouch V3.0 commit (which sets 5V mode instead of open-drain-mode), then as a next step I would like to see a schematic of the output stage (is it more than just the output pin of the ATTINY13A, what resistors and capacitors are on that output pin?). Can be measured but I can't find a V3.0 here, as I said.
It's sort of time to stop experimenting and to get down to some hard facts from ANTClabs. I know they need some secrecy because of the blatant cloning that they are experiencing but maybe just a small part of the details might help.
I myself am equipped with both 5V and 3.3V boards and V2.x BLTouches, they work fine with Marlin. Got some on order but who knows what version will arrive.

[CWSpear]

I have a CR-10 for what it's worth.

I installed the latest from the bugfix-2.0.x branch, and set up the BLTouch, uncommenting out BLTOUCH_FORCE_5V_MODE and BLTOUCH_V3.

It didn't seem to make a difference.

Also, as a side note, when I hit the different options in the new menu, I see stuff like,

echo:enqueueing "M280 P0 SBLTOUCH_5V_MODE"

in the serial monitor log, when I would expect

echo:enqueueing "M280 P0 S140"

Maybe something isn't getting converted correctly in the code? This is true for all the commands, like self-test, stow and deploy. I can execute the commands directly and they work as expected.

But I'm still seeing the delayed response, even if I send M280 P0 S140 to ensure it's in 5V mode.

[CWSpear]

Ok, scratch that. It does seem to be working when I do a G28 Z 🎉

Does still seem to be some kinks, such as the issues I listed above and it doesn't seem to want to take my Z offset into consideration, but maybe I'm doing something wrong (first time with 2.x firmware) (is G28 Z supposed to take into consideration Z offset? This is actually the first time I've really gotten this far).

[InsanityAutomation]

@CWSpear I just opened a pull request to fix the menus.

For a Creality machine, can try my pre-configured branch here - its caught up the the current changes and open PR's

https://github.com/InsanityAutomation/Marlin/tree/Creality_2.0_Devel

[Roxy-3D]

@paulpenney @FanDjango

I apologize! It turns out I also need to give Antclabs your phone numbers so they can fill out the Custom's forms.

[juliandroid]

@InsanityAutomation My printer is CR-10S Pro what is the easiest way to back port BLTouch 3.0 commits?
Currently Creatily offers only source code of V1.60.3 (Marlin1.1.6) : https://www.creality3d.cn/download/source-code_c0001

Any suggestions?

[InsanityAutomation]

@juliandroid Ill have a patch in the Tinymachines builds in the next couple days or so, and when its proven will be published as B6. Testing is in progress now :)

[Bl0wnp0ny]

@InsanityAutomation
looking forward to the tinymachines fix for my CR-10S Pro. I ordered my BLtouch on Amazon. I just installed it and spent a few hours tracing the wiring and troubleshooting. Finally found this thread not knowing there was a new version of the BLtouch. Sure enough I have V3.0. I feel like Antclabs did a terrible job on this rollout of new hardware. I'm down one machine on productivity.

[Kaisertron]

So I think this must be the same problem Im getting. Video here https://youtu.be/eAfLy4Y4R9M

[Bl0wnp0ny]

So I think this must be the same problem Im getting. Video here https://youtu.be/eAfLy4Y4R9M

yep. the sensor will say V3.0 on the side with the connector.

[Kaisertron]

Yep sure does. It's a version 3.0. Ordered off Amazon. Just for clarification the fix is listed above, correct?

[InsanityAutomation]

@Kaisertron grab the code from the open pull request. Should have a v3 running nicely.

[Kaisertron]

@InsanityAutomation ok sorry if I sound like an idiot I just need to flash the firmware in the current state on the page you listed or change setting for my Ender 3. Besides the obvious x and y probe offset.

[Bob-the-Kuhn]

I did some playing with a couple of the V3 units. As best I can tell the main differences between the V3 and V2 are:

• Open drain is the new default rather than a totem pole output (this was reported earlier by others)
• The output driver on V3 (after issuing S60 then S140 commands) is very weak compared to the V2.

I measured the following output voltages with a resistor to ground on two V3 units and a V2. The V3 was given S60 then S140 commands before taking the measurements.

 R      V3       V2
open   4.47V    3.95V
10K    0.96V    3.90V
1.2K   0.15V    3.59V

These numbers translate into an output impedance of about 30K on the V3 and 0.1K on the V2.

[Roxy-3D]

Wow! That concerns me. 30k ohms on a signal wire that is going be run next to stepper motor wires and heater wires makes me think it will be picking up electrical noise.

Bob, can you give us some 'typical' numbers? Do you know off the top of your head what TTL (7400) chips have as an output impedance? Looking at the AVR data sheet... It appears the AVR's are going to have between 20k and 50k ohms of output impedance (Rpu value):

So, maybe 30k ohms is OK?

[Bob-the-Kuhn]

30K is OK if there are no capacitors on the line.

Noise pickup on long lines is also a concern.

On the other hand it would be similar to a mega2560 & RAMPS with mechanical switches and no external pullup resistors. In that case the only pullup would be the Rpu. I don't know if that is a common system or if it has a reputation for false/missing triggers.

[Roxy-3D]

On the other hand it would be similar to a mega2560 & RAMPS with mechanical switches and no external pullup resistors. In that case the only pullup would be the Rpu. I don't know if that is a common system or if it has a reputation for false/missing triggers.

It used to be more common. But many RAMPS boards just had a switch from the signal pin to ground. And the pull up resistor inside the GPIO macro cell (or the processor) was used to provide power. It would be good for some of the old school types to jump in here and correct me if I'm wrong. But I think we used to see noise and had debounce logic in use for that case.

[Bob-the-Kuhn]

I see the following main categories of V3 uses:

• Inputs that have a 10K or stronger discrete pullup and no capacitors. RAMPS_FD_V1 is an example. V3 can be used right out of the box in this case.
• Inputs without external pullup or capacitors - Mitigations: Use V3 option in Marlin to enable the 30K pullup, enable the contoller chip's pullup via the Marlin option and/or add an external pullup resistor.
• Inputs with capacitors - rule of thumb calculations indicate that 0.1uF is the area where problems can start. Mitgations are the same as previous with leaning heavily toward external pullup resistor.

My recommendation for responding to people that are having problems with V3:

1. Enable the endstop pullup for the BLTouch's pin. This enables both the controller's and the BLTouch's weak pull up resistors.
2. If the above doesn't work then add an external pullup resistor. A 1K external pullup should be strong enough without imposing a large burden on the BLTouch or the power supply.

[Roxy-3D]

@Bob-the-Kuhn

Bob... The 30k ohm output impedance is only for the driving +5 volt side, right? The probe can sink a lot of current easily, right? Otherwise, adding a 1K ohm external pull up resistor would over power the probe, right?

[Bob-the-Kuhn]

Yes, the probe can sink a lot of current. The data sheet says max IO is 300mA. In my testing the output low voltage rose less than 10mV between no load and a 1K load (5mA) which means it hardly knew the 1K was present. I wouldn't worry even if someone used a 0.1K pullup.

There are no concerns with the low voltage portion of the BLTouch's output.

The problem is being able to provide enough current to charge the capacitance on the line up to about 2V in less than 5mS (10mS BLTouch pulse width minus 5mS Marlin guaranteed sense time). I'd be surprised if there were a system out there where just the cabling had enough stray capacitance to have problems when the Marlin endstop pullup option is enabled.

[Bl0wnp0ny]

@InsanityAutomation do I just need the new configuration.h file from your example configurations fo rmy CR-10S Pro. Sorry, I'm still pretty green with this stuff.

[Roxy-3D]

@Bob-the-Kuhn Thank you for the explanation!

So changing the direction of the discussion a little bit: If we turn on the pull up resistor on the signal pin for the BL-Touch probes..... Are we OK? I think that is what I'm hearing you say.

[Kaisertron]

We will have to use the new version from the pull and put the examples from the Creality file and apply our own settings. I just bought the older version BLtouch. This is a little outside our knowledge level and they dont have time to explain how to install for the dozens of different printers. This is more for development purposes than application to end user.

[Bob-the-Kuhn]

I found a schematic for the Ender 3 that was created by a user. It shows a 10K pullup to 5V with a 4.7uF capacitor. The time constant for that is 47mS which means it should get to 63% of 5V in 47mS.

All I could find on the Ender 3 CPU is that it's a 5V Atmel 8 bit CPU. Being very conservative, assume that the logic 1 transition is at 1.5V, it'll take 0.35 time constants or 16.5mS to go from zero volts to a logic one as seen by the CPU. If we assume the transition is at 2.5V then it'll take about 33mS. Add 1% for the pullup resistor tolerance and 20% for the capacitor tolerance and worst case might be in the 40mS range.

I'm thinking an external 1K pullup is the only thing that will guarantee Ender 3 and BLTouch V3 compatibility.

[Kaisertron]

If I get the older version in which I think I will I'm willing to ship my V3.0 out to one of you guys for development help

[Roxy-3D]

If I get the older version in which I think I will I'm willing to ship my V3.0 out to one of you guys for development help

@Kaisertron I can exchange your v3.0 for a new, never used v2.0 BL-Touch if you would like to do that.
(And if you would prefer an even older v1.x, new, never used BL-Touch, that can be done too...)

[Roxy-3D]

Are you on Discord? If so, we can exchange shipping addresses right now.
(It doesn't look like you are using Discord. You can create an account at www.3dprintboard.com and send me a message there with your address. And I'll reply and send you my address.)

[Roxy-3D]

@Kaisertron That name (jvkaiser) isn't showing up as available for messages at 3dprintboard ???

[Roxy-3D]

Hmmmm.... I can find the post you just made with the 'jvkaiser' name.... But I can't find a user with that name.

[Bob-the-Kuhn]

Here's one idea to add the external pullup.

Steps:

1. Keep the wire cable installed. It helps keep the pins from moving if the connector gets hot.
2. Pre-form the 1/8W 1K resistor
3. Pre-tin the resistor and the connector
4. Using a tweezers to hold the resistor, tack the resistor lead to the white wire contact.
5. Use the tweezer to bend the othe lead into the final position.
6. Solder the resistor to the red wire's contact.
7. Re-solder the white wire contact.
8. Clip the excess resistor wire.
9. Apply thick super glue to the resistor. Do not put the glue on the connector or you may end up glueing the two mating parts together.

Yes, I know the picture has a 10K in it but I couldn't find my 1K 1/8W resistors.

[paulpenney]

@InsanityAutomation - Thanks for all your help so far. I am having some issues with customers and the CR10S pro with the 3.0. Can you confirm or deny that your firmware is updated to resolve these issues as of now? Is there anything else the user has to do besides uncomment the machine and ALB Bl touch?

[ghost]

@Bob-the-Kuhn : On my GT2560, it is as you say:

On the other hand it would be similar to a mega2560 & RAMPS with mechanical switches and no external pullup resistors. In that case the only pullup would be the Rpu.

Just the Rpu. And yes, there is a danger of noise on a bunched up cable to the extruder, I can confirm.

On my MKS SBASE, things are more complicated (3.3V):

I need to find out the values of the components on the GPIO input and will post them here. But: These are part of an effort to make the input pin 5V tolerant, which is really not needed, this MPU already has got internally 5V tolerant input pins on this specific port. I will test the BLTouch V3.0 on this board when it arrives.

---

It would seem consensus is nearly reached:

ANTClabs statement is that removing that one single capactor should solve the problem (see far far above). Not really desirable, I know, but that capacitor probably should be added in to your rise-time estimates.

If (as confirmed) in the default open-drain mode with just the Rpu active, the V3.0 won't work, and ANTCLABS speak of removing the capacitor, the problem this addresses is the rise-time. Then the ONLY good solution would be to add a pull-up (as you suggested. Easier to add something (a pullup) than to remove something (the capacitor) especially as a lower pull-up impedance and a capacitor will subdue noise more effectively, which is definetly a problem (one such issue was actually mentioned further up).

[InsanityAutomation]

@paulpenny I added the code to the source section, but one user reported it still wasn't working. Made a bracket earlier today and I plan to hook it up and see what's going on with that board either today or tomorrow.

[paulpenney]

@InsanityAutomation Thanks so much! We're big fans of your firmware and any issues our customers have with the 10SP seem to be solved with it. Until now of course ;)

[InsanityAutomation]

@paulpenny - thank tinymachines for donating a development machine! As soon as they saw how bad it was stock he got one to me so I could figure it out! The Marlin 2.0 port is progressing. It's not done, but far enough to at least show at mrrf.

[darkone88]

Ended up here after having issues installing new Bltouch and discovered I got the V3.0 from the same amazon link above that CWspear posted. I have an ender 3 would it be possible if someone posted the new marlin 2.0 profile set up for that?

[Bob-the-Kuhn]

Here's another idea on adding an external 1K pull up resistor. Definitely easier to do.

V3 cable mod.docx

[Bl0wnp0ny]

@Bob-the-Kuhn would just adding this resistor solve the V3.0 issues without needing to update the firmware(besides uncommenting it)?

[gloomyandy]

Folks just some more data points for you. The MKS Sbase and Bigtreetech SKR V1.1 (and probably V1.3) both have similar input circuits (see the schematic posted above by @FanDjango). On the SKR schematic the values are:
R41: 10K (pullup to 3.3V)
R44: 1K (inline with input)
C34: 0.1uF (between ground and the pullup)
On the Sbase schematic these seem to be:
R41: 1K (pullup to 3.3V)
R44: 5.6K (inline with input)
C34: 0.1uF (btween ground and the pullup)

Will the external pullup work for both of these?

[Roxy-3D]

If Antclabs is saying the problem can be fixed by removing that capacitor on the BL-Touch probe... Does this mean they will start shipping without that capacitor?

[Bl0wnp0ny]

@Roxy-3D that would be an easy fix but has anyone confirmed it? I don't want to clip mine and find out I trashed my bltouch.

[kAdonis]

@Roxy-3D
Afaik, antclabs was referring to the C7 capacitor on the Ender 3 mainboard not a capacitor on the BLTouch

[Bl0wnp0ny]

That's what I heard as well.

[Roxy-3D]

Thank You for the clarification!!!

[Bob-the-Kuhn]

I believe that adding the 1K external pullup will make the V3.0 act the same as previous BLTouch versions.

[Bob-the-Kuhn]

@gloomyandy - I'm pretty sure that neither of these need the 1K external pullup. The V3.0 should work with or without the software mods.

[Ragaroah]

I'd just like to mention that I ran into the same issue with the new BLTouch v3.0. G28 would crash into the bed, G29 would skip points or not finish the leveling.

Switching to the new Marlin 2.0.x bugfix version solved my issue. Thanks!

[RmnX1]

Upgrading my CR-10S Pro with the BLTouch v3.0 and the InsanityAutomation Creality_DWINTest firmware drove me a little crazy on weekend. After several crashes with creepy sounds of the motors, I found this Bug-Report. The workaround with the 1k resistor doesn’t work for me.

I also found this CR10SP mod https://www.reddit.com/r/CR10/comments/aq6fi9/finally_cr10spro_with_bltouch_without_that_stupid/ by 33cl. He uses different PINs than in the the 3D Printing Canada Video do. For initial tests I used 33cl’s firmware and the BLTouch works without any problems. On G28 the probe deploys and the motors stop on contact.

After comparing the BLTouch related parts in the two firmwares I modifyed the Creality_DWINTest firmware with code from 33cl's and it seems to work. I'm not happy with the actual levelling results but thats a whole different problem.

Marlin.zip

[gtorige]

I second @Ragaroah comment. Installed Marlin 2.0.x bugfix and now the BLTouch v3.0 is working great on my Ender 3-S.

Thanks for all the efforts!

[Bob-the-Kuhn]

@gtorige - just to confirm - the V3 works on the Ender 3 with Marlin 2.0.x bugfix and no other changes?

If yes then that's VERY good news for the community. That means the addition of an external resistor is not needed by anyone!

I don't understand but I'm glad to be wrong in this case.

[Ragaroah]

Indeed @Bob-the-Kuhn, no issues now. I'm able to run G29 and G28 without any problems on my Ender 3 Pro.

[gtorige]

@Bob-the-Kuhn correct. Ender 3 with Marlin 2.0.x bugfix and BLTouch V3.0. No resistor added

I just did the standard changes on Configuration.h and Configuration_adv.h to enable BLTouch like uncommenting the #defines for BLTouch, adding the #define SERVO0_PIN 27, adjust offsets and disable speaker, SD Card, slim LCD, etc... In Configuration_adv I've enabled babysteps and disabled ARC.

Just basic changes. If there's something I should try to help the community feel free to ask

Edit: my board is the Melzi by Creality v1.1.4

[jacobwtyler]

@Bob-the Kuhn Would it be okay to use a 1/4W 1K resistor. That’s all they have at Altex...

[kuksinsky]

Has anyone solved this bug for the CR-10S PRO?

[InsanityAutomation]

@kuksinsky I have the code that should work in the DwinTest branch in my fork, however reports indicate its still having issues. I planned to hook it up on that machine this weekend but ran out of time. I may get to it tonight.

[Bob-the-Kuhn]

@jacobwtyler - the wattage isn't important. The 1/8W was thinner leads which is easier to use.

Have you tried the latest Marlin 2.0.x code? Reports are coming back that the new code is all that was needed for the Creality Ender 3 which we think is the worst case.

It's looking like an external pullup is not needed.

[Bl0wnp0ny]

Upgrading my CR-10S Pro with the BLTouch v3.0 and the InsanityAutomation Creality_DWINTest firmware drove me a little crazy on weekend. After several crashes with creepy sounds of the motors, I found this Bug-Report. The workaround with the 1k resistor doesn’t work for me.

I also found this CR10SP mod https://www.reddit.com/r/CR10/comments/aq6fi9/finally_cr10spro_with_bltouch_without_that_stupid/ by 33cl. He uses different PINs than in the the 3D Printing Canada Video do. For initial tests I used 33cl’s firmware and the BLTouch works without any problems. On G28 the probe deploys and the motors stop on contact.

After comparing the BLTouch related parts in the two firmwares I modifyed the Creality_DWINTest firmware with code from 33cl's and it seems to work. I'm not happy with the actual levelling results but thats a whole different problem.

Marlin.zip
@RmnX1 I tried your firmware on my cr-10s pro and it didn't seem to work. when i go to the levelling menu, the x and y home and the bltouch sensor comes out and goes back in and stops.

[RmnX1]

@ RmnX1 I tried your firmware on my cr-10s pro and it didn't seem to work. when i go to the levelling menu, the x and y home and the bltouch sensor comes out and goes back in and stops

@Bl0wnp0ny Have you wired the BLTouch as described in 33cls howto?
Brown -> A10G
Red -> A10V
White -> D12S
Yellow -> D11S
Black -> nc

Homeing and leveling work for me, but the leveling results vary greatly. Also, the adhesion is very bad despite correcting Z offset during print. :/

[Bl0wnp0ny]

good call. i forgot to move my white wire. So black doesn't get connected?
is your leveling results related or something different?
Are you still on the original build surface? I found wiping the bed at temp with a damp towel works very well.

[Bl0wnp0ny]

@RmnX1 just rewired and no go. going to try uploading your firmware again.

[RmnX1]

@Bl0wnp0ny Right. The black doesn't get connected
I did three levelings in a row after a print. The last two are very close together
https://nxc.oliver-assmus.de/index.php/s/SzZ3Xd8WEc3ECy9

I'm using the original surface and clean it with isopropanol before printing. The printer is just one week old and it's my first one, so it's all really new to me. Till now it's also more try and error for learning. But I think that the stock 1.60.3 firmware with the capacitive probe got better printing results instantly after unboxing.

I can check my cabeling and flash my firmware again. Maybe I forgot something to mention...

Okay...here's my cabling https://nxc.oliver-assmus.de/index.php/s/SzZ3Xd8WEc3ECy9#//IMG_3202.JPG

Don't be surprised about the cable colours. I used a network cable to expand the BLTouch cable. On the picture
green (BL red) --> A10V
brown (BL brown) --> A10G
white/blue (BL white) --> D12S
orange (BL yellow) --> D11S
blue (BL black) --> not connected

I also flashed my firmware mod again and did a "offline test" only USB connected with manually moves of x and y to the stop.

G28 x
SENDING:G28 X
[...]
ok P15 B3
G28 y
SENDING:G28 Y
[...]
ok P15 B3
G28 z
SENDING:G28
[...]
ok P15 B3

A few seconds after G28 Z the probe deployed, I touched it. A few seconds later it deployed again, I touched it again and got the ok.

Maybe you can flash the firmware from 33cl and do some tests with Printrun.

[Bl0wnp0ny]

interesting that the last 2 are very close together. Was the bed cooling off while leveling?
let me know if you find anything. i have the red, brown, and orange wires wired up like the original bltouch, the black wire is clipped with no connection and the white wire is connected next to the orange jumper.

[RmnX1]

No. The bed temperature was permanently set to 70°C (because it's the temperature inside of the heating and the delta to the surface is 10°C at my setup). The first measuring was after moving all axes. The second directly after the first, and the third directly after the second. I'll keep testing and learning.

[jacobwtyler]

@Bob-the-Kuhn I got the printer (actually a CR10) working with the 1/4W pull-up but I haven’t tried the v2.0 firmware fix yet. Seems to be some inconsistency in the mesh bed leveling so I think I’m going to try the software fix and clip off the pull up. Would it make any sense to do this? Seems like there is still a slight delay between when the probe touches the bed and when it retracts.

[Bob-the-Kuhn]

Yes, removing the resistor makes sense. So far everyone has said the new marlin code is all that was needed.

The pulling up of the probe is solely under control of the BLTouch. It'll come back down unless Marlin issues a stow command.

[juliandroid]

@kuksinsky I have 10S Pro, but I'm still hesitant to disassemble current capacitive sensor and replace it with BLTouch V3.0 since I don't have a base that is working and I wouldn't know what is the problem if something goes wrong.

Once @InsanityAutomation gives a green light with particular pair of Mainboard+LCD firmware to flash I can try upgrading that.

Some people reported poor sensing, but there is another difference between BLTouch 2.2 and 3.0 - the recommended distance between the sensor and the bed is now 4mm +/- 0.3mm, so old mount adapters are no longer optimal.

[Bl0wnp0ny]

tempted to go back to the stock sensor until this is figured out. i already cut the capacive sensor's connector off to wire up the bltouch so i'll have to solder it back on. At least it was decently usable. My printer has been idle for almost 2 weeks now.

[Bl0wnp0ny]

@RmnX1 do I need to uncomment #define BLTOUCH_FORCE_5V_MODE in your modified firmware?

[Bl0wnp0ny]

nvm that didn't seem to work either.

[StreckerCM]

My BL Touch has been a paper weight since I got it. Lucky I saw this bug before I started installing it!

Hope @InsanityAutomation can come up with an awesome solution since Antclabs has been no help!

[ghost]

@StreckerCM

My BL Touch has been a paper weight since I got it. Lucky I saw this bug before I started installing it!
Hope @InsanityAutomation can come up with an awesome solution since Antclabs has been no help!

Current bugfix-2.0.x contains pull-commits by @InsanityAutomation to support the BLTouch V3.0.

Note that there are printer types out there that

a. will work unchanged
b. will work if a 1K pullup is connected to the signal line and +5V
c. will work if the newest Marlin bugfix-2.0.x is flashed, configuration is modified, no 1K pullup needed

and maybe some more - like "doesn't work yet".

So what is your printer?

[StreckerCM]

@FanDjango it is a CR10S Pro

[ghost]

@Bob-the-Kuhn
Something I would like to run by you:
In open-drain mode (the default), the V3.0 BLTouch should be acting like a normal-closed microswitch SIGNAL to GND.
Take any printer that can handle such a microswitch as a probe, for example the ones mounted on a servo. If that printer is configured to work with that switch, it should work with the BLTouch in open-drain mode as well, were it not for the output only being a pulse - a real switch closes "a long time". Sadly, due to capacitances and pull-ups being widely different on various printers, the effective length of the pulse varies greatly.
Shouldn't we try configuring the input pin in the same way as if we had connected a normal micro-switch and because of the pulse nature of the signal, make sure this pin is interrupt-capable and turn on the interrupt?
I suppose that since not all scenarios have got interrupt capable probe pins, one must alternatively resort to sampling the pin - but then the sample rate must be made significantly higher than it is now.
The current solution to use 5V mode or a 1K pullup just make the pulse width at the MCU longer, which kind of proves that point.
So in my mind the best solution would be to use the BLTouch in the default mode and make sure we don't miss the short pulse.
It is also interesting to note that ANTClabs actually comment on not needing or wanting the capacitors so prevalent on many printers boards, (rightly) claiming that it lowers accuracy (although it might be needed in noisy environments):

(this is from their website)

[estrelaj]

Hello Everyone,
I've been following this thread closely and I would like to add that I purchased 2 BLTOUCH V3's recently and installed them on a FLSUN C Plus machine with a MKS Gen L v1.0 board running 1.1.9 with no issue, started working right away with no modifications to the software (with the exception of enabling BLTOUCH) or hardware. I also installed it on a Zonestar P802NR2 running a ZRIB V2.1 board (2560 chip) (I know that this printer was never meant to have a BLTOUCH but I like to print on glass and the inductive sensor wasn't cutting it), wouldn't work under 1.1.8 or 1.1.9. But after a long reconfiguring and pin remapping (using X+ for the servo pin) and using Marlin 2.0 with the BLTOUCH_FORCE_5V_MODE and OPEN DRAIN MODE, it is working great now, the only major thing is to use the new 4.3mm distance instead of the 3.3mm offset. Works like a charm now, thanks to everyone involved in providing the fix.

Jeff

[Bob-the-Kuhn]

@FanDjango - the input pin configuration for a BLTouch IS the same as for a NC mechanical switch.

The difference used to be in how fast it was sampled. Currently all types of endstops are sampled at the same rate - no more than 2mS apart. Two consecutive active samples are needed to declare an endstop active.

What the interrupt mode does is start the sampling sooner. After that it's every 2mS max.

Marlin is designed to catch the 5mS pulse of the original BLTouch. It takes quite a big capacitor to shorten the V2's and V3's 10mS pulse to under 5mS.

I'm doubious of the accuracy claim. It's repeatability that matters most. As long as the homing speed doesn't change then the home position of the head will stay the same.

[RmnX1]

After some tests with the @InsanityAutomation firmware and the 33cl's firmware and cabeling for the CR-10S Pro, my BLTouch v3.0 works in general with Z_MIN_PROBE_ENDSTOP instead of Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN. The probe works how expected (deployment, stowing and triggering), also the homing. Despite many times in manual leveling and preparation, the auto-leveling results are very unsatisfying. My prints will start with a default Z-Offset of -0.9 up to -1.0 but the adhesion is always very bad and differs much on different bed positions. With 33cl's firmware it's a little better than with InsanityAutomation

@Bl0wnp0ny I took 33cl's firmware as reference and there is no #define BLTOUCH_FORCE_5V_MODE. So I commented it and also modified other references. For me it works. After new changes, I always test them with an unpowered printer, only the board connected via USB and send G-Codes on serial monitor. Only if I'm sure that the printer won't destroy itself, I do tests with power on. Thats are my lessons learned from the first tries ;-)

I'm not very familiar with 3D printing and Marlin yet and unfortunately I do not have much time to test currently. But the configuration gives incredible many options for optimization. It makes a lot of fun to me!

[Yellow06TJ]

Hi Jeff,
I saw your email earlier and have a couple of questions.  I too just purchased a BLTouch v3 (timing is everything).  I'm planning to install it in a Tevo Tornado which has the MKS Gen L v1.0 board.  Based on your experiance it looks like I should not have any issues.  The one question I have is, you mention the change in the offset from 3.3mm to 4.3mm.  Is this within the software or physically with the mount? 

Sincerely,Brian [email protected][phone]

On Wednesday, March 27, 2019, 10:22:07 AM CDT, estrelaj <[email protected]> wrote:

Hello Everyone,
I've been following this thread closely and I would like to add that I purchased 2 BLTOUCH V3's recently and installed them on a FLSUN C Plus machine with a MKS Gen L v1.0 board running 1.1.9 with no issue, started working right away with no modifications to the software (with the exception of enabling BLTOUCH) or hardware. I also installed it on a Zonestar P802NR2 running a ZRIB V2.1 board (2560 chip) (I know that this printer was never meant to have a BLTOUCH but I like to print on glass and the inductive sensor wasn't cutting it), wouldn't work under 1.1.8 or 1.1.9. But after a long reconfiguring and pin remapping (using X+ for the servo pin) and using Marlin 2.0 with the BLTOUCH_FORCE_5V_MODE and OPEN DRAIN MODE, it is working great now, the only major thing is to use the new 4.3mm distance instead of the 3.3mm offset. Works like a charm now, thanks to everyone involved in providing the fix.

Jeff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[estrelaj]

Hey Brian,

I was referring to the mounting position,  the offset from the nozzle to the tip of the BL.   You also need to set the Z Probe offset in the software too. 

Jeff

[Yellow06TJ]

Jeff,
Thanks for the quick reply.  I have enough variability in the mount that I can account for the extra 1mm of offset.  The springs should be able to soak that up.  Was there anything else that you had to do differently with the Gen L board?  If not I'm going to start the upgrade!

Sincerely,Brian [email protected][phone]

On Thursday, March 28, 2019, 12:12:23 AM CDT, estrelaj <[email protected]> wrote:

Hey Brian,

I was referring to the mounting position,  the offset from the nozzle to the tip of the BL.   You also need to set the Z Probe offset in the software too. 

Jeff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[estrelaj]

Not really, just make sure you're on 1.1.9 or higher of Marlin

[100ccmREFO]

Hello everyone

I got the BLTouch V 3.0 working on my Ender-5 !! I updated to Marlin 2.0.x bugfix and defined bltouch AND IMPORTANT: define BLTOUCH_V3 ! With these two settings done and of course all the other settings you would do on Marlin 1.1.x, my BLTouch worked perfectly !
Thanks to everyone :)

[GilLarose]

Paul with my CR 10S pro if I upload the bug fix for BLTouch 3 will it fix the problem........... I also changed Z_MIN_PROBE_ENDSTOP instead of Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN but no luck still does not work...... very frustrating having a new probe and cannot use it.

[kuksinsky]

Paul with my CR 10S pro if I upload the bug fix for BLTouch 3 will it fix the problem........... I also changed Z_MIN_PROBE_ENDSTOP instead of Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN but no luck still does not work...... very frustrating having a new probe and cannot use it.

What pins did you connect it to? It is possible that the bltouch v2 connection scheme is not suitable for the third version.

[reloxx13]

reference
PR https://github.com/MarlinFirmware/Marlin/pull/13406
PR https://github.com/MarlinFirmware/Marlin/pull/13454
PR https://github.com/MarlinFirmware/Marlin/pull/13495

[ghost]

Been doing some testing here with BLTouch V3.0

On my MKS SBASE V1.3 it is a drop-in replacement for the previous BLTouch probe, no problems. Needed to change the Z-Offset though, so on the mechanical side it is maybe not a drop in replacement after all, but this is documented in their datasheet.

I would like to sum up some of the previous posts:

Thanks to the efforts of @InsanityAutomation and @Bob-the-Kuhn there are hardware and software solutions to the BLTouch V3 problems:

YOU ARE LUCKY; YOU DONT NEED TO FLASH NEW FIRMWARE and DONT NEED TO SOLDER A 1K PULLUP, if...
...your printers controller board has given the designated input pin enough pull-up (either because the processor involved has got "good enough" pull-ups internally and you have set the pull-ups to be active, or because they have added external pull-ups on the board), the BLTouch V3.0 will work just like the previous ones. NO NEED TO FLASH a the new Marlin firmware with the BLTouch V3.0 support in this case, and even if you do, no real need to #DEFINE the BLTOUCH as V3, but I would recommend it. If you are in doubt, why not post your printer/controller board here and let's check the schematics to see what's all connected on that pin and what the chances are.

Otherwise, if you...
DONT WANT TO FLASH A NEW FIRMWARE...
...chances are close to 100% that soldering a 1K resistor between the white (PROBE SIGNAL) and the red (5V) wires of the probe will get it working. The wattage and the physical size of the 1K resistor is secondary, but the smaller the better for fitting it in somewhere (see above - posts by @Bob-the-Kuhn and further down by @StreckerCM).

Otherwise, if you...
DONT WANT TO SOLDER ANYTHING
...chances are close to 100% that using the new Marlin firmware or if you need special versions (a special fork) for your printer, using a newly updated version of that fork which contain the recently made changes for the BLTouch V3.0 will get it working. In this case, you need to then use the correct definitions in the BLTouch section of configuration.h and then flash the new firmware (see above, but also check the github commit history).

Otherwise ...
TOUGH LUCK?
(meaning the BLTouch V3.0 does not work for you as is, you don't wan't to add a 1K pullup and you don't wan't to flash a new firmware) ... all is not lost. If this is an idividual case, you could offer to swap with someone that is willing to give you his previous version of the BLTouch in exchange. Maybe you could ask in here?

[GilLarose]

Paul with my CR 10S pro if I upload the bug fix for BLTouch 3 will it fix the problem........... I also changed Z_MIN_PROBE_ENDSTOP instead of Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN but no luck still does not work...... very frustrating having a new probe and cannot use it.

What pins did you connect it to? It is possible that the bltouch v2 connection scheme is not suitable for the third version.

Hello Kuksinsky
Ive connected the pins exactly like Jason at 3D Printing Canada shows on there Youtube channel https://www.youtube.com/watch?v=PLKEhdznVMY
so
(bottom left (S)ignal) rowD11 (Orange wire), then (top middle (G)round) row A10 (Brown wire) and finally top right (V)olt row A10 (Red wire)

[GilLarose]

Paul with my CR 10S pro if I upload the bug fix for BLTouch 3 will it fix the problem........... I also changed Z_MIN_PROBE_ENDSTOP instead of Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN but no luck still does not work...... very frustrating having a new probe and cannot use it.

What pins did you connect it to? It is possible that the bltouch v2 connection scheme is not suitable for the third version.

Here are some pictures of the pins I use on my Cr10S pro

Ive connected the pins exactly like Jason at Canada 3D printing shows on there Youtube channel https://www.youtube.com/watch?v=PLKEhdznVMY
so
(bottom left (S)ignal) rowD11 (Orange wire), the (top middle (G)round) row A10 (Brown wire) and finally top right (V)olt row A10 (Red wire)

[caseyjmorton]

Can we back port this fix to the 1.1-Bugfix branch? It would be nice to have this in a production-worthy release sooner rather than later. I would draft the PR myself but I don’t feel comfortable enough with the marlin codebase and development processes to know if this is more than just a straight up cherry-pick or what.

[GilLarose]

anybody can help me solve this problem with my Cr10S pro....... and BLTouch 3.0
please let me know if you have the same printer and got it to work......
sincerely GilLarose

[mister2212]

I have an anycubic i3 mega with trigorilla board and the same problem with the bltouch v3. I can control it but when i start g29 the bltouch doesnt trigger and the nozzle hits the bed.

[caseyjmorton]

I just finished working through this issue on an Ender 3. I resolved it by
pulling down the latest 2.0-Bugfix build from the website and then enabling
BLTOUCH_V3 and all of the associated options.

On Fri, Mar 29, 2019 at 2:35 PM mister2212 [e-mail] wrote:

I have an anycubic i3 mega with trigorilla board and the same problem with
the bltouch v3. I can control it but when i start g29 the bltouch doesnt
trigger and the nozzle hits the bed.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-478105357,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABg6FkvTzfHTJFEkzLMnR8XkhqBvnMT-ks5vblzagaJpZM4bmrEd
.

[Kaisertron]

@caseyjmorton do you mind sending me a copy of your configuration.h file and back end advanced

[caseyjmorton]

Not at all. I’ll send it a little later tonight once I get home. Keep in
mind that you will need to customize the probe offsets. I am using the Hero
Me gen 2 hotend duct/mount, which I highly recommend. I’ll post a like to
the files for it on thingiverse if you are interested.

On Fri, Mar 29, 2019 at 8:40 PM Kaisertron [e-mail] wrote:

@caseyjmorton https://github.com/caseyjmorton do you mind sending me a
copy of your configuration.h file and backend file

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-478189024,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABg6FnQmDEt0AVe9XLoZXxTYSGVpr8ikks5vbrKGgaJpZM4bmrEd
.

[Kaisertron]

@caseyjmorton that sounds great a lot of users use the Creality Ender 3 and CR 10 so I think it would be very beneficial for them to have an easy drop file and over right ability. This would help clear up most of the clutter on users finding this thread.

[caseyjmorton]

Yeah you are right. It may be best to host the configuration files on a
thingiverse thing on their own. I’ll post a link in a bit.

C

On Fri, Mar 29, 2019 at 9:09 PM Kaisertron [e-mail] wrote:

@caseyjmorton https://github.com/caseyjmorton that sounds great a lot
of users use the Creality Ender 3 and CR 10 so I think it would be very
beneficial for them to have an easy drop file and over right ability. This
would help clear up most of the clutter on users finding this thread.

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

[kuksinsky]

Paul with my CR 10S pro if I upload the bug fix for BLTouch 3 will it fix the problem........... I also changed Z_MIN_PROBE_ENDSTOP instead of Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN but no luck still does not work...... very frustrating having a new probe and cannot use it.

What pins did you connect it to? It is possible that the bltouch v2 connection scheme is not suitable for the third version.

Here are some pictures of the pins I use on my Cr10S pro

Ive connected the pins exactly like Jason at Canada 3D printing shows on there Youtube channel https://www.youtube.com/watch?v=PLKEhdznVMY
so
(bottom left (S)ignal) rowD11 (Orange wire), the (top middle (G)round) row A10 (Brown wire) and finally top right (V)olt row A10 (Red wire)

I also did as in this video. This works for the second version. But for some reason does not work in the v3.

[StreckerCM]

I can confirm that @FanDjango 's workaround works on the CR10S Pro. I didn't even need to solder to test it just put the 1K resistor into the back of the dupont connector.

Just going to tape it up to protect it and use it like this until a more permanent solution is found.

[ghost]

@StreckerCM I don't think anything more permanent will be found. The choice is adding the 1K pullup or updating the firmware, which tells the BLTouch to "do a sort of pull-up". I usually glue the two dupont receptacles together with a tiny bit of superglue, thus there is not such a long distance to overcome. But you still risk a crash of the nozzle if the connection ever becomes flaky, thus I prefer the firmware update.

[GilLarose]

@FanDjango
even if you update the new firmware on the Cr10s Pro IT DOES NOT WORK believe me i have tried you still have to install the pull up 1k resistor to work...... thank you FanDjango i did this today to my Cr10s Pro and boom the BLTouch is now doing its thing.......

[caseyjmorton]

Are you enabling ENDSTOPPULLUP_ZMIN_PROBE? Theoretically if you do that in
conjunction with the new BLTouch 3.0 settings it SHOULD work without the
resistor. I don't have a CR10 to validate but I think the CR 10 has the
same board as the Ender 3.

Casey

On Sat, Mar 30, 2019 at 5:28 PM FanDjango [e-mail] wrote:

@StreckerCM https://github.com/StreckerCM I don't think anything more
permanent will be found. The choice is adding the 1K pullup or updating the
firmware, which tells the BLTouch to "do a sort of pull-up". I usually glue
the two dupont receptacles together with a tiny bit of superglue, thus
there is not such a long distance to overcome. But you still risk a crash
of the nozzle if the connection ever becomes flaky, thus I prefer the
firmware update.

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

[paulpenney]

Casey,

The problem board seems to be the CR10SP - It has a different board than the CR10.

On Mar 30, 2019, at 7:04 PM, Casey Morton [e-mail] wrote:

Are you enabling ENDSTOPPULLUP_ZMIN_PROBE? Theoretically if you do that in
conjunction with the new BLTouch 3.0 settings it SHOULD work without the
resistor. I don't have a CR10 to validate but I think the CR 10 has the
same board as the Ender 3.

Casey

On Sat, Mar 30, 2019 at 5:28 PM FanDjango [e-mail] wrote:

@StreckerCM https://github.com/StreckerCM I don't think anything more
permanent will be found. The choice is adding the 1K pullup or updating the
firmware, which tells the BLTouch to "do a sort of pull-up". I usually glue
the two dupont receptacles together with a tiny bit of superglue, thus
there is not such a long distance to overcome. But you still risk a crash
of the nozzle if the connection ever becomes flaky, thus I prefer the
firmware update.

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

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

[caseyjmorton]

Aaahhh, gotcha. Does that one use the Melzi board?

C

On Sat, Mar 30, 2019 at 7:31 PM paulpenney [e-mail] wrote:

>

Casey,

The problem board seems to be the CR10SP - It has a different board than
the CR10.

On Mar 30, 2019, at 7:04 PM, Casey Morton [e-mail]
wrote:

Are you enabling ENDSTOPPULLUP_ZMIN_PROBE? Theoretically if you do that
in
conjunction with the new BLTouch 3.0 settings it SHOULD work without the
resistor. I don't have a CR10 to validate but I think the CR 10 has the
same board as the Ender 3.

Casey

On Sat, Mar 30, 2019 at 5:28 PM FanDjango [e-mail]
wrote:

@StreckerCM https://github.com/StreckerCM I don't think anything
more
permanent will be found. The choice is adding the 1K pullup or
updating the
firmware, which tells the BLTouch to "do a sort of pull-up". I usually
glue
the two dupont receptacles together with a tiny bit of superglue, thus
there is not such a long distance to overcome. But you still risk a
crash
of the nozzle if the connection ever becomes flaky, thus I prefer the
firmware update.

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

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <
https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-478297016>,
or mute the thread <
https://github.com/notifications/unsubscribe-auth/AU_y2VWfcjSOfl9ITYUU77V_bwqd9bodks5vb-2DgaJpZM4bmrEd
.

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

[paulpenney]

The boards are different - the CR10 board is the same as the ender 3 and only has four outputs and is Sanguino based. The CR10S Pro uses an ATmega 2560 base and is considerably different in functionality and layout.

On Mar 30, 2019, at 7:33 PM, Bob Kuhn [e-mail] wrote:

Same controllers, same software and V3s but one needs the 1K pullup and one doesn't.

I'm starting to think there are two V3 variants:

One where you get a strong pullup and never needs the 1K pullup.
One with a weak pullup that needs the 1K only in a few cases. That's what I have in hand.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-478298469, or mute the thread https://github.com/notifications/unsubscribe-auth/AU_y2eRtImwEpTux7VXhZQBc9m9bnTeQks5vb_RbgaJpZM4bmrEd.

[Bob-the-Kuhn]

Nevr mind - just deleted it

[caseyjmorton]

Thanks for the clarification.

On Sat, Mar 30, 2019 at 7:36 PM paulpenney [e-mail] wrote:

The boards are different - the CR10 board is the same as the ender 3 and
only has four outputs and is Sanguino based. The CR10S Pro uses an ATmega
2560 base and is considerably different in functionality and layout.

On Mar 30, 2019, at 7:33 PM, Bob Kuhn [e-mail] wrote:

Same controllers, same software and V3s but one needs the 1K pullup and
one doesn't.

I'm starting to think there are two V3 variants:

One where you get a strong pullup and never needs the 1K pullup.
One with a weak pullup that needs the 1K only in a few cases. That's
what I have in hand.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <
https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-478298469>,
or mute the thread <
https://github.com/notifications/unsubscribe-auth/AU_y2eRtImwEpTux7VXhZQBc9m9bnTeQks5vb_RbgaJpZM4bmrEd
.

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

[caseyjmorton]

IMHO, this is smelling more and more like an issue that Paris needs to
address in hardware.

On Sat, Mar 30, 2019 at 7:37 PM Casey Morton [e-mail] wrote:

Thanks for the clarification.

On Sat, Mar 30, 2019 at 7:36 PM paulpenney [e-mail]
wrote:

The boards are different - the CR10 board is the same as the ender 3 and
only has four outputs and is Sanguino based. The CR10S Pro uses an ATmega
2560 base and is considerably different in functionality and layout.

On Mar 30, 2019, at 7:33 PM, Bob Kuhn [e-mail] wrote:

Same controllers, same software and V3s but one needs the 1K pullup and
one doesn't.

I'm starting to think there are two V3 variants:

One where you get a strong pullup and never needs the 1K pullup.
One with a weak pullup that needs the 1K only in a few cases. That's
what I have in hand.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <
https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-478298469>,
or mute the thread <
https://github.com/notifications/unsubscribe-auth/AU_y2eRtImwEpTux7VXhZQBc9m9bnTeQks5vb_RbgaJpZM4bmrEd
.

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

[GilLarose]

Casey yes i have tried both end stop version and still did not work
Like i wrote on previous thread my printer is the Cr10s Pro and the new firmware will not fix the problem so after uploading the new DWINSET on github/insanityautomation/marlin/creality
and flash the board still did not work so after all that the 1 k resistor did the the trick

Gilbert Larose jr.
Stunt Coordinator
3-2-1 Action inc.
[phone]
e-mail: [email protected]
web: www.321action.ca

On Mar 30, 2019, at 7:04 PM, Casey Morton [e-mail] wrote:

Are you enabling ENDSTOPPULLUP_ZMIN_PROBE? Theoretically if you do that in
conjunction with the new BLTouch 3.0 settings it SHOULD work without the
resistor. I don't have a CR10 to validate but I think the CR 10 has the
same board as the Ender 3.

Casey

On Sat, Mar 30, 2019 at 5:28 PM FanDjango [e-mail] wrote:

@StreckerCM https://github.com/StreckerCM I don't think anything more
permanent will be found. The choice is adding the 1K pullup or updating the
firmware, which tells the BLTouch to "do a sort of pull-up". I usually glue
the two dupont receptacles together with a tiny bit of superglue, thus
there is not such a long distance to overcome. But you still risk a crash
of the nozzle if the connection ever becomes flaky, thus I prefer the
firmware update.

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

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[Stephenm64]

@FanDjango @InsanityAutomation

Installed a BLTouch v3 on my Ender3 Pro and i can confirm the Creality_2.0_Devel firmware looks to have the BLTouch working correctly, no c7 snip needed. Though there is the problem with it where it starts off blinking red/blue. On the previous v2 i had installed, on power-up it would do a self test then stay red. with this fw and the V3 it will turn on be red for a moment then blink red-blue 50/50 duty cycle until a auto home is started.

Is this a new/known behavior or is there a bug?

[ghost]

@Stephenm64 To me it looks like the new BLTouch V3 only does a self test when it is commanded to do so. In very cryptic terms on the bottom of the datasheet they mention that the self-test behaviour has been changed. Probably a change for the better, a power-on self test could hit the printed object if it was done for (say) a power glitch on the 5V line. I suppose this is for safeties sake.

[ghost]

@GilLarose So we have found a printer, the CR10s Pro, which needs both the new firmware and the 1K resistor to make the BLTouch V3 work?

It would be nice to know the following, just to totally sure:

• Would the 1K resistor alone, without the new firmware, have done it?
• Before using the 1K resistor, in the new firmware, ENDSTOPPULLUP_ZMIN_PROBE was correctly set?

But if it is working for you now, that's fine. Other's using this printer will come across this here and will go on from this point - @InsanityAutomation who so quickly made the changes to the firmware would probably really like to know why his modifications don't appear to work on one (up to now) special case.

[juliandroid]

@Stephenm64 Probably a change for the better, a power-on self test could hit the printed object if it was done for (say) a power glitch on the 5V line. I suppose this is for safeties sake.

I guess that also includes "Print resume" after power failure?

[ghost]

I guess that also includes "Print resume" after power failure?

I have been asking myself what prompted ANTClabs to modify the V3 in such a fashion as to cause the problems we have been seeing.

• some new commands (at new servo angles)
• a new output configuration (open drain)

My personal take on this is:

• the old output stage, 5V logic level had two disadvantages: a). Need to cut a trace to change to 3.3V logic (even older probes: you absolutely needed some resistors) b). Can potentially destroy an input pin on a non-5V tolerant processor/controller board
• the power on self test could occur at, let's say, inopportune times

So, what a nice idea, let's make it configurable by software and choose a safe default mode (open drain) which cannot harm anyone. Might not work for everyone - but I think that they surely did some testing of their own and who knows how many probes are being installed and work out of the box somewhere - we only see the fails here, right?

Sadly, as can be seen in the previous post, each and every controller board attempting to improve upon original RAMPS "standard", by using protective resistors, noise-reducing capacitors and suchlike, every one of them differing from the others, make a standardised interface difficult. There will probably always be a board out there that needs a resistor pull-up

My main criticism of the V3 is, there should be a mode that increases the 10ms pulse to be a continuous level until reset as if the probe were a normal microswitch but one that stays closed after touching.

[RageQuit]

I have a CR-10S Pro currently running capacitive sensor, Tiny Machines firmware, Arduino for compilation, Raspberry Pi with Octoprint, S3D for slicing.
Have a BLTouch V3.0 ready to install and am trying to work out best method to make it functional.
Would love some guidance on where to download Marlin 2.x to test plus clear instructions as to what coding I need to change/uncomment, start up scripts as well.
Thanks in advance.

[ghost]

@RageQuit Coming from a non-BLTouch szenario, you need a firmway flash anyway, so see the @InsanityAutomation posts above where he points us towards his special CR forks? (Since it is a CR - normal folks just get the current Bugfix-2.x from here.

And then

/**
 * The BLTouch probe uses a Hall effect sensor and emulates a servo.
 */
#define BLTOUCH
#if ENABLED(BLTOUCH)
  //#define BLTOUCH_DELAY 375   // (ms) Enable and increase if needed

  // BLTouch V3.0 and newer smart series
  #define BLTOUCH_V3
  #if ENABLED(BLTOUCH_V3)
    //#define BLTOUCH_FORCE_5V_MODE
    //#define BLTOUCH_FORCE_OPEN_DRAIN_MODE
  #endif
#endif

and also make sure you define ENDSTOPPULLUP_ZMIN_PROBE

[juliandroid]

@InsanityAutomation I was looking at the branches, but I couldn't find the correct one which is preconfigured for CR10S Pro + DWIN + BLtouch V3.0 fix.

The "Creality_DWINTest" looked promising but the comment "// Has not seen real hardware yet!" didn't inspire confidence.

On the TinyMachines I found this hex file: https://www.tinymachines3d.com/pages/10spro is that the BLTouch V3.0 fixed version and based on which branch it was build (if that was the case)?

Thanks!

[InsanityAutomation]

That's the right branch! That comment needs to be removed.... It's very old and I've been lazy.... See note above about 1k resistor as well, since most report needing it.

[GilLarose]

@FanDjango
To answer your questions....

        >Would the 1K resistor alone, without the new firmware, have done it?

i did not try the 1k pull up resistor on my Cr10s Pro BEFORE updating to the new firmware because following the instruction from 3D Canada Printing you need to update your machine after installing the BL Touch..... to late now to see if it would have solve the problem......

        >Before using the 1K resistor, in the new firmware, ENDSTOPPULLUP_ZMIN_PROBE was correctly set?

i actually tried both end stop:

1: Z_MIN_PROBE_ENDSTOP ........ and then
2: Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
and still did not work.

I did not try flashing the new marlin 2.0 to this printer only the newest version of DWINSET TEST firmware

In conclusion what worked for me on my Creality CR10S PRO with the BLTouch ver.3
Update the DWINSET TEST firmware on github/insanityautomation/marlin/creality
enabled
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
flash the board then add the 1k pull up resistor will fix the problem........ anyways it did for me

[RageQuit]

Hi GiLarose,

Can you post the full url for github/insanityautomation/marlin/creality

Looking to download DWINSET TEST firmware to get my BLTouch V3.0 running on my CR-10S Pro

Thanks in advance.

Geoff.
On 1 Apr 2019, 1:21 PM +1100, GilLarose [e-mail], wrote:

@FanDjango
To answer your questions....

Would the 1K resistor alone, without the new firmware, have done it?
i did not try the 1k pull up resistor on my Cr10s Pro BEFORE updating to the new firmware because following the instruction from 3D Canada Printing you need to update your machine after installing the BL Touch..... to late now to see if it would have solve the problem......
Before using the 1K resistor, in the new firmware, ENDSTOPPULLUP_ZMIN_PROBE was correctly set?
i actually tried both end stop:
1: Z_MIN_PROBE_ENDSTOP ........ and then
2: Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
and still did not work.
I did not try flashing the new marlin 2.0 to this printer only the newest version of DWINSET TEST firmware
In conclusion what worked for me on my Creality CR10S PRO with the BLTouch ver.3
Update the DWINSET TEST firmware on github/insanityautomation/marlin/creality
enabled
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
flash the board then add the 1k pull up resistor will fix the problem........ anyways it did for me
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Ttnow]

I did exactly what you did @FanDjango.

"my Creality CR10S PRO with the BLTouch ver.3
Update the DWINSET TEST firmware on github/insanityautomation/marlin/creality
enabled
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
flash the board then add the 1k pull up resistor.

My bltouch v3 homing detects the bed pulls up twice and on the third time wants to travel trough the bed approx 5mm. not sure how to adjust the offset.. I thought by sodering the 1K resistor would just return to v2 bltouch behaviour and I could just follow the exact instructions on the 3dprinting canada youtube video for stalling bltouch on cr10spro.. so close and yet so far...

[InsanityAutomation]

Here's the branch url https://github.com/InsanityAutomation/Marlin/tree/Creality_DWINTest

[GilLarose]

Hello RageQuit

Here's the branch url https://github.com/InsanityAutomation/Marlin/tree/Creality_DWINTest

Insanity Automation also posted the link

[RageQuit]

Thanks GilLarose - I appreciate the link

On Mon, Apr 1, 2019 at 6:17 PM GilLarose [e-mail] wrote:

Hello RageQuit

Here's the branch url
https://github.com/InsanityAutomation/Marlin/tree/Creality_DWINTest

Insanity Automation also posted the link

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

[GilLarose]

WELLL GUYS I WISH INEVER BOTH THIS PAIN IN THE ASS BL TOUCH VER.3 JUST HEADACHES MAN
3 weeks now without being able to print after installing the firmware
I thought I found the solution with the 1k resistor but NOPE the BLTouch does not work on my CR10s Pro the levelling is always inconsistent and errors popping up with the auto levelling

This is what I see on the LCD display after updating from the new DWINSET TEST firmware I thought it was the new marlin 2.0 so Guys out there with the CR10S PRO who as not installed this new firmware DON'T you will be very disappointed and discourage keep your inductive or passive probe for now until somebody finds the right solution

[GilLarose]

[GilLarose]

[ghost]

Some advice from me maybe? Long experience with frustrating situations of this kind - in your case I would go back to your previous config and probe, put the BLTouch V3 in its box and do some happy printing in the old configuration. Wait a few days or a week or so to see new developments on this problem topic. Maybe then take a new and fresh attempt with no anger. I believe the problem is solvable. @InsanityAutomation and @Bob-the-Kuhn have done an admirable job getting this thing to work initially but maybe some more details and possible optimisation might appear, thanks also to your reports. And then you can try again.

[kingofmonkeys]

This thread is kind of scary. I just got my BLTouch today, installing it on a CR-10S and it is the 3.0 version. I'm currently running Marlin 1.1.9..is there any hope of having a bug fix version of 1.1.x that works with BLTouch 3.0? Do we think simply adding the 1k resistor will make it work with Marlin 1.1.9?

[StreckerCM]

@GilLarose I got that error twice yesterday after two successful prints. I also noticed that if I turn off auto bed leveling on the touch screen it turns itself back on if I press the Home Z button. I also cleared the EPROM and restarted the printer and the grid persisted on the screen. I think we may still have some bugs to workout with the V3.

[GilLarose]

FanDjango were do I upload the CREALITY ORIGINAL Firmware it is not on the sd card they supply with the machine

[ghost]

@kingofmonkeys 1K resistor should do it, yes. But please, before you mount it or modify your extruder, you can hook it up and hold it in your hand to test the probing when you do a G28 Z or a G29.

... use your finger to "simulate" the touches. Make sure to put a bar of soap or a marshmallow under the nozzle in case you fall asleep doing the simulated touches with your finger or drop the probe because the cat came in

Be inventive!

@StreckerCM Could be

I got that error twice yesterday after two successful prints.

Would you like to help debugging that? Can you activate the probing repeatbililty test in the firmware and repeatedly run that, thereby stress-testing the probing operation and report back on how that performs? And maybe other things that come to mind to isolate the problem?

[StreckerCM]

@FanDjango I’ll do that when I get home tonight and report back. I spent an out last night trying to get the gantry as spot on as possible so I don’t think that is actually the issue.

[ghost]

@GilLarose You want to go back? maybe here?

[kingofmonkeys]

@FanDjango Thanks! I have the petsfang on so its simple to add the mount and test it out but I plan to be very careful to not drive the nozzle into the bed. Hopefully the resistor does the trick. If not, do you see a problem with me updating to Marlin 2.0 bugfix on my CR-10s?

[ghost]

@kingofmonkeys If the 1K works, fine for now. If not, yes, try the special CR fork of @InsanityAutomation (see above). Make sure you can go back if not happy. But apart from two cases above, it's not looking bad.

[GilLarose]

FanDjango if im not mistaking you don't have the CR10S Pro...... to make some test on your side right....... i wish you did so you could test and help all of us with the CR10SP

luckily for me I did not install my glass bed yet because every time I go on the LCD and press levelling it does an automatic levelling BL Touch is doing its thing then for some reason it goes down Z- right into the bed nozzle crashing into the Original Aluminum plated bed...... imagine if I have the bed........ ouchhhh

[ghost]

Seems to me that open problems with the BLTouch V3 seem to concentrate on CR printers, CR-10s pro? No others out there from looking at this thread, looks like.

Current (possible) problems:
@GilLarose CR-10s pro - problems reported
@Ttnow CR-10s pro -problems reported
@RageQuit CR-10s pro - IS IT WORKING?
@juliandroid CR-10s pro - IS IT WORKING?
@StreckerCM CR-10s pro - problems reported

[GilLarose]

Yes all of us with the CR10S Pro have an issue.... so my point is HOPEFULLY the Guys at 3D Canada Printing will get back to there customers who bought the Ver.3 for these machine and help them ASAP...... I know you understand FanDjango..... when you buy and new gizmo and were sold on it being a very effective product and it does not work..... it gets annoying......

[ghost]

FanDjango if im not mistaking you don't have the CR10S Pro...... to make some test on your side right....... i wish you did so you could test and help all of us with the CR10SP

That's correct. Just trying to get down to the cause of the problems, is all...

But here is another thought: Could you tell me more about your setup?

In my case, the probe is also the Z-MIN stop. So, the probe is used to do the Z-HOME.

And then, if I connect to the printer and do a manual (NOT ON THE LCD) G28 Z, it will home using the probe. So far so good.

And then, if I do a G29 it will start levelling, in my case 7X7 grid. Works fine.

And after that, finished.

Can you try some stuff not only the LCD operation like I described?

[InsanityAutomation]

But I do have a 10s pro (obviously lol) and now that I'm back from mrrf where that was on display, I can get a bltouch on it. I have a few more of the V3 to verify on the machine as well. Hopefully I can have proper support instructions that will work easily for everyone as soon as I can get the workshop all back together after traveling.

[GilLarose]

FanDjango just now entered G28 Z and BLTouch did not activate and was going strait into the bed so I had to stop before it did...... im using Simplify3D

[ghost]

@GilLarose - ok, so wait a mo for @InsanityAutomation to work his magic. He's got the same printer. He can see the stuff in this thread. Let's give him room to breathe and get to the bottom of this.

[GilLarose]

One good thing about the DWINSET TEST firmware for the CR10SP is on the Simplify3D software the current temperature display and Temperature Plot did not show up with the original firmware now it does LOL. but id rather have an BLTouch working

[GilLarose]

totally agree with you lets wait for @InsanityAutomation to work his magic.

[juliandroid]

@FanDjango I didn't try that yet :/ Many reasons for that, one I don't believe I really need 1k resistor and it should be just a software fix, so I prefer @InsanityAutomation (thanks btw for all of the effort and time spent from all of you helping), when he has time to confirm on CR10S Pro.
Another is the list of reported and confirmed bugs in the branch that I have to go through and decide whether to upgrade to that version or keep the original (1.60.3 yet) that I built from source. And lastly, the BLTouch 3.0 needs a slightly different mount, so I have to modify the 3d model and print it in something more temperature stable than PLA.

[StreckerCM]

@FanDjango I downloaded the firmware fresh from @InsanityAutomation GitHub, reflashed, reset the Eprom, and levled the bed manually. I then performed the repeatability test on each corner and in the middle of the bed. It is no where close to the 3mm of deviation that the probing failed message states.

I did not get this error during the test at all but I also didn't do an ABL code just the tests.

Notes: This is with a BL Touch V3.0 Smart with a 1K resistor between the Red 5V and White wires

Front Left (50,50)

Send: M48 P4 X50 Y50 V4 E L2

Recv: M48 Z-Probe Repeatability Test
Recv: Positioning the probe...

Recv: Bed X: 50.000 Y: 50.000 Z: 0.019
Recv: Starting radius: 22.00 angle: 143.00 Direction: Clockwise
Recv: Going to: X81.76 Y83.40 Z5.70

Recv: 1 of 4: z: 0.023 mean: 0.0230 sigma: 0.000000 min: 0.023 max: 0.023 range: 0.000
Recv: Starting radius: 14.00 angle: 123.00 Direction: Counter-Clockwise
Recv: Going to: X77.88 Y70.00 Z5.70

Recv: 2 of 4: z: 0.024 mean: 0.0237 sigma: 0.000750 min: 0.023 max: 0.024 range: 0.002
Recv: Starting radius: 25.00 angle: 292.00 Direction: Clockwise
Recv: Going to: X82.69 Y39.09 Z5.70

Recv: 3 of 4: z: 0.012 mean: 0.0200 sigma: 0.005339 min: 0.012 max: 0.024 range: 0.012
Recv: Starting radius: 8.00 angle: 353.00 Direction: Clockwise
Recv: Going to: X96.30 Y58.07 Z5.70

Recv: 4 of 4: z: 0.012 mean: 0.0180 sigma: 0.005777 min: 0.012 max: 0.024 range: 0.012
Recv: Finished!
Recv: Mean: 0.018000 Min: 0.012 Max: 0.024 Range: 0.012
Recv: Standard Deviation: 0.005777

Back Left (50,250)

Recv: Bed X: 50.000 Y: 250.000 Z: -0.022
Recv: Starting radius: 14.00 angle: 290.00 Direction: Clockwise
Recv: Going to: X84.53 Y250.11 Z5.70

Recv: 1 of 4: z: -0.024 mean: -0.0240 sigma: 0.000000 min: -0.024 max: -0.024 range: 0.000
Recv: Starting radius: 35.00 angle: 21.00 Direction: Counter-Clockwise
Recv: Going to: X109.57 Y292.02 Z5.70

Recv: 2 of 4: z: -0.022 mean: -0.0230 sigma: 0.001000 min: -0.024 max: -0.022 range: 0.002
Recv: Starting radius: 16.00 angle: 54.00 Direction: Clockwise
Recv: Going to: X105.22 Y267.94 Z5.70

Recv: 3 of 4: z: -0.024 mean: -0.0232 sigma: 0.000850 min: -0.024 max: -0.022 range: 0.002
Recv: Starting radius: 28.00 angle: 231.00 Direction: Counter-Clockwise
Recv: Going to: X85.14 Y235.43 Z5.70

Recv: 4 of 4: z: -0.020 mean: -0.0224 sigma: 0.001556 min: -0.024 max: -0.020 range: 0.004
Recv: Finished!
Recv: Mean: -0.022375 Min: -0.024 Max: -0.020 Range: 0.004
Recv: Standard Deviation: 0.001556

Middle (150,150)

Recv: 1 of 4: z: -0.017 mean: -0.0165 sigma: 0.000000 min: -0.017 max: -0.017 range: 0.000
Recv: Starting radius: 28.00 angle: 141.00 Direction: Clockwise
Recv: Going to: X184.66 Y190.49 Z5.70

Recv: 2 of 4: z: -0.018 mean: -0.0173 sigma: 0.000750 min: -0.018 max: -0.017 range: 0.001
Recv: Starting radius: 27.00 angle: 58.00 Direction: Counter-Clockwise
Recv: Going to: X190.47 Y190.00 Z5.70

Recv: 3 of 4: z: -0.017 mean: -0.0173 sigma: 0.000624 min: -0.018 max: -0.017 range: 0.001
Recv: Starting radius: 11.00 angle: 216.00 Direction: Counter-Clockwise
Recv: Going to: X186.60 Y152.54 Z5.70

Recv: 4 of 4: z: -0.008 mean: -0.0150 sigma: 0.004077 min: -0.018 max: -0.008 range: 0.010
Recv: Finished!
Recv: Mean: -0.015000 Min: -0.018 Max: -0.008 Range: 0.010
Recv: Standard Deviation: 0.00407

Front Right (250,50)

Send: M48 P4 X250 Y50 V4 E L2
Recv: M48 Z-Probe Repeatability Test
Recv: Positioning the probe...

Recv: Bed X: 250.000 Y: 50.000 Z: -0.035
Recv: Starting radius: 36.00 angle: 231.00 Direction: Clockwise
Recv: Going to: X254.79 Y55.52 Z5.70

Recv: 1 of 4: z: -0.034 mean: -0.0340 sigma: 0.000000 min: -0.034 max: -0.034 range: 0.000
Recv: Starting radius: 21.00 angle: 260.00 Direction: Counter-Clockwise
Recv: Going to: X296.14 Y42.92 Z5.70

Recv: 2 of 4: z: -0.034 mean: -0.0340 sigma: 0.000000 min: -0.034 max: -0.034 range: 0.000
Recv: Starting radius: 21.00 angle: 306.00 Direction: Counter-Clockwise
Recv: Going to: X308.54 Y53.14 Z5.70

Recv: 3 of 4: z: -0.036 mean: -0.0345 sigma: 0.000707 min: -0.036 max: -0.034 range: 0.002
Recv: Starting radius: 14.00 angle: 79.00 Direction: Clockwise
Recv: Going to: X298.43 Y74.18 Z5.70

Recv: 4 of 4: z: -0.040 mean: -0.0358 sigma: 0.002250 min: -0.040 max: -0.034 range: 0.006
Recv: Finished!
Recv: Mean: -0.035750 Min: -0.040 Max: -0.034 Range: 0.006
Recv: Standard Deviation: 0.002250

Back Right (250,250)

Recv: Bed X: 250.000 Y: 250.000 Z: -0.017
Recv: Starting radius: 25.00 angle: 316.00 Direction: Clockwise
Recv: Going to: X297.73 Y239.22 Z5.70

Recv: 1 of 4: z: -0.018 mean: -0.0185 sigma: 0.000000 min: -0.018 max: -0.018 range: 0.000
Recv: Starting radius: 37.00 angle: 119.00 Direction: Clockwise
Recv: Going to: X288.71 Y299.98 Z5.70

Recv: 2 of 4: z: -0.008 mean: -0.0132 sigma: 0.005250 min: -0.018 max: -0.008 range: 0.010
Recv: Starting radius: 5.00 angle: 291.00 Direction: Clockwise
Recv: Going to: X289.30 Y258.05 Z5.70

Recv: 3 of 4: z: -0.013 mean: -0.0130 sigma: 0.004301 min: -0.018 max: -0.008 range: 0.010
Recv: Starting radius: 19.00 angle: 330.00 Direction: Counter-Clockwise
Recv: Going to: X308.51 Y267.27 Z5.70

Recv: 4 of 4: z: -0.016 mean: -0.0138 sigma: 0.003945 min: -0.018 max: -0.008 range: 0.010
Recv: Finished!
Recv: Mean: -0.013750 Min: -0.018 Max: -0.008 Range: 0.010
Recv: Standard Deviation: 0.003945

LCD ABL Result

[kingofmonkeys]

So I installed my v3 BLTouch this morning on my CR-10s and it seems to be working just fine with Marlin 1.1.9. I don't have any of the firmware fixes or the 1k resistor on it and its working as far as i can tell (this is my first bltouch).

Is it possible there were some bad v3's that got into circulation?

[GilLarose]

@kingofmonkeys
if you look closer at the threads about the BLTouch ver. 3 most of the problem is with the CR10s Pro not the CR10s

[GilLarose]

CR10s Pro is a different board of the CR10s and Ender

[kingofmonkeys]

Good to know, so we think the issue is only with the pro?

[paulpenney]

Heres another point of data for @InsanityAutomation - A customer has installed a V3.0 on his CR10SP with the https://github.com/InsanityAutomation/Marlin/tree/Creality_DWINTest software. He installed the 1k resistor between red and white on his probe lines. The issue is that it will home twice (BL touch will detect the bed, then do it again) but then Z moves down a THIRD time and doesn't deploy the probe, and just keeps descending into infinity. He tried this about 20cm up using his finger, and after the BL touch senses home the second time it just descends.

[GilLarose]

@streckerCm
what was the firmware name you downloaded, was it the DWINSET TEST

[StreckerCM]

@GilLarose Marlin-Creality_DWINTest

[GilLarose]

@paulpenney
exactly what happened to me yesterday ....nonstop.... the third homing the Bl Touch does not deploy so nozzle goes strait into the bed ....ouch if you have a glass bed

[StreckerCM]

@GilLarose @paulpenney when I did my repeatability test there were a few times it tested twice did a self test and tried again. Did you reset the EPROM and redo the Z offset after flashing?

[GilLarose]

EPROM no don't know how

[GilLarose]

@StreckerCM
This is what I get on my front display info
is this what you see on yours as well

[StreckerCM]

@GilLarose I will confirm when i get home tonight but try this to reset the EEPROM. You can then use the LCD to set the Z offset in the leveling menu.

M502 Reset current settings to defaults, as set in Configurations.h. (Follow with M500 to reset the EEPROM too.)

https://github.com/MarlinFirmware/Marlin/wiki/EEPROM

[GilLarose]

Chris, is your CR10s Pro all good now or you still have issues

[GilLarose]

@StreckerCM
Chris, is your CR10s Pro all good now or you still have issues

[StreckerCM]

@GilLarose I got it leveled and I didn't get the Probing Failed error yet. I got home late yesterday so I wasn't able to start a print. I will try one tonight to see how it works.

[GilLarose]

@paulpenney
@InsanityAutomation
@FanDjango
@StreckerCM
You guys won't believe this....... ANOTHER ISSUE on the CR10s Pro, with the new DWINSET software after trying to print something the Extruder Stepper motor is going the wrong way so instead of pushing the filament into the extruder its retracting..........

[Roxy-3D]

ANOTHER ISSUE on the CR10s Pro...

CR10's don't seem ready for Prime Time....

[chrisbatman]

@InsanityAutomation I sincerely hope you "settle in" after MRRF soon. My CR10s Pro is a non-working hunk of metal at the moment. I'm a NOOB to Marlin and wish I could contribute to help others out with modifying the firmware, as I've been reading there's a lot of us "dead in the water" after installing V3.0 BLtouch. Thank you for your effort.....and thanks to the community for their efforts.

[RageQuit]

I started the swap over to BLTouch then put the original sensor back in and am waiting for a fix. At least I can print in the meantime.

[StreckerCM]

@InsanityAutomation not sure if this helps but I got the Probing Error again after doing three G29's in a row.

If you tap on this screen you get a message but despite having my language set to English it is in Chines so i am not sure what it is asking.

I am still using the OEM aluminum bed and it was levied manually. Not perfect but no where near the 3MM out the warning claims.

Octoprint Terminal Output

Recv: ok N6 P15 B3
Send: N8 G2827
Recv: ok N7 P15 B3
Send: N9 G2927
Recv: T:225.00 /225.00 B:49.91 /50.00 @:59 B@:62
Recv: echo:busy: processing
Recv: T:225.06 /225.00 B:50.00 /50.00 @:57 B@:14
Recv: echo:busy: processing
Recv: T:225.06 /225.00 B:50.00 /50.00 @:57 B@:15
Recv: echo:busy: processing
Recv: T:225.06 /225.00 B:50.00 /50.00 @:57 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:58 B@:15
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.01 /50.00 @:58 B@:8
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:58 B@:14
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:58 B@:14
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:58 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:58 B@:14
Recv: echo:busy: processing
Recv: T:224.96 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: X:90.00 Y:63.00 Z:5.00 E:3.94 Count X:7200 Y:5040 Z:2000
Recv: ok N8 P15 B2
Send: N10 M117 ETL 07h00m38s50
Recv: T:224.96 /225.00 B:50.00 /50.00 @:59 B@:14
Recv: echo:busy: processing
Recv: T:224.96 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:224.87 /225.00 B:50.00 /50.00 @:61 B@:14
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:224.96 /225.00 B:50.00 /50.00 @:60 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:16
Recv: echo:busy: processing
Recv: T:224.96 /225.00 B:50.00 /50.00 @:60 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:16
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:15
Recv: echo:busy: processing
Recv: T:225.06 /225.00 B:50.00 /50.00 @:58 B@:16
Recv: echo:busy: processing
Recv: T:225.00 /225.00 B:50.00 /50.00 @:59 B@:17
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N11 M10523
Recv: Error:STOP called because of BLTouch error - restart with M999
Changing monitoring state from "Printing" to "Error: STOP called because of BLTouch error - restart with M999"
Changing monitoring state from "Error: STOP called because of BLTouch error - restart with M999" to "Offline (Error: STOP called because of BLTouch error - restart with M999)"
Connection closed, closing down monitor

[juliandroid]

@InsanityAutomation @FanDjango Looking at the DWINTest branch I don't see inside the code the BLTOUCH_V3 constant and I'm wondering whether people properly setup Marlin for the CR10s Pro. Also, as far as I understand the EEPROM should be reset (since Creality stores z-offsets there) and after mounting the probe you should measure the physical position and update the configuration with those values and recompile the source.

So, I would ask kindly @InsanityAutomation once you have check your CR10s Pro to write down brief step-by-step instructions what you are doing, because I'm certain that most of us will miss something critical that is obvious to you, most experienced here! Thank you!

[Roxy-3D]

So, I would ask kindly @InsanityAutomation once you have check your CR10s Pro to write down brief step-by-step instructions what you are doing,

Let's try to minimize his effort.... If you were to produce a list of steps you know are necessary, he can just review that list, and edit it to match his thinking.

[InsanityAutomation]

I'm planning to do some experimenting to see if I can find an input pin that has the ability to read this reliably without adding the pull-up resistor. I just got back from traveling, and I'm trying to catch up at the day job. I'll be sitting down to do some work on this soon but it's not a 30 second task. It's going to take a decent bit of testing and validation to be sure that it's 100% reliable every time, especially given the intermittent issues that we've been hearing about.

[GilLarose]

@StreckerCM
Hey Chris did you finally get a chance to print something last night...... because like a wrote yesterday the BLTouch is not working properly but I tried anyways to print something to see how the printer reacts to this DWINSET TEST firmware and my extruder stepper motor is going backwards..... man this is so annoying instead of pushing the filament into the hothead its retracting........ soooooo weird

[StreckerCM]

I was able to print last night after a power cycle I was able to complete a G29 without error. The print completed this morning but I have only seen it on my Pi Cam I didn’t have a chance to inspect it

[ghost]

@juliandroid and others:
It is the 1.1.9_B6 (or higher) version found under here
Don't compare it to the current Bugfix-2.0.x of Marlin. @InsanityAutomation has not created the V3 defines for the configuration. So searching for such symbols will not find them. If you really somehow want to make sure you have downloaded the right source code, search for this string instead: BLTOUCH_FORCE_5V_MODE
It is enough to define the BLTouch V3 just as before the V2. All the instructions above for special defines are for the stock Marlin Bugfix-2.0, which has got a bundle of new defines for the V3 in configuration.h
The Creality_DWINTest fork contains the necessary V3 code as soon as you just define BLTOUCH.
In other words, it does the same as the stock Marlin when V3 is defined, but without you needing to define V3, it is V3 capable "by default".

[Bl0wnp0ny]

thinking about returning mine and purchasing one directly from creality. are there any advantages to the V3 that is worth this hassle?

[Roxy-3D]

You do get an extra 1mm of clearance above the part being printed. That is very helpful when you are printing things with over hanging edges that curl upward.

[ghost]

As this seems to hit only the CR10s-Pro I would worry more about what it is that makes that controller board so finnicky - but @InsanityAutomation did mention looking for a more lenient pin to connect to so there is hope.
@Roxy-3D I have also now profited from that 1mm more - the additional clearance is actually quite obvious when peering at the nozzle from the side.
So, @Bl0wnp0ny, maybe wait a few days. Where's the hassle unless you have ripped everything apart already?

[Bl0wnp0ny]

After being down for nearly 2 weeks, i rewired the original sensor. Does the 1mm extra clearance make that much of a difference? if i have overhangs curling up that much, the print probably won't end well anyway.

[GilLarose]

@Bl0wnp0ny
after rewired the original sensor, did you keep the same flash firmware (DWINSET TEST) or did you go back to the original creality software

[Bl0wnp0ny]

i went back to the last good tinymachines firmware which I had saved a copy of.

[GilLarose]

do you mind sharing that copy with us so i can go back to a firmware that does work because my Cr10s Pro is totally out of wack with this DWINSET firmware and cannot use it at all......

[kopsy63]

I would like to thank all of you working on this problem. I have a Monoprice Maker Select Plus. I purchased the BLTouch and ended up with a v3. I have the ADVi3++ v3.0 firmware currently installed and it does not yet work with the v3 BLTouch. Given that, I stuck the pull up resistor in and it worked great - my printer is auto bed leveling just like I hoped it would. I stuck the bed leveling gcode right after starting the extruder and bed heating. Works great since heating takes about 4 minutes and the bed leveling takes about 3.5 minutes, so it is finished before the printer is completely heated. Thanks!

[caseyjmorton]

Yes/no, I will publish a copy of my configuration.h files, but you will
still need to update the offsets for your specific mounting bracket,
meaning that a pre-compiled version Isn’t scalable. Once I publish it to
thingiverse, I’ll send a like on this thread.

C

On Sun, Apr 7, 2019 at 8:38 AM kb79000 [e-mail] wrote:

Hello it' possible to send me a precompiled version with bltouch 3.0 for
my ender 3 pro ?
Thx

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

[InsanityAutomation]

Can also look at the universal Creality branch that's been linked several times in this thread and has been proven working....

[caseyjmorton]

All, I have posted my configuration files up here for the Ender 3. Please dont just drop these in your build and upload. Depending on your mount, you will likely still have to update the probe offsets.

[kb79000]

You link is dead @caseyjmorton

[mtwomey]

I'm not completely familiar with the different boards with some of these printers, I have a Makerfarm i3v which is Arduino / Ramps 1.4 based. Does it appear likely, at this point, that the software solution will work for the BLTouch v3.0? (I'm about to order one)

[caseyjmorton]

It should be good now. Thanks!

C

On Mon, Apr 8, 2019 at 4:03 AM kb79000 [e-mail] wrote:

You link is dead @caseyjmorton https://github.com/caseyjmorton

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

[Penn1337]

Hey guys I'm having an issue with the BLTOUCH V3. I've been working on this what seems like weeks now and I'm stumped. I've tried lots of things including multiple working configs for marlin 2.0bug fix. I've got a ender 3 and I've hooked everything up and when I start the machine up the bltouch just flashes at me. If I run the sw deploy it goes red and I can reset it and then the error goes away. I've made a couple YouTube videos showing the problems I will link them. The only thing i think i havent done is take the c7 cap out.

The bltouch will self test just fine with 1.1.9 but wont stop the z axis. I think I'm beyond frustrated. I initially thought bltouch was bad so I got a replacement as well as my pin 27 board. The bltouch unit is getting 4.92 volts. The weird thing is that if i plug my PC in the bltouch starts right up and does themself test. With the PC plugged in it gets 4.62 volts.

Here are the links to the videos. Sorry for the crappy quality. Any help would be great because I've been banging my head against the wall for a couple weeks now.

I also sent an email to antclabs telling the situation

Watch "BLTOUCH not stopping when probing." on YouTube
https://youtu.be/Q96Zg1Ij-Pc

Watch "BLTOUCH V3 ENDER 3 Problem" on YouTube
https://youtu.be/6x0KWZ_wUt4

Watch "Ender 3 BLTOUCH V3 error" on YouTube
https://youtu.be/4JTLYnWoako

[Stephenm64]

I have a ender 3 and used insanityautomation's creality 2.0 branch with the
bltouch v3 and it works fine, but does blink on startup. If you ignore it
and do a bed calibration it will stop blinking and you can print without
issues.

On Tue, Apr 9, 2019, 7:10 AM Penn1337 [e-mail] wrote:

Hey guys I'm having an issue with the BLTOUCH V3. I've been working on
this what seems like weeks now and I'm stumped. I've tried lots of things
including multiple working configs for marlin 2.0bug fix. I've got a ender
3 and I've hooked everything up and when I start the machine up the bltouch
just flashes at me. If I run the sw deploy it goes red and I can reset it
and then the error goes away. I've made a couple YouTube videos showing the
problems I will link them. The only thing i think i havent done is take the
c7 cap out.

The bltouch will self test just fine with 1.1.9 but wont stop the z axis.
I think I'm beyond frustrated. I initially thought bltouch was bad so I got
a replacement as well as my pin 27 board. The bltouch unit is getting 4.92
volts. The weird thing is that if i plug my PC in the bltouch starts right
up and does themself test. With the PC plugged in it gets 4.62 volts.

Here are the links to the videos. Sorry for the crappy quality. Any help
would be great because I've been banging my head against the wall for a
couple weeks now.

Watch "BLTOUCH not stopping when probing." on YouTube
https://youtu.be/Q96Zg1Ij-Pc

Watch "BLTOUCH V3 ENDER 3 Problem" on YouTube
https://youtu.be/6x0KWZ_wUt4

Watch "Ender 3 BLTOUCH V3 error" on YouTube
https://youtu.be/4JTLYnWoako

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

[Penn1337]

Oh ok then haha that's great. Thanks for the info!

[caseyjmorton]

At this point in time the v3 is only working on the Marlin 2.0 branch.
Follow the directions that I posted in the thing overseas link earlier on
this thread. On the ender 3 there is no need to take out C7 or modify the
hardware in any way. If you follow the directions on my thingiverse link
and it's still not triggering when it homes, then you may have a wiring
issue. If the probe deploys, that means the servo wires are ok, so it's
possible that the actual hall sensor wires (the black and white ones) are
backwards.

On Tue, Apr 9, 2019 at 10:10 AM Penn1337 [e-mail] wrote:

Hey guys I'm having an issue with the BLTOUCH V3. I've been working on
this what seems like weeks now and I'm stumped. I've tried lots of things
including multiple working configs for marlin 2.0bug fix. I've got a ender
3 and I've hooked everything up and when I start the machine up the bltouch
just flashes at me. If I run the sw deploy it goes red and I can reset it
and then the error goes away. I've made a couple YouTube videos showing the
problems I will link them. The only thing i think i havent done is take the
c7 cap out.

The bltouch will self test just fine with 1.1.9 but wont stop the z axis.
I think I'm beyond frustrated. I initially thought bltouch was bad so I got
a replacement as well as my pin 27 board. The bltouch unit is getting 4.92
volts. The weird thing is that if i plug my PC in the bltouch starts right
up and does themself test. With the PC plugged in it gets 4.62 volts.

Here are the links to the videos. Sorry for the crappy quality. Any help
would be great because I've been banging my head against the wall for a
couple weeks now.

Watch "BLTOUCH not stopping when probing." on YouTube
https://youtu.be/Q96Zg1Ij-Pc

Watch "BLTOUCH V3 ENDER 3 Problem" on YouTube
https://youtu.be/6x0KWZ_wUt4

Watch "Ender 3 BLTOUCH V3 error" on YouTube
https://youtu.be/4JTLYnWoako

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

[Penn1337]

Hey Casey the probe works and stops the z axis I just thought I had an issue because on startup the touch will just flash. But if I plugged my PC in and ran off that power it would self test just fine. Just thought it was kind of weird but thanks for the input. I will check it out. Thanks again for the help!!!

[caseyjmorton]

Oh, yeah. Mine actually does that too. It doesnt seem to really affect
anything but once it does the first z-home, it stops flashing, or at least
mine does. No worries!

C

On Tue, Apr 9, 2019 at 11:55 AM Penn1337 [e-mail] wrote:

Hey Casey the probe works and stops the z axis I just thought I had an
issue because on startup the touch will just flash. But if I plugged my PC
in and ran off that power it would self test just fine. Just thought it was
kind of weird but thanks for the input. I will check it out. Thanks again
for the help!!!

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

[StevenP94]

I have a v2 and mine does the same: flash at startup. Maybe there is something wrong on initialization ? I have a 32bit ruramps4d. Startup was fine with the old ramps1.4 board. Maybe something related with a faster init ?

[mad-bee]

I've stumbled on this thread after spending last weekend trying to get a bltouch 3 working on an Ender 3. I currently have it working using 1.1.x bug fix version, which includes the #define BLTOUCH 3 line.

I'm a bit confused now though since the above suggests only Marlin 2.0 should work.

Just thought I would mention in case it is any use for you to know that I have 1.1.x working.

Happy to post any further details.

[kb79000]

Hello which version do you use?

[mad-bee]

I am using the bugfix 1.1.x version downloaded from the Marlin website on Sunday.
I used the Ender 3 configuration files in the downloaded zip file and followed the changes listed in the AnCLABS Bltouch version 3 manual. Uploaded firmware via ICSP.

I previously tried the version on the creality website ( I bought the creality branded kit for bltouch so was trying to follow their instructions). I then tried marlin 1.1.9. All of these initial attempts yielded the same problems described above.

With bugfix 1.1.9 it works. Currently using a 5 by 5 grid....got the smoothest first layer I have ever seen.

[GilLarose]

@paulpenney @InsanityAutomation
Good morning guys it has been over a week, do you have any good news for the CR10S PRO and the BLTouch 3.0 ver.

[paulpenney]

UPDATE -

I have received an update from Paris at ANTCLABS. She seems to believe that it is not a firmware issue and is in fact a hardware issue. The good news is that they have modified the firmware on the device for an increased amperage output and seem to think that this will solve the issues plaguing the original V3.0 devices. I will be receiving these on the 15th and testing them immediately on older firmwares, older devices, the ender 3 / CR10S line / CR10SPro and reporting here as soon as I can.

[GilLarose]

@paulpenney
Thanks Paul

[caseyjmorton]

Assuming everything tests out OK, has Paris given any indication of what
the recourse will be for those with the original 3.0s?

C

[paulpenney]

Assuming everything tests out OK, has Paris given any indication of what the recourse will be for those with the original 3.0s? C
…

No she hasn't mentioned it yet. I am hoping things will be made right with affected customers. I'll talk to her after we have confirmed functionality.

[mad-bee]

UPDATE -

I have received an update from Paris at ANTCLABS. She seems to believe that it is not a firmware issue and is in fact a hardware issue. The good news is that they have modified the firmware on the device for an increased amperage output and seem to think that this will solve the issues plaguing the original V3.0 devices. I will be receiving these on the 15th and testing them immediately on older firmwares, older devices, the ender 3 / CR10S line / CR10SPro and reporting here as soon as I can.

Thanks for your work on this. As I note above, it seems to be working on my Ender 3. Judging by the above this seems surprising... should I be expecting problems further down the line do you think?

[paulpenney]

Not if you used Marlin V2.0 - the ender seems to be working with that build. If its working though I wouldn’t worry about it!

[InsanityAutomation]

That definitely explains the inconsistent results I've been seeing. If the new ones perform better, may just need to note the resistor fix for the particular batch and move on.

[mad-bee]

Assuming everything tests out OK, has Paris given any indication of what the recourse will be for those with the original 3.0s? C
…

No she hasn't mentioned it yet. I am hoping things will be made right with affected customers. I'll talk to her after we have confirmed functionality.

Sorry but I'm not quite familiar with how the versions are branched. I have used the bugfix 1.1.x version...which includes a bltouch v3 option. Does this implement the same changes as version 2?

[InsanityAutomation]

The changes in 2.0 are more comprehensive than what's in 1.1.x

[GilLarose]

@InsanityAutomation
when you say move on I hope your not talking for the CR10S PRO BECAUSE NOTHING works for that particular printer....... resistor.....new firmware..... nothing

[InsanityAutomation]

@GilLarose I had one working here with the resistor and current firmware branch on my GitHub - I'll try a few more sensors on it and see if any still exhibit issues. Which firmware branch are you using with no luck atm?

[GilLarose]

@InsanityAutomation @paulpenney
I followed exactly the video on youtube by Jason from 3D Printing Canada A MONTH a go with the firmware DWINSET TEST as Jason suggested for the CR10S PRO
and flashed the main board and the LCD board shown on the video

https://www.youtube.com/watch?v=PLKEhdznVMY

Now (today April 11 2019) if you go on that Youtube video.... 3D Printing Canada has changed the title by:
How to install a BLTouch v2.2 or older on a Creality CR-10s Pro.

because of all the bad review they receive from customers complaining about the ver 3.0 and hopefully stop the new costumers (buying the BLTouch ver.3) from installing that version on the CR10S PRO

[paulpenney]

@GilLarose Until the issues with the CR10 are worked out for good, you may just want to flash back to the original firmware / sensor instead of having your printer out of commission for more time. The latest creality firmware is here: https://www.creality3d.cn/creality3d-cr-10s-pro-p00253p1.html

Try 1.60.71 for the firmware and the board. You can keep the BLtouch wires where they are and just swap it on when the issues are resolved.

[InsanityAutomation]

Do you have B5 or B6 shown in the info menu?

[juliandroid]

@paulpenney Do you have an information how to perform firmware update of the BLTouch 3.0 (I have Arduino Uno, if this board can be used as programmer)? Also thanks for the updates and I hope Paris from ANTCLABS will give you information for the current users of the BLTouch 3.0 - I have one still lying around and waiting for proper setup with CR10s Pro or return to them. If you know what Paris recommends in our case, please write here :)

@InsanityAutomation you said before, you are going to test your CR10s Pro and if I understand correctly, your CR10s Pro works by adding 1k resistor on the cable and DWinTest branch (i.e. NOT the Marlin 2.0 based one), right? Nothing more? And works consistently, not failing every other print/bed calibration?

[paulpenney]

@paulpenney Do you have an information how to perform firmware update of the BLTouch 3.0 (I have Arduino Uno, if this board can be used as programmer)? Also thanks for the updates and I hope Paris from ANTCLABS will give you information for the current users of the BLTouch 3.0 - I have one still lying around and waiting for proper setup with CR10s Pro or return to them. If you know what Paris recommends in our case, please write here :)

Depends on what printer you have.

[mad-bee]

@InsanityAutomation @paulpenney
I followed exactly the video on youtube by Jason from 3D Printing Canada A MONTH a go with the firmware DWINSET TEST as Jason suggested for the CR10S PRO
and flashed the main board and the LCD board shown on the video

https://www.youtube.com/watch?v=PLKEhdznVMY

Now (today April 11 2019) if you go on that Youtube video.... 3D Printing Canada has changed the title by:
How to install a BLTouch v2.2 or older on a Creality CR-10s Pro.

because of all the bad review they receive from customers complaining about the ver 3.0 and hopefully stop the new costumers (buying the BLTouch ver.3) from installing that version on the CR10S PRO

The ANTCLABS website has also been updated to distinguish between bltouch made in March and those made since early April (which presumably have some form of fix). The site also now mentions removing capacitor c7 from the ender 3 board.

My concern is that the March 2019 version becomes unsupported in future firmware updates.

Thus is not a fault with Marlin or its developers.....ANTCLABS must assist those with a March 2019 bltouch version 3. The current website creates the impression they will be cut loose.

[InsanityAutomation]

I haven't finished porting the touch screen to 2.0 yet, so correct the b6 build of 1.1.9 for the machine. Hoping to have more time messing with it this weekend.

[juliandroid]

Depends on what printer you have.

@paulpenney I have CR10s Pro.

[paulpenney]

Depends on what printer you have.

@paulpenney I have CR10s Pro.

I don't know of a reliable fix yet. In development.

[GilLarose]

@paulpenney Thanks Paul the only problem I did sort of try to reinstall the original firmware but I don't know exactly how to do it in Simplify 3D.... do I need to install Cura to reinstall the creality firmware or is there another way....

@InsanityAutomation this is what I see on the menu display

[paulpenney]

@paulpenney Thanks Paul the only problem I did sort of try to reinstall the original firmware but I don't know exactly how to do it in Simplify 3D.... do I need to install Cura to reinstall the creality firmware or is there another way....

I would install cura 4.0.0 - I'm a simplify3d user as well but have a copy on hand just because. Flashing with cura is easy - you connect it and then flash the hex in the machine profile

[GilLarose]

@paulpenney @InsanityAutomation
Thank you Paul, we may seem complaining at times on this blog about this issue but..... thank you for your hard work and understanding.......
sincerely Gil jr.

[InsanityAutomation]

B6 should have the updated code for it. Are you on discord to run through a few things this weekend sometime?

[GilLarose]

@InsanityAutomation
are you talking to me for the run through

[GilLarose]

@InsanityAutomation
are you talking to me for the run through

[GilLarose]

@InsanityAutomation
are you talking to me for the run through

[InsanityAutomation]

@GilLarose yeah, need to find out what's repeatable on it if there's still chances of stuff not working!

[StreckerCM]

@InsanityAutomation I have had a few good prints but I have been swamped and not been able to test it. I am going to solder my resistor this weekend to see if it makes it more consistent. I am wondering if the occasional probing failures I get are possibly from a weak connection.

If there are two versions of the V3 now has anyone contacted ANTCLABS about an exchange?

[ghost]

Here is my take on the current situation:

Looking at the ANTClabs website, one can see that there is now a
V3.0 pre April 5 2019, and one after April 5 2019.

You can find out if you have an old one or a new one via the QR code on the circuit board.

I wonder why one couldn't have called the new one V3.1, but I suppose things needed to be done very quickly in software only, so no chance to modify the circuit boards.

When comparing the two manuals, the only difference that can be seen is this:

V3.0 pre April 5, 2019
※ 5V Logic Zmin(140°) for unusual board : H Signal is very weak( Not recommended for general board)

V3.0 after April 5 2019
※ 5V Logic Zmin(140°) for unusual board : High Signal is not weak. Stronger than V2.x(Smart V3.0 produced since April 5th, 2019)
☞ For example, Board with large capacity capacitor in end-stop input circuit(Melzi and some of the Creality3D, ANET board, etc.)

If you look that their recommendation for the Marlin configuration, the GENERAL recommendation is still to use the V3.0 in the default mode ( = OPEN DRAIN ) and to ensure that you have enabled the PULL-UPs in the MARLIN config.

Here is their recommendation from their manual (and they specifically refer to Marlin Bugfix-2.0.x):

#define ENDSTOP_INTERRUPTS_FEATURE 
#define ENDSTOPPULLUPS                         // BLTouch Smart V3.0 and Later  
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define BLTOUCH 
#if ENABLED(BLTOUCH) 
   #define BLTOUCH_V3
   #if ENABLED(BLTOUCH_V3)
   //#define BLTOUCH_FORCE_5V_MODE            //for 5V logic
     #define BLTOUCH_FORCE_OPEN_DRAIN_MODE   // default : Logic Voltage Free
   #endif 
#endif 

Note that this goes against the recommendations of @insanityautomation, in that up to now the MARLIN path was to use #define BLTOUCH_FORCE_5V_MODE instead, to ensure a good pull-up situation on the V3.0 pre April 5 2019 version, which has a "weak H-signal".

---

Here is the decision logic when you proceed:

If you have a V3.0 PRE APRIL 5 BLTOUCH:

It might work if configured as a "BLTOUCH" in older versions of Marlin, ones before the V3.0 fix about a month ago. These know nothing about a V3.0 but they might work anyway because the V3.0 default is OPEN DRAIN and the controller board has no "bad" circuitry modifying the pin input and you have pull-ups enabled.

Otherwise try the 1K resistor solution mentioned above AND/OR the Bugfix-2.0.x Marlin that contains the V3.0 fix (i.e. it knows the parameter #define BLTOUCH_V3). It very very probably will then work.

Unless you have a CR 10s-Pro - which still seems to be posing some problems, but this is not totally sure at this moment.

If you have a V3.0 AFTER APRIL 5 BLTOUCH:
It might work if configured as a "BLTOUCH" in older versions of Marlin, ones before the V3.0 fix about a month ago. These know nothing about a V3.0 but they might work anyway because the V3.0 default is OPEN DRAIN and the controller board has no "bad" circuitry modifying the pin input and you have pull-ups enabled.

Otherwise, use the Bugfix-2.0.x Marlin that contains the V3.0 fix (i.e. it knows the parameter #define BLTOUCH_V3). It very very probably will then work. No need to try the 1K resistor solution, as this BLTouch version has a stronger pull-on on the logic output anyway: But if the ANTClabs parms of #define BLTOUCH_FORCE_OPEN_DRAIN_MODE do not work, try using #define BLTOUCH_FORCE_5V_MODE instead, as recommended by @InsanityAutomation

---

I personally remain convinced of using the default mode of OPEN DRAIN and a clean input circuit (I am lucky with my controller board), ENDSTOPPULLUPS defined - works out of the box.

[InsanityAutomation]

Because most of my testing was on the boards they specify as needing the 5v drain! The formbot boards and raise 3d board we're both fine in open drain mode.

[ghost]

@InsanityAutomation Yo, of course. Just trying to sum up this Mega-Thread.

[GilLarose]

@InsanityAutomation
ill try to be near the printer, Sunday is better for me...... so before i reinstall the creality original firmware I should wait for you to try some stuff..... right....

[InsanityAutomation]

@FanDjango I know, just figured it was ironic they called out most of what I tested with in their note on when to use 5v .

[sgsalman]

So, I have pre 5th April V3, what will I do exatly?

what is the exact solution?_

[mad-bee]

Write to ANTCLABS and complain!

On Fri, 12 Apr 2019, 18:33 sgsalman, [e-mail] wrote:

So, I have pre 5th April V3, what will I do exatly?

what is the exact solution?_

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-482658802,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AvFqzwWV4WiyXH7I37dlZKzu4lmRf6tqks5vgMNtgaJpZM4bmrEd
.

[paulpenney]

I’Ve received the newest units and will be be testing them as stated above. After the problem has been concerned solved I am going to get the answer fro, Paris. I couldn’t see her keeping her customers high and dry.

Sent from my iPad

On Apr 12, 2019, at 1:33 PM, sgsalman [e-mail] wrote:

So, I have pre 5th April V3, what will I do exatly?

what is the exact solution?_

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[InsanityAutomation]

@paulpenney Theyre due later today here according to the latest from DHL. Hopefully ill have good results with em on the 10SPro without resistors this weekend!

[paulpenney]

Not if I beat you to it ;)

Sent from my iPad

On Apr 12, 2019, at 1:38 PM, InsanityAutomation [e-mail] wrote:

@paulpenney Theyre due later today here according to the latest from DHL. Hopefully ill have good results with em on the 10SPro without resistors this weekend!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[StreckerCM]

@paulpenney I have emailed ANTCLABS twice using the email on the website. Once on March 26th and I followed up yesterday. Neither has gotten a response yet.

[mad-bee]

Similarly. Some form of acknowledgement would be appreciated ...if anyone
from ANTCLABS is reading this.

On Fri, 12 Apr 2019, 18:41 Christopher Strecker, [e-mail]
wrote:

@paulpenney https://github.com/paulpenney I have emailed ANTCLABS twice
using the email on the website. Once on March 26th and I followed up
yesterday. Neither has gotten a response yet.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-482661295,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AvFqzy9kqpuU4w0m-BRsOGVNAGeeazJJks5vgMU7gaJpZM4bmrEd
.

[GilLarose]

@StreckerCm
same here no repond from Antclabs

[ghost]

Meanwhile, I have been doing some testing with mine.

This concerns the Bugfix-2.0.x Firmware with the current support for V3.0 BLTouch (pre AND after April 5, 2019) (commit by @InsanityAutomation nearly a month ago by now)

The BLTouch V3.0 has a new mode called "SW" mode. This should be read as "SWITCH" mode - meaning that instead of a 10ms pulse, it produces a continuous output until a STOW command resets that,

@InsanityAutomation's V3.0 code, which you get if you #define BLTOUCH_V3, WILL automatically set this mode to active on every DEPLOY.

What does this mean for us? Well, two things:

Firstly, there is no worry about the 10ms timing and thus a capacitor on the pin will not cause the 10ms window to be missed. The "high level" output will stay long enough on the pin to be recognized. As long as the high level is "high" enough to be seen (that's the CR 10s Pro problem).

Secondly, this means you can now check the functioning of the probe with M119. How? Easy: Go into the lcd menu configuration, BLTouch and then hit DEPLOY. Do a M119 and verify that z-min is not triggered. Push up the pin (and verify that the red light goes on and the pin STAYS up - on a pre V3 probe or a firmware that does not set SW mode the probe comes back down after a moment after being pushed up). And then verify with M119 that z-min is now TRIGGERED. You can hit STOW for the probe and then check M119 again - no longer triggered.

If you can verify that the pin stays up after pushing it up - then you know the new firmware is doing its thing. And then if M119 does NOT show TRIGGERED, you might be on the wrong input pin (possible), or you might need the 1K resistor after all (not probable).

If you have not #define BLTOUCH_V3 correctly, this will not work. You can DEPLOY, but pushing up the probe will red light for a moment and the pin will come back down, M119 will not catch the short pulse. And the lc menu configuration for BLTouch will be missing the new functions.

[mtwomey]

Just following up on my earlier question in this comments thread - I can confirm that my ramps 1.4 based Prusa i3 worked "out of the box" with the BLTouch Smart v3 which I received the other day from Amazon. Running on unmodified 1.1.9 release with no modifications.

[ghost]

@mtwomey Conversely, without the new firmware that means you are running the V3.0 probe in the following mode:

OPEN DRAIN mode (default)
This is different from the pre V3 probes but you have got the ENDSTOP_PULLUPs doing their thing

PULSE MODE (and not SW MODE)
Just like the pre V3 probes

Your input pin on your controller is "clean" enough not to mangle the pulse or lower the logic-high level so you don't need SW mode and don't need a 1K resistor

[InsanityAutomation]

@FanDjango Good summary of the fun!

@mtwomey Matches the formbot boards as well! A few are lucky but not all :(

[Bob-the-Kuhn]

I just received some new strong drive BLTouch V3.0 units. In the 5V mode the output high driver impedance is about 50 Ohms. Plenty of muscle.

Still defaults to open drain (no surprise) but at least an external pull up resistor is no longer needed.

[caseyjmorton]

So reading between the lines, at least on the ender 3 and other melzi
machines, it will still not run without the BLTOUCH_V3 setting, right?

C

On Fri, Apr 12, 2019 at 6:32 PM Bob Kuhn [e-mail] wrote:

I just received some new strong drive BLTouch V3.0 units. In the 5V mode
the output high driver impedance is about 50 Ohms. Plenty of muscle.

Still defaults to open drain (no surprise) but at least an external pull
up resistor is no longer needed.

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

[Bob-the-Kuhn]

Correct.

Since it still defaults to open drain then any system that needed an external pullup would need to use the following settings:

  #define BLTOUCH_V3
  #if ENABLED(BLTOUCH_V3)
    #define BLTOUCH_FORCE_5V_MODE
    //#define BLTOUCH_FORCE_OPEN_DRAIN_MODE
  #endif

[Roxy-3D]

I just received some new strong drive BLTouch V3.0 units. In the 5V mode the output high driver impedance is about 50 Ohms. Plenty of muscle.

I got a DHL package as well. The new 'v.3.0' probes work better.

[RobBott]

Are there any updates to this for the Creality CR-10s Pro? Just went through the whole process of the upgrade to run into this issue. I have the latest firmware with the v3.0 code. I have not modified anything in the firmware except for uncommenting line 93.

[InsanityAutomation]

I just closed my laptop from poking at the 10spro... 1am here... More tomorrow.

[ghost]

@InsanityAutomation What does your M119 say when you push up the pin after manually deploying it? Does it stay up? If it stays up and M119 doesn't read a triggered, (of course, 5V Mode defined?) then something is fishy - back to the oscilloscope?

[paulpenney]

UPDATE - I have tested the BLtouch V3.0 with the updated April firmware on a CR10S Pro and @InsanityAutomation latest DWIN_TEST. I am pleased to report this combination is finally working properly and consistantly on this end - no false readings, plungers not extending, or other anomalies. My only feedback for @InsanityAutomation is that a way needs to be found around the 'reset' that seems to happen before every homing move (pin moves up and down 4 times or so before it finally extends for homing).

I have emailed Antclabs and asked them to replace the units we have in stock currently with updated ones in exchange for the March firmware versions. Then we will reconcile with affected customers. I'll post the jist of her response when I receive it.

[Bob-the-Kuhn]

@FanDjango

The BLTouch V3.0 has a new mode called "SW" mode.

Does M280 P0 S60 put the unit into this mode? If yes then V2 also has it.

[ghost]

@Bob-the-Kuhn Arrrgh! I just checked the V2.0 "manual" and yup, you are right - that feature has been there all the time and could have been used, thus making the 10ms window and capacitor charge-up less of an issue. I didn't see it, sorry.
Looking at the code... Apart from the the fact that "clones" might misinterpret unknown servo-angles (or do the clones also have a SW mode), shouldn't we perhaps add a define to allow "forcing SW mode" even if V3 is not defined? But on the other hand, if you have a V2 and are having problems, it probably won't hurt to lie and to define it as being a V3. Hmmmm.....
How much complexity would one want here whilst only a minority are having problems at all?
Talking about this part:

[InsanityAutomation]

@paulpenney Ive been playing with it a bit. Thats part of the self test and error detection sequence. Needs to get it out of switch mode, test, then back to switch mode. Im not sure its safe to eliminate tbh.

[Roxy-3D]

I've been checking out the 60 degree "Alarm Release & Touch SW" mode...

I'm thinking we should use that mode when probing with a BL-Touch. It makes it a lot easier for people to check out their probes and verify the end stop wires are correct with M119.

[juliandroid]

and could have been used, thus making the 10ms window and capacitor charge-up less of an issue. I didn't see it, sorry.
Looking at the code... Apart from the the fact that "clones" might misinterpret unknown servo-angles (or do the clones also have a SW mode), shouldn't we perhaps add a define to allow "forcing SW mode" even if V3 is not defined?

@FanDjango Correct me if I'm wrong, but if you don't have that 50ohm impedance provided by 5th April revision then charging the capacitor (on board like CR10s Pro) will take a lot more time, so the Z will continue to travel further down to the bed even that the sensor already reported the 0 level. Also having that capacitor loaded that slow will mean also less accuracy on average?

[ghost]

@juliandroid Yes, charging will take more time, therefore the nozzle will travel a few steps further down, depending on the size of the capacitor ( -> slope of the rising voltage on the pin ) and depending on the speed of your probing.
You can calculate the time using the RC formula, you can calculate the distance using the homing/probing speed (mm/s) and you can move the probe down by a millimeter if you really must or you can probe slower. I have never needed to do this.
Since the charge is the SAME, EACH TIME you probe, subsequent probe actions will ALL reflect this deviation from a trigger point with no capacitance. Remember that the capacitor will discharge easily before the next probe action.
The accuracy question thus only relates to the question of repeated triggering on a steep slope or on a slope with lower gradient. I offer no current data on that, but as long as the slope is not nearly flat (huge capacitor) I see no real problem.
Please note that there is an advantage to having the capacitance on the pin, in that there are some users who would otherwise be susceptible to noise on the signal (*1) - those with a direct extruder stepper motor on the same cable harness as the probe signal cable, for example. In the same vein, the probe repeatability test definitely will show up better values if you turn off the nozzle heater pwm while probing to reduce noise.
If your power supply or cabling is flaky, turn off the bed heater pwm also. These influence the accurancy of a probe trigger much more than a slightly less steep slope on the signal.

(*1) The "noise" issue is referred to somewhere to the top of this huge issue #13128

[ghost]

@Bob-the-Kuhn

50 Ohms. Plenty of muscle

Hope you didn't watch the 100mA for too long because we have every reason to believe that is a ATTINY output pin (max 40mA) :-)

[Bob-the-Kuhn]

It was calculated. I measured the voltage across 1.2k, 2.0k and 10K resistors tied between ground & signal. The difference in voltage divided by the difference in current between any two pairs gives an average of the series impedance of the driver.

[juliandroid]

@FanDjango That was the reason to be resistant of adding resistor and also to not be happy with the recommendation of Antclabs to remove the cap on the motherboard. The claimed precision of 0.005mm won't be possible (as people reports now) with that large cap and weak signal without special compensation in Marlin.
It is obvious that BLTouch should be the one compatible with different printers and Antclabs not to expect that Creality will make their printers compatible with them, when their printers are with capacitive sensors. A good generic solution here would be the cap to be charged as fast as possible independently of its general value, so the time to charge to be insignificant, instead of hacking Marlin to compensate the Z travel depending of the printer-cap-sensor combination :)

What I've ordered two weeks ago is "Copper Shield Sleeve" which I plan to put inside the standard "PET Cable Sleeve" and ground the first one to reduce the interference through that 2m flat cable.

[Bob-the-Kuhn]

I found out why V3 switched to open drain as the default. They were afraid that 5V would damage 3.3V CPUs.

I've pointed out that there is lots of information that says this is very rare to non-existent. I also suggested that they make the 3.3V mode the default.

[ghost]

Har har. Thought so.
14 days ago I wrote:

the old output stage, 5V logic level had two disadvantages: a). Need to cut a trace to change to 3.3V logic (even older probes: you absolutely needed some resistors) b). Can potentially destroy an input pin on a non-5V tolerant processor/controller board

Not getting tired of reiterating: OPEN DRAIN is safe and allows the implementer his own choice of how much pull-up he needs to counter filtering components on the input pin. I am on ANTClabs side here when considering possible damage claims :-(. Sure enough most boards I know of are 5V tolerant, but I don't know if ANTClabs is also delivering OEM-wise to wherever this might be an issue.

Kudos to @InsanityAutomation for a quick and working solution, but the current code goes into 5V mode without really good control by the user, based on some other defines (like ENDSTOPPULLUPS etc.). It is not well documented what will cause 5V mode (see the code). Not really happy with that, better to be in OPEN DRAIN mode (and even if that does not work) than in 5V mode by mistake in the (rare) case where this might be detrimental. And then give the user full control.

    #if ENABLED(BLTOUCH_V3)
      #if ENABLED(BLTOUCH_FORCE_OPEN_DRAIN_MODE)  // Set OPEN DRAIN mode if explicitely demanded
        set_OD_mode();
      #elif ENABLED(BLTOUCH_FORCE_5V_MODE)        // Set 5V mode if explicitely demanded
        set_5V_mode();
      #else
        set_5V_mode();                            // If no explicit setting requested, choose 5V mode 
                                                  // to be compatible with pre-V3 probes
      #endif

And let's bring in full control of the SW mode as well (sigh, another new define for configuration.h):

    // BLTouch pre V3 and clones will "drop" down again after being triggered and having
    // issued a 10ms pulse. The trigger STOW (see motion.cpp for example) will pull up 
    // the probe as soon as the pulse is registered.

    // The BLTouch V3 (and V2) can be set to "SWITCH" mode. When triggered, instead of a 10ms
    // pulse, there is an indefinetly long trigger condition, until reset by the STOW as
    // soon as this "very very long" pulse is registered.Also, the probe stays pulled up. 
    // It doesn't "drop" down again after being triggered. The STOW is still needed to reset
    // the triggered condition.
    #if ENABLED(BLTOUCH_V3) \
        || ENABLED(BLTOUCH_FORCE_SW_MODE)         // V3 should always use SW mode
                                                  // or, if explicitely requested (maybe a V2 probe?)
      set_SW_mode();
    #endif

I have got a PR ready for a this approach but am still a bit daunted because this show is more or less not something for a newbe like me and I don't want to piss off anyone.

[Roxy-3D]

Not really happy with that, better to be in OPEN DRAIN mode (and even if that does not work) than in 5V mode by mistake in the (rare) case where this might be detrimental. And then give the user full control.

I think I agree with this... How about we only go into 5 volt mode if the user has explicitly enabled the BLTOUCH_FORCE_5V_MODE option? Even if they have a 5 volt platform... It should work in most cases with the probe at 3.3 volts.

[ghost]

Well @InsanityAutomation has a very valid point in saying that the naive user just wants it to work like the old probe, or if he had a different probe before (capacitative or inductive or plain switch), in that case he would have been configured as ENDSTOPSPULLUPS turned on, which is indicative of wanting 5V mode. But don't forget, because we were more or less really only focusing on the fails of different CR printers, that needed 5V mode in ADDITION to the ENDSTOPPULLUPS to work at all. And that approach would also work for the users of other printers.
You will agree that the current solution works fine. It is just not "according to the book", somehow.

[juliandroid]

Also don't forget manufacturers. For example Creality sells BLTouch kit and nobody knows how long it will take for them to release official support for BLTouch V3.0, so if user happily uses their firmware with BLTouch V2.x and then buy a V3.0 as replacement then nothing works anymore out of the box.

For me it is clueless why ANTCLabs broke the compatibility with V2.0 for no reason. There are cheap logic level-shifters, bi-directional that would happily convert 5V/3.3V depending on the power voltage. In Ali you can buy a set of 5 boards for retail price of 1 USD.

[caseyjmorton]

FWIW I heard reports on Reddit that Creality is supposedly shipping V3s as
well. Not sure how much validity there is to the report though.

C

On Sun, Apr 14, 2019 at 5:39 PM juliandroid [e-mail]
wrote:

Also don't forget manufacturers. For example Creality sells BLTouch kit
and nobody knows how long it will take for them to release official support
for BLTouch V3.0, so if user happily uses their firmware with BLTouch V2.x
and then buy a V3.0 as replacement then nothing works anymore out of the
box.

For me it is clueless why ANTCLabs broke the compatibility with V2.0 for
no reason. There a cheap logic level-shifters, bi-directional that would
happily convert 5V/3.3V depending on the power voltage. In Ali you can buy
a set of 5 boards for retail price of 1 USD.

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

[mattgrimley]

FWIW I heard reports on Reddit that Creality is supposedly shipping V3s as well. Not sure how much validity there is to the report though. C
…

I can confirm that the "official" creality kits are shipping with v3.0 BLTouch's. Received mine yesterday and spent most of today finding my way to this thread!

[caseyjmorton]

Glad word is getting out quickly about this issue. I screwed around with
it for 2 weeks.

On Sun, Apr 14, 2019 at 6:40 PM Matt Grimley [e-mail]
wrote:

FWIW I heard reports on Reddit that Creality is supposedly shipping V3s as
well. Not sure how much validity there is to the report though. C
… <#m_-1903683907704834257_>

I can confirm that the "official" creality kits are shipping with v3.0
BLTouch's. Received mine yesterday and spent most of today finding my way
to this thread!

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

[Roxy-3D]

So Creality is shipping Z-Probes they never bothered to check to see if they worked with their machines?

[caseyjmorton]

Not surprising. In their defense, on Amazon there was no indication mine
being a different version, even though ANTCLABS was the seller.

On Sun, Apr 14, 2019 at 6:54 PM Roxy-3D [e-mail] wrote:

So Creality is shipping Z-Probes they never bothered to check to see if
they worked with their machines?

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

[mattgrimley]

So Creality is shipping Z-Probes they never bothered to check to see if they worked with their machines?

Yep. I even just tried the firmware they suggest in their official guide. That doesn't seem to have any BLTouch recognition at all. Where the Th3d firmware displayed issues similar to those in this thread, the "official" creality firmware did nothing other than home with the probe Off the bed and then hit the endstop on the z until i switched it off.

I'll be reflashing my bootloader and giving Marlin 2.0 Beta a crack tomorrow :) - But brace yourselves for an influx of newbies like me finding this thread!

[caseyjmorton]

At this point we should probably move this discussion to a forum somewhere.

On Sun, Apr 14, 2019 at 7:41 PM Matt Grimley [e-mail]
wrote:

So Creality is shipping Z-Probes they never bothered to check to see if
they worked with their machines?

Yep. I even just tried the firmware they suggest in their official guide.
That doesn't seem to have any BLTouch recognition at all. Where the Th3d
firmware displayed issues similar to those in this thread, the "official"
creality firmware did nothing other than home with the probe Off the bed
and then hit the endstop on the z until i switched it off.

I'll be reflashing my bootloader and giving Marlin 2.0 Beta a crack
tomorrow :) - But brace yourselves for an influx of newbies like me finding
this thread!

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

[Roxy-3D]

For historical reasons... It is good to have the full context of what ever gets decided here.

[caseyjmorton]

True but I don't want this IMHO this should not be used as a support
thread.

On Sun, Apr 14, 2019 at 7:51 PM Roxy-3D [e-mail] wrote:

For historical reasons... It is good to have the full context of what ever
gets decided here.

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

[Roxy-3D]

We are discussing architectural issues. The developers are working together in this thread to resolve questions such as "should we default the probe to 5 volts or 3.3 volts?". Or "Should we change the probing to use Switch mode where possible?"

Right now... a few 'support' questions sneaking into the discussion are not unwelcome. They actually help us understand if we have all the bases covered.

[caseyjmorton]

Fair enough 😁

On Sun, Apr 14, 2019 at 8:10 PM Roxy-3D [e-mail] wrote:

We are discussing architectural issues. The developers are working
together in this thread to resolve questions such as "should we default the
probe to 5 volts or 3.3 volts?". Or "Should we change the probing to use
Switch mode where possible?"

Right now... a few 'support' questions sneaking into the discussion are
not unwelcome. They actually help us understand if we have all the bases
covered.

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

[GilLarose]

@paulpenney
Hello Paul........ couple of question for you for the test you did on the CR10S PRO this weekend and the BLtouch ver.3.xxx you received from Paris (Antclabs)
-when you tested the new BLtouch, did you keep a 1k resistor between the white and red wire.
-other than testing the homing and auto leveling with the new ver.3 did you print something to see if it was still ok
-if all is good do i have to send you back to (3D Canada Printing) my BLtouch ver.3 to get the version that does work.
-will you post a video (Youtube) to explain the hole process how to flash the firmware with the new ver. 3 updated in April

sincerely Gil jr.

[Sander71]

Newbe here,

Can also confirm that creality is sending v3.0 in their kit. AND i got a replacement kit (also containing v3.0) when reporting this issue. Meaning they are NOT aware of this issue with the v3s at all.

[paulpenney]

Oh Creality.

Paris has gotten back to me and ANTCLABS has agreed to send us updated units in exchange for March manufactured units. We will then be working with our customers to get them exchanged if they are installing them on an affected machine once we receive them. This is primarily the CR10SP. I tested and was satisfied with the homing and auto levelling on that machine with the BL touch.

Sent from my iPhone

On Apr 15, 2019, at 7:20 AM, Sander71 [e-mail] wrote:

Newbe here,

Can also confirm that creality is sending v3.0 in their kit. AND i got a replacement kit (also containing v3.0) when reporting this issue. Meaning they are NOT aware of this issue with the v3s at all.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[juliandroid]

10 days ago I've ordered the kit from Creality with the idea to replace V3.0 with advertized V2.x, so obviously when the kit arrives I'll have 2 x V3.0.

The way ANTCLabs didn't let me in advance that they will sells me a new incompatible and unannounced version, I guess the same way they ship the new V3.0 to Creality too.

Paris promised "I will update the BLTouch software", but does she supposed to send a hex file to update or I have to send my two BLTouch sensors remains mystery.

Not to mention the expenses and time spent on Customs for that package.

[StreckerCM]

@paulpenney @InsanityAutomation Even with the 1K resistor I am still getting probe failures about 25% of the time with the V3. I made a little dupont cable jumper to put between the probe and the board with the resistor soldered to eliminate the possibility that it was just a poor connection.

I got a response form Paris requesting a bunch of information from me. I sent a lot of what I documented here so hopefully she will agree to replace my unit!

[tkroon]

All of this thread said, what's the best work around for this issue?

[StreckerCM]

@tkroon for the CR10S Pro the 1k resistor between the red and white pins works just not always consistent. If it fails you need to power cycle and try again.

[paulpenney]

@StreckerCM Precisely. I tried to get it working with the old version on the 10SP and would get very inconsistent results even with the resistor. New one performed nominally.

[InsanityAutomation]

@Roxy-3D we could also add definitions to pins files for open drain or 5v based on whats known working and known logic level. In my testing here, open drain worked but showed hesitation retracting many times. Just didnt function as smoothly on the same board as with 5v mode. If a board is not specified then we can let it keep the open drain. I would be setting the formbot boards to open drain and creality to force 5v mode for example.

[ghost]

Something on the order of IF ENABLED(BLTOUCH_V3) ..... #DEFINE BLTOUCH_FORCE.....xxxxx etc. ?
That's rather brilliant, actually.

[StreckerCM]

This was the summary of the response I got today from ANTCLABS it sounds to me like they are saying they are saying you need to buy the Creality BLTouch kit for it to work on Creality printers. So basically they supported it previously but now since Creality sells co-branded version they stopped with no announcement of this change?

Thank you for your kind explain.
I thought your CR-10S is for BLTouch, but it seems like the control board in your printer is not for BLTouch. Because we have announced that for using a board which one has a large capacitor in the end-stop input circuit (like Melzi board), users have to remove the capacitor, Creality is providing a different control board when they install BLTouch in their printer.
If your control board has a large capacitor in the end-stop, In this case, it is not a different issue as I told you at my last email.

[ghost]

I read it as: She thinks Creality uses a different board on printers they deliver with BLTouch already installed, as opposed to printers without the BLTouch already installed, those have an unsuitable controller board because of the capacitor.
But that's only what I think she thinks.... :-)
Ahem - perhaps the difference is that Creality remove the capacitor when delivering a printer with a BLTouch ready installed. And when you order one later as an add-on, it was no problem that you HAD the capacitor on your board until ANTClabs brought out the unhappy V3 pre April 5, which didn't like that approach.

[juliandroid]

The kit they sell is a BLTouch, long cable, programmer and mount adapter. I never seen on the market preinstalled Creality printer with BLTouch.
And from the feedback here, the kit also includes BLTouch V3.0 and as you said the capacitor is needed because of the noise.
Not to mention that warranty is gone with that modification. I don't understand how Antclabs can recommend such aggressive modification on the hardware of another company?

[ghost]

I never seen on the market preinstalled Creality printer with BLTouch.

Ok, so much for that conjecture of mine, scrap it.

Not to mention that warranty is gone with that modification. I don't understand how Antclabs can recommend such aggressive modification on the hardware of another company?

Ok, very good point.

Previous experience in CR (customer relations, lol, not Creality) tells me ANTClabs should get into direct contact with Creality ASAP if it is not happening already to clear up a number of issues and to decide how to handle V3 pre April 5 customers and make them happy.

Let's face it - I have not seen a single non CR BLTouch problem anywhere (not only here) in the past few days or is it weeks already.

One interesting point is that all of my probes work fine on the normal Marlin (pre-BLTouch V3 logic) - a V2.0, a V2.2, a V3.0preApr5 and a V3.0apresApr5. All of them. No problem. So if you were to ask me alone (and potentially many many silent others) there would be no need for specialised V3 logic in Marlin at all.

[StreckerCM]

@FanDjango @juliandroid

It wasn't in my original post because it was in the bottom of the email but Paris still recommends removing the cap even with the post April 5th version.

But even though you receive the new one, I really recommend you to remove the capacitor for using BLTouch well.

@paulpenney did you remove the cap when you did you testing on the new V3's?

[Roxy-3D]

https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-483337319

we could also add definitions to pins files for open drain or 5v based on whats known working and known logic level.

That would be a very safe way to proceed. We would have to edit every pins file... And we do have a problem with things like RAMPS where the board is normally 5 volt but is also used with 3.3 volt 32-bit microprocessors. With that said, even in that case... we have a Re-ARM version of the file and we could force it to 3.3 volts for that special case.

If we went this direction, the safest thing to do would be respect what ever is declared in the pins.h file. And if nothing is declared there, we default to Open Drain at 3.3 volts.

FanDjango has a good point: https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-483379937

One interesting point is that all of my probes work fine on the normal Marlin (pre-BLTouch V3 logic) - a V2.0, a V2.2, a V3.0preApr5 and a V3.0apresApr5. All of them. No problem. So if you were to ask me alone (and potentially many many silent others) there would be no need for specialised V3 logic in Marlin at all.

Pretty much... This problem is mostly focused on Creality machines... So maybe we want to resist adding a special 3.3 volt mode ?????

[ghost]

@StreckerCM I know she recommends that. But you know, technically if you are using the right Marlin Firmware that does turn on SW-Mode and your logic high level is satisfactory (thanks perhaps to a 1K resistor) it should work flawlessly repeatedly, albeit triggering a few tenths of a millimeter further down. One should perhaps concentrate on finding out what might be wrong in that it fails once in a while:

• Firmware being used is not the one actually needed (for whatever reason). Therefore SW mode is not becoming active. For that, to verify that, use the lcd menu to deploy, push up by finger action, see if it stays up. It should.

• Logic Level High is not high enough or it is high enough but there is spurious noise: Test the probe repeatability test M48 a lot of times instead. How often does it fail to probe? If it probes wonderfully 100 times, the problem is somerwhere else methinks, maybe noise from the nozzle heater?

Let's get to the bottom of this.

[ghost]

@StreckerCM Or if it triggers further down due to the capacitor, maybe you are on the edge of the limit where the probe needs to be mounted for it's travel/trigger. Consider lowering it by a millimeter with a washer, maybe?

[StreckerCM]

@FanDjango the trigger height on mine isn't bad it is the probing failure. I am using the Hero Me mount so I can adjust it easily up and down if needed. Paris said they will send me a Post April 5th V3 which according to @paulpenney works on the CR10S Pro as the V2 did.

However, you heater noise theory intrigues me because most of the probing failures that I have gotten after adding the 1K resister were when performing a G29 in the print gcode after preheating.

[ghost]

@StreckerCM Easy to check that out - just for once (or twice ;-) ) consider not heating until after the G29. Just to see if PID heater cable noise..... costs you nothing.

[ghost]

@StreckerCM The probing failure - you still don't mention if and for how often a M48 will go instead of the G29? Just really curious but don't hate me for being so stubborn :-)

[Roxy-3D]

The probing failure - you still don't mention if and for how often a M48 will go instead of the G29?

This is a very valid question to resolve. If there is electrical noise causing the failure, it isn't just how long an M48 runs before failure. We should also see it fail sooner and later. It would probably be wise to run the M48's with the nozzle heaters turned on to see if that makes the failures worse.

(and it would also be important to do the tests with BLTOUCH_HEATERS_OFF turned on and off...)

[juliandroid]

So, the alternative in open drain mode could be also to try smaller resistor let's 220 ohm, instead of 1k for faster cap charge? If I'm correct @Bob-the-Kuhn calculated that even up to 100 ohm could be OK.

The question is rather, why 1k which everyone with CR10s Pro reports to be not good enough is repeatedly proposed as solution?

[InsanityAutomation]

@juliandroid because its working with that on mine without an issue though I havnt run the same sensor for 100 cycles in a row....

[Roxy-3D]

The question is rather, why 1k which everyone with CR10s Pro reports to be not good enough is repeatedly proposed as solution?

You are dealing with two variables. With 30K ohms of output impedance, it is easy to super-impose (or pick up) electrical noise on the signal wire. If you have high current wires running right next to the signal wire for a 'long' distance... It maybe that 1K ohm isn't enough of a pull up to hide the noise.

My guess is 1K ohm is enough in many of the CR10 cases... But it is very marginal. We don't have enough data to know for sure on any of these guesses yet.

[ghost]

The question is rather, why 1k which everyone with CR10s Pro reports to be not good enough is repeatedly proposed as solution?

everyone is how many people according to current count?

Those that have still got a problem are not really providing enough data apart from G29 fails "once in a while".

Whoa betide you if you take a photo of your printer and we see an added on PWM LED light for the extruder carriage that causes 2V of noise on the cabling.

Seriously, help us find the cause. Provide more data beyond what has been there up to now.

Do a M48 with 100 probes. Probe G29 with heater off. Do a deploy and push it up. Stays up? Then M119 and see if it displays triggered. Repeat the M119 a hundred times, always triggered? Turn heater on, still triggered even after many tries?

Something must be different from @InsanityAutomation s machine. We can find it. At least, I would want to find it. Send me your printer, LOL

[Bob-the-Kuhn]

1K isn't a magical number. It's just one that looked like it would give a quick rise time (1/2 to 1 mS from trigger to logic 1) without pulling lots of current.

I see no danger in going as low as 470 Ohms.

[ghost]

@Bob-the-Kuhn I second that. 470 Ohms. To a certain degree that is doctoring the symptoms. Regardless, @juliandroid @StreckerCM if you have a 470R sitting there I suppose in your position I would try it. If it helps, one would know a little more about the cause of the problem.

[InsanityAutomation]

it may also be worth noting that my wiring for the bltouch is not tied up to the ribbon Cable in any way, it's floating completely separately. if you have done a clean wiring solution clipping it right to the ribbon nice and tightly without any shielding in between there's a good chance if there's a difference in noise coming from either of the steppers running through there. I've got a bunch of miscellaneous resistors floating around so I'll dig up a 470 and give that a try as well.

[StreckerCM]

@FanDjango I don't have anything on hand that isn't less then 1K. Paris said if i destroy my current one and send photos she will send me a new one. From what @paulpenney says the new V3 should work better. Would it hurt to leave the 1K resistor on the updated V3 or would that cause issues?

I wanted to try a repeatability test while cold and while heating but it failed the first to times while cold. And the readings were pretty consistent.

Send: M48 P50 X150 Y150 V2 E L2
Recv: M48 Z-Probe Repeatability Test
[...]
Recv: 1 of 50: z: -0.063
[...]
Recv: 2 of 50: z: -0.065
[...]
Recv: 3 of 50: z: -0.064
[...]
Recv: 4 of 50: z: -0.063
[...]
Recv: 5 of 50: z: -0.069
[...]
Recv: 6 of 50: z: -0.066
[...]
Recv: 7 of 50: z: -0.069
[...]
Recv: 8 of 50: z: -0.066
[...]
Recv: 9 of 50: z: -0.067
[...]
Recv: 10 of 50: z: -0.065
[...]
Recv: 11 of 50: z: -0.063
[...]
Recv: Error:STOP called because of BLTouch error - restart with M999
Changing monitoring state from "Operational" to "Error: STOP called because of BLTouch error - restart with M999"
Changing monitoring state from "Error: STOP called because of BLTouch error - restart with M999" to "Offline (Error: STOP called because of BLTouch error - restart with M999)"
Connection closed, closing down monitor

On the 3rd try I was able to get it to run while cold and got a pretty consistent result!

Recv: Finished!
Recv: Mean: -0.058300 Min: -0.063 Max: -0.052 Range: 0.011
Recv: Standard Deviation: 0.003054
Recv: 
Recv: X:190.00 Y:163.00 Z:5.00 E:0.00 Count X:15200 Y:13040 Z:1980
Recv: ok P15 B3

Repeated the same test while heating the bed to 80C and the hotend to 245C. It did not fail but the readings were much less consistent as was hypothesized

Recv: Finished!
Recv: Mean: -0.003833 Min: -0.061 Max: 0.055 Range: 0.117
Recv: Standard Deviation: 0.038436
Recv: 
Recv: X:190.00 Y:163.00 Z:5.00 E:0.00 Count X:15200 Y:13040 Z:1980
Recv: ok P15 B3

I moved the cable as far away as I could from the OEM cables (except the bundle near the print head) and it seems to have improved the accuracy by a little. It was still worse than the cold test but and improvement.

Recv: Finished!
Recv: Mean: -0.050900 Min: -0.101 Max: -0.010 Range: 0.091
Recv: Standard Deviation: 0.026889
Recv: 
Recv: X:190.00 Y:163.00 Z:5.00 E:0.00 Count X:15200 Y:13040 Z:1980
Recv: ok P15 B3

[StreckerCM]

Is C48 the capacitor that they are saying to remove on the CR10S Pro?

[Ronny3D]

My BLTouch works 19/20 times. Since it takes 10 readings per print, (one home and 9 for the bed) about half the prints have to be restarted. Creality Ender 3 board V1.1.4. BLTouch V3. No resistor hack.

The times it 'fails' it either 'detects' the bed right away (very high) or it sends an error to Octoprint and disconnects the server.

[Roxy-3D]

Wow! I didn't read most of the thread yet. But...

Paris did respond saying "After v2.2, because we use ceramic resonator, so we don't accept too large error than before." - Not sure what it means.

1 year ago, Paris didn't really speak English. (or at least... not fluent English) There was always a delay because a translator would have to get things into a form she could understand. Especially with highly technical jargon. But I think Paris reads English now. What she is saying is after v2.2 they started using a ceramic (quartz crystal) oscillator. The frequency error is much less than it used to be.

And this part is speculative: But those little AVR parts can be run without an external clock. My guess is she is saying they used to use the built in clock circuits, but the processor frequency drifted some amount. That isn't a problem as far as the firmware goes. It will run the code. The problem is the BL-Touch probe is trying to key off of various pulse widths to get commands because it is pretending to be an RC-Servo. The fact the built in clock circuits where not highly accurate some times caused the BL-Touch to misinterpret (or miss) commands being sent to it....

[ghost]

@Roxy-3D I think the main reason to go to a ceramic resonator instead of using the internal AVR RC oscillator was: In order to add some more new commands in between the already defined command angles, they needed to reduce the "glitch window" they had been using before due to the inaccurcy of the internal clock. Solution: Use an external clock, reduce the tolerances on the angle decoding, Reward: Space for some new commands at angles in between before.
But still you are right: When searching for the cause of the problems, one should never overlook: certainly it could be that (for example) the STOW command by Marlin when the trigger is recognized "goes missing because misinterpreted" once in a while.
How sure are we that our ANGLE -> PWM -> FREQUENCY output to the probes/servos are accurate and not borderline off by some degrees?

This was my comment on 12 March:

Sounds like they might be more exacting on the incoming PWM ratio that determines the servo angle. As they have moved to an external resonator for the MCU of the BLTouch, they don't need such a big leeway in detecting the desired angles setting - and that also gives them two additional new positions to use for two new "commands" (at 140° and at 150°.). If Marlin is slightly "off", something might go wrong.

Note that this kind of error would hit more than just a jew people, right?

[ghost]

@StreckerCM First of all thanks for the effort. Your results (when it doesn't fail) coincide with my results.
2 Observations:

1).
Because of the bad results while heating, I really needed to specify the following in my configuration.h:

#define PROBING_HEATERS_OFF       // Turn heaters off when probing
#if ENABLED(PROBING_HEATERS_OFF)
  //#define WAIT_FOR_BED_HEATER     // Wait for bed to heat back up between probes (to improve  accuracy)
  //turning this on, causes G28 Z (Home Z-Axis) to wait for bed heating up,
  //and causes G29 to wait before each probe, making it really slow.
  //Bed does not cool down too much, so that's ok for G29.
#endif
#define PROBING_FANS_OFF          // Turn fans off when probing
//#define PROBING_STEPPERS_OFF      // Turn steppers off (unless needed to hold position) when probing
#define DELAY_BEFORE_PROBING 200 

This way, the bed will be hot, but probing will be accurate because the heaters get turned off in the short period where the probe is moving downward. You can go back to your preferred method of G29'ing on a heated bed.
Then all of your M48's should have the acceptable results, unless of course they fail. Which is the "main" problem, not yet solved.

2). You listed the output of a failed M48. Super, thanks. That error tells me something. Your printer (and its Marlin) is not in danger of missing a probe trigger, otherwise it would sometimes plough into the bed. It is the opposite: I think that you are getting spurious triggers - the code sees the orginal trigger, checks that it isn't a noise trigger by wanting to see it twice in a row at least, then it issues the STOW command to react.
Then on the next deploy, it checks if the trigger is still active, or we have an alarm condition. It tries to reset that, waits a while, checks again if the probe is triggered and then issues the message you saw.
That's the only place where this message is issued.

To find out the problem I can give you a modified firmware that issues some debug messages telling us more. Are you using the Creality_DWINTest from @InsanityAutomation ?

[ghost]

@Bob-the-Kuhn Did you ever look at #13128? The guy had a noise problem and instead of pulling up more he ADDED a 10nf on the signal line at the probe. But the symptoms are very very similar to @StreckerCM

[juliandroid]

@FanDjango Regarding the noise, I guess alternative to the 10nf could be using a grounded copper shield sleeve that protects the entire length of the cables from the sensor to the motherboard.

[StreckerCM]

@FanDjango I am currently using the Creality_DWINTest from @InsanityAutomation I pulled it about two weeks back so it is the latest one he has published.

[Bob-the-Kuhn]

Noise is a real pain. So many potential sources, Lots of different ways to mitigate.

All of these have been reported as helping. I'm sure there are others.

• Lower pullup resistance at controller
• Higher capacitance at controller
• Shielding
• Moving cables
• Adding capacitance at BLTouch
• Turning off heaters & fans while probing
• Improved power wiring

---

I'll do some servo timing measurements on various CPUs. It may be a few days before I can get this completed.

[ghost]

Twisted wires help a LOT at times. Twisted pairs are used everywhere now to remove EMI both emitted and picked up.

So I always twist all sensor wires, power wires and motor wires.

With the stepper motors you don't twist all 4 wires together, you have 2 seperate twisted pairs, one for each winding. This can reduce emitted noise from the motor wires by quite a lot at times.

I use a little plastic drill to twist then all after removing the wires from the plugs. Doing it by hand would drive you mad ;)

[ghost]

@StreckerCM Could you open a separate issue for a few things we need to check out and test and then close, to avoid cluttering up this one until we have some conclusive things to report? Or are you on DISCORD?

[ghost]

@InsanityAutomation @StreckerCM
Been playing with probes manually for hours and I have come across something which corresponds to @StreckerCM 's problem.

      if (deploy && TEST_BLTOUCH()) {      // If BL-Touch says it's triggered
        bltouch_command(BLTOUCH_RESET);    //  try to reset it.
        bltouch_command(BLTOUCH_DEPLOY);   // Also needs to deploy and stow to
        bltouch_command(BLTOUCH_STOW);     //  clear the triggered condition.
        safe_delay(1500);                  // Wait for internal self-test to complete.
                                           //  (Measured completion time was 0.65 seconds
                                           //   after reset, deploy, and stow sequence)
        if (TEST_BLTOUCH()) {              // If it still claims to be triggered...
          SERIAL_ERROR_START();
          SERIAL_ERRORLNPGM(MSG_STOP_BLTOUCH);
          stop();                          // punt!
          return true;
        }

I am getting a seldom case where the sequence RESET->DEPLOY->STOW does not clear an alarm.
What happens is that RESET clears the alarm, light stops blinking, no longer triggered. Then issue a DEPLOY - all of a sudden light starts blinking, pin stays up (no, its not blocked :-) ) and signal goes to HIGH because of the ALARM. The subsequent code, i.e. the STOW does nothing to clear the new ALARM and then we run into the second triggered test -> BLAM! We stop.

All I needed to do, to get out of this situation (meaning RESET-DEPLOY-STOW does not clear the alarm) was to issue some other command and then to RESET, DEPLOY, STOW, bingo, back on track.

Since it occured once over long long time while playing manually with the probe menu, I have yet to find out if there is any specific cause for this. But I am beginning to feel it might be a bug/glitch in the probe.

Actually, there is no need for the DEPLOY in that recovery code anyway, in my opinion. Maybe @StreckerCM could just delete that line, recompile and check it out? It is the one with the DEPLOY, bltouch_command(BLTOUCH_DEPLOY); // Also needs to deploy and stow to in Marlin_main.cpp

Some other observations:

RESET or other commands than OD_MODE will not clear 5V mode, it is persistant. Doesn't hurt to do it over and over again though. POWER OFF/ON will go back to OD mode

Don't do anything after DEPLOY, because otherwise it won't trigger on pin-push-up.

If DEPLOYed, but not in SW mode, trigger will occur, pull up completely and redeploy ready for another cylce, we need to do a STOW. If we take too long to recognize the trigger, stop the motion and then STOW, you can observe the pin being pulled up, falling down and then being pulled up again due to the STOW finally arriving or even the probe hits the deck or we get an ALARM on the probe.

If in SW mode, trigger will occur, but actually the pin doesn't get pulled up by the probe. Recognizing the trigger must stop the motion, and do the STOW to pull up the trigger. Only if the pin gets pushed up to the end will it stay up of its own accord.

Never STOW and then set SW Mode - it will produce a HIGH signal, because the signal just reflects the position of the probe.

On the other hand, to find out the current position of the pin, set SW Mode and query the input signal.

STOW, DEPLOY, SELF-TEST and RESET will clear SW Mode but note:
RESET will clear the SW mode, but if the pin is currently STOWed (i.e. we have a HIGH signal), this will only be cleared by a second command after the RESET, like STOW.

So my recommendation: RESET->STOW to reinitialize. But not RESET-DEPLOY-STOW.

[Roxy-3D]

https://github.com/MarlinFirmware/Marlin/issues/13345#issuecomment-484014997 this is certainly worth a try!!!

[InsanityAutomation]

My concern is if a jam / error condition exists if you dont deploy and stow you dont know if its cleared. I would want the physical move to validate its actually good before continuing on. I believe that was the original intent of the code here though it pre-dates my involvement.

[ghost]

Valid point. In case the delete of the DEPLOY helps (not a final solution), next step is to replace the entire sequence by RESET->STOW->DEPLOY-STOW maybe? Because actually it is still unclear why that code is even being entered - why is there an ALARM or trigger in the first place. Just want to know what is going on.

[Roxy-3D]

Because actually it is still unclear why that code is even being entered

It is very possible... @Bob-the-Kuhn wrote this code. I think it has been in place almost since the beginning of BL-Touch support in Marlin. I'm trying to look at the v1.1.x code to see who created it because it would be good to hear their thinking.

Unfortunately... GitHub can't give me the 'Blame' page. The information I want is the names at about line 2150 of: https://github.com/MarlinFirmware/Marlin/blame/1.1.x/Marlin/Marlin_main.cpp (where that Reset -> Deploy -> Stow is....

[InsanityAutomation]

Im assuming history there is way too long so its exceeding the timeout....

[ghost]

Play it out:
We deploy ok. Move down.
Trigger! (dont care SW mode or not) - recognize trigger (good!) - STOW
And then next probe:
We WANT to deploy once more, BUT: the signal is high (still high? The STOW didn't reset it? Hmmpf. Noise, hmmmpf maybe. ALARM, okok, but why? And then why the ALARM is not resettable?
So many things you can only test at currently the only one who has the symptoms often enough. And test iteratively with small changes. If he is even willing because he is getting a new probe soon anyway. Also, if he has noise that spans 1500ms waiting time, why is his M48 going well for such a long time before it happens first time?

[ghost]

@InsanityAutomation @Roxy-3D There is no such thing as blame in open source, only regrets and flames

[InsanityAutomation]

@FanDjango Thats what GitHub calls the feature showing who made what change! Not our call! lol

[ghost]

Ok. Since I have seen this error ONLY twice now in several weeks of probing and can understand the users who see it so much more often I will dedicate a printer over the Easter Holidays with a V3 pre Apr5 probe (courtesy and my thanks to ANTClabs) to endless probing and debugging output on a terminal. Can't promise this will prove anything, but you never know. After thousands of probes I'll probably have to replace some cables or chains, but WTH. Signing off and I hope you all find a lot of eggs.

[Roxy-3D]

So many things you can only test at currently the only one who has the symptoms often enough. And test iteratively with small changes. If he is even willing because he is getting a new probe soon anyway.

If the user (@StreckerCM) is willing to send the probe to @FanDjango... I have a 'very current' BL-Touch v3.0 I can send to replace it. (This is the 2nd generation of the v3.0 probe that has much lower output impedance and seems to clean up the Creality problems we have seen.) Or if @StreckerCM prefers to avoid the v3.0 issues... I can send a v2.2 probe to replace it.

Any probe I send would be new and sealed in the factory shrink wrap.

[ghost]

@Roxy-3D No need thanks. Got all versions here, even clones (dirty word I know). When @StreckerCM has received a afterApr5 V3 probe to test we will see if his problems go away.

[Bob-the-Kuhn]

Lots of people have been involved with the BLTouch code. What you see is the result of people trying to address the failure modes as they cropped up. The main ones were:

• Unknown state after a reset or power up
• Attempt to recover after the pin gets stuck

---

SOAP BOX

I'm not aware af a generally applicable Z sensor system that is robust (fewer than 1 probing failure in 100K) and yet has consistency/repeatiblity over the whole surface.

I'm not impressed by the BLTouch's reliability. I estimate I see a probing failure (fails to deploy or retract) about every 250 - 1000 probes. It's probably the best of the mechanical probes but it's still mechanical. Head crashes will happen. I've gotten so tired of repairing my cartesian printer's head that a) I've mounted my head via a French cleat so that it pops off the mount before it gets damaged and 2) I've ordered a delta printer because the low mass of the head helps minimize damage during crashes.

I don't like the capacitive and inductive sensors because of how the sensitivity changes near the edges.

For a while I thought that piezo sensors might be the answer. It's been a couple of years now and so far I'm not seeing any unbiased claims of greatness.

Currently I'm hoping to see an elegant IR optical system come along. IR just because it has the potential to sense the top surface of a glass plate.

[Bob-the-Kuhn]

I measured the servo pulse widths on a 1284P, 2560, LPC1768 and a Due. The results were better than I expected.

Summary       
      + pulse times (in microseconds)     
      nominal  min     max    delta   worst deviation from nominal
S10    650     644.5   655.0  10.5       5.5
S60   1165    1157    1168    11         8
S90   1475    1466    1478    12         9
S120  1780    1774    1788    14         8
S140  1985    1979    2001    22        16
S150  2090    2082    2095    13         8
S160  2190    2184    2199    15         9

I captured 60 seconds of pulses on my logic analyzer. Sampling rate was 4MHz giving a 0.25uS resolution. The min and max times were obtained from the analyzer's built-in functions. Only 4 digits are reported.

Worst numbers cames from the 1284P 16MHz SANGUINOLOLU. I didn't see a crystal on the board so I expect it was using it's internal RC oscillator. No surprise it was the worst.

I did a capture of S160 data for each CPU while the X stepper was running at F5000. To my surprise there was no difference in the min/max numbers.

I also tried a couple of 240 second captures. No differences in the min/max numbers.

I'll forward this to Paris for her comments.

Here's the raw data.
Book2.xlsx.zip

[Roxy-3D]

SOAP BOX
I'm not aware af a generally applicable Z sensor system that is robust (fewer than 1 probing failure in 100K) and yet has consistency/repeatiblity over the whole surface.

I'm a really big fan of the original design... A Z-Probe leg that gets kicked down with a micro-switch on it.

[InsanityAutomation]

FYI, I ran 200 cycles today with 1k resistor. I made 2 small changes, I changed the safe delay from 375 to 500ms. I moved the switch mode command above the deploy command. Ill be repeating with the 470ohm shortly, but prior it was less reliable than the 1k before making the changes above, only getting about 30 cycles before a fault.

[Roxy-3D]

I moved the switch mode command above the deploy command.

I was under the impression the switch mode command had to be given after the deploy. Is it still going into switch mode with that being done first?

[ghost]

You can do it before the deploy, in which case because the pin will probably be up, you will get a trigger signal until the moment the deploy drops the pin, after which you no longer will be in SW mode. I think it is cleaner to do it after actually.

[ghost]

The safe delay has been on my list of possible things to change as well

[ghost]

@insanityautomation could you please check reset-stow-deploy-stow on fail just to humour me? Seeing that strecker is no longer with us and you do still are able to reproduce the fails... because we are looking at two fails here, I think. Number one is why it fails in the first place, number two is why doesn't our RESET-etc. sequence recover from that because the pin is NOT blocked, is it?

[InsanityAutomation]

@FanDjango I saw some of the interesting bits of back and forth in the error clear cycle.

if (deploy && TEST_BLTOUCH()) {      // If BL-Touch says it's triggered
        bltouch_command(BLTOUCH_RESET);    //  try to reset it.
        bltouch_command(BLTOUCH_DEPLOY);   // Also needs to deploy and stow to
        bltouch_command(BLTOUCH_STOW);     //  clear the triggered condition.
        safe_delay(1500);                  // Wait for internal self-test to complete.
                                           //  (Measured completion time was 0.65 seconds
                                           //   after reset, deploy, and stow sequence)
        if (TEST_BLTOUCH()) {              // If it still claims to be triggered...
          SERIAL_ERROR_START();
          SERIAL_ERRORLNPGM(MSG_STOP_BLTOUCH);
          stop();                          // punt!
          return true;
        }

Exactly how its written here. If you tell it to home, and it sees its triggered (which it will when in switch mode), reset then deploy / stow.

100 cycles in with the 2 changes mentioned on 470ohm, deviation is higher than 1k resistor but no fails yet.

[InsanityAutomation]

Between the two resistor values on the 10spro, 600 cycles 0 errors with those two changes... As for switch mode after deploy, that was my first thought however I think that may be what caused the clones to have an issue. I think its safer to have the known standard command last in case theyre dropping out of triggering condition when the unknown command is seen instead of silently ignoring it like a genuine bltouch. Ill run a few more cycles on a post april probe without the resistor next.... After I color eggs with the kids!

[Roxy-3D]

Ill run a few more cycles on a post april probe without the resistor next.... After I color eggs with the kids!

Wrong answer! You should be 3D-Printing stuff on your Easter Eggs! Check out what this guy did last year using Marlin: http://www.rooiejoris.nl/3d-printing-on-eggs/

He had some problems generating a mesh for each egg... The bed appears to the firmware to be super warped. But once we were able to get a mesh generated by UBL... He was able to print on the eggs.

Just in case anybody is interested in the idea... The full support thread is here: https://github.com/MarlinFirmware/Marlin/issues/10218

[juliandroid]

100 cycles in with the 2 changes mentioned on 470ohm, deviation is higher than 1k resistor but no fails yet.

@InsanityAutomation Great news, but what about deviation in the measurements with 470ohm and 1k? I would expect better precision with 470ohm not only no errors too :)

To sum it up, with the latest changes (moving the BLTOUCH_DEPLOY upfront) + resistor it works fine for pre 5th april revisions without affecting recovery sequence?

[InsanityAutomation]

50 cycles per result here :

1k resistor :
.001564
.001117

470ohm
.001856
.001521
.001422

Post April 5th version, no resistor :
.001299

[InsanityAutomation]

@Roxy-3D I do have 2 machines making eggs atm.... Thats pretty awesome and on another level from what im doing here! lol

[ghost]

If the "reset sequence on unexpected triggered" is working ASIS, why is @StreckerCM 's machine going into Recv: Error:STOP called because of BLTouch error - restart with M999. We are saying his pin is blocked or something?

[InsanityAutomation]

@FanDjango I got that within 30 cyles before moving the switch mode command and expanding the safe delay. Im assuming he needs to make those same 2 changes. Ill make a PR to match this later tonight as it seems to be better across the board.

[ghost]

@InsanityAutomation Righto, you're eliminating the initial error itself. Fine. But if you go back to the situation where the "error" occurs and produces this error message, why is the reset sequence not fixing it? Sorry to be so persistant, but I had this case and followed up on it - need a STOW after the RESET before you DEPLOY and STOW again, the even if the error happens, it will recover. And you seem to be in a position to even test that adverse case

[InsanityAutomation]

In my case when it faulted it called KILL so the machine was halted. Nothing was resetting that... I haven't yet had it trigger the error without calling kill right behind it. Every time I got the error was during an M48 sequence not a g29. I can go back to the code to pass that caused it more frequently and trim down the command delay and see if I can make it show up. Most likely you need reset twice, once to change mode back and once to release alarm, the normal deploy then stow after that.

[Bob-the-Kuhn]

Paris commented on the measured pulse widths. She expressed concern about the 1284P 16MHz SANGUINOLOLU.

To me that implies the crystal oscillator boards are compatible with V3 but the RC oscillator boards may not be.

[ghost]

As for switch mode after deploy, that was my first thought however I think that may be what caused the clones to have an issue. I think its safer to have the known standard command last in case theyre dropping out of triggering condition when the unknown command is seen instead of silently ignoring it like a genuine bltouch.

Not really: The BLTOUCH_SW_MODE is inside a #IF ENABLED(BLTOUCH_V3. Won't hurt a clone if it comes after the DEPLOY.

In my case when it faulted it called KILL so the machine was halted

I see, so it was not the SERIAL_ERRORLNPGM(MSG_STOP_BLTOUCH); message in your fail, but a different one?

In my case (two times), I came in here:

if (deploy && TEST_BLTOUCH()) { // If BL-Touch says it's triggered bltouch_command(BLTOUCH_RESET); // try to reset it. bltouch_command(BLTOUCH_DEPLOY); // Also needs to deploy and stow to bltouch_command(BLTOUCH_STOW); // clear the triggered condition. safe_delay(1500); // Wait for internal self-test to complete. // (Measured completion time was 0.65 seconds // after reset, deploy, and stow sequence) if (TEST_BLTOUCH()) { // If it still claims to be triggered... SERIAL_ERROR_START(); SERIAL_ERRORLNPGM(MSG_STOP_BLTOUCH); stop(); // punt! return true; }

And the RESET cleared the alarm, but the DEPLOY immediately produced a new ALARM and did not drop the pin, the STOW changed nothing and then the TEST brought us into the KILL branch.

Quoting myself now:

but the DEPLOY immediately produced a new ALARM and did not drop the pin

This is something I would like to ask ANTCLABS about, my pin certainly was not blocked or anything

Why would a DEPLOY go into ALARM (Blinking Red) if the probe pin is not blocked? A STOW cleared this condition (on my manual experiments), a power-off-on of the probe cleared it, so it was not a mechanical problem, not in this case.

Most likely you need reset twice, once to change mode back and once to release alarm, the normal deploy then stow after that.

Yeah, I thought that too, but it didn't. The only thing that got me out was RESET-STOW. Then you could DEPLOY and STOW again.

The first RESET certainly cleared the ALARM. The problem was that the DEPLOY after the RESET caused a new ALARM, see above.

[ghost]

Ok. Easter Monday dedicated to BLTouch testing.

I have been able to reproduce the @StreckerCM problem and know how to fix it. I also need to report it to ANTClabs sometime soon.

First let me sum up the current situation of actually 2 problems with the new V3 BLTouch:

1. Due to noise and bad input configuration, weak pulls up on pre-Apr5 BLTouch V3 probes, false triggers can occur. @InsanityAutomation in working on that with increasing success, but it concerns mostly CR printers and maybe a few others. In a nutshell, it may mean adding resistors lower than 1K (e.g. like 470R) to the signal line AND using new firmware. Still being tested how much better the new V3 (after Apr5) are on the CR machines.

2. Sometimes the probing fails because a DEPLOY does not work. I can reproduce as of today this with ALL of my V3 probes, both the early ones and all the new ones after Apr5. My clones and V2 and V2.2 probes do not exhibit this behaviour.

Description of Problem 2

After many successful probes, suddenly, probe does not react on DEPLOY command. After a while it goes into ALARM (red blinking state). This is what eventually leads to the MSG_STOP_BLTOUCH - the ALARM stays on because DEPLOY fails.

How to reproduce problem 2 manually

All you need to do is deploy the probe (when it works, of course). Then you yourself push up the pin with your finger, use your fingernail pointing upwards and be vehement. Get it to hit the top stop firmly and don't let it bounce. It will stay up and a subsequent DEPLOY will not deploy it. The probe will fail to push the pin down. It's not blocked though, you can pull it down with your fingers and it will come down easily. On my probes I am now able to reproduce this problem at will, even though during normal operation it would happen "nearly" never.

Explanation of problem 2

There is a magnetic detent at the top of the pin travel. Its strength is such that the solenoid that pulses the pin downwards is sometimes not QUITE strong enough. If the pin is pulled up, it most of the time bounces on the detent and settles down a few 10ths of a millimeter away from the top detent and the magnetic field keeping it up is slightly less strong OR more likely, it is slighty too far away upwards from the control solenoid. If the probe is not adjusted well from the factory oo the 5V supply is on the weak side, the needed strength to get the pin on its way down is missing.

Solution

Probe works better if you re-adjust the probe very slightly. Take a hex tool and screw the ferrite nut on the top of the probe inwards (clockwise) by 30°. NOT MORE, just a teensy weensy bit. Take care that the tool fits well or is made of plastic, as the ferrite nut is sensitive to being cracked or crumbled. For me, it was no longer possible to make the pin "stick" in the up position after this slight readjustment.

I have not investigated yet if a fat capacitor on the 5V supply near the probe would help. Turning the ferrite nut in seemed the better solution.

Oh, and @InsanityAutomation, therefore it makes no difference to the RESET sequence as discussed above. No need to change it after all. The pin is actually "blocked" in a sort of fashion. Sorry for the cry wolf. One more thing: the SW mode should be set after the deploy, otherwise the probe reverts to non-SW mode. And this even works on the V2.0 and V2.2 probes that I have, so they too would profit from a FORCE-SW-MODE config define.

[InsanityAutomation]

Not really: The BLTOUCH_SW_MODE is inside a #IF ENABLED(BLTOUCH_V3. Won't hurt a clone if it comes after the DEPLOY.

Im talking about the reason V3 was made a toggle, before this was conditional.

One more thing: the SW mode should be set after the deploy, otherwise the probe reverts to non-SW mode.

Ill confirm again, I thought it persisted until it got a reset command when I was looking at it.

I havnt seen a deploy failure yet myself though.

[Zol-Tank]

SOAP BOX

I'm not aware af a generally applicable Z sensor system that is robust (fewer than 1 probing failure in 100K) and yet has consistency/repeatiblity over the whole surface.

I'm not impressed by the BLTouch's reliability. I estimate I see a probing failure (fails to deploy or retract) about every 250 - 1000 probes. It's probably the best of the mechanical probes but it's still mechanical. Head crashes will happen. I've gotten so tired of repairing my cartesian printer's head that a) I've mounted my head via a French cleat so that it pops off the mount before it gets damaged and 2) I've ordered a delta printer because the low mass of the head helps minimize damage during crashes.

What I'd like to see is a manually adjusted "Oh Crap!" microswitch end stop on the Z axis to catch the head before a crash in case BLTouch probing fails.

[InsanityAutomation]

@Zol-Tank Many do use it this way. Disable #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and define a pin for the probe individually.

Edit : also dont merge M851 with babystepping since that value will now need to be fixed!

[ghost]

@InsanityAutomation Got a video. Seeing is believing: Stuck BLTouch

[InsanityAutomation]

@FanDjango But reproducing is understanding! I havnt sat back down to this since you posted how to cause it. At the day job now, so possibly tonight ill get to it again to see this, and confirm switch mode is working as I thought it was beyond any doubt.

[monsoon7]

I've been actively paying attention (not necessarily understanding) to this thread. I'm an extreme noob when it comes to all this technical jargon your gents are referring to. Definitely not my area of expertise! I have Cr10s Pro and of course the BLTouch doesn't work. What I'm wondering is, is there a solution to this problem yet? Can I simply desolder a capacitor and off to the races I go? If so, which one? I appreciate all the research you guys are doing to help us dummies out. Thanks!
Jack

[Roxy-3D]

I have Cr10s Pro and of course the BLTouch doesn't work. What I'm wondering is, is there a solution to this problem yet? Can I simply desolder a capacitor and off to the races I go?

CR-10's appear to be the worst case. Removing the capacitor on the end switch signal 'fixes' the problem. Adding a pull up resistor to the signal line is less 'invasive' and pretty much fixes the problem. We are working towards a solution where the BL-Touch shipped from Antclab's works with out any hardware modifications. The probes they (Antclabs) shipped after April 15 work much better than the original v3.0 probes. But there still seem to be some issues.

If you are willing to modify your controller board... You don't even have to de-solder the capacitor. You can cut it off (carefully!!!) with a small wire cutter (dikes). But de-soldering it (if you have the skill to do that) is a cleaner solution.

[monsoon7]

Hey Roxy! Thanks for your reply. I am pretty sure I can desolder. I'm not the best but I have the tools. But which one do I desolder. I was told the c7 but I don't even see a c7 capacitor on the board. I see where it says c7 but no capacitor. If you can can you send me a picture of it? Thanks!

[ghost]

I have more or less run out of things to "optimize" and this is the current state on my test/cludge printer, a modified Anet A6 with MKS SBASE, with a Apr5+ V3 BLTouch, using the current bugfix-2.0.x, running in BLTOUCH_V3, ...OD and ...SW mode:

I tried a G29 with visualisation and a M48 on V3 preApr5, V3 Apr5+ and a V2 (You can see the V3 is much better):

Here are the results:

G29: (7 by 7 Mesh)

M48 on a V3 Apr5+:

Recv: Finished!
Recv: Mean: 0.015250 Min: 0.011 Max: 0.019 Range: 0.007
Recv: Standard Deviation: 0.002424

M48 on a V3 preApr5:

Recv: Finished!
Recv: Mean: 0.006375 Min: -0.001 Max: 0.019 Range: 0.020
Recv: Standard Deviation: 0.006742

M48 on a V2.0 (works fine in "V3" mode):

Recv: Finished!
Recv: Mean: -0.009375 Min: -0.021 Max: 0.000 Range: 0.021
Recv: Standard Deviation: 0.007315

Oh, and someone donated a clone for me to test, and looking at the numbers, I will actually make an extra effort to send it back ASAP:
This needed the #define BLTOUCH_V3 to be removed, because its behaviour was slightly different. It does support SW mode (but this behaves subtly differently) and it successfully ignores 5V and OD mode, but worked better defined as a pre-V3 probe:

M48 on a GeeTech Clone:

Recv: Finished!
Recv: Mean: 0.003625 Min: -0.071 Max: 0.144 Range: 0.215
Recv: Standard Deviation: 0.059117

[InsanityAutomation]

Hey Roxy! Thanks for your reply. I am pretty sure I can desolder. I'm not the best but I have the tools. But which one do I desolder. I was told the c7 but I don't even see a c7 capacitor on the board. I see where it says c7 but no capacitor. If you can can you send me a picture of it? Thanks!

Use the latest code just updated at https://github.com/InsanityAutomation/Marlin/tree/Creality_DWINTest and put a 1k ohm resistor between the red and white wires and the probe will function as expected.

[InsanityAutomation]

I have Cr10s Pro and of course the BLTouch doesn't work. What I'm wondering is, is there a solution to this problem yet? Can I simply desolder a capacitor and off to the races I go?

CR-10's appear to be the worst case. Removing the capacitor on the end switch signal 'fixes' the problem. Adding a pull up resistor to the signal line is less 'invasive' and pretty much fixes the problem. We are working towards a solution where the BL-Touch shipped from Antclab's works with out any hardware modifications. The probes they (Antclabs) shipped after April 15 work much better than the original v3.0 probes. But there still seem to be some issues.

If you are willing to modify your controller board... You don't even have to de-solder the capacitor. You can cut it off (carefully!!!) with a small wire cutter (dikes). But de-soldering it (if you have the skill to do that) is a cleaner solution.

The pro is a different board than the others, and has been the most problematic. The Creality Melzi boards seem to mostly work, but pwm range is concerning... The 10S boards (Creality 1.1.2 - 2.2) appear to be just fine. The 2.4 board in the pro needs the resistor. Way too many creality boards to track! lol

[monsoon7]

So a 1/4 watt, 1ohm resistor would work?

[InsanityAutomation]

So a 1/4 watt, 1ohm resistor would work?

Yup!

[Roxy-3D]

So a 1/4 watt, 1ohm resistor would work?

Yup!

NO!!!!!! 1K Ohm. NOT 1 Ohm !!!!!!

[InsanityAutomation]

Doh! Yes 1k I skimmed too fast!

[CRCinAU]

@Roxy-3D I'm trying to debug a BLTouch v3 purchased from Creality's site - so likely a Pre Apr15 version.

Occasionally, it fails to deploy while doing a G29 - but it seems to occur randomly. It's fitted to an Ender 3 Pro - which has a 1.1.3 mainboard.

Am I reading correctly (this is a huge thread) to think that the solution to this is either:
1) Remove the C7 cap on the Z endstop if its there; or
2) Install a 1k resistor between red and white wires (this seems difficult to achieve without splitting the cable).

[ghost]

@CRCinAU Yes. You got it right. Please report back your results, ok?

[CRCinAU]

I noticed that I didn't have a single failure doing 5 x 5 grids with 2 probes per position (however that sample size is currently 1)... But when I was doing 3 x 3 with 3 probes per position, it would fail at least once when doing 2-3 runs of G29 in a row.

I also noticed that the Z speeds were different between 2 probes and 3 per position... 2 probes = 1 fast, 1 slow whereas 3 probes = 3 slow.

This is the results of my first 5x5 grid of the stock magnetic build surface that comes with the Ender 3 pro:

Send: M420 V
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 +0.070 +0.051 +0.030 +0.079 +0.122
Recv:  1 -0.049 -0.064 -0.059 +0.010 +0.045
Recv:  2 -0.044 -0.098 -0.076 -0.030 +0.030
Recv:  3 -0.034 -0.051 -0.051 +0.001 +0.044
Recv:  4 +0.096 +0.012 +0.017 +0.035 +0.099
Recv: 
Recv: echo:Bed Leveling ON
Recv: echo:Fade Height OFF
Recv: ok

[ghost]

@CRCinAU Prefer to see the results of a M48 first.

Read this from configuration.h:

// The number of probes to perform at each point.
//   Set to 2 for a fast/slow probe, using the second probe result.
//   Set to 3 or more for slow probes, averaging the results.
//#define MULTIPLE_PROBING 2

[CRCinAU]

@FanDjango that'd do it - always forget to RTFM :)

Rebuilding with Z_MIN_PROBE_REPEATABILITY_TEST defined... but looks like I run out of space... Might take me a bit to figure that part out...

[CRCinAU]

Ok, got it... I guess this seems bad:

Recv: Mean: 0.154450 Min: -0.051 Max: 2.003 Range: 2.054
Recv: Standard Deviation: 0.616017

[ghost]

Ooof. Not good. Compare that to after you use resistor or remove cap.

[CRCinAU]

After removing C7, my screen lights up but doesn't display anything, and the BLTouch is flashing RED (alarm?) mode all the time... Suggestions?

This is the kit shipped directly from Creality - so it has the pin 27 board etc

EDIT: ok, so this is strange - not sure what I did - but after unplugging and replugging the pin 27 board a couple of times and powering it on / off, it came back up good again...

[CRCinAU]

Ok, results of M48 after removing C7:

Recv: Mean: -0.003100 Min: -0.005 Max: -0.002 Range: 0.003
Recv: Standard Deviation: 0.000889

I did notice however that it went into alarm mode a number of times - but the test seemed to handle that ok and (what it looked like) reset the BLTouch v3 with not much more than a delay. Not sure why its now coming up with an alarm state though...

EDIT: Doing a G29, I notice multiple failures to deploy during a 5x5 grid which seems to lead to even more inaccurate readings :\

EDIT2: This is the output of a G29 after removing the C7 cap:

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 +3.122 +0.110 +0.088 +0.141 +0.174
Recv:  1 -0.005 -0.010 -0.005 +0.072 +0.102
Recv:  2 +3.003 -0.048 -0.024 +0.025 +0.084
Recv:  3 +0.018 -0.003 +0.004 +0.054 +0.098
Recv:  4 +0.148 +0.073 +0.081 +0.091 +0.157

Note the +3 values where the deploy failed occurred.

[ghost]

I did notice however that it went into alarm mode a number of times - but the test seemed to handle that ok and (what it looked like) reset the BLTouch v3 with not much more than a delay. Not sure why its now coming up with an alarm state though...

You could try turning the ferrite screw 30° carefully. I would be curious as to if that changes things. But only if you have the right hex key size.

Recv: Mean: -0.003100 Min: -0.005 Max: -0.002 Range: 0.003
Recv: Standard Deviation: 0.000889

That's looking quite nice, right?

[CRCinAU]

I have a hex key that fits - and I did try - but there's an assload of resistance meaning I need to use quite a lot of force to move it - so I chickened out - knowing what ferrite slugs are like.... Should it be expected that its bloody hard to move?

[ghost]

The +3 values on deploy failure are because the nozzle is that much further up when it fails and it is put into the mesh anyhow.

Yes mine had quite a resistance and I nearly chickened out myself

[ghost]

Can we sum up for now:

This is also for @InsanityAutomation to smile at and ANTClabs to ponder:
Removing C7 helped the M48 accuracy a lot (no it didn't, you were just lucky to have no fails in the series). But it introduced a new issue: Deploy failures once in a while, you didn't have those before removing C7. Are all of those statements correct?

It would mean 1k resistor still needs to be checked out, so sorry.

[CRCinAU]

Had deploy failures prior to removing C7. However the BLTouch v3 didn't flash red on deploy failure previously. Now it seems to go into alarm mode more often - which depending on where the alarm started (ie on move or start of a probe etc etc) how it seems to be handled.

So the accuracy via M48 is much better - but it goes into alarm mode more often - which seems to lead to an aborted reading (if during a probe) or a reset and handled with a delay (if after a move).

EDIT: Doing another M48, I got the following - with at least 2 (maybe 3?) failures to deploy:

Recv: Mean: 0.557300 Min: 0.156 Max: 2.160 Range: 2.004
Recv: Standard Deviation: 0.800726

[ghost]

You ARE running the new firmware, right?
OK, so the M48's are also being brought off course by the deploy failures.

[CRCinAU]

You ARE running the new firmware, right?

I'm running bugfix-2.0.x from a pull today.

Also have:

define PROBING_HEATERS_OFF

define BLTOUCH_DELAY 375

I don't force 5v mode though - I'm not sure if the Creality boards are 5v or 3.3v logic - so I haven't played with that setting.... What's the wisdom of the elders on this?

[ghost]

Ensure these, especially 5V:

  #define BLTOUCH_DELAY 500   // (ms) Enable and increase if needed

  #define BLTOUCH_V3

  #define BLTOUCH_FORCE_5V_MODE

[ghost]

I don't force 5v mode though - I'm not sure if the Creality boards are 5v or 3.3v logic - so I haven't played with that setting.... What's the wisdom of the elders on this?

@InsanityAutomation actually recommends the 5V mode AS WELL as a 1k resistor from signal to 5V. Also define the endstopspullup further up in the config.

Reasons:

1. That controller is 5V tolerant on that pin
2. That early BLTouch needs ENDSTOPPULLUPS on in OD mode, but that is then too slow because of C7 on the CR printers
3. That early BLTouch is too weak in 5V modes and then needs a 470Ohm to 1kOhm resistor to bring up the high logic level, ENDSTOPPULLUPS still recommended

[CRCinAU]

Ok, so I sat and watched it closely just now while doing an M48... it seems that the deploy failure isn't actually the pin failing to come out - it spits out, then retracts straight away and the BLTouch starts flashing red. Between deply & retract, there's zero Z movement.

I hadn't noticed that before as I hit the button, then looked at it when it either it sounded different, or the flashing caught my eye.

This is with #define ENDSTOPPULLUPS and #define BLTOUCH_FORCE_5V_MODE set.

I'm trying again with changing BLTOUCH_DELAY from 375 -> 500 to see if that makes a difference.

[ghost]

Ok, so I sat and watched it closely just now while doing an M48... it seems that the deploy failure isn't actually the pin failing to come out - it spits out, then retracts straight away and the BLTouch starts flashing red. Between deply & retract, there's zero Z movement.

THAT is a valuable observation (I will need to think about that for a while) and thanks for all your efforts so far. Forget needing to turn in the ferrite nut, this is not that problem but a different one.

Leaves the 1K. There was one guy further up in this mega-thread, who just stuck the wires of the resistor into the backs of the dupont sockets, for temporary testing only of course. Also, anything between 470R and 1K will do if you have any.

[CRCinAU]

Yeah, I've got all that stuff... thankfully, embedded stuff and arduino development as well as hardware prototyping is my thing. I'm just about to go have dinner with the folks (I'm already late) - so I'll head back and see what the results are of changing the delay from 375 -> 500 after that - probably about an hour or two...

[CRCinAU]

Ok, I'm back... First run of M48 after setting BLTOUCH_DELAY to 500. No failed probes.

Recv: Mean: 0.001050 Min: -0.001 Max: 0.004 Range: 0.006
Recv: Standard Deviation: 0.001650

Second run... 11th probe failed in an alarm state (slow probe) and was recovered. Probe retracted on probe 10, Z moved up, probe deployed, straight away retracted and flashed red, slight pause, alarm cleared, probe deployed, next probe started. Results:

Recv: Mean: 0.009200 Min: 0.004 Max: 0.013 Range: 0.009
Recv: Standard Deviation: 0.002943

[CRCinAU]

Four more runs of M48 gives the following:

M48 start:
F S F X S F S F S F S F S F S F S F S F S X F S
Recv: Mean: 0.016600 Min: 0.016 Max: 0.018 Range: 0.002

F S X F S F S F S F S F S F S F S F S F S F S
Recv: Mean: 0.016750 Min: 0.016 Max: 0.018 Range: 0.003

F S F S F S F S F S F S F S F S F S F S F S
Recv: Mean: 0.019050 Min: 0.018 Max: 0.022 Range: 0.004

F S F S F S F S F X S F S F S F S F S F S F S
Recv: Mean: 0.022000 Min: 0.020 Max: 0.023 Range: 0.003

Where F = fast probe, S = slow probe, X = alarm triggered.

[CRCinAU]

Installed a 1k resistor between white and red wires at the mainboard end of the plugs - then did 4 more runs of M48. Same legend as above:

F S F S F S X F S F S F S F S F S F S F S F S
Recv: Mean: 0.001700 Min: 0.000 Max: 0.003 Range: 0.003

F S F S F S F S F S F S F S F S F S F S F S
Recv: Mean: 0.005450 Min: 0.004 Max: 0.008 Range: 0.004

F S F S F S F S F S F S F S F S F S F S F S
Recv: Mean: -0.001050 Min: -0.003 Max: 0.000 Range: 0.003

F S F S F S F S X F S F S F S F S F S F S F S
Recv: Mean: 0.000950 Min: 0.000 Max: 0.002 Range: 0.002

[CRCinAU]

So, from reading the code, what I think is happening is that once the probe retracts, occasionally, it goes into an error state either before, or as the Z axis moves up. It then deploys & retracts with no Z movement - which I believe is the error handling on getting notification of an alarm - ie Release Alarm -> deploy -> retract. It then goes on with the next probe.

So, any theories on why it would go into alarm state after completing a probe?

[ghost]

I agree with your logic. No theories yet. I've got the same bug fix version running. Doesn't happen here with a pre apr5 probe. But you are definitely in a position to find out because it happens nice and often on your system.

[CRCinAU]

Ok, so to try and rule something out - I wasn't 100% confident in jamming the resistor into the connectors at the mainboard end - so I've jammed it into the connector at the BLTouch end - which I'm much more confident in it making contact... Running another few M48's now...

[ghost]

One thing is: the probes internal logic makes it go into alarm if you hinder the pin from going up. Maybe their timing is too aggressive for a weak 5v system that doesn't retract fast enough.

Could you let a self test run for 10mins to prove the probe itself is not at fault

[ghost]

According to our current knowledge the 1k should get it working... Be nice to have a confirm or non-confirm

[CRCinAU]

Just to double check, the option #define BLTOUCH_FORCE_OPEN_DRAIN_MODE was mentioned earlier... Should that be defined, or commented? I currently have it commented out...

EDIT: To remove all doubt, I'm currently using:

#define BLTOUCH
#if ENABLED(BLTOUCH)
  #define BLTOUCH_DELAY 500   // (ms) Enable and increase if needed

  /**
   * BLTouch V3.0 and newer smart series
   * For genuine BLTouch 3.0 sensors. Clones may be confused by 3.0 command angles. YMMV.
   * If the pin trigger is not detected, first try swapping the black and white wires then toggle this.
   */
  #define BLTOUCH_V3
  #if ENABLED(BLTOUCH_V3)
    #define BLTOUCH_FORCE_5V_MODE
    //#define BLTOUCH_FORCE_OPEN_DRAIN_MODE
  #endif
#endif

[Zol-Tank]

@Zol-Tank Many do use it this way. Disable #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and define a pin for the probe individually.

Edit : also dont merge M851 with babystepping since that value will now need to be fixed!

I've been thinking about this over the past couple of days. With the BLTouch the nozzle almost always sits more than 0.5mm (or whatever configured amount) above the probe. It would be nice if when it's doing the ABL pass, if Z goes below Z=0 by more than 0.5mm, Z is stopped to prevent a head crash. It wouldn't prevent a crash if the BLTouch fails when homing, but it would prevent a crash during ABL, which would make the window significantly smaller.

[ghost]

@CRCinAU That looks right

[CRCinAU]

Ok, great... I've been running a number of M48's - but I've still been hearing the click-click of the alarm reset in them. Hard to tell if the resistor is making a difference or not - ie rather subjective...

[CRCinAU]

Just wanted to throw it out there if anyone else has any ideas? I'm at a loss as to why the probe keeps going into the ALARM state...

[ghost]

Some ideas to find out more:
Can you put it in self-test for half an hour and confirm that that has no "glitches"? Then set do M48's to see how often those fail? Can you experiment with BLTOUCH_DELAY (like go up to 1000?) How often does it fail if you just repeat G28 Z?

[ghost]

Ooops sorry, I forgot you already stated that the M48 are also "alarming".

[ghost]

You can also do the following: Using the lcd menu, you can DEPLOY, you can set SW mode, you can then push up the pin once by hand, then you can STOW, and then repeat that a couple of times. That is the sequence that occurs according to the code when M48'ing. If that never goes into alarm mode, maybe the timing is too aggressive? We could play around with the code to check that.
I mean, the STOW needs to be as immediate as possible when the probe is moving downwards. But maybe after the STOW there needs to be more grace period before DEPLOYing again?

[CRCinAU]

So I've been tinkering around more - what I've noticed that if I do a single probe in each location instead of 2-3 (2 seems a waste as only one is used anyway, 3 does an average), I don't seem to get any alarm states.

I forgot that I still have the resistor in place on the hotend side of the BLTouch cable - but I'm not sure if that is making a difference.

Devils Advocate is also screaming at me to think if there are no alarm states happening because I just do fewer probes ;)

EDIT: And of course, because I just posted this, I ended up getting a probe in alarm mode twice doing a 5x5 G29. The firmware seemed to recover though - as the level still came back pretty good:

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4
Recv:  0 +0.120 +0.058 +0.030 +0.033 +0.060
Recv:  1 +0.000 -0.043 -0.017 +0.020 +0.045
Recv:  2 +0.000 -0.040 -0.033 +0.033 +0.088
Recv:  3 +0.000 -0.010 +0.023 +0.098 +0.128
Recv:  4 +0.120 +0.063 +0.088 +0.160 +0.237

[ghost]

@CRCinAU I've been waiting for you to pop up again 🥇
Look at #13841
You can pick it up under bugfix-2.0-x-SPECIAL-BLTOUCH-RELEASE
Maybe the debug text will help you isolate the problem.
Use this BLTouch section in the configuration.h:

/**
 * The BLTouch probe uses a Hall effect sensor and emulates a servo.
 */
#define BLTOUCH
#if ENABLED(BLTOUCH)
  /**
   * For all BLTouch probes and clones:
   */
  #define BLTOUCH_DEBUG_MSGS  // Produce some debugging messages when commands are issued to the probe
  #define BLTOUCH_DELAY 375   // (ms) Allow the servo signal to settle for this long before the next command

  /**
   * For BLTouch V2.0 and newer probes which support SW mode. Some clones do too.
   * Set the probe into SW mode, producing a longer pulse when triggered, useful when there
   * is noise or high capacitance on the signal pin.
   * If your probe works fine without this, don't turn it on, as it slow down probing
   */
  //#define BLTOUCH_FORCE_SW_MODE

  /**
   * For BLTouch V3.0 and newer probes:
   * If you want the new functions of the BLTouch V3 or need 5V mode (see below), enable this.
   * This adds the special V3 commands (5V, OD, SW modes) to the LCD configuration menu for BLTouch
   */
  #define BLTOUCH_V3
  #if ENABLED(BLTOUCH_V3)  
    /**
     * These probes default to OPEN DRAIN mode. All other probes are in 5V mode per default.
     * If you have a BLTouch V3.0 or newer and explicitely want 5V mode, use this define -  this 
     * makes it more compatible with previous probe versions. 
     * Warning: Make sure your controller boards input pin is 5V tolerant.
     */
    #define BLTOUCH_FORCE_5V_MODE
    /**
     * Advanced users who fervently believe in the reliability of their BLTouch probes can 
     * activate the HIGH SPEED mode for their unit. This will reduce the timing so far that 
     * DEPLOY and STOW failures are only captured on the NEXT such command to be issued.
     * The result is faster probing but much less surety of catching and identifying errors.
     * NOT RECOMMENDED for novice users and in unstable environments. As homing and probing are
     * not done so often, the speed gain is nice but not really life changing.
     */
    //#define BLTOUCH_HS_MODE
  #endif
#endif

[ghost]

EDIT: And of course, because I just posted this, I ended up getting a probe in alarm mode twice doing a 5x5 G29. The firmware seemed to recover though - as the level still came back pretty good:

Depends at what Z-height you got the alarm. Since they seem to be noise related in your machine, you were probably just lucky.

Have you also tried all of these:

#define PROBING_HEATERS_OFF       // Turn heaters off when probing
#if ENABLED(PROBING_HEATERS_OFF)
  //turning this on, causes G28 Z (Home Z-Axis) to wait for bed heating up,
  //and causes G29 to wait before each probe, making it really slow.
  //Bed does not cool down too much, so that's ok for G29.
  //#define WAIT_FOR_BED_HEATER     // Wait for bed to heat back up between probes (to improve accuracy)
#endif
#define PROBING_FANS_OFF          // Turn fans off when probing §§§§
#define PROBING_STEPPERS_OFF      // Turn steppers off (unless needed to hold position) when probing
#if ENABLED(PROBING_STEPPERS_OFF)
  //#define PROBING_STEPPERS_OFF_E_ONLY // Only turn off E steppers Special mod of my own, you can't activate this
#endif
#define DELAY_BEFORE_PROBING 200 

[corso1]

Hi,

Im new to 3d printing and my first printer is cr10s PRO. Now, like else I had problems with leveling, etc and I ordered bltouch and like else got v3 before april version.

I have few questions and please help.

First, I saw solution with resistor. Is that reliable solution and end of the problem?

Second, which firmware to download?

Third, do I need to change anything in that firmware or its precompiled yet?

Thank you in advance,
Luka

[CRCinAU]

@CRCinAU I've been waiting for you to pop up again 1st_place_medal
Look at #13841
You can pick it up under bugfix-2.0-x-SPECIAL-BLTOUCH-RELEASE
Maybe the debug text will help you isolate the problem.

Ok, this will probably take me a while to get to.... I'm wondering, since we removed C7, there isn't any filtering to stop noise... I wonder what the value of C7 is supposed to be... I'm wondering if a smaller cap would assist - without blowing out the accuracy somewhat...

EDIT: Silly me forgot that my multimeter has a capacitance tester :) Looks like its a 10uF ceramic.... I'm going to ask the electrical engineer at work tomorrow to see what he reakons....

[ghost]

There WAS a guy who had some problems and he ADDED a capacitor to solve them ( #13128 ) but it wasn't really the same problem as yours, I think.

Oh, and 10uF is huge for a filter. Are you sure you removed the right one after all? It should be close to the socket where you plug in the endstop. One of the pads should have 0Ohms the signal line of the probe to be sure (unless there is also an R in series, then R Ohms).

[CRCinAU]

Yeah - the meter certainly reads 10uF...

Found the PCB of the 1.1.2 board here. Mines a 1.1.3 - but I doubt its changed that much.
https://github.com/Creality3DPrinting/Ender-3/blob/master/Ender-3%20PCB/Ender3_pcb_parts.PDF

I'll have to take a peek to see what I have / can acquire... but its 3:24am now and work tomorrow (today!).

[ghost]

I found this: link

Looks like you got the right one.

In there it seems

[CRCinAU]

Interesting that is marked 4.7uF. Mine measured 10uF. In fact, its about 10.2uF according to the meter. I figure that taking C7 off the board has removed any/all noise filtering that was supposed to be present. I can see the idea about putting a tiny ceramic cap on there - I did notice I had a 100nF at home - but I didn't look too closely as to what I have on hand.

I wonder if the 4.7uF -> 10uF is a 'whoopsie' or a design change. If its a normal microswitch Z-Stop, I could see that it'd be one way to eliminate noise. Might not work well for the BLTouch though - it'd take quite a time to charge and have the value hit the logic transition point.

[CRCinAU]

I added a 100nF cap between the two points where C7 was... Noticed there still isn't much difference... A couple of repeated M48 runs caused alarm + reset cycle to happen. I do have my BLTouch cable tied quite firmly to the other cables that run from the hotend, all the way to the board. I'm going to try and undo this and see what its like in free-space...

[CRCinAU]

I also just captured a video to remove all doubt as to what it does.

https://www.youtube.com/watch?v=C6PIp6wQYZ4

To be fair, this was the 7th run... The 6 runs before this I was recording and it worked perfectly.

[ghost]

We're on to something here.

1. The blue light is very bright and flickering like crazy. Mine does not do that, it is very faint.
2. At 0.15, you have actually got ORANGE for a short moment. Should not be!

ANTClabs doesn't go into any detail, sadly:

So, lemme ask some questions: Is the BLTouch connected to 5V correctly (The red is +5V and the brown is GND?) How stable is the 5V? Is it 12V by mistake? Can you measure? What could cause the blue light to be so bright AND to flicker like that? Actually the red is also flickering.

[ghost]

Compare to my machine. Blue light faint, no orange: video

[CRCinAU]

I think the camera.... exaggerates the brightness.... If I take pictures from the side:

[CRCinAU]

Interestingly, the blue flicker isn't visible to the naked eye. I didn't notice until you pointed it out and I watched the video...

[CRCinAU]

Just looked at the cable... I don't have a brown... From the left, Blue Red Yellow Black White...

[ghost]

Maybe brown is politically incorrect in some destination countries 👎
Here's one of mine:

[ghost]

Regardless I have been watching the video.
As it goes down, the pin touches the bed and slowly gets pushed up.
It triggers because I can see the movement of the carriage stop, Marlin has seen it. But the pin hasn't been pushed in far enough to be pulled up by the probe. After a moment, Marlin pulls up the probe (STOW). If Marlin is a little too late, the probe goes into error because it is sitting in trigger-happy position for too long. I think the probes software is a little flaky at that point, or it didn't succeed to pull up the pin. Maybe turn in the core a little? I had to turn in the core on ALL of mine by some 30° to get them to be more reliable. And you are going too slow.
What happens if you make the downward movement a lot faster so that we get a few 100ths of a mm more downward movement before the trigger is reacted on?

[StreckerCM]

Update on my side:

I got the new Post April 5th BL Touch from ANTCLABS yesterday. Machine isn't 100% reassembled and still needs to be updated to the latest @InsanityAutomation firmware but I was able to do a two homing tests. Without the 1K resistor both homing operations completed successfully. The BL Touch did an error recovery on the 2nd homing attempt but recovered itself.

Given the issues I was having before would it still be of value to keep the resistor in the circuit?

[CRCinAU]

Given the issues I was having before would it still be of value to keep the resistor in the circuit?

Given my testing, the resistor doesn't seem to do much. Removing the C7 cap is certainly required for accuracy. I'd be interested to know if you are able to measure the C7 cap and see what value you get.

[ghost]

I'm sure of it. Normal Manual LCD test operation is: DEPLOY, confirm pin falls down, try pushing it up with your finger, at a certain point the probe will pull it up completely by itself, after a short trigger pulse (which you can only see on a good oscilloscope) the probe will let the pin fall down again and you can repeat. Please play with that for a moment to get a feel for it.

And please confirm that behaviour.

When probing, the pin is pulled up by the probe, it really is a lot quicker to do this, and moments later Marlin will come along and also do a STOW to cancel the DEPLOY and KEEP THE PIN up, as movement to the next probe point is to be expected. I don't see the probe pulling up the pin by itself. I see the movement stop. Then a pause, and then Marlin STOW pulls it up

Go faster downwards

[CRCinAU]

Go faster downwards

What's the #define for that? Save me having a big search... Is that the babystepping or a different one?

[ghost]

The BL Touch did an error recovery on the 2nd homing attempt but recovered itself.

Which means if you were to level with it, that Z value would be off.

It shouldn't go into error recovery, sorry to say that.

[ghost]

// Feedrate (mm/m) for the first approach when double-probing (MULTIPLE_PROBING == 2)
#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z * 2

// Feedrate (mm/m) for the "accurate" probe of each point
#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 4)

and

#define HOMING_FEEDRATE_Z   720

[CRCinAU]

Ok, so currently, I have:

#define HOMING_FEEDRATE_Z  (4*60)
#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z
#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2)

That gives: 240 and 120.

You've probably played with these probes a lot longer than me, what kind of value are you thinking for that? If 120 is too slow, is it usually ok for a 240 slow speed?

[StreckerCM]

@FanDjango I will level it and try again tonight. Last night I ran the wire though a cable shield to prevent interference from the wire running near other sources. After that I only had time to do a quick homing test to make sure i wired everything correctly. I will finish assembling and get it on the latest firmware tonight and re-level and test again.

[ghost]

720 / 1440 / 360 on my machine. It is a matter of taste.

The 720 isn't so loud when coming down from a big height, I hate that. And then the probe itself on homing first one, I love it when that is real fast, then the accurate one "real slow" (to my mind, that's 360, which is 3 times faster than yours :-) )

By the way, my #define HOMING_FEEDRATE_XY 3600

That machine is a piddling litte Anet A6, it's not a mechanical work of art.

#define DEFAULT_MAX_FEEDRATE          {   200,  200,   30,  100 } //§§§§
//                        (in mm/min) ( 12000 12000  1800  6000 )   §§§§
//                                      =========================   §§§§
//                   ....(in steps/s)   40000 40000 24000 20000     §§§§

/**
 * Default Max Acceleration (change/s) change = mm/s
 * (Maximum start speed for accelerated moves)
 * Override with M201
 *                                      X, Y, Z, E0 [, E1[, E2[, E3[, E4[, E5]]]]]
 */
#define DEFAULT_MAX_ACCELERATION      {  1000, 1000, 100, 10000 } //§§§§

/**
 * Default Acceleration (change/s) change = mm/s
 * Override with M204
 *
 *   M204 P    Acceleration
 *   M204 R    Retract Acceleration
 *   M204 T    Travel Acceleration
 */
#define DEFAULT_ACCELERATION            500  // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION   1000  // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION    1000  // X, Y, Z acceleration for travel (non printing) moves

[ghost]

@CRCinAU But its not about "who is faster" - it is to find out why the probe is not going up, so before you go faster, play with the finger test first.

[ghost]

Here is an example:
Using the LCD, I have deployed the probe and using the LCD I go down by 1mm twice, the probe triggers, pulls up by itself and drops back down. Indignantly, if it doesn't get a STOW quick enough, it goes into ALARM. That's how it works. Video

[CRCinAU]

@FanDjango Whenever I test it with my finger, the probe always seems to suck up... Hence going to have to trigger this some other way.... Let me try that via Octoprint...

[ghost]

Don't push it too far yourself. And it should come back down, regardless. Or something is different.

[CRCinAU]

You know what - I think you might be on to something..... If I take it down in 0.1mm steps, I can get the probe to suck back up - then it drops and goes into error mode. If I move it up 0.1mm while it is sucked up and before it deploys again - then its happy.....

[ghost]

Ok, <>. Here's another video: Video

[CRCinAU]

Hmmm - HOMING_FEEDRATE_Z at 480 I got a couple of proper probe failures:

Recv: Finished!
Recv: Mean: 0.501250 Min: -0.003 Max: 5.000 Range: 5.003
Recv: Standard Deviation: 1.499584

Trying to build again with 720....

I also wonder (if you happen to have the location open), before it does a STOW, does it wait for BLTOUCH_DELAY ms before telling it to stow?

EDIT: Nah, can't be - as the probe doesn't actually move until the STOW command is given, right?

[ghost]

Right. No. The delay is after setting the servo angle (PWM frequency), how long to wait before the next servo angle could be set.

EDIT: Nah, can't be - as the probe doesn't actually move until the STOW command is given, right?

Right 👍

[ghost]

This business of the probe sticking with the pin up is a second problem by the way, with less priority than this one you are trying to find. But it will also hit you, as it then fails to deploy at some point. To solve that one, you need to turn in the core by some 30° (ANTClabs speak of 180° even in their manual).

I am assuming that although you are going faster now, it is still the SAME bad behaviour...

[CRCinAU]

Yep - so even at #define HOMING_FEEDRATE_Z 720 and #define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 4)

The downwards movement stops (Z stop triggered) and the probe does not retract until the STOW command is given.

To contrast this, if I manually put the probe down, then use my finger to push it up again, it stows, then deploys again.

[ghost]

Ok. Let's think about this information.

What about playing around with the homing height, it sure probes from pretty far up each time, lemme see...

[ghost]

#define Z_CLEARANCE_DEPLOY_PROBE    3 // Z Clearance for Deploy/Stow §§§§
#define Z_CLEARANCE_BETWEEN_PROBES  2 // Z Clearance between probe points §§§§
#define Z_CLEARANCE_MULTI_PROBE     2 // Z Clearance between multiple probes §§§§
//#define Z_AFTER_PROBING           2 // Z position after probing is done §§§§

#define Z_PROBE_LOW_POINT          -2 // Farthest distance below the trigger-point to go before stopping

What's yours?

Ugh, ANTCLabs recommend 15 and 20mm. Yuck.

[ghost]

@paulpenney Anyone within 10 miles of my location when this thread/issue hits 500 posts will get a beer to celebrate

[ghost]

Does anyone else have a BLUE wire instead of a BROWN one? What can that mean? A really drastic fake?

[CRCinAU]

What's yours?

#define Z_CLEARANCE_DEPLOY_PROBE   10 // Z Clearance for Deploy/Stow
#define Z_CLEARANCE_BETWEEN_PROBES  5 // Z Clearance between probe points
#define Z_CLEARANCE_MULTI_PROBE     5 // Z Clearance between multiple probes
//#define Z_AFTER_PROBING           5 // Z position after probing is done

#define Z_PROBE_LOW_POINT          -5 // Farthest distance below the trigger-point to go before stopping

[ghost]

Yeah, I don't really think that is a problem, mine were that high in the beginning - it wasn't a problem

[ghost]

I am out of ideas at the moment, honestly. I am going to study your video a lot more for the moment.

[CRCinAU]

I am out of ideas at the moment, honestly. I am going to study your video a lot more for the moment.

While I'm twisting values and testing.... So the Z movement stops when the Z-Stop triggers... Even if it isn't far enough down to cause the probe to auto-retract. There's a delay between when the Z-Stop triggers and the STOW gets issued. What delay is that?

I'm building again with #define BLTOUCH_DELAY 50 - just to see if it makes any difference at all...

[ghost]

Anything below 100 +/-10 will fail commands that follow up on each other too quickly. Not recommended.

[ghost]

So the Z movement stops when the Z-Stop triggers... Even if it isn't far enough down to cause the probe to auto-retract.

I agree

There's a delay between when the Z-Stop triggers and the STOW gets issued.

I agree

What delay is that?

Well, in bugfix-2.0-x the `blocking_move' comes back on trigger. Endstop is tested so that we have it as a variable, heaters and fans are turned back on (but no pause because of the 'false'), and then comes the stow, that's actually quite good.

#if QUIET_PROBING
    probing_pause(true);
  #endif

  // Move down until the probe is triggered
  do_blocking_move_to_z(z, fr_mm_s);

  // Check to see if the probe was triggered
  const bool probe_triggered =
    #if BOTH(DELTA, SENSORLESS_PROBING)
      endstops.trigger_state() & (_BV(X_MIN) | _BV(Y_MIN) | _BV(Z_MIN))
    #else
      TEST(endstops.trigger_state(),
        #if ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
          Z_MIN
        #else
          Z_MIN_PROBE
        #endif
      )
    #endif
  ;

  #if QUIET_PROBING
    probing_pause(false);
  #endif

  // Re-enable stealthChop if used. Disable diag1 pin on driver.
  #if ENABLED(SENSORLESS_PROBING)
    endstops.not_homing();
    #if ENABLED(DELTA)
      tmc_disable_stallguard(stepperX, stealth_states.x);
      tmc_disable_stallguard(stepperY, stealth_states.y);
    #endif
    tmc_disable_stallguard(stepperZ, stealth_states.z);
  #endif

  // Retract BLTouch immediately after a probe if it was triggered
  #if ENABLED(BLTOUCH)
    if (probe_triggered && bltouch.stow()) return true;
  #endif 

The comment is not accurate - the STOW should catch the probe with the pin up.

[ghost]

If you turn off the PROBING_HEATERS and FANS and etc. etc. off, you could remove even that latency

[CRCinAU]

with BLTOUCH_DELAY 50:

https://www.youtube.com/watch?v=yFHhWhYOxqU

But yes, I'm still getting probe failures on that... Full failures:

Recv: Finished!
Recv: Mean: 0.338250 Min: 0.020 Max: 3.187 Range: 3.167
Recv: Standard Deviation: 0.949751

[ghost]

And the probe at 0:43 is crazy. Look at the sequence of that probe. The probe is crazy.

Kudos to you for catching that 👍 💯 Carriage moves up and while moving up the pin finally starts being pulled up. I cannot explain that behaviour at this moment.

For safety: This is your ONLY Z-MIN ENDSTOP, right? You don't have a separate microswitch somewhere?

[CRCinAU]

For safety: This is your ONLY Z-MIN ENDSTOP, right? You don't have a separate microswitch somewhere?

Yep - I only have the BLTouch....

[ghost]

Looks more like you should test BLTOUCH_DELAY 1000 - the probe is taking variable long times to do it's thing.

[CRCinAU]

Looks more like you should test BLTOUCH_DELAY 1000

Lets go 2000... Then it should be DAMN obvious of a delay....

My gut is still telling me that it won't retract until the STOW is commanded....

[ghost]

My gut is still telling me that it won't retract until the STOW is commanded....

No, the STOW should come immediately on the trigger. And the STOW should then be sitting there for 2000ms before anything else happens. SHOULD.

[ghost]

We should do this on discord, actually. Nobody is going to read all this shit.

[paulpenney]

I’m reading it lol. Can I get in on the discord?

On Apr 30, 2019, at 11:03 AM, FanDjango [e-mail] wrote:

We should do this on discord, actually. Nobody is going to read all this shit.

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

[ghost]

I'm FanDjango on discord

[InsanityAutomation]

For the ones who need it - https://discord.gg/fRZHFh

[CRCinAU]

I'm the old man having to go through a password reset for discord now ;)

EDIT: And now swearing because discord's stupid policy for validation link lifetimes is less than the standard SMTP graylisting retry timer..... facepalm

[CRCinAU]

My summary of the few issues I had with my Creality Ender 3 Pro (1.1.3 Mainboard) with BLTouch SMART v3.

The BLTouch was purchased directly from Creality's web site:
https://www.creality3donline.com/c/creality-bl-touch_0385

Problem: Accuracy as tested by M48 is bad (0.6 or higher deviation or range).
Solution: Remove capacitor C7 from the mainboard. This is directly below the Z-Stop socket that the BLTouch is plugged into.

Problem: Occasional trip into ALARM mode (BLTouch flashing red) when doing a probe.
Solution: Turned the slug in the top of the BLTouch v3 ~30 degrees in the clockwise direction.

I am now at the point of having doing quite a few hundred probes without a single failure.

Example results:

Send: G28
Recv: X:162.00 Y:124.00 Z:12.47 E:1053.11 Count X:12960 Y:9920 Z:5040
Recv: ok
Send: M48
Recv: M48 Z-Probe Repeatability Test
Recv: Finished!
Recv: Mean: 0.000250 Min: 0.000 Max: 0.003 Range: 0.003
Recv: Standard Deviation: 0.000750

[ghost]

Issue Summary May 1, 2019

The current situation if you have problems with your BLTouch probe (and it's not as hopeless as you think):

You have a number of options depending on the failure and the controller board.

(Often seen on CR printers) 1. Check if your input pin is being dampened too much by a capacitor (too much noise reduction). Symptom: No trigger or many missing triggers. Solution: Remove capacitor AND/OR add a 470Ohm or 1KOhm pull-up resistor. Check ENDSTOPPULLUPS in configuration.h

(Seen on custom cabling rigs) 2. Check if your input pin and the subsequent cabling is susceptible to noise (not enough noise reduction). Symptom: False triggers, unreliable probing. Solution: add a small 10nf-100nf ceramic capacitor from the probe signal to ground. Preferably at the probe, but possibly at the controller. Better solution: Eliminate the noise - better cabling. Turn off Nozzle Heater on probing. Turn off E-Stepper when probing if it is a direct extruder.

(All V3 probes seem to be factory-adjusted slightly too tightly) 3. Ferrite core maladjusted: Symptom: DEPLOY failures (especially) or STOW (have been experienced) failures. These lead to single or multiple probe failures, recoverable, but they ruin the M48 (bad range and standard deviation) or G29 (bad mesh) values. Solution: Turn in the ferrite core with a well fitting hex driver by 30° clockwise.

4. Get better error messages about the problem with #13841 - that's out there as a PR, still being discussed and perhaps modified, it might be rejected, it might make it into bugfix, but it might help find out the cause of the problem. Needs you to be able and willing to download, configure and install a firmware. Enable BLTOUCH_DEBUG_MSGS, study the output and get closer to determining the problem.

MYTH DEBUNKED
On my MKS SBASE I just tested putting in some big capacitors. I can go up to about 15uF before I get failures. At 10uF, it was still working. Accuracy didn't suffer. Same M48 range and standard deviation. But: Z-OFFSET was now off by 0.2ms and needed to be changed. I think this is what ANTClabs meant when they talk about accuracy. The one that hits me most though, repeatability, doesn't suffer. It's logical: The position on the time axis where the trigger will take place moves to the right.

When the capacitor is finally big enough for a fail, what is happening is that the part of voltage curve that reaches logic high voltage becomes too short (or disappears altogether) for it to register. My board is 3.3V though, so I have more grace than a 5V board - on 5V boards the maximum capacitor should NOT be that large. As a matter of fact, after some calculations I would state that 1uF would be a tentative maximum, better a maximum of 100n ceramic. CR printers (5V seem to have 4.7uF or 10uF depending on version, so that's too much.

This is important in case you are battling noise - 100nF won't hurt you for problem #1, but it will help for problem #2.

[CRCinAU]

Seeing as you did such a good writeup (as comment 505!), I simplified mine. Hopefully it helps others too.

[juliandroid]

Thanks a lot!

I'm in a process of a replacement for post 5th April BLTouch. I've sent my pre 5th version and I guess then I might need only 30° clockwise rotation fix and no cap or resistor fixes.

[CRCinAU]

I guess then I might need only 30° clockwise rotation fix and no cap or resistor fixes.

That depends on what printer you have. If you're talking about the Creality boards such as the Ender 3, your accuracy will still be average with C7 fitted. On my 1.1.3 board, C7 was 10uF. The 1.1.2 board was supposed to have 4.7uF.

Once you get it going, do an M48 test and see what your results look like - compare them to mine above. If they're a couple of decimal places different to mine, remove C7 and try again.

[ghost]

Summary edited - see above

[CWSpear]

So is this _not_ something that can be solved with software alone? Most this thread is way over my head. I was apparently one of the first ones to get a v3 in early-mid March and haven't used my CR-10 since...

[paulpenney]

The CR10 fix is easy. Just remove capacitor C7 near the Z end stop plug.

On May 1, 2019, at 11:53 AM, Cameron Spear [e-mail] wrote:

So is this not something that can be solved with software alone? Most this thread is way over my head. I was apparently one of the first ones to get a v3 in early-mid March and haven't used my CR-10 since...

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

[CWSpear]

Easy is a relative term...

[kopsy63]

For those of you that have used both V3s, I have the March V3 with a 1K resister and it works about 98% of the time. I do not know how repeatable it is (is there an easy way to test this?) Should I return the March V3 and get the newer version?

[paulpenney]

Easy is a relative term...

Simply grip it with a pair of needle nose pliers and twist. It will break easily off the board.

[CRCinAU]

This is important in case you are battling noise - 100nF won't hurt you for problem #1, but it will help for problem #2.

@FanDjango - I can confirm that on my system, once the 10uF cap was removed, the ~standard deviation~ range went from ~0.6 to ~0.003. Adding a 100nF ceramic cap took it to ~0.008 repeatedly. Technically worse, but certainly well within the required value scale.

[Roxy-3D]

Simply grip it with a pair of needle nose pliers and twist. It will break easily off the board.

It would probably work better to grip the middle of it with a small pair of wire cutters and cut it in half. And just leave the two halves soldered to the board. But I wouldn't do this.

[ghost]

@kopsy63 Check if turning in the ferrite core helps you, maybe? Check the repeatability with M48

[ghost]

Let's face it: CR boards with 10uF 👎 That is HUGE by sensor standards. They must have been having incredible worries about noise and stability on the Z-MIN pin. LOL If the sensor were then a microswitch closing down to GND, keen X-ray eyes might be able to see a small spark on the contacts when it closes... the only thing limiting that would be the resistance of the wire.

[juliandroid]

Accuracy didn't suffer. Same M48 range and standard deviation. But: Z-OFFSET was now off by 0.2ms and needed to be changed.

@FanDjango So, to completely fix the CR10s Pro with post-5th April BLTouch, without hardware modification could be Z_OFFSET + TIME_DELAY*PROBING_SPEED to accommodate for the delay introduced by the larger cap?

[ghost]

@juliandroid No, others have already seen that you will ALWAYS need to reduce or remove a capacitor this large on a 5V system. Ok, a trick is to add a resistor (**) as additional pull-up, that gives you some leeway. The normal mode of the probe is pulse mode, and that is only 10ms long. So the voltage at the pin will never reach a high enough level before it goes down again. But if you haven't removed the capacitor yet and are in a position to test something, I have a last option I would like to investigate. Just looking for a victim with some time on his hands.

**never forget the additional pull-up resistor. See @InsanityAutomation et. al., it is always easier to add something externally than to blast away on your controller board.

[juliandroid]

@FanDjango I left with impression, that this extra resistor is needed only when you are dealing with the pre-April revision? I'm confused now - what is the improvement of the post-April BLTouch?
Is there now any difference and does your summary cover both variants?

My BLTouch is travelling back to South Korea, but once I have my replacement I would try to test and measure the signal raise/fall time.

[ghost]

@juliandroid I understand. The post Apr 5 version has stronger logic high output and thus should not need an additional resistor as long as you set the newest firmware to 5V mode. Your task will be easier with the new version and the pain will be less, but actually both can be made to work. ANTClabs recommends removing the capacitor on ANY version.

I can't tell anyone in advance what he will need or not. I am just saying that if it doesn't work: there are your options.

Maybe option 5 should have been added: Send in the old one and get a new one, less pain.

but once I have my replacement I would try to test and measure the signal raise/fall time.

And also test if the waveform ever goes above, say, 3V, before going back down again already. It might not plateau at all.

[ghost]

Here some graphics to explain the problem:

Blue is what we want, in an ideal world. Orange is what we get thanks to the capacitor. If the capacitor were a bit smaller, you might see a plateau in the middle.

The bigger the capacitor, the plateau disappears and a small peak is left over and the lower the peak will be. The capacitor sort "eats up" the signal.
So that the input pin can recognize the signal it needs to be high enough:

It needs to reach or exceed 3V for long enough for Marlin to see it. Marlin wants to see it twice (to be sure) and checks "quite often".

[chunter1]

I got an CR-10S PRO and connected an BLTouch V3.0 to the usual z_min input.
It's working "somehow ok" if i add a 1k pullup resistor to 5V and desolder the 100 nF capacitor C48 on the Creality3D v2.4 motherboard.
HOWEVER
If i take a look at the signal with my scope, i see a high-level of only 2 V!
Disconnecting the BLTouch from the motherboard gives me a perfect 5V level on the sensor output.
How can that be??

[chunter1]

Even worse... if you choose the pullup to be too low, you kill your BLTouch (see my post here: https://github.com/InsanityAutomation/Marlin/issues/32)

I still don't undestand how th Z_MIN input can be driven that low-impedant to GND although there seems to be a 10 k resistor in series with the GPIO?
With the pullup used (1 k) i only get to 2 V if there was something pulling to GND with around 600 Ohm.

[Goldbacher]

My BLTouch V3 is working on motherboard V2.4 without jumper. Should I install the jumper anyway?

[quarky42]

So, what should I do to install a V3 BLTouch on a CR-10S Pro v2.4.1 control board? Am I removing capacitor C48? Flashing TM3D's hex file to the control board and their touch screen to that device?

Do I still need a resistor? (I just bought the V3, so I'm thinking they are the newer stock.)

[ghost]

I didn’t remove the capasitor c48. I only use resistor 1k ohm between red and white wire and it works well. On my cr-10s pro 2.4.1 main board.

[chunter1]

You don't need any pullup resistor.
You don't have to remove the 100nF capacitor C48.
You should use "#define BLTOUCH_FORCE_5V_MODE // For BLTouch V3.0 force 5V only mode"
You MUST place a jumper on "Z-" connector (as shown below) to keep the optocoupler from pulling down the Z_MIN line!
(see picture here: https://github.com/InsanityAutomation/Marlin/issues/32#issuecomment-492809555)

[quarky42]

Thank you chunter1! I've read through that thread several times, now. I'd like to use those three pins in a row to connect the servo, as well. Does that induce any changes in the configs like a port mapping perhaps? I did end up using the Arduino IDE project version so I could enable my all metal hot end as well. I was able to flash it without any major problems, so I'm feeling better about how that works.

I (like many others) could probably benefit greatly from an all-in-one write up of how to install the BLTouch V3 on a CR-10S Pro. I'd certainly be glad to help with summarizing it, but I am not confident yet.

If there are places I should be aware of where I can read more about any of this, I'd be glad to learn. So far I've just been picking up pieces here and there.

[chunter1]

Does that induce any changes in the configs like a port mapping perhaps?

No changes are needed since you are only using other supply pins (which are all the same).
I am a total beginner with 3D printing myself trying to get an undestanding of the different variants of Marlin for the CR-10S PRO.

[vidlord]

does anyone have information on how to get the new BLTouch to work on an ANET A8 mainboard

[ghost]

Does it not work?
Sorry: But which BLTouch version? V3.0 pre Apr5, V3.0 after Apr5

[ghost]

There is a 10uF cap on the input.
You can try a number of things:

1. remove the cap, ANTClabs recommendation. No need for different firmware in that case
2. add 1k resistor between WHITE and RED. No need for different firmware in that case
   
   But it depends on which ANET board you have. The newer ones might have a smaller cap.
   So it will be a bit trial and error I am afraid.

[ghost]

With the at this moment current bugfix-2.0.x you can run a M119 and diagnose the BLTouch, that helps when you are experimenting with the 1k resistor

[ptuxbury]

Ugh... I struggled with the BLTouch v3 sensor on my CR10S Pro for a couple of days until I ended up here. chunter1's jumper recommendation worked for me. I didn't need to add a resistor or remove a capacitor. Works great now! Thanks!

[Gyosa3]

Hi I am confused by this thread and the other ones I have read so far. It is like, this issue is solved by the latest firmware. I think I am falling between the cracks here, because I still cannot have it working on my setup:

• Creality CR10 S5 latest version with V2.2 board
• BLTouch v3.0 probably from before April 19
• Marlin 1.1.9-bugfix and TH3D firmware attempted

I have tried to enable BLTOUCH and BLTOUCH_V3 options, force 5V, tripple-checked the wires, it still does not stop the homing. When I issue a M119 command before homing all endstops are "open". If I would have the endstop cables in the wrong order or not well plugged it would say "triggered".

Self test is OK. When I issue single commands it does react well. Deploys well, retracts well. But... homing does not stop.

The symptom that I don't understand most is that at the very beginning, with the TH3D firmware and without enabling V3 commands, the BLTouch was deploying, z-axis was moving down, then when I was touching the probe with the finger the probe was triggering a retracting move, but the homing would not stop. Now with the V3 option enabled, when z-axis is moving down, although I have the blue light on, the probe does not react when I touch it. it is just staying on the tip of my finger. At some point, when I press enough up the red light switches on and at the end the probe stows up when I push it completely up.

At some point I start to doubt about the probe itself. I cannot say if there is a physical issue with the probe or a programmatic issue with the firmware. If all others seem to have it finally working and I can't, could this be because of a faulty probe (while still reacting to all individual commands) ? How can I test this further if all single commands react well ?

Other possible factor, initially I had extension cables on all my cables. Reading about noise issues with the BLTouch, I removed most extension cables finally, except for the Y-axis on which I have a TL-smoother board. Could this play a role in the probe not working ? Thanks !

[juliandroid]

@Gyosa3 what we saw as a critical problem was that an optocoupler pulled the signal down on the secondary board, available on the CR10s Pro ( https://github.com/InsanityAutomation/Marlin/issues/32 ). All the other Creality printers so far the problem was solvable with post April 5th BLTouch or by adding resistor (and removing/replacing capacitor).
So, generally, fully functional and working pre BLTouch with software only fix is not available everywhere. It is quite possible that on CR-10 S5, there is similar issue with something pulling the signal down. Also you can check your Z-endstop capacitor whether exceed 100nF.

[Gyosa3]

@juliandroid Thank you for the info now I understand more clearly the problem and the options. The Antclabs manuals only make sense to me now that I read your post. My BLTouch QR code says production date is 2nd April, so I do not have the right probe and it will not work with just a firmware update. That I saw... I saw many fixes for the 1.x boards but nothing for the v2.x board fix. I know in particular that the v2.2 has new "capacitor and regulator" somewhere on the board. I have not seen any mention or removing capacitator on the board. I am then down to adding a resistor somewhere, still don't understand where, or going back to my reseller, and either get a refund or request a post 5 April model. I will try the later one first :)

[juliandroid]

Yes, I would recommend you doing so. I didn't accepted myself doing hardware modifications due to poor compatibility introduced by Antclabs. The problem here is rather "political", because they didn't announce that the new v3.0 breaks compatibility, so I expected to work without issues.
I've replaced my BLTouch with post 5th April and with the optocoupler discovery on CR-10s Pro now I'm feeling safe that the BLTouch will work reliably.
In your case, however you better go with post 5th April and only if you have issues you might mod the cable with resistor or looking at the capacitor next to Z-endstop.

[RedJohn14]

Hello,

I installed Marlin Build from your repo here: (v.1.1.9)
https://github.com/MNieddu91/Marlin-AI3M-BLTouch

My settings in configuration.h looks like this:

`//#define PROBE_MANUALLY
//#define MANUAL_PROBE_START_Z 0.2

/**

A Fix-Mounted Probe either doesn't deploy or needs manual deployment.
(e.g., an inductive probe or a nozzle-based probe-switch.)
*/
//#define FIX_MOUNTED_PROBE
/**

Z Servo Probe, such as an endstop switch on a rotating arm.
*/
//#define Z_PROBE_SERVO_NR 0 // Defaults to SERVO 0 connector.
//#define Z_SERVO_ANGLES {10,90} // Z Servo Deploy and Stow angles
/**

The BLTouch probe uses a Hall effect sensor and emulates a servo.
*/
define BLTOUCH
if ENABLED(BLTOUCH)
define BLTOUCH_DELAY 100 // (ms) Enable and increase if needed

/**

BLTouch V3.0 and newer smart series
For genuine BLTouch 3.0 sensors. Clones may be confused by 3.0 command angles. YMMV.
If the pin trigger is not detected, first try swapping the black and white wires then toggle this.
*/
//#define BLTOUCH_V3
if ENABLED(BLTOUCH_V3)
define BLTOUCH_FORCE_5V_MODE
define BLTOUCH_FORCE_OPEN_DRAIN_MODE
endif
endif`

I used the original BLTouch v3.1 from here:
https://www.amazon.de/…/B075B57CHD/ref=ppx_yo_dt_b_asin_tit…

I also tested your new repo Marlin 2.0.x:
https://github.com/MNieddu91/Marlin-Ai3M-2.0.x-BLTouch

I have home everything with G28 and use G29 all works perfekt. BLTouch Pin comes out but if I TRIGGERED it from hand nothing happens Z axis not stop!

If I home everything again with G28 and looks with M119 I see this:
< 13:10:36: x_min: TRIGGERED
< 13:10:36: y_min: TRIGGERED
< 13:10:36: z_min: TRIGGERED
< 13:10:36: z2_min: TRIGGERED
< 13:10:36: z_probe: open

The z_probe status won't change. I TRIGGERED the Pin manual but the status won't change. The Server cable on my motherboard is correct because I can use this command without any problem:

M280 P0 S10 ; pushes the pin down
M280 P0 S90 ; pulls the pin up
M280 P0 S120 ; Self test – keeps going until you do pin up/down or release alarm
M280 P0 S160 ; Release alarm

Only the trigger status will not work Z axis not stop! Any idea what the problem is?

Here is also a video from the printer:
https://drive.google.com/open?id=1cAup0ubzmK27F0MHrlfSdWe8jBjmkSl9

Attached you find pictures and a video. Ideas? Maybe someone can help me? I tested everything 4 days now 😞 😞I hope someone can help me ...

Attached you find a picture from my BLTouch mount in the printers head. And a picture from the cable on my motherboard. I have the new Board 1.1. I have an Anycubic i3 Mega Printer.

[caseyjmorton]

Double check and make sure the version of your BLTouch hardware is not V3
or above. If it is, make sure to uncomment BLTOUCH_V3

On Thu, Jan 2, 2020 at 2:56 PM RedJohn14 [e-mail] wrote:

Hello,

I installed Marlin Build from your repo here: (v.1.1.9)
https://github.com/MNieddu91/Marlin-AI3M-BLTouch

My settings in configuration.h looks like this:

`//#define PROBE_MANUALLY

//#define MANUAL_PROBE_START_Z 0.2

/**

A Fix-Mounted Probe either doesn't deploy or needs manual deployment.

(e.g., an inductive probe or a nozzle-based probe-switch.)

*/

//#define FIX_MOUNTED_PROBE

/**

Z Servo Probe, such as an endstop switch on a rotating arm.

*/

//#define Z_PROBE_SERVO_NR 0 // Defaults to SERVO 0 connector.

//#define Z_SERVO_ANGLES {10,90} // Z Servo Deploy and Stow angles

/**

The BLTouch probe uses a Hall effect sensor and emulates a servo.

*/

define BLTOUCH

if ENABLED(BLTOUCH)

define BLTOUCH_DELAY 100 // (ms) Enable and increase if needed

/**

BLTouch V3.0 and newer smart series

For genuine BLTouch 3.0 sensors. Clones may be confused by 3.0 command angles. YMMV.

If the pin trigger is not detected, first try swapping the black and white wires then toggle this.

*/

//#define BLTOUCH_V3

if ENABLED(BLTOUCH_V3)

define BLTOUCH_FORCE_5V_MODE

define BLTOUCH_FORCE_OPEN_DRAIN_MODE

endif

endif`

I used the original BLTouch v3.1 from here:
https://www.amazon.de/…/B075B57CHD/ref=ppx_yo_dt_b_asin_tit…

I also tested your new repo Marlin 2.0.x:
https://github.com/MNieddu91/Marlin-Ai3M-2.0.x-BLTouch

I have home everything with G28 and use G29 all works perfekt. BLTouch Pin
comes out but if I TRIGGERED it from hand nothing happens Z axis not stop!

If I home everything again with G28 and looks with M119 I see this:
< 13:10:36: x_min: TRIGGERED
< 13:10:36: y_min: TRIGGERED
< 13:10:36: z_min: TRIGGERED
< 13:10:36: z2_min: TRIGGERED
< 13:10:36: z_probe: open

The z_probe status won't change. I TRIGGERED the Pin manual but the status
won't change. The Server cable on my motherboard is correct because I can
use this command without any problem:

M280 P0 S10 ; pushes the pin down
M280 P0 S90 ; pulls the pin up
M280 P0 S120 ; Self test – keeps going until you do pin up/down or release
alarm
M280 P0 S160 ; Release alarm

Only the trigger status will not work Z axis not stop! Any idea what the
problem is?

Attached you find a picture from my BLTouch mount in the printers head.
And a picture from the cable on my motherboard. I have the new Board 1.1. I
have an Anycubic i3 Mega Printer.
[image: Bild 2]
https://user-images.githubusercontent.com/47501883/71689365-2c55e500-2da2-11ea-929a-3900fa77e3c7.jpeg
[image: Bild]
https://user-images.githubusercontent.com/47501883/71689366-2c55e500-2da2-11ea-8f05-59058dad1e69.jpeg

Here is also a video from the printer:
https://drive.google.com/open?id=1cAup0ubzmK27F0MHrlfSdWe8jBjmkSl9

Attached you find pictures and a video. Ideas? Maybe someone can help me?
I tested everything 4 days now 😞 😞I hope someone can help me ...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/13345?email_source=notifications&email_token=AAMDUFVR3J7DFWLFRZBY6B3Q3ZBHDA5CNFSM4G42WEO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH7HIOI#issuecomment-570324025,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMDUFR6BIV36DPQ5UEUNK3Q3ZBHDANCNFSM4G42WEOQ
.

[RedJohn14]

Überprüfen Sie nochmals, ob die Version Ihrer BLTouch-Hardware nicht V3 oder höher ist. Wenn dies der Fall ist, müssen Sie BLTOUCH_V3 auskommentieren
…

I checked my BLTouch and it is on original BLTouch Version 3.1. Any ideas why Z Axis not stoped? All other commands worked without any problem (Self test, BLTouch PIN out, BLTouch PIN in). Only if i started G29 printer will not probe the bed see video:
https://drive.google.com/open?id=1cAup0ubzmK27F0MHrlfSdWe8jBjmkSl9

[InsanityAutomation]

define BLTOUCH_DELAY 100 // (ms) Enable and increase if needed

This is WAY too short. Default for V3 is 500.

[ManuelMcLure]

The BLTOUCH_V3 setting is no longer available nor is it necessary.

[RedJohn14]

The BLTOUCH_V3 setting is no longer available nor is it necessary.

Okay, which settings does I need for an Anycubic i3 Mega Printer with Trigorilla Board 1.1 and the newest BLTouch original sensor in Version 3.1 ? I have tested so much settings nothing worked .... :-( I hope you can help me..

[mdsavio]

The BLTOUCH_V3 setting is no longer available nor is it necessary.

Okay, which settings does I need for an Anycubic i3 Mega Printer with Trigorilla Board 1.1 and the newest BLTouch original sensor in Version 3.1 ? I have tested so much settings nothing worked .... :-( I hope you can help me..

RedJohn, you resolvit?

[borislavstefanov]

Did you have a progress byt i have this problem with bltouch 3.1.

[buckholt82]

not sure if im in right place but ive looked every where. when I do G29 and it gets to the point to double touch, well on the second touch the z motors go really slow and causes it to say fail to heat which is not my concern its the z going down super slow. I tried to go thru the configuration.h file to change speed but only thing I saw was (#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST)
which said 2 I think and I changed to 5 but didn't notice any difference besides maybe a lil slower

[thinkyhead]

@buckholt82 —  This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

• MarlinFW.org Marlin Documentation
• RepRap.org Marlin Forum
• Tom's 3D Forums
• Facebook Group "Marlin Firmware"
• Facebook Group "Marlin Firmware for 3D Printers"
• Marlin Configuration on YouTube
• Marlin Discord server. Join link: https://discord.gg/n5NJ59y

After seeking help from the community, if the consensus points to to a bug in Marlin, then you should post a bug report.

[github-actions[bot]]

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.