Flashing Grbl Hex to Arduino Uno in Ubuntu 10.4

Getting Grbl link This page is where you start to get the directions and files you need to flash grbl to your arduino. I had to make a few changes to the code to get it to work on the arduino Uno. This tutorial is directed at those using Ubuntu 10.4

Download the programs and files as directed on the website. You will need the Arduino IDE, Processing, and the grbl hex file grbl_0_6b_atmega328p_16mhz_9600.hex, which is contained in the archive link at the left. Once you get everything working, you will want to remake this hex file from the current version in the git archive , which would be the subject of another tutorial. Our purpose here is to get Ubuntu 10.4 talking to the arduino Uno, so it can run the MTM Snap.

The first thing you need to do is to find where the latest version of arduino is on your system. I found that Synaptic installs version 18 in usr/bin, you will need to change the name of that file from arduino to arduino-old as root. Then you can have the latest version 22 in its own directory, and use the most recent files, as I show in the code below. The Dank page has some code which needed the following modifications to get it to work on my system with the Uno:

grbl$ ~/arduino-0022/hardware/tools/avrdude -pm328p -cstk500v1 -P/dev/ttyACM0 -D -Uflash:w:grbl_0_6b_atmega328p_16mhz_9600.hex

You can see that I am calling avrdude, not avrdude.conf. Also, I have changed the processor to -pm328p. I plugged my Uno into my computer to find the name of the port, which is ttyACM0. Also, I dropped the switch -b19200, it will not work with that command in the string. When this sequence of commands is run in the terminal in the directory in which the hex file resides (I made one on the Desktop called grbl), you will be rewarded with the following:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "grbl_0_6b_atmega328p_16mhz_9600.hex"
avrdude: input file grbl_0_6b_atmega328p_16mhz_9600.hex auto detected as Intel Hex
avrdude: writing flash (16726 bytes):

Writing | ################################################## | 100% 3.39s

avrdude: 16726 bytes of flash written
avrdude: verifying flash memory against
grbl_0_6b_atmega328p_16mhz_9600.hex:
avrdude: load data flash data from input file
grbl_0_6b_atmega328p_16mhz_9600.hex:
avrdude: input file grbl_0_6b_atmega328p_16mhz_9600.hex auto detected as Intel Hex
avrdude: input file grbl_0_6b_atmega328p_16mhz_9600.hex contains 16726 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.84s

avrdude: verifying ...
avrdude: 16726 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

The Next Steps


There will be a couple of tricks to get the processing sketch to now work with your arduino Uno. A copy of the sketch is also included in the link here in the archive. The first thing you need to do is to copy a couple of files from the arduino directory, and copy over the equivalent files in the processing directory. These files are:

arduino-0022/lib/librxtxSerial.so
arduino-0022/lib/RXTXcomm.jar

*Note* Although I copied over the libtxtxSerial.so, that is not necessary according to the instructions given at MTM Snap Desktop Milling Machine Motion Control w/ Arduino, GRBL, and GCTR. However, it does not appear to hurt anything if you do.

*Note* Installed arduino IDE and processing on Ubuntu 9.10 at fab lab, modified only the RXTXcomm.jar file, that is the only that needs to be changed. Also, processing has a new version and new directory structure where this file is located, at:

*Note* The new version of processing 1.5 is not stable in Ubuntu 9.10, and crashes the system. Performed an upgrade to 10.4, and works OK. Also flashed an arduino Mega, was able to get it to work on my laptop, but not consistently on the fab lab desktop computer. I did have to change the baud setting to get it to flash grbl as if it were an Arduino Duemilanove, modified Makefile from 115200 to 57600, and port ttyUSB1

processing-1.5.1/modes/java/libraries/serial/library

Copy them and overwrite existing file(s) into the processing directory

processing-1.2.1/libraries/serial/library/

Don't forget to reboot!

Now you can open and run your processing sketch gctrl.pde, with one more trick. When you depress the "p" key to select the serial port, it may hang up, and you will have to stop the sketch. Try again, and hold the "p" key down longer the next time. Eventually, you will get a response, and be able to select the serial port, and then the other menu keys to control the stepper motor board. Pressing the "g" key will allow you to load a g-code file created in the fab modules for output on the MTM Snap.

*Note* If you modify the processing sketch, and insert the serial port directly so you do not have to select it by pressing "p", life will be much easier. Simply uncomment the following line [String portname = "/dev/ttyACM0";], and get it to read the following serial port:

Serial port = null;

// select and modify the appropriate line for your operating system
// leave as null to use interactive port (press 'p' in the program)
//String portname = null;
//String portname = Serial.list()[0]; // Mac OS X
String portname = "/dev/ttyACM0"; // Linux *Note the change for the Arduino Uno*
//String portname = "COM6"; // Windows

Of course, do not try to select "p" from the pop up menu, but you can now use the cursor keys to move the MTM SNAP around

Git it Yourself


