In my last post I mentioned having a problem over flowing the tiny arduino serial buffer while streaming gcode from one unit to another. Since then, I have talked to a few people about the matter, and one suggested implementing some sort of hardware flow-control .

"What it seems to me like you might need is some physical hardware flow control, just a wire running between the master and slave independent of the serial line. So maybe the slave would send some data, and wait for a change on the line, whereas the master would wait to receive data, process it, change the line status, rinse, repeat."

How the implementation ended up going down was something like this:

1.) Connect wire between arduinos (Slave: Pin7 to Master: Pin13)
2.) Master: after each byte recieved, check the status of the buffer. By issuing the serialAvailable() command returns the number of bytes available to be read from the buffer. We know the buffer is only 128bytes in size, so we can do a simple if statement:
   if(serialAvailable()>= 128) {LEDPORT |= _BV(LEDBIT);}   //turn on LED13

3.) Slave: before sending byte, check the status of pin7
           while ((c = file.read()) > 0)
          {
             while(val = digitalRead(flowpin) == HIGH)
            {
               delay(100);
            }
            Serial.print((char)c);
          }
Here is a video of the setup in action. Keep in mind that the SD "shield" is not a shield, i.e. the pins are not repeated on the top of the shield. So, in order to get this to work, i had to use the mini-bread-boards and because of that, this looks a lot more complicated than what it is.

Also, on a somewhat related note: grbl made it on MAKE!

After frying my old Arduino Duemilanove I knew that I'd need to get a new one, and fast. Sparkfun to the rescue. I sat down, ordered a new one (the standard chip is now an atmega328!), ordered some jumper wires and a new breadboard while I was at it. The three tiny breadboards were ordered before I fried my easyDrivers. FYI: they are the perfect size to hold and tie in to a single EasyDriver (v4.2) with headers soldered on!

I also took the liberty of ordering an atmega328 chip with Arduino bootloader. Because of the semi low cost (~$5), i figured it was worth trying to revive my old arduino. First thing I did when the new gear came was pop the old chip out of the fried arduino and popped in the chip in. Yahtzee! My old Arduino is not only alive, it's also upgraded to a better chip. Needless to say, that was good news.

While I decide what path to take for the rest of this project I also ordered more easy drivers. Although there's a good chance I will be using a different solution by the time I complete this project, but I feel comfortable with the easy drivers and know they will work for the time being.

Also, I have been thinking very much about cutting the PC out of the loop entirely. As is, the PC (currently my Dell Mini 9) is simply streaming a gcode file to the arduino. From there, grbl does the rest. Seems like overkill to use a PC for such a simple task.....Enter a second arduino.

The second Arduino will have some FAT library loaded as firmware (have yet to decide which one) and be connected to an SD card shield! The arduino will then read one line of gcode at a time, send it to the primary arduino and wait for the "OK" before sending the next line.

Also, I ran across this instructable, which gave me a pretty rad idea: Why not use one of my old N64 controllers to control the mill? I'm thinking about going to a two Arduino setup as is, with one Arduino not doing much work there should be plenty of ports and programming space available to implement a program which will allow me to jog the machine around, along with possibly homing the Z axis.

In fact, although the feature has a certain amount of "coolness", its quite practical. After all, one does need a way to gracefully move the machine to a "home" position. Right?