Improve BLTouch reliability for STM32F1 boards

[sjasonsmith]

Description

There have been many reports of unreliable BLTouch probing on STM32F1 boards. This is caused by unstable PWM ouput on the servo line. It seems that when the BLTouch receives an invalid pulse, it will not trigger for 2-3 PWM cycles after the correct pulse width is restored.

HAL/STM32F1 relies on a hardware timer ISR to control the pulse width. When these ISRs happen to align with STEP and TEMP ISRs, the pulse width is corrupted.

This PR increases the priority of the timer interrupt used for PWM generation, to ensure it can output a stable signal.

The following image demonstrates the beginning of the servo pulse being delayed by ~20 microseconds by the other ISRs:

Benefits

Improves probing consistency, by ensuring the BLTouch is in the proper state when it hits the bed. It may also improve other BLTouch "randomness" such as dropped pins, but I have not explicitly tested for this. The following chart shows the difference in probing consistency before and after this change, across 60 probes.

Related Issues

#18598
Probably many others, I will need to finish filling in this list later when I have time to search for them.

[sjasonsmith]

Please ask any questions you may have regarding my methodology or how I ended up with this as a solution. A lot of instrumentation and measurements went into identifying this, but I don't have time to describe it all right now.

[qwewer0]

With this fix, ADAPTIVE_STEP_SMOOTHING Enabled, BLTOUCH_FORCE_SW_MODE Enabled, BLTOUCH_HS_MODE Enabled, M48 P50

ENDSTOP_INTERRUPTS_FEATURE Disabled (This had failed probing before the fix, so I tested it more)

READ: Mean: -0.002400 Min: -0.005 Max: 0.002 Range: 0.007
READ: Standard Deviation: 0.001997
READ: Mean: -0.002700 Min: -0.005 Max: 0.000 Range: 0.005
READ: Standard Deviation: 0.001308
READ: Mean: -0.002600 Min: -0.005 Max: 0.002 Range: 0.007
READ: Standard Deviation: 0.001729
READ: Mean: -0.002950 Min: -0.005 Max: 0.000 Range: 0.005
READ: Standard Deviation: 0.001387
READ: Mean: -0.003400 Min: -0.008 Max: 0.002 Range: 0.010
READ: Standard Deviation: 0.001855
READ: Mean: -0.004000 Min: -0.008 Max: -0.003 Range: 0.005
READ: Standard Deviation: 0.001658
READ: Mean: -0.004050 Min: -0.008 Max: -0.003 Range: 0.005
READ: Standard Deviation: 0.001312
READ: Mean: -0.004500 Min: -0.008 Max: 0.000 Range: 0.008
READ: Standard Deviation: 0.001871
READ: Mean: -0.004750 Min: -0.008 Max: -0.003 Range: 0.005
READ: Standard Deviation: 0.001521
READ: Mean: -0.004950 Min: -0.008 Max: -0.003 Range: 0.005
READ: Standard Deviation: 0.001767
Restarted the printer here.
READ: Mean: 0.000350 Min: -0.003 Max: 0.002 Range: 0.005
READ: Standard Deviation: 0.001501
READ: Mean: -0.000300 Min: -0.005 Max: 0.002 Range: 0.007
READ: Standard Deviation: 0.001382
READ: Mean: -0.000550 Min: -0.003 Max: 0.002 Range: 0.005
READ: Standard Deviation: 0.001823
READ: Mean: 0.000550 Min: -0.003 Max: 0.005 Range: 0.008
READ: Standard Deviation: 0.002079
READ: Mean: 0.000200 Min: -0.003 Max: 0.007 Range: 0.010
READ: Standard Deviation: 0.002390
READ: Mean: -0.000250 Min: -0.003 Max: 0.005 Range: 0.008
READ: Standard Deviation: 0.002016
READ: Mean: -0.000350 Min: -0.003 Max: 0.002 Range: 0.005
READ: Standard Deviation: 0.001937
READ: Mean: -0.000400 Min: -0.003 Max: 0.002 Range: 0.005
READ: Standard Deviation: 0.001530
READ: Mean: -0.000650 Min: -0.003 Max: 0.002 Range: 0.005
READ: Standard Deviation: 0.001484
READ: Mean: -0.000750 Min: -0.003 Max: 0.002 Range: 0.005
READ: Standard Deviation: 0.001346

ENDSTOP_INTERRUPTS_FEATURE Enabled

Mean: -0.000400 Min: -0.003 Max: 0.005 Range: 0.008
Standard Deviation: 0.001828
Mean: 0.000350 Min: -0.003 Max: 0.005 Range: 0.008
Standard Deviation: 0.001733
Mean: -0.003200 Min: -0.005 Max: 0.000 Range: 0.005
Standard Deviation: 0.001418
Mean: -0.002100 Min: -0.005 Max: 0.002 Range: 0.007
Standard Deviation: 0.002022
Mean: -0.002150 Min: -0.005 Max: 0.002 Range: 0.007
Standard Deviation: 0.001937
Mean: -0.001550 Min: -0.005 Max: 0.000 Range: 0.005
Standard Deviation: 0.001312
Mean: -0.002800 Min: -0.005 Max: 0.000 Range: 0.005
Standard Deviation: 0.001470
Mean: -0.002350 Min: -0.005 Max: 0.002 Range: 0.007
Standard Deviation: 0.001831
Mean: -0.002650 Min: -0.005 Max: 0.002 Range: 0.007
Standard Deviation: 0.001831
Mean: -0.000950 Min: -0.005 Max: 0.002 Range: 0.007
Standard Deviation: 0.002173

Compared to #18598 (comment) there are no failed probing.

[txt4nk]

forgive me for my ignorance.. are we supposed to go make these changes ourselves or is there a way to download the files you've changed that I'm not immediately seeing?

EDIT

I got it. Went to the file and clicked RAW, copied and pasted into my files.

[Dracrius]

I am the Op of Issue #18598 and I did take the chance to pull this and make a few builds. For testing sake I ran one with Adaptive Step Smoothing since it was an easy way to trigger an obvious issue. After 8 test runs of bed mesh generatiion I saw no abnormal behavior vs the up to -1mm random probe points that could be observed with Adaptive Step Smoothing enabled prior to this pull on Bugfix and 2.0.5.4.

[Dracrius]

I am almost certain this is also the proper fix for #18526 rather then relying on enabling END_STOP_INTERRUPT in the default Configuration.h

[Dracrius]

After a quick look not deeper then 6 pages into the issues I'd make a safe bet some of these would also be solved by this Pull Request. I checked the configs of each and every one of them has ADAPTIVE_STEP_SMOOTHING enabled and are reporting ABL issues that match the bill from bad compensation to out right fails depending on speeds and use of MULTIPLE_PROBING

#18506
#18480
#18478
#18372
#17872

[kmobs]

This fixed my issues as well.

[sjasonsmith]

@Dracrius I do expect that this will resolve multiple issues relating to probing unreliability (and the inconsistent leveling behavior that goes with it).

For now it will only fix boards using the STM32F1 HAL, so it won't apply to every one of the issues you listed. I suspect that any similar issue involving a BLTouch may be resolved for this for many common boards, including the very common SKR E3, SKR Mini, FYSETC Cheetah and (most) MKS Robin boards.

Most notably it won't impact any issues involving SKR 1.x boards (LPC1768 HAL) or SKR Pro boards (STM32 HAL).

There may be similar root causes on these boards, but that would need to be verified and fixed separate if found to be a problem. For ANY board experiencing these issues, disabling ADAPTIVE_STEP_SMOOTHING is likely to help reduce the frequency of issues, due to reducing overall CPU load on the system.

[sjasonsmith]

I am pretty well set up now that I could try to reproduce and debug the same issue in those other HALs, I just don't have much time to invest into this during the work-week.

[Dracrius]

I appologize for overlooking that detail though I'b make a safe bet most if not all the boards made by BTT probably have a similar issue based on reports.

[sjasonsmith]

I am almost certain this is also the proper fix for #18526 rather then relying on enabling END_STOP_INTERRUPT in the default Configuration.h

Endstop interrupts are good, but don't actually help with the accuracy issue this PR addresses at all. They are especially important if using a BLTouch-like device that does not support SW_MODE, since the incoming signal might be missed entirely without endstop interrupts.

The issue this PR resolves results from the BLTouch signaling late, and causes inaccurate probing no matter how fast the incoming signal is detected.

[GMagician]

@sjasonsmith this PR will simply move servo priority above step and temp, Am I right? I'm going to adopt it also for samd

[ghost]

Was this merged?

[thisiskeithb]

Was this merged?

Yes

[ghost]

Too little sleep, sorry! I'm experiencing similar issues with a SKR board, and I came across this PR. Trying to put together some information. I honestly think some folks might be right about electrical noise and adding a filtering cap. I was running a Creality MB before with my own firmware and it ran trouble free.

[thisiskeithb]

@vogelfreiheit:

---

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:

• Marlin Documentation hosted on MarlinFW.org
• Marlin Forum hosted on RepRap.org
• Marlin Firmware Facebook Group
• Marlin Firmware for 3D Printers Facebook Group
• Marlin Configuration on YouTube
• Marlin Firmware Discord server

After seeking help from the community, if the consensus points to a bug in Marlin, then you should post a bug report.