From ShapeOko
Jump to: navigation, search

SD Support

A few years back, almost immediately after finding grbl, I became obsessed with the idea of creating a truly headless CNC machine. A couple of reasons: Having a full sized computer next to the machine made it look silly. Having a full sized laptop next to the machine made it look silly. But, mainly because the only reason a computer was needed at all was to push simple text across tx/rx lines and that seemed like a waste to me.

The idea of course was to have an SD card loaded with programs (gcode), and send those programs over to grbl without the need for a computer.

I never even messed with the idea of putting SD reader functionality into grbl, thinking there wouldn't be enough room and (to be honest) really having no idea how to incorporate such a task into the existing code. Instead, I bought an SD shield from seeedstudio, and used a seperate arduino to handle the SD card / fat16 stuff. [1] (code moved here?)

Surprisingly I came to a basic solution rather quickly (although it was quite hacky and by no means pleasing to the eye).

What resulted was a successful "headless" machine. Lots of people commented that the second arduino was a waste of resources. I never felt that way because I could see extending the duties of the second arduino to include other related yet not vital operations to running hte machine. Plus, for the relatively low cost of a single arduino (~$25USD), it seemed like a more cost effective solution than using a full blown computer to do the simple chore.

So how does it work?

Headless CNC

Master Arduino <--> Slave Arduino tx <--> rx rx <--> tx d13 <--> d7

1.) The master arduino is running grbl. 2.) The slave arduino is loaded with Bill Greiman’s fat16 arduino library and is connected to an SD shield from seeedstudio. 3.) When the slave arduino's power is turned out it starts reading a txt file from the SD card and sending that information over to the master arduino.

There were some issues (obviously) of overflowing the arduino's tiny serial buffer. To circumvent those overflow issues, I implemented a poor man's version of hardware flow control. Each time grbl processes a command it checks the serial buffer:

if(serialAvailable()>= 128) {LEDPORT |= _BV(LEDBIT);} //turn on LED13

If the buffer is >=128 then it's full. And if that's the case turn on LED13.

On the slave side, before sending data over the serial line, we check the state of pin7 (pin 13 of master is connected to pin 7 of slave). If pin7 is high, then the buffer is full and we need to wait. If pin7 is low, then there is room left in the serial buffer for more txt.

This method hasn't been proven to a degree other than basic functionality. After getting it up and running I went on to something else, thinking one day I would get back to it.

Now What?

grbl has come a long way since then.

What has re-ignited the desire to get this working is the real-time position feedback that is provided from grbl as of version 0.8D. Because with the addition of this feature, we can now implement a simple DRO!

All we need to add to the current setup is an LCD display and a couple of buttons. With those it would be relatively easy to display real time coordinates (X,Y,Z) and possibly even a basic progress meter (0-100%) on the LCD and control grbl's new features (Status Report, Feed Hold, Cycle Start, Reset, Homing) with the buttons. Assuming everything works out as planned the result would be a simple, elegant, low cost control box.


Powering the micro-controller may involve different voltages. Devices for that: http://www.shapeoko.com/forum/viewtopic.php?f=37&t=6181&p=47914 http://www.amazon.com/gp/product/B00IWOPS8K/

See also