CuraEngine command line: use Cura profiles instead of "-s" options?

[erri 2]

Hi,

i'm working with Cura (2.3.1) under linux. I have created a custom UM2 machine profile and some material/quality profiles.

Slicing with the Cura GUI is going well.

Now i want to atomate things, i.e. i want to use CuraEngine (from a Makefile) to slice my STL files into gcode.

To do this i would have to use many "-s" commandline options to specify the non-default slicer options (a look into cura.log reveals that it is calling CuraEngine with about 330 "-s" options, for example).

Now the question is:

Is it possible to use the Cura(-GUI) generated profiles (.cfg files stored in HOME/.local/share/cura) instead of listing them one by one on the CuraEngine command line? It seems that there is no commandline option to specify Cura profiles :-(

Or is there some other way like generating a list of "-s" options from the Cura profiles?

[nallath 1,120]

The logs output them when a slice starts. You can just copy them from there.

[erri 2]

The logs output them when a slice starts. You can just copy them from there.

 

Of course i can copy it from cura.log... But i am looking for a more integrated/elegant way, something that is more 'single source'.

Problem is, for example, if i change the machine/profile in cura, i have to remember all places (scripts, Makefiles) where this profile is used (hardcoded settings) and have to update them by hand... This is duplicated and error-prone work.

I would like to avoid such hardcoded settings and instead reference the cura profiles at theese places.

[nallath 1,120]

We don't have that. The setting architecture is quite complex. Porting it to the engine would only increase the odds of it going wrong (as we'd be re-implementing a bunch of code in another language). As we don't even use it, i don't think it's likely that we're going to spend time on this. We have a lot more stuff that has higher priority.

[lormar98 0]

I’ve the same problem.

Any news about how is possible to use the Cura generated profiles (.cfg files) instead of listing them one by one on the CuraEngine command line with -s option?

[nallath 1,120]

Nope. We haven't put any time into this. This might change in the future, but I don't expect this to happen in the very near future. The next release (2.7) won't have any changes regarding this.

[erri 2]

Hi,

i have written a python program cura-engine-wrapper.py that reads the slicing parameters from Cura machine and quality/material profiles and calls CuraEngine with them to slice a model (stl file).

You can overwrite specific profile parameters on the command line and there are some additional use cases like listing available Cura containers/profiles or dumping the parameters of a given profile.

You can find it here: http://github.com/ErwinRieger/ddprint/tree/master/scripts.

More information here: http://ibrieger.de/cura-engine-wrapperpy-helper-to-call-curaengine-from-command-line.html.

[nallath 1,120]

Hi,

i have written a python program cura-engine-wrapper.py that reads the slicing parameters from Cura machine and quality/material profiles and calls CuraEngine with them to slice a model (stl file).

You can overwrite specific profile parameters on the command line and there are some additional use cases like listing available Cura containers/profiles or dumping the parameters of a given profile.

You can find it here: http://github.com/ErwinRieger/ddprint/tree/master/scripts.

More information here: http://ibrieger.de/cura-engine-wrapperpy-helper-to-call-curaengine-from-command-line.html.

 

Protip; use the CuraContainerRegistry. It does a bit more magic. If you ask the value from a stack that is returned there, it should also handle the resolve. Should be a simple as switching out the ContainerRegistry with the CuraContainerRegistry.

Also; Very nice work!

Edited July 26, 2017 by Guest

[erri 2]

@nallath: Thanks for the tip, i will look into this.

[erri 2]

Protip; use the CuraContainerRegistry. It does a bit more magic. If you ask the value from a stack that is returned there, it should also handle the resolve. Should be a simple as switching out the ContainerRegistry with the CuraContainerRegistry.

Updated the script, replaced ContainerRegistry with CuraContainerRegistry.

@@Nallath: The value for *infill_overlap* is not resolved/evaluated (neither by using ContainerRegistry nor by using CuraContainerRegistry):

infill_overlap = =10 if infill_sparse_density < 95 and infill_pattern != 'concentric' else 0

I think this code has to be evaluated somehow before it gets passed over to curaEnginge?

Any hints?