[BUG] BL-Touch Probe fails intermediately with BTT E3V3 board #24351
Comments
|
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. |
Disabling Are you using a genuine BLTouch or a clone? If you are using a genuine BLTouch, which version? |
thisiskeithb
added
Needs: More Data
|
@thisiskeithb I am using a genuine BLTouch. Version 3.1 |
|
@ellensp Attached is the TXT of the failure. It happens at the bottom |
|
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: 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:
|
|
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.
|
|
@ellensp Is there anything else you need to address this issue? I see that the 'Needs: more data' label is still applied. |
|
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. |
|
This sounds similar to a problem I experienced with the BTT SKR 3 and a 3D Touch probe. |
|
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. |
|
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. |
|
@Mech131 and @ALL As reported here bigtreetech/BIGTREETECH-TouchScreenFirmware#2536 try to:
|
|
@PSCY and did you also enable BLTOUCH_SET_5V_MODE in Configuration_adv.h? |
|
@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. |
|
@Mech131 if the suggested changes are not solving the issue then it's probably a bug introduced in Marlin fw. |
|
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. |
|
When I was trying to figure out my BLTouch issues I took a very close look at the BLTouch 5V options. #define BLTOUCH_SET_5V_MODE Will set the BLTouch to 5V Touch output if #define BLTOUCH_FORCE_MODE_SET is set |
|
@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 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? |
|
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: ***@***.***>
|
|
@DickQuaif If you ended up leaving 5v mode off, Then what's the point of flashing the firmware with BLTOUCH_FORCE_MODE_SET? |
|
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.
|
|
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_STEPPINGHere is the full configuration files for those interested. |
|
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. |
|
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: 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: 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. |
|
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 2I tried a build with the default marlin STM32 HAL irq priorities on an BTT E3V3 board by removing the Step Timer: Priority 1Setting Step Timer: Priority 0The default as configured in the stm32g0.ini file. Very unreliable BLTouch performance as documented in this thread. New DevelopmentsOver in #24927, a user found an issue with firmware resets while homing while CPU intensive input shaping features are enabled. User tombrazier hypothesized that:
Which is corroborated by cbagwell:
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 : #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. |
|
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. |
|
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. |
|
Hey. Translated with www.DeepL.com/Translator (free version) |
|
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. |
|
@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. |
|
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. |
|
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. |
|
If anyone wants to spend some time to try and fix this, Here are two ideas. |
|
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. |
|
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. |
|
Hey @cbagwell , I have the exact same setup as you and was seeing some failures. I'll retest this week with some prints. Just complied the latest from the bugfix branch, will install it in a while and see how it goes. |
|
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. |
|
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. 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. |
|
This should be resolved in |
github-actions
bot
removed
the
Needs: More Data
|
Running 2.1.2 with exactly same issue |
|
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. |
Did you test the latest
bugfix-2.1.xcode?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
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
Configuration.handConfiguration_adv.h.Additional information & file uploads
Config & Config_adv attache
Configuration.zip
d
The text was updated successfully, but these errors were encountered: