Closed boelle closed 8 years ago
boelle
commented
8 years ago 
I thought there was some code that says thermal runaway. I guess this is similar to what you want. The printer stops printing if the temperature change is to fast or a bit weird.
boelle
commented
8 years ago
You can also set the maximum heat in the config file.
boelle
commented
8 years ago 
Yeah, but in this case, there is no "visible" heat change for the printer to see, because it only monitors temperature on the hot-side of hot-end.
Let me do an example: With E3D-V6 hotend, the heater cartridge heats up to 240°C, and at this temperature, the cold-end side (the aluminium ribs) have just a little over 70°C in the closest point to the heater cartridge, and this temperature descend gradualy with the distance from the heater cartridge. Which leaves the hotend mount at something just over room temperature. But if the fan stops blowing air through the ribs, they can heat up to temperature over 90°C which will cause them to melt or deform the hotend mount if it is printed from ABS or PLA. But in this situation the heater cartridge temperature still doesn't exceed 240°C. And so, system will not detect any failure or dangerous situation.
boelle
commented
8 years ago 
Can we close this old issue for housekeeping, or is this still an active feature request?
boelle
commented
8 years ago
If it is not solved yet, I would keep it as open feature request. Since it is safety concerning request which is easy to implement I think someone should look into it. I would write it by myself but I cant code. But I can give a rough sketch what it will propably looks like:
define: fan_minimal_RPM = 200 //or any pre-defined value get RMP reading of fan1 if fan1_RPM <= fan_minimal_RPM //indicate fan failure wait_seconds = 5 //wait fes seconds to see if the fan stop isnt only temporary if fan1_RPM <= fan_minimal_RPM //check if the fan failure still last then shutdown_hotend_heating return "FAN ERROR"
else continue monitoring
boelle
commented
8 years ago
Just putting this link here for reference, if someone decides to implement this. http://playground.arduino.cc/Main/ReadingRPM
jbrazio
commented
8 years ago Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.
gerleimarci
commented
5 years ago This feature would be useful. I would use it for a flow sensor for water cooled hotend. With the new 32bit boards it would be easy without overloading it.
AnHardt
commented
5 years ago This is relatively easy for always full on fans. Just reserve a hardware timer of the processor, count it up with every puls of the fan and occasionally look if the counter counted a reasonable number. If you have a PWMd 3-wire fan its nearly impossible to get a reasonable result. The PWM pulses will be seen on the fans pulse output. There are ways to get a more or less acceptable RPM reading, but then (at least for the 16MHz AVRs) the PWM for the fan has to be in a very audible frequency. (Take a look at the PRUSA bug tracker.) With 4-wire fans i expect respektable results. But even on 32bit systems this will be not acceptable when wanting to use more than 1 or two fans. To be performant every fan will have to use two hardware counters. One for counting the pulses and another one for the needed 25KHz PWM. Looks as if this is enough reason to use a dedicated fan-controller-processor (like a blue pill) or at least a separate dedicated PWM-chip. However, this will not be a cheap solution. Alone getting the right size 4-wire fans could be difficult. Another path one could go is building your own fans with a independent powered (optical/magnetic) RPM-sensor. But i also non't see much acceptance for that.
So all in all measuring fan RPM is possible, but either cost or usefulness or afford will limit the acceptance. I can't find the golden way.
edumaker-limited
commented
5 years ago I'm back looking at this again in context of a feature rich dedicated extruder controller.
I think this is still a reasonable feature to request, as I have encountered several times a failure mode on standard 40mm fans, where over time they lose lubrication and slow down.
At this point, the fan may still be turning, some or all of the time, but at reduced speed, and cooling of the cold end of the extruder may be intermittent or negligible. This can affect quality, and in the case of PTFE lined hot ends (Creality especially) the bowden tube may degrade, releasing toxic chemicals and likely causing a severe clog requiring the extruder to be stripped down.
Worst yet - when the fans stop entirely they are still receiving power, and get extremely hot inside - maybe even posing a fire risk in themselves!
I disagree that the existing thermal runaway protection is all we need here. Temperatures are normally only measured in the heater block - now we can install a second thermistor in the heatsink, but if I remember correctly this is really designed only to give a second failsafe thermistor on the heater block, and works by checking we are within a determined offset to the heater thermistor. It would be very hard to find a useful threshold temperature offset, which would not generate false positives even when printing PLA, Nylon or PEEK, and in anything from a freezing garage to an enclosed build chamber at 80 degrees C.
Also, if we have cheaply available fans which contain a dedicated sensor output, it makes sense to monitor the health state, not wait for symptoms of death... For example these fans can be re-lubricated and last for a long while after. With a dedicated monitoring subsystem, we can decide how the printer should respond - it could be set up to pause the print like filament runout, or merely report back to the user.
I would like to better understand this issue of PWM control making the output of the hall sensor line useless.
For the main case of monitoring a heatsink fan for failure, this won't be an issue however, as it is normally on or off, and this behaviour can be enforced (you can have monitoring OR PWM but not both).
It might be the best solution is an external monitor giving a single line logic level OK/FAIL - it would still be great if Marlin can handle this neatly within the firmware!
AnHardt
commented
5 years ago It's very simple. As long as the fan gets a high enough voltage it turns and the circuit in the fan produces pulses. If you suddenly turn off the power the still turns, but the electronics is not able to produce pulses. Usually we drive our fans with a PWM, we set a on/off relation to adjust the fans speed. During the on-phase we se the pulses, but not during the off phase. If we count the seen pulses we almost only count our PWM-cycles. When the PWM pulses are long enough to for sure measure a real pulse the fans are very audible. The alternate attempt to not measure all the time but in short phase where the fan gets full power resulted in a whining sound. For counting the pulses polling does not work reliably (inside Malin). You have to use an interrupt capable pin, better one with a hardware counter.
edumaker-limited
commented
5 years ago Thanks very much, that's exactly the kind of explanation I was hoping for, to supplement what I understood was going on. So, we could use a 3-wire fan comfortably for heatsink cooling fans which are normally on at all times (or when over a temperature threshold). These are commonly available in suitable sizes IE 30x30x7-10, 40x40x10-20 We could also use a 4-wire fan for PWM controlled part cooling. The thresholds for triggering a fan under-speed alert would have to take into account the nominal fan speed and the duty cycle in force at the time, but I imagine that could get harder, and the first step is to have a minimum RPM count when the fan is known to be 'on'. To reduce the burden on the main processor and improve modularity I'm considering offloading this task to a dedicated microcontroller, which could send a simple OK/FAIL signal back to any digital input. Assuming spare interrupt capable pins on the main printer board (ATMEGA2580) is counting the pulses from 2 fans actually asking a lot from the MCU's resources?
AnHardt
commented
5 years ago For 4-wire fans the required 25 KHz PWM is challenging for the 8-bit processors. 16.000.000 / 25.000 = 640. 640 / prescaler = resolution. This results either in a fractional prescaler or a unusual number of states or not 25KHz. If not using a hardware PWM the processor could not do anything else.
github-actions[bot]
commented
4 years ago 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.
github-actions[bot]
commented
4 years ago 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.
github-actions[bot]
commented
4 years ago 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.
github-actions[bot]
commented
2 years ago 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.
Some all-metal hotends requires active cooling on cold end with a small fan. When this fan malfunctions, they quickly overheat and tend to cause damage to plastic mount which holds them.
A way to prevent this issue will be to assign one pin for RPM reading, and check the fan RPM every X seconds. When the RPM drops below given value, Marlin will stop heating hotend and give FAN_ERROR or something like that.
If something like this already exist in Marlin can you point me where to find it? If not, I would call it feature request.