Object name as placeholder variable

[Florin-Popescu]

Is your feature request related to a problem? Please describe. I sometimes have a project which requires different parts, say 3 input .stl files. I want to use the exact same profiles for all the parts and prepare 3 separate gcode files to print the 3 parts individually. To do this easily and to make sure I use the same profiles consistently for all the parts, I use a single project and add all 3 .stls to it. Then, for each part one by one I:

• set it as printable (the eye icon next to the STL file name)
• set all other parts as not printable
• press the arange button so that the part I want is centered on the build plate and the others are pushed outside, so will not be sliced
• slice and save the gcode
• rinse and repeat for the other parts

My issue is that I cannot easily set the name for each .gcode file to contain the name of the object (= name of .stl input file). All gcode files are named by default the same as the project name (the .3mf file). So I have to manually type in the name of each of the objects whenever I'm exporting a gcode file so that I will know later what each .gcode file contains.

There is the Output filename format setting which I expect would allow me to set a variable like {object_name} to be part of the file name, but such a variable doesn't exist as far as I can tell. I believe List of Placeholders is the most reliable list of such variables, but no variable fits what I am looking for.

Describe the solution you'd like Add a variable {object_name} or {printable_object_name} which would be available to be used in the Output filename format setting.

Describe how it would work That variable should be an array containing the names of the visible/printable objects (really, the names of the .stl files) arranged in the same order as they appear in the interface. Having it as an array would be useful when i.e. you want to print 2 of the 3 objects on the same platter. Either the input file extension would need to be omitted (so variable returns object instead of object.stl), or there could be 2 variables like we currently have input_filename & input_filename_base.

Describe alternatives you've considered I am not sure if the way I am using prusaslicer is the way it is intended. I would imagine having one separate project per object I want to print (or more broadly one project per platter) would solve my problem, but then I have to make sure that if I change a setting in my profiles, that I update all those project files to match. It's an extra step which adds a higher chance for human error.

Also in my head I have one "project" which requires 3 parts to work together. It would make sense from a UX point of view that I would have them all grouped into a single project file.

[stepikovo]

Hello @Florin-Popescu, this should be solved in 2.5.0, the filename should be based on the active object. Try creating a new project, import 2+ files and then leave only one visible and slice it.

[Florin-Popescu]

Hi,

Thanks for looking into this.

Just tested it today. It doesn't work on an existing project. Exporting still uses the .3mf file's name regardless of visible object, But when I create a new project, import 2+ files, slice only 1 and export, it works correctly, exporting with the visible object's name.

However, as soon as I save that new project it uses the project's .3mf file name again.

Is there a different variable for this? I'm using {input_filename_base}.

[DragonFinlay]

You're right, and unfortunately this is intended. Most users will want the 3MF project as the name for the exported g-code. I'll keep this open, maybe we can implement this as a setting in the future to make both user groups happy.

[bilbs84]

I think this would be a great idea, as when printing a project file with multiple objects, every export of an object will result in the project name, with no reference to the active part that is being printed. Or, for my lazy habit, I load an STL, print, then just clear the build plate, and print again, only it exports with the name of the first STL that I loaded. I could stop being lazy, but this would allow me to at least include the active object in the output name.

[carlosjln]

@bilbs84 I do the same thing, I have an 3MF file with all the settings needed for a specific type of product. I clear the plate and load another STL file and would like to export using the model filename instead of the project.

[Florin-Popescu]

You're right, and unfortunately this is intended. Most users will want the 3MF project as the name for the exported g-code. I'll keep this open, maybe we can implement this as a setting in the future to make both user groups happy.

Just a separate variable like {active_object_name} would work. Then no compatibility is broken with the other group.

[wikolii]

You're right, and unfortunately this is intended. Most users will want the 3MF project as the name for the exported g-code. I'll keep this open, maybe we can implement this as a setting in the future to make both user groups happy.

Just a separate variable like {active_object_name} would work. Then no compatibility is broken with the other group.

This is exactly what I'm looking for, I hope this gets implementes shortly. Thanks!

[armishmajerj]

Coming here to say I would like this too. Working on printing a project with the same settings throughout and remembering to re-name each time I export has been tedious. Too many times have I overwrote a previous export on accident so I started looking for a way to use the model name instead of the project name and stumbled on this.

[jkotowicz123]

+1

[kmclaughlin]

Just a separate variable like {active_object_name} would work. Then no compatibility is broken with the other group.

+1 to this. This would things a lot easier when dealing with multiple objects across multiple prints being sliced using the same settings saved in a project file. Like armishmajerj said, it is very tedious to keep renaming the exported gcode to add the object name

[jhyland87]

I like the idea of having an {active_object_name}. I was trying to set up a test print (in the Between Objects G-Code) where the object name would determine the setting. eg: z-offset tests, the object named z_offset__0_02 would set the z-offset to -0.02. I was initially just going to have it use {input_filename_base}, but I found that that only gives you the previously object that was completed. IMO - This isn't nearly as useful as knowing what the next or current object is.