BLTOUCH - AutoHome Z will not stop

Pulling my hair out. Machine is TronXY X5S upgraded to an SKR 1.3 mainboard.

Now trying to install BLTouch clone. Using Marlin 2.1.2 Sensor is connected to Servo and Zmin connectors.

I can manually DEPLOY and RETRACT the sensor through the menu. I correctly read Open, and Triggered when I query with M119 with Pronterface under these conditions

M43 S reports and triggers fine.

But when I execute Autohome in the menu - Z axis continues even when the sensor is triggered. I trigger with bed low otherwise it would drive nozzle into bed.

I've attached my configs

Thanks in advance.

You didn't uncomment USE_PROBE_FOR_Z_HOMING ! ("Force the use of the probe for Z-axis homing")

Also, Z_MIN_PROBE_ENDSTOP_INVERTING should be uncommented

Edited 1 time(s). Last edit at 04/05/2023 08:19PM by yet-another-average-joe.

Thanks for your response.

I made attempts uncommenting USE_PROBE_FOR_Z_HOMING with no effect.
If you look at the comment in the code just above for Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
it automatically enables USE_PROBE_FOR_Z_HOMING.

Where do you see Z_MIN_PROBE_ENDSTOP_INVERTING? I just searched and can't find that. I think that was in the older versions of Marlin. All the youtube video guides are on the old versions of marlin, and they mention that setting.

I just switched to Marlin 2.1.2 Bugfix branch. Note to self - never use the main branches of Marlin

Anyhow, I see they changed how the logic is handled for the endstops. It is now defined as HIGH or LOW instead of "inverted true/false".

So I'm going to play with these today and see if I can make any progress.

However I think inversion is potentially the problem, but the sanity checks mandate that with BLTOUCH declared then Z_MIN_ENDSTOP_HIT_STATE, Z_MIN_PROBE_ENDSTOP_HIT_STATE, cannot be different from each other and must both be set HIGH.

In any case, from my perspective it is a "bug" if all the diagnostics proclaim that the BLTOUCH is working properly (i.e., M43, M119, BLTOUCH menu items work, etc) and AUTOHOME fails to work, especially if USE_PROBE_FOR_Z_HOMING is defined. At the bare minimum if there was some other setting that needed to be set then use a sanity check to issue a warning during compile.

I was going to enter that as a BUG on github. But then in the bug entry form it mentioned that you should try your problem on the bugfix branch first before entering a bug.

So this is where I am at.

Edited 1 time(s). Last edit at 04/06/2023 09:55AM by brokencase.

Still no luck with 2.1.2 bugfix

Here is proterface terminal capture. In marlin menu I deploy and retract bltouch, and then I issue M119 to capture state.

I then follow up with M43 S test. It cycles the probe and then extends and asks me to trigger probe. All is fine.


Connecting...
Printer is now online.
>>> m119
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: open
>>> m119
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: TRIGGERED
>>> M43 S
SENDING:M43 S
Servo probe test
. using index: 0, deploy angle: 10, stow angle: 90
. Probe Z_MIN_PIN: 57
. Z_MIN_ENDSTOP_HIT_STATE: HIGH
. Check for BLTOUCH
. Deploy & stow 4 times
** Please trigger probe within 30 sec **
. Pulse width (+/- 4ms): 10
= BLTouch pre V3.1 (or compatible) detected.


AutoHome still not working. It properly homes x,y, and then moves the head to the center of the bed. Probe extends Bed rises and then I manually trigger the probe. Bed bed does not stop and continues to rise. I then turn off power to avoid nozzle/bed collision.

I'm on last version of stable release. (e7c4a86, january 2023)
Z_MIN_PROBE_ENDSTOP_INVERTING is line 1123

made a mistake. It's set with true/false, false = default.

I'll have to wait a few hours before I can see how my printer behaves because it is currently printing...

Didn't really touch the BLTouch settings for the last 5 years, copying/pasting settings over and over from version to the next using WinMerge... But at first I've been struggling a bit !

I imagine the probe deploys lower than the nozzle (?)

Also : my BLTouch is a v2 ; and switched to a SKR 1.4 that has dedicated BLTouch ports, and does not use the Z- pins. Will have to look at my archives.

Jumped into this thread because I was having problems with this old probe, problems I finally solved by adjusting the grub screw. Don't do this if your BLTouch is not blinking !!! (it didn't like the heated chamber)

There is discussion on other forums about swapped black and white wires coming from some BLTOUCH sensors. I just checked. My wiring is correct. On the sensor itself the connector has two side pins to hold the connector to the PCB. I DMM buzzed between these (which are presumably ground) and my black pin and there is continuity. So my black wire is ground and I checked the skr 1.3 schematic and and I am connected properly on the Z min input on the board.

Z_MIN_PROBE_ENDSTOP_INVERTING does not exist in 2.1.2.

What version of Marlin are you on? I went with the latest because as I recall bktree display firmware recommended 2.1.0 or later.

I will happily back track the version if I can get this to work .

Last stable, line 1123 :

[github.com]

Edited 2 time(s). Last edit at 04/06/2023 04:39PM by yet-another-average-joe.

Thanks. I'll give it a shot. Perhaps I'm ahead of the cutting edge with 2.1.2...

I'll post an update tomorrow after I merge my configs...

Had a look to the bugfix : they renamed the constants (see *_ENDSTOP_HIT_STATE) and they now define the pin hit state HIGH or LOW, rather than the positive/negative logic. Makes sense as it reflects what can be read using a DMM, rather than the way the firmware interprets the pin state.

On my printer, M119 also reports : Recv: z_probe: TRIGGERED

Meaning your problem is not a inverted logic.

#define Z_MIN_PROBE_ENDSTOP_INVERTING false

is equivalent to

#define Z_MIN_PROBE_ENDSTOP_HIT_STATE HIGH

M43 S returns :

Send: M43 S
Recv: Servo probe test
Recv: . using index: 0, deploy angle: 10, stow angle: 90
Recv: . Probe Z_MIN_PROBE_PIN: 10
Recv: . Z_MIN_PROBE_ENDSTOP_INVERTING: false
Recv: . Check for BLTOUCH
Recv: = BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 detected.
Recv: ** Please trigger probe within 30 sec **
Recv: . Pulse width (+/- 4ms): 10
Recv: = BLTouch pre V3.1 (or compatible) detected.

