[BUG] SKR Pro 1.1 BLTouch is frequently deploying during print

[DarkShortie]

Bug Description

I've recently migrated to a SKR Pro 1.1 board and I'm using a BLTouch. The BLTouch deploys frequently deploys during the print. If it hits the build plate it goes into error state, if Z is raised enough to fully deploy it stays deployed and crashes into the printed object sooner or later.

I've already did a lot of test to find the cause:

• separated the BLTouch wires from the rest to ensure no interference from other wires going to the print head
• changed the wires to the BLTouch to ensure they are not broken
• tried different pins (PA1, PA2, PC9) to ensure no interference on the board itself
• turned the skrew on top of the BLTouch one round counter clockwise

Nothing of this helped. The only workaround I found so far is to pull the servo wire from the SKR after G28 is done. 5V, GND and Z min stays connected. So I think for some reasons deploy commands are send frequently during the print.

My Configurations

config.zip

Steps to Reproduce

1. Use a SKR Pro 1.1 with latest Marlin bugfix 2.0
2. Start a print

Expected behavior:
Print is started, G28 is executed and during the print the BLTouch doesn't deploy.

Actual behavior:
Print is started, G28 is executed and during the print the BLTouch is deploying frequently.

[MangaValk]

I have been investigating this for a while.
Seems something is going wrong with the timer used for servo, but couldn't find a solution yet.

Also the turn off servo after move doesn't seem to work. This would be a possible solution if it worked.

[boelle]

turning off servo after move works fine for me, but using a re-arm

[davidcgu]

I have a bltouch clone and have no issue at all, this use to be a lose connection problem o bad cable.

Regards

[thisiskeithb]

@DarkShortie: Do you have a genuine BLTouch or a clone?

[davidcgu]

Note: connect the contact to Zmin switch

[TB1405]

i also have sometimes problems with my skr pro and BL Touch. but iam not 100% could also be a cable problem.

[DarkShortie]

It's a genuine BLTouch, but a very old one, it's Smart V1.0.
I already tried different pins and also a different cable and separated the cable from the others.

I will try turn of servo after move tomorrow, I was not aware about this option so far..

[RudyBenner]

The header for the BLTouch uses PA2 , change 2 lines as indicated. 825 and 843

[DarkShortie]

Also with DEACTIVATE_SERVOS_AFTER_MOVE activated it doesn't work.

[TB1405]

i also checked my cables now. Cable are all okay. i think it is a bug

[davidcgu]

I told you.... don't connect to PA2, connect to Zmin endstop

[randellhodges]

This is a real question, not a snarky response. I am not the OP and I am using the zmin endstop myself on an SKR PRO 1.1 (just started using this board), but I'm curious.

Why would that change the behavior? PA2/zmin endstop should be read when it deployed and undergoing homing. Deploying the pin is triggered on one of the other pins/servo.

Is it maybe that PA2 is noisy or something that is causing the BLTouch to freak out and drop the pin?

[davidcgu]

The only I can tell you is that I have a bltiuch clone running on a skr pro and have no problem at all with the latest release at least since september.

I have updated the firmware frequently and actually running with the latest release.

So I really doubt there is a but that only afects to youm but never knows...

Regards

[DarkShortie]

Like I wrote before I already tried different pins.

[DarkShortie]

I had the chance to try it with a genuine BLTouch Smart V 3.1, the issue stays the same.

Regarding DEACTIVATE_SERVOS_AFTER_MOVE which was mentioned earlier, this is automatically deactivated when using a BLTouch:

Marlin/Marlin/src/inc/Conditionals_LCD.h

Line 468 in 432decd

#undef DEACTIVATE_SERVOS_AFTER_MOVE

But even if I comment this undef and enable DEACTIVATE_SERVOS_AFTER_MOVE then BLTouch stops working completly.

[randellhodges]

I have a 3.1 on an SKR PRO 1.1. I haven't watched a full print and haven't witnessed a deploy during a print. This morning after a 2.5 hour print was done the bltouch was blinking red.

I am plugged into the z_min endstop with a genuine BLTouch.

[DarkShortie]

A friend visited me with a cheap logic analyzer and we hooked it up to the servo pin to see what is happening there. It seems there is some pwm even if the printer is idle on the servo pin. Is this intended?

[AnHardt]

Yes.

[sjasonsmith]

@DarkShortie that should be the “stow pin” command on the PWM. If you measure the pulse length you can compare it to the BLTouch datasheet to determine which command it is.

If you are looking for issues that might cause a pin to drop, you would want to look for interruptions to that steady PWM signal when it happens.

[Zappa55555]

