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

    Any g-code in stop.g causes heaters to turn off

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    7
    25
    2.3k
    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.
    • fmaundefined
      fma @jv43
      last edited by

      @jv43 said in Any g-code in stop.g causes heaters to turn off:

      maybe for safety reasons if stop.g or cancel.g are not present/readable or corrupted in some way

      If the SD card is corrupted, the M0/1/2 commands won't be executed anyway; the chance that the SD card fails right after the M0 command is read, and before the macro is read is close to nothing 😉

      We could also imagine a more global safety feature, shuting down the entire printer in case a SD corruption is detected.

      Frédéric

      jv43undefined 1 Reply Last reply Reply Quote 0
      • jv43undefined
        jv43 @fma
        last edited by

        @fma I wasn' talking about a corrupted sd card, but a corrupted file (maybe after unexected power loss during edit?)
        M0 will work with no cancel.g/stop.g present and default behaviour is to shut off all heaters.

        1 Reply Last reply Reply Quote 0
        • gnydickundefined
          gnydick @jv43
          last edited by

          @jv43 What's really strange logic is that cancel.g is preferred. I don't have a cancel.g. I had an empty stop.g. The heaters didn't turn off from a cancel.

          Then when I added code to the stop.g, it did turn off the heaters. Either way, there was no cancel.g, so why did adding code to the stop.g cause the heaters to turn off when in both cases, there was no cancel.g. Just feels not so intuitive.

          dc42undefined 1 Reply Last reply Reply Quote 0
          • A Former User?
            A Former User
            last edited by

            https://github.com/T3P3/Duet/blob/master/Duet2/SD Card Contents/sys/cancel.g

            By default there is a cancel.g file.

            1 Reply Last reply Reply Quote 0
            • wilrikerundefined
              wilriker
              last edited by

              Also what is interesting here is the question how you cancel the print? DWC (both 1 and 2) will send M0 H1 which leaves the heaters on.

              Manuel
              Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
              with probably always latest firmware/DWC (incl. betas or self-compiled)
              My Tool Collection

              1 Reply Last reply Reply Quote 0
              • dc42undefined
                dc42 administrators @gnydick
                last edited by dc42

                @gnydick said in Any g-code in stop.g causes heaters to turn off:

                @jv43 What's really strange logic is that cancel.g is preferred. I don't have a cancel.g. I had an empty stop.g. The heaters didn't turn off from a cancel.

                Then when I added code to the stop.g, it did turn off the heaters. Either way, there was no cancel.g, so why did adding code to the stop.g cause the heaters to turn off when in both cases, there was no cancel.g. Just feels not so intuitive.

                Please test that again. That's not what should happen, and I can't think of any type of firmware bug that would cause that. If there is no stop.g or cancel.g file, then the heaters should be turned off by the firmware. Except if you terminate it using DWC and it sends the H1 parameter on the M0 command. [I didn't agree with the introduction of the H1 parameter, and I am minded to remove it.]

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                1 Reply Last reply Reply Quote 0
                • alexjxundefined
                  alexjx
                  last edited by

                  I observed a similar issue recently too. When sending "M0 H1", if I put any code into stop.g, my heaters are all off and my tool got deselected. But the behavior is different if the file is empty. I believe this is a bug. I think the problem happens because the machine state is pushed to stack but the gcode buffer is not.
                  The stopping logic is executed after the macro runs, then testing the "H" flag. By then the gcode buffer contains the last line in the macro. The stopping will always be executed as if there is no "H" flag. This is confirmed if I put an "M117 H1" into the last line of stop.g, "M0 H1" behaves as expected.

                  I currently don't have a simple solution, since the state should be set to "normal" when macro exists, but by then the state has already pushed to stack...

                  @dc42 said in Any g-code in stop.g causes heaters to turn off:

                  [I didn't agree with the introduction of the H1 parameter, and I am minded to remove it.]

                  I think the H flag has its use for cases. Excuse me that I'm new to RRF. But I found that once the heater got disabled, only tool re-select will enable it back on.
                  I have a dual extrusion printer, similar to an Ultimaker 3 with a lifted second nozzle. With this setup, the "no tool selected" state is actually invalid.
                  If the current mechanically activated tool is selected again, the switch will hit the switching dock in a very unpleasant way. If there is no other solution, I think the "H" flag, in this case, will benefit my scenario.

                  1 Reply Last reply Reply Quote 0
                  • dc42undefined
                    dc42 administrators
                    last edited by

                    Thanks @gnydick and @alexjx, I confirm this is a bug. I will fix it in firmware 2.03RC4.

                    Duet WiFi hardware designer and firmware engineer
                    Please do not ask me for Duet support via PM or email, use the forum
                    http://www.escher3d.com, https://miscsolutions.wordpress.com

                    1 Reply Last reply Reply Quote 0
                    • dc42undefined
                      dc42 administrators
                      last edited by

                      This is now fixed.

                      Duet WiFi hardware designer and firmware engineer
                      Please do not ask me for Duet support via PM or email, use the forum
                      http://www.escher3d.com, https://miscsolutions.wordpress.com

                      alexjxundefined 1 Reply Last reply Reply Quote 0
                      • alexjxundefined
                        alexjx @dc42
                        last edited by

                        @dc42 Confirmed working. Thanks.

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