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

    returning a "result value" with M99

    Scheduled Pinned Locked Moved
    Gcode meta commands
    4
    8
    408
    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.
    • hlwerschnerundefined
      hlwerschner
      last edited by

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

      dc42undefined 1 Reply Last reply Reply Quote 0
      • OwenDundefined
        OwenD
        last edited by

        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.

        hlwerschnerundefined 1 Reply Last reply Reply Quote 0
        • hlwerschnerundefined
          hlwerschner @OwenD
          last edited by

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

          OwenDundefined DonStaufferundefined 2 Replies Last reply Reply Quote 0
          • OwenDundefined
            OwenD @hlwerschner
            last edited by OwenD

            @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
            • dc42undefined
              dc42 administrators @hlwerschner
              last edited by

              @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
              • DonStaufferundefined
                DonStauffer @hlwerschner
                last edited by

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

                dc42undefined 1 Reply Last reply Reply Quote 0
                • dc42undefined
                  dc42 administrators @DonStauffer
                  last edited by

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

                  T3P3 created this issue 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

                  DonStaufferundefined 1 Reply Last reply Reply Quote 1
                  • DonStaufferundefined
                    DonStauffer @dc42
                    last edited by

                    @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