Duet runs pause.g prior to running trigger?

SneakyTiki

I've noticed some behavior I wasn't expecting based on the documentation, and was hoping someone could help clarify.
Using Duet Meastro 1.0
Firmware Version 2.02(RTOS) (2018-12-24b1)

I have setup a simple switch as a filament run-out sensor as such:
;Filament Run-out Sensor
M591 D0 P1 C4 S1 ; Define filament run-out sensor. Monitors E0, enabled active-high switch, connected to E1 (pin4), enable filament monitoring

;Define trigger event when filament runs out. T0 is Emergency stop, T1 is pause.g, T2-9 defined in trigger2-9.g
M581 E1 S0 C1 T2 ; Which endstop to monitor, trigger occurs on falling edge of signal, only trigger when printing from SD, run trigger 2

The trigger2.g file I created is as follows:
M400 ; Wait for current moves to finish before running

M83 ; relative extruder moves
G91 ; relative positioning
G1 E-10 Z10 F4800 ; retract 10mm of filament AND lift Z simultaneously. Might avoid some blobbing

M291 P"Ran Out of Filament" ;A friendly message

To keep it short, everything basically works, except I discovered that pause.g is executed before executing trigger2.g

My question is this: Is it normal and intended behavior for the Duet to execute pause.g before executing the defined trigger macro? Or did I do something wrong? If this behavior is normal, I would kindly request this to be documented appropriately to help others avoid issues. Based on the documentation I was under the impression that when I define T2 in the M581 command, trigger2.g would be the only thing executed.

Phaedrux

@SneakyTiki said in Duet runs pause.g prior to running trigger?:

Firmware Version 2.02

This is a quite old firmware version at this point. Unless you have an overriding reason to stick with it, might be a good idea to update to 2.05.1 and see if the behaviour is still present.

SneakyTiki

No, no special reason. Just prefer stability. It worked and did what I wanted, so didn't bother changing.

Updated firmware, now running 2.05.1 (and tested the new DWC interface. Will probably get used to it on desktop, but my mobile devices thank you :D)

Tested the behavior, pause.g is still executed before executing trigger2.g

deckingman

@SneakyTiki said in Duet runs pause.g prior to running trigger?:

..................My question is this: Is it normal and intended behavior for the Duet to execute pause.g before executing the defined trigger macro?................

No that isn't normal behaviour. At least it isn't the behaviour that I have ever noticed. T1 will execute pause.g but any "T" number>1 should only run the associated macro. I'm scratching my head for possible reasons...........Can you confirm that both pause.g and trigger2 both run when the switch changes state? Is the trigger macro in the macros directory? The only thing I can see that I do differently to you is that I use C0 so that the trigger will run any time, whereas you are using C1. There is nothing wrong with that but can you try using C0 just to see if the behaviour changes. That information might help to track down what's amiss.

dc42

Either use M591 to manage your filament monitor, or use a GP input pin and use M581. Not both.

SneakyTiki

@dc42 said in Duet runs pause.g prior to running trigger?:

Either use M591 to manage your filament monitor, or use a GP input pin and use M581. Not both.

Ahhh, that was my problem. Thanks for the clarification. The way I read the documentation, I thought that M591 just defined the switch (like an M574), and M581 defined the behavior. So if my understanding is correct, M591 is specific and pre-configured command for filament monitors which will always run pause.g when triggered, where as M581 is a general command for assigning a macro event to a switch input.

I think it would still be beneficial to note in the documentation of M591 that it runs pause.g on it's own. And while I don't have one, it leads to the question: what happens if you use M591 with a filament monitor which also keeps track of whether the filament is moving or not? Does it just run pause.g? Or is there a way to have it adjust extrusion multiplier to compensate for deviations in filament diameter and/or slipping?

@deckingman said in Duet runs pause.g prior to running trigger?:

Can you confirm that both pause.g and trigger2 both run when the switch changes state?

I confirmed this by including some beeping sounds at the start and end of both pause.g and my trigger2.g file. It was executing both, first pause, then trigger (which makes sense from the documentation)

@deckingman said in Duet runs pause.g prior to running trigger?:

Is the trigger macro in the macros directory?

No, it was just in my sys folder.

@deckingman said in Duet runs pause.g prior to running trigger?:

can you try using C0 just to see if the behaviour changes

I did not try this since dc42 explained where the issue was coming from. Based on my current understanding, the same thing would still happen.

Thank you all

dc42

It's on my work list to allow filament monitors configured using M591 to run a customised file instead of pause.g.