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

    Where can I access persistent state?

    Scheduled Pinned Locked Moved
    Beta Firmware
    4
    11
    232
    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.
    • jltxundefined
      jltx
      last edited by

      I am trying to debug an issue related to gcode state. In this case it is relative vs absolute positioning. Somehow my machine is left in the wrong state but I can't find the error in my configs.

      I looked in the object model but could not find it. Is there a gcode command to dump it out? I'd also like to know current feed rate for each axis.

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

        @jltx It's in the object model, separately for each source of GCodes.

        ab65fa1f-9d9e-48a9-996a-85987cd7a260-image.png

        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

        jltxundefined 2 Replies Last reply Reply Quote 0
        • jltxundefined
          jltx @dc42
          last edited by

          @dc42 perfect! thanks, I knew it had to be there. Totally missed that section.

          1 Reply Last reply Reply Quote 0
          • jltxundefined
            jltx @dc42
            last edited by

            @dc42 this is eye opening and explains some things. Just to confirm, each source of gcode maintains a separate state. In addition, it looks like the state of a macro is local and not persistent? So if I leave one macro with G91 (relative) it flips back to absolute when the macro ends. So if I chain macros I need to assume the state is not preserved? What about nested macros?

            infiniteloopundefined 1 Reply Last reply Reply Quote 0
            • infiniteloopundefined
              infiniteloop @jltx
              last edited by infiniteloop

              @jltx

              this is eye opening

              Better risk a second look, for instance at the G91 GCode. In the Notes section, it states:

              The flag state is saved when a macro starts and is restored when a macro ends.

              If every macro had to preserve the complete machine state when called, the Duet would run out of steam memory very fast.

              The GCode meta commands are an essential reading and an indispensable reference for macro coders as well. In the GCode Dictionary, look up the details of any G-, M- and T-Codes you are interested in. For the third source, @dc42 already mentioned the object model which you can most easily access by means of the DWC plugin.

              However, even an excessive documentation will not cover all and every detail, not to talk of unknown side effects. That's why macros (sometimes even single code lines) have to be tested. When I write a macro, I often carry one or more temporary macros with me, using them as a test bed for code snippets or to check the persistence of vars across a call chain. Last but not least, there's always this incredible forum to help you out 😊

              Edit: I've contributed some sample code to your second thread. To put down these few code lines, I had to run several tests. To get rid of the error messages and warnings, I consulted the "GCode meta commands" multiple times. BTW, over time, that has become kind of a misnomer for this document, I call it the "RRF Macro Programmer's Reference".

              jltxundefined 1 Reply Last reply Reply Quote 0
              • jltxundefined
                jltx @infiniteloop
                last edited by

                @infiniteloop said in Where can I access persistent state?:.

                If every macro had to preserve the complete machine state when called, the Duet would run out of steam memory very fast.

                This is the opposite of what my mental model has been. I thought there were just a few global bits that got altered by the most recent call and stuck until changed. I do see that is documented clearly in the dictionary. I normally read all of any new commands but I was already familiar (so I thought) with G91 that has no arguments so didn’t dig in to the details. My bad.

                To be clear, I don’t have a problem with this but it is a large change to how I was assuming it worked and I need to correct my debug strategy. In particular, the eye opening part, is that when I make a change through DWC and then walk over to the room with the printer to visually observe and use the LCD interface for further commands I am not using the same state I had just altered. And that explains some very odd behavior I was observing.

                infiniteloopundefined 1 Reply Last reply Reply Quote 0
                • infiniteloopundefined
                  infiniteloop @jltx
                  last edited by

                  @jltx

                  I normally read all of any new commands but I was already familiar (so I thought) with G91 that has no arguments so didn’t dig in to the details. My bad.

                  No excuses required. The sheer mass of documentation has become an invitation to some quite interesting hide-and-seek sessions.

                  I make a change through DWC and then walk over to the room with the printer to visually observe and use the LCD interface for further commands…

                  Well, that can sum-up to some miles to go. I prefer to test my code in isolation, i.e. with all potentially harmful GCodes commented out (as far and as long as possible), so that I can stay in front of DWC most of the time. Often, some echos can do the job.

                  droftartsundefined 1 Reply Last reply Reply Quote 0
                  • droftartsundefined
                    droftarts administrators @infiniteloop
                    last edited by

                    @infiniteloop @jltx There is also @OwenD 's Conditional G Code best practice.pdf (last updated Feb 2024 I think) from https://forum.duet3d.com/post/155650. I don't know if this is up to date with any changes in RRF 3.6, though.

                    Ian

                    Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

                    infiniteloopundefined jltxundefined 2 Replies Last reply Reply Quote 0
                    • infiniteloopundefined
                      infiniteloop @droftarts
                      last edited by

                      @droftarts Good hint, THX. @OwenD's code is in fact a joy to read.

                      1 Reply Last reply Reply Quote 0
                      • jltxundefined
                        jltx @droftarts
                        last edited by jltx

                        @droftarts said in Where can I access persistent state?:

                        @infiniteloop @jltx There is also @OwenD 's Conditional G Code best practice.pdf (last updated Feb 2024 I think) from https://forum.duet3d.com/post/155650. I don't know if this is up to date with any changes in RRF 3.6, though.

                        Ian

                        Thanks for the pointer! I will digest that.

                        I realize I have built a quantum printer. When I am not observing it then it can print anything, but when I observe it the wave function collapses and the cat is definitely dead. 😸

                        infiniteloopundefined 1 Reply Last reply Reply Quote 0
                        • infiniteloopundefined
                          infiniteloop @jltx
                          last edited by

                          @jltx

                          the wave function collapses and the cat is definitely dead.

                          Common wisdom: Never bet on a cat, they always know better…

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