M582 in start.g to check for homed axes
-
@TC You might just be better off waiting for conditional gcode which DC42 is in the process of implementing. It might be easier in the long run.
-
Hm I am not that concerned about this homing thing. You are right the saved time is not much. But if this is not working, does it mean triggers are in General unreliable during a print?
-
@TC said in M582 in start.g to check for homed axes:
Hm I am not that concerned about this homing thing. You are right the saved time is not much. But if this is not working, does it mean triggers are in General unreliable during a print?
No. They generally work very well. I use them a lot.
-
@deckingman Can you give an example what you use them for? Just Single comands or mpre complex movements?
-
@TC said in M582 in start.g to check for homed axes:
@deckingman Can you give an example what you use them for? Just Single comands or mpre complex movements?
On Duet 2 I used to use these type of commands M581 E4 S1 T0 C0. Essentially just initiate an emergency stop when a normally open switch closed. On Duet 3 I'm using these type of commands M581 P"!0.io3.in" T2 C0 and M581 P"0.io3.in" T3 C0 which run macros when a set of contact on my UPS change state. I've found them both to work reliably and consistently. But as I mentioned before, I'm not familiar with using a start.g macro and I've never tried using M581 from within a macro.
-
Thinking about this some more, I suspect that the problem might be to do with running a trigger from within a macro(start.g) which in turn runs another macro. I'm not much of writer of code but I'm thinking along the lines that a macro essentially branches away from the main code, runs a series of commands, then returns back the main code. A trigger works by kind of interrupting the main code so essentially it too branches. So maybe a trigger that runs a macro from within a macro returns to the wrong point.
I'm not sure if I've explained that very well and I could be wide off the mark.
-
I've never tried using M581 from within a macro
works fine, to create or clear macros. but a newly created macro will not run if the chosen input is already asserted, an additional M582 is needed for that.
-
@bearer Thanks for the clarification.
-
I suspect the problem is that M581 triggers other then emergency stop run from their own separate GCode stream. This will execute concurrently with the original GCode streams. There is a locking mechanism to prevent two streams doing simultaneous movement.
I'm not sure there is a foolproof way of doing that you want, however you could try putting a G4 delay command after the M582 command, to give the trigger macro time to execute, or at least time to start executing.
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 -
@dc42 said in M582 in start.g to check for homed axes:
There is a locking mechanism to prevent two streams doing simultaneous movement.
is this on a per axis basis, or a single global lock?
-
@bearer said in M582 in start.g to check for homed axes:
@dc42 said in M582 in start.g to check for homed axes:
There is a locking mechanism to prevent two streams doing simultaneous movement.
is this on a per axis basis, or a single global lock?
A single global lock on the movement subsystem.
-
For those who might be interested
I found a solution: Right after the M582 a couple of M400 commands have to be included. It looks like one needs as many M400 as there are G1 commands in the trigger file. It is more a workaround than a clean solution, but works fine for me