Once you have everything working, you can modify the grbl file to permit machine constants to be incorporated into the hex file. There is a Makefile which is compiled and flashed into the arduino Uno, which yields the following result, similar to the above when the "make" command is issued in the directory in which the Makefile resides, followed by "make flash":

avrdude -c stk500v1 -P /dev/ttyACM0 -b 115200 -p atmega328p -B 10 -F -U flash:w:grbl.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "grbl.hex"
avrdude: writing flash (16706 bytes):

Writing | ################################################## | 100% 3.57s

avrdude: 16706 bytes of flash written
avrdude: verifying flash memory against grbl.hex:
avrdude: load data flash data from input file grbl.hex:
avrdude: input file grbl.hex contains 16706 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.03s

avrdude: verifying ...
avrdude: 16706 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

*Note* The only disadvantage to this is that you wipe out your bootloader, and cannot use the first method described to flash a precompiled binary. There is a SparkFun tutorial here that should get your Uno back in business. I tried putting in a "-D" option on line 43 of the Makefile so as not to erase the chip, but then the board does not find the serial port.

*Note* Turns out that I did not mess up the bootloader. Pressing the reset key on the Uno, and making sure that the right board was selected in the Arduino IDE solved the problem that wasn't there.

Installing the following program will give you a table of file allocation on your arduino Uno after running the Makefile:

sudo apt-get install ruby

Then you will get this output instead of an error message (apologies for lack of formatting):

--- Requires 1732 bytes of SRAM
avr-size *.hex *.elf *.o

text data bss dec hex filename

0 16706 0 16706 4142 grbl.hex
16706 0 1732 18438 4806 main.elf
340 0 0 340 154 eeprom.o
3338 0 34 3372 d2c gcode.o
44 0 0 44 2c main.o
994 0 0 994 3e2 motion_control.o
4024 0 1317 5341 14dd planner.o
386 0 51 437 1b5 serial_protocol.o
1649 0 0 1649 671 settings.o
22 0 0 22 16 spindle_control.o
1722 0 33 1755 6db stepper.o
898 0 4 902 386 wiring_serial.o

Notes from Jonathan

============

Make sure you have these files modified to look like this, and follow the steps on this page: http://mtm.cba.mit.edu/machines/mtm_snap-lock/build/software.html

grbl/config.h

#define STEPPING_DDR DDRB
#define STEPPING_PORT PORTB
#define X_STEP_BIT 4
#define Y_STEP_BIT 2
#define Z_STEP_BIT 0
#define X_DIRECTION_BIT 5
#define Y_DIRECTION_BIT 3
#define Z_DIRECTION_BIT 1

grbl/settings.h

// steps per revolution * revolutions per inch / mm per inch
#define DEFAULT_X_STEPS_PER_MM (400.0 * 10.0 / 25.4)
#define DEFAULT_Y_STEPS_PER_MM (400.0 * 10.0 / 25.4)
#define DEFAULT_Z_STEPS_PER_MM (400.0 * 10.0 / 25.4)
#define DEFAULT_STEP_PULSE_MICROSECONDS 10
#define DEFAULT_MM_PER_ARC_SEGMENT 0.1
#define DEFAULT_RAPID_FEEDRATE 500.0 // in millimeters per minute
#define DEFAULT_FEEDRATE 600.0
//#define DEFAULT_ACCELERATION (DEFAULT_FEEDRATE/100.0)
#define DEFAULT_ACCELERATION (25.0)
#define DEFAULT_MAX_JERK 225.0
#define DEFAULT_STEPPING_INVERT_MASK 0

===================

The values given by Jonathan in the following 2 lines of settings.h differ than what I downloaded from the git repository:

#define DEFAULT_RAPID_FEEDRATE 600.0 // in millimeters per minute
#define DEFAULT_FEEDRATE 500.0

where they are reversed. It seems to make a difference (changing 500 to 600, and 600 to 500), as I could get it to work after I made this change. I don't know why this should work, or if I am doing something else different - but I pass it on.

*Note* I must have been doing something else different, as I see using the values from the git archive, it works fine.

Bottom line: it requires quite a bit of persistence to get the sketch to work, but it will eventually. You just have to keep reloading the sketch and pressing buttons until you get a response! I also reflashed the board when all else fails, and then retried. I have noticed in the processing environment that sometimes you will get a second instance of the gctrl terminal, which hides behind the processing IDE. That can cause problems, especially error messages. However, once you get a response from the steppers with the cursor keys, it will also run a gcode file

*Note* It isn't worth it! Put the serial port in the processing sketch as described above and forget about the "p" key, it does not work consistently or often at all

This is what should appear in the bottom echo screen of the processing sketch:

Stable Library
==========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7

G
Grbl 0.6b
'$' to dump current settings
ok
ok

gctrl needs to be the current window, with the serial port selected and recognized, else the curor keys will not activate the stepper motors. As already mentioned, sometime you will get a second gctrl screen hiding behind another window (usually the processing sketch), which has to be closed.

Here are some other links discussing grbl:

http://www.contraptor.org/grbl-gcode-interpreter

http://grbl.tumblr.com/