Open vfilby opened 1 year ago
Thinking about this a bit further and looking into the g-code for the timelapse macro, my guess is that the move is caused by {macro.pause}
. I am relatively new to Klipper so I don't know what the stock pause macro does, but I do see that both Mainsail and https://github.com/jschuh/klipper-macros wrap the pause.
When I can I'll run a test print and try using the macros with and without the wrapped macros.
I'm getting this too. I can see logic in there to detect overridden macros, but possibly mine is overridden twice and it's only going back one step.
It would be great to be able to choose our own pause and resume macros. It seems that using basic pause and resume is also preventing filament changes using the pause command, so I'd like to change it to a wait command instead. Using wait instead of pause and resume might be better in other ways too, like preventing KlipperScreen or other interfaces going into Pause state (Obico and Mobileraker, for instance, send a notification on every pause and resume by default).
+1 on the notifications being annoying. I had to go digging to turn them off because my phone was buzzing constantly.
I'm getting this too. I can see logic in there to detect overridden macros, but possibly mine is overridden twice and it's only going back one step.
It would be great to be able to choose our own pause and resume macros. It seems that using basic pause and resume is also preventing filament changes using the pause command, so I'd like to change it to a wait command instead. Using wait instead of pause and resume might be better in other ways too, like preventing KlipperScreen or other interfaces going into Pause state (Obico and Mobileraker, for instance, send a notification on every pause and resume by default).
You need a PAUSE, and we use the original pause state to not interfear with anything. The system uses a polling mechanism (delyed_gcode) to start the head after the picture is done. This time is not even constant from picture to picture nor from used printer to printer.
There is a flag that indicates that it is a Timelapse pause and the guys from Obico and mobilracker would only need to read that
I do have a PAUSE. However the time-lapse plugin is using the wrong version of it which includes park commands. I'd rather it use the built-in Klipper pause or be able to configure which pause macro to use.
There seams to be a bit of misunderstanding. When you overwrite a Klipper internal gcode like PAUSE you specify a
rename_existing
We parsing your config to find that https://github.com/mainsail-crew/moonraker-timelapse/blob/main/klipper_macro/timelapse.cfg#L184, the same is done for RESUME.
That insures that we using the Klipper original version and not any own macro you did.
I am not sure what you mean by wrong version, you can have only one overwrite for each macro. If you send a klippy.log I can analyze your config and explain it to you in more detail.
I'm having exactly the same problem - it's moving (slooooowwwwwllllyyyyyy) back right before returning to defined park position, pausing, taking snapshot, and then continuing. Klippy.log attached... klippy.log
Daft question - it wouldn't be case sensitive would it - and therefore it's not picking up [gcode_macro PAUSE] which is defined?
I setup timelapse + mainsail. The frame is triggered on layer change as expected but the tool head first moves to the rear-right position before moving to the custom position (or the preset one like rear-left). So on ever layer change, the tool head moves to rear left first, then to the custom position, then back and resumes printing.
Is this expected?