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):

IMG_0398

 

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.

Pleasant Flashing

IMG_2801

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.

IMG_2739My 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.

IMG_2799The 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!

IMG_2796

 

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.

retainer1clamp

 

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

IMG_2795

 

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:

IMG_2798

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

IMG_2791

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.

G-Code Sender

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 :)Pleasant Flash

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:

The mill’s soul

IMG_2456.JPGI just published v0.4 of Pleasant Mill‘s firmware on Github yesterday:

https://github.com/zaggo/PleasantMill

As you might guess from the version number, this firmware isn’t finished yet and probably still has some bugs to fix (help’s highly appreciated, BTW :).

As mentioned before, I use a Seeduino Mega and some Pololu A4983 stepper motor drivers.

One recent addition on the hardware side was a 24V/6.3A power supply. I also glued some small heat sinks on the A4983 chips.

Then I increased the current to 1.68A, the max current, the stepper motors (SY42STH47-1684B) are rated for. Driving the steppers at 24V/1.68A enabled me to dramatically increase the top feedrate for the machine (about 1800mm/min instead 600mm/min). Unfortunately, the little heat sinks weren’t enough and the thermal shutdown of the A4983 kicked in after a few minutes. So I had to lower the current to about 1.2A again (and the max feedrate to 1100mm/min).

As you can see in the image at the top of this page, I’m still using a messy bread board for the electronics. As soon as I have the feeling to know the main issues with the whole shebang, I’ll build some kind of Seeeduino Mega shield, of course.

Right now, I plan to put the stepper motor drivers on a separate daughter PCB, somehow integrated in some kind of big ass heat sink.

If anyone knows a good way to cool the tiny A4983 chips on the Pololu breakout boards, please let me know!

The just published firmware release contains code for the G2/G3 commands (arcs) and for several drilling cycles (G81, G82, G83, G85, G89 and G73, see video below).

The drilling cycle commands also recognize the L (loop) parmeter, which is nice to drill multiple holes in a row. Just switch to incremental positioning (G91) and use something like G81 X10 Y0 Z-12 R1 L7 to drill 7 holes along Y=0mm, 10mm apart and 12mm deep. Don’t forget to switch back to absolute positioning (G90) after :)

I also added the M6 (tool change) command. Of course, I have no automatic tool changer (and I don’t really plan to build one). On the Pleasant Mill, the M6 command pauses the G-code processing and displays a message on the LCD, containing the tool number, requested by the G-code program and waiting for feedback from the operator.

For example, the line

M6 T3

results in

IMG_2482.JPG

I even wrote some code to save a “tool database” in the Seeeduino’s EEPROM, so the LCD would say something like “Insert tool: 3mm drill bit”, but this code doesn’t work properly yet.

Both, the drilling cycles and the tool change command are showed off in the following video:

And here’s the G-code, I sent to the machine during the video:

G21
G90
G0 Z3
G0 X2 Y2 ; Simple drilling cycle
G91
G81 X6 Y0 Z-8 R2 F300 L4
G90
G0 X2 Y7 ; Drilling cycle with dwell
G91
G82 X6 Y0 P500 L4
G90
G0 X2 Y12
G4 P1000 ; Peck Drilling cylce
G91
G83 X6 Y0 Q2 L4
G90
G0 X2 Y17; Peck drilling cycle, high speed
G91
G73 X6 Y0 Q3 L4
G90
G0 X2 Y22 ; Drilling cycle, slow retract
G91
G85 X6 Y0 L4
G90
G0 X2 Y27; Drilling cycle with dwell, slow retract
G91
G89 X6 Y0 P500 L4
G90
G0 X0 Y-25 Z19.5 ; Tool change position
M6 T2 ;  Change Tool
G0 X2 Y32
G91
G81 X6 Y0 Z-5 R2 L4
G90
G0 X2 Y34
G91
G81 X6 Y0 Z-5 R2 L4
G90
G0 X0 Y25 Z13.5

I also implemented the commands G54 to G59. Each of these commands switches the machine to one of 6 “work coordinate systems” (WCSs). These are 6 user defined “zero positions”, saved in the machines EEPROM.

To define a WCS, use the “Jog XZ”, “Jog Z” and “Jog AB” functions in the mill’s UI (“Cartesian”) to move to the desired position. Then choose the menu command “Set WCS” to save this position in the EEPROM. You also can view already saved positions with the “Show WCS” command.

When writing G-code, you can then use one of the commands G54 to G59 to load the previously saved positions as zero positions.

In order to get the whole WCS stuff working, you need to “home” the machine once (either by sending the G28 command or by choosing “Find home” from the Cartesian menu in the UI). This is necessary to give the firmware an idea of the machine’s absolute zero position. If you try to save a WCS position in the UI or to use G54 to G59 without homing, an error is displayed.