PrusaSlicer
PrusaSlicer copied to clipboard
prusa3d
Object name as placeholder variable
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.
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.
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}.
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.
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.
@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.
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.
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!
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.
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
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.
I'd suggest doing a list of object_names in the print, which can be indexed into using current_object_idx, which already exists.
That way you could also do stuff like appending object_names[0] to the filename. I'm not sure if lists work in filenames, but maybe it could even join multiple into one filename in that context.
The {active_object_name} could become an annoyance if there are several objects flagged as printable when the GCode is created because the name of the created file will then not reflect its real content.
What can be done is naming the GCode file by default with the part name when a single part is flagged as printable and use the project file name otherwise (as of currently). Ideally this behavior should be controllable with a setting such as "legacy export naming" or whatever similar.
My logic dictates that it should be named as the 1st flagged as printable object on the active bed (even if there are other object in the same bed flagged as printable but i would also like this other behavior a lot
The
{active_object_name}could become an annoyance if there are several objects flagged as printable when the GCode is created because the name of the created file will then not reflect its real content.What can be done is naming the GCode file by default with the part name when a single part is flagged as printable and use the project file name otherwise (as of currently). Ideally this behavior should be controllable with a setting such as "legacy export naming" or whatever similar.
Another take could be, if there are several objects flagged as printable use:
- the first object name
- the selected object name
- the project filename
- the project filename + object count
Wouldn't it just be easier to provide a prompt that would allow the user to change the value of {input_filename_base}? Having PrusaSlicer try to figure out which of the loaded STLs should be {input_filename_base} probably will not work. But it would be nice if there was a "File->Rename this Project" (or maybe Edit->Rename) menu that let you set it.
Or maybe, when you right-click on an object, the context menu includes an option "Use as project name", and the project will be renamed to whatever the STL for that object was called.
