[BUG] BLTouch v3.0 not working properly with marlin homing #13345
Comments
|
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. |
|
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 |
|
Seems to me there are some changes from V2.2 to V3.0: |
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. |
|
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 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). |
|
Actually, after giving this some more thought, this:
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:
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 whilst on my machine:
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? |
|
Can you try a manual M280 Px S140 and then try a G28 Z? ? |
|
But try the S10 and S90 first, to confirm you have the right "x" |
|
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 |
|
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. |
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. |
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:
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. |
|
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. |
Dont you love being patient zero? lol Pretty bad to get hit with that qty of them as well... |
|
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) 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. |
|
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: I can use PayPal to send you $$ to cover your costs and/or return it to you.. |
|
From my experience with the V2.0 units:
|
|
Bob, I would try Paris @ antclabs@gmail.com 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 |
|
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. |
|
Or maybe its a resistor. Anyways its the bigger yellow component. |
|
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? |
|
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. |
|
Could you post the original text of their reply and also post a foto of the V.30 PCB with the C7? |
|
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. |
|
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.
|
ghost
mentioned this issue
|
My BLTouch V3 is working on motherboard V2.4 without jumper. Should I install the jumper anyway? |
|
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.) |
|
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. |
|
You don't need any pullup resistor. |
|
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. |
No changes are needed since you are only using other supply pins (which are all the same). |
|
does anyone have information on how to get the new BLTouch to work on an ANET A8 mainboard |
|
Does it not work? |
|
There is a 10uF cap on the input.
|
|
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 |
|
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! |
|
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:
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 ! |
|
@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 ( InsanityAutomation#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). |
|
@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 :) |
|
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. |
|
Hello, I installed Marlin Build from your repo here: (v.1.1.9) My settings in configuration.h looks like this: I used the original BLTouch v3.1 from here: I also tested your new repo Marlin 2.0.x: 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: 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 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: 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. |
|
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 ***@***.***> 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
<#13345?email_source=notifications&email_token=AAMDUFVR3J7DFWLFRZBY6B3Q3ZBHDA5CNFSM4G42WEO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH7HIOI#issuecomment-570324025>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMDUFR6BIV36DPQ5UEUNK3Q3ZBHDANCNFSM4G42WEOQ>
.
|
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: |
|
define BLTOUCH_DELAY 100 // (ms) Enable and increase if needed This is WAY too short. Default for V3 is 500. |
|
The |
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? |
|
Did you have a progress byt i have this problem with bltouch 3.1. |
|
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) |
|
@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:
After seeking help from the community, if the consensus points to to a bug in Marlin, then you should post a bug report. |
|
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. |
and others
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
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
The text was updated successfully, but these errors were encountered: