As such, the heater cannot be controlled because the logic is being fed bogus information. If the (ribbon) cable comes unplugged in this state, the last temp keeps being read as if it's being updated even though the cable is physically not plugged in. If your PID is properly tuned, your system is printing and the last reported temp is perfectly normal but say 2C under the set temp, the heater will be in the on state because you are trying to reach the setpoint. Without a (hardware) change, there is no way code (firmware) can detect this state of error. Is this device no safe to run unattended?Ĭan I get rid of the fire extinguisher beneath my printer now? In which way do the changes prevent thermal runaway?Īre the mods discussed in this forum reg. I also would be interested to get more infos/details about the changes from our Raise3D-friends. What I'd be interested in would be users experiences. Modified M112 kill function to implement fast stop feature (uncomment #define DUAL to get dual head version.) In case to avoid the damaged second thermocouple on single head machine to generate an error Temperature reporting during heating period fixedĮnlarged thermal runaway protection range to fix the thermal error on certain machinesĪdd extruder number while throwing out max or min temperature error to help identify the corresponding thermalcoupleĪdd compile option for single extruder. Reimplemented thermal runaway function, added protection while changed by gcode Looking at the release notes I thought this might be a good idea to install.:Īdd history tracking into thermal runaway function Well, to be honest I have found the update by chance, I was looking for something completely different.Īnd then I did a search in the forum for "Motion Conrtroller Firmware 1.1.6" - and was surprised to find
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |