Return Values from Macros

NineMile

One of the features that I think would make RRF meta gcode more obviously powerful is an inbuilt way to return values from macros back to where they're called.

At the moment this is possible using global variables, but requires writing handler code into every calling and called macro to handle those global vars, and if you don't use the same variable name(s) across all macros you can end up polluting the global namespace quite quickly (with the associated memory implications).

I had a quick look this morning to see whether it would be possible to extend the M99 call so that it can pass values back to the caller, similar to how acknowledging an M291 dialog can put values back into the input variable, and I ended up with something that works like this:

G901.g:

; Run child macro
G902
echo { "Returned Value: " ^ retval }

G902.g:

var testval = 902
while { iterations < 5 }
    set var.testval = var.testval + iterations

M99 R{ "Test", var.testval }

M98 P"G901.g" prints the output Returned Value: {Test,912}.

Is this something that has legs to be added to RRF itself?

Has this been thought about already and rejected for reasons I'm unaware of? Would be grateful to hear any input on this front

oliof

@NineMile the memory implications will be the same (or worse, since a bit more hidden in plain sight) with retvals.

NineMile

@oliof Only in the best case imo, where all macros that are called and return values do it using a single global variable, which is entirely dependent on the approach and understanding of the person(s) writing the meta gcode.

If it were possible to scope the retval constant to the calling macro so it is GC'd after going out of scope then I think this approach would be better in every way. No idea if that is possible though

My main reason for suggesting this change isn't memory optimisation. It's a quality of life suggestion to provide an obvious route to avoid repeating meta gcode that doesn't involve copying a bunch of boilerplate code across files to manage global variables, and all the associated issues that could come from that.

This could help to simplify complex macros and even make it viable for people to build 'function libraries' that can be integrated into others' macro code with an obvious API.

Right now, everyone who writes macros and wants to return a value will pick a global variable name that works for them - they might just use 1 (best case), or they might use one per "function" (worst case) or something else - but this means that there's no consistency when it comes to integrating macros or libraries that have potentially been written by different people.

dc42

@NineMile please create a feature request for this on the Github Issues page of the RepRapFirmware project.