search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.27k stars 19.23k forks source link

[BUG] BL-Touch Probe fails intermediately with BTT E3V3 board #24351

Closed Mech131 closed 1 year ago

Mech131 commented 2 years ago

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

When probing with the BL-Touch, installed in the z-endstop pin on the BTT E3V3 board, the probe will fail intermittently. A quick google search will show that this is a widespread and perversive bug.

Bug Timeline

This has been around since the BTT E3V3 board was released

Expected behavior

Probe doesn't fail

Actual behavior

Probe fails intermittently

Steps to Reproduce

  1. Use the BTT E3V3 board
  2. Install BL-Touch
  3. Attempt a mesh

Version of Marlin Firmware

2.1.x

Printer model

Ender 5 Plus

Electronics

BTT E3V3

Add-ons

None

Bed Leveling

ABL Linear grid

Your Slicer

Cura

Host Software

OctoPrint

Don't forget to include

Additional information & file uploads

Config & Config_adv attache Configuration.zip d

ellensp commented 2 years ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

thisiskeithb commented 2 years ago

A quick google search will show that this is a widespread and perversive bug.

Disabling ADAPTIVE_STEP_SMOOTHING seemed to remedy this issue when this bug was reported here before (see https://github.com/MarlinFirmware/Marlin/issues/23958), but I see it is disabled in your config.

Are you using a genuine BLTouch or a clone? If you are using a genuine BLTouch, which version?

Mech131 commented 2 years ago

@thisiskeithb I am using a genuine BLTouch. Version 3.1

Mech131 commented 2 years ago

@ellensp Attached is the TXT of the failure. It happens at the bottom Debug BLTouch Fail.txt .

dwlovell commented 2 years ago

I have this issue. The probe can fail randomly during homing, but is most likely seen during ABL mesh probe since more points are attempted.

I have captured video and matching logs for both a full successful mesh probe and a mesh probe that fails on point 16 out of 25. That said, it randomly fails on any point from first to last.

The videos and matching logs can be accessed here: https://1drv.ms/u/s!AtXsq10ysfY6lex2LVKSpjjQQ5tv1Q?e=NhuPnU

Genuine BLTouch Smart V3.1 that came with the Ender 5 Plus. Using BTT SKR Mini E3 V3.0

EDIT: For some additional context, I did try all of the following:

cdement commented 2 years ago

I have this issue as well. I wanted to include some findings I have discovered with this and not really sure that they would be related or not. I am still new to the 3D printing world.

Mech131 commented 2 years ago

@ellensp Is there anything else you need to address this issue? I see that the 'Needs: more data' label is still applied.

KerseyFabrications commented 2 years ago

I'm getting a lot of reports on this one in my firmware. I don't see this myself so I'm unable to work on a direct fix. I've submitted two fixes to the community, one with ADAPTIVE_STEP_SMOOTHING disabled and one with a higher ENDSTOP_NOISE_THRESHOLD. So far, neither is reporting an improvement. My configuration can be found here for 2.0.9.3: https://github.com/KerseyFabrications/Marlin/tree/2.0.9.3-BTT-SKR-mini-E3-3.0-Ender5Plus It's similar to all of my other configs but I'm only seeing reports on this board.

Triangulix commented 2 years ago

This sounds similar to a problem I experienced with the BTT SKR 3 and a 3D Touch probe. The PWM frequency from the fan or heater creates interference in the servo and probe lines between board and probe. Since I only had the problem with the servo line I soldered a 100nF capacitor to the probe between SERVO and GND. You could do the same between PROBE and GND.

Mech131 commented 2 years ago

Hello @Triangulix, We've had users swap out their cables for shielded ones with no improvement. Also, the probe works fine with the Creality board or a different version of the BTT board. This only happens with the E3V3.

PSCY commented 2 years ago

Over here the same problem. I need to print, so I switched back to the Creality board.

Longer delays for probing, cabling outside the case, new probe, nothing works.

digant73 commented 2 years ago

@Mech131 and @all As reported here https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/2536 try to:

digant73 commented 2 years ago

@PSCY and did you also enable BLTOUCH_SET_5V_MODE in Configuration_adv.h?

Mech131 commented 2 years ago

@digant73 Turning on BLTOUCH_SET_5V_MODE made the issue worse. Are you sure it's suppose to be on for the BigTreeTech E3V3 board?

I disabled Advanced_OK, flashed the firmware and still have the same issue.

digant73 commented 2 years ago

@Mech131 if the suggested changes are not solving the issue then it's probably a bug introduced in Marlin fw.

DickQuaif commented 2 years ago

I have two identically configured Ender 5 pro printers with SKR Mini E3 V3.0 boards using real BLTouch 3.1’s. I was having a lot of trouble getting a consistent a first layer on both printers, one worse than the other. I replaced the BLTouch on the worst one and it was no better. I updated to Marlin Rev 2.1.0 and things got much worse. The BLTouch on one stopped working 90% of the time. I found the note about ADAPTIVE_SMOOTHING and that helped but it was still very unreliable. I went back to Rev 1.9.7 and noticed that the BLTouch was better but still unreliable. I think this is the root problem with my first layer issues. I got thinking the BLTouch didn’t really work but most people love it. I built a test fixture to test it and it’s even better than the spec. I was getting 0.002 or better standard deviations on my test fixture. Thinking back, I started to have first layer issues when I switched from the SKR E3 Turbo to the SKR Mini E3 V3.0. I switched because they have discontinued the Turbo board. I switched back to the Turbo board and that fixed my issues. The problem is with the SKR mini E3 V3.0 and got very bad with the latest Marlin Firmware. I got thinking about the SKR Mini E3 and that most customers are happy with it. Why is it failing so badly in my case? I think the problem might be that the Ender 5 Pro has a T8.4 lead screw for the Z axis. That requires the resolution to be 800 step/mm. That doubles the Z axis motor moves/second over the 400 steps required for an Ender 3. I went back to my test fixture to test this theory and sure enough when you go from 400 steps/mm to 800 steps/mm the BLTouch gets unreliable. I adjusted the Z axis resolution to 400 steps/mm and changed the micro steps from 16 to 8 and the reliability of the BLTouch improved considerably.
I have not reinstalled the SKR Mini E3 V3.0 boards back into the printers so have not tested this in an actual printer but I think disabling ADAPTIVE_SMOOTHING and adjusting the Z axis resolution and micro steps may solve this problem. I hope this helps deal with this issue.

DickQuaif commented 2 years ago

When I was trying to figure out my BLTouch issues I took a very close look at the BLTouch 5V options. In technical terms the options are open drain or active high drive from the BLTouch. The BLTouch is a 5V device with logic thresholds compatible with 3.3V logic. The active high drive is to 5V. All the I/O pins on the STM32G0B1 processor that are used for end stops (Including the PROBE input) are 5V tolerant. The processor I/O logic for those pins also has a pull up to 3.3V capability and Marlin is turning it on. It’s like the pins have a pull-up resistor attached to them but it is internal to the processor. (They also all have interrupt capability.) The PROBE pin has no external filter but does have an ESD clamp that is a 3.3V device. The ESD clamp is supposed to protect the processor from damage. It will clamp a 5 volt logic input to a little above 4V but the BLTouch active high drive doesn’t seem to mind. (I wouldn’t leave it like that forever though) IMHO the best configuration for the SKR Mini E3 V3.0 board is to use the PROBE input and set the BLTouch to open drain mode. That will give you reliable results with the fastest response. All the options will work and won’t damage anything.

define BLTOUCH_SET_5V_MODE Will set the BLTouch to 5V Touch output if #define BLTOUCH_FORCE_MODE_SET is set

define BLTOUCH_FORCE_MODE_SET Forces the BLTouch to be reprogrammed to the 5V_MODE or the Open drain mode It should be turned off when the BLTouch has been set.

define BLTOUCH_LCD_VOLTAGE_MENU Provides a menu that allows the BLTouch mode to be changed from the display.

I use: //#define BLTOUCH_FORCE_SW_MODE //#define BLTOUCH_SET_5V_MODE

define BLTOUCH_HS_MODE true

define BLTOUCH_LCD_VOLTAGE_MENU

BLTOUCH_LCD_VOLTAGE_MENU allows all these to be changed later and works great!

Mech131 commented 2 years ago

@DickQuaif In the past when I have tested out the 5V mode, the problem has gotten significantly worse. I will try adjusting the firmware to have both `#define BLTOUCH_SET_5V_MODE

define BLTOUCH_FORCE_MODE_SET`

If I'm understanding your comment correctly, after loading the firmware and running 'BLTOUCH_FORCE_MODE_SET', do I need to flash the firmware again with '#define BLTOUCH_FORCE_MODE_SET' back off? According to the notes the devs left about 'Force_Mode' it says to use it once then it off and re-flash. Or are you saying that by enabling '#define BLTOUCH_LCD_VOLTAGE_MENU' I can turn 'BLTOUCH_FORCE_MODE_SET' back off from the TFT35 screen menu and that will suffice?

DickQuaif commented 2 years ago

How you set  BLTOUCH_SET_5V_MODEhas no affect unless you also enable BLTOUCH_FORCE_MODE_SET.  BLTOUCH_FORCE_MODE_SET forces Marlin to write the 5V_Mode eitheron or off at power up.  You only need todo that once so in the end, after you have everything working,BLTOUCH_FORCE_MODE_SET should be off. This is what I use.    //#defineBLTOUCH_SET_5V_MODE  //#define BLTOUCH_FORCE_MODE_SET  //#define BLTOUCH_FORCE_SW_MODE  #define BLTOUCH_HS_MODE true  #define BLTOUCH_LCD_VOLTAGE_MENU  I then use the menu option to try the various modes.  I ended up with High speed on, SW Mode off and 5V Mode off.  I am very frustrated with the BTT  Mini E3 V3.0 board but most seem to loveit.  I think there are a few issues thatcan cause problem. First is the BLTouch is a 5V device with 5V inputs andoutputs.  The 3.1 version modified theoutput so it could be compatible with 3.3V boards by making an open drainoption.  To make open drain work, theinput on the controller board needs a pull up of some kind.  Both the PROBE input and Z end stop inputprovide that pull up.  The Z end stop hasa noise filter cap that slows down the input so is not the ideal input for aBLTouch.  The PROBE input goes directlyto the processor and the pullup is actually internal to the processor but does have a 3.3V ESD clamp.  The ideal option is to use the PROBE inputand for the BLTouch to be in open drain mode (5V_MODE OFF).  5V Mode will work because the processor inputis 5V tolerant but the ESD clamp may activate. It shouldn’t hurt the BLTouch’s output but it’s not the intended mode.  Second the BLTouch servo input is also a 5V but will acceptthe 3.3V logic levels from the Mini E3 V3.0 board.  The noise margins of a 5V input working at3.3V is poor so the servo signal can have noise problems.  The BLTouch seems to be susceptible to errorson the servo line and if it receives a signal with incorrect timing, it willget confused.   The processor on the Mini E3 V3.0 does not use a PWM tocontrol the servo signal.  It uses atimer and software interrupt to generate the timing of the servo signal.  This causes the timing to very slightly andcan confuse the BLTouch.  ADAPTIVE_STEP_SMOOTHINGmesses up the servo timing and causes the BLTouch to fail.  Make sure that is off. The next issue is that sometimes the Mini E3 V3.0 seems todelay responding to the signal from the BLTouch.  I have two printers with Mini E3 V3.0 boardsand one is worse than the other.  I haveremoved both boards and tested the BLTouch on a test fixture and it follows theboard.  Both boards have poor repeatability so I gave up on the MiniE3 V3.0 and went back to my E3 Turbo boards. They work fine but seem to have some ESD sensitivities that reprogramthe TMC steppers mid print.  I did someESD hardening so hopefully that won’t be an issue for me going forward. I got thinking about the Mini E3 V3.0 and I have them inEnder 5 Pro printers with T8.4 Z axis lead screws.  That makes the steppers run at twice thefrequency as the Ender 3.  I did a littletesting on the test fixture and the Mini E3 V3.0 works better with theEnder 3 step rate.  They are still not asgood as the Turbo board so I am sticking with the turbo boards for now. (Theturbo board uses a different processor that is much faster than the Mini E3V3.0.) If you are using this in a printer with the Z resolutiongreater than 400, try halving the resolution and changing the micro steps onthe Z axis.  The micro step value is thenumber of micro steps in the natural resolution of the step motor.  So if you change the resolution from say 800steps/mm to 400 steps/mm change the micro steps from 16 to 8 so everythingstill works.  The TMC stepper drivers canoperate at 1, 2, 4, 8, 16, 32, 64, 128, 256 micro steps but you must pick oneof these values.  See if that fixes yourproblems. You seem to see a difference in the 5V modes and you shouldnot.  I suspect that you are using the ZEnd Stop input or you may have a cable or connector problem.  Check those carefully.   Using the Z End Stop with a filter is a welldocumented issue and you should really be using the PROBE input.  If you really need to use the Z End Stopinput, you need to remove the 0.1uF cap (C10) on that input.   The Mini E3 V3.0 uses a JST connectors on the board and wherea 3M or AMP connector will plug in, the connection is poor.  Try to use a JST connector on the probe inputif you can.  There are two grounds on theBLTouch.  Make sure both are makingconnection.  It will work with one butboth work better.  If all else fails, check the voltage on the BLTouch.  If it’s high, that will mess up the noisemargins and cause the BLTouch to over drive the return signal.  It should be no higher than 5.1 Volts but nolower than 4.8 Volts. If the 3.3Volts is low, it will have the sameaffect.  Unfortunately, there is nothingyou can do about the voltage levels. I hope this helps. Dick Quaif -----Original Message----- From: Mech131 @.> To: MarlinFirmware/Marlin @.> Cc: DickQuaif @.>; Mention @.> Sent: Tue, Aug 23, 2022 9:37 pm Subject: Re: [MarlinFirmware/Marlin] [BUG] BL-Touch Probe fails intermediately with BTT E3V3 board (Issue #24351)

@DickQuaif In the past when I have tested out the 5V mode, the problem has gotten significantly worse. I will try adjusting the firmware to have both

define BLTOUCH_SET_5V_MODE #define BLTOUCH_FORCE_MODE_SETIf I'm understanding your comment correctly, after loading the firmware and running 'BLTOUCH_FORCE_MODE_SET', do I need to flash the firmware again with '#define BLTOUCH_LCD_VOLTAGE_MENU' back off? Or are you saying that by enabling '#define BLTOUCH_LCD_VOLTAGE_MENU' I can change '#define BLTOUCH_LCD_VOLTAGE_MENU' back off?—

Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

Mech131 commented 2 years ago

@DickQuaif If you ended up leaving 5v mode off, Then what's the point of flashing the firmware with BLTOUCH_FORCE_MODE_SET?

DickQuaif commented 2 years ago

BLTOUCH FORCE MODE SET does exactly what it says. It forces Marlin to write to the BLTouch. If 5Vmode is defined it writes 5Volt mode to the BLTouch on every power up. If 5Volt mode is not defined it writes open drain mode to the BLTouch If BLTOUCH FORCE MODE SET is not defined it does not write anything to the BLTouch.

Sent from my iPhone

On Aug 24, 2022, at 2:13 PM, Mech131 @.***> wrote:

 @DickQuaif If you ended up leaving 5v mode off, Then what's the point of flashing the firmware with BLTOUCH_FORCE_MODE_SET?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

ldursw commented 2 years ago

I've been dealing with this board for a few weeks and I think I've finally managed to find a configuration that works well. Ender 3 V2 with SKR Mini E3 V3.0.0 and BLTouch 3.1 from ANTCLABS.

// The Z speed is the most important part. More than 3 mm/s
// would not register the probe reliably.
#define Z_PROBE_FEEDRATE_FAST (3*60)
#define Z_PROBE_FEEDRATE_SLOW (2*60)

// I use 2 probes per point but it works well with just one probe per point.
#define MULTIPLE_PROBING   2

// If you have an original BLTouch you can enable the high speed mode to reduce
// the clicks it makes. If you enable high speed make sure to disable SW mode
// otherwise the pin can get stuck and will give a false reading at the Z
// clearance point.
#define BLTOUCH_HS_MODE true
//#define BLTOUCH_FORCE_SW_MODE

// Counterintuitively I've found out that disabling the endstop interrupt
// would give a better reading in this specific board.
//#define ENDSTOP_INTERRUPTS_FEATURE

// My tests were all with the BLTouch configured as open drain.
//#define BLTOUCH_SET_5V_MODE

// These values are for a Hero Me Gen5. If you are using multiple probes
// make sure the pin lifts from the bed when the Z is raised. If it keeps
// the contact on the second probe the reading may be off.
#define Z_CLEARANCE_DEPLOY_PROBE    2
#define Z_CLEARANCE_BETWEEN_PROBES  2
#define Z_CLEARANCE_MULTI_PROBE     2
//#define Z_AFTER_PROBING           5
#define Z_PROBE_LOW_POINT          -2

// Disabling Adaptive Step Smoothing helps a lot as well.
//#define ADAPTIVE_STEP_SMOOTHING

// I've left this enabled but doesn't seem to make a difference.
#define SQUARE_WAVE_STEPPING

Here is the full configuration files for those interested. Configuration.zip

rileymcdowell commented 2 years ago

I found a possible workaround for anyone who is having issues with a BL-Touch that is caused by enabling ADAPTIVE_STEP_SMOOTHING and resolved by disabling it. If you want to try with both enabled, see #24922 for more info.

I don't believe this issue is related, as ADAPTIVE_STEP_SMOOTHING is already turned off according to @Mech131 's config . @thisiskeithb suggested I comment on this issue anyway.

cbagwell commented 2 years ago

Based on the discussions in #18598 and #18637 , the servo interrupt priority change could improve BLTOUCH reliability even for cases when ADAPTIVE_STEP_SMOOTHING is disabled.

It looks like a version of the HAL/STM32F1 update made it over to HAL/STM32 as well because the default SERVO priority is highest:

#define SERVO_TIMER_IRQ_PRIO_DEFAULT     1 // Requires tight PWM timing to control a BLTouch reliably
#define STEP_TIMER_IRQ_PRIO_DEFAULT      2
#define TEMP_TIMER_IRQ_PRIO_DEFAULT     14 // Low priority avoids interference with other hardware and timers

It seems to be only SKR Mini E3 V3.0 that is re-arranging that default order and putting STEP at higher priority in stm32g0.ini:

build_flags                 = ${stm32_variant.build_flags}
                            -DPIN_SERIAL4_RX=PC_11 -DPIN_SERIAL4_TX=PC_10
                            -DSERIAL_RX_BUFFER_SIZE=1024 -DSERIAL_TX_BUFFER_SIZE
=1024
                            -DTIMER_SERVO=TIM3 -DTIMER_TONE=TIM4
                            -DSTEP_TIMER_IRQ_PRIO=0

Since the stm32g0 has a slower clock then stm32f1 cards then I would assume it has an even higher probability of BLTouch issues then SKR Mini E3 V2.0 had before #18637 was merged.

I have ADAPTIVE_STEP_SMOOTHING disabled and do not see any probe failures but it might explain bad values that shows up pretty often.

rileymcdowell commented 2 years ago

I tried a few different configurations and have been following the Marlin issue tracker. I'm trying to run with ADAPTIVE_STEP_SMOOTHING and S_CURVE_ACCELERATION enabled.

Step Timer: Priority 2

I tried a build with the default marlin STM32 HAL irq priorities on an BTT E3V3 board by removing the -DSTEP_TIMER_IRQ_PRIO=0 from stm32g0.ini. This should be equivalent to priority 2. It resulting in some really ugly sounds coming from my steppers. I was able to home the printer successfully, but the sound was not a healthy one.

Step Timer: Priority 1

Setting -DSTEP_TIMER_IRQ_PRIO=1 rather than 0 works fairly well (as I reported in #24922) , but the variance in BL_TOUCH measurements is still higher than one would expect. In fact, it's greater than 0.2mm, making it unreliable for automatic bed leveling with typical nozzle sizes.

Step Timer: Priority 0

The default as configured in the stm32g0.ini file. Very unreliable BLTouch performance as documented in this thread.

New Developments

Over in #24927, a user found an issue with firmware resets while homing while CPU intensive input shaping features are enabled. User tombrazier hypothesized that:

ADAPTIVE_STEP_SMOOTHING causes the stepper ISR to be called so often that when you add extra ISR calls for input shaping, the CPU spends all its time in ISRs. Consequently endstop logic is not processed and the watchdog timer never gets reset, resulting in a reboot.

Which is corroborated by cbagwell:

ADAPTIVE_STEP_SMOOTHING was recently disabled in config files for this specific board because that appeared to solve some cases with BLTOUCH failing. Others have found another solution to allow ADAPTIVE_STEP_SMOOTHING with BLTOUCH by increase interrupt priority of PWM timer (https://github.com/MarlinFirmware/Marlin/issues/24922 ) while others needed to disable both ADAPTIVE_STEP_SMOOTHING and ENDSTOP_INTERRUPTS_FEATURE (mentioned in https://github.com/MarlinFirmware/Marlin/issues/24351 ) for BLTOUCH stability.

The common theme in those solutions are to reduce or rearrange interrupts to solve bltouch issues so the board is likely already struggling with the interrupts it has and adding INPUT_SHAPING on top of ADAPTIVE_STEP_SMOOTH may be pushing it into watchdog territory.

Consensus seems to be there is an issue with ISR priority or handling. Then cbagwell discovers a possible underlying cause that applies to S_CURVE_ACCELERATION issues : https://github.com/MarlinFirmware/Marlin/pull/24955

There's a lot to take in there, but the short summary is that the E3 Mini V3 uses a Cortex M0 processor that has to emulate some multiplication instructions. The emulation of those instructions is poorly optimized, causing some routines to take far longer than anticipated. This could be a contributing factor to blocking ISRs.

It's not clear to me if ADAPTIVE_STEP_SMOOTHING would use those same multiplication instructions, but if so this is a possible root cause.

dwlovell commented 2 years ago

With respect, I don't believe this is a Marlin issue or a firmware configuration issue. I believe that it is some kind of interference issue on many E3V3 boards based on the design of the board and maybe manufacturing tolerances. Some firmware settings may mitigate the underlying issue, but they don't eliminate it. When failure occurs during Z-home, the nozzle crashes into the bed and I have had some smooth PEI beds dented up as a result which is really frustrating. When probe fails during bed mesh level, fortunately it doesn't crash into the bed as long as Z_PROBE_LOW_POINT is not more negative than -2, but during z homing there isn't any knowledge of zero so it just keeps going down after failure.

I had tried all of the following with the E3V3:

In all cases, probe failures were random, but seemed to be more likely to happen if the heaters where still pre-heating (not at set temp). Additionally attempts to G29 over serial (OctoPrint) would be much more likely to fail.

I recently swapped out for the E3V2 with firmware that is essentially identical settings and the issue is completely resolved with no other changes. Bltouch probing is 100% solid, no failures ever with the same hardware. I ran 10+ Octoprint bed level visualizer (25 points) and 10+ repetitions of bed leveling from Marlin interface (25 points) without a single failure. With the E3V3 I couldn't go even 2 runs of bed leveling with the e3v3 without a probe failure.

Given that the E3V2 is functional 100% with the same settings, this seems like a design flaw with the E3V3. I am willing to admit that not all boards are bad, but its a common enough problem that it has been reported a lot. My recommendation for fix is to go to E3V2 or SKR2 or other newer board.

cbagwell commented 2 years ago

I quickly looked over ADAPTIVE_STEP_SMOOTHING and didn't see any calculation that should be an issue for cortex-m0. The main issue there is if any cycle estimates are off then ADAPTIVE_STEP_SMOOTHING will overshoot its CPU usage.

ADAPTIVE_STEP_SMOOTHING looks to be attempting to scale all step rates that take less than 50% CPU to become 50% CPU usage. It's estimating that off of whole ISR taking 940 cycles but with unoptimized SCURVE its really taking 1500 cycles then CPU usage is probably scaled up to 75% instead of 50%.

I'm not sure I would risk leaving both ADAPTIVE_STEP_SMOOTHING and S_CURVE_ACCELERATION enabled together if using existing code base on e3v3.

RiMr71 commented 2 years ago

Hey. I have fitted several End5Plus printers with MINI E3 v3 boards. And even after endlessly trying different firmwares, adjusting various parameters, I have not achieved reliable BLTouch functionality. The Mini E3 boards of all versions were never one of my favorites, but I could always get by with them in the end. But v3 is so bad, unfortunately, that I'm done with it and am returning them all. And it's not just the BLTouch, but the weird hotend temperature measurement in some cases. Today, on 3pcs of identical Ender5Plus printers with problematic BLTouch, I removed those v3 boards and installed for test regular simple Creality v4.2.7 boards. All problems disappeared. For this test I compiled firmware with triple measurement of each point and the bed mesh leveling has one hundred points (10x10). Every printer that was unable to go further than the tenth to twentieth point with the Mini E3 v3 board regardless of firmware suddenly became completely problem free and every printer measured 10x mesh bed leveling (10x10) with triple measurement without a SINGLE error. That's 1000 triple points and 3000 BLtouch cycles. Without a SINGLE failure... Plus, even one printer that was having problems measuring temperatures suddenly measured everything correctly. I think the MiniE3 v3 is unfortunately a beautiful but just bad board.

Translated with www.DeepL.com/Translator (free version)

cbagwell commented 2 years ago

Here is an idea for people to try to see if BLTouch issues are related to SKR Mini E3 V3.0 having a slower CPU.

I hooked up a MAX7219 to monitor how busy the CPU is. It seems very close to 99% idle while running a bed level or homing.

On the other hand, if I run a print which includes bed leveling, it's closer to 40% idle. It's not the bed level itself taking CPU time but the fact that I set up my startup GCODE to warm the hotend to its final temp while leveling. Once it's at temp, the CPU falls immediately to around that 99%.

Should be easy enough modification for people to test if BLTouch reliability improves by making sure everything is at temp before homing or leveling.

dwlovell commented 2 years ago

@cbagwell I think your theory is very likely. I did find that if I preheated both nozzle and bed to temp and then activated the bed leveling function, the random failures were less often. If the bed/nozzle were still heating, failures were extremely likely. Even the z-home before the mesh started would likely fail if heating.

Further, the failure rate was even higher, heating or not, when bed level mesh was initiated from OctoPrint over the serial connection. My understanding is serial communication also consumes CPU.

All this said, preheating and only leveling from the marlin interface only reduced the occurrence, for me, to about once every other bed level mesh. This got me by for a long time as I didn't need to run a mesh often and I would just restart it over a few times if it failed. The only really frustrating thing was that it still might fail during z-home before a print. This is why I eventualy gave up and went to the e3v2 where the issue just doesnt exist at all.

DickQuaif commented 2 years ago

Several months ago I instrumented both my Ender 5's with a BTT E3V3 boards that were having BLTouch failures. I found that when the BLTouch fails it is not reporting the touch. I built a test fixture to try and find out why and found that if you mess up the servo signal, the BLTouch will delay or won’t report the touch at all. If the servo signal is correct, it will not fail and is in fact extremely accurate. I came to the conclusion that the BTT E3V3 board was messing up the servo signal so I tried to find out why. The firmware uses a timer interrupt to generate the servo signal and during periods of heavy interrupt activity, (or maybe electrical noise) the signal is not stable. I didn’t see any way to fix this without a significant modification to the firmware or hardware that I was not willing to spend the time to do. The solution I came up with was to replace my BTT E3V3 boards with older BTT E3 turbo boards. I have had no further BLTouch issues. Unfortunately BTT E3 Turbo boards are no longer available from BTT.

RiMr71 commented 2 years ago

Today I also tried TH3D fw for 5USD and the problem persists even with this firmware. I have SKR2/SKR3/SKR EZ boards with 2209 on higher versions of Ender5Plus. But on the lower versions I used Mini E3 (v1/v1.2/v2) or Mini Turbo. Unfortunately that is no longer possible. I will yet try MKS Robin E3D V1.1 with 2208 or 2209.

DickQuaif commented 1 year ago

If anyone wants to spend some time to try and fix this, Here are two ideas.
The processor pin used for the servo on the BTT E3V3 is not directly controllable by a timer but the fan pins are. If you were to cut the traces from the processor and swap the fan and servo pins you could control the servo directly from timer 3 as a PWM. This should stabilize the servo signal as it no longer would need interrupts. This is rather invasive and requires some new software. I think Timer 3 is already used to control the fan speed so the fan control would have to change. The second option is to use an Arduino Nano or Pro Mini to intercept the servo signal and regenerate it with the PWM in the Atmega328P. The code for the Arduino is not all that complicated and if only valid BLTouch times are allowed it should also fix the problem. This would not require any changes to the BTT E3V3 board. Just an idea!

rileymcdowell commented 1 year ago

I experienced this problem with S_CURVE_ACCELERATION, EXPERIMENTAL_SCURVE, and ADAPTIVE_STEP_SMOOTHING all enabled. Since turning off ADAPTIVE_STEP_SMOOTHING, I have not experienced a BL_TOUCH error. That includes 2 10x10 UBL grid meshes probed 3x per point, so 600 confirmed successful probes.

I need to try it with ADAPTIVE_STEP_SMOOTHING on and all the S_CURVE stuff off to see what that does. cbagwell has confirmed that the ISR CPU use calculation is incorrect with S_CURVE enabled. Maybe that's the real culprit.

cbagwell commented 1 year ago

If possible, those seeing BLTouch probe issues should retest with latest bugfix-2.1.x branch. There are two commits merged that will help prevent the stepper ISR from using too much CPU time.

Previously, I never saw BLTouch probe failures with my stocker Ender 3 Pro hotend on my SKR Mini E3 V3.0 but last week I upgraded to a Sprite Pro and I started seeing lots of probe failures. I started testing my new hotend with bugfix-2.1.x before those improvements were merged and I'd see the HALT shutdowns like @dwlovell videos show about every 4th print and that was with ADAPTIVE_STEP_SMOOTHING disabled.

I've spent a day testing the latest bugfix-2.1.x and those 2 commits and I even enabled both ADAPTIVE_STEP_SMOOTHING and S_CURVE_ACCELERATION as a stress test and I do not see the HALT's anymore. Or if I do seem them, it's closer to 1 in 20 prints.

Sud-Puth commented 1 year ago

Hey @cbagwell , I have the exact same setup as you and was seeing some failures. I'll retest this week with some prints. I've been following a few issues where you were commenting so thank you for your wonderful insights and time. Thought I was upgrading to the latest and greatest with the mini v3 but looks like the board has issues.

Just complied the latest from the bugfix branch, will install it in a while and see how it goes.

RiMr71 commented 1 year ago

Hi - only info - Ender 5 Plus tested with a cheap MKS Robin E3 v1.1. No problem with a bltouch. HS mode, hundreds measurings no fail.

cbagwell commented 1 year ago

I've continued testing and things are looking quite good with latest bugfix branch on my skr mini e3 v3. Originally, I followed this issue not because I saw probe failures but because I had X homing failures and auto-level maps would have unexpected dips and I thought they might have related causes. After I upgraded to a Sprite Pro, I could also finally reproduce probe failures.

After 50 prints with latest bug fix and 1000's of test probes with probe repeatability test, I am unable to reproduce any of those things now. This is even with all items enabled that help trigger Stepper ISR taking more CPU time (ADAPTIVE_STEP_SMOOTHING+S_CURVE_ACCELERATION+LIN_ADVANCE+INPUT_SHAPING but I do have ENDSTOP_INTERRUPT_FEATURE enabled to save some CPU) .

To wrap the topic up for me, I was doing lots of probe repeatability tests to see how accurate things were and if any room for improvement. It turns out there is not a lot of room for improvement with my CRTouch (a BLTouch may behave different).

In some of the older BLTouch issues the consensus is when Stepper ISR delays Servo pulse then the BLTouch will stop responding for a minimum of 40ms to 60ms and @DickQuaif also mentions seeing this behavior in this thread. I think we can use that value with Z_PROBE_FEEDRATE_SLOW to get a feel for minimum error size to look for. In my case, I use 2mm/s so by multiplying by 0.04 and 0.06 I'm looking for around 0.08mm and .12mm lower probes.

My previous unexpected low points where in the 0.2 range commonly so I think there is a good chance this bad servo pulse was what was causing my dips.

After 1000's of test probes with latest bug fix, my average range of probes comes out to the 0.005 range example shown here and no where near 0.2 difference anymore.

Recv: Mean: 0.067177 Min: 0.065 Max: 0.070 Range: 0.005
Recv: Standard Deviation: 0.001752

Since I know the stepper ISR priority is higher than servo; which doesn't match skr mini e3 v2 boards; I tried changing it to see if that range would go even lower. When I did, I exactly reproduced @dwlovell results. When I change Stepper ISR priority to 2 then the X and Y axis (but not Z for some reason) get noisy; as if stealth chop is disabled but maybe even slightly louder than that. If I change the priority to 1 then the noise goes away but I also do not see any improved behavior in probing beyond above values.

So at least for me, I see no reason to change stepper ISR priority.

Its always possible that a subset of BLTouch users will see improvements with priority changes (less delayed servo pulses) or that some are seeing addition issues that are in addition to Stepper ISR issues.

thisiskeithb commented 1 year ago

This should be resolved in 2.1.2, but please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

rfnovo commented 1 year ago

Running 2.1.2 with exactly same issue

github-actions[bot] commented 1 year ago

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.