BL-touch works unreliable with SKR Mini E3 V3.0

[Nuet0815]

Describe the bug
I have a problem with my BL-Touch V3.1 on my Ender 3V2 controlled by an SKR Mini E3 V3.0 running Ender3V2-SKRME3V3-BLTUBL-20221002.bin. I recently changed the board because somehow one stepper driver on my old 4.2.2 board gave up.

When I probe the bed with BL-Touch (while tramming / bed leveling / M48) and the new MB, there is a ~10% chance, that the BL-Touch triggers (LED goes red) but the board doesn't recognize the trigger. Observating the PROBE pin with an oscilloscope shows, that everytime it fails, the BL-Touch was sending only a very short but clear pulse (~2.5us width from 0V to ~4.5V, see first attached picture). When it successfully propes, the signal stays at ~4.5V until it deploys again (second picture). I also tried enabling / disabling HS mode, but this doesn't have any impact to the problem. When it fails with HS mode deactivated, the BL-Touch goes red but the pin is not retracted and the stepper drives into the bed. stepper drives into the bed.

From my perspective, this might be related to the firmware BLTOUCH_FORCE_SW_MODE disabled, therefore (sometimes???) outputting short pulses and probably the SKR Mini E3 V3.0 not using ENDSTOP_INTERRUPTS_FEATURE for the probe pin, but I can't check this becasue I didn't find the SKR ME3V3 config used for Ender3V2-SKRME3V3-BLTUBL-20221002.bin. Maybe also my BL-Touch is defective but this would be a strange coincidence.

To Reproduce
Steps to reproduce the behavior:

1. Use the SKR Mini E3 V3.0 mainboard
2. Connect BL-Touch V3.1 to the probe connection
3. Flash Ender3V2-SKRME3V3-BLTUBL-20221002.bin firmware
4. Carefully! probe the bed with M48, because everytime it fails ,the nozzle is driven into the bed. I adjusted the endstop switch so that it physically stops the z-axis 1mm before the nozzle touches the bed but BL-Touch still triggering.

Expected behavior
BL-Touch triggering everytime either by supplying a longer high signal on the PROBE pin or the SKR Mini E3 V3.0 detecting even the small pulses correctly (via IRQ).

Screenshots

Version (please complete the following information):
Ender3V2-SKRME3V3-BLTUBL-20221002.bin

Additional context
I will try to compile different firmware configurations but, since I can't access the configuration used for Ender3V2-SKRME3V3-BLTUBL-20221002.bin, I need to adapt it myself and this might result in a different behavior / doesn't work at all. But I will post an update if I find something new.

[mriscoc]

Check special configurations repository:

https://github.com/mriscoc/Special_Configurations/tree/main/Ender3V2-SKRME3V3-BLTUBL

[gsuresh2u]

I have the same problem with same board
But I have little different, BL touch is working well
Z offset is storing well, when I start print, it is staring print in mid air, without taking the z offset

[mriscoc]

https://github.com/mriscoc/Ender3V2S1/wiki/Calibration-Guides

[mriscoc]

I have the same problem with same board But I have little different, BL touch is working well Z offset is storing well, when I start print, it is staring print in mid air, without taking the z offset

If BLTouch is working for you in that board, that indicates that maybe the OP has a faulty BLTouch. So, I will close this issue. Please open another issue with your specific problem.

[Nuet0815]

Update: I found this issue thread in the Marlin Core repository that fit's my experienced issues, so it seems that the SKR Mini E3 V3 can cause some serious issues, whether hardware related or STM32G0 MCU software related is not yet clear. I managed to fix my old Creality V4.2.2 board and installed it, BL-Touch and all other functions working like a charm with Ender3V2-422-BLTUBL-20221002.bin, so it's definetly not my BL-Touch, but the SKR Mini.

[mriscoc]

Update: I found this issue thread in the Marlin Core repository that fit's my experienced issues, so it seems that the SKR Mini E3 V3 can cause some serious issues, whether hardware related or STM32G0 MCU software related is not yet clear. I managed to fix my old Creality V4.2.2 board and installed it, BL-Touch and all other functions working like a charm with Ender3V2-422-BLTUBL-20221002.bin, so it's definitely not my BL-Touch, but the SKR Mini.

Ok, thank you for your report.

[AsterDaishi]

I just wanted to chime in and say that my printer, which also uses a SKR Mini E3 v3.0, is affected by this exact behaviour, too. I suspected a faulty probe as well initially, but the problem began the exact moment I swapped board from creality stock to the SKR board. I haven't found a solution that completely resolves it, but through trial and error I was able to heavily mitigate it by disabling ADAPTIVE_STEP_SMOOTHING. In my case this seemed to reduce the probe failure chance to well below 1% on average. Almost eliminating it, but not entirely.

Among the other things I've tried in order to avoid disabling ADAPTIVE_STEP_SMOOTHING, the second most effective was to change the BLTOUCH_DELAY value in conjunction with increasing the Z probing feedrate. I've increased BLTOUCH_DELAY to 650 and the Z probing feedrate to 600 up from the default of 480 before I stopped noticing any further improvements. Ultimately this led to the occurrence of the issue to be reduced to about 1%, not quite as good as the first method but a noticeable improvement, and mostly usable.

I also would like to add that among the other things I've tried, I attempted to enable BLTOUCH_FORCE_SW_MODE as mentioned in Nuet0815's message, however I found that at least in my case, instead of improving the situation it made the issue a lot worse.
Another thing I've tried was to plug the bltouch's probe wires to the Z endstop header on the board instead of having everything connected to the probe header, and enabled Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN. This didn't seem to influence the behaviour in any way.

Edit: forgot to mention, the configs I'm using as base are made with the firmware configurator with the following settings: Ender3V2-SKRME3V3-BLTUBL-T5-LA-MPC

[Sud-Puth]

MarlinFirmware/Marlin#24955 (comment) this just got merged into the Marlin fw repo, maybe I can try this out next

[mriscoc]

Please try with the latest version, it has some improvements for SKR boards from Marlin.

[belak]

I've been using this for the last week or so and while the changes have improved reliability, it's still not perfect. Thankfully, once the mesh is made, probing only needs to happen at the start of a print.

If I'm following the thread in Marlin correctly, in theory the changes they made remove the need for disabling ADAPTIVE_STEP_SMOOTHING, as the SKR E3 Mini configurations in Special_Configurations do, but that still seems to cause major issues.

With the default settings from Special_Configurations, I seem to get a failure about within 100 probes or so (it seems to be even less frequent when it's warmed up). With ADAPTIVE_STEP_SMOOTHING re-enabled, I get a failure approximately every 20 probes. When it does make it through the full probe test, it's much less accurate (deviation is close to 0.01mm with it enabled, closer to 0.001 with it disabled) with it enabled, so at the very least for now it makes sense to keep it off.

I'm using the M48 Probe Test menu entry to test this.

[mriscoc]

With the default settings from Special_Configurations

From the last version I added an item in the control menu to disable Adaptative step smoothing if it was enabled in the firmware, perhaps disabling before make a mesh and using enable only before printing could give good results; to use that menu item ADAPTIVE_STEP_SMOOTHING needs to be enabled.

[mriscoc]

No more feedback seen to be fixed in latest versions.

[github-actions]

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.