Prusaslicer: feature request: support for "Octoprint-Cancelobject"

[nicksears]

I have a very simple, but super simple request to add support for Octoprint's "cancel object" plugin.

I absolutely LOVE pronterface's ability to cancel a failing object by selecting it with a box. As I understand it, the program then ignores gcodes within the coordinates of the box. The plugin says it only supports gcode sliced with simplify3D because of the comments made by the program, unique to each object.

This uses a regular expression to look for " ; process (.*)" (excluding quotes)
Not sure how the "#Object" part works

This would be a REALLY powerful addition to slic3r and any host software using its gcode.

[paukstelis]

I wrote the plugin. If you check the readme, I've include some information on how to get this to work in Slic3r for sequential printing (doesn't work with all objects at once). There may be some other settings that need to be tweaked to handle missed retractions and extrusion resets, depending on your settings.

That being said, I have been staring at the Gcode.cpp/hpp files to see how much effort it would take to put object-specific comments at the start of each object. I don't know any C++, but I suspect one of these devs could do it. It seems like the object information is stored in LayersToPrint, which means the object name is accessible. It would require putting in a comment with the object name at the start of each of those when parsing into gcode.

EDIT: The #Object thing is there because octoprint purges all comment lines by default. The plugin converts the ; process XXXX line into #Object XXXX so that it doesn't get thrown out.

[nicksears]

Cool! Great idea and great work! I would think the more useful situation would be many parts printing at once (not sequential) but it is still very useful.

I know it's possible to ignore command within a bounding box(es) with pronterface and that's probably the easiest stopgap solution for octoprint.

I've attached an illustration (sorry for the crappy paint-shop) of the multi-item handling as well as pronterface's "excluder" option for comparison:

[paukstelis]

The plugin does work with multiple objects printed at once with S3D, though it does require multiple processes. Multi-item handling already works in this case:

The issue with Slic3r (and other slicers) is that it doesn't have the comments. The "Between Objects Gcode" lets you kind of get around that, but then it is only good for sequential prints.

The main limitation of the Pronterface function is that it just excludes an area in XY. If you had an object that had an overhang into the XY area you've exclude (say at a higher Z-height) you would lose those bits. The method I've implemented should have cleaner exclusions in that sense.

[vojtechkral]

@paukstelis

The #Object thing is there because octoprint purges all comment lines by default. The plugin converts the ; process XXXX line into #Object XXXX so that it doesn't get thrown out.

Does that mean the #Object XXXX line gets sent to the firmware and it is expected the firmware will ignore it?

[paukstelis]

No, the plugin strips the line from the queue. It is just used to demarcate the different objects in the gcode.

[vojtechkral]

@paukstelis Ok

[bdynamic]

+1 for this feature - would be great if the names which slic3r anyway knows about could be passed on in a compatible way to the gcode...

[paukstelis]

It would also be ideal if the slicer would reset extrusion distances at the start of each object. It is not an absolute requirement, but would decrease overhead for octoprint.

[nicksears]

agreed, but only for sequential printing. Would not work for simultaneous which is much more common and useful IMO.

[paukstelis]

It works fine for simultaneous. I just mean that there is a G92 E0 at the start of each object. This is the default for many slicers already. If this isn't there, the plugin will have to get the E position at the end of the cancelled object and inject a G92 EXXXX before it starts the next object. Its fairly trivial to do that, but it does mean you have to parse all the gcode of a cancelled object instead of just purging it from the queue.

[supermerill]

I've done it, the commit for cherry-picking: 59ea6431de6da65212d2e068c8cccb4827c978e9

Experimental build for testing (win32 only):
--removed--
You have to select "verbose g-code" in the output options.
When we have some return (or I tested it myself), i will submit a pull request.

You can discuss my implementation here https://github.com/paukstelis/Octoprint-Cancelobject/issues/8

[paukstelis]

@supermerill, did you ever get a pull request in for this?

[supermerill]

I can make one, but i have no answer on my other pull request....
So I wonder how to collaborate & communicate efficiently with the prusa team.

I made a fork, which is the prusa release with my changes: https://github.com/supermerill/Slic3r/releases
If you need a linux build and you can't compile it, i may make one.

[paukstelis]

Won't hurt to have the pull request there for them to look at. I'll try to get a linux version of your fork compiled myself. In the past I can get the program itself to compile, but ran into issues with the gui, something related to opengl libraries.

[bubnikv]

@supermerill

I can make one, but i have no answer on my other pull request....
So I wonder how to collaborate & communicate efficiently with the prusa team.

Let me try to explain our stance on pull requests in general:

