Marlin: [BUG] BLtouch occasionally and randomly triggers incorrectly during probing.

[The3DE]

Bug Description

I am running the SKR mini E3 v2.0 with a BLtouch v3.1 and I am having problems with probing. Most of the time, probing is successful, but occasionally the probe fails to trigger correctly. The pin deploys, but when it contacts the bed, it doesn't trigger and retract, so the gantry continues to move down. Once it goes for about a millimeter, the probe flashes red a couple times and triggers, but it triggers over 1mm too low. This happens randomly and not very often. I am using UBL and when probing a 10x10 mesh about 1 point out of the 100 is incorrect each time. It also happened once during a G28 autohome when I was watching. I have verified that the wiring is correct, have tested 2 different BLtouch probes and cables, and checked that the 5v supply on the board is working, as well as changing various parts of the firmware, but the issue persists. If the probing is successful, everything else works, but I cant seem to stop it from not triggering correctly that ~1% of the time.

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.
Configurations.zip

Steps to Reproduce

1. Wire and set up BLtouch v3.1 with the SKR mini E3 v2.0
2. Test probing (I did this with the 10 point mesh in UBL)

Expected behavior: [What you expect to happen]
All points trigger correctly and return the correct values.
Actual behavior: [What actually happens]
Sometimes 1-3 points of the 100 trigger incorrectly and the returned value is over 1mm lower than expected.

Additional Information

Tried 2 different probes, cables, checked all the connections, and commented/uncommented various features and combinations and firmware with no effect. Error is random and not frequent (~1%) but doesn't go away. An incorrect probe during autohome will mess up the z offset.
Using the latest version of Bugfix 2.0.x

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[GMagician]

I suggest you to enable ENDSTOP_INTERRUPTS_FEATURE and give a try.
OT: how did you get the graph you posted?

[The3DE]

I’ll try to enable interrupts but I don’t know if it would change anything since the BLTouch itself doesn’t trigger at those points, and it’s not that the board doesn’t detect the trigger, at least that’s what I think.

I got the graph from the bed visualizer plugin in octoprint.

[GMagician]

If bl-touch doesn't trigger I suspect Marlin can do nothing to solve it

[The3DE]

It only occasionally happens and I’ve gone through 2 different BLTouches as I though the sensor was defective, both both show the same behavior and others have reported this problem as well. I think that it is a problem with marlin sending commands to the BLTouch.

[GMagician]

mmmm now sure but when Marlin stow bl-touch doesn't trigger error (red led blink) it seems like the trigger is missed and interrupt may help

[qwewer0]

I have the same issue, with BLTouch v3.1, SKR Mini E3 v1.2.

Standard deviation 0.0015+-0.0005
With DEBUG_LEVELING_FEATURE and M114_DETAIL enabled,
BLTouch ALARM or TRIGGER after STOW recovering-M48_S1_V4.txt
Edit: Configuration.zip

Will test ENDSTOP_INTERRUPTS_FEATURE and give feedback.

[GMagician]

ok I see it:

READ: BLTouch STOW requested
READ: BLTouch Command :90
READ: BLTouch ALARM or TRIGGER after STOW, recovering
READ: BLTouch Command :160
READ: BLTouch Command :90
READ: bltouch.stow_proc() end

[qwewer0]

With ENDSTOP_INTERRUPTS_FEATURE enabled, I run M48 P50 six times without any bltouch alarm. (4 with BLTOUCH_HS_MODE and 2 without.)
Can't say that it fixed the issue until I made a lot more probing with different speeds and settings.

[qwewer0]

Got a bltouch error, but it is not the same as before:

READ: BLTouch STOW requested
READ: BLTouch Command :90
READ: bltouch.stow_proc() end
READ: >>> do_blocking_move_to X158.8600 Y121.0700 Z7.4850
READ: <<< do_blocking_move_to
READ: //action:notification Probing Failed
READ: Error:Probing Failed
READ: <<< Probe::probe_at_point
READ:   current_position= X158.8600 Y121.0700 Z7.4850 : Probe::set_deployed
READ: deploy: 0

[GMagician]

This error seems related to probe not deployed when required. Can you post something before?

[qwewer0]

@GMagician Thanks for the help.
Here is the whole M48:
M48 V4 P50.txt

Edit: It's with BLTOUCH_HS_MODE enabled.

[GMagician]

here it is:

READ: SLOW Probe fail! - No trigger.

[qwewer0]

Thanks, did not saw that.
But I don't really know what any of the fails could mean.

[GMagician]

not sure but maybe increase a little bit Z_PROBE_LOW_POINT. It can also be that ibl-touch doesn't trigger for real...

[qwewer0]

By 'increase' you mean decrease, right?

[The3DE]

