Curaengine: Material Feedrate differs CLI/UI Slicing

[dombmann]

Hello everyone,
while slicing with the CLI CuraEngine I noticed a difference in the material Feedrates (EX.X Codes in the GCode File) compared to the GCode generated by the Frontend Cura (the UI version).
I compared Testprints and the corresponding GCodes

Application Version
Cura 4.4.

Platform
Windows 10

Steps to Reproduce
Slice a .stl file using Cura UI to generate CGode
Compare this GCode to GCode generated when slicing the same file with same settings (extracted from the extruderstack) via CLI CuraEngine

Actual Results
Extruder Feedrates are not equal
Using Cura Front End
G1 F1800 X94.502 Y81.213 E0.01516
vs.
CuraEngine from command line
G1 F1800 X104.502 Y91.213 E0.00572

Expected results
EX.XX should be equal

Additional Information
Dont worry about the difference in X and Y Coordinates
Throughout the entire GCode File the E Commands seem to be off by a factor of ~2.6522
Slicing via commandline invokes the fdmprinter.def.json overwriting this with the current extruderstack (-s extrudersetting="value").

Glad to hear from you.
Greetings,
Dominik

[nallath]

This is probably caused by having different values. Have you checked the logs of the frontend to see what settings it's sending to the engine (they are logged there) and use those exact values with the CLI?

[dombmann]

Well, I am taking all the settings from the getActiveExtruderStack() function.
Those are then piped as -s parameters to the CLI, so the should be the same.
keys = CuraApplication.getExtruderManager().getActiveExtruderStack().getAllKeys()
for i in keys: Logger.log("d", "%s : %s" , i , CuraApplication.getExtruderManager().getActiveExtruderStack().getProperty(i, "value"))

Im still new to Cura so please can you elaborate what settings you suggest me to take a look at?

[nallath]

Because we as developers are lazy, we already added what you want to the logs. When you start a slice via the interface, Cura will print all the settings it sends to the engine formatted in such a way that you can copy them and give them to the CLI.

[dombmann]

Okay, thank you that was very helpfull for the start.
All (five) parameters use the same values
machine_max_feedrate_z
machine_max_feedrate_e
machine_max_feedrate_x
machine_max_feedrate_y
machine_minimum_feedrate
Are there any other paramters responsible for setting the feedrate ? (The EX.XX Commands in GCode)

Edit: The _backend log uses ~400 more parameters than I can get via the Extruderstack. What is the recommended way to acces those ? Copy Paste via the Cura log file is not possible for my use case.

[nallath]

You can have a look at what the StartSliceJob (https://github.com/Ultimaker/Cura/blob/master/plugins/CuraEngineBackend/StartSliceJob.py) does.
Also; check the wiki of this project, there is some info about the setting & profile system there.

[Ghostkeeper]

Apart from the extruder stack, there are also setting overrides on the global stack, namely the settings that are not specific to a certain extruder (like build plate temperature). Those could still be missing if you're just looking at the extruder stack. This could change for instance the layer height, which is a global setting and influences your E values.

[dombmann]

I will give it a try, but it seems using the CLI is limited by the ammount of -s param='value'.
Can someone confirm this suspicion ?

EDIT:
Microsoft says: the maximum length of the string that you can use at the command prompt is 8191 characters - so I guess this is the more likely reason why my scripts won´t execute.

[Ghostkeeper]

Yeah at some point you're going to have to resort calling the script from a different language than MS Bash. You can still call it from Python with longer command line arguments, for instance.

[dombmann]

Im experimenting on that atm. Im trying to replicate the procedure that happens after the User hits the "Slice" Button in the "Prepare Stage", by calling the forceSlice https://github.com/Ultimaker/Cura/blob/b03f666bf527c4cfcf452bb96434126f9800b8d9/plugins/CuraEngineBackend/CuraEngineBackend.py#L231 function. Is that what you suggest Ghostkeeper , or am I making things much more complicated than necessary by that ?

EDIT: Calling CuraEngine from within Python via Subprocess works fine. I narrowed down the differences in the Parameter Sets (BackendLog and Log of the Extruderstack).
Why does the CuraEngine call so many duplicated -s Parameters although the value is the same ?
Is there more to the Parameter than just their value ?

[Ghostkeeper]

If you're going to emulate what's happening with the slice button in Cura you're making it needlessly complicated, most likely. That button is going to:

1. Check all settings for errors.
2. Check the build plate for errors.
3. Gather up the data from the build plate, which models need to be sliced.
4. Replace tokens in the start and end g-code.
5. Assume that CuraEngine is started and listening to a port (via the connect command line option of CuraEngine).
6. Create a Protobuf message that packages the models with applied transformations and all of the settings (global, per-extruder and per-model), and send it over to CuraEngine via a local socket.
7. Wait for a response in the form of g-code and layer view data.

Most likely you'll want to start with just using the slice command which directly loads and slices a file.

The engine needs a -s parameter for all global setting overrides, as well as one for all extruder overrides. Cura's front-end just puts all flattened settings in the debug message in the log there, so one for global and one for each extruder. That's not actually how it sends the settings over though. That happens with the aforementioned Protobuf message.

[dombmann]

Question now also asked in https://community.ultimaker.com/topic/31546-feedrates-cliui-differ/
Im still struggling to understand what further settings have an impact on the feedrate and how I can acces those to send to the CLI.
Edit:
Im not sure if that information is helpfull, but using an older Version of CuraEngine (from 2018, unsure about the exact Version) I was not able to replicate this.
Edit2:
I was also using an older version of fdmprinter.def.json
Somewhat certain I found the reason now

[Ghostkeeper]

I mean, it should be the same if you did everything correctly. And with "correctly" I mean that all of the overrides from the profiles are resolved correctly (or taken from the debug output of CuraEngine when running through the GUI). Note that the debug output doesn't include per-object settings. Pay particular attention to the material diameter and flow settings, considering your problem. Maybe you have to use -j ultimaker3.def.json or something instead of -j fdmprinter.def.json.

[dombmann]

Solved:
Settings were extruder specific so my mistake was to write -s params before the -eX parameter.
Thanks for the help, it gave me a lot of insight.