[BUG] BLTouch probe no longer deploys or resets after a print is finished or cancelled #17683
Comments
|
I really hope I haven't wasted anyone's time as I am now unclear if this is Octoprint or Marlin (although only Marlin has been updated recently) but if I choose a completely different part to print (not just reselecting the same part over and over, or reslicing and sending the same file), then the probe appeared to work. I am not sure what actually happens programatically when a print finishes, but perhaps something has gone awry when a print is finished or cancelled and it's somehow reset when a NEW part is selected to print? I will run this test a couple more times to see if it continues to hold true. -William |
|
Additional testing shows that it wasn't loading an additional or different part but I may have rebooted the printer without thinking about it since that has been my way of dealing with this. I am also testing letting a certain length of time pass. I am trying to see to see if there is some sort of hung command that may be at play. -William |
|
Waited for 5 minutes and no change. Deleted an uploaded file in Octoprint and sent another one and the issue persists so I suspect I had rebooted the printer out of habit during my last test and thus it started working. :) So alas, the issue continues. :( |
|
I can confirm this. I had the same problem. I ended up moving back to my SKR 1.4 board. Look for the blue led on the side of the BLTouch. You'll notice that when it isn't going to work, the blue led isn't lit. It no longer is getting a PWM signal. |
|
Thanks for the comments. I have the older BL Touch with only the RED LED. but I suspect your comments are correct that the signal is no longer getting to the BLTouch for some unknown reason. Doesn't appear to be wiring :) -William |
|
Which version do you have? There is a tiny blue led, almost unnoticeable that is lit with PWM. |
|
I have the old classic. :) Couldn't bring myself to pay the price again for another one. |
|
I'm having similar issues with my BLTouch probe attached to a SKR-PRO 1.1. I noticed that whenever I'm using it together with NEOPIXEL as PRINTER_EVENT_LEDS or CASE_LIGHT_ENABLE the BLTouch is not deploying as it should be (at least not every time). I end up to disable PRINTER_EVENT_LEDS and CASE_LIGHT_ENABLE and be setting my NEOPIXEL via M150 in start/end gcode for now. I noticed in your config that you use RGB_LED and PRINTER_EVENT_LEDS, I'm not sure but try to disable both and see if it makes any different for you. edit:fixed typo |
|
@MoellerDi What pins do you have your lights connected to? |
|
@randellhodges I'm using the following. It seems (so far) NEOPIXEL on it's own is working fine. |
|
That's interesting PE4 (PE_4) isn't found in PeripheralPins.c. It looks like that pin does not have a timer or pwm capabilities. You only get issues with it combined with printer_event_leds? |
|
My pins are in the configs attached when I opened the issue. As mentioned by MoellerDi above, I use RGB_LED and PRINTER_EVENT_LEDS with a simple transistor control for each color. Nothing too fancy. I do have the base of my transistors connected through a resistor for good measure. :) -William |
|
I also have/had case lights, single color, on |
|
For me with PRINTER_EVENT_LEDS enabled the BLTouch failed to deploy when heating hot-end or bed with M109/M190 after it reached the target temperature. Disabling PRINTER_EVENT_LEDS solved the BLTouch issues for me (for now). I didn't investigated the issue with CASE_LIGHT_ENABLE is detail; I was just playing with it and found it cause same or similar issues with BLTouch, so I instantly disabled it again (w/o any further troubleshooting). I will try to use another PIN for the BLTouch (e.g. from extension-2 header) on the weekend to see is it makes any different. |
|
I managed to do some more troubleshooting and used PIN PC9 instead of PA1 for the BLTouch. To make a long story short, it didn't change anything :-( Still the same issue that the BLTouch is not deploying sometimes. However, this time I attached a logic analyzer to the pins and found the following. It seems that the PWM signal stopped on the servo pin for whatever reason.
edit: PRINTER_EVENT_LEDS was enabled during logging |
|
Yup, I noticed that when I saw, or rather, no longer saw the blue led on my
bltouch. Something is killing the timer that the stm32 library is using.
I don't think there is overlapping timers defined in Marlin's configuration.
It is like something at the end of the print is calling something in the
platform library and that is killing more than it should.
…On Wed, May 6, 2020, 6:07 AM MoellerDi ***@***.***> wrote:
I managed to do some more troubleshooting and used PIN PC9 instead of PA1
for the BLTouch. To make a long story short, it didn't change anything :-(
Still the same issue that the BLTouch is not deploying sometimes.
However, this time I attached a logic analyzer to the pins and found the
following. It seems that the PWM signal stopped on the servo pin for
whatever reason.
[image: image]
<https://user-images.githubusercontent.com/26838463/81169840-d97f7a80-8f99-11ea-932e-56978481c3f5.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17683 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB26S26LGY3WGDTBABKDF3DRQFAG7ANCNFSM4MPRI64A>
.
|
|
it seems it's not (only) at the end of the print. My screenshot is showing the timing of a M109 and shows it's already killing the timer a few seconds after the heater is triggered. Also I'm not sure if the timer was actually killed or if something just pulled the pin high |
|
I think the heaters are software pwm as well. Different timer probably, but
still, a commonality.
…On Wed, May 6, 2020, 7:56 AM MoellerDi ***@***.***> wrote:
it seems it's not (only) at the end of the print. My screenshot is showing
the timing of a M109 and shows it's already killing the timer a few seconds
after the heater is triggered.
Btw, PRINTER_EVENT_LEDS was enabled during logging
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17683 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB26S23ZHBN5VKZSYQGPEMTRQFNALANCNFSM4MPRI64A>
.
|
|
Hi, i'm having the same exact Problem with my SKR Pro 1.1 and BLtouch 3.1. I already crashed my nozzle once. Did you find a solution for the Problem? |
|
It seems to be working properly for me with more recent bugfixes but there was other discussion in this thread that showed folks were still having issues. I know there has been work on some timer swaps as well in another PR (regarding the Speaker/buzzer) and I have done that manually which may be helping me. Not positive though. William |
|
Well as of updating to yesterdays bugfix 2.0 my BLTouch now randomly deploys during prints. Perhaps it was doing it before as well but I hadn't noticed. I have been hearing it hit my glass bed when on the lower layers since yesterday and I see the probe flashing at me. :( -William |
|
Now the bltouch is causing prints to cancel right after probing finishes with a bltouch error. :( Swapping units and cables didn't resolve it. Going back to the 9/24/20 bugfix doesn't appear to have the issue. Strange. Not sure if something weird with timers is happening. I know that there have been STM32 updates in platformio recently which could be contributing. No idea how to troubleshoot. -William |
9/24/20 ??? Futur??? Time machine??? Format? Different calendar? |
|
;) nope, just fat fingers. 5/24/2020. Sorry about that. William |
|
@viper93458 still an issue? |
|
@boelle As of my comments 7 hours ago I have BLTouch issues that are now a little different with recent bugfix versions. I opened another ticket (#18372) for those specific issues so I suppose we can close this one out. Other folks were commenting in this thread about issues/things to investigate so I had left it open assuming investigation was happening but perhaps there are bigger issues afoot with timers, STM32 versions, etc... -William |
|
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. |
Bug Description
After one of the recent 2.0.x Bugfix versions in the last week or so, my BLTouch probe only works when the printer is initially powered on. Once a print has been completed (or cancelled), the probe no longer deploys or resets. Power cycling returns the probe to service. I discovered this when I heard my nozzle crash into the bed due to the probe not deploying. Resetting the printer resolved it and then it happened again so I started watching closer.
Initially I was using the Z-min endstop connection but I then moved it to the dedicated PA2 pin on the SKR-PRO 1.1 after I was looking through recent commits and saw #17359. Unfortunately the problem continues.
Next I tested disabling adaptive step smoothing after this recent issue was filed: #17676
However that made no difference either.
The probe works perfectly until a print is finished or cancelled. I am using octoprint as the host. The terminal shows that the BLTouch commands are returning an OK from the board, but nothing actually happens.
I have also tried unplugging the bltouch from the main board and re-plugging it (which results in the probe running through its power on self check without issue) before power cycling and this does NOT return the probe to service.
The probe doesn't appear to have any power issues or noise issues. It doesn't have any problems (nor did it have up till this issue) with probing the bed at the start of a print. M48 works fine (until a print finishes or is cancelled). The probe simply seems to ignore (or more likely the command isn't actually being sent to the proper pins?) any commands. Connections are tight, LED is bright without any flicker.
My Configurations
Configs.zip
Steps to Reproduce
Expected behavior: [What you expect to happen]
I expected it to probe properly as it always has.
Actual behavior: [What actually happens]
The probe doesn't deploy or reset even though the board returns OK
Additional Information
Thank you for your time and consideration!
-William
The text was updated successfully, but these errors were encountered: