Dank

One stop Arduino-shield for Grbl!

2012-01-27T10:38:00Z

Riley Porter and Alden Hart of Synthetos has just announced their Grbl-shield, an Arduino shield purpose built for working with Grbl! Ours is in the mail, and we can’t wait to try it out. (Featured in the blogs of Make and Adafruit)

Plug and play compatible with grbl 0.6
Three stepper motors supporting X, Y and Z axes
8x microstepping
2.5 amps per winding (bipolar steppers)
12v-30v motor voltage supported
Independent current control per axis
Motor connectors plug compatible with RepRap and Makerbot electronics
Uses TI DRV8811 stepper drivers

Simen S. S. i Dank

Teardown time! Interfacing "Pocket Radar"

2011-03-04T11:50:33Z

Having children warps your perspective. Totally. And last summer I spent an unhealthy amount of time being annoyed at cars racing up our narrow residential street while rambling incoherently, “Heathens! Think of the children!”

So what does one do? I think some friendly automated neighborhood traffic surveillance would go a long way. So a while back I therefore got hold of a Pocket Radar. While it does evoke the stray ‘is that a radar in your pocket’-joke it is in fact a precise, yet tiny unit. The interface is admirably simple – one big red button (BRB) which starts metering and upon release displays the speed of anything substantial hurtling towards you to within a couple of km/h. So how does it interface?

HEED THIS JOURNEYMAN: According to Pocket Radar the device is very sensitive to static discharge – mostly the pins on the RF board – so if you intend to poke around one of these you should consider an ESD work mat and proper grounding. I did my probing in winter, wearing wooly socks while sliding around on hardwood floors with nothing for protection apart from my sanguine temperament. Stupid luck, most probably.

Promisingly the unit breaks out a few pins right over the battery compartment behind a little sticker. These however proved not to actually carry data, and are probably just diagnostics. Meh.

So here we go.

Broadly the front of the board carries:

1 16-bit TI microcontroller – MCU MSP430F21x2
1 TI programmable DSP – TMS320LF2401A
4 8-bit shift registers for driving the display – "SN74AHC595PW":http://focus.ti.com/lit/ds/symlink/sn74ahc595.pdf
A slew of analog electronics for powering and filtering whatever comes back from the antenna.
2 L324 op-amps

The back has fat pads connecting to the LCD and a light sprinkling of analog components. The bold 7 segment LCD display seems pure oldskool as do the shift registers. It doesn’t have hidden vias or mutiple layers. It’s a USPS truck. It’ll keep on truckin’ till long after the apocalypse.

Photoshop grants me x-ray specs:

Anyways, poking about a bit reveals that the DSP does signal acquisition from the op-amp / RC grid while the shift registers hang off the other MCU and do display refresh. So given:

RADAR → DSP → MCU → SHIFT REGISTERS → DISPLAY

we might just be lucky and find an available digital signal between the DSP and the MCU. Unfortunately finding out what the unit is doing could be somewhat difficult as the antenna is affixed to the back plate of the unit. The same back plate you remove in dissasembling it. Doh. But hey, the unit still powers up and pressing the BRB still still produces a random speed reading every once in a while. I’m guessing this is just noise from the hanging pins usually connected to the antenna.

Probing the DSP while staying far away from the sensitive op-amps reveals that pin 3, SCITXD, unsurprisingly sends something digital and serial to the MCUs RX pin. The TIs support normal UART, but after doing 3 captures I’m left with this:

2 different lengths of signal. Yet a total of 12 changes in sign for all of them.

The display can be set to meters/sec, feet/sec, km/hour and mi/hour. For all we know the data is coming off the DSP in a fifth intermediate format. Hoping that it’s one of the four above and counting.

The width of each pulse is 122µs = 0.122ms = 8196,7 baud. Now, 8196,7 / 2 is 4098 which seems just too much of a coincidence.

Transcribing the bits as clocked out gives us:

1. low ->  1010101011100010101000 -> high 


2. low ->  10101010111011100010001110 -> high


3. low ->  1010101000101110001010 -> high

While the display readings in binary are:

1.


86m/s ––    1010110     / lsb 0110101


283f/s ––   100011011   / lsb 110110001


311km/h ––  10011011    / lsb 11011001


193mi/h ––  11000001    / lsb 10000011





2.


81m/s   ––    1010001   / lsb   1000101


