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.
    • jv43undefined
      jv43 @gnydick
      last edited by

      @gnydick what firmware version are you running?
      I never added a "cancel.g" and i just checked, it's in my sys files.
      I just added

      M106 P0 S0
      

      to my cancel.g and it turned off the part cooling fan, while keeping all heaters on.

      yeah, that makes sense, but this feels like another example of assumed use case rather than the machine just doing what it's told. What If I didn't want the heaters to turn off at the end of the print?

      Using cancel.g when cancelling a print seems like the machine IS doing exactly what it's told.
      So I don't really see the problem in creating cancel.g or updating your FW

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

        @jv43 no problem with using the cancel.g. my point was that intrinsic behavior is problematic. We have start, stop, layer change, tool change, etc. scripts in our slicers; I don't want my printer to get involved.

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

          So you want to use M0 with your slicer?
          try

          M0 H1
          

          and add

          M106 P0 S0
          

          to your stop.g
          please test if thats now behaving as you want it to.

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

            @jv43 that's not my issue. I know how to program the machine. The fact that it does things with no instruction is what bothers me.

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

              @gnydick running M0 with no H1 parameter shuts all heaters off. This is normal behaviour for any FW based on the RepRap FW and always worked that way afaik. I never used any other FW except for marlin, which is also based on RepRap, so i can't comment on the behaviour of other firmwares when executing M0.
              This behaviour is documented on the RepRap wiki as well as the Duet documentation, so it does exactly what you instructed it to do?

              1 Reply Last reply Reply Quote 0
              • fmaundefined
                fma
                last edited by

                The difference is that RRF triggers macros (stop.g, cancel.g...).

                Why not just call the macros, and do nothing if they are not there? By default, the macros could contained what is now implicitly done, so things are explicit, but can be more fine tuned...

                The current behaviour, whith several if/then/else, is confusing.

                Frédéric

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

                  @fma that's exactly right. @jv43 my point has nothing to do with how to do it. It's the fact that the firmware does things WITHOUT being instructed to do so. That is, IMHO, never a good way to do things. In fact, the fact that we have access to all of these macros (/sys/*.g files) is the exact emblematic implementation of someone thinking a machine should only do what it's told and not have any innate logic. To expose the ability to customize everything and then have the machine do things that you can only change by editing the firmware itself, is counterproductive.

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

                    @gnydick I definately agree it would be better to put the gcode in the macro itself rather than having it be empty by default and have some other code run when no actual gcode is present in that macro, maybe @dc42 can give some insight why it was implemented this way (maybe for safety reasons if stop.g or cancel.g are not present/readable or corrupted in some way).
                    You're posting in tuning and tweaking, so I thought you mainly wanted to make it work.
                    In that case my suggestion would be to create cancel.g and add your code.

                    For fundamental changes to RRF I'd suggest you post in Firmware Wishlist.
                    David is currently working on RRF 3.0 and I think that thread is open for suggestions too.

                    fmaundefined gnydickundefined 2 Replies Last reply Reply Quote 0
                    • 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