CuraEngine socket communication

[Luiz_coder 0]

Dear friends,

 

I have been trying to do some automation regarding slicing STL files to convert them to GCODE programmatically, i.e. through the use of a computer programming language.

I have tried basically these three approaches:

 

1) Calling CuraEngine as a command line process.

2) Connecting to CuraEngine socket.

3) Controling Cura GUI with a third part automation software.

 

With approach number 01 I can generate GCODEs, but they end up being malformed, a lot bigger in file size and there is also a limitation on the number of  "-s" parameters I can send through command line, thus bringing unsatisfiying results.

 

Approach number 03 is not very reliable, as it depends on how the app window is located on screen, resolution and other factors, although is the best way considering GCODE generation.

 

Approach number 02: I could successfully connect to CuraEngine socket through Java and LibArcus, but the only Google Protocol Buffers message I am able to send to CuraEngine is of "Progress" type. Also, I did not find any message types that allow me to load an STL file (as the CuraEngine "-l" argument does) neither to output a GCODE (as "-o").

 

So I kindly ask you guys if you can provide me with any code example of correct way of using CuraEngine with socket option.

 

What I am doing is executing "CuraEngine socket 127.0.0.1:8080" (or other port) and connecting to it with Java and LibArcus library.

It connects successfully, I can communicate with CuraEngine socket, but I don't know how to load an STL and send a "Slice" command and output the generated GCODE.

 

I've done a lot of research on the Internet but found nothing. So I ask for your kind help.

 

Regards,

Luiz.

 

[nallath 1,120]

Quote

With approach number 01 I can generate GCODEs, but they end up being malformed, a lot bigger in file size and there is also a limitation on the number of  "-s" parameters I can send through command line, thus bringing unsatisfiying results.

I've never ran into the number of parameters issue. Perhaps this is some issue with windows? I've also not have had them being malformated. The larger size is likely because of different settings.

 

Quote

Approach number 02: I could successfully connect to CuraEngine socket through Java and LibArcus, but the only Google Protocol Buffers message I am able to send to CuraEngine is of "Progress" type. Also, I did not find any message types that allow me to load an STL file (as the CuraEngine "-l" argument does) neither to output a GCODE (as "-o").

I really don't understand what you're doing here. The engine sends progress to the frontend, not the other way around. There is no command that allows you to load an STL as the -i command, you will need to send triangle soup yourself. You can also not let the engine directly save to disk like that. You will get a message with the g-code and you will need to save it yourself.

[Luiz_coder 0]

Nallath, thank you for your kind reply. I will do some additional research here, based on your comments.

[dpd123 0]

Hello Luiz, I'm curious if you have made any progress with automated slicing?

 

Cura is my favourite slicer, but the lack of automation slicing 3MF files is becoming very cumbersome. Reslicing hundreds of files by hand when print settings evolve, or when I add new printers to the farm? This is Cura's massive downside in a professional shop.

 

It's more frustrating because all of the pieces seem to be almost-there, but I have not found a way around too many -s options breaking the command line. Also it is cumbersome to have to down convert 3MF to STL to keep my bed placements. The whole command line / scripting / automation situation, critical for busy shops, seems to be low priority and basically broken.

 

I have built some scripting tools for mounting 3MF and swapping entire parameter directories, essentially cloning one 3MF's printer and slicer settings into target 3MFs, which I'm happy to share with anyone curious. It saves a lot of time manually reapplying profiles and printer variants in the GUI. But efficient slicing is still elusive.

If you have made any strides in this direction yourself, I'd love to know, before jumping ship to one of the slicers that have working batch support.

Edited October 2, 2023 by dpd123

[Cuq 198]

Which slicers offer these functions in batch mode ? Perhaps giving software and function references will help us understand your requests a little better ?

[Slashee_the_Cow 266]

If it's possible to do what you want using the GUI, you could try automating it using something like AutoHotkey. Slow? Probably. Better than nothing? Maybe.

[dpd123 0]

Hi Slashee, thanks for the suggestion.

Indeed, I put a lot of work into scripting using xdotool in linux, which is a powerful scripting tool that sends keys and mouse events directly to applications and windows. There are a few problems with this approach in Cura.

- The QT library as implemented by Cura has a lot of nonstandard behaviour. For example, try scaling a model (I'm using 5.4.0). Double click on the %scale. In a normal program, you can then type a new %. In cura, the keyboard is sent back to the model display window, you have to click again, then backspace-backspace etc. This was not an issue with 4.x, it's part of the (very awesome, apart from scripting issues) 5.x opengl-heavy rendering and windowing. In short, its behaviour is a bit nonstandard for a linux/QT app in several ways that make window focus commands, event listeners etc. break.

 

- Files take SO LONG to save in 5.4.0, the only way to script events is to wait a very long time, like 5 minutes between save commands to make sure larger models save properly. This means the computer takes 20 hours for a task that should take an hour.

 

The command line is the ideal solution, but as you can find when you search the forums, reddit, etc., it is pretty much broken. There is no way to put the whole settings list into the command line, it truncates the list and complains that settings are missing, when they are there. This is a known issue, as documented by Luiz_coder above.

 

So command line is nonfunctional, presumably because the Cura devs only care about the socket connection method to CuraEngine, and do not have any unit tests or devs assigned to command line functionality.

 

There are some supposed workarounds, like placing settings directly into printer definitions as defaults. But this is a lot of script programming I would have to do, to automate placement of Cura profile settings into the printer definition JSON and then slice on the command line. Altogether, it is definitely not meant to be used this way.

 

Another issue is that CuraEngine on the command line expects an STL input, not Cura's own 3MF format. So if you take the time to orient and arrange your models and save a 3MF, it is wasted, you have to convert it back to STL which is more room for errors and issues.

 

I'm not complaining about open source Cura in general, the developers have made a great product and deserve only praise. They don't have to prioritize anything just for ME (and others who don't like spending 2 days manually clicking in an app to process their library.)

 

So I think restoring this once-working functionality is going to be a job for the community, either in a fork and pull of the code, or in a tertiary app that connects to CuraEngine via socket which still works, because it's how Cura does it internally.

 

The only complaint I have is that there is no documentation anywhere that advises us "don't bother trying, it's unusable", which would have saved a lot of time investigating, but an awesome program that is free can get away with whatever it wants.

 

I just want Cura to be in the running, for the use cases that e.g. slice the same model, but for 4 different printers, without hours and hundreds of mouse clicks. It would be a great tool for a proper 3D printing farm if this was possible, but as it is, I think it's advisable to use PrusaSlicer or SuperSlicer instead if automated slicing and parameter changes and using 3MF format is required. Notwitstanding, I haven't actually tested the supposed command line for either of those alternatives yet, I've been stubborn not wanting to leave Cura!!

[Cuq 198]

You can use the CuraLiveScriptingPlugin   https://github.com/Ultimaker/CuraLiveScriptingPlugin to automate some actions in Cura.

 

The updated version I'm using : https://github.com/5axes/CuraLiveScripting