That couldn’t be… the fan not working will not cause the temp to go too high… the thermistor and board would continue to regulate the temperature correctly. The only reason it would go too high is failure of the MOSFET or if it was commanded to go to a high temperature. A fan failure would cause the filament to retain too much heat, or depending on which fan failed, simply cause the printer to jam. (Two fans cool the extruded plastic and one small fan cools the heat brake.)
Bill
Again, not true. A failure of the hotend MOSFET would also cause the same problem. You need to examine the GCode to determine what temperature was commanded to it. Look for the M104 command. If the GCode command issued was within normal ranges, then the MOSFET likely failed. The Ultimaker relies on a bad design based on the RAMPS 1.4 board, which has a failure mode which causes the MOSFET to pull to ground when it fails, which closes the heating element circuit, causing a run away temperature failure, just like what happened here.
They are supposed to have a watchdog set in the Mega2560, however, it automatically pulls all IO lines to ground, which also does the same thing. Bad design all around.
Bill
Thanks for the clarity Bill.
Bill,
Maybe you could help me figure this out better (and also preempt this sort of thing in future):
None of the FETs blew or have shown any problems. The UM2 is printing quite well now with replaced fan, wiring, clean hotend, etc.
On the schematic, it shows Q1-Q3 are enhancement N-fets. If the drain was shorted somehow and they fried, wouldn’t they fail open? Of course, if they can handle the over-current situation, they would remain closed (which would cause runaway heating). I don’t see where the gate voltage would come from in that case, though. If the control board stopped switching the FET, the gate-source pull-down would dissipate the gate capacitance and open the FET, no? I did notice that on ramps 1.4 the pull down R is not directly connected to gate, as it is in ultimaker.
So, does the firmware fail by pulling these pins high? If so, that’s stupid, but fixable.
Would a logical additional failsafe be to fuse the heater FETs?
The only transistor fried in this case was a BJT: T100 which is a BC817 NPN that turns the heat brake fan on at 40 degrees C (connected to PJ6 on micro). This makes sense, as a short across fan wires here would have thrown too much current through the BJT. That makes sense to me.
For now I simply bypassed T100 so that the brake fan is always on (this was the way the first UM2’s worked anyway).
Just want to understand better and know what to look out for improve upon.
Lorin
Lorin,
If you would like to borrow my um2 to compare board readings you are more than welcome too sir. Just let me know and I can bring it to you.
Bill,
Sorry, just looked at where the output to heater is – on the DRAIN! So, yes normal mosfet failure would cause closed, always on heater. That is really stupid. Maybe I missed it because I didn’t want to see it ;). So dumb. Heater has a separate path to ground…
So, here’s my ideas:
Feeder sensor (already at work on this) – just a rotary encoder that stops printer if filament stops moving (to counteract the problems when the feeder skips, chews the filament, etc). If filament doesn’t move forward for x seconds, print stops – simple instruction to marlin.
2nd thermocouple. If temp exceeds maximum value, shut down printer. I could just impliment this on a seperate PIC which also reads the feeder sensor.
I could fuse the heater fets.
What do you think.
Lorin
Lorin,
What package are the FETs in question? I’ve played with quite a lot of them in the past year and there are a few “autoprotected” FETs that incorporate over-load shutdown, over temp shutdown, etc. and fail OPEN not shorted. I did manage to fuse a couple of them shut but it took some pretty serious abuse with inductive loads. I might have something that is a drop in or close to a drop in that would be a safer/smarter replacement.
-D
So, here’s my ideas:
Feeder sensor (already at work on this) – just a rotary encoder that stops printer if filament stops moving (to counteract the problems when the feeder skips, chews the filament, etc). If filament doesn’t move forward for x seconds, print stops – simple instruction to marlin.
2nd thermocouple. If temp exceeds maximum value, shut down printer. I could just impliment this on a seperate PIC which also reads the feeder sensor.
I could fuse the heater fets.
To me, the 2nd option is the best one, and only one required… secondary thermistor that cuts power to the primary hot end. Using an ATTiny or a simple PIC to do the logic would be dead simple.
Bill
Bill, you know Lorin wouldn’t do that with a PIC or ATTiny! If he couldn’t do it with an op-amp, trim pot and NPN transistor I’ll be shocked. 
-D
Dave,
IRF8736PBF 8-SOIC (0.154", 3.90mm Width)
I think an Autoprotected FET could help a lot, as a FET failing closed is a failure mode (sigh, all too often).
It looks like the overall design flaw is that there is an additional RAMPS failure mode which does this as well:
Quoting Bill,
The watchdog is supposed to reverse this, but it pulls the FET closed as well.
So, yes, another FET would be great, and I’ll take you up on that.
But I’ll also have to correct for the watchdog interrupt problem. I’m not going to mess with the printer firmware, as it is complex and somewhat convoluted and I’m not familiar with it. I’d rather just add a redundant monitor since I have to make a PIC or atmel monitor the rotary encoder anyway…
So, the FET did not fail in this case, but it does happen often enough to show up on the Ultimaker boards. In this case, something else may have set it out of control and the failsafe watchdog may have then clamped the heater closed…
Dave & Bill, thoughts?
Lorin
Bill,
I’ll plan on adding a therimstor failsafe on the same PIC.
Dave, thank you for the compliment. Yes, sometimes when I program a micro, I gently weep into my Art of Electronics 1st edition. But, there’s work to be done and things to be learned.
Thanks Bill and Dave!
Lorin
Lorin,
Look at:
VNS14NV04
shitty datasheet, but a friend made use of them so I asked him. Pinout works.
http://rusefi.com/wiki/index.php?title=Manual:Hardware_Frankenstein_board
I just ordered you ten of them in my digikey order. I’ll keep what you don’t need.
-D
Thanks Dave,
Also, since you wanted a discrete solution here you go: A honeywell NTC thermistor (R3) with about 3500K beta approaching close to 300 degrees would switch the FET off. I didn’t even use an opamp, just current mirror / differential pair.
“OUT” would go to the MOSFET on the printer board, protecting it regardless of state.
Sorta textbook, but it works in practice too. No op-amp needed.
Nice mental exercise, but a micro might be easier.
Lorin
hahahahahhahahahahahha. Thanks The Autoprotected FETs will be here Friday.
-D
Those fets will be excellent.
The IRF8736 in there is much more prone to dV/dt (over-voltage on drain) and avalanche breakdown. The stock IRF8736 on the ultiboard has a max Vds of 30V, and the supply is 24V. That’s not a big margin. Both failures result in a welded FET closing the circuit as Bill has seen in practice.
Since your fet has a very fast clamp integrated and 4x the avalanche energy, it is much less likely to fail in this mode.
Dave, how about we tag-team this project. I set up the etch tank and we could etch PCBs for this project since you were interested. Or, if we feel really energetic, we could set up shapeoko to mill PCB. Julian got it well within tolerance.
Lorin
They’re the same package and pinout… All we should have to do is hot air.
I was very careful choosing.
-D
If it works…can we do my um2 also
The simple mod is just to replace the FETs… The ones I specced out are much more robust. Apparently, this doesn’t fix another design flaw, for which I’m examining schematics and stuff to try and come up with a clever solution.
-D
Bill,
Can you give us more insight on the failure mode in which ramps pulls down the IO and closes the heater fet? I’m unfamiliar with Marlin firmware, and don’t have your experience in the field…
Lorin