I started running a long print and realized in the middle that I didn't want to execute one of the Filament changes programmed in the GCode (or similarly if one wants to skip a programmed pause).
It would be great have a PlugIn that allows you to delete/skip upcoming pauses from the Octoprint console before they happen.
I think of this as analogous to "Cancel Object" which allows you to cancel an object midprint.
I imagine it shouldn't be too hard as all you would need to do is to find and delete the apropriate G-codes from the Gcode file to skip any pre-programmed pauses or filament changes.
The PlugIn could list the upcoming filament changes or pauses with the ability to delete one or more of them by selecting the relevant upcoming changes.
As a bonus it would be helpful to print the estimated time to each upcoming pause/filament change alongside each item.
It doesn't solve the whole problem, but there is a 'Time To Filament' plugin, that is supposed to show the time to the next filament change. It could be a useful starting point in terms of reading the gcode file to find upcoming filament changes, and then I would imagine it would be 'relatively' simple to allow the user to skip them.
You can edit the gcode while printing - for example ssh into the Pi and edit the gcode with nano.
Press Ctrl + W and search for the line.
It only works as long as that line isn't used/read by OctoPrint.
Yes - I have the "Time-to-Filament" plugin and it is helpful -- though for some reason it is a bit flakey for me and doesn't always work. Like right now, my Prusa MK3S+ is printing an object with the LCD saying a filament change is coming in 1:18 hours but Octoprint doesn't show it. Other times it works but I haven't discovered a pattern.
That being said, my hope was that as you note, such logic that detects upcoming filament changes (or pauses) could also be used to allow the user to skip/delete them.
Which gcode do you edit?
The uploaded gcode stored and saved in ~/.octoprint/uploads or is there a cached value corresponding to the print-in-progress that one can safely edit.
It would be good if one didn't have to edit the original uploaded copy -- similar to how "Cancel Objects" presumably changes the in-process Gcode to remove code corresponding to the canceled object WITHOUT changing the original uploaded gcode.
So the gcode in gcode in ~/.octoprint/uploads is read in line-by-line as the print executes without buffering, allowing you to edit it in place?
What happens if there is a collision between you writing to the file and octoprint reading it?
It also would be nice to solve the complementary challenge -- i.e., ADDING a "Pause" or "Filament Change" mid-print. At least one that happens at a change in levels.
There are many times when I have resliced an STL and "forgotten" to add back a color change or pause to insert a magnet etc.
So it would be great if you could tell Octoprint "Add a pause before the start of line XXX" or "Add a filament change before the start of line YYY"
I can't tell you exactly how it's processed and I'm sure there's some buffering.
But yeah it's read line by line.
When you know you want to change something that is a few minutes in the future it shouldn't be a problem.
That's no feature or something and it isn't guaranteed to work, but it worked for me at least ten times.
No idea. I also don't think anybody has tested that case.
Yup. I also had that issue.
It's nice when your slicer adds context like which layer or starting with infill.
I like to put my pauses before the infill, so there's no chance I'm getting artifacts.
I don't think that's going to happen.
We would have to keep up to date with all kinds of slicer meta data flavors and if they change something it would break that feature in OctoPrint.
But it shouldn't be an issue to add those options with a plugin.
Just to be clear, I was talking about user-inserted pauses or filament changes in the slicer.
And my hope was that a plugin could override (i.e. cancel) such changes real-time based on user input at the time of print.
Conversely, it would be helpful if a user could insert real-time new, additional pauses or filament changes programeed at a user-specified level. Otherwise, if one forgets to add a pause/filament change or otherwise wants to add one while the object is printing, you have toi carefully follow the printer and be there at the precise moment when the printer starts the desired new level.
However, as the notice as the top says it might require reconnecting, which of course is not good while printing. Just not sure if this setting is real-time or does require a reconnect or not. In either case, a plugin could easily be made to ignore/drop commands as it processes through the gcode queue.
I could take a stab at it this weekend if no one else is interested.
this might be possible with the same gcode queuing process but is a bit more complicated. easiest would be by exact height, as you could watch for G1 Z moves, but z hop would introduce a problem. it might be possible to add your own flags in the slicer's on before layer change gcode settings to keep track of position and watch for those though. that might be a possible work around.
