nallath

I meant that printing a single model with one at a time doesn't change anything (and isn't a default setting if I recall correctly).

The guy also has cura in one at a time mode for some weird ass reason. We just have a different definition for "normal" (as I'd guess that s3d takes about 2 times as long, which makes it a rather unfair comparison)

In the new Cura (2.1), you can create a plugin for almost everything (Views, tools, model loading / writing, etc). The old Cura only had post processing 'plugins' (the new Cura also has them; https://github.com/nallath/PostProcessingPlugin). The post processing of the new Cura is called when you save the g-code.

Cura is our slicing application. It doesn't do a whole lot with the printer directly. You could have a look at the USBPrint plugin that's in cura. That bit connects with a printer over USB and streams g-code there.

Mechanical prints. Nothing quite seems to show how awesome 3D printers are as things that you can print (and usually need to assemble) that can move (rotating heart gear, motors, etc)

I didn't have this much issues in getting it to work on Linux. Windows is always a fickle beast in getting software like this to work. But yeah, the issue tinkergnome posted should 'fix' the problem. What i can see from the rest of the logs is that most of the stuff you need did load correctly, so i'm moderately positive that you're almost there

We have fairly little control as to how non Ultimaker printers behave. Almost all support in Cura for non UM stuff is built by people in the community. Because we usually don't have those machines, those bits are not tested (and although we do put the code in, we don't really see it as our responsibility to verify these things). If it runs on Marlin it should be doable. Another option would be to see if there is a SD card controller, so you can just put the g-code on there and let the controller send the commands on the machine (which is the standard way we do it). You could also try prontoface to stream the g-code to the printer.

The link doesn't work. I don't have any experience with using offsets. You could try asking this on the curaEngine github. Our engine engineers check that a lot more frequent than the forum.

Yep. So in my case (I checked out both Cura and Uranium in my Development folder) I use PYTHONPATH=.:/usr/local/lib/python3/dist-packages/:../Uranium/ python3 cura_app.py in order to start Cura. I run this from the Cura folder.

No, you need to give it a file that describes the settings (and the defaults). If you give it that file and no changed settings, it uses the defaults.

Just run the CuraEngine binary. It will output a set of commands that tell you how to handle settings.

As far as I know it's pretty much the same one.

You could also use my Barbarian plugin which converts Imperial units (eg Barbarian units ) into proper metric You can find it on https://github.com/nallath/BarbarianPlugin

The right one? All kidding aside, Cura uses Marlin firmware. You can find the source on https://github.com/Ultimaker/UM2.1-Firmware/tree/UM2.1_JarJar

The effect you have is called pillowing. There are some fixes floating arround here if you look for that.

I think Cura already does this automatically. The old cura has a pre and post hotend switch g-code bit where you can do these things.

I don't really know what caused the crash you have now. I'd suggest running the python stuff from source and copy the artifacts that you do need (eg; CuraEngine)

Cura can. This is a list of all the settings we have wrt to support;

It could use a bit more documentation in the functions. I'm willing to give it a go to make this into a plugin, but I will need to do a bunch of re-factoring to get it to work (eg; I don't want the plugin to load a file, I want it to use an already loaded file (so it can work for all Cura supported file types)

If you're interested, have a look at the new Cura API. Adding this as a plugin there should be quite doable.

Cura also supports angles for support.

We don't build anything with msvc as far as I'm aware. The building system we use is rather complex and fails quite often, so sorry for that.

The cura engine does need to be built, but that is much much easier to build than building all the distributables for Cura. As to finding protobuf, did you install protobuf 3 beta 2? You can find it on https://github.com/google/protobuf/releases

Originally we went with a year.month.version for the release numbering. At one point we decided to pretty much re-do everything we had to make it more feature proof. The latest 'old' cura is 15.04. The first 'new' cura was released as 15.06. This caused quite a bit of confusion, as the distinction wasn't clear enough. This is why we switched to a major.minor versioning system. The upcoming release is the 2.1 release.

If you just want to get started you just need to clone: git clone -b 2.1 git@github.com:Ultimaker/cura.git git clone -b 2.1 git@github.com:Ultimaker/uranium.git git clone -b 2.1 git@github.com:Ultimaker/CuraEngine.git git clone -b 2.1 git@github.com:Ultimaker/libArcus.hit build libarcus; cd libArcus mkdir build cmake .. sudo make install Then build CuraEngine cd CuraEngine mkdir build cmake .. make and run in the cura folder (for linux) PYTHONPATH=.:/usr/local/lib/python3/dist-packages/:../Uranium/ python3 cura_app.py You also need to ensure that the preferences backend_location is set to the right place. Python is an interpreted language. There is no need to compile it.