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

    M574 can't disable pin

    Scheduled Pinned Locked Moved Solved
    Beta Firmware
    5
    17
    718
    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.
    • Leonard03undefined
      Leonard03
      last edited by

      Hello everyone!

      I've encountered a strage problem with my setup wich I can't overcome
      Seems to be related with nasted macros and while loops.

      First of all, I am running a Duet 2 WiFi + DueX5, RRF 3.5.0-beta.4+ (from Dropbox), DWC 3.5.0-beta.4 and WiFi server 2.1beta4.

      The contents of my SD card / configuration can be seen here:
      https://drive.google.com/drive/folders/1OcTPiUw0RlYuLT-Skopb6It37nG4u9Io?usp=sharing

      At least at this moment, the issue I have has something to do with those two files:

      0:/sys/MMU Control/errorAction.g

      if global.errID = null
      	M99
      
      elif global.errID = "INSPECT_FINDA"
      	M98 P"0:/sys/MMU Control/idlerMove.g" S5
      	M226
      	M99
      
      elif global.errID = "FINDA_FILAMENT_STUCK"
      	G91
      	while iterations < 5
      		G1 V5 F1500
      		G1 V-5
      	M98 P"0:/sys/MMU Control/unloadToPTFE.g"
      	M98 P"0:/sys/MMU Control/getFindaStatus.g"
      	if global.statusFinda = 1
      		M226
      		M98 P"0:/sys/MMU Control/idlerMove.g" S5
      	M99
      
      elif global.errID = "FINDA_DIDNT_TRIGGER"
      	M98 P"0:/sys/MMU Control/idlerMove.g" S5
      	M226
      
      elif global.errID = "FSENSOR_DIDNT_TRIGGER"
      	while iterations < 2
      		M98 P"0:/sys/MMU Control/getBondtechStatus.g"
      		if global.statusBondtech = 0
      			M98 P"0:/sys/MMU Control/unloadToFinda.g"
      			M98 P"0:/sys/MMU Control/getFindaStatus.g"
      			if global.statusFinda = 0
      				M98 P"0:/sys/MMU Control/unloadToPTFE.g"
      				M98 P"0:/sys/MMU Control/getFindaStatus.g"
      				if global.statusFinda = 0
      					M98 P"0:/sys/MMU Control/loadToFinda.g"
      					if global.errID = null
      						M98 P"0:/sys/MMU Control/loadToBondtech.g"
      						if global.errID = null
      							M98 P"0:/sys/MMU Control/idlerMove.g" S5
      							M98 P"0:/sys/MMU Control/loadToNozzle.g"
      			else
      				M99
      
      	if global.errID = "FSENSOR_DIDNT_TRIGGER"
      		if global.useCutter = true
      			M98 P"0:/sys/MMU Control/unloadToFinda.g"
      			M98 P"0:/sys/MMU Control/getFindaStatus.g"
      			if global.statusFinda = 0
      				M400
      				M98 P"0:/sys/MMU Control/unloadToPTFE.g"
      				M98 P"0:/sys/MMU Control/getFindaStatus.g"
      				if global.statusFinda = 0
      					var selPos = {move.axes[3].machinePosition}
      					M98 P"0:/sys/MMU Control/filamentCut.g" S{state.currentTool}
      					if global.errID = null
      						G1 U{var.selPos} F1200
      						M98 P"0:/sys/MMU Control/loadToFinda.g"
      						if global.errID = null
      							M98 P"0:/sys/MMU Control/loadToBondtech.g"
      							if global.errID = null
      								M98 P"0:/sys/MMU Control/idlerMove.g" S5
      								M98 P"0:/sys/MMU Control/loadToNozzle.g"
      							else
      								M98 P"0:/sys/MMU Control/idlerMove.g" S5
      								set global.errID = "LOAD_TO_EXTRUDER_FAILED"
      		else
      			M98 P"0:/sys/MMU Control/idlerMove.g" S5
      			set global.errID = "LOAD_TO_EXTRUDER_FAILED"
      			M99
      
      elif global.errID = "FILAMENT_ALREADY_LOADED"
      	M98 P"0:/sys/MMU Control/idlerMove.g" S5
      
      elif global.errID = "UNLOAD_MANUALLY"
      	M98 P"0:/sys/MMU Control/idlerMove.g" S5
      	M116 H1
      	G1 E-100 F600
      
      elif global.errID = "UNKNOWN_ERROR"
      	M17 U V W
      	M98 P"0:/sys/MMU Control/idlerMove.g" S5
      

      and 0:/sys/MMU Control/loadToFinda.g

      M574 V0 P"^!duex.e2stop" S1						; set FINDA as endstop for V axis
      
      G91												; use relative positioning
      G92 V0
      G1 H4 V70 F2400									; push filament at high speed until FINDA triggers	50
      G1 V-15 F2400									; pull filament back
      G1 H4 V70 F1200									; push filament at high speed until FINDA triggers	50
      G1 V3 F1500										; 3
      
      if sensors.endstops[4].triggered				; check FINDA if filament in present
      	set global.errID = null						; no errors during loading
      	G92 V0										; reset V position
      else
      	set global.errID = "FINDA_DIDNT_TRIGGER"	; error during loading to FINDA
      
      M574 V0 P"nil"									; release FINDA pin
      

      If the macro "loadToFinda" is called from a toolchange macro (tpost0.g) the the command M574 V0 P"nil" is doing its job to free up the pin duex.e2stop and the filament is loading successfully to the nozzle, that endstop is activated as a filament sensor and the printing si continued.

      On the other hand, if the same macro {(0:/sys/MMU Control/loadToFinda.g) is called from the 0:/sys/MMU Control/errorAction.g (here it is called twice, but no matter where) after all macros are completed the print aborts with the error

      Error: Pin 'duex.e2stop' is not free
      Cancelled printing file 0:/gcodes/Extruder_1_0.2mm_PLA__1h3m.gcode, print time was 0h 17m
      Error: G1: Failed to enable endstops
      

      I've tried those workarounds:

      • Adding delays like G4 P250 in both macros, had no effect
      • Adding some M400 in both macros, had no effect
      • Tried calling M574 V0 P"nil" jus before activating that endstop as a filament monitor, also gad no effect
      • Adding an "echo" command at the end of the macro -> it showed up, so the macro is not exiting prematurely

      Also I tried rolling back to some earliet 3.5 beta versions, no luck neither.
      Is like the M574 __ P"nil" line is skipped/ignored.

      After aborting the print (after thar error) even sending M574 V0 P"nil" from the DWC console is ignored

      Any ideas are welcomed 😢

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

        @Leonard03 I'm having a look at your config to see if I can reproduce the issue.

        Something probably not related but worth fixing that I noticed scrolling through, is on line 146 in config.g, I think you have a typo G10 P3 X0 4Y0 Z0 ; set tool 3 axis offsets

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

          @Leonard03 Are you able to change the endstop pin from duex.e2stop to one on the Duet 2 and see if the issue is still present?

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

            @Leonard03 I think I have found your issue.

            I file sys\MMU Control\getBondtechStatus.g you have

            M574 V0 P"^!e0stop" S1 ; use bondtech sensor as V endstop
            
            if sensors.endstops[4].triggered
            	set global.statusBondtech = 1
            else
            	set global.statusBondtech = 0
            
            M574 U0 P"nil"         ; free up exp.e2stop pin
            

            I think the final line should be M574 V0 P"nil"

            In errorAction.g, getBondtechStatus.g is called before loadToFinda.g which is probably what is causing the Duet to get into the mess

            elif global.errID = "FSENSOR_DIDNT_TRIGGER"
            	while iterations < 2
            		M98 P"0:/sys/MMU Control/getBondtechStatus.g"
            		if global.statusBondtech = 0
            			M98 P"0:/sys/MMU Control/unloadToFinda.g"
            			M98 P"0:/sys/MMU Control/getFindaStatus.g"
            			if global.statusFinda = 0
            				M98 P"0:/sys/MMU Control/unloadToPTFE.g"
            				M98 P"0:/sys/MMU Control/getFindaStatus.g"
            				if global.statusFinda = 0
            					M98 P"0:/sys/MMU Control/loadToFinda.g"
            					if global.errID = null
            						M98 P"0:/sys/MMU Control/loadToBondtech.g"
            						if global.errID = null
            							M98 P"0:/sys/MMU Control/idlerMove.g" S5
            							M98 P"0:/sys/MMU Control/loadToNozzle.g"
            			else
            				M99
            

            Please let me know if it is a typo or intentional. And if my suggestion fixes the issue.

            1 Reply Last reply Reply Quote 0
            • jay_s_ukundefined
              jay_s_uk
              last edited by

              I think some of the issue stems from the use of V0 in the M574 command. This is setting that theres no endstop on that axis and maybe the firmware is having an issue undeclaring a pin from endstop for an axis that doesn't have one. I suspect it should really be V1 or V2 and that will fix the issue.

              Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

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

                Hello @AndyE3D @jay_s_uk and thank you for your time trying to help me 😊

                @AndyE3D said in M574 can't disable pin:

                I think the final line should be M574 V0 P"nil"

                Yes, you're right, it really didn't catch my attention. With this corrected, I took a step forward ! Thank you 😊

                @AndyE3D said in M574 can't disable pin:

                In errorAction.g, getBondtechStatus.g is called before loadToFinda.g which is probably what is causing the Duet to get into the mess

                Well, that's intentional, because I wanted to double check that the filament was not grabbed between the extruder gears before retracting it back to the MMU.

                @jay_s_uk said in M574 can't disable pin:

                I suspect it should really be V1 or V2 and that will fix the issue.

                I tried this as well, but made no difference, so I'll leave that line with the V1 parameter. Also, I removed from all the files the P"nil" section because seems that disabling an endstop is freeing up that pin and by contrast the command M574 V0 P"nil" does not free it (strange..).

                With that correction, I come to another (strange) issue.
                Now, the last thing that I don't know how to overcome is that the last line in the loadToNozzle.g wich should activate filament sensing gives this error:

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

                But it's strange because checking with OM plugin and inserting some echo commands just before trying to activate filament sensing, the duex.e2stop is not assigned anywhere but after that error, the filament sensing is enabled (wtf).
                Checked that with OM because adding a command like M591 D{state.currentTool} lets say in the errorAction.g leads to a "StuckInSpinLoop" crash

                This behavior takes place only when loadToNozzle.g is called from errorAction.g and sadly 'M400' or any G4 before it has no effect

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

                  @dc42 please.. can you have a look at my issue? Any idea is welcomed 😔

                  gloomyandyundefined 1 Reply Last reply Reply Quote 0
                  • 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