Friday, August 02, 2013
New open source slicer: CuraEngine!
"Cura is the name of a divine figure whose name means "Care" or "Concern""Source: Wikipedia
Ever heard of Cura? Besides a divine figure, it's a 3D printing solution that is meant to be useful and usable to both beginning and advanced 3D printer users. David Braam is full-time developer of Cura, at Ultimaker. We recently released version 13.06, which was a major update. Compared to the previous version it looked... well ...exactly the same. But on the back-end, the engine that generates the toolpath from the mesh-surface model (e.g. the STL or AMF) was replaced by a new engine, written entirely from scratch.
The short summary is for this initial release:
- Faster slicing
What took hours now takes seconds. Also, this enabled us to create the following two features. - On-the-fly model preparation
There is no slicing button anymore because it starts processing right-away. - Live tweaking of slicing parameters
Because you see toolpaths re-appear whenever you change a setting, you can quicky find the optimal settings for your print job. - Model fixing
The engine can fix major problem in a model. - Multiple materials
The engine was built from the start with multi-head printing in mind. - Cross-platform
The Engine is written in C++ and released for Linux, Windows & Mac. Compilation on these and other platform should be trivial. - Open source
The license is Affero GPLv3.
A nice side effect of the new slicer is that it turns out to be fast, really fast. We decided to do something unconventional: removing the "Prepare for printing" button from Cura's interface entirely. It will just start slice the model in the background (with a low-priority). If you change the layer height or any other setting, it will just restart. If you don't change settings, it may already have finished before you're thinking to save the resulting G-Code to an SD card or print directly through USB. An extra, pretty useful, side-effect is that you can inspect the generated toolpath, change the settings and see the new toolpath preview appear automatically and quickly, without pushing a button.
Because Cura is developed to work with the Ultimaker and most other RepRap-based designs, we'd like to ask you what you think of the new engine. Also, because, like Cura (source), the Engine is released under the Affero GPL version 3, we'd love to see anyone benefit from this new solution and possibly help us improve it further.
Below is a 45-minute presentation on the Cura release, focusing mostly on the new Cura Engine.
Below is the interview with David by Andrew of 3DHacker.com:
Labels: announcements, G Codes, g-code file, host, host software, improvements, Mac, mesh, multiple materials, simulation window, stl
Wednesday, January 28, 2009
Support for overhangs

The latest Java host program in the repository now contains code to compute the support needed for overhangs automatically. Above is a screenshot of it working - the L block bottom left is being deliberately built the wrong way up so that it needs support. The layer currently being computed is shown in the diagnostic window. You can see the cross-section of the object itself (blue) and the support for the overhang (brown).

Here it is part-way through the build. You can see the support pattern at the front, and the pillar of the L-shaped object being built at the back.

Here is the build finished. The supported bit is at the front.

Here is the part after taking it off the machine viewed from underneath with the support still in place.

And here it is in its final form with the support separated.
The program allows you to specify a support material for each material in the RepRap machine by name. As the RepRap code allows you to have several logical extruders all talking to the same physical extruder you can use a material to support itself by copying its entries in the preferences file (sort the file first to bunch them together) then renaming them from Extruder_0 to Extruder_1 (or whatever). You then change the infill pattern of the support to whatever you want. Here I set it not to outline, only to infill, and not to change the direction of the ply between layers.
The support cleaved pretty easily from the part with a penknife blade, but I suspect that this would have been harder had the underside of the part been undulating rather than flat. Of course two extruders would allow - for example - a friable paste to be used as a support (my current favourite: cornflour mixed with a gel of PVA glue and methanol - to be blogged when I have some results...).
The supports are only computed by the host software when it is saving G-Codes to a file. The reason for this is that the software has to do the calculation in reverse - from the top down - so that it can know what's immediately above the layer it is currently creating. It can only do that by writing each layer as a temporary file, then concatenating them all in reverse order to actually build from the ground up when it has finished.
If you are interested in how the use of a CSG representation makes the support calculation easy to code, take a look at the
private void supportCalculations()function in the class LayerProducer.
As you can see, I have not exactly tested the code on the world's most complex shape, so all this should probably be regarded as experimental...
I'm off for a week to give RepRap talks in Wales and then Spain. When I get back I'll try it on something a bit more challenging, and when it's working properly we'll do a release.
Labels: host, java, overhang, support
Saturday, July 12, 2008
Multilingual Host Software
Thanks to Daniel Kessel, who has done a version of the RepRap Java host software that supports different languages. This isn't in the main subversion trunk yet, but if you want to experiment with it you can find it here.
Labels: host, multilingual
Tuesday, February 26, 2008
Software fixed. Many new special bugs introduced...
I did a foolish thing. I fixed a bug in the Java host code (in the bit that algebraically simplifies CSG expressions) and, instead of just checking that back in, I also spent some time tidying the code, then tested it, then checked in the lot. That gave Subversion revision 1333.
Unfortunately my tidying introduced several new exciting features that many users would have found not entirely helpful that were not apparent in my testing... Sorry.
Now (with Zach's help - thanks), the code has been reverted back to the version that worked, to which I have applied just my CSG fix.
The current revision is 1369. It's not perfect. But it's a lot better than 1333...
Next thing: fix the memory management...
Unfortunately my tidying introduced several new exciting features that many users would have found not entirely helpful that were not apparent in my testing... Sorry.
Now (with Zach's help - thanks), the code has been reverted back to the version that worked, to which I have applied just my CSG fix.
The current revision is 1369. It's not perfect. But it's a lot better than 1333...
Next thing: fix the memory management...