Conditional GCode and object model variables


  • administrators

    I've been working on the documentation and implementation of conditional GCode for the RRF 3.01 release. The core implementation is nearing completion, but there is much work remaining to implement the object model variables. Please can would-be users of this facility list which object model variables they would find most useful. Here are some that I have in mind:

    • Deviation reported by the last G29 or G32 command (so that you can repeat the command if the deviation was higher than expected)
    • Currently selected tool number (so that pause.g and other macro files can take different actions depending on which tool is selected)
    • Current workplace coordinate system number

    Also, what mathematical functions would be useful to have? I'm thinking sin, cos, tan, sqrt, abs.



  • Don't forget the basics ie +/-/:/x/>/</=
    You probably have those but just in case ....



  • Current tool position could be nice, During multi-hotend, pressure advance and retraction calibration it would allow printing multiple lines / objects with different offsets, and then manually jogging the head to the correct one and selecting that.

    I think that E3D guys already requested this feature a few months back.

    Also, floor, ceil, round? functions would be useful.



  • I would like to see extruder position as something able to be used. Been thinking about adding additional motor that would perform certain actions depending on the print head position. Not sure if there’s another way of doing this or not.



  • i remember some people asking for things like
    endstop status.
    axis homed status
    temperature
    is printing
    last command failed (failure to probe)
    macro parameters
    function to read value from analogue/digital pin

    here is an idea. have a json function that outputs the entire state of the duet as json.
    then have a jsonpath function that can be used to get whatever value is desired from that json.


  • administrators

    BTW in case anyone is wondering why it's taken a while: https://miscsolutions.wordpress.com/2019/12/27/using-exceptions-in-c-embedded-software/


  • administrators

    @jens55 said in Conditional GCode and object model variables:

    Don't forget the basics ie +/-/:/x/>/</=
    You probably have those but just in case ....

    Already have: + - * / = > < >= <= & I !


  • administrators

    @Veti said in Conditional GCode and object model variables:

    here is an idea. have a json function that outputs the entire state of the duet as json.
    then have a jsonpath function that can be used to get whatever value is desired from that json.

    This is essentially what I am implementing, except that a json representation of the entire state would be huge, so we don't actually construct it.



  • For me the most useful, by far, would be something that I can set myself: Set object value to something, use the value later. I write the software that sends G code to my machine myself, so I’d be happy with something simple, like
    “var1 = xx.xx” and later use “G0 X%var1%”.

    Perhaps more generally useful would be a way to set a value from a get command or a previously set value. Examples:
    varX = M114 X // set varX to current X position
    BedT = M140 S? // set BedT value to whatever was previously set by M140 command



  • While I don't have the whole plan ready to go I'd be most interested in functions that would enable me to probe the work piece in (CNC mode)

    Basic trig like you mentioned, tool diameters (either as user defined variables like JuKu mentioned or as part of the tool definition). And for user interaction attaching input pins to user prompts, with optional timeouts and default for M291. Input (and output) pin state instead of M582.

    Looking forward to experiment with this!



  • @dc42 said in Conditional GCode and object model variables:

    BTW in case anyone is wondering why it's taken a while: https://wordpress.com/post/miscsolutions.wordpress.com/3287

    took me to a login page. presumably this is the one? https://miscsolutions.wordpress.com/2019/12/27/using-exceptions-in-c-embedded-software/

    interesting read. thanks for sharing! (lots more to read as well i see, good stuff



  • @dc42 said in Conditional GCode and object model variables:

    why it's taken a while

    I hope you do know that gcc/g++ exceptions are not "really" thread-safe. Never used exceptions on embedded systems so can't confirm how it behaves on ARM but since you are using RTOS on the RRF3 you might wanna be careful 🙂

    As variables go, no idea, never used variables in G-Code, no clue what I'd use it for but I'm sure when I see how others are using it some ideas will be born 😄



  • @dc42 Math functions and the ability to store coordinates in temporary variables is what I am looking for. Also yes to the sin, cos, tan, sqrt, abs. It would be handy to have.

    Example of center find on X axis,

    Storing x axis location stop point in each direction. (H1 and H2).

    Then subtracting location 1 from location 2. (H3=H1-H2).

    Dividing the result in half. (H4=H3/2)

    Adding the new result to location 1. (H5 =H4+H1)

    Move to new location G1(H1).

    At some point when the center location is found the XYZ offset can then be saved to G10 for the tool with an M500.

    The "H" can of course be whatever name you are planning to use. In the Fanuc controls the variables are stored in locations with a "#". So I can call up a value to move to like this, G1 X12.125 Y#2265 F30.0. What ever is stored in 2265 gets transferred into Y.

    Not sure if you are planning to follow a GCode standard or not.



  • Perhaps it’s time for a library build in between newlib and newlib-nano

    I have seen number of these, they are pain to maintain and usually never get updated/patched ... actually now when I think about it, I don't think I ever seen one revisited after initially created for the project ... creating some "standard" newlib-milli and/or newlib-micro would probbly get traction if one is to dedicate one's time to maintain it...



  • Whilst I don't have anything specific in mind, I'd think that some type of switch/case function would be handy for many of the intended uses.



  • I swap between multiple mixing hot ends and have a number of configuration files to suit. I also use pre and post print macros rather than using the slicer start and end gcode. But if I use the wrong macro, I get errors setting temperatures for non-existant tools. So it would be great if I could have something like "If tool n exists, G10 Pn Snnn Rnnn". Then I'd only need one macro per filament rather than multiple macros to suit the number of tools defined in config.g as well as filament types.
    I'd also like to be able to run a purge macro depending on the time that a filament has been held at print temperature. So when printing PLA which will hydrolyse over time, when changing tools (filaments) a purge macro would only run if the time since the new filament was last used was greater than a predefined amount of time.


  • administrators

    @smece said in Conditional GCode and object model variables:

    I hope you do know that gcc/g++ exceptions are not "really" thread-safe. Never used exceptions on embedded systems so can't confirm how it behaves on ARM but since you are using RTOS on the RRF3 you might wanna be careful

    Interesting, I wasn't aware of that. Are you sure? Now that C++ supports threads natively, that seems odd. The implication is that gcc uses a static area of memory to do the stack unwinding. Anyway, it won't matter because only the GCode parsing part of RRF uses exceptions, and only one task calls that code.



    • Everything reported in an M408.
    • Time (ticks? ).
    • User (dynamic)
    • EVERY command that sets anything, perhaps as a %command% to make it easy to remember.

    The above probably covers this: Everything that has a position. The 'control point' Work coordinate systems, every kind of offset like tool offset, cutter offset, and so forth. Everything that has a position or offset.


  • administrators

    What I am actually asking for is the most useful things to include in the object model, so that I can do a beta release that is useful to some people. If I wait until I have implemented everything that I plan to include, it will be weeks or even months before the beta release.



  • The most useful thing for me would being able to detect a voltage on an input to identify which tool is fitted.
    E.g. tool 1 is 1V, tool 2 is 2V and so on.
    Then the machine would be aware of what tool is fitted and apply offsets accordingly etc.



    • Currently selected filament (Similar uses to currently selected tool)

    • min(), max(), ave() functions. Could be used universally. Like with G29 if your initial suggestion returned a list (max deviation) rather than a specific function alone for G29.



  • I use a Duet wifi card in my sand table. Right now I can program playlists using the M98 command, but it would be nice if there was some means to randomly select pattern files to run from among any gcode file stored in a specific directory on card 0 or card 1. It would be especially nice if I could call a single gcode macro file upon power-up that would then randomly select pattern files to run and just keep doing that until the machine is powered off (maybe days or weeks later). That would require some looping capability, I imagine.

    It would be especially nice if the random function were seeded by a real time clock or other means so that when I power up the table, the random sequence that it plays would be different every time (or almost every time).



  • @dc42 said in Conditional GCode and object model variables:

    Are you sure?

    Unfortunately, yes. that's for e.g. why Falcon never went GA after so many engineer years was put in and hundreds of bugs reported (and fixed) to both GCC and Intel C/C++ compiler. It's not unsafe by design, it's just that most C++ compilers have it buggy as hell. Today situation is much better than for e.g. 2009, but is still not resolved. Again, no clue how that relates to embedded systems, and if it relates at all.. it's just one of those things few ppl think about and can hit you below the belt when you least expect

    Now that C++ supports threads natively, that seems odd.

    If that's the only thing 😄

    only the GCode parsing part of RRF uses exceptions, and only one task calls that code.

    That's safe.
    I think it would be safe even if not only that 'cause the unsafe part start to pop up under contention, I don't finally remember all the details but but I think it's the number of threads and not the CPU load that was a problem so since I doubt you'll have issue with number of threads on the RRF you should be safe 😄 whatever you do... but yes, single thread using exceptions will never hit any of those bugs



  • @dc42

    Ternary operator like the c language ? :
    Very useful for doing machine specific parameter substitutions vs having to do if then else.

    Min, max functions

    Max z of the current print job. Useful for doing tuning of parameters. That, or an interpolate with z function. For example
    M572 DO S%zinterpolate(0.1,2.0)%
    which would be the same as
    M572 D0 S%0.1+(2.0-0.1)*z/max_z%



  • I suspect most of my conditional code use would be some form of
    while (measured value < setpoint) {
    move this
    move that
    pause a while
    }

    and if (this) then { that }

    The conditional code provided by LinuxCNC and accessing of state information through numbered or named variables is not all that complicated and works well enough.

    I would at prefer to have access to axis positions and sensor values.


Log in to reply