Same as yours (except for pin # of course)

I found this discussion on Github : [github.com]

It seems some BLTouch clones have different timings (triggering delays). See BLTOUCH_DELAY and BLTOUCH_FORCE_SW_MODE in Configuration_adv.h

Long ago I had a clone and issues with. I had to change BLTOUCH_DELAY ; also, I set ENDSTOP_NOISE_THRESHOLD to 2 (it still is, BTW, as it does not hurt...)
I also had to purchase a genuine BLT, because the repeatability test was all over the place ; it was a black 3D Touch I got from Ali for 7€ or so.

Thanks for that link. I noticed this...

"To enable trace:
#define DEBUG_LEVELING_FEATURE
Issue the command: M111 S32
This will make Marlin output a lot of trace data about probing. That might help."

..which I think will be useful. Just need a way to debug. Hopefully I am only hours away from bltouch bliss.

Finally...It works.

I tried loading 2.1.x and it locked up my board. Killed USB. I was worried for a bit.

So I reloaded bugfix 2.1.x manually via SD card and I did the changes that john4242 did in the [github.com] link...


Configuration.h
#define BLTOUCH
#define Z_MIN_PROBE_ENDSTOP_INVERTING false // No need to invert, leave this as config default
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN - commented out because I am using ZMAX pin
#define Z_MIN_PROBE_PIN P1_24 // the z max pin - SKR1.3 board
//#define ENDSTOPPULLUP_ZMIN_PROBE - this is to be commented out, though maybe not important
#define AUTO_BED_LEVELING_BILINEAR - I use this one
#define NUM_SERVOS 1 // Servo index starts with 0 for M280 command - 3DTouch
#define SERVO_DELAY { 750 } // VERY important, this seems to be the root cause. The default 300 is not enough

Configuration_adv.h
//#define BLTOUCH_DELAY 1000 // if you didn't set the SERVO_DELAY, you could set this delay, otherwise can be commented out
//#define BLTOUCH_FORCE_SW_MODE - leave this commented out, or you will have errors
// generally leave all other BLTOUCH bits commented out

OK, need to get familiar with all this and setup my zoffset etc.. Then I'll run the repeatability test.

FWIW, The sensor I am using is this clone off of amazon,

[www.amazon.com]


yet-another-average-joe - you're above average, thanks

Well, it is not quite there yet.

It is no longer attempting to crash into bed but AUTOHOME is not always reliable. It always works on the first touch, then it backs z off and tries again with the second touch which is not always successful.

Sometimes the second touch works, it backs off 10mm and the display says the printer is ready. I call this success.

Sometimes the second touch fails and I get "homing failed machine halted please reset" message.

Sometimes the second touch works it backs off 10mm and the display status line reads STOPPED instead of READY.

I've tried to adjust the sensor height slightly to see if there is a sweet spot but it is hard to tell if there is any difference.

One thing I have noticed is that enabling BLTOUCH_FORCE_SW_MODE is the problem child. This is the cause of the original problem of it wanting to drive it into the bed.

I'm going to turn on the debug tracing and maybe I can find out what is going on.

Maybe you got a lemon... Or 3DTouc are lemons.

Had an earlier version, it was an absolute crap, and unusable. Never again !

Here's a test I did, dated may 2019 : BLTouch vs 3D Touch ; repeatability test, 4x with the BLTouch, 3x with the 3DTouch. Not sure commenting it is usefull !

OK, making more progress...

I slowed down the z speed during leveling
//#define Z_PROBE_FEEDRATE_FAST (4*60)
#define Z_PROBE_FEEDRATE_FAST (2*60)

// Feedrate (mm/min) for the "accurate" probe of each point
//#define Z_PROBE_FEEDRATE_SLOW (Z_PROBE_FEEDRATE_FAST / 2)
#define Z_PROBE_FEEDRATE_SLOW (60)

I also set MTOUCH_DELAY to 1200


I am still getting occasional errors (as seen in the repeatability test below). Autohoming, Z homing always seems to work fine.
However I was able to make it through a bed leveling session and setup my Z offset.

Attached below in pronterface capture of the repeatability test M48 V4, However you can see there was a error event.
But I think the repeatability is reasonable. Correct?


>>> G28
SENDING:G28
>>> M48 V4
SENDING:M48 V4
M48 Z-Probe Repeatability Test
Positioning the probe...
Bed X: 165.00 Y: 165.00 Z: -0.00
1 of 10: z: 0.002 Mean: 0.002496 Sigma: 0.000000 Min: 0.002 Max: 0.002 Range: 0.000
2 of 10: z: -0.000 Mean: 0.001246 Sigma: 0.001250 Min: -0.000 Max: 0.002 Range: 0.003
3 of 10: z: -0.000 Mean: 0.000829 Sigma: 0.001179 Min: -0.000 Max: 0.002 Range: 0.003
4 of 10: z: 0.002 Mean: 0.001246 Sigma: 0.001250 Min: -0.000 Max: 0.002 Range: 0.003
5 of 10: z: -0.000 Mean: 0.000996 Sigma: 0.001225 Min: -0.000 Max: 0.002 Range: 0.003
6 of 10: z: 0.002 Mean: 0.001246 Sigma: 0.001250 Min: -0.000 Max: 0.002 Range: 0.003
7 of 10: z: -0.003 Mean: 0.000710 Sigma: 0.001750 Min: -0.003 Max: 0.002 Range: 0.005
8 of 10: z: -0.000 Mean: 0.000621 Sigma: 0.001654 Min: -0.003 Max: 0.002 Range: 0.005
Error:!! STOP called because of BLTouch error - restart with M999
Error:!! STOP called because of BLTouch error - restart with M999

Errorrinter stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)
Errorrinter stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)

9 of 10: z: -0.005 Mean: -0.000004 Sigma: 0.002357 Min: -0.005 Max: 0.002 Range: 0.008
10 of 10: z: -0.008 Mean: -0.000754 Sigma: 0.003172 Min: -0.008 Max: 0.002 Range: 0.010
Finished!
Mean: -0.000754 Min: -0.008 Max: 0.002 Range: 0.010
Standard Deviation: 0.003172

Another thing I did (not sure it made a difference) was to solder a small 10uf electrolytic cap between power and ground on the sensor itself.

The idea here is because it's a large format machine and the long distance for the power wires then there is potential noise on the wires and the cap can help filter.
I figure it can't hurt anything.

I just can't believe it. It is the intermittent failure aspect that I just find difficult to fathom here. I've tried a million options today.

I've been an embedded software engineer for over 35 years. Everything tells me there is a software issue here.

I mean, how simple the operation is here? Uh.. extend probe,, reduce Z and then trigger. Retract. Do over....

You would have to pay me money to make it fail intermittent like it is doing now.

I don't want to pull it out and install an "official BLTOUCH" because I don't believe the issue is the sensor.

You're thinking EMF ?
Why not... But 10µF (electrolytic) should be maried with a ceramic (high frequency "aware") 0.1 µF...
Your repeatability test looks great...

