Halloween Costume

A couple posts back I wrote that I was working on my halloween costume. Here's the result:

Again, here's the inspiration:

Serial Protocol Testing

I love metrics. Real data that demonstrates the truth (or falsity) of a claim. Try to convince me of something using "anecdotal evidence" and I'll call you out for it.

My new robust serial communications protocol is coming along. In my day job I write "high-level" code working with models of business concepts and logic. It's been a long time since I've gotten down and dirty and worked directly with bits and bytes.

I hinted in my last post that I was going to use a MIDI-like protocol. The first byte has the left-most (MSB) bit raised. This marks the start of the frame/packet. All other bytes in the packet have the MSB cleared. This means each byte holds a "value" in 7 bits. The other 7 bits of the first byte carry the command. I clear the high bit to extract the command, then the next 5 bytes have to be bit-shifted into a 32-bit variable.

All this is pretty easy, really, I just haven't done much of it in Java. I got tripped up for a while because Java datatypes are all signed. Funny things happen when you shift bits left and right in signed datatypes. I learned about two's complement in college but never used it after that. The solution was to work with integers instead of bytes and just waste the extra bytes.

The last 2 bytes in the packet hold a checksum. I implemented a "Fletcher 14" checksum algorithm. I made that up. There's a 16 and 32 bit Fletcher checksum. Since all my data bytes have 7 bits, I can't do a 16 bit Fletcher without spreading it out over 3 bytes and having to do more fancy bit shifting. Probably wouldn't have been a big deal.

So back to the metrics thing. I've never written a checksum before, so I need to know if it works. I wrote a test program to randomly inject errors into the packet. I flipped 1 to 3 bits and swapped bytes in the packet. I ran 1.2 billion iterations with 1/4 billion errors. The checksum missed 47K errors. That's 1 in 5000 errors missed. That's pretty good for a checksum. The computational cost if this algorithm is low so I'm pretty happy with this outcome.

Then I wrote the code to handle the serial transmission of the packets for the Java client (the Arduino code is in C). It's much easier to debug in Java, so I connected 2 Java serial drivers together with a "ManglingInputStream" between them. This randomly injects dropped bytes and flipped bits. This demonstrated that error handling was sound. It would have been pretty hard to write it for the Arduino and throw it into the shop and wait for errors to happen. I'll collect error reports later so I know what the real-world error rate of the system is.

Robust Communications

I experienced a bit of a setback yesterday. I set up to make a test run of the smaller PCB design cut from a block of plaster. I experienced 4 failed runs. 2 failures were due to phantom triggering of the limit switch or E-stop. The other 2 failures involved the machine taking the wrong path.

Electrical noise is a common problem in systems like this. Motors are a great source of "static" to confuse the logic circuitry. This often leads to misreads of switch inputs. The wires I'm using for the limit switch and E-stop are 2- and 4-conductor telephone wires. They aren't shielded. Also, when I am running "programs" (toolpaths from the computer) I power the Arduino from my laptop which is running off battery. I don't think that constitutes a quality grounding of the system. I bought a power supply for the Arduino a little while ago. I'm going to start using it, it might help with this situation. The firmware "debounces" the switches by requiring a state change to last at least 10ms. I can increase this until I can get some better shielding in place. Can't go too high or the machine will pop the switches off and I'll have to fire up the hot glue gun again.

Twice the spindle clearly went in the wrong direction. Off the toolpath that is. The first time it simply bore into the plaster block. Good thing it was soft plaster or I would have lost my $20 0.015" end mill. The other time it ran off the back boundary of the board then came back and went up instead of down. I don't have a real good explanation for this. The only thing I can imagine is data communication failure. I'm using a simple character-based packet for sending a command and a parameter. If a character gets lost now and then this could certainly send things south. With a high baud rate plus all the interrupt handling I'm doing it might not be unexpected to lose one character every five or ten minutes. I have no idea, really, I'm just guessing.

So it's time to make a proper binary communication layer with a checksum. I've done some work with MIDI-like protocols so I'll probably stick with that. MIDI is a single command byte with a 14-bit data portion. The command bit has the last bit raised to mark the start of the packet. All other bytes have the last bit low. Bit shifting will be required to put it all back into 8-bit bytes. I need 32 bits in the data so that's 5 bytes with 3 left over bits. Then I'll add a checksum. I've never written a proper checksum. I'll probably use a simple XOR (exclusive or) checksum. I'm not sure how many bits is good for that. I'll use one or two bytes for the checksum. That's 7 or 8 bytes per packet. That's a lot less than the average character packet for sure.

I'm off to prototype it in Java. I'll start with Java talking to itself. Once that works I'll have half the code I need and then I'll port the solution to the Arduino.

Copper Test Path

I got the micro end mill for the isolation routing. I ran a test on the plaster and it looked pretty good. Well as good as fine plaster routing can look, I guess.

The copper PCB board came in, too. I'm pretty sure the 12" x 12" board represents a life-time supply. I made a sacrificial tooling plate from 3/4" MDF. I faced the top with the fly cutter. I swept the top surface with my dial test indicator to check it for level. It was quite flat but bumpy. The next step was to mount a test piece of the PCB. Flat. That's the hard part, actually.

I don't have a decent clamping mechanism for holding down the PCB. I read how some others have done it. First I drilled holes around the perimeter and screwed it in place with the screw heads overlapping the edge of the PCB. Surprisingly that didn't work. I drilled a couple holes in the board and put in more screws. Still no go. It was fairly easy to push down the corners and see the board move.

Next I tried double-sided cellophane tape. That didn't work. The PCB board appears to have a curve in it, probably just one axis. It's tough stuff, too. It appears it's going to need a thorough, strong clamping or other hold-down method. I read about one person's approach where he uses an aluminum tooling plate and glues the PCB down with CA/Krazy Glue/Super Glue, Cyanoacrylate. Then he uses acetone to soften the CA and remove it from the plate. I'm not real clear how he did the drilling. Maybe he drilled into the aluminum, I don't know.

I haven't had much luck with CA myself, at least not the hardware store variety. Maybe the industrial kind is better, but I never find it "bonds instantly" with much strength. I can't get anything to hold together with it, actually. I went to Lowe's (home center) and looked over the adhesives. I figured the tape didn't work so I didn't want to buy something that wouldn't be otherwise useable. I suppose I could have tried some 5-minute epoxy I already had... Anyway, I decided to give Gorilla Glue a try. Not the "super" variety, just regular GG.

I applied the GG to the MDF tooling plate, sprayed it lightly with water and put the PCB on. I clamped it really well and left it over night. Next day, I swept the surface and found it was much flatter but still had about 5 mils variation. I was pretty bummed at this point. I really didn't expect to have such a problem holding it flat. I decided to go ahead with a test cut anyway.

I set the system up to cut at "zero" depth. It's tough to set the Z height just right, so this was playing is safe. It did cut lightly into the copper on one half and through the copper on the other. I lowered it 2 mils and ran it again. This resulted in a complete cut over the whole path which is really a pretty small area. Here's the result:

The isolation is complete, the edges are clean. I had done a test cut on the red resin material. I don't have a photo because the cut was so clean you really can't see where the lines are. The cuts I did with the cheap conical bit are white on the red because the edges are actually fuzzy.

The Gorilla Glue is pretty good stuff. I thought GG was at least partially CA but it may be that the standard formula is polyurethane only. I put so much on it was clear I wasn't going to soften it with anything. I tried some Goof Off anyway (Xylene formula). Finally I just ripped it off with a chisel. Quite a lot of the MDF came off with the board. This was not going to be a solution for the actual production.

Then I glued a piece of PCB to a piece of plexiglass using much less glue. I clamped it real well and waited overnight again. The 6 or so small drops spread out to cover almost the whole surface. To my surprise a little easy flexing of the plexiglass separated the PCB. There was no glue on the plexi. I tried some nail polish remover (with a large acetone component) to remove the GG from the PCB. I don't think that route is going anywhere.

The glue is on the component side, of course. It makes a nice shiny surface if the coverage is complete. It might not be a problem at all to leave it on there. Maybe there's something I don't know that will lead to trouble. We'll see. Maybe I'll find someone who knows a little more about it.

After taking the above picture I drilled a 1/32" hole in the small pad in the middle and soldered a scrap lead to it. The solder went on nice, so all the questions about isolation width, pad area around drill holes and solderability have all been answered favorably.