Delay when implementing automation macros

[Marty3450]

I am wanting to use 2 macros on pause and resume to raise and stop my spindle (on pause) and start my spindle, delay 6 seconds and lower my spindle on resume. I’m having a heck of a time with a delay as soon as I enable these macros and also it not working consistently. Without the macros enabled, the pause button is very reliable, there is almost no delay but as soon as I enable the macros, there is a huge delay, so much so that it’s completely unreliable ( 4 to 10 seconds).
Below are the macros I have been trying:

On Pause:

M05 ; stop spindle

G91 ; Relative positioning

G0 Z25.4 ; Raise 25.4mm

G90 ;Absolute positioning

On Resume

M03 ; Restart spindle

G4 P2 Wait 2 seconds

G91 ; Relative positioning

G0 Z-25.4 ; Lower 25.4mm

G90 ; Absolute positioning

Aside from the delay which I find absolutely unacceptable, the 2 second pause on resume isn’t working and I have no confidence it is raising or lowering the correct amount (sometimes it goes right to the hard stop of Z which is over 50mm higher and it seems too low sometimes when it starts). I have never had these macros enabled when I was actually performing a cut, I just don’t trust it.
Anyone else having similar issues or can help?

[KGN]

Pause automation not being instant is not a bug, it’s the only way to send gcode before a hold state.

See my explanations in the following threads:

Settings -> Program Events -> Program Pause/Resume

This is by design and should (or will be) part of the documentation. Standard pause issues a feed hold which pauses movement immediately even if there are movements planned - those movements will happen once the hold is resumed. Feed hold prevents further g-code commands from being executed, which also means that gSender cannot inject any code. Pause events stop sending on the software side (sender hold) so no further lines are sent but that also means than any planned movements already in th…

Automations line pause

They do, but pause works a little differently. Since you can’t send non-realtime commands in a hold state, pause automations have the following effect: Stop sending on the sender side (workflow pause) Empty buffer (firmware handles all planned movements) On empty buffer, send pause automation - so the pause code will actually run Actually hold the firmware using ! The side effect of this is that pauses are no longer instant (as if we held instantly we’d have no way to send the pause automati…

gSender Edge - 1.5.0-Edge-8 - All New UI!

You can do this in Pause/Resume automations (in both Edge and main) with the caveat that pause events change pause behaviour (we can’t simply immediately feed hold because we need to be able to send the event code so it stops sending but completes the planning buffer vs holding immediately if there’s no event)