What would be brilliant would be to have a plugin that would allow you—during the print itself—to select and abort a single part out of several on the bed.
What happens often with a multi-part print for tall parts is that one might break loose from the bed or otherwise have problems. So that part is then no longer there each time the hotend comes around and it starts to make a mess of hot filament... which then can contaminate the other parts. You can come back to find that "one apple has spoiled the entire basket", in other words.
In the past and if it's almost finished, I'll physically hold the bad tower/cylinder part to collect its fair share of filament even though I know that this one is a ruined part. This will usually save the remaining parts.
A better solution would be to PAUSE and to select something in a plugin to abort a part through a selection process. After resuming, when that part comes around again for its turn, it gets no filament or a complete ignore of its related tool path code.
By the time it gets to GCode, the distinction between parts is completely lost. The best alternative I could think of would be to define a cube (or area on the bed) that the printer would ignore.
depending on how the file was sliced, this ranges from "tricky" to "99.99% impossible".
You'd have to totally rearrange all the numbers inside the gcode in some cases, not to mention figuring out how to compensate for the lack of extrusion in one area when it comes to another area. The gcode is going to tell the printer it should have extruded 10mm of filament by now, but since you've removed a section it's only extruded 1mm. So when it gets back around it'll over extrude like you wouldn't believe.
@b-morgan That's a novel approach: to make a bounding rectangle or circle and if that G0/G1 command includes an X/Y in that region then it's skipped.
@PythonAteMyPerlWould you have to compensate for extrusion? I would have thought that each toolpath code (G0/G1) would be a discreet unit of work. Certainly, you can't interrupt a single command. But you can programmatically ignore them if they've not been sent to the ramps board yet. Where is this compensation code that you refer to?
You would. Most slicers produce absolute coordinates on the E axis, meaning you'd have to re-calculate each and every line you send to the printer, compensate for any G92 E0s you might have jumped etc etc.
Considering the computational overhead that would produce and the fact this is usually running on a Pi - nope, this is most likely not going to work.
I'm looking at a file with six parts: three tall columns and three lids. The file contains exactly seven G92 E0 commands in it to zero the extrusion amount.
So you're saying that the next three commands like this:
You might be able to configure your slicer like this. But the default seems to be "everything absolute". Making leaving out things extremely computationally expensive.
So then, Cura would produce GCODE in the way I'm thinking it should work. And then a variety of post-processing could occur where you would like "to over-extrude here" and "under-extrude here", to play with bridging effects, etc.
Gina pointed me here from a github issue. I think a lot of being able to do this depends on what information you can get out of the slicer. Using Simplify3D, you can set each object to have its own process. This gives you a delimiter (in the form of a comment line) between objects that you can use to figure out which blocks of gcode OctoPrint should ignore. I did a small modification to comm.py to show that it was possible to make a list of ignored processes. S3D also resets extrusion length after each process switch, so that gets handled fine, but a G92 E0 would likely have to be injected if objects/processes were cancelled on the fly.
I'm used to having more control back when I was doing CNC work. You could stop the job at a certain point, tweak the z-offset slightly, rewind the queue a few lines and start it back up again. So you get used to interpreting G0/G1 commands in this sort of environment and even "fix" problems by jogging around and then driving on.
The difficulty here in this space is the extrusion audit that's going on. Since the printer's other motors are in absolute mode, so is the extruder. So that means that subsequent extrusions are offsets-from-that-original-zero-event rather than relative-from-last-extrusion.
The S3D's feature of zeroing the extruder before changing parts would help a whole lot in attempting to make this work.
Personally, if I had the line # in the file where the last command was run from ...then I think I could successfully/programmatically split the file into a job-two-of-two file and send this to the printer, having removed the offending part throughout all remaining layers. As long as S3D zeroes the extruder between parts, that would work out (as long as I toggle off G29 on the next startup).
Version two: I should write a post-processing program to do what S3D is doing, zeroing the extruder before changing parts. I'll at least be one step closer to something automated.
S3D and slic3r will let you set all extrusion to be relative. This is used for other post-processors (filaswitch is one). My tests just regexing for the '; process Process_Name' works well, if you are willing to use S3D and use separate processes.
I've sort of thought through the things that would need to be done to implement at this level, though I don't know that I have the skills to do a plugin. Here are some of things I was thinking:
Pull out all the processes during the analysis phase. This is basically just regexing for the line above and putting it into a list
Hook the plugin into getNext method in the communication thread to check if the block of gcode is in the ignore process list
Do all the nifty web stuff to put the process names from the analysis into a nice little pop-up or drop down so they could be selected and added to the ignore process list.
If you've made this far it is probably trivial to add in process tracking, so the user can see what process is currently being printed.
It would also be useful to add a feature for sequential printing that would just be something like "skip to next process". Should also be pretty trivial to add.
Yeah... if you're in relative extrusion mode this starts to look do-able. I've got Cura and although I've heard brilliant things about S3D, I probably won't switch to it until I've added the second extruder that's still in the box.
I'll consider writing this plugin but later when I've done one or two simpler ones.
In Cura 3.2.18, go to Settings, Configure Setting viability... Scroll down to the Special Modes section and check Relative Extrusion. Now it will appear on Right Side when Custom Print Setup is selected.
The tooltip says absolute mode before any Gcode script is output. Seems to work for me (i.e. scripts are absolute, switches back to relative mode after).
This is beginning to look easier to put together to me, at least if this you are using comment lines to separate the objects.
Since there will have to be pre-processing anyway, you can pull out the ranges of line numbers associated with each delimiter comment. Then you can just hook in to the queuing phase to see if the linenumber in the hook tag is within the range of a cancelled object.
The main thing I'm not sure of is how OctoPrint is handling comments line number, since it is stripping out all of the comments when processing lines to put them in the queue.
EDIT: Looks like will have to use the file position instead of line number.
Not a full plugin, just something to drop into the plugins folder to test out.
Its messy, but I've sliced four objects in S3D with process names P1, P2, P3, P4.
I'm replacing the process changes comments with something else so they can be parsed when queuing.
In this case I am just setting P2 as cancelled to test. Works great. The only issue I am seeing is that I lose a retraction. That could be injected with a setting if the user wanted that.
Very nice, I'll try that out. Here's an example of a problematic job in the past (which would have been nice to have opted out of printing the remaining part of one of them). There's just a point where you're hours into it and you'd like to get some good parts even if you can't have all of them. This ought to ultimately been awesome when we get something going on this. (Thanks.)
Here is my first attempt at putting together a plugin. Just the bare functionality for now. It only works with the Simplify3D process comments. It puts them in a table with a cancel button, and allows the user to skip over chunks of gcode during queuing. The javascript made it a struggle for me to get this far, but I'll keep adding to it as I get more familiar with octoprint plugins in general.
What I usually do in a case like this for my README.md file is to screencap it in action, upload that graphic to a GitHub issue called "Placeholder for README.md images" and then note the URL it provided.
I then copy/paste that URL reference in the issue into my README.md and now it has a nice graphic to show the user what the interface looks like before they download.
I haven't installed it yet and unfortunately I don't have S3D. But I'll take a look at what's going on, certainly.
There you go. I've been using an earlier/branded version of Cura but that's reason alone to upgrade/unbrand. Sweet.