If you've got your head around machine coordinates and work coordinates, that's great. A lot of people struggle at that point! Tool offsets are not really needed a lot of the time. In fact, they are most useful if you are using a toolchanger where each tool will go back in the spindle at the same precise position every time. You set work coordinates by touching off the work in X, Y, and Z as described using a reference tool; then the software can use the preset tool offsets to, in effect, reset the Z work coordinate based on the new tool's projection from the spindle every time you change tools. Like a lot of people, I use a slightly different approach. I use a touchplate to set the Z coordinate for the first tool I am going to use. I run a macro which first touches off the movable touchplate (maybe on the top surface of the work, maybe off the spoil board or bed, depending on what I am using as a reference) and then touches off a fixed touchplate set into the bed. The software stores the difference between the Z coordinates. When I switch to the second (or third, etc) tool, another macro touches the tool off the fixed touchplate and can use the stored offset to, in effect, translate this into referencing off the original surface. Which might have be machined away by this point. It's not quite the same as using tool offsets, but it is more suited to a machine like mine where the tool is held in a collet and I cannot control "stickout" very accurately when I change tools.

Which brings me to my problem with open source software for CNC as it stands at the moment - the commercial software lets me do these kinds of things very easily, both in terms of writing macros and modifying control screens to add or change functionality. I had a play with grbl a while ago for another project as I needed motion control software that I could get inside and modify reasonably easily and grbl fitted the bill. However, there is a big difference between adding functionality via macros that give direct access to "CNC functionality" and working out how to do that while grubbing about with a C compiler. It's a bit like asking why I should bother with using a database package when I could write the same thing in assembler! Well, that's a bit of an exaggeration but it's a bit like that. The other problem is that I ended up using Universal Gcode Sender to sit between PC and grbl. UGS seemed to be the best option at the time I was looking. While it had some machine control features, it was a bit clumsy to use and somewhat limited. That might have changed by now - I haven't needed to look. The commercial options are much better in this respect. LinuxCNC is a halfway house - pretty much the same functionality as things like Mach3 but a full open-source "product". But you do then need to cart around a PC or similar with you, which is why I was looking at grbl. Maybe RPi is the way to go but my aim at that time was to get something working rather than spend ages researching options. I'm sure that this is a developing area, although I have to say that as the open-source aspect is driven mainly by lower-power machines which make less demand on the control system, it may be that the priorities for development will be different in the same way that a desktop skate-bearing machine with a router as spindle differs from a full-sheet router with 3HP spindle. I'm not knocking the former option BTW - my first CNC router was MDF with skate bearing guides and I used that (with LinuxCNC) for the best part of 5 years.

I shall continue to watch the open-source area with interest as I'm sure that there will be some useful developments. For example, there is the stmbl open-source hardware development for servo drivers, and there are a lot of creative "amateurs" out there.

BTW, on the subject of Arduino power - I'm pretty sure that the Uno spec says that it is happy with 7-12V as it has onboard regulation to give 5V for the Atmega chip, etc. I think my Sanguinololu 3D printer controller (that dates me...) uses 12V. I'm in the process of developing an Arduino-based controller for a different kind of machine at the moment, which is why I was looking this up on the Arduino site a couple of nights ago. It may be that the shield does not pass its power to the Arduino purely because its acceptable input voltage range exceeds what is acceptable by the Arduino.