Pleasant Hardware

February 17, 2015 by Zaggo

Ohm’s Law

Recently I had to flash another batch of my Zaggometry Adapter. Of course I did it with my PleasantMill flash tool setup.

It had been a while since I last used it, so it needed re-adjusting of the zero position. In order to do this, I put a panel of Zaggometry adapters on the mill’s table and lowered the programming tool to a height of approximately 1mm above the chips. Then I used the mill’s positioning joystick to bring the programming tool directly above the first ATMega.

So far so good.

Then I lowered the tool further down until the tool’s pogo contacts touched the chip’s pins. I manually tried to start the programming procedure. The plan was to see if the flashing procedure worked, and if yes, to set the mill’s position display to (0,0,0). Well, the positioning seemed to be slightly off, so the flashing procedure reported an error right away.

And then the (two) mistake(s) happened: Instead of either moving the programming tool back up (and to recenter it further) or at least to disconnect the programming tool from my computer, I had a brilliant idea how to improve my controlling software for the PleasantMill. I quickly opened the development IDE and checked the source code. After 2 or 3 minutes, I figured that my idea wasn’t that brilliant after all. So I went back to set the zero point of the programming tool and moved the tool head on the mill upwards.

To my surprise, not only the toolhead moved away from the board, but also the ATMega.

Apparently, the power pin of the programming tool had shortened out to some ground pin when I lowered the tool on the chip. And leaving this all in place for a couple of minutes had produced enough heat to de-solder the chip (and melt parts of the programming tool):

I wondered, how much power was involved, so I checked the data sheet of my Macbook Air:

The USB3 port of my 11″ Macbook Air seems to be able to deliver 900mA. So my “automated desolder head” had a power out of

P = V x I = 5V x 0.9A = 4.5W

Obviously, this seems to be enough to reach the 300-350°C after 120 seconds. However its not easy to calculate this, right?

Interestingly (and luckily), all this didn’t damage any involved electronic. The Macbook Air, it’s USB port and also the USBtinyISP adapter still work. Only the (partly) melted programming connector was KIA (well, all the pogo pins still work, but I’m not sure if their alignment is still correct). In fact, after switching the programming connector to a spare one (I had laying around, fortunately), I was able to continue the flashing procedure.

Even more interestingly (and probably luckily), even the de-soldered ATMega survived the procedure. After soldering it back on the PCB, I was able to flash the firmware and it passed all tests afterwards.

February 10, 2015 by Zaggo

Cutting the Red Wire

I need to cut about 1000 pieces of wire of about the same length (5.5cm). So I built this “quick and dirty” contraption to do the job for me:

I’m not sure if it would have been faster to cut them by hand, but it definitely wouldn’t have been so much fun. Also, I doubt that cutting the wire manually would result in such nice uniform lengths. Finally, I might need even more wires in the future and I know I’ll be very happy to be able to pull this thing out of the junk box again.

The wire feed and the cutter action are both driven by their own DC motor (RB350050-0A101R gear motor). The motors are driven by an Adafruit Motor shield, I found in my parts box. The shield (and the motors) are powered with 12V from my lab power supply.

The cutter action has one end stop for the “open” state. When cutting the wire, the motor pulls the upper grip down for a “hand tuned” amount of time and then opens the cutter again by running backwards until the end stop is reached. The feeder motor is driven for a fixed amount of time with no feedback loop at all. The rollers on the wire feed are cut pieces of a plastic wine cork…

The whole thing is controlled by an Arudino Duemillenove with a little Arduino sketch, using the Adafruit library for the motor shield:

#include <AFMotor.h>
int switch_pin = A0;
AF_DCMotor cutterMotor(4);
AF_DCMotor feedMotor(1);

void setup() {
 Serial.begin(115200); 
 Serial.println("I'm cutting the red wire!");
 pinMode(switch_pin, INPUT_PULLUP);
 
 // turn on motor
 cutterMotor.setSpeed(255);
 cutterMotor.run(RELEASE);
 feedMotor.setSpeed(255);
 feedMotor.run(RELEASE);
}

int count=0;
int wanted=290;
void snip() {
 // Cut
 cutterMotor.run(FORWARD);
 delay(800);
 // Release
 cutterMotor.run(BACKWARD);
 while(digitalRead(switch_pin))
 delay(1); // Until the upper endstop is reached
 cutterMotor.run(RELEASE);
 
 Serial.print(++count);
 Serial.println("pcs");
 
 // Stop when the wanted number of wires is cut
 if(count>=wanted)
 while(true);
}

void loop() {
 
 // Feed the wire
 feedMotor.run(FORWARD);
 delay(630); // The wire length is determined by this delay
 
 feedMotor.run(RELEASE);
 
 // Cut it...
 snip();
}

July 10, 2014 by Zaggo

Pleasant Flashing

For a project of mine, I need to flash several hundred of ATMegas.

I use a special programming connector, which sits on the SMD chip and connects directly to the ISP and power pins on the chip.

My first attempt to ease the flashing process was to mount the programming connector to a lever with some additional weight on it. That way, once the connector was in place, I didn’t need to hold down the connector manually during the flashing process.

The PCBs come in panels of 40 (10 x 4 PCBs per panel) with milled slots in between each PCB. So to make the positioning of the PCBs under the connector a little easier (and more repeatable), I put two metal pins (with the same diameter as the milled slots) on the base of the lever.

The whole thing worked well so far, but since it takes ~~about a minute or so~~ [Update: after changing some default settings in avrdude, the time to flash a chip is down to 15 seconds…] to complete the flash process for each chip, it was still an annoying job to flash several hundreds of them: Position the next chip on the pins, lower the lever with the connector, start the flashing script, wait a minute for the flashing process to finish, lift the lever, position the next chipon the pins and so on…

—

With the standardized PCB panels, a Pleasant Mill on hand and some custom coding, it should be possible to completely automize this process, right?

Right!

After removing the spindle from the mill, I needed some kind of retainer for the -more or less- irregular shaped programming connector. The only regular shape on the connector is it’s square footprint (about 10x10mm) at it’s lower end. So I designed a simple bracket with mounting holes for the mill on its back and a square hole for the programming connector on its base. A clamp on top of the programming connector hold it in place when it is pressed onto the chip during the flashing process.

I printed both parts on my Mendel and mounted the programming connector on the mill:

To hold the PCB panel in place, I put four metal pins (with the same diameter as the milled slots in the panels) in the base plate:

With help of these pins, the panels can be changed quite fast and easily with very good repeatability of the panel’s position.

Finally, I needed some software to control the whole thing.

Fortunately, I wrote a very simple app some years ago to send gcode over the serial port of my Mac. Originally this app was written for the SphereBot but later slightly changed for use with the PleasantMill.

I added a button (to start the automated flashing) and a text view (for protocol output) to the GUI and finished was the PleasantFlash software :)

Ok, I still needed to code some functions for synchronously send the gcodes to move the programming connector in the correct position, execute some “avrdude” shell commands, pipe the shell output for verification back into the app and protocol the whole thing accordingly. But all this was more or less straight forward and done in about an hour.

Of course, the code is hacked together without much care to be user configurable. The paths to avrdude, the program files (.hex) and the fuses are all hard coded in the source. But since I use this setup only for this one project in the foreseeable future, I guess thats ok. And if I’ll need it again for another project, the sources are changed easily enough…

[Update:] After changing a default setting in avrdude (“-B 1”), flashing a chip takes only about 15 seconds now. This means, that flashing a complete panel of 40 PCBs takes only about 10-12 Minutes!

And here’s the Pleasant Flash at work: