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

    How should the firmware respond to a heater fault?

    Scheduled Pinned Locked Moved
    Firmware wishlist
    13
    19
    2.9k
    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.
    • DjDemonDundefined
      DjDemonD
      last edited by

      I think that covers a very sensible sequence which allows for maximum recoverability without compromising safety in any major way.

      Simon. Precision Piezo Z-Probe Technology
      www.precisionpiezo.co.uk
      PT1000 cartridge sensors NOW IN, just attach to your Duet board directly!

      1 Reply Last reply Reply Quote 0
      • PropellerHatundefined
        PropellerHat
        last edited by

        This sounds great. All the safety and flexibility to continue.

        1 Reply Last reply Reply Quote 0
        • nhofundefined
          nhof
          last edited by

          Sounds good, as long as we can disable the (eventual) bed heater timeout if we don't want it.

          1 Reply Last reply Reply Quote 0
          • DocTruckerundefined
            DocTrucker
            last edited by

            Was this implemented? I want to be able to shut down the heaters using M81 on heater fault but can't find the gcode to set this up?

            Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

            1 Reply Last reply Reply Quote 0
            • DocTruckerundefined
              DocTrucker
              last edited by DocTrucker

              Continued my a dig around and thought to check the 1.20 release notes on the following link.

              https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md

              This has the comment:

              "When a heater fault occurs, the print is now paused and all heaters are turned off except bed and chamber heaters. After a timeout period, the print is cancelled, all remaining heaters are turned off, and the firmware attempts to turn the power off as if M81 had been received."

              I am guessing this timeout value is the timeout mentioned to cancel a print:

              "Heater fault timeout to cancelling print is now configurable (M570 S parameter, in minutes)"

              Why does the gcode reference refer to the M570 as the time in seconds the heater has to reach a set temperature before a fault was raised in seconds? From the release notes I was expecting M570 to be time in minutes after a fault before a build is cancelled and M81 called?

              https://duet3d.dozuki.com/Wiki/Gcode#Section_M570_Configure_heater_fault_detection

              Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

              1 Reply Last reply Reply Quote 0
              • timcurtis67undefined
                timcurtis67
                last edited by

                I like the sequence.

                1 Reply Last reply Reply Quote 0
                • Barracuda72undefined
                  Barracuda72
                  last edited by

                  Something i would like:

                  The Error message is not very clear..had 1 week ago a heater fault every large print. Bed shut off ( thats bad because i use a Ultrabase so the print popped off when bed is cold) but i cant tell where exactly was the problem..would be fine if you can read the temp chart because..if temp dropped 100° within a sec its clearly the thermistor..if temp drops more slowly its the heater cartridge.

                  Btw..that black plugs on Smart effector sucks. only small chance to get a faulty pin out of the plug housing. Wished we had there the other plugs too

                  carlossprundefined 1 Reply Last reply Reply Quote 0
                  • carlossprundefined
                    carlosspr @Barracuda72
                    last edited by carlosspr

                    @barracuda72 Step 3 would leave bed ON, therefore covering your use case.

                    In general I would replace the step 6 by a "Macro" (something like on heaterfault0.g). This macro could include the actions as described on M81 or be configured by the user to its preferences.
                    It is not the same a heater fault on the Bed than a heater fault on the nozzle. The basic security steps could cover any failure modes, but a macro associated to the heaters would be the more flexible option and would give room for improvements without further code changes required. Something like the Toolchange macros for each defined tool.

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

                      I like the idea of replacing the sequence of steps with a macro or macros. That is in line with the general RepRepFirmware philosophy. We can have the current behaving in the macro(s) as a default so no change is noticed unless someone wants to change their macros.

                      (also p.s. zombie thread revival!)

                      www.duet3d.com

                      DocTruckerundefined denkeundefined 2 Replies Last reply Reply Quote 0
                      • DocTruckerundefined
                        DocTrucker @T3P3Tony
                        last edited by

                        @t3p3tony said in How should the firmware respond to a heater fault?:

                        (also p.s. zombie thread revival!)

                        Ish. I was asking about the current implementation of the feature as it isn't clear from the release notes and the release notes don't tally with the duet g-code documentation.

                        Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

                        1 Reply Last reply Reply Quote 1
                        • denkeundefined
                          denke @T3P3Tony
                          last edited by

                          @t3p3tony
                          replacing the sequence with a macro could be dangerous:
                          Assuming a faulty / detached thermistor, if someone made an incorrect / empty heaterfault.g file, which would not turn off the faulty and eventually all heaters, it would quite probably cause a fire ... IMHO some safety features should never be modified by mere mortals / end users...

                          Plus if I'm correct quite a few functionality is missing to implement this .... the gcode would have to receive props (variables / constants) for this (describing the faulty heater) and accept variables / constants as parameters to be able to turn only the faulty heater off... and there is the problem of the timeout also to turn all heaters off at the end... This timeout should be able to be interrupted and not execute the code to turn all heaters off, if the heater fault is cleared....
                          So:
                          Function defining
                          variable handling
                          variable passing
                          reference passing
                          conditional execution ( if ... else )
                          loops, (iteration ... it is not structly required, but its absence makes the code ugly)

                          function heaterfault (*heaterFault, faultyHeater, allHeaters) {
                          heater_off(faultyHeater);
                          cnt = 3600;
                          while (cnt -- > 0 && *heaterfault == true) {
                          sleep 1;
                          };
                          if (*heaterfault == true) {
                          for (heater, allHeaters) {
                          heater_off(heater);
                          };
                          };
                          };

                          The code is very incomplete, it just serves to illustrate he scope of the task...

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

                            possibly we can get part of the way by having a macro for a heater fault on each heater, but i take you point about a user misconfiguring it. its a trade off between usability in some cases against people misconfiguring something where the defaults are sensible.

                            www.duet3d.com

                            denkeundefined 1 Reply Last reply Reply Quote 0
                            • DocTruckerundefined
                              DocTrucker
                              last edited by DocTrucker

                              Can some one please clear up my question regarding the difference between the release notes and the wiki?!

                              Regards safetys I can't see why it shouldn't be simple. Safe as possible by default with the option to opt out if required. Make this clear in the release notes and we should only have a few months of posts questioning why things aren't working like the recent no move before homing! 😉

                              Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

                              1 Reply Last reply Reply Quote 0
                              • denkeundefined
                                denke @T3P3Tony
                                last edited by

                                @t3p3tony
                                My opinion is that the end user should never have the freedom to set his/her equipment and consequently his/her house on fire however neglegant / short sighted he/she may be.

                                1 Reply Last reply Reply Quote 0
                                • Dr_Ju_Juundefined
                                  Dr_Ju_Ju
                                  last edited by

                                  My take on it, would be that any heater fault detected, should imediately re-set the printer thereby disabling all sources of heat generation i.e. bed & heater cartriges and motors.

                                  My own recent experience of a Simplify3D remote USB print failing, hours into the print, the hot end heater stopped, but the bed & motors carried on as if nothing had happened.

                                  I realise that being remotely driven the Web interface would not know about the print, but the Duet board had detected & raised the problem, but to my mind, didn't cleanly shut down the printer.

                                  2 penneth

                                  Julian,

                                  Old goat, learning new things….

                                  1 Reply Last reply Reply Quote 0
                                  • EdChamberlainundefined
                                    EdChamberlain
                                    last edited by

                                    @dr_ju_ju said in How should the firmware respond to a heater fault?:

                                    My take on it, would be that any heater fault detected, should imediately re-set the printer thereby disabling all sources of heat generation i.e. bed & heater cartriges and motors.

                                    If a mosfet fails open (e.g. heater on) then a controller reset will not prevent heating - what you ideally want is a digital IO to a kill switch, cutting the mains power.

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