In making the mounts for the motors, there's been a few tricky spots to drill holes for. One of the first projects I wanted to try was to make a corner drill. You know... one that can drill around corners.

I didn't realise that under Mach3, an M0 program stop wasn't "terminate", but "pause", and that pressing Run (Alt-R) again would continue on from the next line.

High on the list for the next project is that emergency stop button I should have...

A few years ago low-cost rechargeable drills/drivers hit the market. I purchased a nice GMC 18V driver with two batteries.

It's given good service over the years, but:

• the batteries don't hold as much charge as they used to
• the batteries don't hold their charge as long as they used to
• recently, the "charger" (timer & battery clip) died
• recently, the plug-pack transformer died

The drill itself is perfectly fine, and I've worked around the charger & plug-pack issues, but the time had come... the batteries died completely.

Professional cordless tools often have replacement parts available, but my drill was only a consumer level item and years later, is completely superseded. A number of people have had success rejuvenating cordless tools by "repacking" the batteries. Often, the battery packs for these tools consist of a number of series wired "Sub-C" cells (18V = 15 x 1.2V Nickel-cadmium cells). At $3-$5 per Sub-C, that's $90-$150 for both packs. After making such an investment, a much smarter (and safer) charger would be justified. If the charger is not "smart" (i.e. it cannot detect when the battery is fully charged), then overcharging is likely, which will damage the battery.

With a new 18V drill + two batteries available for AU$99, repacking didn't make economic sense. Armed with the experience from my first, my wish-list was:

• 18V - I like the power from the 18V driver, and want to keep that. 
• Geared - My ungeared driver wasn't fast enough for drilling wood or plastic, but I still need power for driving screws.
• Low self discharge - Sometimes I won't use it for weeks, I want it ready to go.
• Smart charger - If I need to charge a half used battery for use tomorrow, I want to not think about it (and not  damage the batteries).
• No hammer action - Even with the hammer action disabled, hammer drills have an amount of axial play that interferes with accurate bit placement.

Any geek worth his salt knows a little about batteries (phones, laptops, etc): Nickel-cadmium (NiCd) then nickel metal hydride (NiMH) then lithium-ion (Li-Ion) then lithium ion polymer (Li-Poly) cells. The latest professional cordless power tools have started to use lithium-ion (Li-Ion), and in my scouting around I found the Bosch PSR 18 LI-2.

What do I like?

• At AU$250, it's much cheaper than other Li-Ion drills on the market at the moment.
• The lithium-ion battery is only about half the size & weight of comparable NiCd batteries.
• 18V power
• 2 speed gearbox
• 85 percent of the charge is retained, even if it has not been used for four months.
• Charging station is automatically switched off when the battery is fully charged (with no memory effect, these batteries can be recharged at any time without reducing their charge capacity.
• Interrupting the charging procedure does not damage the battery.
• Not a hammer drill (no axial play)

With all the smarts included to prolong the life of the battery, I figure it should give twice the value of a $99 Nickel-cadmium (NiCd). Time will tell...

Spin motor left, spin motor right. Easy enough. The next step is to get positional feedback by mounting an encoder on the motor shaft. Sounds easy enough, doesn't it? But since my motors don't have a shaft on either end, I'll need to add an extension.

Luckily someone much better than me has already done this, and put nice instructions on the web. How hard could it be? It would also be my first real piece of work on the new mill.

It didn't go completely smoothly, but no fatal mistakes were made. A couple of cubic millimetres of material were removed that didn't need too... and a bit of extra glue.

At the end of the day... I'm fairly happy with the results.

In my effort to get BlogEngine.NET running under Linux I've been chasing a few issues...

I had Mono 1.2.5.
Had a problem with HTTP file uploads from Windows based browsers.

I upgrade to Mono 1.9.
Fixed the problem with HTTP file uploads from Windows based browsers.
Introduced a problem with URL rewriting.

I upgrade to Mono from SVN r101230.
Fixed the problem with URL rewriting.
Introduced a problem with master pages in a different path from the content page.

I hacked up System.Web.UI.TemplateParser.cs r101177 with an ugly work-around.
Fixed the problem with master pages in a different path from the content page.
Introduced... who knows what else.

I've got my mill now, and I've had a little play with it.

One of the things I've noticed is the amount of play in the hand-wheels before they move the table. After turning in one direction, the hand-wheel will move back an indicated 0.2mm before they engage again. This means if you're using the markings on the wheels alone, you may wobble about by 0.2mm.

I took a quick measure of the change in distance between the bearing block and the wheel mount during a left to right transition: 0.1mm. The details of how the screw is mounted to the table is hidden a little, so I disassembled it to get a good look.

Screw (with pin), first thrust bearing, the bearing mount, second thrust bearing and hand-wheel mount

It's pretty easy to see where some slack in the system comes from... there is nothing holding this assembly together tightly. It relies on the placement of the pin and pin bores (it's important to keep in mind here that this is a economy Chinese machine, and not high precision equipment).

With the screw released from the table, I measured the movement of the screw against its "nut" on the saddle: 0.1mm.

0.1mm in the nut + 0.1mm in the bearing mount = 0.2mm total.

At the moment I'm not looking to eliminate this movement. I'm just looking to identify it... I just had a wild realization. In talking fractions of a millimeter (mm), it makes sense to use the next prefix - micrometer (µm). I've never dealt with such little units before. 0.2mm=200µm. Microns baby... microns. We're talking about two and a half times the width of an average human hair.

Maybe I'll just shim it with some average human hair...

