Where can I access persistent state?
-
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.
-
@jltx It's in the object model, separately for each source of GCodes.
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 -
@dc42 perfect! thanks, I knew it had to be there. Totally missed that section.
-
@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?
-
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
steammemory 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".
-
@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
steammemory 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.
-
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.
-
@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
-
@droftarts Good hint, THX. @OwenD's code is in fact a joy to read.
-
@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.
-
the wave function collapses and the cat is definitely dead.
Common wisdom: Never bet on a cat, they always know better…