267f/s  ––  100001011   / lsb 110100001


293km/h ––  100100101   / lsb 101001001


182mi/h ––  010110110   / lsb  01101101





3.


136m/s - 10001000


446f/s


489km/h


304mi/h - 100110000

The repeats seem to be carrying information, but how? I stare unblinkingly at it for half an hour to grok pattern, but give up at 1:30AM. Next day I give Simen a call. He remembers a blog post he happenend upon describing an unclocked serial protocol where the recipient meters the baud-rate, by looking at the initial pulses. The repeats then carry a specific truth value regardless of their being high or low. This very quickly gets results.

1. low ->  1010101 011100010101000 -> high 


    mi/h     0 0 0  0  1  100000  1





2. low ->  1010101 0111011100010001110 -> high


   mi/h     0 0 0  0  10  1  10  1  10








3. low ->  1010101 000101110001010 -> high


   mi/h     0 0 0  1  00  1  10000

The protocol starts with 7 bits of toggling, presumably to establish a bit rate, 9 bits of data follow. Repeats are signal true, any other toggle is false. The data is in miles per hour.

This snippet of ruby will run the decoder for you – raising an error for repeats that aren’t threes is left as an exercise to the reader:

pulses = ["1010101000101110001010", "10101010111011100010001110", "1010101011100010101000"]


should_equal = [304, 182, 193]





def decode pulse


  # chop first 7 bits. sync pulse


  pulse = pulse[7..-1]


  result = "" and cnt = 0


  while cnt < pulse.length do


    if pulse[cnt] != pulse[cnt+1]


      result << "0" 


      cnt += 1


    else


      result << "1"


      cnt += 3


    end


  end


  return result.to_i(2)


end





pulses.each_with_index do |pulse, index|


  puts "= #{decode(pulse)} // #{should_equal[index]}"


end

Even W. i Dank

Open source laser cutter Lasersaur using Grbl*

2011-02-08T23:18:32Z

Stefan and Addie or Nortd Labs are creating an open source laser cutter. Looking for a suitable firmware they happened across Grbl and dared to try out the ultra-beta acceleration branch which turned out nicely for them:

Initially we wanted to write our own firmware from scratch for an ARM Cortex M3. Then we started playing with some open source AVR firmwares. Man, these 8-bit hackers have done some impressive work. […] In the end we only got grbl to perform smoothly (after updating to the super cutting edge code of Feb 3).

We appreciate their enthusiasm and look forward to assist them in adapting Grbl for laser cutting as much as we look forward to being able to build our own open source laser cutter from their plans.

(Also, if you’d like one, consider pitching in via the paypal links at the bottom of this page)

*) Grbl is our free, open source, high performance CNC controller written in optimized C that will run on a straight Arduino. More

Simen S. S. i Dank

Hello Kitty Stencil

2011-03-03T21:29:22Z

When my first daughter was born 2.5 years ago I attempted shielding her from the insiped, trite garbage that is marketed to their bracket. Pink was not to be worn. Unisex garb in earth tones mandated. And indeed, as resistance proves to be futile, today I milled her a Hello Kitty stencil. So she can wield a clone army of pink little kitties and bomb her way to day care.

Shot and edited on my phone. The volume tends to vary.

Even W. i Dank

Optimizing the cornering algorithm for the Grbl acceleration code.

2011-01-19T08:18:18Z

Attempting to discover the best algorithm for determining optimal speed reduction in order to pass a corner at maximum speed but within a set jerk limit.

Red: The jerk-limit, Yellow: The actual jerk, Transparent blue: The sum of incoming and outgoing feed rate. The intersection between the red and yellow is the set of candidate cornering factors, the optimum one is the one where the speed is the highest, i.e. where the blue transparent layer is at its tallest.

The final optimizing algorithm must run on the AVR328 in a matter of milliseconds.

Simen S. S. i Dank

Mad professor control unit

2011-01-15T11:10:01Z

We are experimenting with real time controls for the milling operation and came up with this unit cobbled together from dumpster spoils and the Big Dome Push Button. Now we can tweak the feed rate in real time using the sliding pot, see if we suffer buffer underruns because of poor serial comms and we have two buttons for pause and emergency stop. There is an experimental branch up on github if you want to experiment with real time feed rate tweaking: Control. (Warning: The pins had to be remapped. Be sure to check config.h for the updated pin out.)

