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

    M574 can't disable pin

    Scheduled Pinned Locked Moved Solved
    Beta Firmware
    5
    17
    805
    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.
    • gloomyandyundefined
      gloomyandy @Leonard03
      last edited by

      @Leonard03 I think you should repost your files as they are now and describe exactly what the problem is currently and when it happens. I've been following this thread and I've lost track of what is working and what is not.

      Leonard03undefined 1 Reply Last reply Reply Quote 0
      • Leonard03undefined
        Leonard03 @gloomyandy
        last edited by Leonard03

        @gloomyandy Hello!

        I updated to drive the actual configuration of my printer.

        I'll try simplify it how much as I can:

        tpostX.g -> /loadToFinda.g -> /loadToBondtech.g -> /loadToNozzle.g this works
        tpostX.g -> /errorAction.g -> /loadToFinda.g -> /loadToBondtech.g -> /loadToNozzle.g this doesn't work.

        The problem seems to be in 0:/sys/MMU Control/loadToNozzle.g.
        If it is called from tpostn the filament sensing is activated ok
        if it is called via the "errorAction.g" i get this error

        Error: Pin 'duex.e2stop' is not free
        Error: G1: Failed to enable endstops
        

        wich cancels the print but looking in OM after that error, the filament sensor is enabled as it should

        AndyE3Dundefined 1 Reply Last reply Reply Quote 0
        • AndyE3Dundefined
          AndyE3D @Leonard03
          last edited by AndyE3D

          @Leonard03 said in M574 can't disable pin:

          tpostX.g -> /errorAction.g -> /loadToFinda.g -> /loadToBondtech.g -> /loadToNozzle.g

          Since you have a lot of nested macros, I think the actual control flow is more complex than you have shown here. Try adding an echo command to the start of each macro in the MMU Control folder to help find what file the error is actually in.

          This error Error: G1: Failed to enable endstops can only occur with a G1 H1/3/4 command which is not present in loadToNozzle.g, which implies (at least part of) the issue is in some other macro

          Can you send the full console output of the macro calls that: a) work, b) do not work

          Leonard03undefined 2 Replies Last reply Reply Quote 0
          • Leonard03undefined
            Leonard03 @AndyE3D
            last edited by

            @AndyE3D said in M574 can't disable pin:

            This error Error: G1: Failed to enable endstops can only occur with a G1 H1/3/4 command which is not present in loadToNozzle.g, which implies (at least part of) the issue is in some other macro

            I thought about this as well. I modified only the errorAction.g errorAction_debug.txt
            I opted for M118 because echo commands gets skipped (not showing in the console).

            On the other hand, for whatever reason I can't download the console as text but I copy it here
            Console.txt

            Screenshot (1287).png Screenshot (1288).png Screenshot (1289).png

            1 Reply Last reply Reply Quote 0
            • Leonard03undefined
              Leonard03 @AndyE3D
              last edited by

              @AndyE3D said in M574 can't disable pin:

              This error Error: G1: Failed to enable endstops can only occur with a G1 H1/3/4 command which is not present in loadToNozzle.g, which implies (at least part of) the issue is in some other macro

              That error must come from load or unload to finda. That are only macros that uses exp.e2stop followed by a G1 H4 command. But the strange thing is that those macros behave as they should even with that error in place. Maybe that error cannot show up until any macros are executed, but even then, everything works as it should except for that error wich cancels any print

              1 Reply Last reply Reply Quote 0
              • Leonard03undefined
                Leonard03
                last edited by

                No one..?

                1 Reply Last reply Reply Quote 0
                • Leonard03undefined
                  Leonard03
                  last edited by

                  Good morning everyone
                  Since I got almost no answer, especially from devs, I have a simple question:

                  This issue, being a software issue (I assume that I opted to try the beta firmwares) is there any chance that updating the endstops pins configurations between deeply nested macros to be solved before the first release candidate of RRF3.5 becomes available?

                  gloomyandyundefined dc42undefined 2 Replies Last reply Reply Quote 0
                  • gloomyandyundefined
                    gloomyandy @Leonard03
                    last edited by

                    @Leonard03 Unfortunately complex macros like this can become pretty much "write only code" (at least to anyone other than the author), so it is very hard for anyone else to follow exactly what is happening here. Looking at your current debug traces I suspect that the full execution path has still not been revealed with the addition of the trace code in the errorAction.g macro (remember that if there is a bug in RRF the code path may not be what you think it is). I suggest that what you should do is...

                    1. As mentioned above "Try adding an echo (or M118) command to the start of each macro in the MMU Control folder to help find what file the error is actually in."
                    2. Add additional M118 commands whenever you enable/disable the problem endstop
                    3. Add additional M118 commands whenever you make a G1 H4 command (or any other command that uses an endstop).
                      Hopefully this will reveal the full code path being followed and we can then narrow down what is going on.

                    I realise this is very tedious, but it is pretty much impossible for anyone else to try and reproduce the situation you have. For a developer to be able to fix a problem (if there is one) we really need to be able to reproduce the issue ideally with as simple an example as possible and one that does not require special hardware.

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

                      @Leonard03 please can you try to reduce the complexity of the macros to the minimum need to reproduce the fault. Then I will try to reproduce it.

                      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
                      • Leonard03undefined
                        Leonard03
                        last edited by

                        Good morning everyone!

                        First of all, I would like to apologize to you. This was not an issue with RRF but with my own code... Thank you all for your help and support!

                        Just in case, @gloomyandy and @AndyE3D you were right about M118 in every file in MMU Control. But I has no chance seeing something unusual until I used logging.
                        @dc42 I am sorry for tagging you here and wasting your time.. was my fault, not RRF's fault..

                        The problem was elsewhere, right at the beginning, in tpostn.g.
                        There, were three simple calls: load the filament in the MMU, then in the extruder and last in the nozzle. If during those macros any error raised, the tool change macro continued showing a dialog (M291). But, it can also call errorAction.g which by itself loads the filament all the way to the nozzle, but being called from a "while" loop in tpostn.g, after errorAction.g the while loop was trying to load it again to the MMU. The log confirmed that:

                        2023-08-02 12:02:28 [debug] Finish: loadToBondtech.g
                        2023-08-02 12:02:28 [debug] Begin: idlerMove.g
                        2023-08-02 12:02:28 [debug] Finish: idlerMove.g
                        2023-08-02 12:02:28 [debug] Begin: loadToNozzle.g
                        2023-08-02 12:02:28 [debug] Finish: loadToNozzle.g     < here the duex.e2stop is configured as a filament sensor
                        2023-08-02 12:02:28 [debug] Begin: loadToFinda.g     < here the duex.e2stop is used to load the filament in the MMU
                        2023-08-02 12:02:35 [warn] Error: Pin 'duex.e2stop' is not free
                        2023-08-02 12:02:35 [warn] Error: G1: Failed to enable endstops
                        2023-08-02 12:02:41 [info] Event logging stopped
                        

                        In tpostn.g adding a break statement to exit the wile loop solved this problem

                        Thank you again to all of you for your support! 😊

                        1 Reply Last reply Reply Quote 3
                        • Leonard03undefined Leonard03 has marked this topic as solved
                        • First post
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA