Is there a work around to restore the old heater fault handling?
-
@diy-o-sphere It might help if you explain what problems you have with the way that 3.4 handles heater faults and why you prefer 3.3.
-
This post is deleted! -
@gloomyandy
Out of the change log...The handling of heater faults has changed. When a heater fault occurs, an event is created. To handle the event, RRF runs macro file heater-fault.g without pausing the print first. The heater number is passed as param.D along with some other parameters. If file heater-fault.g is not found then the print is paused and the user is notified. Currently, RRF does not attempt to turn off power to the whole machine if the user does not respond to the heater fault. We plan to reinstate this or a similar function in release 3.5.0.
(UTC+1)
-
-
@diy-o-sphere you could set up your own heater fault script to reinstate the behavior. I usually point towards @OwenD's fantastic macro collection at https://github.com/owendare/RepRapFirmware-Macros but that's a bit too involved for my taste for a critical piece of functionality, even though it implements a lot of safety logic -- so maybe do follow that (-:
-
@diy-o-sphere good question. This applies to the subset of users who control the power supply to their machine from firmware (most do not). If you do then there is a requirement to be more explicit, in your macro handling of events, what you want to happen in the case of a heater fault. As @oliof has pointed out you can specify you want the power to the machine (if controlled by firmware) to be shut off after some time after a heater fault.
Over all the new event management system will allow for much more granular and user/usecase specific handling of "issues" (they are not always a significant problem for some people).
-
@t3p3tony I still share the concern that taking out the old functionality and asking people to write their own macro for a critical safety feature is not great. As described the current 3.4 behavior doesn't not only switch off all power, it also doesn't switch off heaters or motors in case of a fault, so depending on the heater fault this could mean a fully powered heater running while the machine sits in pause mode. If that isn't correct, the documentation needs some clarification.
-
@oliof said in Is there a work around to restore the old heater fault handling?:
If that isn't correct, the documentation needs some clarification.
It seems that there was a change in the documentation after this post was made.
I just found it by chance. https://docs.duet3d.com/User_manual/RepRapFirmware/Events
Which brings me back to this topic again.It is a pity that there was no direct answer to this question. At least the behavior is now described understandable for me.
@dc42 If in 3.5 the standard behavior is reintroduced and only optionally the event handling by macro is accessed this would be great.
One point I would still like to consider. For me it seem to make sense to load the event handling macros already into the memory at boot time . And not only be read in case of an error. But in case of a card error, hopefully the standard routine of the firmware would then take effect. -
@DIY-O-Sphere there is now a category for documentation issues if you spot them:
https://forum.duet3d.com/category/42/documentation -
@T3P3Tony
I had actually hoped that there would be some kind of announcements about changes in the documentation. Or the places that have been changed are easier to find.
I always find very well updated info. One notices that you put effort into it. -
@DIY-O-Sphere Ahh I see, I will need to see if the documentation software allows for change list to be viewed.
-
undefined DIY-O-Sphere referenced this topic