In related news: We finally have gotten through most of the code for a look ahead optimizing acceleration manager for Grbl. It is completely untested yet, but if you are so inclined you can have a look at the code in this experimental branch. The details will be explained in a proper blog post later.

Simen S. S. i Dank

74LS-heaven

2010-06-24T23:27:39Z

While diving our favorite dumpster: a clutch of more than 300 vintage 7400-series logic chips! Previously we have scored stepper motors to last a life time in this very dumpster.

Simen S. S. i Dank

Configuring Grbl

2011-02-21T11:52:31Z

Grbl has the neat ‘$’-command to tweak the settings at runtime.

Connect to Grbl using the serial terminal of your choice (baud rate 9600 unless you changed that in config.h).

Once connected you should get the Grbl-prompt. Write $ and press enter. You should see something like this:

$0 = 400.0 (steps/mm x) $1 = 400.0 (steps/mm y) $2 = 400.0 (steps/mm z) $3 = 30 (microseconds step pulse) $4 = 480.0 (mm/sec default feed rate) $5 = 480.0 (mm/sec default seek rate) $6 = 0.100 (mm/arc segment) $7 = 0 (step port invert mask. binary = 0) $8 = 25 (acceleration in mm/sec^2) $9 = 300 (max instant cornering speed change in delta mm/min)

To change e.g. the microseconds step pulse option to 50us you would do this:
>> $3=50
The settings are stored in eeprom and will be retained forever or until you change them.

$0, $1 and $2 – Steps/mm

Grbl needs to know how far each step will take the tool in reality. To calculate steps/mm for an axis of your machine you need to know:

The turns per mm of the lead screw
The full steps per revolution of your steppers (typically 200)
The microsteps per step of your controller (typically 1, 8 or 16)

The steps/mm can then be calculated like this

steps_per_mm = (steps_per_revolution*microsteps)/turns_per_mm

Do this for every axis.

$3 – Microseconds/step pulse

Stepper drivers are rated for a certain minimum step pulse length. Check the data sheet or just try some numbers. You want as short pulses as the stepper drivers can reliably recognize. If the pulses are too long you might run into trouble running the system at high feed rates. Generally something between 20 and 50 microseconds works.

$5 – default feed rate

When running G-code this setting will usually not enter into the picture as all feed rates will be specified in the file. I set these to the highest practical feed rates.

$6 – mm/arc segment

Grbl renders circles and arcs by subdividing them into teeny tiny lines. You will probably never need to adjust this value – but if you find that your circles are too crude (really? one tenth of a millimeter is not precise enough for you? Are you in nanotech?) you may adjust this. Lower values gives higher precision but may lead to performance issues.

$7 – invert mask

My cnc-stepper controller needs its values inverted. Signal lines are normally high and goes low for a couple of microsecond to signal an event. To achieve this I need to invert some of the bits. This value is a byte that is xored with the step-data before it is sent down the stepping port. That way you can use this both to invert step pulses (like I do) or to invert one or more of the directions of the axes. The bits in this byte corresponds to the pins assigned to stepping in config.h. Per default bits are assigned like this:

#define X_STEP_BIT 0 #define Y_STEP_BIT 1 #define Z_STEP_BIT 2 #define X_DIRECTION_BIT 3 #define Y_DIRECTION_BIT 4 #define Z_DIRECTION_BIT 5

If you wanted to invert the X and Y direction in this setup you would calculate a value like this (in your favourite calculating environment):

>> (1<<X_DIRECTION_BIT)|(1<<Y_DIRECTION_BIT)

Which is equal to 24 so issuing this command would invert them:

>> $7=24

$8 – acceleration

This is the acceleration in mm/second/second. You don’t have to understand what that means, suffice it to say that a lower value gives smooooother acceleration while a higher value yields tighter moves.

$9 – max instant cornering speed change

This is the maximum immediate speed change that the acceleration manager will allow. Higher values gives generally faster, possibly jerkier motion. Lower values makes the acceleration manager more careful and will lead to careful cornering.

Coming soon: Using Grbl

Simen S. S. i Dank

Connecting Grbl

2011-02-21T11:41:43Z

Grbl provides control pulses that control stepper motors. It connects to stepper drivers that actually drive the steppers. To connect a stepper driver you need to connect three wires from the Arduino to each controller board: Ground, Step and Direction. Step is pulsed once for each step the stepper should move. Direction indicates the direction of the step. By default Grbl holds Direction low for forward motion and high for reverse.

By default Grbl uses the AVR port D for stepping pulses. PD0, PD1 and PD2 is step signal for X, Y and Z axis respectively. PD3, PD4 and PD5 is direction signals accordingly. So e.g. for the X stepper controller you shoud connect Step to PD0 and Direction to PD3.

To make things simple, the Arduino is not marked according to AVR port-mnemonics. Referring to the chart below we see that PC0-PC5 corresponds to the pins named “analog input” 0-5.

The pin mapping is identical for atmega 328

If you need to – and you are building Grbl yourself – you can reassign all ports used by Grbl by editing config.h. The relevant piece of code looks like this:

#define STEPPING_DDR DDRD #define STEPPING_PORT PORTD #define X_STEP_BIT 2 #define Y_STEP_BIT 3 #define Z_STEP_BIT 4 #define X_DIRECTION_BIT 5 #define Y_DIRECTION_BIT 6 #define Z_DIRECTION_BIT 7

For performance reasons all step and direction-pins need to be on the same port, but you can pick port and bits at will. Make sure STEPPING_DDR and STEPPING_PORT point to the same port, and always do a full clean before you rebuild after changing config.h as changes in header-files will not automatically lead to recompilation of the affected units. Rebuild like this:

% make clean && make

Next: Configuring Grbl

Simen S. S. i Dank

Getting Grbl

2011-02-19T23:15:06Z

Grbl runs on the AVR Atmega 168 and 328 microcontrollers, the processor that powers the famous Arduinos. The code is freely available from our github repository

The simplest possible way

Getting a prebuilt version running is easyish if you are able to do a bit of detective work using the console on your system. If you’d rather build Grbl yourself check out the DIY way.

For windows

Get an Arduino Duemilanove or some other *uino-flavor based on the atmega 168 or 328
Download one of the prebuilt .hex-files from the Github downloads-page
Connect the Arduino to your computer
Install the Arduino Uploader and upload the .hex-file to the Arduino and you’re done. Move on to Connecting Grbl

For mac/linux

Get an Arduino Duemilanove or some other *uino-flavor based on the atmega 168 or 328
Download one of the prebuilt .hex-files from the Github downloads-page
Download and install the Arduino IDE
Connect the Arduino to your computer
Then just flash the code onto the arduino using avrdude which installed with the Arduino IDE

… which can seem a bit hairy the first time you do it. Here goes:

Locate avrdude inside the Arduino IDE folder. On my Mac it is located here (on your system it might be somewhere else):

/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude/avrdude

Locate avrdude.conf inside the Arduino IDE folder. On my system it is here:

/Applications/Arduino.app/Contents/Resources/Java/hardware//tools/avr/etc/avrdude.conf

Discover the name of the serial port for your Arduino. (This instruction is for Linux or Mac – I actually have no idea what you would do on a Windows-box.) Making sure the board is connected write:

% ls /dev/tty.usbserial*

The name of the device will be listed. If more than one device shows up, you might have to guess a little. You’ll figure it out.

Then, being inside the folder where your .hex-file is residing, issue a command like this substituting your two paths, the serial port device name and the name of the hex file you are flashing:

/path/.../.../avrdude -C/path/.../.../avrude.conf -pm168 -cstk500v1 -P/dev/tty.usbserial-A3132 -b19200 -D -Uflash:w:grbl_328.hex

You should see something like this:
avrdude: AVR device initialized and ready to accept instructions


Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0×1e9406

avrdude: erasing chip

avrdude: reading input file “grbl.hex”

avrdude: input file grbl.hex auto detected as Intel Hex

avrdude: writing flash (14228 bytes):
Writing | ################################################## | 100% 8.06s
avrdude: 14228 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 auto detected as Intel Hex

avrdude: input file grbl.hex contains 14228 bytes

avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 6.45s
avrdude: verifying …

avrdude: 14228 bytes of flash verified
avrdude: safemode: Fuses OK

avrdude done. Thank you.

Next: Connecting Grbl

The DIY way

Grbl compiles using the avr-gcc toolchain. On most linux-systems this is availible as a package. On Windows you’ll have the Winavr package.

If you use a Mac you should avoid the MacPorts-package (old, old!) and just use the toolchain that comes installed with the Arduino IDE. On my system I keep this line in my ~/.bash_profile:

