## Monday, 18 June 2007

### Disaster, frustration, success, disaster

Not posted for a while because I couldn't get the I²C link between my main controller and the spindle controller working. Before that I had a minor disaster when I crashed the drill chuck into a block of plastic. It appears to have bent the shaft out of true as the tool runs a little eccentrically now. The drill was made by Minicraft but they seem to have gone out of business. This made me realise how precarious it is to make something out of surplus components and things you have to hand rather than readily available parts. If I break anything then it might be impossible to get a drop-in replacement. Something like the $4000 XY table I got for$400 would be virtually irreplaceable.

Fortunately the drills seem to crop up on eBay fairly often. I got one almost identical except that it has a collet chuck rather than a three jaw one. It seems to have a bit of end play but this appears to be due to the bearing being loose in the housing rather than having play itself. I should be able to fix it with glue or shim it with a washer.

The I²C problem was a nightmare. I could get it to work if I stepped through the code at either end but not if I ran it. I was fairly sure the software was right because I had used the MSP430F2013 code before on a very similar device and it was based on an app note. The code at the MC9S12NE64 end was a translation of some code I used recently on a Coldfire which seems to have an almost identical I²C module. Not surprising as they are both Freescale devices.

Obviously it was a timing issue but all the timing should be done by the hardware. I am only running it at 100K baud and with 1K pullup resistors over 4 inches of cable I should have no problems. Looking round the Web I found an errata for the MSP430 which seemed to have lots of I²C bugs in the B revision of the chip with no workarounds. Mosts of these are fixed by revision C but my chip seems to have an X where the die revision should be.

Because the problem manifested itself as a lockup it wasn't possible to get a repetitive signal to look at on my analogue scope. I decided I should really have a digital storage scope for these types of problem so I ordered a cheap USB scope front end made in China from a company in the US. \$360 plus shipping for 100MHz bandwidth, two channels, 250 MSps. Not bad if it works and the software is half decent. Most software to support hardware seems to be complete rubbish these days. I have had four PC TV cards so far each with decent hardware but software that is utter crap.

While waiting for it to arrive I decided in desperation to try reducing the clock speed of the MSP430. To my amazement dropping it from 16MHz to 8 MHz appeared to fix the problem. So definitely hardware not software then.

Flushed with success I added a Python function to control the drill speed by sending a command via Ethernet to the main controller which forwards it by I²C to the head controller. This worked fine but as soon as the drill made contact with the tool height sensor for the first time the sensor stopped working. I thought the shaft of the drill was ground but actually it was +12V. Now that the power supplies are linked by the comms cable it stuffed 12V into two of the 3.3V inputs of the MC9S12NE64 and not surprisingly they don't work anymore! In fact I am surprised any of it still works but most of it does.

So, major disaster. It will be very difficult to replace the chip as it is fine pitch surface mount. I do have some spare inputs I could use providing the rest of the chip holds out. I can probably still buy another demo board but its starting to get expensive repairing my mistakes.

Curiously the replacement drill seems to have an isolated shaft. I knew the first one wasn't but I assumed it was ground not +12V. However, it wouldn't have made any difference because foolishly I switched it with a low side driver so when it is off both wires are at 12V!

So now I have to rewire the tool sensor inputs, add some protection and cobble the two drills together to make one good one, preferably using the motor with the isolated shaft. The I²C comms need beefing up a bit with a CRC, packet sequence flag and an acknowledgment / retry mechanism. I also want to add drill stall detection and employ the shaft encoders on the XY table to detect that stalling as well. Hopefully then I will avoid any more costly tool crashes and move on to making the RepRap extruder.