Delay when implementing automation macros

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