I spent a little time last night looking over the wiring and found that I had reversed 2  wires on each stepper motor........which is why my motors were traveling in the "opposite" direction that I expected. Gotta say, I felt pretty dumb but pretty happy to catch that one.

Tonight I loaded up a gcode file I had created a while back of the sparkfun logo (they have a pretty comprehensive logo page in their about section with a ton of different logos, shapes, etc, etc, in high quality vector (PDF & EPS) files. I used cambam to generate the code (flawless I must say) and have just been waiting to use it.

Turns out that my mill actually works. I shouldn't bee too surprised, I mean after 3 years of tinkering around you'd figure I'd get lucky sooner or later. My next task is to design a dremel mount. At my rate that will probalby take a year, but at least I can draw with a pen until then :-)

Just a quick post to say that Simen has begun documenting grbl. For a quick start guide, head over to http://dank.bengler.no/-/page/show/5471_gettinggrbl

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?

While doing any long term project you are bound to run across three things: Good things, bad things, and downright ugly things. It's part of the territory. In fact, for a hobbiest, these are the things that make a project a project!

The Good:
A short blip about the project was mentioned in a recent article on Tom's Guide. Grant it, after seeing the posting on Sparkfun, I was actively pursuing being featured in the article, but none the less we made it in! That pretty much made my week.

The Bad:
Last Saturday I drove to a "local" (2 hours away) hackerspace meeting to meet up with fellow geeks and check out what other people have been up to. A couple of bad things happened: Only 2 people showed up (not including the host and hostess). This ended up being OK as the the host and hostess did a fantastic job of making us feel welcome. Even with the limited number, we managed to bottle some beer and have a generally good time BSing with each other.

Worse: I tried showing off my mill project (yes, I brought it with me!) but for some reason, I couldn't get it to work. I thought that during the trip something on my protoboard became disconnected.

After all it was the first time I had moved the machine and with extensive use of a breadboard, it wasn't exactly in mobile form to begin with. After troubleshooting for about 15 minutes, I couldn't figure it out and just packed it up. Not a big deal. I figured I'd get it running once I got back home.

The Ugly:
After making the 2 hours trip back to my house, I unpacked the mill and took it back into the Lab, hooked everything back up, put the meter to a few key connections, and tried to give it a test run. Nothing. OK. It had been a long day, I unplugged everything and let it sit.

After a few busy days of domestic duties and work, I had some time Tuesday evening to work on it. After messing around disconnecting the easy drivers from the protoboard (not an easy task!) and simplifying my circuit to only one axis and a simple (known working) sketch. I couldn't get anything to work.

I emailed the creator of the Easy Driver and asked him on a couple of things. Being the generous person he seems to be, he replied with a few tests (procedures) to check if the drivers were fried. Long story short: They were.... All three of them were fried! Here's a couple of pictures of my metering.....

To make matters worse: I fried my Arduino too! It seems that when I tried to demo my machine at the hackerspace meeting I crossed the +24v from my Power Supply and the GND, which essentially meant that I sent 24V into the arduino and then into the Easy Drivers. Both of which were only expecting 5V....

Right now I have a new Arduino on its way from Sparkfun. I will order the easy drivers tonight. In the meantime I'm hoping to learn how one may protect against accidents like this....

But I'll stay positive because, to steal a quote from Dostoyevsky, "A just cause is not ruined by a few mistakes" :)

Here's a video of shapeoko + grbl parsing gcode being streamed from my Dell Mini9. (You can download the gcode below.)

Clearly something is not right. However, the job will run identically, which makes me think that it's a simple software tweak as opposed to something more devistating like a hardware problem.

Another positive sign is the fact that the z-axis height seems to be working just fine. This particular g-code calls for a clearance height of 6.25mm and a target depth of -1mm. Both of which seemed to be consistent throughout the job.

Here is a short video of ShapeOko drawing a box via grbl and hyperterminal. There is still a lot of work to do before this project is "production" ready. But it's really nice to make some progress every once in a while.

The current setup includes:
CNC Controller: Arduino running grbl
Stepper Controllers: Easy Drivers
Stepper Motors: 65oz/in bipolar
Linear Rails: Salvaged from previous builds
Power Supply: 24v 150W
Frame: Custom Designed Laser Cut 1/4" MDF (from ponoko.com)
Z Axis Mount/Slide: 3D Printed Custom Design (from shapeways.com)

If anyone has an idea as to what is causing the wobble in the y-axis, please let me know. I'm open for suggestions :)

What a long long night...

grbl is definitely installed on my arduino. That is good news! Actually it's the only good news for the night.

After getting home from work and getting the regular chores done, putting the baby to bed, and spending some time with my wife, I headed to the basement to put the final touches on this fantastic project. Honestly, I thought this was going to be "the" night. I couldn't have been any more wrong.

First: my lab is a disaster, which I had forgotten about because it's been at least 3 weeks since I last stepped foot in there. It seems that I was using it for "temporary" storage during the holiday season, and have since neglected to remove the temporary items. OK, spent 10 minutes moving stuff around enough so I could at least sit down and reach all of the components.

Two: The battery in my D630 laptop is totally gone. If I unplug it for a second, I get a critical beep and then BAM. power off. I should note that I'm using a power strip as an "e-stop". So, forgetting about the battery deal, i plug in my laptop, power up, log in, load the desktop (at least a 7 minute affair) and then decide to throw the power on the strip because I realize my soldering iron is plugged in. BAM, laptop powers off. I proceed to do this not once but TWO more times before i finally get smart an plugin to a dedicated strip.

Three: I hadn't exactly completed breaking out the STEP/DIR pins for each axis. Not a huge deal, but i did have to strip some wire and do a quick bit of soldering. Here's a picture of the proto board fully loaded.

In retrospect I should have done some color coding for step/dir and especially for the motor harnesses. Chalk that one up under being a rookie I suppose...

OK, so now that everything was setup, I was ready to manually send gcode to the arduino via the serial monitor in the arduino IDE. Laptop is powered up, arduino is connected via USB, XYZ axis' are connected to the arduino. All Set:

I power up the 24v Power supply and everything goes crazy. The X axis is wobbling back and forth, the Y axis is stalling itself out, and the Z axis was making a really creapy humming noise. Power off. Quick.

After trying a few more times, and double checking the pinouts in Simen's config.h file. I couldn't locate the problem. All I know is that if I don't hook up the arduino then everything is fine. The motors will sit there quietly, and everything looks like it's in order. But, the moment I hook up the arduino... bad stuff happens. Here's a video demonstration.

 

So, like I said: That's it for tonight. I'm going to enjoy this delicious Pale Ale from Bell's Brewery and go to bed. Maybe tomorrow will be the day?

After a busy holiday season, it looks like we're back to work:

eps files have been uploaded to Ponoko, and can be found by searching for "ShapeOko". From there you can order. It wasn't exactly necessary but removes one step of the process for anyone looking to build their own mill. Instead of having to upload the files, you can just add them to your cart, and go. Also, the files are freely available to anyone either through ponoko or through the forum here.

Does anyone have experience releasing something under an open source license of an sort? After giving this some though I'd really like to get an official release method but don't really know where to start. Suggestions are welcome.

Machine progress update:

• grbl is loaded on my arduino!
• replicatorG is loaded up and (hopefully) configured correctly on my PC.

I will have some time tonight to test this out, so everyone please keep your fingers crossed. I'll report back tomorrow.

I have managed to find some time during the holiday season to work on the mill. Here's a recap:

• Soldered the EasyDrivers down to a protoboard, and ran the appropriate wires, bringing out the power, step, and dir from each one. I'll get a picture of that up soon.
• Still working on configuring grbl. I've email Simen again trying to clarify a few things. Hopefully he gets back to me soon.
• Posted the updated set of drawing files on the forum (including STEP, DXF, PDF, and the EPS nest.
  
• Posted link to shapeways
• Looking at embedding a 3D model using Autodesk's Project Freewheel
• Used myNesting to product semi-efficient nests. They are in beta now, so all of the nests are free! A very good service if you're looking for a simple nesting solution.