Wishlist - cancel one of many

Well... that sucks.

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:

G1 F3000 X51.389 Y48.951 E0.01332
G1 X51.175 Y49.245 E0.02542
G1 X50.959 Y49.521 E0.03707

...are accumulative...? (ick) Alright, I think I get it.

I guess it would be too much to ask for a slicer to position X/Y with absolute coordinates and the extruder with relative positioning?

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.

This fork for relative extrusion would be the starting point, methinks.

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:

  1. Pull out all the processes during the analysis phase. This is basically just regexing for the line above and putting it into a list

  2. Hook the plugin into getNext method in the communication thread to check if the block of gcode is in the ignore process list

  3. 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.

  4. 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.

  5. 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).

1 Like

:clap: There you go. I've been using an earlier/branded version of Cura but that's reason alone to upgrade/unbrand. Sweet.

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.

1 Like

Thanks for the warning. I wasn't aware that they were filtered out.

Here is a proof-of-concept: https://pastebin.com/dvfuuna0

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.

2 Likes

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.

Cancel Object plugin sounds like what you need. I used it to cancel one object and it stopped printing and went onto the next and everything worked great, the first time. Since then I've run into an issue where it extrudes a blob at the beginning of the next object each layer but that could be a setting I've changed between the first use and the next one.

It's possible that this is an extrusion audit—related bug. You might want to see if the problem goes away if you use relative extrusion in your slicer. If that works, then you could consider adding an issue in the plugin author's repository.

Relative extrusion will fix this. For reasons I don't quite understand and haven't really looked into yet, tracking absolute extrusion moves isn't working. I'll try to get it fixed in the next version.

Perhaps six months ago I was coding post-processing scripts in a stand-alone Go CLI app. I actually made some successes in the area of replaying a layer under the harsh reality of absolute extrusion but then Cura came out with relative extrusion and I haven't thought twice about the subject since.

I just stole a little helper class from the filaswitch post-processor to track all extrusion moves and retracts. Seems to be work reasonably well now.