Fix BLTOUCH and FAN PWM conflicts on SKR E3 v2 boards#19208
Fix BLTOUCH and FAN PWM conflicts on SKR E3 v2 boards#19208Asterchades wants to merge 1 commit intoMarlinFirmware:bugfix-2.0.xfrom Asterchades:bugfix-2.0.x
Conversation
Corrects the same issue as #15547 on the newer SKR Mini E3 v2 boards. Also re-ordered the conditions to put all the SKR Mini E3s together, though that has no functional benefit (though if someone knows how to wild-card the condition it could be more evident what needs to be included).
thisiskeithb
added
Needs: Testing
|
There were some concerns in the original PR that this may break more than it fixes: #19205 |
|
I'm all for a better solution (seems a pulldown setting on the servo pin might help). But for now this has stopped my already-bent probe from being broken, which I figure is perhaps worth sharing with other affected users. |
|
So here is the problem: The 1.x boards use fan pins which attach to Timer 1. The BLTouch was also controlled from timer 1. The V2 board uses fan pins which attach to Timer 8. Please post your configuration headers. Maybe we can spot something else in them which was conflicting on Timer 1 with the BLTouch. |
|
config.zip There shouldn't be anything unexpected in there. Basically it's the example Ender-3 configurations, modified to suit an Ender-2 (different display) with a BLTouch installed. There's some changes to acceleration/jerk, S-curve and JD disabled so I can use LA, different temperature presets, changing stepper current (I have the larger motor on Y, not E), and probably some soft PWM stuff from when I was trying that as a solution. |
|
I did not see anything in the configs that would cause a problem with Timer 1 that this used prior to your change. The fan pins (PC6 and PC7) are tied to Timer 8. I previously verified this from the STM32F103R datasheet, but here it is from the Maple variant as well: I'm not sure why moving the Servo to timer 8 is helping things for you, but it certainly is not correct to use timer 8 on this board for the servo. That adds the conflict your PR is attempting to prevent. I suggest you test again without your change, but with |
|
Unfortunately I don't have this board, so I can't actually do any testing of my own. |
|
I run an SKR Mini E3 V2 with a genuine BLTouch on one of my test printers and have completed many 1/2 day prints without the probe deploying randomly. I’d look at wiring and other possible issues (like a bad BLTouch clone) before forcing all V2 boards to use the incorrect timer to solve this issue. |
|
I often faced this behavior and the cause was EMI (in most cases, solved routing cables differently), low amperage on 5V rail (too many devices connected) and sometimes this was due to "clone" itself that misunderstand some "3.0/3.1" commands and deploy when it shouldn't |
Already a step ahead of you there. Before I tried this I already gave the soft PWM a try. It seemed a little better, but it was still triggering. And since it is random than "better" could just have been dumb luck. Oddly, though, my fan seemed quieter in that mode, Just to clarify, the probe will only randomly deploy when the part cooling fan is on and when it's not in an "alarm" state, so it's clearly receiving a signal of some kind which is being (mis)interpreted as a command to deploy, yet somehow it's aware that it should be retracting immediately if the printer is idle. Without the fan going it sits perfectly still, even if I shimmy the effector like a madman (1-2mm stroke, 200mm/s @ 5,000mm/s²). Is it at all possible that Timer 1 just puts weird noise onto the line, and that this could have worked with me shifting it to pretty much anywhere else? How would I (keeping in mind I haven't done much programming since "Restart to MS-DOS" was still an option, and even that was Pascal) go about testing that?
Prior to this Marlin installation I had been running Klipper for a while (at least weeks, if not months) without similar problems. Same physical configuration - the only part moved to do the install, rather expectedly, was the SD card. This points me away from it being a hardware issue, though naturally the configuration between Marlin and Klipper is going to be fairly different. What I am curious about since it's mentioned, and because the internal documentation doesn't seem to say anything about it, is whether I can enable some kind of BLTouch 2.0 compatibility mode. It wouldn't surprise me in the least if it's not completely 3.0/3.1 compatible. |
Soft PWM runs really slow, something like 8 Hz. It will definitely sound different, and in many cases will work with fans that won't work with a higher frequency signal.
No, because the timer is just used to periodically run an interrupt routine which actually toggles the output line. The way you get "noise" is by something else using reconfiguring and using the timer when it is supposed to be controlling the BLTouch. The likely candidates are fans, SD, and SPEAKER, but none of those seem to be the issue with your configuration. At this point I don't really know how to proceed. This can't go in with the timer conflict it introduces. If it were happening on my desk I would use a scope and logic analyzer to watch the power and servo PWM lines when the error occurs. I don't know whether you have any equipment to be able to do something like that. As for why you aren't seeing problems on timer 8, I could imagine a couple reasons why you don't see an issue:
|
|
I do have access to a DSO (2-channel 70MHz) with a decent understanding of how to use it, but currently have an injured hand which may limit my ability to accurately probe anything. You'd be surprised just how often you use your subordinate thumb, especially when dealing with a 3D printer. Still, if you can point me in the right direction I'll see what I can do, though that may have to wait until tomorrow at this point. FAN_SOFT_PWM is not defined, so that isn't the reason I'm not seeing interference with this change. I tried it with that before switching timers and it made no difference, so I set it back to have a config more closely resembling the provided examples. And correct, I didn't have the fan enabled when probing. If you feel like that's a data point worth having I can arrange to test what happens in those circumstances (though I'm understandably reluctant). Worth mentioning is that I discovered the issue during a print with it set to 100% fan. It didn't seem to be noticeably better or worse than any of the other values I tried afterwards (5, 25, 50, 127, and 255) - if the fan was on, at all, there was a problem. I would have assumed that 255 would lead to a 100% duty cycle (no pulses to speak of) yet it still caused interference. This again points me away from EMI being the cause. I'm also controlling the system remotely (via OctoPrint) so you can probably rule out SD operations as being the cause. That's not to say the SD subsystem isn't potentially conflicting, just that if it is than it's under very specific, seemingly unrelated circumstances. SPEAKER is also undefined so I wouldn't suspect that as a cause. *ed: My mistake. I just re-read your point 2 and realised you were referring to how it was functioning with my change, not without. So I ran an M48 with the fan set to various speeds (0, 25, 127, and 255): (Mean, Min, Max, Range, SD) During this process I did also notice the suspected conflicts, so that's a definite cause for concern. When the probe is signalled or when the fan is operating below 100% there is a clicking through what I can only assume is the onboard speaker. Further, whenever the probe as signalled the fan stopped (or at least slowed down significantly). Also, only the 100% fan test completed on the first run - the rest required between 2 and 4 (even the 0%). So this definitely isn't a complete or reliable solution. |
BL-Touch servo emulation requires I have seen more than a few (defect) fans, rotating perfectly well, without any abnormal acoustical noise, but sending out big amounts of electrical noise, even when running at full, not PWMd, voltage. |
|
Well, this just became a whole heap harder to diagnose... tried switching out the fan to test that idea, and now I have that delightful smell of burned electrics and the mosfet next to the fan header is burned out. So.... yay! Looks like I found a dead fan. Anyone know how to reconfigure it to use the motherboard fan header for the part fan instead? Replacement parts on order... found some local-ish AO3400s, which should be a suitable replacement for the PL4009s. *ed: Before I forget... again... I found this discussion on Reddit which referenced the original PR: https://www.reddit.com/r/BIGTREETECH/comments/d02e79/skr_mini_e3_dip_v10_bltouch_issues/ I also noticed that without the fan plugged in at all (and following the mosfet dying) it was perfectly stable. But I'm assuming the firmware is waiting for some kind of feedback for the PWM timer, so that may be of little relevance. |
That means cabling or EMI on cables. No feedback from fan so Marlin act as it is mounted even if it isn't |
|
Y'know... in hindsight... if I'd known there was zero feedback to the firmware regarding the PWM state, I could probably have avoided all this hassle much earlier on by simply unplugging the fan and taking a look. Then I'd be blissfully unaware of how annoying Github is when trying to make a pull request as an outsider. So... it would seem, given that (and I'm assuming it's accurate), that this is a local issue rather than a firmware-wide one. So when I get the board going again I'll have to do some more physical diagnostics. I suppose there's an outside chance it was a failing mosfet causing the problem, which I just happened to push over the edge, but I suspect this is going to be wiring. Any suggestions for how to go about that? Shielding feels excessive, but just twisting the wires (I'd have to get longer ones) doesn't sound like it would work since there's three of them - unless the idea is to do a twisted pair with the servo wire and ground (and possibly the fan and ground for good measure). I'll be closing this now. |
Please don’t let this discourage you from contributing fixes on the future. I appreciate the desire to share your fixes back to the community. We’ve all had our PRs that ended up being discarded once others look it over And voice concerns. |
Sometime grouping cables without "interlacement" (is it right in English?) may help |
|
I'm not sure that's how it would be traditionally said, but I have a bit of a background in video so I think I understand what you're getting at. Basically making sure the wires don't cross over each other, which would explain why every cable I've seen for these things just has 5 wires run side by side in a ribbon, rather than with any shielding or twisting. Will definitely need to do something about the proverbial "rat's nest" inside my control box, though, for that to work. . Which would mean replacing the BLTouch wires anyway, since they're too short making it so I have to curl up the rest. |
@Asterchades I agree, but don't know how is the correct form. But you understood correctly. I had this kind of issue more than once and last time I solved simply by "distance". Cables was one next to other, by distancing PWM cables from bltouch was a kind of solution (currently my bltouch, after probing, raises, lowers and raises again pin, not everytime. This is for known a 3.0/3.1 set of commands no recognized correclty (my clone claims to be 2.0, replaced with another clone 1.0 problems vanish). |
|
It still has me genuinely confused as to why my code modification made any appreciable difference, and why Klipper never showed any issue. Surely the same interference would always be present, excepting perhaps a harmonic. Short term... I'm thinking I'll fix the mosfet, then try twisted cables. Pairs for the fans and probe feedback, and a triple for the servo control (which will also give me an opportunity to put some JST connectors on the motherboard end instead of the Duponts). If that doesn't work I might just have to run a second loom with only the BLTouch wires in it. But one step at a time - need to get the thing back to a state where I can demonstrate the issue before I start trying to fix it. Honestly a genuine is sounding like a better and better idea, but not really for this printer. Granted I could just move it over if I got something else, this is still just an Ender-2 which I'm using to learn how FFF 3D printing works and all the tinkering involved. |
|
Well, if you're still watching... I have good news, good news, and frustrating news. *ed: And even more good news. The good news is that I have my printer back up and running. Switching out the MOSFET was easy enough, aided in part by the original literally crumbling when I gripped it with tweezers. Substitute didn't go in quite as perfect as the existing one but it's in and it works. So, hurray! And I have 4 more spares just in case. The next bit of good news is that my probe is also no longer randomly deploying when I enable to part fan. Started up dead still, and stayed that way when I corrected the issue with the probe's 5v line pin having slipped out of the JST I put on instead of the dupont. Hurray again. The frustrating part, though, is that I undertook bad scientific process. While I was repairing the MOSFET I took the opportunity to do a few other bits and pieces - added a IEC connector, power switch and fuse to the power supply input and an XR60 connector to the DC power going to the printer. Problem is I also twisted the wires leading to the part fan and made a new, twisted (2+3) cable for the probe. Now, I don't fully expect my home-made twisted cables will have solved whatever the problem was, but it does mean I can't say with any confidence what actually was the fix between those, simply re-running the cables (which now cannot easily wrap around each other individually), or the new MOSFET. So I suppose all in all it's good news, and definitely invalidates the PR I had proposed. But I was probably the only one still expecting it might have done anything anyway. *ed: The even more good news? My probing accuracy is now up - with or without the fan. M48 is giving a range of 0.030-0.033, and a standard deviation of under 0.01. So maybe there's something to this home-twisted wiring after all. |
|
Thanks for the update, I’m glad it’s working. This PR turned out not to be needed, but I hope we’ll see more contributions from you in the future! |
5 participants
Requirements
Description
Corrects the same issue as #15547 on the newer SKR Mini E3 v2 boards. Also re-ordered the conditions to put all the SKR Mini E3s together, though that has no functional benefit (though if someone knows how to wild-card the condition it could be more evident what needs to be included).
Benefits
Prevents some Z probes (notably certain BLTouch clones) from deploying randomly when the PWM fan is triggered while using a newer BTT SKR Mini E3 v2 board. Prevents damage to both the print and probe. Tested for over an hour with zero random deployments mid-print.
Configurations
N/A
Related Issues
None listed. Personal issue encountered during recent experiments which, given the previous issue, is likely to impact other users with similar configurations.
As per discussion in my misplaced original pull request (#19205) this snippet may be complete but there should be alterations made following. In specific, the Mini E3 v2 does not use PA8 for the FAN_PIN, rather they use PC6 as mentioned by @thisiskeithb. As I don't fully understand the purpose of the notation I have made no attempt to alter it.