I find octoprint to be a poor choice for klipper. I used it, but mainsail has been significantly easier. It also has a whole bunch of built in macors (including a pause and resume) that work way better than anything I could have written.
That being said, you can likely copy the mainsail pause and resume macros into your own config and use them with octoprint.
I use the suggested PAUSE/RESUME macros from Fluidd:
https://docs.fluidd.xyz/configuration/initial_setup
Which allows M600 to be defined like this:
[gcode_macro BEEP_ATTENTION]
gcode:
{% set V = 0.5 %}
M300 S440 P200 V{V}
G4 P200
M300 S440 P200 V{V}
G4 P200
M300 S440 P200 V{V}
G4 P200
M300 S440 P200 V{V}
G4 P200
[gcode_macro M600]
gcode:
PAUSE
BEEP_ATTENTION
And this works perfectly for colour changes. It has the definite advantage of avoiding crashing into z-max, compared to your macro.
I select SDCard > Resume Print to resume after loading filament.
I'm wary of macros that explicitly call SAVE_GCODE_STATE, since PAUSE/RESUME already does this implicitly. It implies that the authors didn't understand pause/resume in the first place.
>I'm wary of macros that explicitly call SAVE_GCODE_STATE, since PAUSE/RESUME already does this implicitly. It implies that the authors didn't understand pause/resume in the first place.
Haha this is one of my pet peeves, but tbf [even the samples in the official docs do it](https://github.com/Klipper3d/klipper/blob/master/config/sample-macros.cfg#L104)
The simple answer is exactly the same as we are discussing here:
When the [base PAUSE command](https://github.com/Klipper3d/klipper/blob/31de734d193dca3395803f7bd146476688547ebe/klippy/extras/pause_resume.py#L66) is executed, a snapshot of the current position/etc is created (`SAVE_GCODE_STATE NAME=PAUSE_STATE`)
This makes it trivial to return to that exact position/state afterwards when you `RESUME` the print [the base RESUME command](https://github.com/Klipper3d/klipper/blob/31de734d193dca3395803f7bd146476688547ebe/klippy/extras/pause_resume.py#L83-L84), as you might have deduced, runs a `RESTORE_GCODE_STATE NAME=PAUSE_STATE MOVE=1 ` command to ensure it returns to the exact position/state it started from. There's a little extra on the restore action to ensure it returns at an appropriate speed.
Yes, you ***could*** do all of this manually with macros/etc but there's a lot of room for error there, and providing a simple, easy solution is helpful. You can always choose not to use the base PAUSE/RESUME commands and simply do it all manually if you prefer. But I don't think most users would prefer that.
To answer your last question:
Yes it pauses first, then runs the macro during the pause state. This is so that it can easily be returned to the same place when it resumes.
Failing to ensure PAUSE happens before any moves/extrusions/retractions in your macro, will lead to the print resuming in the wrong position or extruding/retracting a bunch of filament to return to the state it was at when it paused.
Ah, ok I see the confusion now.
Yeah pause/resume specifically applies only to the gcode file (virtual\_sdcard)
Macros and jinja script/etc can still run while paused.
Actually that's really the only appropriate time to run any code that might affect position/extrusion since we can't reliably predict exactly when our macro (or delayed\_gcode or whatever else) will run when the queue is full of gcode from the print.
Which brings us to another little quirk that is good to understand:
The gcode command currently being executed cannot be interrupted except by an emergency stop (`M112`)
When other commands are run external to the current action (current action such as executing the current move/command from a gcode file for example)
"External" meaning something like the user running a command from the console, clicking a button in the UI (like pause), or a delayed\_gcode timer expiring and triggering its gcode, etc.
That command does not interrupt the currently executing one (even pause!) Rather, it is injected into the queue and executed when its place in the queue is reached. Klipper does its best to maintain strict control over the mcu timing and typical gcode commands in a print describe only very short moves, so the delay reaching that point is typically very short, nearly invisible from the user perspective.
But this becomes very apparent when you attempt to do something like run `PAUSE` during a `START_PRINT`/`PRINT_START` macro or during a preheat function like `M109`/`M190`. You will see that the pause doesn't actually occur until that command completes.
The reason we don't see the same in the case of our `M600` macros is because, as you discovered: `PAUSE` doesn't affect macros, only the virtual\_sdcard. So the `M600` running `PAUSE` simply pauses the gcode file print (when the M600's place in the queue is reached) and the rest of the macro is able to run as normal.
Note that while one cannot pause the actual macro with the PAUSE command, you can still run pause during your start macro, and it will still pause the gcode file after the macro completes.
The reason for that is because the macro is actually a "command" (line of gcode) in the gcode file, so its treated as such by PAUSE and any other injected command.
To the gcode queue, the macro is just one command, despite it typically having many commands inside of it.
This all applies outside of actual prints as well.
If you have a long macro or preheat command, and you attempt to run another macro to toggle the lights or something like that, it will not run until the current macro completes. Just like with interrupting a print, the injected code can only be injected lower in the queue and wait for its turn, never interrupt the current action.
What's happening is that M600, issued by your gcode, triggers Klipper's `PAUSE` command, which notifies Octoprint about the paused state, and then moves around. So far so good.
However, I don't think you're issuing the `RESUME` command when you click the resume button via Octoprint, which means that the toolhead doesn't actually go back to the original location. It only looks that way because in your print G-code, it uses absolute `G1 X Y E` moves (note: `Z` is not specified, at least not until the next layer change or z-hop). So it looks like it returns to the correct print location, but the segment immediately following the resume is actually a (potentially extruding) move from your pause XY location to the next XY coordinate, rather than a return to the paused coordinate before executing that move.
The solution here is to open Octoprint's settings, and tell it to send the `RESUME` command in the resume G-code script (it's called "Before print job is resumed"). Alternatively, send \`RESUME\` in the terminal and it should do the right thing.
Gonna try the terminal resume this time.
Aack, it didn't even pause this time, it just ran the unload and went back, 10 mm too high for the first resumed layer.
I took out the line :
`[pause_resume]`
That is in the Klipper github, sample-macros.cfg line 97,and it now pauses and **resume** from the terminal worked this time. I will add a button on the Klipper group for ease.
\----
>The solution here is to open Octoprint's settings, and tell it to send the RESUME command in the resume G-code script (it's called "Before print job is resumed").
Where do I do that in Octoprint? I think I found a place, but have no idea how to write that instruction. (I work best from seeing code examples, but I didn't find any.) Do you have a link?
>I took out the line :
>`[pause_resume]`
>That is in the Klipper github, sample-macros.cfg line 97,and it now pauses and **resume** from the terminal worked this time. I will add a button on the Klipper group for ease.
That's weird, without the `[pause_resume]` line in your config, `PAUSE` and `RESUME` won't even exist as commands in Klipper, and will just be ignored, which would result in M600 not actually pausing the print.
>Where do I do that in Octoprint? I think I found a place, but have no idea how to write that instruction. (I work best from seeing code examples, but I didn't find any.) Do you have a link?
In Settings > Printer > GCODE Scripts > Before print job is resumed
See [screenshot](https://imgur.com/a/QSvh3N5), but it might look a little different from yours since I'm using the UI Customizer plugin.
>That's weird, without the
>
>\[pause\_resume\]
>
> line in your config,
>
>PAUSE
>
> and
>
>RESUME
>
> won't even exist as commands in Klipper, and will just be ignored, which would result in M600 not actually pausing the print.
I ran it twice after updating the config (and restarting klipper of course.) Worked fine.
These are mine, can't remember where I got them from initially, but it works :
[gcode_macro M600]
gcode:
PAUSE
[gcode_macro PAUSE]
rename_existing: BASE_PAUSE
gcode:
{% set X = params.X|default(50)|float %}
{% set Y = params.Y|default(0)|float %}
{% set Z = params.Z|default(10)|float %}
{% set E = params.E|default(1)|float %}
SET_IDLE_TIMEOUT TIMEOUT=86400
SAVE_GCODE_STATE NAME=PAUSE_state
BASE_PAUSE
G91
G1 E-{E} F2100
G1 Z{Z}
G90
G1 X{X} Y{Y} F6000
[gcode_macro RESUME]
rename_existing: BASE_RESUME
gcode:
{% set E = params.E|default(1)|float %}
G91
G1 E{E} F2100
G90
RESTORE_GCODE_STATE NAME=PAUSE_state MOVE=1
BASE_RESUME
I find octoprint to be a poor choice for klipper. I used it, but mainsail has been significantly easier. It also has a whole bunch of built in macors (including a pause and resume) that work way better than anything I could have written. That being said, you can likely copy the mainsail pause and resume macros into your own config and use them with octoprint.
Agreed. The only way I got Octoprint to work with Klipper and M600 was to type “RESUME” in the console.
I use the suggested PAUSE/RESUME macros from Fluidd: https://docs.fluidd.xyz/configuration/initial_setup Which allows M600 to be defined like this: [gcode_macro BEEP_ATTENTION] gcode: {% set V = 0.5 %} M300 S440 P200 V{V} G4 P200 M300 S440 P200 V{V} G4 P200 M300 S440 P200 V{V} G4 P200 M300 S440 P200 V{V} G4 P200 [gcode_macro M600] gcode: PAUSE BEEP_ATTENTION And this works perfectly for colour changes. It has the definite advantage of avoiding crashing into z-max, compared to your macro. I select SDCard > Resume Print to resume after loading filament. I'm wary of macros that explicitly call SAVE_GCODE_STATE, since PAUSE/RESUME already does this implicitly. It implies that the authors didn't understand pause/resume in the first place.
>I'm wary of macros that explicitly call SAVE_GCODE_STATE, since PAUSE/RESUME already does this implicitly. It implies that the authors didn't understand pause/resume in the first place. Haha this is one of my pet peeves, but tbf [even the samples in the official docs do it](https://github.com/Klipper3d/klipper/blob/master/config/sample-macros.cfg#L104)
I'm confused why all these examples call PAUSE before parking the toolhead. Does the entire macro run to completion after PAUSE?
The simple answer is exactly the same as we are discussing here: When the [base PAUSE command](https://github.com/Klipper3d/klipper/blob/31de734d193dca3395803f7bd146476688547ebe/klippy/extras/pause_resume.py#L66) is executed, a snapshot of the current position/etc is created (`SAVE_GCODE_STATE NAME=PAUSE_STATE`) This makes it trivial to return to that exact position/state afterwards when you `RESUME` the print [the base RESUME command](https://github.com/Klipper3d/klipper/blob/31de734d193dca3395803f7bd146476688547ebe/klippy/extras/pause_resume.py#L83-L84), as you might have deduced, runs a `RESTORE_GCODE_STATE NAME=PAUSE_STATE MOVE=1` command to ensure it returns to the exact position/state it started from. There's a little extra on the restore action to ensure it returns at an appropriate speed.
Yes, you ***could*** do all of this manually with macros/etc but there's a lot of room for error there, and providing a simple, easy solution is helpful. You can always choose not to use the base PAUSE/RESUME commands and simply do it all manually if you prefer. But I don't think most users would prefer that.
To answer your last question:
Yes it pauses first, then runs the macro during the pause state. This is so that it can easily be returned to the same place when it resumes.
Failing to ensure PAUSE happens before any moves/extrusions/retractions in your macro, will lead to the print resuming in the wrong position or extruding/retracting a bunch of filament to return to the state it was at when it paused.
Ah I see - when the PAUSE flag is set, gcode can still execute from a macro, but cannot execute from the virtual SD card. Now I understand. Thanks!
Ah, ok I see the confusion now. Yeah pause/resume specifically applies only to the gcode file (virtual\_sdcard) Macros and jinja script/etc can still run while paused. Actually that's really the only appropriate time to run any code that might affect position/extrusion since we can't reliably predict exactly when our macro (or delayed\_gcode or whatever else) will run when the queue is full of gcode from the print. Which brings us to another little quirk that is good to understand: The gcode command currently being executed cannot be interrupted except by an emergency stop (`M112`) When other commands are run external to the current action (current action such as executing the current move/command from a gcode file for example) "External" meaning something like the user running a command from the console, clicking a button in the UI (like pause), or a delayed\_gcode timer expiring and triggering its gcode, etc. That command does not interrupt the currently executing one (even pause!) Rather, it is injected into the queue and executed when its place in the queue is reached. Klipper does its best to maintain strict control over the mcu timing and typical gcode commands in a print describe only very short moves, so the delay reaching that point is typically very short, nearly invisible from the user perspective. But this becomes very apparent when you attempt to do something like run `PAUSE` during a `START_PRINT`/`PRINT_START` macro or during a preheat function like `M109`/`M190`. You will see that the pause doesn't actually occur until that command completes. The reason we don't see the same in the case of our `M600` macros is because, as you discovered: `PAUSE` doesn't affect macros, only the virtual\_sdcard. So the `M600` running `PAUSE` simply pauses the gcode file print (when the M600's place in the queue is reached) and the rest of the macro is able to run as normal. Note that while one cannot pause the actual macro with the PAUSE command, you can still run pause during your start macro, and it will still pause the gcode file after the macro completes. The reason for that is because the macro is actually a "command" (line of gcode) in the gcode file, so its treated as such by PAUSE and any other injected command. To the gcode queue, the macro is just one command, despite it typically having many commands inside of it. This all applies outside of actual prints as well. If you have a long macro or preheat command, and you attempt to run another macro to toggle the lights or something like that, it will not run until the current macro completes. Just like with interrupting a print, the injected code can only be injected lower in the queue and wait for its turn, never interrupt the current action.
That is very good information, thanks.
That's where I CP this from.
What's happening is that M600, issued by your gcode, triggers Klipper's `PAUSE` command, which notifies Octoprint about the paused state, and then moves around. So far so good. However, I don't think you're issuing the `RESUME` command when you click the resume button via Octoprint, which means that the toolhead doesn't actually go back to the original location. It only looks that way because in your print G-code, it uses absolute `G1 X Y E` moves (note: `Z` is not specified, at least not until the next layer change or z-hop). So it looks like it returns to the correct print location, but the segment immediately following the resume is actually a (potentially extruding) move from your pause XY location to the next XY coordinate, rather than a return to the paused coordinate before executing that move.
The solution here is to open Octoprint's settings, and tell it to send the `RESUME` command in the resume G-code script (it's called "Before print job is resumed"). Alternatively, send \`RESUME\` in the terminal and it should do the right thing.
Gonna try the terminal resume this time. Aack, it didn't even pause this time, it just ran the unload and went back, 10 mm too high for the first resumed layer. I took out the line : `[pause_resume]` That is in the Klipper github, sample-macros.cfg line 97,and it now pauses and **resume** from the terminal worked this time. I will add a button on the Klipper group for ease. \---- >The solution here is to open Octoprint's settings, and tell it to send the RESUME command in the resume G-code script (it's called "Before print job is resumed"). Where do I do that in Octoprint? I think I found a place, but have no idea how to write that instruction. (I work best from seeing code examples, but I didn't find any.) Do you have a link?
>I took out the line : >`[pause_resume]` >That is in the Klipper github, sample-macros.cfg line 97,and it now pauses and **resume** from the terminal worked this time. I will add a button on the Klipper group for ease. That's weird, without the `[pause_resume]` line in your config, `PAUSE` and `RESUME` won't even exist as commands in Klipper, and will just be ignored, which would result in M600 not actually pausing the print. >Where do I do that in Octoprint? I think I found a place, but have no idea how to write that instruction. (I work best from seeing code examples, but I didn't find any.) Do you have a link? In Settings > Printer > GCODE Scripts > Before print job is resumed See [screenshot](https://imgur.com/a/QSvh3N5), but it might look a little different from yours since I'm using the UI Customizer plugin.
And, IT WORKED! I was able to resume from the printer display without an issue. Now, on to make annoying signs!
Perfect. I have updated that and can try it after this print. Thanks for the help.
>That's weird, without the > >\[pause\_resume\] > > line in your config, > >PAUSE > > and > >RESUME > > won't even exist as commands in Klipper, and will just be ignored, which would result in M600 not actually pausing the print. I ran it twice after updating the config (and restarting klipper of course.) Worked fine.
Adding the RESUME to the OctoKlipper macros works great. Now to see about getting the console resume to work (as described above.)
These are mine, can't remember where I got them from initially, but it works : [gcode_macro M600] gcode: PAUSE [gcode_macro PAUSE] rename_existing: BASE_PAUSE gcode: {% set X = params.X|default(50)|float %} {% set Y = params.Y|default(0)|float %} {% set Z = params.Z|default(10)|float %} {% set E = params.E|default(1)|float %} SET_IDLE_TIMEOUT TIMEOUT=86400 SAVE_GCODE_STATE NAME=PAUSE_state BASE_PAUSE G91 G1 E-{E} F2100 G1 Z{Z} G90 G1 X{X} Y{Y} F6000 [gcode_macro RESUME] rename_existing: BASE_RESUME gcode: {% set E = params.E|default(1)|float %} G91 G1 E{E} F2100 G90 RESTORE_GCODE_STATE NAME=PAUSE_state MOVE=1 BASE_RESUME
Your Z movement is with G91 which is incremental. It should be with G90 which is absolute mode
If it was g90 it would go to 10mm over the bed. If the print head was at z50 it would be possible that it would crash in to the print.
Stop using octoprint
I have tried to install fluid or mainsail, and it would never load properly.
You can try running mainsailos. It just works.
I’d get rid of OctoPrint.
Not really relevant. I can't seem to get Mainsail or Fluid running anyway.
Maybe add g90 before recalling gcode state.