Duet-Wifi Fans won't turn off
-
I take that back,
M106 P2 H-1
M106 P2 S0
M106 P2 S255
M106 P2 S0Gives the expected results (off, on full, off)
Same for P1….
So I guess I broke only P0
-
I just looked up that pump and can see right away it uses a brushed motor.
I don't have the Duet WiFi schematic in-front of me, but I doubt the Duet WiFi was designed to handle inductive loads on the fan outputs since everyone uses brushless fans. Without sufficient protection built into the fan outputs, it's possible the mosfet was damaged by back-emf from the brushed motor.
-
Suggestions for an external PWM controller to drive that pump safely off a duet as a fan?
-
Kraegar, are you using both hotends? if not then you could use the second one to control it.
-
No, single hotend. Curious how that'd work?
I found those mosfets are rated for 2A, and know at least one other person running that same pump off a fan control on a DuetWifi. Thought I'd done enough homework.
-
It's not so much the current draw that's the issue.
In addition to that, because of something called the flyback effect, depending on the PWM carrier frequency being used there's a LOT of time for the motor's winding to generate quite a bit of voltage as the magnetic field collapses been cycles. Depending on the motor I wouldn't be surprised to see over 100-volt spikes on an oscilloscope.
Regardless of the mosfet used, at the very least I'd put a clamping diode across the motor's contacts to protect whatever you're powering it with.
https://en.wikipedia.org/wiki/Flyback_diodeA ceramic cap wouldn't hurt either, as that will help reduce RF interference from 3rd order harmonics. Regulating the speed of a brushed motor with PWM can effectively make a powerful spark-gap transmitter, potentially angering any HAM radio operators in your area.
EDIT: I'd suggest something like this. As a bonus its also galvanically isolated to help protect the MCU from ground loops and other mishaps.
-
The fan outputs on the Duet do not include a flyback diode because the usual brushless fan motors do not need one. However a brushed DC motor does.
Fortunately the fan MOSFETs are not difficult to replace, and on the Duet Wifi we added an extra resistor to protect the processor if the fan mosfet fails.
I will add a note to the documentation about adding a flyback diode if a brushed DC motor is connected.
-
Thanks dc42 - so I should be OK to use the motor via the fan PWM outputs as long as I have a sufficiently rated flyback diode between the leads of the motor?
-
Thanks dc42 - so I should be OK to use the motor via the fan PWM outputs as long as I have a sufficiently rated flyback diode between the leads of the motor?
The running current of 1A is well within the fan mosfet ratimg, but the startup current might be too high. Best measure the resistance with a multimeter, calculate the startup current, and compare it with the current rating on the mosfet data sheet.
-
4.5 ohms, measured through the motor at rest. Not finding a calculation for startup current, though.
-
Unless you're able to "zero" your meter before measuring such a low value, figure about a quarter to half an ohms of resistance is in the probe leads themselves, so the motor is likely closer to about 4-4.25 ohms.
Using Ohms law Volts = Current * Resistance, we can solve for current.
So 12V = I (current) * R 4.25 ohms
12V/4.25ohm = 2.82A
That's about 2.8 to maybe 3 amps of in-rush current depending on your probes. That's obviously not the most accurate way of calculating inrush current, but it should be pretty ballpark.
-
As an aside, can I point out that this should serve as a warning to us all?
When the MOSFET failed, it failed shorted, leaving the attached device running at full. For a fan, this is annoying, but for a heater a shorted MOSFET could start a fire. The board would happily detect an overtemperature condition, but it would respond only by commanding the MOSFET to shut off, which would do nothing. If the setup used PS_ON, and if the firmware triggered an emergency stop on overtemperature, the fire would be averted.
-
I would make the argument that heaters capable of auto igniting a fire shouldn't be used without direct full supervision, but that's just me.
-
Unless you're able to "zero" your meter before measuring such a low value, figure about a quarter to half an ohms of resistance is in the probe leads themselves, so the motor is likely closer to about 4-4.25 ohms.
Using Ohms law Volts = Current * Resistance, we can solve for current.
So 12V = I (current) * R 4.25 ohms
12V/4.25ohm = 2.82A
That's about 2.8 to maybe 3 amps of in-rush current depending on your probes. That's obviously not the most accurate way of calculating inrush current, but it should be pretty ballpark.
The fan mosfet is rated at 4.4A for up to 5 seconds at 25C ambient temperature with 4.5V gate drive. The rating will be a little lower at 3.3V gate drive or if the board is warm, but probably still sufficient. If you want to reduce the inrush current, you could connect an inrush current limiting thermistor such as B57153S0200M0 in series with the pump.
You definitely need to use a flyback diode when driving a brushed motor.
-
I've ordered a pwm/mosfet board to drive the motor, so that'll keep it off the duet. I'll look into getting the mosfet on my duet replaced, and for now, just use the next fan channel.
Is there a way to make m106 default to fan1? Or do I have to force that in gcode?
-
Currently there isn't a gcode to map fan channels. I am considering adding fan mapping on a tool-by-tool basis in a future firmware release.
-
Alright. I've scripted it in my slicer to control P1, so no biggie.
-
Fan mapping will be supported in 1.16 beta 11 using a new F parameter on the M563 command.
-
Fan mapping will be supported in 1.16 beta 11 using a new F parameter on the M563 command.
Excellent, thanks.
-
Alright. I've scripted it in my slicer to control P1, so no biggie.
Can I ask which slicer you used for this? I can't figure out how to make slic3r's fan control control anything but the first fan.
