M582 in start.g to check for homed axes
-
I dont use start.g macro as well, so just blind guessing here, but looks like actual gcode file is executed before homeall.g is finished. Maybe because start.g calls trigger2.g and then actual gcode is executed, but because trigger.g calls homeall.g, they are executed same time. How to make gcode wait until homeall.g is finished? Not sure at all, maybe try to add M400 to trigger2.g after M98 command?
-
@fcwilt Well sometimes I allready did something with the printer and it is already homed and sometimes it is not. Additionaly it is a prove of concept
-
@TC said in M582 in start.g to check for homed axes:
@fcwilt Well sometimes I allready did something with the printer and it is already homed and sometimes it is not. Additionaly it is a prove of concept
I'm still a bit foggy on the concept.
Even if the printer is already homed the amount of time it takes to home it again is small compared to the amount of time most anything is going to take to print.
I print mostly functional parts and even the small ones take 30 minutes or more. Saving 30 seconds by skipping a redundant homing is not going to buy me much time.
Of course if you are just doing it for fun - that I can understand - fun is good.
Frederick
-
@aidar Yes that was my assumption. I already tried a M400, not helping at all.
@deckingman I used beep sounds to debug and it definitly reaches the homing file. But it is not executed immediately. That is why I already wrote, that commands are interfering with each other and asked for someone who knows how the priority of triggered macros is handled.
-
Not quite sure I get use case here.
If you want to avoid homing the printer between prints, just don't run homing sequence? (You'll need to keep the motors energized between prints to keep accurate positioning).
To avoid "unnecessary" homing at start up I did something similar. Create a trigger for each endstop, check the triggers manually and delete the triggers. trigger for each axis contain a G92 command to set the axis to zero or max travel. In having the axis set with G92 before config.g terminates will leave the printer in a homed state at power on; IF the axis triggers the limit switch at power on. However it won't be quite as accurate as just homing as the axis can move and still keep the end stop triggered, and the time savings won't be all that, I only used it for testing purposes.
-
@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
