dpd123

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!!

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.