Let me tell a story about EMF I'm facing right now. I built a RasPi cape/shield that displays the Marlin UI over Octoprint as a on screen display (in a overlay window, using low level RasPi GPU API's : 12864 emulator).
The bed is mains powered, through a static relay of course. I use a magnetic bed (magnetic mat + stainless sheet, the bed itself being glass with a silicone heater). When I touch the stainless sheet with the thinner skin of my arm, I can feel some electricity ; feels like static. And my RasPi shield (powered with a STM32) interprets it as a button press : toggles the on screen display ON/OFF. [EDIT] I still didn't earth the bed...
The cause is obvious : capacitive couplings all over the place.

Do you have some metal that could act the same, randomly ? Or magnets that could interfere with the Hall sensor ? (just an idea...)

BTW, why did you post on this sub-forum ? Some Marlin devs are watching the Marlin sub forum : you could get much more relevant answers than mine !!!
Maybe you could ask a moderator for moving your thread ?

Edited 1 time(s). Last edit at 04/12/2023 01:38PM by yet-another-average-joe.

Yeah, sorry for posting in the wrong sub-forum. I was new here and this initially seem like the right place.

I think I am getting close. There are several configuration options to disable heaters and fans during probing operations. I turned them on and it has made a difference,
I'll post my configuration files once I feel stable. Slowing down the z probing speed I think really helps with the repeatability.

I am able to get through the auto bed leveling and start a print now. But every once in a while an AUTOHOME will fail and I have to redo it.

And then there were other things that I noticed I needed, like z offset wizard and then octoprint reminded me that I didn't have the command pause/response stuff turned on and so forth...so all kind of code changes this morning.

I have a few more things to do. I have dual Z axis steppers and I would like the Z steppers to power on and stay on for the duration of the machine run time so they stay detent locked into position during idle states. I typically set each side even manually with a caliper when I first power up the machine. They will then stay synchronized thereafter

Today I noticed that one of the corexy belts had finally failed. These belts are steel cord re-enforced. I was always curious as to what the failure mode would be on these.

What happened was in one spot the steel cords frayed apart internally and broke The belt then stretches and narrows at that point. I had foreseen this day and I had purchased replacement belt a while back. While performing the series of upgrades the past few weeks (SKR v1.3, BIQ H2 direct drive extruder, 3d touch), I also replaced all the pulleys and PDM wheels/bearings.

The machine is 2018 vintage and has seen pretty regular use since that time. So you can figure about four years before needing a refresh on these items.

Edited 1 time(s). Last edit at 04/12/2023 11:04PM by brokencase.

I am just thinking of a parameter I completely forgot about : ENDSTOP_NOISE_THRESHOLD

Read this issue on Git : [github.com]

Scroll down : I had a similar issue !!! And have a look at the answer I was given by AnHardt, a Marlin team member.

Since then, in Configuration.h, I always have :

#define ENDSTOP_NOISE_THRESHOLD 2

This could be the solution. I verified your Configuration.h, this line is commented. Just un comment it, and see what happens. It worked for me. Since then, this line is uncommented in my Configuration.h, and I never had any problems. (to my knowledge, the "contact" in a BLTouch is just a MOSFET with a pullup? discrete or from the MCU output)

Edited 3 time(s). Last edit at 04/13/2023 10:15AM by yet-another-average-joe.

Just to give an update.

It is working pretty good now. I have done quite a few prints. I have not yet enabled and set ENDSTOP_NOISE_THRESHOLD. But I will give that a try.
It is strange. Auto home has rare occasional errors, but the 9 point bed leveling always works.

I have to say I really like this BIQ H2 direct drive extruder. A little trade off on the acceleration performance but well worth it in all other aspects.
The BIQU extruder stepper runs a little hot. Maybe around 130F. But I am running it a little below it's rated current.
I'm not sure how much of this heat is migrating from the hot end. I'm a little worried if I try to take the hot end up to around 280-325C.
Yes I have a PT1000 thermistor setup...and have raised max hot end temp to 325C. Plan was to try pure polycarbonate at some point in the future.

I had to rig up a couple lengths of 2x4 lumber and a piece of 1.5" pvc pipe to hold the spools above the printer.
I may try tweaking xy acceleration/jerk parameters to get a bit more speed.

See attached photo. Never mind the messy wiring in the background!

Geat !

I also recently ran into problems with my very old AntcLabs BLTouch v2.0 while switching to Klipper. Probing without retracting didn't work as expected. AFAIK this mode is supported by v2, but I could be wrong ! The old BLTouch had a cracked casing, so I finally replaced it for a brand new 3.1 (because of the bad experience with an earlier 3DTouch, and even if you showed great repeatability tests) ; now problems are gone, works like a charm.
The status "stowed/retracted" wasn't reported correctly or in time or was noisy; of course randomly ! Sounded a bit like what you were experiencing.