I’ve just started testing with endstop interrupts enabled and so far it’s successfully probed a 10 point grid and a standard M48 with 10 points gives a SD of ~.0011. I’ll continue testing to see if any issues come up. I enabled 5V mode and set z_min_probe_endstop_inverting to false. I also just successfully completed a M48 P50. High speed mode is off.
When the printer powers on the BLTouch does it self test but then deploys, flashes red a few times quickly, and then retracts and goes back to normal, is this behavior supposed to happen?

[qwewer0]

The quick flashes at the start is the indication of the 5V mode.

[qwewer0]

Before this, I had 1-2 failed probing out of 100, but now I had 0 out of +1000 (M48), and was able to probe 7*7 UBL mesh two times without any issue.
So far so good.

@GMagician Could you please explain why could have ENDSTOP_INTERRUPTS_FEATURE helped, and what it does?

Enable this feature if all enabled endstop pins are interrupt-capable.

And how can I check if I would be able to use it on a different board?

[The3DE]

I am guessing that the board has missed the trigger pulse from the BLTouch, which caused the previous problems. Interrupts would fix this as it would be able to sense the change in state of the pin reliably. I also am having very good success after enabling this, so far no fails on a few 10x10 meshes in UBL and a few M48s.

[ManuelMcLure]

Another option is to enable BLTOUCH_FORCE_SW_MODE which makes the BLTouch always show triggered when retracted instead of just generating a short pulse. This makes it act more like a conventional micro switch endstop.

[qwewer0]

Another option is to enable BLTOUCH_FORCE_SW_MODE which makes the BLTouch always show triggered when retracted instead of just generating a short pulse. This makes it act more like a conventional micro switch endstop.

@ManuelMcLure Will try that too, thanks.

[GMagician]

@qwewer0 interrupt is a fast way to detect input. Once input pin changes it's state cpu is redirected to check it. Standard mode checks input (endstop) on a 1KHz base frequency (into temperature code) so you may miss a signal that changed very quickly (bltouch trigger)

and yes increase the number but since it's negative decrease is a best description. Sorry for that

[The3DE]

I don't know why but the triggering problem came back. I have attached my current configs. I have interrupts enabled and it seemed to work, but then I switched to a different sensor and it failed to trigger again. I then switched back to the sensor that had worked but it didn't fix the problem. I have 5v mode enabled, but the probe no longer does the deploy, flash, and stow sequence at the start for some reason.

I also tried enabling force SW mode, and I briefly tested it without failure, but it caused my standard deviation to be > .01, around .03 from what I remember, so I switched it back off.
Edit: I had endstop interrupts enabled with SW mode.

Should I try decreasing z_probe_low_point or is that for another issue?

Configuration.zip

[GMagician]

5V mode... is your board a 5V tolerant input?

[GMagician]

Should I try decreasing z_probe_low_point or is that for another issue?

May be increased when probe stow & deploy correctly but Z moves down and probe doesn't reach the "trigger position" you have to see a failure like the one posted above. It seems not your situation.
Now I don't know what is different between SW and 5V mode on bltouch, I have a old V2.0 (clone), I need to read documentation about it.
But all these seems a configuration issues, not related to Marlin. I think it's better to move to discord (but I'm not there often)

[The3DE]

The problem is that I'm not really sure what the issue really is, as I couldn't find much about it when doing a search. My board is 5V compatible.
I am pretty sure that SW mode just causes the trigger pulse to be longer and act like a conventional switch, and that 5V mode doesn't effect it.
I don't know whether the probe itself isn't triggering correctly or the mainboard isn't detecting the trigger pulse, and at this point I'm not even sure if its a hardware or software issue, even though I tested 2 separate BLTouches. I wish I had a video of it failing but it is random and infrequent so I can't predict when it'll fail and I don't want to record a whole M48 P50 and hope that I catch it.
I can try asking on discord to see if anyone else has any idea.

[kmobs]

I had this issue consistently on the 1.2 version of this board. The stock configs puts the stepper current very high in the config. I dropped the x and y to 580 and the z to 600. I also recommend making sure your belts aren't too tight. I think it's power related with the BLtouch pin.

After changing these things I get near 0 failures. I don't think it's really a software Marlin issue and more a problem with power to the board/BLTouch.

[GMagician]

@kmobs yours can be a solution. PWM and high current generates electric noise.
High drain may lower 5V if PSU is not "big" enough or board has bad traces and bl touch may have issues...

[cjsoong]

@GMagician
You can add a 10~22uf capacitor to the 5v & GND of BLtouch, which can stabilize the BLtouch power supply..

@kmobs yours can be a solution. PWM and high current generates electric noise.
High drain may lower 5V if PSU is not "big" enough or board has bad traces and bl touch may have issues...

[kmobs]

@cjsoong that's a good idea. Not sure if this is truly the reason, but seems to have mostly solved my issues. Hopefully not just a coincidence

[The3DE]

My stepper current is currently set to 580 on all 3 axis. I can try putting a capacitor on the power pins for the BLTouch.
Are you running the BLTouch in force sw mode?

[The3DE]

I put a 10uF electrolytic capacitor across the 5V lines and it didn’t fix the problem. I’ll leave it on there since it probably doesn’t hurt but I don’t think it’s an issue with the power supply.

[The3DE]

I uncommented force SW mode and so far no fails. The SD is greater than before (.012 vs .002 before), and the range has increased to ~.07. I think this means that where it would previously fail, since it is in SW mode, the board can detect the trigger, but it detects it a bit late, so the trigger point is about .07mm lower than it should be. This is improved from it completely missing the trigger, but I'm wondering if there is any way to decrease this inaccuracy. I have already slowed probing speeds down and it seems to be moving pretty slow, any slower and probing would take way too long. The only way I can think of to work around this is to enable multiple and extra probing in order to invalidate the inconsistent probes, along with slowing down the homing validation speed by a lot.

[The3DE]

It seems that the board is slow to respond to the pin’s change in state sometimes, even with interrupts enabled, any idea what’s causing this?

Edit: could it be that my SKR mini E3 v2.0 is defective somehow? I think that this is unlikely but I’m not sure.

[kmobs]

@The3DE no I'm not using SW mode. I did force 5V mode though. Look at my repo for my current config

[GMagician]

I read that with big condenser on input may give problems to bl-touch. Sure is not your case? on antclabs site there are some fixes to apply in such cases

[sjasonsmith]

It seems like we have two possible solutions for this:

1. Enable ENDSTOP_INTERRUPTS_FEATURE, although it might not be an option for all boards.
2. BLTOUCH_FORCE_SW_MODE

Is anybody still experiencing issues with one of these enabled, or can this be closed as a configuration issue?

[The3DE]

@GMagician a capacitor on the 5V power lines doesn’t effect it, that refers to the capacitor on the sensor input. The dedicated probe pin for the BLTouch doesn’t have this capacitor, so I might try to switch the zmin endstop pin and the probe pin in the pin configurations and plug the BLTouch into the probe pin to see if it helps.

I am not getting any failed probes, but I have discovered that the inaccuracies I am getting is from it occasionally probing about .07mm lower than expected. This is way better than the ~1.3mm from before, As it doesn’t cause the nozzle to crash, but .07mm is still somewhat troubling as that can be half a layer height. I will try to test some things to see if this can be reduced, but enabling multiple and extra probing would be able to work around it. I believe that this is the result of the board occasionally being slow to detect and respond to the change in the endstop pin, even with interrupts enabled. Other than those times it probes low, the BLTouch is very accurate and repeatable.

I also still haven’t ruled out that this is an issue with my board and not the firmware or configs, so I got a capacitive probe and I will test it to see if it has the same problems as the BLTouch, in which case my board might just be defective, or this issue applies to z probes in general and is not exclusive to the BLTouch.

[GMagician]

@The3DE the capacitor on 5V supply is to keet 5V stable when someone drain current. The one I was refering to was on input but since you don't have it, it's better. Don't move to endstop.
With interrupt is really hard to think board is "slow" to detect (only reason is an interrupt with higher priority).

[The3DE]

I looked at the schematic and the SKR mini E3 v2.0 has a .1uF capacitor on the z endstop input. The probe input, however, doesn’t have this capacitor. That is why I thought of trying to redefine the probe input as the z endstop input in the pin configs and using that to see if anything changes.

As far as the interrupts, I am puzzled by that too, but I have seen others get better results with interrupts disabled, so I might try that to see if anything changes.

[kursatu]

My 2cents. I also had such problems with Skr 1.3, 1.4, & turbo boards, bl touch dropping pin, not dropping during probing etc. Tried bunch of stuff , capacitors, supercapacitors, SW_MODE, looked at the defect related rto LPC boards, platform code etc.
It turned out to be EMI (elctromagnetic interference), well at least portions of it.
The problem was quickly reproducible.
Changed the heater cable to be twisted pair I've made from speaker wires , it helped a lot.
I am still waiting twisted pair cables to replace all the other wires. It sill happens but a lot less.

[The3DE]

@kursatu Did this only happen with heaters on? When I tested the BLTouch most of the time it was with the bed and hotend off.

[ManuelMcLure]

One thing to check is if the servo port that the BLTouch is connected to outputs 5V or 3.3V signals. If it outputs 3.3V this could be a bit too low for the BLTouch. That's one reason I added a 3.3V->5V level shifter when I connected my BLTouch to my Re-ARM/RAMPS combination.
If nothing else, using 5V signals should make them more resistant to interference.

[The3DE]

I'm pretty sure that the SKR is a 3.3v board as it is based off a STM32, but it can work with a BLTouch in force 5v mode, so I'm not totally sure. I looked at the schematic and pinouts and the BLTouch connections don't go to 5v tolerant pins, but it works in 5v mode, and is even default in the example Marlin has for the board. However, I am pretty sure that the board still outputs 3.3v on all pins, so I might try to add a level shifter to see if that helps.

