Microcontrollers Robots "/>

X/Y robot with MakeBlock (Part 4)

17 February 2014 at 1:38 am

Article image for X/Y robot with MakeBlock (Part 4)

Have spent a couple evenings on getting GRBL up and running now. Here's my notes from setting it up.

Compiling GRBL on OSX

At Oslo Maker Faire, I finally met Simen Svale Skogsrud from the Oslo firm Bengler. One of their/his many cool side-projects is GRBL - a machine control software used for CNC, laser and 3D printers. As soon as I saw the Makeblock X/Y gantry, I knew that I had to make it run GRBL. Since most of the guides available seem to think that getting GRBL onto an Arduino is difficult, I thought that I'd write a small guide/tutorial for how I did this.

Start by copying / clone the source files from the Github repository to your machine. The precompiled versions could work, but I'll need access to the source later.

Download what we'll need

If you don't have the Arduino IDE installed, go get it from arduino.cc. This contains all the command line tools we'll need, including avrdude (used for uploading code to the Arduino) and the avr-gcc compiler (converts source code to something the Arduino can use). The Terminal application is in the Utilities subfolder on your Mac /Applications/Utilities/Terminal. Open the app and type avrdude. If you get an error message along the lines of "command not found", we will need to setup the Mac to know where the AVR software are.

Adding the AVR tools to PATH

My original intent was to use LadyAda's tutorial (http://www.ladyada.net/learn/avr/setup-mac.html) for setting up AVR, but it's unfortunately quite outdated. Some of the external links are dead and I think it's possible to do this a little easier given that all the required tools are in the Arduino download.

Add your AVR-dude to the OSX path according to this tutorial. The AVR tool location on your machine will vary, but it will probably be somewhere inside your Arduino app folder like this:


After adding to the path, you'll need to close that terminal window and open a new one for the PATH to refresh. Typing "avrdude" in this new terminal window should now list all the options instead of "command not found". If not, go back to the tutorial above and try again.

Compiling the source

Now that we have the AVR tools in our path, we can go to the GRBL folder. I placed mine along with other Arduino code at /Users/jensa/Documents/Arduino/grbl/. Open open a terminal window and go to that folder:

cd /Users/jensa/Documents/Arduino/grbl/

To generate a .HEX file from the source code, simply type "make" and hit Enter.

If all goes well, you will now get a compiled program that you can upload to your Arduino. If something goes wrong, type "make clean" to remove the generated files. To see what other options are available, have a look at the "makefile" in the grbl folder. this is also where you'll adjust the compilation options if you're compiling for something other than an Arduino UNO (or other Atmega 328p-based devices).

AVR adjustments

To upload the hex file to the Arduino, you'll use "make flash". As long as the path has been set properly, that will compile just fine, but uploading it didn't go as planned. After figuring this one out, I found this official guide that could have helped me. To help others in the same situation, I'll leave how I got it working without this guide and the errors I got:

avrdude -c avrisp2 -P usb -p atmega328p -B 10 -F -U flash:w:grbl.hex:i
avrdude: can't open config file "/usr/local/etc/avrdude.conf": No such file or directory
avrdude: error reading system wide configuration file "/usr/local/etc/avrdude.conf"
make: *** [flash] Error 1

Looks like avrdude needs some custom configuration. Let's have a look at what's required. By typing "avrdude" on the command line, you'll get an overview of what's possible. From this, we can see that the "-C" flag allows us to set a custom configuration file. Since we are using the Arduino supplied version of AVR, we should probably use that config file as well. I found this file by using the find command in the terminal window:

sudo find / -name "avrdude.conf"

In my case, the path was:


so you're will probably be something similar. I added this to "makefile" after the other parameters for "PROGRAMMER" so that the line was now:

PROGRAMMER ?= -c avrisp2 -P usb -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf

Running "make flash" now returned a different error message:

avrdude: usbdev_open(): did not find any USB device "usb"

Right… That makes sense. In the Arduino IDE you're always specifying paths that start with /dev/ and such. You can find the correct port using the command

ls -l /dev/cu.*

This returns a list of possible devices and it's the same you'll find in the Arduino IDE. In my case it was /dev/cu.usbmodem411. Note: do not have the Arduino IDE open while doing this as it can cause trouble.

My "PROGRAMMER"-line in the makefile was now like this:

PROGRAMMER ?= -c avrisp2 -P /dev/cu.usbmodem411 -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf

I still got errors though:

avrdude: stk500v2_ReceiveMessage(): timeout

Ok. I've seen this one before. It basically means that your config is correct, but something is incorrect with the programmer. The programmer is set with the "-c" flag and here it's set to "avrisp2". That's the same as using "AVRISP mkII" in the Arduino IDE and that won't work with an Arduino UNO board. How about removing the number 2 so we get this:

PROGRAMMER ?= -c avrisp -P /dev/cu.usbmodem411 -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -carduino

Note the addition of -carduino at the end there? It helps with defining the right board. Ohhh! It's uploading! Now let's see if this works. We should be able to log onto the GRBL installation using the Arduino serial monitor. Bingo.

For figuring out the rest, I looked a lot at this tutorial that details how to use GRBL for a laser engraver. It's a little outdated, but has tons of good info!

For some defaults, I tried what is found on the GRBL wiki. That didn't work too well with the MakeBlock setup I have. Instead I ended up on using something like this:

$0=12.650 (x, step/mm)
$1=9.000 (y, step/mm)
$2=25.000 (z, step/mm)
$3=5000.000 (x v_max, mm/min)
$4=5000.000 (y v_max, mm/min)
$5=500.000 (z v_max, mm/min)
$6=500.000 (x accel, mm/sec^2)
$7=500.000 (y accel, mm/sec^2)
$8=10.000 (z accel, mm/sec^2)
$9=200.000 (x max travel, mm)
$10=200.000 (y max travel, mm)
$11=200.000 (z max travel, mm)
$12=10 (step pulse, usec)
$13=2500.000 (default feed, mm/min)
$14=192 (step port invert mask, int:11000000)
$15=25 (step idle delay, msec)
$16=0.050 (junction deviation, mm)
$17=0.005 (arc tolerance, mm)
$18=3 (n-decimals, int)
$19=0 (report inches, bool)
$20=1 (auto start, bool)
$21=1 (invert step enable, bool)
$22=1 (soft limits, bool)
$23=0 (hard limits, bool)
$24=1 (homing cycle, bool)
$25=224 (homing dir invert mask, int:11100000)
$26=100.000 (homing feed, mm/min)
$27=500.000 (homing seek, mm/min)
$28=100 (homing debounce, msec)
$29=2.000 (homing pull-off, mm)

An error that had me stumped for a long time was that the limit switches would be hit all the time causing the GRBL error:

ALARM: Hard/soft limit. MPos?

I searched and searched until I found this post https://github.com/grbl/grbl/issues/226 regarding testing of homing in 0.9. Oh my… GRBL wan't to work with a 3 axis setup? How on earth could I know that… Well. I guess I could change the Z-axis a bit. That way I could even fit a Dremel on there? Hmmm! That sounds interesting…