Ultimaker Cura Prefix

[Brulti 177]

A customizable prefix would be best IMO. Keep it short, a few letters, 3 to 5 max. It's enough to quickly identify which of the printers in a network is being used for this specific file.

[geert_2 557]

If automatic pre- or suffixes would be desirable for some people, maybe a *versatile system based on parameters* might be best?

 

Similar to the one used by IrfanView? But then of course adapted to 3D-printing instead of photos. In IrfanView you use the parameter "$N" as a placeholder for the original filename, and you can add your own text around it as you like. There are other placeholders for file size (in bytes), dimensions (in pixels), zoom factor, exif-data, file-date, Nikon or Canon camera specs, etc... See the screendumps with syntax below.

 

Personally, I would prefer no automatic pre- or suffix at all, since I may add different abbreviations for material (PLA, PET, NGEN,...), for high and low temps, high and low speed, high and low flows, upper part and lower part of a design, model-date, etc... It all depends on the situation. And the filenames have to fit in the 20-characters limitation of my UM2-display. So I can not use a fixed syntax.

 

Most people who could use a fixed syntax, will use a different one. So it has to be versatile.

 

Screendumps of IrfanView text syntax for: on-screen display of filenames, for batch-renaming, HTML-export, etc... (see red box):

 

 

 

[AbeFM 35]

 

Quote

On 5/31/2018 at 9:24 AM, gr5 said:

Followed by "N" for nozzle and first digit of nozzle size:

n1=0.15 or 0.1 nozzle

n1=1.0 or 1.5 nozzle (yes this is a repeat of the 0.1 - most people will not use both in their lifetime and if they do they probably remember which print will use the small and which will use the large

 

 

Really a bigger problem is material. Printing a TPU file with PVA in the nozzle would be a lot worse than printing a 0.2mm file with a 0.4mm nozzle.

 

I often put print temps in the file name (or material). I've done nozzles, but that's somewhat rare and won't result in as serious a problem as printing 50 degrees off.

 

 

On 5/31/2018 at 9:24 AM, gr5 said:

For my UM2/UM3 series printers I prefer a suffix as you don't get much of the filename visible.  The most important thing in the file name is the printer type (not the printer name) followed by nozzle size (when I go to print an older file I need to know what nozzle to install).

 

Prefix would be great if we could get this down to two characters:

 

At least make it fixed. I'd rather see 2 everywhere - a single letter can be too easy to confuse?, but frankly letting me pick my own identifier is WAY better.

 

----------------------------------------

 

I really like what geert_2 is getting at, but it's a lot more invovled than just letting using the printer name or a dedicated "append name". As a long term goal, it could and should be a lot more flexible (or have the printers be smart enough to read a header file and report the actual settings, ALL of them).... But in the mean time, just add a blank to printer definitions that says "prefix: ___" and let us fill that in.

Edited June 4, 2018 by AbeFM

[kmanstudios 1,120]

1 hour ago, AbeFM said:

But in the mean time, just add a blank to printer definitions that says "prefix: ___" and let us fill that in.

That is assuming that users want to get into printer defs. not everybody is that technically minded.

[drayson 75]

I would suggest to make te prefix/suffix setable in the printer settings. Everyone has it´s onwn needs - from no pre/suffix to a specific numbering/lettering. If it might be possible to set it in the printers settings - maybe with a max. of 3 digits - it could be easy self-configured and everybody is more happy than with a predefined one...

[AbeFM 35]

23 hours ago, kmanstudios said:

That is assuming that users want to get into printer defs. not everybody is that technically minded.

I've been too casual with my language. This is what I've been envisioning all along:

 

 

I have only written a few programs in my life, but I cannot see what is technically challenging about this, and it seems straightforward from a user perspective as well.

Edited June 5, 2018 by AbeFM

[kmanstudios 1,120]

11 hours ago, AbeFM said:

I've been too casual with my language. This is what I've been envisioning all along:

 

 

I have only written a few programs in my life, but I cannot see what is technically challenging about this, and it seems straightforward from a user perspective as well.

Gotcha now :) that makes good sense.

[Brulti 177]

I fully support that idea. And it's easy and simple even for the most casual user.

[jockspice 6]

I would like a suffix, rather than a prefix, and would like nozzle size and material being used. As I change nozzles and use different materials, it would be nice to know if I can just print something off with what is loaded in the machine.

At the moment I add these details manually, but it would be nice to be able to tailor it.

[Anders Olsson 136]

The current prefix that new Cura adds has never been of any use for me, I simply don't move gcodes between machines.

What I normally do though is adding the nozzle size (if not 0.4) and adding the plastic type if not PLA.
I would write "600um_ABS_Ultimakerrobot" for a 0.6 mm ABS print.

[kmanstudios 1,120]

Having seen the balance of points of view and desires, it would seem that something similar to what @AbeFM would be flexible enough to provide room for the various ideas.

 

Whether it be printer name or what, the two fields could be divided into simply "Prefix' and 'Suffix' allowing for naming as people desire. Although, I do think a limit on input characters would be helpful.

[Swissengineer 25]

For us as company we use SVN to all our projects so the creation date of file is lost.

I would suggest  the date as a prefix or maybe a suffix, I agree that to view on our UM3E the name it is difficult

[drayson 75]