[kursatu]

@The3DE Yes, it did happen with the heaters. I was able to conclusively isolate it as a contributor.
Your case might differ, apparently.

[ManuelMcLure]

In this case it’s not the output signal from the BLTouch that’s the problem but rather the input signal that controls it. The BLTouch is powered from 5V so it’s expecting 5V TTL signal levels and 3.3V is just on the edge of 5V logic high so it may work sporadically.

[qwewer0]

With ENDSTOP_INTERRUPTS_FEATURE I get error less often, and maybe a different kind.
Here is one with BLTOUCH_HS_MODE:

READ: SLOW Probe fail! - No trigger.
READ:   current_position= X158.8600 Y121.0700 Z-0.5150 : <<< run_z_probe
READ:   current_position= X158.8600 Y121.0700 Z-0.5150 : Probe::set_deployed
READ: deploy: 0
READ: Probe::move_z(6.0000)
READ: >>> do_blocking_move_to X158.8600 Y121.0700 Z7.4850
READ: <<< do_blocking_move_to
READ: BLTouch STOW requested
READ: BLTouch Command :90
READ: bltouch.stow_proc() end
READ: >>> do_blocking_move_to X158.8600 Y121.0700 Z7.4850
READ: <<< do_blocking_move_to
READ: //action:notification Probing Failed
READ: Error:Probing Failed

With BLTOUCH_FORCE_SW_MODE I didn't get errors yet, but that doesn't mean anything, as at first that was my experience with ENDSTOP_INTERRUPTS_FEATURE too, so we will see in the long run.
But what bugs me is that the standard deviation goes from ~0.002 to ~0.02 with BLTOUCH_FORCE_SW_MODE.

[The3DE]

@qwewer0 I have that same problem with standard deviation in SW mode too and it is also bugging me. I haven't had any fails yet, but the SD has increased to around the same as yours. Looking at the actual data from the probes, it is mostly consistent, but occasionally there is an outlier that causes the SD to be so high. What is the range you are getting, along with the min and max? My range with SW mode on is about .07, with max being around 0 and min being around -.07. I looked at the points and sometimes they were around .07mm too low. I think this is because SW mode stops the probe and board from missing the trigger completely, but it is still late to detect the trigger, so the late reaction causes the point to be around .07mm too low. This means that SW mode makes the previous problem a lot better, but still doesn't solve it completely as it is still probing outliers.

[GMagician]

