search

bigtreetech / BIGTREETECH-SKR-mini-E3

BIGTREETECH SKR-mini-E3 motherboard is a ultra-quiet, low-power, high-quality 3D printing machine control board. It is launched by the 3D printing team of Shenzhen BIGTREE technology co., LTD. This board is specially tailored for Ender 3 printer, perfectly replacing the original Ender3 printer motherboard.
2.01k stars 1.97k forks source link

[BUG] Part fan interfers with 3DTouch (BLTouch clone) operation #372

Closed Asterchades closed 4 years ago

Asterchades commented 4 years ago

Description

Using a cloned BLTouch (one with "3DTouch written on the side) enabling the part fan (set to every level I've tested) will cause the probe to periodically deploy on its own for no reason. This includes during the print, where the probe can (and does) get caught on parts risking both damage to the probe and the part itself.

Steps to reproduce

  1. Boot printer
  2. Ensure 3DTouch is operational and retracted
  3. Enable part cooling fan to any amount greater than 0%

Expected behavior

Understandably the expectation is that the probe, once retracted, will stay retracted until such time as it is requested to deploy again. This is the also the behaviour observed when using Klipper firmware instead of Marlin (2.0.6.1 built from official source with BTT configurations, modified to suit an Ender-2)

Actual behavior

So long as the part fan is running at all, the probe will periodically deploy. If it is idle, the system will immediately retract the probe. However, if the printer is in operation it can (and usually does) stay deployed until it either contacts the bed (on early layers) or it contacts the print.

Occasionally the probe will enter "fault" mode with the flashing red light. At this time it becomes safe, no longer randomly deploying at all until the "alarm" is reset.

Additional Information

With the exception of this fault the probe works as I expect it to. And, as mentioned, this behaviour was not observed using Klipper firmware - only Marlin, which leads me to suspect a software (possibly configuration) fault rather than hardware.

Asterchades commented 4 years ago

Further information:

I have attempted switching to soft PWM for the fan control. This is better, in that the probe erroneously deploys far less frequently, but that it still happens at all tells me I'm not necessarily on the right track for finding a solution on my own.

I was able to find this older post on the Marlin repository which seems a likely culprit, but at that vintage I would suspect whatever fix it imposed has already gone in and I'm unable to formulate a new solution based on the information presented with my current level of understanding: https://github.com/MarlinFirmware/Marlin/pull/15547

*ed: I take that back. I might have found a solution using that pull request. By adding an extra condition to the end of what is now line 83 in timers.h, specifically referencing "BTT_SKR_MINI_E3_V2_0", it's so far seeming to be stable. I cannot in any way, shape or form guarantee that this doesn't have other side-effects, though, so I'd rather someone more knowledgeable investigate the matter.

tablatronix commented 4 years ago

hmm i had this happen a few times also, I assumed it was noise on the long wires. I just compiled and flashed latest marlin, have not tested yet

Asterchades commented 4 years ago

Well, that's a distinct possibility. And it may well fit with what I've since discovered.

After some discussion over on the Marlin git, followed by my damaging and subsequently repairing my V2, I've been able to confirm that the old fix for the V1 and V1.2 was not only not required but it did indeed have side-effects. Mostly to do with the speaker clicking when the fan was in operation or the probe was signalled, and it occasionally caused the probe to error (though it never failed to use it to home). But that all just makes it even more weird as to why it made any difference to my situation, unless the extra load stabilised the signal somewhat.

Unfortunately, while I've since fixed my issue (finally confirmed as of about 30 minutes ago), I didn't follow good scientific method so I'm not exactly sure what fixed it. It was either the fan0 MOSFET I replaced (it blew while I was experimenting with different fans) or the cables (which I re-made with home-twisted variants) - or some combination of the two. Since my wires are longer now, and my probe is more accurate (standard deviation is down significantly) I'm leaning towards the latter.

So if I were offer advice to someone experiencing the same issue, it would first be to try re-running the wires to the probe, twisting them (I used a a twisted pair for the signal, twisted triple for the servo) if length allows or running them in a separate loom to the fan/s.