Cancel individual objects on the build plate

[ChrisP]

@bot said in Cancel individual objects on the build plate:

Excellent post. Thanks for tagging me I enjoyed the read.

Thanks. Unfortunately it's drilled into me to be as complete as possible when documenting features or bugs, so I know I can sometime go on a bit. Glad it was of interest.

As for your skirt/brim problem with S3D. Let's not go too far catering to S3D's gcode. If they don't manage to get 5.0 out anytime soon, their company is as good as done. I'm very actively looking for ways to move away from S3D totally. We should demand slicers do things properly instead of bloating a codebase to cater to odd scenarios.

Indeed. I agree that catering too far for S3D's code (or any particular slicer) isn't the right way to go about producing the right output from an input that's fundamentally wrong. However, while like you, I'd love to move away from Simplify (probably to PrusaSlicer), unfortunately for what I use it for both at home and work there's still nothing that comes close to Simplify. Though I do agree that unless they get a new release out soon, they'll be dead.
edit: it also has to be said that there is already some specific parsing for PS and S3D labels etc, so why not add the functionality to identify skirt/brims and logically separate them from the process tag?

In terms of that last point, cancelling an object on the first few layers is something I brought up in one of these threads as something that would be useful. At the same time, I realize that most use cases would have the cancellation come much farther along into the print, where ignoring or catering to the skirt/brim may not be necessary. However, does the x/y extent calculation when a skirt/brim is present interfere with proper cancellation behaviour?

Yes. Everything works as expect otherwise. My main reason for bringing this point up was because I imagine this data will be key to any UI that is made to make object cancellation user friendly. Or automated object cancellation through in-process monitoring.
From my point of view, I was less interested in the aspect of cancelling a skirt or brim and more interested in ensuring the data that RRF generated was accurate

[bot]

@ChrisP I wasn't thinking about the UI implications! Definitely warranted to cater to another S3D quirk in that case. As you say, we already cater to many slicers' quirks. Even now, I'm spending a lot of time ensuring that the gcode icesl generates can emulate S3D for visualization purposes and compatibility with firmware which expects such formatting.

[dc42]

I've now modified the M486 command so that when it is used without parameters, it lists the objects that RRF knows about. There are new builds of RRF with this functionality at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

[NitroFreak]

Is it worth it to implement this? I think it is literally easier to make sure things stick to the bed than to label all the parts on the print bed individually, especially when they´re duplicates.

[deckingman]

@NitroFreak There are a lot of things that can go wrong with a print as well as poor bed adhesion. Is this feature worth implementing? I guess that's a decision for each individual user to make. One could say the same about a lot of features. For example, one could argue that it's much better to build a bed that is flat, level and stays that way than it is use to use mesh bed compensation. Personally, that's the approach that I take but there are many more users who prefer to use firmware to compensate for "deficiencies" in hardware. So my take on it is that it's a good thing the features exist even though they may not be for me.

[ChrisP]

@NitroFreak said in Cancel individual objects on the build plate:

Is it worth it to implement this? I think it is literally easier to make sure things stick to the bed than to label all the parts on the print bed individually, especially when they´re duplicates.

Yup, in an ideal situation this feature shouldn't be needed, and on a most hobbyist-size systems theres almost no excuse if you're printing "standard" materials.
Unfortunately if you're printing up to 1000 items in one hit, it only takes one part to fail (and as @deckingman mentioned, we're not necessarily rarely talking bed adhesion issues here) to potentially write off the whole lot. Similarly imagine a bed with just two parts using £200+ of material - I'd rather cancel one to save the other than scrap both. Printing with more exotic material can often increase the chance of failure - I'd have loved this feature back when I was printing PEEK!

@deckingman said in Cancel individual objects on the build plate:

For example, one could argue that it's much better to build a bed that is flat, level and stays that way than it is use to use mesh bed compensation. Personally, that's the approach that I take but there are many more users who prefer to use firmware to compensate for "deficiencies" in hardware.

Indeed. Interesting example - I've no doubt that probing and mesh compensation works well for those that use it, but in the years I've been printing I've never had a need for it (auto-levelling is the first thing I turn off on a new UM3)... I guess the exception is delta calibration.

[ChrisP]

@dc42 said in Cancel individual objects on the build plate:

I've now modified the M486 command so that when it is used without parameters, it lists the objects that RRF knows about. There are new builds of RRF with this functionality at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Thanks, this works well! One very very minor thing is that it seems to put an extra space at the beginning of each line from line 2 onwards...

[dc42]

@ChrisP, did you run M486 from DWC,.or some other way? There should be a leading space on every line, so that the lines still line up when there are 10 or more of them.

[ChrisP]

@dc42 Yes, I ran M486 from the console tab in DWC. I will try again now just to double check...

[ChrisP]

@dc42 From DWC...

It might also be useful to have M486 report what the current object is that's printing...

[dc42]

@ChrisP said in Cancel individual objects on the build plate:

It might also be useful to have M486 report what the current object is that's printing...

Good idea! It's already available in the object model.

EDIT: except that it might not always be entirely accurate, because the moves in the print queue lag the object tracking.

[ChrisP]

@dc42 said in Cancel individual objects on the build plate:

@ChrisP said in Cancel individual objects on the build plate:

It might also be useful to have M486 report what the current object is that's printing...

Good idea! It's already available in the object model.

EDIT: except that it might not always be entirely accurate, because the moves in the print queue lag the object tracking.

Presumably though, the error will only be during travel moves and the first loop of an object then? So it would only be an issue if you happened to get unlucky at the point you queried or if the layer times for objects were particularly small...?

What would eventually be nice to see is an Objects tab under the Status tab in DWC where the bed area is plotted using the the limit info from config, then bounding boxes of the objects are plotted over that with a list of all the known objects on the bed and the current one highlighted.... dreams of the future

[dc42]

@ChrisP said in Cancel individual objects on the build plate:

What would eventually be nice to see is an Objects tab under the Status tab in DWC where the bed area is plotted using the the limit info from config, then bounding boxes of the objects are plotted over that with a list of all the known objects on the bed and the current one highlighted.... dreams of the future

This is planned.

[PCR]

@dc42 any news? I had the possibility in RepetierServer to cancel a object. Was quite nice.

[dc42]

This was waiting for the plugin interface in DWC. That interface has been implemented in DWC 3.2beta1. Now the plugin for object cancellation just needs to be written.

[ppaukstelis]

Just wanted to add that as the person that originally developed the octoprint plugin and did the initial work for Marlin, I really appreciate the systematic way this has been approached in RRF and documented in this thread. Well done. Now, to "standardize" where to put those object labels relative to wipes/retractions....

[T3P3Tony]

@ppaukstelis thanks for the feedback. The model used for changing tools may also be useful here for slicer writers. i.e:

gcode that happens before the object starts to be printed on that layer,
gcode that happens after that layer of the object finishes being printed

Than can the be tagged with ";Pre-ObjectX" and ";Post-ObjectX"

Anything in between a "post-ObjectX and a "pre-ObjectY" is not object related (i.e its travel, or a tool change, or a prime etc).

would that work?

[ppaukstelis]

I was thinking more in terms of what a slicer considers to be an object. Right now PrusaSlicer/SuperSlicer already have "; stop printing objectX" tags that can be used for termination as you suggest. But as of right now post-object wipes are not considered part of the object, they come after the stop printing comments. This wastes time and movement. Cura uses NONMESH object tags which work fine. However, it defines all supports as NONMESH and not as parts of objects, so you can never cancel the supports along with the individual object.

[T3P3Tony]

@ppaukstelis ahh I see, just more granularity required in tagging really