Tuning - post processing at object change - once at a time

Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework

GNU Lesser General Public License v3.0

6.06k stars 2.06k forks source link

Tuning - post processing at object change - once at a time #8555

Open pflegezentrum opened 3 years ago

pflegezentrum commented 3 years ago

Hi,

While tweaking settings like, line width or flow, one has to sweep throug several paramters. It would be quite handy if one could change seetings by script after an object changes in "on at a time" mode.

Is this feature in, or could it be added. I gues this would be appriciated from a lot of makers out there!

BR Gary Vedukovic

Ghostkeeper commented 3 years ago

I'm not entirely sure what you mean. Sorry if language is a barrier.

You're finding that when using one-at-a-time mode, you need a different line width or a different flow rate? What do the post-processing script have to do with that? Which post-processing scripts are you talking about?

pflegezentrum commented 3 years ago

Post Processing

Changing all of them in the list ... ;) would be nice.

Ghostkeeper commented 3 years ago

You mean a checkbox that enables all of the checkboxes? What has that to do with one-at-a-time mode though?

pflegezentrum commented 3 years ago

Hi,

Within CURA you can set the print sequences to "one-at-a-time" (See screenshot).

One at a time

It prints seperate opbjects in a sequence. so object 1.. n (See drawing)

Objects - One at a time

For each Object 1 ..n wich is printed, it would be handy to change parameters. Like flow rate, temperature, line width. Thats the feature request. (See image with notes)

new option request

Ghostkeeper commented 3 years ago

Right, I think I understand. For each of these objects you'd want to change certain settings at a certain height using the ChangeAtZ script.

Post-processing scripts by nature work on the sliced file, as in, the g-code. Therefore the connection with objects in the build plate is lost. The post-processing scripts have no notion of which individual objects are on the build plate. The only way to achieve this would be to connect them via the comments in the g-code when it starts with a certain mesh. But those are not guaranteed to be unique. Meshes can have the same name.

Ghostkeeper commented 3 years ago

We've discussed this and decided to defer this issue, meaning that we realise it's a problem that could be improved but it doesn't get priority for now.

Reasons that factored into this discussion are:

ChangeAtZ is only a tiny fraction of users' prints, and ChangeAtZ + one-at-a-time moreso.
We fear that the interface to steer this would become very complex, with being able to select for which objects to make these changes.
The Post-Processing Scripts system is currently not designed to track settings for each object separately, add sets of settings when you add objects, or delete them when the objects are removed from the build plate. So this change would have a significant amount of work.
There is a workaround when you set the trigger to be at a layer number. The layer numbers keep counting on with multiple objects.

pflegezentrum commented 3 years ago

Hi,

Ok, and thanks for the info!

Please note:

ChangeAtZ is only a tiny fraction of users' prints, and ChangeAtZ + one-at-a-time moreso.? A new option "ChangeAtObject" would be a new selection -> so not ChangeAtZ

rspangit commented 9 months ago

There is a workaround when you set the trigger to be at a layer number. The layer numbers keep counting on with multiple objects.

This does not work in Cura 5.6.0. Layer count resets to 0 at the start of each object. If I have 2 copies of an object with 20 layers printed one at a time, ChangeAtZ at layer 19 works (last layer of the first print). ChangeAtZ at layer 20 or 21 does not insert a change at all.