Multi extrusion naming

[mahtDFR]

Me again! We really like this plugin.

Currently it only recognises an active extruder in the naming scheme. In the case of a multi extrusion job it would be good if it could include all the loaded material types.

I've attached a project file as an example. I've loaded Ultimaker Black ABS and Ultimaker Tough PLA. If I export using your plugin it will only recognise 'Ultimaker ABS' in the filename.

gcodefilenameformatmutiextrusion.zip

Cura can do up to 8 extruders, so there may be a situation where someone even has more than 2!

What do you think?

[rgomezjnr]

Hey Maht!

I'm glad the plugin is helping your team.

I loaded the project file. Using the default filename format

[base_name] [brand] [material] lw [line_width]mm lh [layer_height]mm if [infill_sparse_density]% ext1 [material_print_temperature]C bed [material_bed_temperature]C

produces the following gcode filename:

gcodefilenameformatmutiextrusion Ultimaker ABS lw 0.7000000000000001mm lh 0.2mm if 20% ext1 255C bed 90C.gcode

Is this what you are seeing as well? The plugin seems to only output the Extruder 1 settings. I'm not sure why the line width has so many digits.

What would be helpful here for multi-extruder printers? Something like this?

[base_name] [brand1] [material1] ext1 [material_print_temperature1]C [brand2] [material2] ext2 [material_print_temperature2]C

Or do you think the plugin should attempt to duplicate print settings for all extruders automatically? So the following:

[base_name] [brand] [material]

would produce

gcodefilenameformatmutiextrusion Ultimaker ABS Ultimaker PLA

Something I could use help on is automating testing for the plugin. I've written some unit tests, but I've only gotten them to run when all the Cura dependencies are commented out. I've been able to build the cura-build-environment docker image but I'm really not sure if that's useable for testing. I've attempted to build the Cura dependencies from source according to Running Cura from Source on Windows but I've had issues with the cmake/nmake commands using Visual Studio 2019.

Would you or your team be able to help me or point me in the right direction for testing? Maybe share some info on your testing process and setup for Cura?

[mahtDFR]

My feeling is that there should be some control over the output, so not automatic. So [material1] [material2] etc.

Separate issues: I got a lot of digits too, weird. maybe it's a rounding error.

testing - running from source on Windows is super hard, I can vouch for this. I'll put it to the devs and see if someone is able to give some clues.

[Ghostkeeper]

I'm not sure why the line width has so many digits.

This happens because the setting value is stored as a floating point value, which can't represent the 0.7 number exactly. You never see it in Cura because we round the numbers in the front-end to 3 decimals, and CuraEngine rounds it to micrometers. You could do the same.

As for the actual issue... I think most people would be using this plug-in to automatically archive their files with a reference to some of the most important settings they were using. For that they would ideally see the most significant extruder they adjusted the line width (or temperature, etc.) for. That is, the build extruder rather than the support extruder if they are different. If they are using dual-colour the line width is probably the same for both extruders 99% of the time. I'd say it's a pretty good bet to just display the first extruder that is used in the print (using ExtruderManager.getUsedExtruderStacks for example).

You could also approach this in the same way as how the start and end g-codes replace them. There you can use {line_width, 0} to get the line width specifically from the first extruder, or {line_width, 1} to get it from the second extruder. Just {line_width} would get it from the global stack. Arguably more powerful, but also more complex to use. You could combine my two suggestions as well to make [line_width] get the value from the first used extruder but still allow [line_width, 1] to specify exactly which extruder to use it for. (Do check that the extruder number is valid for the current printer though.)

[mahtDFR]

@Ghostkeeper thanks for the explanation. Just to elaborate a little, the application engineers requested this feature as they need info about both extruders in their filenames.

What @rgomezjnr needs assistance with is a separate issue within this issue (sorry!) I've quoted it below:

Something I could use help on is automating testing for the plugin. I've written some unit tests, but I've only gotten them to run when all the Cura dependencies are commented out. I've been able to build the cura-build-environment docker image but I'm really not sure if that's useable for testing. I've attempted to build the Cura dependencies from source according to Running Cura from Source on Windows but I've had issues with the cmake/nmake commands using Visual Studio 2019.

Would you or your team be able to help me or point me in the right direction for testing? Maybe share some info on your testing process and setup for Cura?

[rgomezjnr]

You never see it in Cura because we round the numbers in the front-end to 3 decimals, and CuraEngine rounds it to micrometers. You could do the same.

Thanks for the explanation @Ghostkeeper. I will round all the floating point values in a future update.

Thanks for the background info on dual extruder use. I'm not that familiar with them so that helps.

Thanks for the input guys. I think I should be able to handle both ways, specifying the extruder number and just the nominal setting. I'll come up with a release candidate and give it to you for testing.

[rgomezjnr]

Hey guys I just pushed 1.5.1-rc1 that adds multiple extruder support and fixes the rounding issue. Can you please test it and provide any feedback?

Do you have any information on the automated testing? Should I just create an issue in https://github.com/Ultimaker/cura-build-environment/issues or https://github.com/Ultimaker/Cura/issues?

[mahtDFR]

Thanks for updating me. I'll take a look today.

Do you have any information on the automated testing? Should I just create an issue in https://github.com/Ultimaker/cura-build-environment/issues or https://github.com/Ultimaker/Cura/issues?

It's better to keep each issue to a separate ticket, so please post about it there.

[rgomezjnr]

Hey Maht do you have any update from the application engineers? Does it work for them?

[Ghostkeeper]

I think @mahtDFR will not be able to help much any more. He's leaving Ultimaker at the end of the month, to go back to his home country.

I tried your release candidate with the following format (just edited the line_width2, the rest is default):

[base_name] [brand] [material] lw [line_width2]mm lh [layer_height]mm if [infill_sparse_density]% ext1 [material_print_temperature]C bed [material_bed_temperature]C

That worked. I don't know if it works for the application engineers that were using this, but I imagine it should. Maybe @ellecross knows more about what they were doing.

As I ran your source code I also found a couple of places where you're using variable is "" to check against an empty string, which gives a SyntaxWarning in Python. It won't behave as you'd expect. You should use variable == "" instead to check if a variable contains an empty string.

[rgomezjnr]

Thanks for the update @Ghostkeeper. @mahtDFR Thanks for your help on this project!

You should use variable == "" instead to check if a variable contains an empty string.

Yeah I'm checking if the string is empty. I think you're right, I'll update the code. Thanks for the code review!

[rgomezjnr]

Hello Ultimaker Team, @mahtDFR, @Ghostkeeper,

Just an FYI I created a separate version of the plugin, GFF+, which is now available in the Cura Marketplace. This one supports multi-extruder formatting as well as some other improvements. The project repo is Gcode Filename Format Plus. I'll be supporting this version going forward. Thanks!

Release notes

• Added multi-extruder support
• Added OctoPrint plugin support
• Added more format options
• Added rounding of all floating point numbers
• Removed Save Gcode button from GFF

[Ghostkeeper]

MahtDFR has left Ultimaker last year.

But yeah, nice! Sometimes it's nice to be able to start over in a new repository.

[rgomezjnr]

Thanks for the info @Ghostkeeper. Let me know if you or your team have any feedback on the plugin. Closing the issue now.