A great source of information about these devices : [www.klipper3d.org]
(also for 3DTouch and CRTouch)

It is about Klipper, but there's information about how the firmware(s) deals with these devices, and problems that could occur.

These things can be weird : with the old v2 I had errors that Klipper relates to v3.1. Of course, the Klipper fiix for the 3.1 didn't work for the v2 !

Can't remember if we talked about the heaters (didn't read again the whole thread). I remember that years ago I've been having problems with the noise generated by the PWM driven heaters (bed and/or hotend) ; at this time the problem was solved with an option that turned the heaters off when probing, and re-powers them between...

Quote
yet-another-average-joe

A great source of information about these devices : [www.klipper3d.org]
(also for 3DTouch and CRTouch)

It is about Klipper, but there's information about how the firmware(s) deals with these devices, and problems that could occur.

These things can be weird : with the old v2 I had errors that Klipper relates to v3.1. Of course, the Klipper fiix for the 3.1 didn't work for the v2 !

Can't remember if we talked about the heaters (didn't read again the whole thread). I remember that years ago I've been having problems with the noise generated by the PWM driven heaters (bed and/or hotend) ; at this time the problem was solved with an option that turned the heaters off when probing, and re-powers them between...

I should probably start exploring Klipper, however I am making parts that I sell and I find hard to invest the time to do the learning curve and switch over.
Especially if I am working satisfactorily.

Yes, turning off the heaters while bed leveling was a key item for making this work for me.

The other nice thing is that with the SKR board, I now have a separate driver for each of the two Z motors. I made the Marlin change such that the Z motors are always powered and detent locked. As a result I have noticed that my two Z motors are now staying "in sync" with each other.

With the original configuration it was a single driver for both motors, one motor was further away from the main board and would slowly drift away from the closer motor. It was never super problematic, I would always sync with a caliper before a print would start.

But now it is much better.

I'l post my configs shortly for the benefit of others.

Attached are Marlin-bugfix-2.1.x Configuration files for TronxyX5S Upgraded to BigtreeTech SKR v1.3 (2.5" TFT) with TMC2130 drivers, BIQU H2 extruder, PT1000 thermistor, and 3DTouch (BLTouch clone).

Been afraid of Klipper for years. Finally it's much easier to learn than Marlin. Tuning by trial and error is much faster as there's no need for compile/flash. At first I installed it because I wanted to use accelerometers for Marlin Input Shaping tuning ; didn't want to spend hours printing towers ; the plan was to have two sets of SD cards (SKR Pro 1.4 + RasPi) : one for Marlin + OctoPrint, the other for Klipper + Mainsail OS, using Klipper for measurements, then copy the values into Marlin. Never used the Marlin set again ! Learning Klipper was so easy and quick that I never looked back.
Now get 30 minutes Klipper benchies that look much better than the Marlin 1H30 ones. Prints at crazy speeds with no ringing, and tuning Input Shaper takes 10 minutes using the accelerometers ! And still room for more speed/acceleration. It's a bed slinger built with the frame and the bed from a Tevo Tornado (bed slinger, 2.3 kg Y cariage !), the head is a modded Voron Stealthburner : not lighweight by any means !. A real 3x faster.
Config files and precompiled firmwares are available for a bunch of printers, ready for use.
On the RasPi, I installed Mainsail, Fluidd and OctoPrint (3 web servers) ; all of them can be used simultaneously, it's just a matter of port behind the print server URL. I don't print for a living. But I'm sure that the time spent learning Klipper (a few hours) is worth it because of the time saved later on the first long run print.

Currently designing a device that will measure the BL-Touch z-offset at the begining of each and every print (usefull when swapping nozzles or toolheads). The software already exists as a plugin, no coding needed. (BTW also exists in RepRap firmware, as well as accelerometer based IS, no such things in Marlin AFAIK). Marlin most likely will need a OctoPrint plugin for auto-IS.

Edited 2 time(s). Last edit at 05/15/2023 05:27AM by yet-another-average-joe.

Looks like it is pretty easy to setup. I'll give it a shot. I have raspberry pi's setup on each of my printers.
My other FDM printer is an Aquila.

As far as speed goes, I'm not sure I want to go much faster. I'm printing functional parts and I need good layer to layer adhesion.
I also don't think I could speed up printing TPU any faster than I am doing so right now...and I print quite a bit of TPU.

But Kilpper appears to have many other benefits so I'll start investigating it.