returning a "result value" with M99
-
I did a search for "M98 result" and did not find something that matches. So my question is: Is there a way to receive a result from a macro execution (done via M98 P"...") back to the calling line of code?
I imaging that this would be similar to that "iterations" variable in loops which has a very specific context and lifetime. Its use would be :M98 P"some-macro.g" ... set var.gotValue = result
where the variable "result" is provided directly after that M98 command. It may get its value inside of the called macro "some-macro.g" when a explicit M99 is executed:
; this is my macro "some.macro.g" with a lot of embedded commands ... M99 200 ; return with "result" = 200
I do not know if this is very complicated to implement on basis of the current RRF 3.4, but I would be even happy if I could get a simple "true" / "false" back from a M98. As far as I have understood the "abort" command, it willl kill the complete chain of macros executed and can not be used to return with a "failed" indicator to its direct calling macro?!
-
You would need to create a global variable and use that to contain whatever "result" you want your macro to return.
if !exists(global.result) global result = false M98 P"some-macro.g"
If you then set your global to false at the start of your macro, and true at the end of your macro, then any abort or M99 during the macro would leave the global as false indicating it didn't complete.
;some-macro.g set global.result = false if some_condition = true M99 ; cancel macro ;do a bunch of other stuff set global.result = true
You are of course not limited to true or false.
The global can be any format you wish. -
@owend Yes, that is the way as I am doing it now...but as I tried to state, there seems to be room for improvement
Btw: this solutions creates a lot of global variables - in different (nested) macros - that "exist" too long , use up precious memory...and are a non-esthetic way to trivially communicate a "result" from a called macro back to the caller! So far my first msg is more of a proposal for improved meta command handling than a mere question. OK, lets wait for RRF 3.5 -
@hlwerschner
I agree, a way to free globals would be good.
What you're suggesting is analogous to having procedures and functions.
"result" is already a reserved word but I can see the usefulness in what you propose.
Perhaps a new post in firmware wish list is in order. -
@hlwerschner I will add this to the work list for RRF 3.5.
-
@hlwerschner A worse problem with returning via a global value is reentrancy: suppose you have a macro which may be called by daemon.g, and also may be called by a macro not invoked by daemon.g. Unless you built a complex reentrancy system using more globals, the value you receive may not be from your own call to the macro.
-
@DonStauffer I've scheduled this for the 3.6 release. https://github.com/Duet3D/RepRapFirmware/issues/721
-
@dc42 That will be a great addition! Thanks for all your work.