M581 in RRF3 not triggering trigger2.g

[deckingman]

@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.

[Danal]

@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.

[deckingman]

@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.

[chas2706]

@deckingman

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.

[deckingman]

@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.

[deckingman]

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.

[chas2706]

@deckingman

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"
M999

The 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.

[A Former User]

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:)

[deckingman]

@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.

[chas2706]

@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.