Solved M574 can't disable pin
-
@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 typoG10 P3 X0 4Y0 Z0 ; set tool 3 axis offsets
-
@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? -
@Leonard03 I think I have found your issue.
I file
sys\MMU Control\getBondtechStatus.g
you haveM574 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 beforeloadToFinda.g
which is probably what is causing the Duet to get into the messelif 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.
-
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 beV1
orV2
and that will fix the issue. -
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 theP"nil"
section because seems that disabling an endstop is freeing up that pin and by contrast the commandM574 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 theloadToNozzle.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 likeM591 D{state.currentTool}
lets say in the errorAction.g leads to a "StuckInSpinLoop" crashThis behavior takes place only when
loadToNozzle.g
is called fromerrorAction.g
and sadly 'M400' or anyG4
before it has no effect -
@dc42 please.. can you have a look at my issue? Any idea is welcomed
-
@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.
-
@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 errorError: 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
-
@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 aG1 H1/3/4
command which is not present inloadToNozzle.g
, which implies (at least part of) the issue is in some other macroCan you send the full console output of the macro calls that: a) work, b) do not work
-
@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 forM118
becauseecho
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 -
@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
-
No one..?
-
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?
-
@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...
- 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."
- Add additional M118 commands whenever you enable/disable the problem endstop
- 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.
-
@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.
-
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 callerrorAction.g
which by itself loads the filament all the way to the nozzle, but being called from a "while" loop intpostn.g
, aftererrorAction.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 problemThank you again to all of you for your support!
-