Just as an Idea... I usually put some info on gcodes I'd like to save for later reuse directky in the gcode file - as notes. a bit annoying as it is time consuming, but relatively save when there is a ned for reprinting something.

Maybe there could be an additional text box for "further print information" which will directly written in the generated gcode...

[rebekah_harper 60]

hiya,

 

as I selected other here is what I'd like to see. 

 

a user defined prefix based on a user defined list.  

 

I create large multiple part models and I would like to be able to create a model specific prefix.  but I sell these parts It would make it easier when I am working on a project, to be able to have a list of prefixes I input and then select an active prefix. 

[SandervG 1,521]

Thanks for all your votes and feedback guys! I understand the Cura team received sufficient feedback and is taking all input into consideration. 

[ghostkeeper 105]

I think we have a big enough sample size. We'll discuss the results on Wednesday.

 

This was sort of a pilot to see how people would react to involvement in this way. The issue itself is pretty small (trust me, we're tackling bigger issues first really), but it's interesting to hear how people organise their g-code files.

 

We're hearing your feedback that it needs to be customisable and that it would be more useful to have a suffix instead. The suffix should be no problem (if people agree within the team). Customisable may be a bit too much detail for a preference but we'll discuss that Wednesday then. Thanks for participating in any case!

[AbeFM 35]

On 6/6/2018 at 11:57 PM, drayson said:

Just as an Idea... I usually put some info on gcodes I'd like to save for later reuse directky in the gcode file - as notes. a bit annoying as it is time consuming, but relatively save when there is a ned for reprinting something.

Maybe there could be an additional text box for "further print information" which will directly written in the generated gcode...

I was trying to say something like this - it's a bigger job. The printers really need to be aware of the header - and the header needs to have some sensible structure.

It's kinda at the printer level, no?

 

Suffix only makes sense when the __-fix is very long.

 

Most of my reason for wanting to customize it is to get the length down from 5 characters.

 

Lastly, I'd like to reiterate that the Material Choice is far and away the most important. I'd rather print with the wrong size nozzle than the wrong machine, and I'd rather print on the wrong machine than with the wrong material loaded. And I'll GLADLY debate anyone who feels otherwise. ?

Edited June 8, 2018 by AbeFM

[kmanstudios 1,120]

This would be my naming convention I use at home. It may be a bit long winded, but it is thorough. Typos and all.....

UM3E_SpaceCar-UInFolded_FullPlate_Flat_PLA-PLA-04mmNoz_01Lay.curaproject.3mf

 

 

[KickahaOta 14]

On 6/8/2018 at 8:58 AM, kmanstudios said:

This would be my naming convention I use at home. It may be a bit long winded, but it is thorough. Typos and all.....

UM3E_SpaceCar-UInFolded_FullPlate_Flat_PLA-PLA-04mmNoz_01Lay.curaproject.3mf

 

 

Feature request for next Ultimaker: Wider display. :)

[JCD 28]

My suggestion is

 

1) have a prefix which the user can configurate in a  parameter (Cura putting in the parameter a default_value like the ones it has now)

2) have a suffix which can be calculate by Cura (but may be changed by the user) following a user preference,

   - a constant number, including empty string as default value, given by the User

   - a version number which is increased by one each time the user is slicing

   - this suffix would be reinitialized each time the User is inserting a new file, the user having the ability to modify the number at the initialisation

 

So you have the ability to keep the same filename if you choose constant string as suffix, and also, automatically keep multiple files during tests for code/settings comparison without overwriting the former tests

Edited June 12, 2018 by JCD

[Dim3nsioneer 557]

On 6/8/2018 at 11:21 AM, ghostkeeper said:

I think we have a big enough sample size. We'll discuss the results on Wednesday.

 

This was sort of a pilot to see how people would react to involvement in this way. The issue itself is pretty small (trust me, we're tackling bigger issues first really), but it's interesting to hear how people organise their g-code files.

 

We're hearing your feedback that it needs to be customisable and that it would be more useful to have a suffix instead. The suffix should be no problem (if people agree within the team). Customisable may be a bit too much detail for a preference but we'll discuss that Wednesday then. Thanks for participating in any case!

 

May I ask what the result of the Wednesday discussion was?

[ghostkeeper 105]

Yeah, I was about to! Our final decision was to turn the current check box in the Preference window into a text box where you can fill in a formatting string, similar to media tagging software. It's not all that hard to use but covers everyone's use cases.

[kmanstudios 1,120]

2 hours ago, ghostkeeper said:

Yeah, I was about to! Our final decision was to turn the current check box in the Preference window into a text box where you can fill in a formatting string, similar to media tagging software. It's not all that hard to use but covers everyone's use cases.

Flexibility...so nice :) Thanks!!

[Brulti 177]

@ghostkeeper Is the box only for the formatting or can I just type something like 'Printer 01' and it will work as well?

[ghostkeeper 105]

3 minutes ago, Brulti said:

@ghostkeeper Is the box only for the formatting or can I just type something like 'Printer 01' and it will work as well?

We were imagining that you'd type something like: {printer_name}_{model_name}_{date} where {printer_name} gets replaced by the name that you gave the current printer, {model_name} gets replaced by the file name that you loaded and {date} gets replaced by the current date. If you were to type 'Printer 01' then it would always give the same name to the print job regardless of what you're slicing.