As stated before I don't have an original bl-touch (but I will, an original 3.1). I read on web site that new 3.1 has a programmable trigger duration.
Since, AFAIK, sw mode works like a switch (then I think once it triggers it keeps the signal) and this mode has SD issues (I don't find a reason for that), other mode may be programmed to avoid trigger miss but I'm not sure Marlin support duration programming

[The3DE]

@GMagician I don’t think that the standard deviation issues are because of SW mode, but actually still with the board sensing the BLTouch trigger. In my comment above, it says that the reason the SD is high is because there are outlier low points. Increasing the trigger duration would lead to the same issue in my opinion.

[qwewer0]

What is the range you are getting, along with the min and max?

READ: Bed X: 116.0000 Y: 115.0000 Z: -0.0025
READ: 1 of 9: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000
READ: 2 of 9: z: -0.072 mean: -0.0387 sigma: 0.033750 min: -0.072 max: -0.005 range: 0.067
READ: 3 of 9: z: -0.003 mean: -0.0267 sigma: 0.032425 min: -0.072 max: -0.003 range: 0.070
READ: 4 of 9: z: -0.003 mean: -0.0206 sigma: 0.029967 min: -0.072 max: -0.003 range: 0.070
READ: 5 of 9: z: -0.003 mean: -0.0170 sigma: 0.027767 min: -0.072 max: -0.003 range: 0.070
READ: 6 of 9: z: -0.005 mean: -0.0150 sigma: 0.025739 min: -0.072 max: -0.003 range: 0.070
READ: 7 of 9: z: -0.005 mean: -0.0136 sigma: 0.024085 min: -0.072 max: -0.003 range: 0.070
READ: 8 of 9: z: 0.000 mean: -0.0119 sigma: 0.022972 min: -0.072 max: 0.000 range: 0.072
READ: 9 of 9: z: -0.005 mean: -0.0111 sigma: 0.021766 min: -0.072 max: 0.000 range: 0.072
READ: Finished!
READ: Mean: -0.011111 Min: -0.072 Max: 0.000 Range: 0.072
READ: Standard Deviation: 0.021766

[The3DE]

So you are getting the same results as me, where the BLTouch occasionally probes low by around .07mm. Anyone know how to fix this?

[sjasonsmith]

Do you have MONITOR_DRIVER_STATUS enabled in Configuration_adv.h? If so, try disabling it.

[The3DE]

@sjasonsmith I do have MONITOR_DRIVER_STATUS enabled, and I can try disabling it, but would doing so be a safety concern/ risk damaging the Trinamic drivers?

[sjasonsmith]

It mainly won’t reduce current if they are getting too hot. I never enable it, because it is a lot of overhead. Looking at the code, disabling probably won’t help the standard deviation, but it should be easy to test.

[qwewer0]

Tried it with MONITOR_DRIVER_STATUS disabled, and it gives kind of the same result.

READ: Bed X: 116.0000 Y: 115.0000 Z: -0.0050
READ: 1 of 9: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000
READ: 2 of 9: z: -0.003 mean: -0.0038 sigma: 0.001250 min: -0.005 max: -0.003 range: 0.002
READ: 3 of 9: z: -0.115 mean: -0.0408 sigma: 0.052454 min: -0.115 max: -0.003 range: 0.112
READ: 4 of 9: z: -0.005 mean: -0.0319 sigma: 0.048003 min: -0.115 max: -0.003 range: 0.112
READ: 5 of 9: z: -0.003 mean: -0.0260 sigma: 0.044514 min: -0.115 max: -0.003 range: 0.112
READ: 6 of 9: z: -0.005 mean: -0.0225 sigma: 0.041382 min: -0.115 max: -0.003 range: 0.112
READ: 7 of 9: z: -0.005 mean: -0.0200 sigma: 0.038799 min: -0.115 max: -0.003 range: 0.112
READ: 8 of 9: z: -0.005 mean: -0.0181 sigma: 0.036631 min: -0.115 max: -0.003 range: 0.112
READ: 9 of 9: z: -0.003 mean: -0.0164 sigma: 0.034883 min: -0.115 max: -0.003 range: 0.112
READ: Finished!
READ: Mean: -0.016389 Min: -0.115 Max: -0.003 Range: 0.112
READ: Standard Deviation: 0.034883

I don't really like the SD value, but the inconsistency is the worse.

[GMagician]

In my comment above, it says that the reason the SD is high is because there are outlier low points. Increasing the trigger duration would lead to the same issue in my opinion.

I think I'm lost...sorry to ask, It's a probelm of mine, can you repeat what is the problem now so that I that join all my lost points?

[The3DE]

@GMagician if you look at the data from qwewer0 you can see that most of the probes are accurate, but there is one probe that is too low. That is the reason the standard deviation is high. I don’t think that this is an issue with SW mode for the BLTouch, but actually with the board being late to respond to the probe signal, which would mean that reprogramming the pulse length wouldn’t fix it, even in the default mode.

[The3DE]

The problem is that it sometimes probes too low, with SW mode off, it is usually low by about 1.3mm, and with SW mode on, it is usually by around .07mm. This means that while SW mode helps, it doesn’t fix the issue.

[GMagician]

ok, thanks, there should no difference between SW or not SW mode seen on Marlin side when interrupts are on. It may be different when they are off (when non sw mode may miss some trigger) but now where does come's from your "0.07mm" too low? do you home and check nozzle real pos on the same point?
Sorry again but I need to correctly understand

[The3DE]

When doing a M48 probe test the range is usually around .07, with the max being around 0 and the min being around -.07. This is where I got the .07 from. I also confirmed this by probing a 7x7 mesh 4 times. Most of the points were consistent, but there would be some random points that were about .07mm too low when compared to the other meshes.

[The3DE]

M48 probes the same point a set number of times and tells you the min, max, mean, and standard deviation of all the probes values. It is used for testing the reliability and repeatability of the probe.

[The3DE]

READ: Bed X: 116.0000 Y: 115.0000 Z: -0.0025
READ: 1 of 9: z: -0.005 mean: -0.0050 sigma: 0.000000 min: -0.005 max: -0.005 range: 0.000
READ: 2 of 9: z: -0.072 mean: -0.0387 sigma: 0.033750 min: -0.072 max: -0.005 range: 0.067
READ: 3 of 9: z: -0.003 mean: -0.0267 sigma: 0.032425 min: -0.072 max: -0.003 range: 0.070
READ: 4 of 9: z: -0.003 mean: -0.0206 sigma: 0.029967 min: -0.072 max: -0.003 range: 0.070
READ: 5 of 9: z: -0.003 mean: -0.0170 sigma: 0.027767 min: -0.072 max: -0.003 range: 0.070
READ: 6 of 9: z: -0.005 mean: -0.0150 sigma: 0.025739 min: -0.072 max: -0.003 range: 0.070
READ: 7 of 9: z: -0.005 mean: -0.0136 sigma: 0.024085 min: -0.072 max: -0.003 range: 0.070
READ: 8 of 9: z: 0.000 mean: -0.0119 sigma: 0.022972 min: -0.072 max: 0.000 range: 0.072
READ: 9 of 9: z: -0.005 mean: -0.0111 sigma: 0.021766 min: -0.072 max: 0.000 range: 0.072
READ: Finished!
READ: Mean: -0.011111 Min: -0.072 Max: 0.000 Range: 0.072
READ: Standard Deviation: 0.021766

You see how probe 2 is about .07mm too low while the other probes are consistent, that is currently the main problem.

[GMagician]

mmm this is clearing a lot of clouds...I'm tring to level my bed on my printer and I get different mesh every time...now I'm doing it manually and I see that also Z homing is not always on the same position. I given blame to my bl-touch clone (and this is why I bought an original one) but maybe there is something more...

[The3DE]

I’m getting a capacitive probe to test. If this issue is still present with the capacitive probe, that would mean that there is nothing wrong with the BLTouch and that either the board or the firmware is the problem.

[GMagician]

I use another board than yours...

[The3DE]

@GMagician what board are you using?

[GMagician]

AGCM4 + Ramps 1.4.4

[sjasonsmith]

I think we need to use a logic analyzer to monitor the pulse, and measure how long the board takes to respond. Initially watching the servo output change is good enough, but we might need to add outputs to let us see exactly when the end stop is detected.

This may be caused by something like the temperature interrupt firing just as the end stop is triggered.

[qwewer0]

Just for clarification, on SKR Mini E3 v1.2, should I use PROBE (PC14) instead of Z-STOP (PC2) for BLTOUCH_SET_5V_MODE?

[sjasonsmith]

@The3DE I was hoping to reproduce this, so that I could debug what is happening during that delay.
On my SKR E3 Mini 1.0 I'm not seeing as large of a deviation as you are, whether I use SW mode or not.
When I have a bit more time I will compare our configs to see if I find notable differences that might impact it.

Not using interrupts. Not using SW Mode.

M48 P50
Recv: Finished!
Recv: Mean: 0.001650 Min: -0.003 Max: 0.007 Range: 0.010
Recv: Standard Deviation: 0.002480


Not using interrupts, in SW Mode

M48 P50
Recv: Finished!
Recv: Mean: 0.011100 Min: 0.007 Max: 0.015 Range: 0.007
Recv: Standard Deviation: 0.001743

[The3DE]

It’s not really the standard deviation that bothers me, but the range. If it randomly probes a point a lot lower that the rest, it could cause problems.
When I don’t use SW mode the deviation is usually lower, but if it fails a probe deviation increases significantly, to around .1. In SW mode, the deviation is higher, but it never fails entirely, so I would say that it is actually an improvement. I might look at the schematic of the v1.0 and 2.0 and see if there are any hardware differences that might be causing the issue.

[sjasonsmith]

Well, my range is not approaching anything near yours. I am using it in the Z- connector, I have not modified the board at all.

[The3DE]

The only hardware difference I could spot between the boards regarding the z limit input is that the v1.0 has a 1k series resistor in series with the stm32 input pin and the v2.0 has a 100 ohm one in series instead of 1k. Also the dedicated probe port on the v1.0 has a pull-up and a .1uF cap while the v2.0 does not, but since we are not using the dedicated probe port, this should not matter.

[The3DE]

I added a 10uF cap on the 5V rail, but this should not be causing any problems. I can also remove it easily if necessary.

[kmobs]

@qwewer0 I use the z port.

[The3DE]

Has anyone been able to make any progress in figuring out the issue so far? I got a capacitive probe to test in order to see if it has the same problem as the bltouch, but I will be able to test it in a couple days as I need to get it set up.

[etjensen]

I discovered this thread while trying to solve what seems like the same/similar problem (BLTouch 3.1, SKR Mini E3 v1.2, Ender 3 Pro) running Bugfix 2.0.x. My other system is similar but was running 2.0.5.3 release, and I had not noticed any similar problem. Yesterday I built a 2.0.5.3 for this system and so far it seems to be working without issue- running M48 and G29 tests seems fine. Admittedly tricky as the problem was intermittent but wondering if others have tried this. Not sure if this is an option for the v2.0 SKR board though.

[qwewer0]

I had the same problem on 2.0.5.3 too. (v1.2)

[Dracrius]

I can also confirm this issue is 2.0.5.3 but not in 2.0.4.1 my previous version running identical marlin bltouch setting does not show the same random dips. Possibly related is a second issue i note in #18598 where if i enable Multiple Probing to try and compensate it completely fails on a random second probing causing an m112 printer halt.

[Dracrius]

@The3DE It may very well be your Configuration_adv.h

define ADAPTIVE_STEP_SMOOTHING

and or

define SLOWDOWN_DIVISOR 8

Through my testing over night I was able to work it down to only these two settings. I am busy today and can't test more but I checked your config from your original post and you have both these settings and if you check through my bug report you'll see how I got to those settings and when returned to default

//#define ADAPTIVE_STEP_SMOOTHING
and

define SLOWDOWN_DIVISOR 2

I had about an hours worth of repeatable flat bed meshes but otherwise I can replicate the random miss probing.

[qwewer0]

for 2.0.5.3, I had at first //#define ADAPTIVE_STEP_SMOOTHING and #define SLOWDOWN_DIVISOR 2, with the same problems as now, so I'm a bit confused now.

[Dracrius]

@qwewer0 when reading through your post you meantion the bltouch alarm going off so I think you may be experiencing either 2 problems or a diffrent one. The only time i get a Bltouch alarm that i think may be related was with multiple probing enabled and then it would at random fail mid air before one of the second taps with a bltouch alarm.

Otherwise this bug as best i can tell is best seen using Octoprints Bed Level Visualizer plugin or very closly reading your grid as the result is a sucsessful probing grid but with a random massive dip that if printed with would push the nozzle into the bed.

[qwewer0]

Yeah, I might have a different problem.
When my BLtouch worked it produced good results, but I randomly got failed probing without any value on that point.
ENDSTOP_INTERRUPTS_FEATURE might have helped, as when I tested it I got 1 error out of 1000+ probing instead of 1-2 out of 100.

[The3DE]

@Dracrius

//#define ADAPTIVE_STEP_SMOOTHING
and

define SLOWDOWN_DIVISOR 2

So should I change it back to this? Also, did you have endstop_interrupts_feature and/or force SW mode on for the BLTouch, or were your other settings default? I’ve made a lot of changes and I am starting to lose track of them, would it be better to just start with the example configs marlin has for the SKR mini E3 v2.0 and adjust them? That way most of it would be default and should work.

[Dracrius]

@Dracrius

//#define ADAPTIVE_STEP_SMOOTHING
and

define SLOWDOWN_DIVISOR 2

So should I change it back to this? Also, did you have endstop_interrupts_feature and/or force SW mode on for the BLTouch, or were your other settings default? I’ve made a lot of changes and I am starting to lose track of them, would it be better to just start with the example configs marlin has for the SKR mini E3 v2.0 and adjust them? That way most of it would be default and should work.

Yes id try reseting those to default but it may be better to start from scratch. If youd like I maintain a txt file that lists all my personal changes for ease of upgrading I could add it so you can try my settings on the SKR mini E3 v2.0 example.

To be clear though i do not have endstop_interrupts_feature and/or force SW mode on. From what i can tell this is a bug in adaptive sync maybe slowdown devisor but i'm guessing that causes an issue with readings as I was able to start having isses and stop having them just by switching from one build with those settings changed to enabled and 8 respectivly to one that had them set to default.

These two settings are not supposed to relate to the bltouch though so its very strange.

[ASuarez27]

I was having the same issue with the sudden dips using the SKR mini E3 v2.0. I disabled ADAPTIVE_STEP_SMOOTHING and that seems to have cleared it up. Now I'm getting more of an accordion on the bed visualizer.

ADAPTIVE_STEP_SMOOTHING Enabled

ADAPTIVE_STEP_SMOOTHING Disabled

Recv: Bilinear Leveling Grid:
Recv: 0 1 2 3 4 5 6
Recv: 0 -0.025 -0.052 +0.005 -0.007 -0.032 -0.057 -0.128
Recv: 1 -0.237 -0.145 -0.075 +0.045 +0.078 +0.130 +0.140
Recv: 2 -0.060 -0.045 -0.045 -0.025 -0.015 -0.050 -0.105
Recv: 3 -0.262 -0.157 -0.102 -0.037 +0.035 +0.060 +0.068
Recv: 4 -0.027 -0.005 -0.003 +0.025 -0.005 -0.047 -0.108
Recv: 5 -0.220 -0.142 -0.088 -0.030 +0.013 +0.028 +0.035
Recv: 6 +0.078 +0.078 +0.080 +0.057 +0.037 -0.020 -0.065
Recv:
Recv: X:235.00 Y:235.00 Z:15.19 E:0.00 Count X:18800 Y:18800 Z:5996

[The3DE]

@ASuarez27 It seems like turning off adaptive step smoothing fixed the dips, but the accordion was still there even with it on. Are you sure that it is not just your bed, even though that is unusual, and have you tried with more points?

[ASuarez27]

@The3DE I was originally using a 5x5 grid. The pictures are from a 7x7 grid. I've tried the bed leveling with the plain bed, glass bed, Ender 3 Pro magnetic bed. Results are mostly the same. If I look at the probe while it's doing the bed leveling, it seems to trigger a little later on the lower spots. Same as with the big dips but not as easily spotted. It's strange that it's so uniform though.

I currently have it setup using the Z endstop, I was thinking of switching it over later today to the dedicated probe port to see if it acts the same.

[The3DE]

I’m not really an expert in this so I have no idea what could be causing that, but it is strange that the pattern is so regular. I use UBL, have you tried that?

[sjasonsmith]

I saw adaptive step smoothing trigger another issue in a different PR. I am not even suggesting they are related at this point, but that is At least an interesting coincidence...

[Dracrius]

@The3DE I was originally using a 5x5 grid. The pictures are from a 7x7 grid. I've tried the bed leveling with the plain bed, glass bed, Ender 3 Pro magnetic bed. Results are mostly the same. If I look at the probe while it's doing the bed leveling, it seems to trigger a little later on the lower spots. Same as with the big dips but not as easily spotted. It's strange that it's so uniform though.

I currently have it setup using the Z endstop, I was thinking of switching it over later today to the dedicated probe port to see if it acts the same.

You shouldn't worry about changing ports. I ran mine one the z endstop since day one on all other builds without issues. This is most deffinitly a firmware issue not hardware. Also atleast on the e3 1.2 if you look up the curcit diagrams the probe and endstop ports are wired the same.

@ASuarez27 have you changed your Slowdown_Divisor at all? The other thing to note is once it becomes consistent the graph can make it look worse then it really is, the issue in question appears to really cause random insanely bad inconsistancies.

[Dracrius]

@The3DE This lists all changes I make to the example configs. Most of it is personal like temps, Machine name and z Max height and I also left in the settings I had changed that appear to cause it but noted the defaults they should be returned to.
Marlin Firmware Changes.txt
Edit: Boiled it down to just Adaptive Step Smoothing

[sjasonsmith]

M48 P50
Recv: Finished!
Recv: Mean: 0.011100 Min: 0.007 Max: 0.015 Range: 0.007
Recv: Standard Deviation: 0.001743

I just re-ran this with ADAPTIVE_STEP_SMOOTHING enabled, and results were much worse:

M48 P50
Recv: Finished!
Recv: Mean: 0.010500 Min: -0.150 Max: 0.060 Range: 0.210
Recv: Standard Deviation: 0.046532

[italocjs]

I had a lot of these issues, mostly was fixed by soldering a 10nf cap between signal and ground on the bltouch board. not sure if its the same cause but its worth a try

[thinkyhead]

A patch has been merged. Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[sjasonsmith]

@The3DE, have you had a chance to test the bugfix-2.0.x branch yet? I believe your issue will be fixed.

I would like to close this issue out if your problem is resolved. I recognize that other people may still have issues with non-STM32F1 boards, but there are plenty of other issues remaining open for other boards.

[The3DE]

I have not tested the new bug fix branch yet but I have been using the BLTouch with adaptive step smoothing disabled and so far have had no problems. Would the bugfix-2.0.x branch allow adaptive step smoothing to be enabled?

[sjasonsmith]

I have not tested the new bug fix branch yet but I have been using the BLTouch with adaptive step smoothing disabled and so far have had no problems. Would the bugfix-2.0.x branch allow adaptive step smoothing to be enabled?

Probing should be fine with ADAPTIVE_STEP_SMOOTHING, but depending on your combination of features it may cause other issues. Currently ADAPTIVE_STEP_SMOOTHING is too aggressive, and tries to consume 100% CPU usage. If you read this comment from AnHardt on #18598, there is a snippet of code changes you can make if you want to reduce the CPU load from ADAPTIVE_STEP_SMOOTHING.
https://github.com/MarlinFirmware/Marlin/issues/18598#issuecomment-657451656

As for this issue, I'd like for you to close it yourself after you have had a chance to verify that bugfix-2.0.x fixes the issue. For that testing you can enable adaptive step smoothing, since it makes the problem much more likely to occur, and better verifies the fix.

If you are not interested in testing the new bugfix-2.0.x code, then we can close this, presuming it is fixed for you as it is for others with similar hardware.

[The3DE]

I have tested the latest bugfix 2.0.x branch and it seems to work fine. I had high speed mode enabled but adaptive step smoothing disabled, so I don’t know if adaptive step smoothing still causes problems. Has the issue with adaptive step smoothing using 100% cpu been fixed yet? If so I can test it with adaptive step smoothing enabled, but if it hasn’t, I think it is safer to just leave it disabled even if it no longer interferes with BLTouch probing, as it might cause other problems.

Edit: with HS mode enabled and adaptive step smoothing disabled, a M48 P50 returns a SD of ~.002 and a range of <.01.

[sjasonsmith]

@The3DE a change went in a day or so ago to reduce the CPU load from step smoothing. It’s up to you whether you want to go out of your way to test with it enabled.

If you are satisfied that the current code is working please go ahead and close this issue.

[The3DE]

I have tested again with step smoothing enabled using the latest version of bugfix 2.0.x and everything is working.
M48 P50 gives:
Mean: -0.000399 Min: -0.005 Max: 0.005 Range: 0.010
Standard Deviation: 0.002256
And this has remained pretty consistent.
It seems that the issue has been fixed.

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