A nice implementation in Lua (compatible with OpenSCAD) that manage double extrusion the smart way and is able to support G2/G3 GCode (arcs instead of lines!!) between many other advanced features:
http://www.loria.fr/~slefebvr/icesl/
It’s really quite impressive, far ahead of other slicers in many ways. It’s not correct to say that it’s built on top of openscad though 
Hi @Oystein_Krog , you’re 100% correct. I was mistaken and my enthusiasm got the best of me. It’s based on Lua as a scripting language. Not less impressive nevertheless. I really think this is the way to go, next step being also a better integration with 3D printer firmware(s).
This is really awesome. I’m reading the paper on it now.
Lua is a much more powerful language than openscad too.
Openscad quickly becomes painful when you start doing fancy stuff.
Unfortunately this is closed source
Looks awesome, But is there a way to run it on Linux? I see only win32 downloads
@Pavel_Karoukin I have the same concern with a mac version… Being developed in Lua, that shouldn’t be too hard. Probably an additional reason to try to make it popular
I don’t think its developed in lua, but the modelling/scripting language is lua.
@Alexander_Pritchard have you been able to run it successfully? for me it crashed right during setup launch
Just curious, what is the benefit of arcs vs line segments?
Doesn’t the gcode interpreter just split the arcs into line segments based on the tool diameter or some arbitrary number?
@Andrew_Hodel The controller decides how to execute it making it take less bandwidth over serial, possibly even fewer segments to make the arc (or more since it now can decide). 8 bit controllers might have to break it apart, but that’s because they usually aren’t powerful enough and aren’t designed well enough to handle anything but linearity. On better microcontrollers, that limitation goes away.
@Justin_Nesselrotte Then it makes more sense to segment the lines out prior to GCODE and not use arcs as there is more memory than cycles on an AVR when we are talking about sine waves. CAM knows the tool diameter (nozzle diameter in 3dp), which defines the number of line segments.
Serial bandwidth is not the problem, 1 bit (0-255) defines an ascii character. When you have 115200 per second there’s really no problem there even considering extra parameters and the command characters (e.g. G1 FXXX XNN.NN yNN.NN).
You’d have to have a machine running 10’s of thousands of mm/s for that to matter (doesn’t exist).
Just seems like a waste of time to use arcs in gcode. The CAM/slicer is always faster.
That’s the point of serial, it’s not TCP/IP so it’s only talking to one device at a time. (although with TCP/IP the frame sizes (esp extended) could load many arcs at once…
Also FWIW, the GCODE interpreter doesn’t always know the tool/nozzle diameter, where CAM/slicer always does…
1 byte is 0-255. That means 14,400 characters / second assuming you’re using that baud rate. But you can’t look at this with just simple factors like clock speed and memory. You have to understand exactly what’s going on under the hood and the tradeoffs involved.
Ignoring CAM completely (Don’t bring routers into a 3D printing fight? shrug), let’s do a comparison between what the controller has to do with multiple line segments vs an arc as well as look at what it can do. Also, just as a note, neither the arc or the line segments need to know about nozzle diameter in the firmware.
In the case of individual segments, the firmware has to store every single command inside a buffer, until it has processed it into something it can use in its internal buffer. Generally, this means parsing out the mm’s from the input into how many steps it would take, then deciding based on if it’s in relative mode or not, what to put in the internal buffer.
These buffers are not very large, so if I have 30 individual line segments that make up an arc, then the printer might spend a lot of time dealing with the commands it has in the buffer. The problem is that the printer moves faster than we can get those strings back into the buffer and parsed. In fact, assuming that the checksum is handled before inserting into the buffer, and that each floating point number will be represented as XXX.YY (5 bytes), and finally that X, Y, E, and F are used, that’s 30 bytes used for each segment just in the first buffer, not even counting the other buffer that holds movements as steps to take. That’s 900 bytes in the first buffer just to get this 30 segment arc as well as 120 processing of floating point numbers just to get it to a format that the firmware likes.
If you firmly grasp that, you’ll see that a printer might start getting low in its buffer which will either cause it to slow down moves or stop completely when the buffer is empty, waiting for it to fill up a little before continuing. I’ve seen both happen, personally.
If you have an arc, that’s approximately 44 bytes and processing 6 floating point numbers before getting into a format the firmware likes.
Obviously on the side of Gcode, the arc wins here.
What about on the controller side? For an 8 bit avr, with no cos/sin hardware lookup, the line segments are far easier to process, since most of the work is already done. In the case of arcs, the controller breaks it up into how ever many segments it thinks it can handle, BUT it doesn’t have to worry about slowing down by handling so many arcs on its internal buffer. At that point, the only limiting factor is: can the controller handle that math? Remember, there’s a lot of other pieces going on at the exact same time, especially on an 8-bit AVR.
You’re right on the bit vs byte, 14400. I don’t know what you are talking about with routers.
Now in an arc (let’s say 360 degrees) with .4/10 (to be safe)mm per line segment how many lines is that going to be?
If the printer is moving 100mm/s (very fast) then it needs to be 1440 line segments covered in that time. I don’t see how that’s possible.
Not to mention that the gcode interpreter doesn’t know the size of the nozzle.
The problem is not serial bandwidth, it makes more sense as there is enough bandwidth to not complicate the avr.
Remember arcs are from a time when people wrote gcode by hand. It would be worth more argument at 9600 baud (where you may have had trouble) but not at 115200.
For a 50mm circle with a line segment distance of .2mm (half a normal nozzle) there’s 2307 different lines (G1).
If the printer is running at 50mm/s then you have 14400 characters per second. That would be G1 XNN.NNNN YNN.NNNN (20 characters per line) which means for 50mm to be pathed would take a total of 20*50=1000 characters in a single second leaving a total of 13,400 remaining for the baud rate per second of 115,200 serial.
So you could have a machine 10 times that fast (500mm/s) and still be at the baud rate with a 50mm circle and .4mm nozzle. (at half a nozzle width - to be more than fair). And that is assuming a linear path for just the diameter of the circle (50mm) not the actual path distance which is more than that but not worth calculating when just the diameter proves what I am getting at.
You’re focusing too much on the baud rate when that’s not the limiting factor here. You’re also assuming perfect transfer across serial (errors go up as speed does for serial) and you’re ignoring the checksums and serial overhead. You’re also forgetting about feed rate and the extruder running.
Baud rate really is not the issue, it’s the use of interrupts for serial command handling due to po’boy USB implementation. The way many controllers are set up, every time you need to receive a USB command, the processor has to stop whatever it’s doing to receive the input. A series of small gcode segments can very easily block other performance-critical functions such as step generation or motion planning, which causes the controller’s output to stutter or violate dynamics constraints.
In general, this is an issue with the way USB comms are done, not necessarily an arc/line issue. Arc commands are pretty limited: they don’t help with non-quadratic curves.
Then you have to talk about issues with dynamics control… the big POTENTIAL benefit to arc paths (or spline paths) is that the centripetal acceleration can be rigorously defined for vastly improved motion control over the kludgy GRBL-based dynamics code all the mainstream 3DP firmwares use today. GRBL-based algorithms utterly fail to control speed when fed a finely-faceted curve because they only react to magnitude of velocity changes at the segment vertices.
Da hell