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, January 19, 2009
4 Dimensional RepRap
No - we're not doing an open-source time machine. When we get round to that we will do it last year.
This is a more prosaic idea prompted by G Codes and the fact that several people are doing stepper-motor-driven extruders or ones using Zach's neat shaft encoder. I hope I haven't stolen it from Nophead and recycled it as my own idea...
Clearly if you have a stepper extruder there is a precise relationship between the length in mm of filament extruded and the number of steps (this ignores time delays, melt compression and so on - run with me on this). So, why not incorporate the number of mm of filament to extrude as a dimension on each movement? You'd have things like
G1 W50.0 X30.0 Y40.0 F560.0
Where the W coordinate is the number of mm of filament to extrude. This could either get bigger and bigger as a build progresses (we're not going to run out of floating point numbers...) or we could have a convention that zeros it before each move, so it's Pythagoras on the X and Y numbers.
With that we can then control the machine with a 4D Bressenham DDA, which is just as easy to write as the current 3D one and takes hardly any more microcontroller space.
We can then obviously play tricks to get more or less extrudate:
G1 W100.0 X30.0 Y40.0 F560.0
would make a fat splongy line and
G1 W25.0 X30.0 Y40.0 F560.0
would make a jejune one. You can run the extruder without moving to take up any slack:
G1 W10.0 F560.0
and of course you can move with it turned off by omitting the W value altogether.
I'm not sure if this is:
This is a more prosaic idea prompted by G Codes and the fact that several people are doing stepper-motor-driven extruders or ones using Zach's neat shaft encoder. I hope I haven't stolen it from Nophead and recycled it as my own idea...
Clearly if you have a stepper extruder there is a precise relationship between the length in mm of filament extruded and the number of steps (this ignores time delays, melt compression and so on - run with me on this). So, why not incorporate the number of mm of filament to extrude as a dimension on each movement? You'd have things like
G1 W50.0 X30.0 Y40.0 F560.0
Where the W coordinate is the number of mm of filament to extrude. This could either get bigger and bigger as a build progresses (we're not going to run out of floating point numbers...) or we could have a convention that zeros it before each move, so it's Pythagoras on the X and Y numbers.
With that we can then control the machine with a 4D Bressenham DDA, which is just as easy to write as the current 3D one and takes hardly any more microcontroller space.
We can then obviously play tricks to get more or less extrudate:
G1 W100.0 X30.0 Y40.0 F560.0
would make a fat splongy line and
G1 W25.0 X30.0 Y40.0 F560.0
would make a jejune one. You can run the extruder without moving to take up any slack:
G1 W10.0 F560.0
and of course you can move with it turned off by omitting the W value altogether.
I'm not sure if this is:
- Clever,
- Dumb,
- Obvious, or
- Useless.
Labels: Bressenham DDA, G Codes, microcontroller
