[Discussion] Parameter support for G-Code Macros

[FHeilmann]

Hi everyone,

I've been using my Duet Wifi for some time, and really enjoyed making use of the M98 macro call function. During my usage I found myself wanting a basic parameter facility for macros, so you can remove some redundancy in e.g. heating macros.

Here is what I came up with:

Allow M98 to have other parameters (lets go with A B C D E F for now as they don't shadow G or M)

e.g. M98 P"/macros/heatup_macro.gcode" A220 B60

Inside this macro called by M98, allow G-Codes to reference these parameters using special syntax, i.e.

G10 P0 R0 S{A}
M116
M190 S{B}

Especially paired with stuff like Slic3rs conditional g-code execution, this would open up a lot of possibilities for generic macros.

I have a basic mockup of the whole thing in an offline repo. In its current state it bootloops the CPU unfortunately, so I thought I'd rather start the discussion before putting more time into it. IF this gains some traction I'll of course share it.

Things this will give us

• Generic macros, not just for heating, also movements could be parametrized and allow for e.g. generic calibration cubes: just pass a location and a temperature and off you go.

Things that need to be discussed/standardized

• Parameter types: Of course if you pass an int using one parameter and use it in a gcode that expects a string, things could get messy. A little bit of wiggle room presents itself with the abilities to move between ints, doubles and floats and just converting whenever necessary. Another thing that could be done is having specific letters represent specific paramter types (i.e. A and B are ints, C and D are floats, etc.)

• Memory usage: No idea how good/bad this is going to be.

• Protecting the user from the user: Maximum gcode lengths and the like are already handled by the firmware, but I imagine there is several ways this can go wrong.

• Macros calling macros: Same thing here. Memory usage and protection against failures is key.

Thanks for your time, I am looking forward to your discussion.

[dc42]

There are already some other schemes for implementing variables and parameters in GCode, so we should probably adopt one of them instead of inventing our own scheme. Here are some examples:

http://linuxcnc.org/docs/html/gcode/overview.html#_parameters https://www.cnccookbook.com/fanuc-macro-system-variables-cnc-g-code-parameterized-programming/

[Stroppel]

To be honest it doesnt matter to me what type of variables we use but i really like to see this. I just wanted to create a filament change makro and set the extrusion factor for this filament. But the gcode for the extrution factor is global or i have to set the extrude explicitly. Till now the makro is filament specific but not extruder specific. If I now want to have the extrution factor be set in the macro i have to generate makros for all combination of filament in extruder. As I am just trying to build a filament changer functionality for my printer this will explode the amount of macros I need.... And all that just because i have no information inside the macro, in what extruder the filament was loaded...

Greetings

[Schleichmichl]

+1! I have a kraken and need this parameters, too. This opens a new world of possibilities.

[FHeilmann]

closing due to inactivity.

[dc42]

I plan to implement macro parameters as part of the work on variables and conditional GCode that is scheduled for RRF 2.04.