We really appreciate your effort and the effort of other contributors. The contributions help us to improve the software at a faster pace than we would manage ourselves, and it bring us novel ideas. So far so good.

Now, we are a business, we have to support our customers. We need to provide them with regular releases of a stable software with possibly an uncluttered user interface (I know we have a room for improvements), and we need to provide our customers with a clear set of configuration parameters, so they do not get intimidated by their sheer number. Slic3r is quite bad from this respect as well, and look at Cura with all the experimental parameters that nobody ever used. Cura guys brag about the high number of parameters to tweak, while our goal is the opposite: To reduce the number of parameters by letting Slic3r to do the decisions.

If we get a non-trivial pull request, we need to first evaluate its benefits to the customer (well, every 3D printing enthusiast is a customer to us, but some of us are feeding our families). If the benefit is clear, then we will go forward and evaluate the implementation quality and stability of the code and possibly merge it with the master. But both will take time and our team has to plan this together with our other tasks, with the software / hardware features we need to release on time, with the tester work load etc.

If there is a feature, which does not bring clear benefits to the user, but complicates the UI and the parameter set, we will most likely not integrate it, at least not now. We may take the contribution as a basis for our further work and once the feature shows clear benefits to the user, we will integrate it.

Now to your pull requests:

We happily integrated your gyroid infill, thank you! This was a very concise pull request with a clear benefit and a low number of parameters (just the infill type). You also surely noticed, that we evaluated your code first and then we merged a simplified version of it with just the single line thickness infill. Indeed, we integrated, what we believe is most useful.

We reviewed your ironing, and it was not quite convincing, as it was very picky about a precise extruder calibration (and filament tolerances I suppose). You updated your pull request, and we (@lukasmatena) evaluated it recently, and the situation is very much the same. Your pull request is quite large, touching many places of the slicing pipeline and adding many parameters. To accept such a large pull request, it should bring clear benefits.

We may cherry pick one change of yours, that is adding a parameter for controlling the amount of anchoring of the infill. Currently Slic3r is quite conservative, which leads to long print times and excessive weight of an object #668.

We did not have time yet to evaluate your gap fill algorithm. We know, that the gap fill algorithm has a lot of room for improvements, and I have asked @lukasmatena to review your work.

As to all of your other changes or improvements, there may be some, which we have overlooked. It is easiest for us to review your proposals, if you could please create as concise as possible pull requests (one pull request per feature), we will then let our testers evaluate it (they do much more printing than I nowadays) from the point of usefulness, stability of the software, for the corner cases etc. If they give a green light at least from the point of usefulness, our developers will plan and review the code.

I understand, that it is demotivating for you to invest your time into producing a pull request, which may then never be accepted, or that you have no feedback of our plan regarding integration of your contribution. Please send me an e-mail to Vojtech.[email protected] , we may add you to our Slack communication platform, so we can work more closely.

[bubnikv]

@supermerill

I've done it, the commit for cherry-picking: 59ea643

This is tiny and concise enough to be reviewed and possibly integrated. I don't see any harm in general in producing some additional comment into the G-code.

Experimental build for testing (win32 only):

We have a build server, which could produce "feature builds", the name of the branch is then included into the version number. This is what we are giving to our internal testers before we merge a bigger contribution of our team members into the master. We could attach these "feature builds" to the pull requests, so the audience could test your contribution on other platforms. We can do that, but in general we cannot promise to merge your contribution into the master straight away (or ever).

Also from our point of view, it is a bit dangerous to give out builds based on some unstable state of the Slic3r development cycle, as these builds could leak out to the general audience and then ruin our reputation for the software quality and stability.

[supermerill]

Also from our point of view, it is a bit dangerous to give out builds based on some unstable state of the Slic3r development cycle, as these builds could leak out to the general audience and then ruin our reputation for the software quality and stability.

I created a release in my fork
With different logo color and name, to avoid being confused with you product. If I forgot to remove some copyright things (or if it's not different enough), please tell me.

i removed the link to my other "test release"

This is tiny and concise enough to be reviewed and possibly integrated. I don't see any harm in general in producing some additional comment into the G-code.

I will make a pull request. The commit is a bit old and we have made one little modification (adding the object name).

we may add you to our Slack communication platform, so we can work more closely.

thank you, i will try that.

[aligator]

any update on this?

[paukstelis]

It exists in the octoprint-cancelobject branch. It would be great to see it in an full release. There are a lot of "on-the-fly" options beyond just cancelling objects that could be possible if this was integrated.

[nicksears]

Until then I'm using exclude area (like what's enacted in pronterface) and it work well...

