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
Monday, June 28, 2010
New Release
I've just done a new RepRap release at Sourceforge. This will probably be superseded quite quickly (we are in the process of standardising the M Codes used to drive the machine, which won't take long).
The host software now runs an awful lot faster when it is slicing RFO files and STL files. This is because I removed something that, in my ignorance, I had thought would make it run faster, but which experimentation has now shown had the opposite effect: I had put a finalize() function in all the geometry classes. That seemed reasonable - give the garbage collector a bit of a hand to tidy things up. But what it actually does is to subvert the garbage collector and to put unreferenced memory into a queue for later removal; a queue that rarely - if ever - seems to get acted upon. If someone can explain why this is a good idea, I'd love to hear it.
Meanwhile, all the finalize() functions are gone, and the host software now runs pretty zippily... (It uses a lot less memory, too.)
The algorithm it uses to find outlines of slices has also been changed to Marching Squares, which seems both more reliable and faster.
The new software now also supports heated beds.
The host software now runs an awful lot faster when it is slicing RFO files and STL files. This is because I removed something that, in my ignorance, I had thought would make it run faster, but which experimentation has now shown had the opposite effect: I had put a finalize() function in all the geometry classes. That seemed reasonable - give the garbage collector a bit of a hand to tidy things up. But what it actually does is to subvert the garbage collector and to put unreferenced memory into a queue for later removal; a queue that rarely - if ever - seems to get acted upon. If someone can explain why this is a good idea, I'd love to hear it.
Meanwhile, all the finalize() functions are gone, and the host software now runs pretty zippily... (It uses a lot less memory, too.)
The algorithm it uses to find outlines of slices has also been changed to Marching Squares, which seems both more reliable and faster.
The new software now also supports heated beds.
Labels: host software
Saturday, June 13, 2009
Acceleration Code Released
There is a new release of the Java host software and the Sanguino firmware that support accelerations and decelerations during building.
Unfortunately the new firmware is now too big to fit in the Arduino ATMEGA 168 controllers (though the old version that does is still available, of course). However, there is plenty of room in the Sanguino, and we will be supporting the Arduino Mega as a RepRap controller soon.
The new firmware buffers all movements, and so communications with the controller are now asynchronous. This completely eliminates all pauses between one movement and the next.
The main advantage of the new code is that you can run the axis motors at much lower current (as they don't have to hit the feed-rate requested in one step from a standing start) while not compromising build times; indeed, you can set higher maximum feed-rates as the machine now accelerates up to them and decelerates down.
Accelerating RepRap from Adrian Bowyer on Vimeo.
Unfortunately the new firmware is now too big to fit in the Arduino ATMEGA 168 controllers (though the old version that does is still available, of course). However, there is plenty of room in the Sanguino, and we will be supporting the Arduino Mega as a RepRap controller soon.
The new firmware buffers all movements, and so communications with the controller are now asynchronous. This completely eliminates all pauses between one movement and the next.
The main advantage of the new code is that you can run the axis motors at much lower current (as they don't have to hit the feed-rate requested in one step from a standing start) while not compromising build times; indeed, you can set higher maximum feed-rates as the machine now accelerates up to them and decelerates down.
Labels: file release, firmware, host software
Sunday, October 26, 2008
New code first build
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 240oC.
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.
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 240oC.
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
Saturday, October 25, 2008
Multimode Host Software
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 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
Wednesday, October 15, 2008
Yes - it's a square...
...but a square made by a Sanguino-controlled RepRap...
...running the G-code interpreter driven directly by the standard Java host software.
The control panel can now send G codes if they're switched on too, so you can control a G-code RepRap interactively.
I want to get to the point where we can drive both the Arduino and Sanguino running either the SNAP protocol or G-code all using the same program.
The next step is to reconfigure the Sanguino so it uses the latest pinouts decided by Zach to give the maximum electronic versatility.
Labels: host software, sanguino g-codes
Wednesday, July 02, 2008
Java Host Software
I've changed the RepRap control panel in the Java host software so that it'll work under Java 1.5. It used to require Java 1.6 (which isn't on the Mac yet), so moving it back a step was a real pain. It's checked into the svn repository.
It's mostly there, plus a little added functionality. You can now pause a build, Sto(re) the current machine coordinates in the XYZ tab, hit the Rcl (recall) button to load those stored coordinates into the destination location, move the machine about, restock the extruder, etc etc, then hit Rcl again then Go there to get back to where you left off, then resume the build. It turns the extruder off when you pause, but doesn't automatically turn it on again when you resume (as you won't always want this). Turn it on in the extruder panel before resuming if that's what you want.
You need swing-layout-1.0.3.jar in your classpath for all this to work. This requirement will go away when we finally move to Java 1.6 (as its equivalent is in there already), but for the moment it's in the lib directory for your convenience.
It's mostly there, plus a little added functionality. You can now pause a build, Sto(re) the current machine coordinates in the XYZ tab, hit the Rcl (recall) button to load those stored coordinates into the destination location, move the machine about, restock the extruder, etc etc, then hit Rcl again then Go there to get back to where you left off, then resume the build. It turns the extruder off when you pause, but doesn't automatically turn it on again when you resume (as you won't always want this). Turn it on in the extruder panel before resuming if that's what you want.
You need swing-layout-1.0.3.jar in your classpath for all this to work. This requirement will go away when we finally move to Java 1.6 (as its equivalent is in there already), but for the moment it's in the lib directory for your convenience.
Labels: host software, java
