• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login

returning a "result value" with M99

Scheduled Pinned Locked Moved
Gcode meta commands
4
8
395
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • undefined
    hlwerschner
    last edited by 9 Apr 2022, 08:18

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

    undefined 1 Reply Last reply 10 Apr 2022, 09:38 Reply Quote 0
    • undefined
      OwenD
      last edited by 9 Apr 2022, 08:35

      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.

      undefined 1 Reply Last reply 9 Apr 2022, 13:18 Reply Quote 0
      • undefined
        hlwerschner @OwenD
        last edited by 9 Apr 2022, 13:18

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

        undefined undefined 2 Replies Last reply 9 Apr 2022, 21:46 Reply Quote 0
        • undefined
          OwenD @hlwerschner
          last edited by OwenD 4 Sept 2022, 21:47 9 Apr 2022, 21:46

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

          1 Reply Last reply Reply Quote 0
          • undefined
            dc42 administrators @hlwerschner
            last edited by 10 Apr 2022, 09:38

            @hlwerschner I will add this to the work list for RRF 3.5.

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            1 Reply Last reply Reply Quote 1
            • undefined
              DonStauffer @hlwerschner
              last edited by 3 Jun 2024, 20:30

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

              undefined 1 Reply Last reply 3 Jun 2024, 21:44 Reply Quote 0
              • undefined
                dc42 administrators @DonStauffer
                last edited by 3 Jun 2024, 21:44

                @DonStauffer I've scheduled this for the 3.6 release. https://github.com/Duet3D/RepRapFirmware/issues/721

                T3P3 created this issue 24 Apr 2023, 14:49 in Duet3D/RepRapFirmware

                open M99 return result value #721

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                undefined 1 Reply Last reply 3 Jun 2024, 22:02 Reply Quote 1
                • undefined
                  DonStauffer @dc42
                  last edited by 3 Jun 2024, 22:02

                  @dc42 That will be a great addition! Thanks for all your work.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Unless otherwise noted, all forum content is licensed under CC-BY-SA