I've been playing with my little side project, and that involves Atmel AVR microcontrollers. I love the Atmel AVR family because they're simple and compiler friendly. Friendly enough that even GCC supports them... under Windows too (WinAVR). I'm writing some code to generate PWM signals to drive brushed DC electric motors. Now, these great little chips often support built-in PWM generation. In fact, the particular model I'm using supports six hardware PWM channels. Call me a crazy, but I decided to ignore this perfectly good hardware feature and flip the output pins on and off in code.

In doing so, I've got a set of raw output variables which I convert to a PWM structure. When I call the conversion function in my main loop, it works fine. When I call the conversion function from a interrupt handler (connected to a timer), it doesn't update. WTF?

It's the little things in life... hours spent scratching your head about a simple code change. "Hmmm... works here... not here. Okay... Interrupt handler is definitely called."  A trip to AVR Studio's emulator and setting break points on the lines where raw outputs were changed was the key. Quite simply... I couldn't.

When the call that uses these output variables was only within an interrupt handler (and not called from the main body), GCC would optimise away setting (and even calculating) the output variables. My structure was never updated because GCC couldn't see where it was ever used. A similar (non-microcontroller) example is given at over at LinuxDevices.

Adding the volatile keyword to my variable declaration fixed the issue (yay!). Is there a performance impact? Certainly. Enough to worry about? Not yet.

We all want access to our email these days from where ever we may be. Many moons ago, I had a MS Exchange server running Outlook Web Access at home that was exposed to the net. No matter where I was, I could access my box at home.

The problem with this is that you have to maintain your own infrastructure. I'm not sure if I can be bothered... especially that my number one problem is spam. My 30 day spam count is about 1000 messages. My 30 day non-spam count is about 60 messages. Wheat from the chaff, baby.

I was a fairly early adopter of Gmail, and it's number one feature in my books is spam filtering. Numerous other products and services I'd tried didn't come close to the quality of Gmail's filtering. In the years I've been using it, I've only had a couple of false positives. Spam had previously destroyed the usefullness of email for me. Gmail has recovered it.

Gmail recently introduced my number two feature... IMAP. That's right connect your MS Outlook to your Gmail account. You've now got an Online & Offline solution.

GMail's number three feature has been around a little while... "another email address". You can send and recieve email for another domain via your Gmail account. You can add "myaccount@mydomain.com" to your Gmail account, and direct mail to Gmail's servers. Once verified, you can send email from "myaccount@mydomain.com" from your Gmail account. The only catch is differing "From:" and "Sender:" headers giving recipients from descriptors like: "FSmith@gmail.com on behalf of Fred Smith [Fred.Smith@mydomain.com]". I've already had people question it... too confusing for Joe Average.

Here's my setup. My own domain's email goes to my Gmail account.
My machine - 99% of the time: I access my email on Gmail using Outlook via IMAP. Using Outlook I send my email via a separate SMTP server (avoiding the "on behalf of" issue).
Another machine - 1% of the time:  I access my email on Gmail using Gmail Web. Using Gmail Web I send my email (and accept the "on behalf of" issue).

I love Google...

VoIP is one of those great acronyms floating around in IT that is a general idea, not a particular specififcation. The two main ones are the ITU standard H.323 and the IETF standard SIP. I played with a VoIP phone service provider a number of months ago, and you can't argue with the numbers. In this case, I used the Ekiga softphone.

One issue I had is that we're all too used to a phone as a discrete device. We don't want to have a PC running 24/7, we don't want a PC reboot causing call drop-outs, and we don't want to lose the dial-tone reliabilty of standard phone services.

Enter the Linksys SPA3102. It includes my must-have feature: "If power is lost to the unit or Internet service is down, calls can be redirected to a traditional carrier via the FXO interface." I'll never trust my ISP completely.

These units were available for about $95 delivered (beware the ones locked to a single provider). I grabbed mine from Warcom. I like these guys... order one day, on the door-step the next. I've used them before, and probably will again.

I was concerned about the complexity of configuration to get this little machine to work. The configuration pages are pretty daunting. Bravely, I plugged it in, entered the name, password and server from my VoIP provider. Just for kicks, I picked up the phone and rang my mobile. It worked. Damn... it worked. I called back my VoIP number from the mobile... the phone rang.

We'll see after a decent test duration, but in the last few days my call charges are 1/30^th of what I was paying with my POTS provider.

All we need now, is to be able to get the copper pair for our ADSL without having to get a phone service. This has been made possible recently, but the total saving would be about $2 a month. Not worth losing the POTS for.

If you've been thinking about trying VoIP. Dive in... it's not too bad.

Something I read a few months ago, and really did rock my world was The Pragmatic Programmer: From Journeyman to Master. Normally, I consume fairly heavy technical material, and this was certainly a change for me. This book examines a number of traits usually present in "master" programmers, and those traits just aren't highly-technical. It has a section called "Programming by Coincidence" which includes this gem:

"Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn't know why. Fred may well spend a significant amount of time chasing this piece of code around without ever being able to fix it. No matter what he does, it just doesn't ever seem to work right.

Fred doesn't know why the code is failing because he didn't know why it worked in the first place. It seemed to work, given the limited "testing" that Fred did, but that was just a coincidence. Buoyed by false confidence, Fred charged ahead into oblivion."

This described perfectly some developers I'd recently experienced, and I hadn't been able to neatly label the exact pattern. It was great to have it spelled out so simply: "he didn't know why it worked in the first place". Oh, crazy developers...

But, it didn't go away.

I was talking to a friend of mine about some systems engineers at his company. They were unable to determine why IP connectivity was lost when they altered a server's network configuration.  It was the simplest of reasons (multiple NICs & routing) but one they didn't understand because even with a single NIC because they didn't know why it worked in the first place.

This opened my eyes to the reality that there are a lot of people considered professionals (in all fields) that are getting by without understanding why things work. Personally, I think if you're a professional, you should understand why things work.

I'm scared...