Slicer on a microcontroller

I was wondering if I would be mad to think it would be possible to run a slicer on a microcontroller? Here's how I got to the idea, and why I think it would be useful (skip the first paragraph if you want):

So initially I was looking at the Smoothieboard and the LPC1768/9 microcontroller it uses. From there I then found the LPC178x/7x micro which contains an LCD controller to drive an STN or TFT display. I thought it would be cool to have a touch interface for my 3D printer, but then left it at that since it's not much more useful than the character LCDs we have already. A while later I then discovered the Cura slicer, and was impressed at how quickly it did it's work. Also I found the source code very understandable with a clear workflow from 3D model to G-Code. I did however start to notice that although Cura slices quickly, it doesn't always produce the most efficient G-Code. This indicates a trade-off between slicing time and G-Code efficiency.

The above two occurrences bring me onto the idea of running the slicer on the microcontroller. Firstly you don't have to worry about completing the slicing before starting the print. All that would be required upfront is to generate the 2D polygons for each layer and calculate where to place support structure. From there you can spend a lot longer generating the line segments and figuring out the fastest path (A computationally difficult problem to solve). It doesn't matter if the slicing takes 2 hours if the entire print is going to take 4 since the printer only cares about what it needs to print now. The graphic LCD interface would be handy to verify the slicing parameters before printing. Another possibility this provides is the ability to modify a restricted set of slicing parameters on the fly. This may not be that useful when your printer is running smoothly, but could be helpful for setting up your printer, or preventing a disaster.

There are a few challenges I see with this idea:

• Memory: The memory available in a microcontroller would be too limited for this purpose. An external source of memory would be required to store intermediate calculations. This could either be RAM, or even store the data as a temporary file on the SD card. Would a 1MByte SRAM chip be enough?
• Speed: Although the NXP microcontroller can operate at 120MHz, it still may be too much to run the stepper motor control and slicing on the same chip. I think the physical split between slicing and controlling should be maintained by using two microcontrollers with an SPI or similar interface between them. There is still the question as to whether the slicing for a layer will complete faster than the time it takes for the printer to print a layer. This is more of an issue with objects with a very high polygon density.
• UI design: This is probably the most important aspect for the end user. The processing power will probably limit us to 2D renders if we want the UI to remain responsive. It wouldn't be impossible however to render a static isometric view of the print on the build platform. For 2D rendering it will be useful to see the footprint of the 3D printed object and be able to place multiple objects on the build platform. The ability to preview the slicing is also important to enable the end user to tweak the parameters to get the best print. If viewing only a single layer then all you would need to calculate are the line segments for that layer. You can save a lot of calculation time by not worrying about the order to traverse the segments in.

A final point: You may ask why not design a realtime slicer to run on the PC instead and transfer the G-Code over USB as it's being calculated. This is possible, and may be a good starting point. The problem however is the reliability of USB communications for some people (including myself), and the fact you have to have the printer within distance of a PC.

I hope this post wasn't too long. Do you think this idea is at all possible and/or desirable, or am I wasting my time?

Kind Regards,
Sam

Just for perspective, the 'fastest' slicers right now require Gigabytes of RAM and Gigahertz of CPU. Even if you were to consider "Just in time slicing" I don't see it as very feasible on a microcontroller. RAM constraints and threading constraints probably make it impossible. There are other easier ways to handle slicing. People are working on in browser slicing (using Javascript) or having a low powered ARM chip serve as the host controller (web interface/slicing etc. I.E. Octoprint & Cura). At the prices of ARM chips it doesn't make sense to deal with the significant engineering challenges of dealing with slicing on a microcontroller.

All this is of course in my humble opinion of course.

savorywatt

I'd have to agree with savorywatt that slicing on one of the little ATMega or similar MCUs is likely impossible to complete fast enough to work, but have you considered the possibility of permenantly mounting a Raspberry Pi or BeagleBoard onto the printer and using that as a slicing engine. I'm intending on mounting an Rpi permenantly to the circuit board of the large-format 3D printer I'm working on and having it run octoprint to remove the need for an attached PC

---

Prussa i2 Comissioned 4-Nov-2013
Bitcoin : 1Jcrg5czBtNfKyS4sCjFAamJTcSYdTGk9h

An ATmega or similar certainly wouldn't be up to the task. The LPC178x/7x however is a lot more powerful than your usual ATMega, so I thought there may be the slight chance it's possible. The LPC178x/7x microcontrollers can operate up to 120MHz. Compare this to the BeagleBone at 720MHz.
The other difference is that running on a CPU means your process is constantly being interrupted by other processes. On a micro you would be able to have near 100% of the processing time. This may narrow the speed difference a bit more.

I might give the raspberry pi option a try with the Cura engine, and see what the speed is like there. If it's reasonably fast then I think the microcontroller route is still an option.

Slicing uses a lot of RAM, you really need a Linux capable system. Raspberry Pi is probably a reasonable minimum. There is really no chance of slicing on any of the Cortex M series, you'll need at least A series.

But the good news is that there are plenty of fast ARM systems coming through, e.g, Beagle bone, UDOO, Iteaduino, and other ones based on Allwinner socs. You could maybe spend a year trying to get a slicer running on a small MCU, but by then there will be even cheaper/faster ARM CPUs.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

Thanks, It looks like ARM is the way to go. I was trying to avoid that route since most ARM CPUs are in a BGA package which isn't the easiest package to work with. If anyone could point me towards a hobbyist friendly CPU that would be great. Ideally I would like to be able to get everything onto a 2 layer PCB. Maybe I'm asking for too much.

The Raspberry Pi or similar is probably a good start as a prototype.

I am always on the lookout for more "DIY friendly" LQFP packages as well. A colleague and I made a little list at work which I left behind so this is from memory.

A while ago I used a Freescale iMX233 on a 2 layer board, DIY music player project called Lyre which fizzled out. Recently Olimex built some boards on this chip. Its an ARM926 running 450Mhz or so, older architecture but reasonably capable. Chips are widely available. Olimex also have done a board with Allwinner A13, which despite the name is a 1GHz Cortex A8, much more capable, but only source for small quantities is from Olimex who resell them. Olimex designs are Open Hardware, and you can find all the design files on github.

Other chips of note are Freescale Vybrid series, Cortex A5 only 266MHz but has double precision FPU hardware.
TI AM1705 which is also ARM926 but has some TI PRUSS on board which are handy for real time stuff.

NXP also have LPC43xx series which have a Cortex M4 plus Cortex M0, both running at 204MHz, the M4 core has hardware FPU. This might make a good combo for a printer controller, although I would like to see a faster core than M4. There is a rumour of a Smoothieboard based on one of these chips.
Another possible M4 chip is the STM32F429, there is a cheap discovery board available but there is limited RAM.

All the chips mentioned are LQFP and I believe all have external RAM interface as well. Some have ground pad under the chip which is slightly inconvenient but not as bad as BGA.

I hope that gives you something to chew on. I think I would look at the iMX233 or A13 board from Olimex first and see what performance you can get from it.

Sometime I will have another look at that music player project!

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license