Use the currently installed Arduino build environment as the avr-gcc-compiler export PATH=$PATH:/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin

This works exactly like the macports-package, except it is a current version and it even runs on Snow Leopard (thank you Arduino-people!)

If you are serious about AVR-development you should also get a proper programmer. We use the AVRISPmkII and the STK500 Compatible USB Programmer.

The source code lives in this repository at github. You will need to install the version control system git to check out the code. When you got it, do this:

% git clone git@github.com:simen/grbl.git

The code will be in a folder named ‘grbl’ in your current directory.

% cd grbl % make

The code should build. Connect the programmer and do this:

% make flash

And you’re done. Good luck! If you come up with some nice feature, please consider contributing a patch!

Next: Connecting Grbl

Simen S. S. i Dank

Grbl

2012-04-25T23:01:25Z

Grbl is a free, open source, high performance CNC milling controller written in optimized C that will run on a straight Arduino.

Get the code at Github | Follow Grbl on Twitter

MIT Center for Bits and Atoms designed a beautifyl snap fit CNC machine controlled by Grbl.

Nortd Labs runs their open source laser cutters with a Grbl-based firmware

Who shoud use Grbl

Makers who do milling and need a nice, simple controller for their system (and who can handle the lack of a user friendly, graphical client)
People who loathe to clutter their space with legacy PC-towers just for the parallel-port
Tinkerers who need a controller written in tidy, modular C as a basis for their project.

Nice features

Grbl is ready for light duty production. We use it for all our milling here at Dank running it from our laptops using a simple console script (included) to stream the G-code. It is written in optimized C utilizing all the clever features of the Atmega168*/328-chips to achieve precise timing and asynchronous operation. It is able to maintain more than 30kHz step rate and delivers a clean, jitter free stream of control pulses.

The G-code interpreter impements a subset of the rs274/ngc standard and is tested with the output of a number of CAM-tools with no issues. Linear, circular and helical motion are all fully supported.

Most configuration options can be set at runtime and is saved in eeprom between sessions and even retained between different versions of Grbl as you upgrade the firmware.

Acceleration management

The most requested feature that we really wanted to have was a nice and advanced look-ahead accelleration manager. Some users were not able to run their CNCs at full speed without some kind of easing. It proved complicated to get this feature just the way we wanted it (simple yet optimal) so it took more than a year, but finally I think we got it: Grbl’s full acceleration-management with look ahead planner will ease into the fastest feed rates and brake (just enough) before sharp corners for fast yet jerk free operation.

Limitations by design

At this time we have no nice desktop client for Grbl. If you want one anytime soon, you’ll probably have to contribute one yourself. With Grbl you’ll have to be comfortable in a terminal window as all our client tools are simple (yet nice) text based scripts. (We do try to stay compatible with the RepRap software, so you might get stuff like ReplicatorG to control it, but last time we tried it was so buggy on the Mac that we gave up.)

We have limited g-code-support by design. Grbl support all the common operations encountered in output from CAM-tools, but leave human g-coders frustrated. No variables, no tool offsets, no functions, no arithmetic and no control structures. Just the basic machine operations. We have yet to find a CAM-generated file that failed to run, though.

Grbl is for three axis machines. No rotation axes – just x, y and z.

Coming attractions

End stops, emergency stop, spindle control, autodetection of client baud-rate, support for alphanumeric read-outs and headless mode via SD-card.

Next: Getting Grbl

—
_*) Grbl 0.6 fits in the limited code space of the atmega168 only by dropping the circle/arc code. 168-people who needs their circles please use version 0.51 which has no acceleration management, yet is still maintained in this branch

Grbl is licenced under the GNU General Public License and developed at Dank by Simen Svale Skogsrud.

Simen S. S. i Dank

If Norwegian Road Spending was Elevation

2010-06-19T00:38:22Z

After seeing Doug McCune’s playful visualization of public data, If San Fracisco Crime were Elevation I was tempted to do the same for a Norwegian data set.

After casting about for something to make heat maps out of I came upon KOSTRA, the official statistics from Norwegian municipalities. While not exactly as spectacular as prostitution in the Tenderloin, Norwegian road spending per capita is a political hot potato (or at least, a semi-lukewarm potato). Here follows a few renders from last night. Like Doug I have to emphasize that this is close to useless as strict infoviz, but it does make for nice eye candy.

Even W. i Dank