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

    Mutiple Motion Systems & Macro Conflicts in 3.5

    Scheduled Pinned Locked Moved Unsolved
    Beta Firmware
    6
    20
    801
    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.
    • adambxundefined
      adambx
      last edited by

      Hi @SumoSniper ,
      I'm facing similar issues, but with a more complex macro structure with submacros modifying and checking global variables. I haven't investigated too deeply but have been able to get around all issues so far by adding some M598's. First randomly at the start of every macro that is being called and at various points inside the macros. I settled on placing M598's after calls to macros that could modify a global variable that i will need later on and before i check/use a global variable that could have been modified by a macro.

      Due to time constraints i could not investigate too far or boil it down to test cases, but i figured it's because of the deferred queue. Now macros called from jobs behave just as theones being called when no job is running.

      I hope to have some time to read up more on this topic at some point. It would also help if the documentation had some examples of what could go wrong for people using only 1 motion system but trip over some problems with macros, meta commands and queueing etc.

      Hope my "advice" could help out 🙂
      Cheers

      dc42undefined 1 Reply Last reply Reply Quote 2
      • dc42undefined
        dc42 administrators @adambx
        last edited by dc42

        @SumoSniper @adambx I am currently reviewing how conditional GCode commands and multiple motion systems interact. Currently, global, set global and echo commands are only processed by the active file reader; but other commands including abort and the evaluation of conditions in if, elif and while commands is performed by both motion systems. I will change it to execute abort commands only from the active reader; however this will not solve the issue of using global variables in the evaluation of conditions.

        Meanwhile, as a workaround it should be sufficient to place the following at the start of each affected macro, to make the inactive file reader skip all of it:

        if state.thisInput != null & !state.thisInput.active
          M99
        

        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

        dc42undefined SumoSniperundefined 3 Replies Last reply Reply Quote 0
        • dc42undefined
          dc42 administrators @dc42
          last edited by

          PS - the firmware binaries at https://www.dropbox.com/scl/fo/p0136wx04h8xf6ejwdnn9/h?rlkey=efrfwyb6o5tqid11gustz3uvy&dl=0 now include the change to execute abort only from the active file stream.

          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 0
          • SumoSniperundefined
            SumoSniper @dc42
            last edited by

            @dc42 Excellent thanks for that, the workaround should do it for me, will test it out soon.

            No doubt picking what gets executed where is a bit of a pickle, similar to the challenges of refactoring code for multithreading.

            I wonder if you might not save yourself a bunch of headaches by putting in an optional parameter on M98 that selects the motion system / reader you want to run it on? Then you could have either a default behaviour or a reserved constant you could drop into that so that you can perpetuate macro execution within the same motion system.

            eg: A normal macro run is M98 P"foo.g" with optional "S" parameter where -1 is run on calling thread, 0 is run on ALL, 1+ is run on that motion system. Then default could be be -1 which would give the most consistent results for 99% of users.

            1 Reply Last reply Reply Quote 0
            • adambxundefined
              adambx
              last edited by

              Thanks a lot. Will try it out!

              1 Reply Last reply Reply Quote 0
              • SumoSniperundefined
                SumoSniper @dc42
                last edited by SumoSniper

                @dc42 I'm getting an error with this code:

                if state.thisInput != null & !state.thisInput.active
                   M99
                Error:  line 8 column 31: meta command: reached primitive type before end of selector string
                

                The position is pointing to the ! on the second selector which is a bit confusing...

                edit: I tried to diagnose more:

                28/02/2024, 12:03:16 pm 	echo state.thisInput != "null"
                Error:  at column 31: meta command: cannot convert operands to same type
                28/02/2024, 12:01:37 pm 	echo state.thisInput
                0
                28/02/2024, 12:01:22 pm 	echo state.thisInput != null
                true
                28/02/2024, 12:00:59 pm 	echo exists(state.thisInput)
                true
                

                But in the object model on DWC it is showing as =null

                Further edit: I put echos at the start of the relevant macro to see what was going on and the same outputs are happening - so state.thisInput exists and is returning 0 but not evaluating as null, so it can't find .active and fails out.

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

                  @SumoSniper please try this instead:

                  if !inputs[state.thisInput].active
                    M99
                  

                  state.thisInput should return 2 when executed by the primary File stream and 12 when executed by the secondary File stream. It should return 0 when executed from the http stream.

                  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

                  o_lampeundefined SumoSniperundefined 2 Replies Last reply Reply Quote 0
                  • o_lampeundefined
                    o_lampe @dc42
                    last edited by

                    @dc42 What would it return when I execute it from daemon.g or a macro? Are those http-calls, too?

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

                      @o_lampe it would return true. The only reason it shows as null in the object model browser is that the fetch of the object model by DWC is not made in the context of any input. If you run:

                      echo inputs[state.thisInput].active
                      

                      from the DWC command line then it will return true.

                      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 0
                      • SumoSniperundefined
                        SumoSniper @dc42
                        last edited by

                        @dc42 Thanks! That one has fixed it, macros functioning as expected now. Interested to hear where the MMS metacommand handling goes when you've decided on that!

                        Cheers!

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

                          @SumoSniper @adambx @NineMile @o_lampe I have put new firmware binaries at https://www.dropbox.com/scl/fo/3y4agkmfzfmqcifuecqo3/h?rlkey=j0kibs1tubm5dfj7o2vz1vbzj&dl=0. The main difference is that multiple file readers are now only used if your job file or start.g file uses the new M606 command to fork the file reader (see https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m606-fork-input-file-reader) . Therefore, unless you use that command, macros will only be executed by one reader, which should solve the problem.

                          If you do use M606 then the behaviour will be as it was previously from that point onwards, and you will need to ensure that any macros executed subsequently to that M606 command are suitable for execution by both file readers. For example, you can ensure that any global variables needed are set up before the M606 command executes. Please note, testing of the M606 command is still in progress.

                          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 2
                          • dwuk3dundefined dwuk3d referenced this topic
                          • First post
                            Last post
                          Unless otherwise noted, all forum content is licensed under CC-BY-SA