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.
    • 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