M581 in RRF3 not triggering trigger2.g
-
Ok here's what ive found:
In the M581 command I re-introduced the missing space between the "io2.in" and T2.
I operated the microswitch connected to io2.in and nothing happened.
I started a print and operated the microswitch and the trigger2.g executed.
It seems that the "C0" parameter to set the code to execute at anytime does not work and only operates when printing.
Or am I missing something? -
In the Gcode description for M581 it says:
M581 - RepRapFirmware 3
Parameters
P Specify one or more pin names
Tnn Logical trigger number to associate the endstop input(s) with, from zero up to a firmware-specific maximum
C Condition: whether to trigger at any time (C0, default) or only when printing a file from SD card (C1)The Condition for C indicates that when set to C0 will trigger at any time. This is not entirely true. It will trigger AFTER all current moves have finished.
So it is useless for my purpose. -
@chas2706 said in M581 in RRF3 not triggering trigger2.g:
It will trigger AFTER all current moves have finished.
i belive that could be a bug as it did behave like described in the documentation a while ago.
which versio are you using?
M115will show it. -
@bearer
Oh right maybe it is a bug.I'm on version 3.0RC2.
-
Hmmm... I'd expect the trigger to instantly start executing the trigger2.g... however, I'd expect the commands inside that file to enter the planner Q like anything else.
Phrased another way: If there is a long running single G-Code command executing at the moment of trigger, the first command (other than M112 estop, which is handled in a special way) inside the file cannot start until the current command finishes. It also might be true that a chain of short moves that have been treated by the planner as a connected chain, that (dynamic) group of commands might have to finish.
I have no hands on to current or past behaviors. The above is just what I'd expect from the way the planner works.
-
@Danal Last time I tested it on my gen 3 main board (about 2 months ago) it worked as expected/intended (i.e. practically instantly even when printing). The only thing I'm aware of is that M581 is not currently supported for gen 3 expansion boards but both the OP and I are using it with the main board.
@chas2706 Try removing the H2 parameter from the G1 move in the macro. As long as the printer has been homes, it isn't necessary and maybe H2 moves within a print get ignored (because the H2 parameter is usually only used when homing).
If that doesn't work, can you add M118 S"Trigger 2" to the start of your macro. Then check if you see that message when you trigger the macro during a print. I'm just wondering if the macro itself is being called but something is preventing the contents of the macro from running. Adding a message at the start of the macro will prove if it is being called or not.
-
@deckingman said in M581 in RRF3 not triggering trigger2.g:
it worked as expected/intended (i.e. practically instantly even when printing).
That would certainly be preferred! I'll keep reading as you guys experiment with this. Very interested.
-
@Danal said in M581 in RRF3 not triggering trigger2.g:
That would certainly be preferred! I'll keep reading as you guys experiment with this. Very interested.
I used it (M581) a lot on Duet 2. On Duet 3, I've only set up external triggers to disable the bed heater fault parameters when I get a power failure. Basically, I have a 24V UPS which cuts in and keeps the rest of the printer running but the bed is mains powered so it will go off and start to cool, eventually triggering a fault. The UPS has contacts which close when it switches to battery power and that's what I've hooked up to an io port to disable or enable bed heater fault detection depending on the status of the UPS. It works the instant that the contacts change state (I use 2 triggers). On Duet 2, I used micro switches as axes maxima switches and hooked these up such that M598 would stop motion if I did something stupid (like attempt to move beyond axis max before it had been homed). I'll do likewise on Duet 3 but I need DC to implement M581 on expansion boards first.
-
Thanks for your suggestions. I have just tried them.
With H2 removed and M118 S"Trigger2" added, I press home all and just after X and Y are homed I deliberately activate the microswitch connected to io2.in and immediately I see the Trigger2 message appear but the rest of the code is ignored until Z has finished homing.
-
@chas2706 That's probably to be expected. You need to use H2 before an axis has been homed, but once homed, then you don't.
-
You could use M564 H0 which will allow moves prior to homing. If you put that in your config.g file, then it will run when you boot. That's what I do then I never need to use H2. But the danger is that if you inadvertently send a G1 command prior to homing that moves outside the bed limits, it will try to make that move. So instead of "globally" using M564 H0, you could put it at the start of your trigger file, then put M564 H1 at the end. So your trigger file would like like:
M564 H0 ; allow moves prior to homing
G91 ; relative positioning
G1 Z5 F6000 ; lift Z relative to current position (H2 parameter removed).
G90 ; back to absolute positioning
M564 H1 ; disallow moves prior to homing. -
Thanks for your suggested code.
Unfortunately it still does not work.
My idea of use was to use a spare Z endstop microswitch as a safety device to stop movements if the Z probe failed when homing.
The microswitch is activated if Z goes too low.
The easy solution is to configure M581 to activate the emergency stop but the problem then is that I would have to manually move Z off the microswitch to enable a reset.I have a workaround though, thanks to your suggestions.
I have placed M564 H0 in my config.g and the contents of my trigger2 file is now:M118 S"Probe Failed"
M999The reset stops all movements and the state of the microswitch is not saved upon reset so I can then move Z clear using the DWC controls.
-
Could you see if there is a difference in when the code is executed if you use
M112(e-stop)?
Makes sure to try it when its okay to to do an e-stop, i.e. not mid print:) -
@chas2706 Yes, although M581 with a C0 should work at any time, I suspect that during a homing move where the firmware would normally be looking for an end stop to be triggered, would be a special case. Funnily enough, what you plan is one of the things that I used to do on Duet 2 and which I plan to do on Duet 3 when M581 for expansion boards gets implemented. The switch is still present and wired but I can't implement it yet. In my case, though I simply use M581 T0. In fact as well as a Z min backup in case of probe failure, I also have normally closed micro switches on all the axes maxima and wire them in series so that if any one of them breaks contact, it will initiate an emergency stop. It's useful when you use M564 H0 in config.g.
-
@deckingman
Thanks again for your help. I had the very same setup on my Duet 2 board which initiated an e-stop but I was sure that kept the software in an e-stop situation because the switch remained closed.
I don't know what is different but I just tried it again and it works. I can reset the board after the e-stop is initiated and with the switch still made.
So now I am using M581 T0 and it works a treat.