I have the same issue, using an SKR 1.4 board and connecting the BL Touch probe pins to the Z_MIN_ENDSTOP_PIN (which actually doesn't matter for this case, since it is the servo pin which is causing deploy and stow of the BL Touch). The BL Touch deploys and stows its pin completely random, also during printing. I already broke my BL Touch with this. Now it is not deploying the pin and going into alarm state. I use a genuine BL Tough 2.0 smart probe.
Here you see a short video demonstrating this random behavior: https://youtu.be/MT54obwpSnE

[randellhodges]

I hate to be "that guy", but I have a BL Touch 3.1 on an SKR 1.4 and I have not had this problem, or at least I haven't seen it happen yet.

I was using an SKR PRO 1.1 and while I didn't see the drop, I did come back to a blinking probe (see my earlier post). I decided not to deal with it and swapped to the SKR 1.4.

You'll find my configs here:
https://github.com/randellhodges/Marlin/tree/skr-1.4/Marlin

I will keep an eye on mine as I print more to see if I can observe the same behavior.

Edit: @Zappa55555 has it ever worked for you on the SKR 1.4? What was your previous board? I think the wiring of the servo pins is different on the SKR 1.4 vs the 1.3.

[Zappa55555]

@randellhodges i modified my Wanhao Duplicator D9 since originally it has a terrible print quality. Only last week i received the SRK 1.4 board with TMC2209 steppers and i started upgrading my machine. The previous board i used was the genuine Wanhao board which is not open source. I don't know what version of Marlin it was running on, but the BL Touch was working without problems.
On the SRK 1.4 board this random deploy and stow of the BL Touch pin has been quite consisently for me. So to answer your question, it never worked for me on the SRK 1.4.

[LinoBarreca]

I guess I can debug this....

[LinoBarreca]

Maybe I found it. Wait.

[LinoBarreca]

For sure I found it...but I remember the things were different...I want to see who changed the file and why. I'll be back

[sjasonsmith]

Let me guess, PWM pin interfering with the timer?

[LinoBarreca]

Ok. I just made a fix for it.
Where did the bug come from:
Once we used the timer 2 as step timer.
It collided with pwm outputs so I changed it to 7.
@sjasonsmith made changes to the softwareserial reserving the 7 for it (for high priority). he (logically) had to change step timer using a different one so he picked up 5. Made sense back then, I'd have done the same (because TIM5 appeared to be free since servo used TIM6)

However, it looks like, once the PWM pin A1 is used (as servo with TIM6, to control the BLTouch), the output timer of TIM5 triggers the servo on A1 anyway even if it isn't used as servo...and this messes up with "fake commands" to bltouch.

I pushed a commit to https://github.com/LinoBarreca/Marlin please test it. If everything works I'll make the PR to Marlin

[sjasonsmith]

I don’t quite understand the root cause of the problem. Are you saying the servo pin assignment interferes with the timer? This seems odd, because I think the servo output on STM32 is all done with software PWM, the pins are not put into PWM mode.

My concern is that switching these may fix the BLTouch, but move the problem to the step timer. We previously had a problem like that which was corrupting the step output, but I don’t remember what you did to fix that.

[LinoBarreca]

by the way, you don't have to use the zmin endstop. the bltouch connector has all the pins already defined. just plug the cables like this:

and comment the #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN in the config

[DarkShortie]

Great, thanks. Will flash it soon and try.

comment #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN don't work, but it seems to be intended, even if I still got not the whole point: #16244

[sjasonsmith]

Not really. PWM is really done in hardware.

But I thing the actual servo class in the STM32 library just uses them as digital outputs, so that you can have lots of servos without requiring them all to be PWM pins. That is why I am concerned there may be another PWM pin assigned to something else, that could now interfere with the step timer.

I believe this HAL uses the framework’s servo library, but I’m not actually looking at the code at the moment.

We noticed a while back that the STM32F1 HAL actually disables any timers that are connecting to the SD Card pins. I wonder if on STM32 the timer outputs interfere with digital output even if they are not configured for PWM? I assumed the timers would be muxed out if pins were used as simple digital output.

[LinoBarreca]

Not really. PWM is really done in hardware.

But I thing the actual servo class in the STM32 library just uses them as digital outputs, so that you can have lots of servos without requiring them all to be PWM pins. That is why I am concerned there may be another PWM pin assigned to something else, that could now interfere with the step timer.

I believe this HAL uses the framework’s servo library, but I’m not actually looking at the code at the moment.

Yes. they are. The servo library uses the timer (in software mode on channel 1) to manage the servos. that's why, back then, it made sense to use timer 5. Because we thought "okay, since servo uses timer 6, timer 5 shouldn't interfere with pins' PWM" (and what we thought made sense) probably however there's some part that does an analogwrite somewhere on that pin changing the timer mode.
Now, if you look at the commit I made, the TIM5_CH1 is now used for Servos (general) while the TIM5_CH2 is used for HardwarePWM on PA1. they shouldn't conflict and, the analogwrite to PA1 (which is buried somewhere, I don't know where), wouldn't still mess with another timer used for something else.

