Don't go by absolute level since as you point out sometimes there are z-hops
Detect new layer levels based on the comments that many (most?) standard slicers use to indicate a new layer. Presumably, Prusa/Cura/Bamboo use very similar notifictions
In case, a user has a non-standard slicder, allow the user to specify their own layer transition regexp to search for.
More generally, such a unique user-defined comment could also be added by the user to any G-code via a pre-processor for the use case where a user has a number of non-layer transition points where they may optionally want to make a run-time decision whether to pause or change the filament.
Allow the user to add optional pre/post pause or filament change G-code in case anything special needs to be done before/after a pause or filament change.
Many simple use cases:
1.Filament Change: I create or inherit G-code for a multi-color object but realize after starting print that I only want to print it in a single color and want to avoid having the print interrupted by a filament change I no longer want (this happened to me just yesterday which motivated this feature request -- I was running a test print of a multi-color object that I didn't want or need to do in multi-colors)
2. Pause: I have G-code that pauses to insert a magnet but after I start the printing, I decide that I don't need/want the magnet...
The converse use cases are similar
Filament change: I modify and re-slice an object but forget to insert filament (color) changes before starting the print and I don't want to cancel and restart over
Pause: I modify and re-slice an object but forget to insert the pause needed to insert a magnet or a ball bearing before starting the print and I don't want to cancel and restart over
Both use cases have happened to me more than once in my rush to hit print
Of course, if you never make mistakes or never change your mind mid-print then such a plugin may be useless for you
Unfortunately comments are not usable for processing in the gcode queue, but as I mentioned before adding a custom command in the layer change gcode settings of your slicer would be possible (at least in PrusaSlicer). Kind of how DisplayLayerProgress uses M117 INDICATOR- messages as described here.
slow day at work, so I took the liberty to start on this plugin. I think I have most of the underlying original request completed (ignoring embedded pause commands in the gcode file) and the UI for settings and the sidebar widget for managing adding pause positions. Just needs a little more work for actually adding positions from the sidebar.
Ok, that wasn't too bad. I think I have a working Proof of Concept, very minimal. It basically will allow you to skip configured pause command embedded in gcode (use the toggle button in sidebar) and dynamically inject a configured pause command at given heights.
In order for the injection to work you will have to make a slight modification to your slicer settings. On before layer change needs to add the @PAUSE_POSITION line to it with the token for [layer_z] (z height based) or [layer_num] (layer number based). Then when you add pauses in the sidebar you use the relevant number (ie 2.4 vs 12). The one quirk I found is that whole numbers should not include the .0 so if you want to pause at a layer height of 3mm you enter 3 and not 3.0.
Just released a minor update that automatically sorts the paused points in the sidebar list in descending order. In my mind that made more sense as it would be from the bottom up as the object was being printed. Also added a little logic to not allow adding duplicate pause points.
Realized GitHub has made getting install links much more difficult, so to install the plugin go into Plugin Manager > Get More and in the ...from URL field at the bottom copy/paste this and click install.
Thanks for the quick work here.
When you say "pauses", does this also take account of filament changes?
Is there any way to distinguish between pauses and filament changes?
Just curious is the reason you need to inject @PAUSE_POISTION [layer_z] because the comments are pre-stripped out so you have no access to the after layer change G-code that injects the comment `[layer_z]'?
For the settings page, wouldn't it make sense to allow multi-line injections (i.e., not just M600) in case you want to do something else before/after a pause.
Since a color change typically has additional G-code injected, it would be helpful to separate out inserting a pause vs. a color change so that one can have different stock code.
It might be nice to allow an option on-the-fly to insert any G-code you want (not just the defaults in the settings) -- Maybe you want to do something funky, maybe not even a pause but some other G-code sequence
Yeah, that was going to be a future addition at some point. I vaguely remember a method of giving multiple commands with a : separator. That might be a temporary stop gap if that does work with your firmware.
Will consider the best approach for this. Possibly instead of pulling default settings, those are removed and everything is configured when adding the position. Or in settings have the ability to add different types with their own multi-line command sequence and have a type assignment option when adding the pause position in the popup. Both options drastically complicate the settings and logic within the injection process though and not sure I want to do it.
If I were to do this I wouldn't have called it Pause Management and feel like this "nice to have" to be too far out of scope of the intended purpose of the plugin. However, if the comment from 2 gets implemented I probably would make it open ended for what command to send.
Hope you don't mind my suggestions -- just sharing ideas and of course up to you to decide what you like or don't like
Another suggestion, rather than ignoring all pauses, it would be great if together with the newly added @PAUSE_POSITION command, one could list all the pauses, togther with the associated layer levels (of course there could be more than one per level), then one could have a trash can with the ability to delete each one (or all of them using a master delete button).
Perhaps this is what you have already done, but if so, I don't see it in my instance...
Yeah, I was thinking about this option as well. I agree the idea of pre-populating the pause positions in the list based on the selected file would be a good idea. The hard bit here would be parsing the file properly to find those pause commands and then back-track to the last @PAUSE_POSITION. Might be possible with some detailed regex matching with groups.
Master delete button is definitely something I wanted to add. Wasn't sure if clearing the positions on print start, print finish, or removing them individually as they happened made the most sense. Thinking with the extraction from the file as described above, doing it on file select and removing them as they happen would be a logical flow.
@jneilliii I used the link you provided above to load the plugin.
Will the update manager still notify me of updates or will I need to check back manually and reload as needed?
new version 0.0.3 out with extraction of configured pause commands on file selection. still need to add the delete all button, and curious now if the toggle is even necessary if the embedded ones are getting extracted and added to the list automatically now.
I could imagine a delete all could be useful if you have a multi-filament file with tons of filament changes and you just want to do a single color. It could take a long time to delete each one individually, especially since in general I find the Octoprint WebUI slow -- even running on a dedicated Pi4 with 8GB.
