Conditional GCode and object model variables

[dc42]

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.

[jens55]

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

[denke]

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.

[TLAS]

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.

[Veti]

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.

[dc42]

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/

[dc42]

@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 !

[dc42]

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

[JuKu]

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

[A Former User]

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!

[A Former User]

@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

[A Former User]

@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

[timcurtis67]

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

[A Former User]

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

[OwenD]

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.

[deckingman]

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.

[dc42]

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

[Danal]

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

[dc42]

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.

[jay_s_uk]

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.