Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Heater Fault handling improvements

    Scheduled Pinned Locked Moved
    General Discussion
    6
    23
    1.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T3P3Tonyundefined
      T3P3Tony administrators @OwenD
      last edited by

      @owend said in Heater Fault handling improvements:

      What you're asking for is pretty much for RRF to hand over all control of heater safety to the end users. That's a recipe for disaster IMO.
      And yes I note you stated that this would be dependent on the existence of a macro.

      At this stage the plan is to extend the current heater fault behaviour to also work when the heater that has the fault is on a CAN expansion board.

      www.duet3d.com

      1 Reply Last reply Reply Quote 0
      • jbjhjmundefined
        jbjhjm @OwenD
        last edited by jbjhjm

        @owend I agree to your thoughts, however I think my idea is a bit different to what you described. Maybe my initial post was too imprecise.

        I am not talking about a macro REPLACING the automated fault reaction.
        I am talking about a macro called AFTER reacting to a fault.

        As far as I can see this does not violate any safety behavior or risk the safety routines to be broken.
        However it allows for additional, individual measurements. Let yourself be notified by a beeper that there's some trouble for example. That would even increase safety because one will take notice sooner and can react faster.

        In other cases, like those that have just happened to me, there was no real fault, just the layer fan at 100% cooling the hotend so much that a fault was detected.
        In this case, if the printer stops immediately (Toolboard CAN fix) and notifies me immediately (beep, show a big message), I am able to react fast enough to check what has happened and allow the print to continue. (Of course only if I'm 100% sure no real fault has happened. And yes, I already did this successfully, but only could do so cause I knew a certain print will very likely fail due to "cooldown fault" and was sitting next to the printer with a finger on the pause key.)

        1 Reply Last reply Reply Quote 0
        • wdenkerundefined
          wdenker @T3P3Tony
          last edited by

          @t3p3tony correct it paused for a limited time and then the print is gone. It just needs to stay paused indefinitely. I think the time limit is like 5-10 minutes but I'm only checking the printers once every 5-6 hours.

          www.bd3dcustoms.com | BD3DCUSTOMS Supercube

          OwenDundefined 1 Reply Last reply Reply Quote 0
          • OwenDundefined
            OwenD @wdenker
            last edited by OwenD

            @wdenker said in Heater Fault handling improvements:

            @t3p3tony correct it paused for a limited time and then the print is gone. It just needs to stay paused indefinitely. I think the time limit is like 5-10 minutes but I'm only checking the printers once every 5-6 hours.

            An indefinite pause, is in my mind a dangerous situation when you have a heater fault.
            If you're getting heater faults then essentially you have a tuning or hardware problem (if caused by a fan).
            However, it's not hard to implement some code to notify you of a fault and allow you to act before RRF shuts off the printer.
            Something like this in daemon.g should work.
            If you want it to run at intervals less than 10 seconds, put the whole thing a while true loop.

            ;create a global to stare how meany heaters are in error state
            if !exists(global.HeaterErrorCount)
            	global HeaterErrorCount=0
            else
            	set global.HeaterErrorCount==0
            	
            ; loop through al heaters and check state for fault
            while iterations < #heat.heaters
            	if heat.heaters[iterations].state=="fault"
            		set global.HeaterErrorCount==global.HeaterErrorCount+1
            		
            ;if any heater is in error state, sound an alarm	
            if global.HeaterErrorCount>0		
            	M42 P6 S1 ; turn on GPIO connected to alarm relay
            	; do some more code to send a text, flash a light or whatever
            else
            	M42 P6 S0 ; turn off GPIO connected to alarm relay
            

            You could also investigate BtnCmd and the other plugins which have the ability to use HTTP Post, or MQTT to send you a notification.

            wdenkerundefined 1 Reply Last reply Reply Quote 0
            • wdenkerundefined
              wdenker @OwenD
              last edited by

              @owend I don't see how an indefinite pause would be dangerous the heater is turned off that has faulted. Which gives me time to fix the issue at hand and continue where it left off.

              www.bd3dcustoms.com | BD3DCUSTOMS Supercube

              OwenDundefined 1 Reply Last reply Reply Quote 0
              • OwenDundefined
                OwenD @wdenker
                last edited by

                @wdenker
                We'll have to agree to disagree...
                The reason I see it as a dangerous move is that you have no way of knowing what caused the fault code, or how serious it is. Especially in the five hour timeframe you quote.
                For example, if it's a heater runaway, then in it's possible the heater can't be shut down.
                That's why RRF also calls M81.
                Now if you have a thermal fuse and other hardware safety features, perhaps you can take the risk.
                In any case, if the above code doesn't allow you to react in the timeout allowed before forced shutdown then you'll need to continue arguing the case for a configurable option to ignore the fault.

                wdenkerundefined 1 Reply Last reply Reply Quote 0
                • wdenkerundefined
                  wdenker @OwenD
                  last edited by

                  @owend of it was stuck on because of a hardware fault shutting down the board wouldn't resolve it either.

                  www.bd3dcustoms.com | BD3DCUSTOMS Supercube

                  OwenDundefined 1 Reply Last reply Reply Quote -1
                  • OwenDundefined
                    OwenD @wdenker
                    last edited by

                    @wdenker said in Heater Fault handling improvements:

                    @owend of it was stuck on because of a hardware fault shutting down the board wouldn't resolve it either.

                    M81 is called to allow the power supply to the heater(s) to be turned off.
                    So if your system is configured with proper safety in mind, then yes, it will resolve the problem in most cases.
                    I guess frozen duet would be the exception, but then you wouldn't have a heater fault problem either 😉

                    wdenkerundefined 1 Reply Last reply Reply Quote 0
                    • wdenkerundefined
                      wdenker @OwenD
                      last edited by

                      @owend so when I say pause I mean after the heater is turned off. So that I can repair the issue and then bring temp back and continue. The only thing I don't like about the current setup is that it times out after so long to where you can't recover.

                      www.bd3dcustoms.com | BD3DCUSTOMS Supercube

                      T3P3Tonyundefined 1 Reply Last reply Reply Quote 0
                      • T3P3Tonyundefined
                        T3P3Tony administrators @wdenker
                        last edited by

                        @wdenker what is your M570 command set to?
                        https://duet3d.dozuki.com/Wiki/M570
                        You can use the S parameter to set a number of minutes between a heater fault and the subsequent cancellation (and power off)

                        Snnn Integer timeout in minutes (can be set to 0) for print to be cancelled after heater fault (Firmware 1.20 and later). If the S parameter timeout occurs (which only happens if a SD print is in progress), RRF will also try to turn off power via the PS_ON pin.

                        www.duet3d.com

                        wdenkerundefined 1 Reply Last reply Reply Quote 1
                        • wdenkerundefined
                          wdenker @T3P3Tony
                          last edited by

                          @t3p3tony I don't have one didn't even realize I could configure that. How new is this?

                          www.bd3dcustoms.com | BD3DCUSTOMS Supercube

                          T3P3Tonyundefined 1 Reply Last reply Reply Quote 0
                          • T3P3Tonyundefined
                            T3P3Tony administrators @wdenker
                            last edited by

                            @wdenker its been around in some form since RRF 1.14

                            www.duet3d.com

                            zaptaundefined 1 Reply Last reply Reply Quote 0
                            • zaptaundefined
                              zapta @T3P3Tony
                              last edited by

                              @t3p3tony said in Heater Fault handling improvements:

                              @wdenker its been around in some form since RRF 1.14

                              That's only 2.16 versions ago.

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Unless otherwise noted, all forum content is licensed under CC-BY-SA