[supermerill]

For those who can't wait, you can try my experimental fork here: https://github.com/supermerill/Slic3r/releases/

It will help to iron out bugs if there are some.

[paukstelis]

I've been using a compiled version of the octoprint-cancelobject branch quite regularly (though I have had almost no failures on my Mk3!). Verbose gcode is a downside. I think moving to what was done with @supermerill PR for non-PE Slic3r (https://github.com/slic3r/Slic3r/pull/4470) that includes the option to provide just these comments is preferable.

[supermerill]

ok, it's easy to do. I will submit an other pr for that.

@bubnikv what do you think of an option? Also, you should link your "feature build".

[Popeyef5]

Any updates on when to expect this to be on the main release?

[mlyle]

+1 for this, also

[vojtechkral]

@Popeyef5 @mlyle Not likely in the next release, sorry about that. We have _a lot_ todo what with the Perl-to-C++ transition as well as SL1 support and other matters. I would still like to look into this at some point but like I said it's not likely to happen for the upcomming release.

[Popeyef5]

@vojtechkral Completely understandable. But just for clarification, is it on the agenda or is it soon™?

[bubnikv]

It is a relatively minor feature for Slic3r, so it will likely come soon,
but not this year. We did a lot of changes in Slic3r due to the Perl to C++
refactoring and due to a lot of UI and workflow changes, so we are too busy
with recovering the old features as of now.

On Mon, Dec 10, 2018 at 4:07 PM Popeyef5 [e-mail] wrote:

@vojtechkral https://github.com/vojtechkral Completely understandable.
But just for clarification, is it on the agenda or is it soon™?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Slic3r/issues/972#issuecomment-445847938, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFj5IxTH0FZpxWxmKjNI6ycE05CP76Lyks5u3niygaJpZM4Uji9z
.

[ddavidebor]

just wanted to let you know that repetier-server has this feature, similarly to pronterface.

[paukstelis]

just wanted to let you know that repetier-server has this feature, similarly to pronterface.

Its similar, but not actually the same thing. Those versions require you to make a shape around a region of the build plate. That might not always be practical or even possible. This plugin allows you to cleanly remove specific objects.

[tiboine]

@paukstelis where is the windows build that is referenced here?

[paukstelis]

@paukstelis where is the windows build that is referenced here?

https://github.com/supermerill/Slic3r/releases/

[bubnikv]

I am getting confused. I see we have cherry picked @supermerill 's commit to extend the verbose G-code with the comments to support the OctoPrint Cancel Object, is that right?
https://github.com/prusa3d/Slic3r/commit/59ea6431de6da65212d2e068c8cccb4827c978e9

Is there any code in @supermerill 's branch, which would enable these OctoPrint Cancel Object comments without the full verbose G-code mode?

[paukstelis]

I am getting confused. I see we have cherry picked @supermerill 's commit to extend the verbose G-code with the comments to support the OctoPrint Cancel Object, is that right?
59ea643

Yes. I believe that is correct.

Is there any code in @supermerill 's branch, which would enable these OctoPrint Cancel Object comments without the full verbose G-code mode?

@supermerill can likely answer that, but it was implemented in general Slic3r that way (https://github.com/slic3r/Slic3r/pull/4470)

EDIT: It looks like he has done that here: https://github.com/supermerill/Slic3r/commit/577b8444a441b3b10b5946908d3caa8c03979274

[supermerill]

Yes, the mainline slic3r added an option for this function, so I did the same thing. See my last comment.

[bubnikv]

Could you please point me to the commit where the feature is activated with
its own settings different from the G-code verbose mode? On slic3r#4470 is
the same as in current Slic3r PE, activates on verbose G-code.

On Wed, Jan 30, 2019 at 4:22 PM Merill [e-mail] wrote:

Yes, the mainline slic3r added an option for this function, so I did the
same thing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Slic3r/issues/972#issuecomment-458983798, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFj5I1w_b-1yDVhFiewCQVDz0ivmtPyWks5vIbjEgaJpZM4Uji9z
.

[supermerill]

it's supermerill@577b844

just creating a new parameter, and using it instead of verbose. Choose a good name & description, i will keep yours (i'm bad with english). ;-p

mainline commits: slic3r@75de746431dca545ac8bae041526ad1d9a180634 and slic3r@55a4e95b940a41e3f6f296a958746ed0b6089815

[bubnikv]

Adapted implementation by @supermerill, thanks a lot!

Implemented with c82d346c1a5b119aeb8c5176f832ccf19e7dbd9f
closing