RepRap: Blog

"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.

The main goals for this new engine were to be able to implement innovative features that improve the quality of 3D printed objects, and to create a code structure that encourages further development. An intermediate goal was to release it with the baseline feature set that is common in slicing engines, including the ability to robustly handle many kinds of (problematic) models and generate support structures.

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

Ever since we decided to separate the computation of slices from the driving of the RepRap machine by writing the computed slice movements to a G-Code file then subsequently re-playing that on the machine, we have known that that strategy would improve quality. This is because it removes dwells and delays from the build caused by the slicing code having to perform (sometimes quite intensive) computations. The G Code file has exactly all the right speeds and delays in it, and there is no significant delay in transferring the commands to the RepRap machine from simply reading a file.

This improvement was confirmed experimentally and in production by Nophead's Hydraraptor work, and by Zach's ReplicatorG G-Code RepRap-driving program.


Here is the first build out of the standard RepRap Java host software updated as in the post below. It's the RepRap coat hook. I computed the slices and saved them to a GCode file (this took about 12 minutes). Then I replayed the file (this took about an hour and a half). This was on my home RepRap, driven by a Sanguino running the Sanguino GCode firmware extruding ABS at 240^oC.

Above is the coat hook unretouced just after the build finished.


And here is it after brushing the hair off. The quality is almost as good as the superb results that Nophead gets, at which I am well-chuffed as I haven't finished tweaking the parameters yet.

One tiny bug became aparent: the Java hangs writing the GCodes to a file if the RepRap machine isn't plugged into the computer's USB port, even though nothing is going to the RepRap machine at that stage. Now I'm off to hunt that one down; I suspect I may have been too clever adjusting thread priorities...

Tomorrow, Ed and I will get together in the lab at Bath to make sure this all works with the Arduino (which we have on the lab machine) as well as the Sanguino.

Labels: g-code file, host software, java, Sanguino

I have been working on the Java RepRap host software. The latest version (https://reprap.svn.sourceforge.net/svnroot/reprap/trunk/reprap) allows you to:

• Load STL files and print them on a SNAP RepRap (PIC or Arduino).
• Load STL files and print them on a GCode RepRap (Arduino or Sanguino).
• Load STL files and print them as GCodes to a file.
• Load a GCode file and print it on a GCode RepRap (Arduino or Sanguino).

The next step is to put a simple GCode interpreter in there that will allow the final combination: sending a GCode file to be printed on a SNAP RepRap. Also, before doing a release, I need to do a bit more testing (so far I have tested the Sanguino stuff but not the Arduino, for example, as my home machine is Sanguino). I also need to get the progress indicator working with the print-from-GCode-file option; it works with all the others.

The transmission using GCodes is buffered through a separate thread which makes it pretty smooth. This works particularly nicely with GCodes stored in a file (as with Zach's ReplicatorG), and gives good-quality builds. As soon as I've got something more interesting than a cube, I'll post it.

I've had to change a few preferences values - see http://www.reprap.org/bin/view/Main/RepRapSoftwarePreferencesDocumentation.

Finally, you'll see that there is a greyed-out button for "Load RFO". This is the format that Zach proposed along with the Fab@Home guys for multiple-material builds (see http://reprap.org/bin/view/Main/MultipleMaterialsFiles). Watch this space...

Labels: g-code file, host software, java, Sanguino