[LinoBarreca]

oh... by the way...this allows us to possibly define PA2 as an optional PWM, if the users uses the zmin endstop..
I'm gonna push another commit for that.

[sjasonsmith]

The Servo library uses digitalWrite to write the outputs. If that pin is being impacted by a timer, then perhaps we have something wrong in the pin assignments file.
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/libraries/Servo/src/stm32/Servo.cpp#L54

Now, if you look at the commit I made, the TIM5_CH1 is now used for Servos (general) while the TIM5_CH2 is used for HardwarePWM on PA1.

This might work fine, but I suspect it will end up running either the Servo timer or the hardware PWM at the wrong frequency.

[LinoBarreca]

@sjasonsmith it might happen but last "write" should win...and since we are using the same timer(tim5) for the same pin, however, that shouldn't break anything because last setup of the timer (and write) should command the timer and achieve the result the call meant to.

[sjasonsmith]

I don't currently have the time or hardware set up to test it, but I've spoken my concerns.

I think STM32 timer conflicts will continue to cause problems unless we find a good way to detect and report conflicts.

[DarkShortie]

4 hours printing time later and I recognized no issues so far.

[LinoBarreca]

@DarkShortie with my branch?

[DarkShortie]

Yes

[LinoBarreca]

@TB1405 @boelle @MangaValk can you please make a test too? (Without disabling and re-enabling manually)

[koolrob4002]

@LinoBarreca just tested out your fix, and it works. 3 hours into a print with no problems.
using PA1 for servo and z- for endstop.
have not tried on PA2 yet.

[LinoBarreca]

Although the PA2 was designed for it, if you already split the cable to connect to Zmin I would suggest leaving it as is for one simple reason: PA2 can be used to control something analog (fan, light or whatever you like) while the zmin can't (could be useful for filament runout or something digital) it's up to you.

[MangaValk]

@TB1405 @boelle @MangaValk can you please make a test too? (Without disabling and re-enabling manually)

Sunday il be back from holiday and test it :)

[LinoBarreca]

it has been merged. we can close this as fixed.

[Zappa55555]

Maybe a stupid question from my side, but is it fixed only for SRK Pro1.1 or is this fix also working on an SRK1.4 board?

I cannot test right now since i am waiting on a new BL Touch sensor.

[LinoBarreca]

Only pro.
1.4 uses another hal

[Mosher23]

I had the problem you have.And i solved it by wiring my stepper motor with a shielded twisted pair cable CAT6a and connecting shield to stepper and other side to ground

BTW i have SKR 1.4 turbo and BLTouch 3.1 clone and as extruder e3d Hemera

[wiring80]

Seems like this bugging me too. I have testet with three different bltouch and latest marlin bugfix. I wired over PA1 and PA2. So if i set my build fan (5010 Radial - wired on PE5) to 20-40%, he seems to give noise to bltouch, randomly deploy and stows. But if the fan is set to 100%, nothing happens - all is fine. Any thoughts?

[davidcgu]

Connect to Zmin

[wiring80]

I try it later. But correct me if im wrong, the deploy und stow commands/pulses are generated over PA1, so it makes no difference, PA2 receive just the triggered signal?

[davidcgu]

I'm not gonna dig too much, what I can tell you is that issuye was coming since this feature was implemented, I keep it connected to Zmin and it's done for me.

Regards

[AnHardt]

Go away with your hardware problems. This issue tracker is about MarlinFirmware problems.

You are suffering from noise. The, pulsed when not 100%, fan is interfering with the BL-Touches servo lines.

Separate the lines as far as possible.
Use twisted pairs.
Shield the pairs.

[wiring80]

More friendliness could suit you well my friend.

If it is a hardware problem, youre right. Separated already the cables, the pulses are interfering by the pin's on the board, but possibly a hardware defect on my SKR.

However, i only want to exclude that marlin or any marlin related configuration caused that bug/feature. I dont need to spam with hardware problems that are not related to marlin

[Mosher23]

i had same problem. Fan and Motor cables emission high EMI. So solution which i used is shielded cable for motor wiring with both sides of shield grounded.

[wiring80]

Yes, i excluded this - by doing tests without wired cables to the fan and so on - only the BLTouch is wired - and without success. I contacted Bigtreetech, seems the board have an defect, so im out at this point

[github-actions]

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.