-
-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BL-touch works unreliable with SKR Mini E3 V3.0 #509
Comments
Check special configurations repository: https://github.com/mriscoc/Special_Configurations/tree/main/Ender3V2-SKRME3V3-BLTUBL |
I have the same problem with same board |
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. |
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. |
Ok, thank you for your report. |
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. 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 |
MarlinFirmware/Marlin#24955 (comment) this just got merged into the Marlin fw repo, maybe I can try this out next |
Please try with the latest version, it has some improvements for SKR boards from Marlin. |
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 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 I'm using the M48 Probe Test menu entry to test this. |
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. |
No more feedback seen to be fixed in latest versions. |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: