Integrate Everything

After killing it, replacing the Atmega 16U2 IC and re-flashing it, our Shapeoko 3 Driver Board Registers on the USB Bus

After killing it, replacing the Atmega 16U2 IC and re-flashing it, our Shapeoko 3 Driver Board Registers on the USB Bus


A few weeks ago while cutting out some wooden letters for one of my Wife’s Christmas present projects, our Shapeoko died. The machine itself appeared to be OK, but it disappeared off the USB bus, and was never seen or heard from again. I tested the traces on the board, and verified pin to pin continuity between the USB connector and the Atmega 16U2 IC, which it’s driver board uses instead of an FTDI or similar USB to TTL Serial converter. Normally when you plug in any USB device to a Linux computer, you see [something] in the dmesg output – even if it has no drivers for the device and in many cases even when the device does not even work. (I recently ran into a case where a USB device kept complaining that it was “unable to enumerate USB device” – but the kernel was still aware of its’ presence on the bus.) In this case, plugging in our Shapoko yielded nothing. Not even the awareness of something drawing power off the port.


I traced out the pins, made sure the zeners weren’t bridged, and I could connect to the 16U2 via the ICSP header (in fact, I was able to save the binary program from it along with all it’s fuse bits!) However, despite all this, it simply did not work. This evening Jeremie replaced the 16U2 with a new one that arrived today from Digikey, I re-loaded the binary programs from the old chip into the new one and voila: The screen shot you see above! Now all I need to do is re-assemble the machine and test it with a real live cut, but that should be peanuts at this stage now that it is alive and well again.


I just love fixing things!


Venturii VDAC MID-1 Rev 2.0 PCB showing version info on LCD Display

Venturii VDAC MID-1 Rev 2.0 PCB showing version info on LCD Display

Today’s news in bullet form:

  • Soldered a second Rev 1.0 board, first “official” test of the multi-drop protocol.
  • While troubleshooting an intermittent communication issue, discovered that the RS-485 transceiver I ordered for the MID-1 project is a 3.3V model, not a 5V. Replaced with an equivalent 5V variant – no difference in comm issue.
  • Studied other designs and reference material, installed a 10k pull-down resistor between A and ground – scope edges became square where they had been ski hills before. Comm issue went away.
  • Two days after soldering up my second Rev 1.0 prototype, the Rev 2.0 prototype PCB’s arrived in the mail. !!! Yay!
  • Testing on the first multi-device comm bus has yielded a new, interesting problem.


The second revision of the VDAC MID-1 board has been assembled and so far it looks like this revision has indeed fixed all of the design flaws and “bugs” of the Rev 1.0 board. That was very encouraging to see so many things work right from the get-go, and this version also includes numerous new features as well. With three fully-assembled MID-1 VDAC’s, I have been finally able to do some proper testing of the multi-drop protocol. The results of those tests have been mixed. Some aspects of it have worked as expected, and I’ve encountered two new problems – one which appears to be in hardware and one which appears to be in software. Since I love to write, teach, and to tell stories, perhaps this new problem can best be explained in a story of sorts. Here goes.


Suppose there are two people trying to have a conversation with each other. Let’s make these people both in the army: one is a commanding officer and the other is a soldier. The commanding officer barks questions at the soldier, and he replies to the commander’s order when spoken to. No trouble with the communication in this situation. This is the same as it is with a single device on the communication bus. The VDAC module software queries the VDAC device, and it replies. There is no other traffic on the bus, so either side can safely assume that anything that is said is coming from the other party.


Now let’s add two more officers into the room. The commander speaks to each officer with a list of instructions. He might say something like, “Soldier A: I have three things to say to you. Thing 1 … Thing 2 … Thing 3.” As long as the commanding officer is speaking to one of the other two soldiers, the remaining two need not necessarily pay attention to the commander. In fact, they could all be working at desks, filling out paperwork or some other orderly task. It is only when the commanding officer calls out “Solder x” that all three must pay attention to ensure that if the commander is talking to them, that they pay attention, focus on what he is saying and then respond appropriately.

Now we enter into the area where my present dilemma exists. During the conversation between the commander and Solder A, the commander (or even the soldier) may actually say something that sounds like the commander addressing one of the other soldiers. This causes that soldier to perk up and start listening, but since it is a “false alarm” and neither of the other two were actually talking to him, he neither does his regular work anymore (because he is trying to find out how many things the commander has to say to him, nor does he actually get what he is waiting for from the conversation in the room – further instructions. Now he is basically “out of sync” with the conversation, and when the commander actually does address him, he is confused and does not reply until the commander repeats the question.


Ok, so it’s a loose analogy, and perhaps it does a better job of explaining my problem than of describing a likely real-world situation. However, it is, in effect what is happening. All three devices start to converse on the bus, but at seemingly random intervals, one of them will simply stop responding. The way the timeouts are set up at the moment, this causes everyone else to wait too in order to exaggerate the problem, and everyone has to essentially time out, clear their incoming packet buffers and the VDAC module has to re-send the last command before the addressed device responds properly. Originally I thought this might be the result of a problem with the hardware, since it seemed to work fine when there were fewer devices (1) on the bus. However inspection of the last packet “sent” to the devices reveals that there is in fact a segment of data sent on the wire that resembles the beginning of a packet addressed for one of the other devices on the bus. Appropriately, it begins to capture the data on the wire, waiting for the correct number of bytes to be received but this quantity is not satisfied. The conversation between the VDAC Module and the (other) device ceases, the VDAC Module now queries the perked up device, but this query too does not fill the required quotient of bytes, so it waits for more and does not respond, so both sides timeout and the module re-sends the query. Having purged it’s listening buffer now, the new message makes sense, is captured correctly and responded to appropriately. However, it is usually only a matter of seconds or minutes before another mischievious packet triggers this mysterious timeout problem again.


Some of the techniques I’ve seen used in other similar protocols include things like having a single, unique start-of-packet byte that no other message could possibly include. I’m not entirely sure that’s possible with this protocol since I want to be able to use the full range of 8-bit characters in the data payload, and there are no characters that are “off limits” to the onboard device types, and indeed some of them make use of all the characters.


One other technique I have seen amounts to using fixed-length messages, which I’d like to avoid if at all possible. The very nature of the VDAC protocol is such that it is very efficient, but needs to be flexible to ensure that efficiency.


Another technique I’ve encountered includes a multi-byte SOP sequence. This might make more sense for my case, although it is still not impossible for a multi-byte SOP to be encountered within the body of a message’s payload.


The solution that might make the most sense is to re-arrange the byte order a tiny bit, moving the checksum byte from the end of the packet to a fixed location closer to the beginningĀ  of the packet. Nope, nevermind – that won’t work either. We can’t effectively compute the checksum byte until the entire packet has been received, and if the packet length byte is [wrong], we’re right back where we started: potentially waiting for data that isn’t coming. Perhaps a variant of this could be used though, computing a checksum of the packet “envelope” bytes: the SOP, address byte, and length byte. If we added a header checksum byte after this sequence, any listening devices could detect early on that something is amiss with the header and discard it early. It would still be mathematically possible for the correct sequence of bytes to be encountered by accident in the wild, but the probability of this would now be exponentially lower. At some point I want to enable devices that share the same comm bus to “listen” to updates from other devices on that bus and use their data as inputs for local operations. For example, it would be possible to set up an analog output on one device to “follow” an anlog input on a different VDAC device by listening to the comm bus traffic and parsing out the bits that are of interest to it. This would require no server or host intervention, apart from querying the bus. Perhaps there could even be an “offline mode” where devices hold an election and choose one device to query the bus in the absence of a VDAC Module.


Anyway, this project is making good progress now, and most of the work to be done now is in the software. There are a few things I’d like to add, fix, or improve but they can all be done in code. This board has come together rather nicely.

A few weeks ago I ordered a three-pack of different-sized collets for the router in the Shapeoko, and yesterday they arrived. One of the things I love about shopping online is that with the delay in shipping sometimes, you can easily forget that you’ve even ordered anything and such was the case this time. When I opened the mail and found this cardboard box addressed to me, I had no idea what might be inside, and was just as pleasantly surprised when I opened it and realized it was something I’d wanted for a long time!

As it turned out, I had been discussing at that *very* moment a Christmas project my wife wanted to do with some letters cut out of wood, much like I had done on the Shapeoko in previous years. With the new collets in hand, I was more excited than ever to give them a try! Yesterday morning I headed out to the garage early in the day to begin dusting off the Shapeoko. It had sat in it’s corner for several months prior to this, having cut all that I needed it to. I had been experimenting with using Inkscape to generate items with pockets – carving out sections of wood with the end mill, and was getting quite good at it. The only problem I kept running into was that the bit would sometimes slip, drop, and then gouge the wood it was trying to cut a pocket in. Hence my delightment at getting the proper collets for the router.

I spent the better part of Saturday working on this, and cutting out letters for my wife’s Christmas craft. They turned out practically perfect, and I was thrilled with the results. I repositioned the wood I’d been cutting from to make one last set, and was positioning the router into place when all of a sudden Carbide Motion reported that it couldn’t talk to the Shapeoko. That’s odd, I thought, but sometimes it would disconnect when the router was switched off, so I wondered if maybe this wasn’t a similar problem. I unplugged the USB cable and plugged it back in. No dice. Power-cycled everything. No dice. Even rebooted my computer. Nothing. It was as if the USB cable wasn’t even plugged in. I checked dmesg – and there was no indication as far as the computer was concerned that anything was plugged into the USB port. It was dead in the water.

And so it sits now. We’ve contacted Carbide to see if they sell the controller separately. I can read and write the Atmega 16U2 chip which is the USB to TTL converter for the driver board, so it seems to be OK, meaning the problem is most likely elsewhere on the board in some other tiny component. When powered from the 24VDC power supply, the 16U2 has power, so that’s not the problem, and there are only four components between the 16U2 and the USB port which all seem to check out, so I am truly at a loss for what might be causing it to not appear on the bus. Wiggling the board doesn’t help, and like I said – it was working fine all day and then suddenly just disconnected. Bizarre. Maybe it is time to consider a controller upgrade as well.


A 3D render in KiCad of the second revision of the Venturii VDAC MID-1 Interface board.

A 3D render in KiCad of the second revision of the Venturii VDAC MID-1 Interface board.

This evening I submitted the second revision of the Venturii VDAC MID-1 Interface board to OshPark for fabrication. I have taken a few weeks off of my day job this Christmas and really hope that these boards arrive during my vacation so that I can solder them up and test them out. They’ve got some cool new features that I think users will like, particularly the DIY crowd.

Some “New” features of this revision:
– This revision should actually work without any mods. šŸ˜‰ I have verified each footprint matches the data sheets of the products purchased and verified that against the schematic and even examples online. It turned out that my understanding of FETs was incorrect and my original schematic had the Drain connected to Ground and the load connected to the Source, but at 12V the 5V signal was nowhere near high enough to turn it on. Also compared against my working Rev 1.0 prototype that was modded. 95% confident that there should be no surprises on this one.
  • OWI (One-Wire Interface) ports now have some cool new features thanks to suggestions from Mark and Jordan.
    • Each OWI port now has it’s own select-able Pull Up/Down 10K Potentiometer.
    • A 3-position jumper selects whether the data pin will be pulled up, down, or left floating, and a 10K Potentiometer determines how hard the data pin is pulled in the selected direction.
    • A 220 Ohm resistor in series with the wiper of the pot prevents the pin from being railed.
    • Ā Because of the Pull Up / Down selection, two status resistors had to be used as the polarity changes depending on which way the pin is pulled. This was FAR cheaper than trying to go to a SMD bi-color LED.
    • The status resistors on each OWI port are enabled with a jumper so that they can be disabled if their load / capacitance causes any interference on the data line.
  • As before, each OWI port can be used to talk to Dallas DS series temperature sensors (IE: the DS18B20), products in the AM230x family (digital temperature & humidity sensors) or can be used as a digital input or output pin.
  • The two shift registers that collect the four Digital Input pins, the four User Interface buttons and the 8 Configuration DIP switches have had their order changed so that the Digital Input Pins and the button register can be read without having to read the DIP switch register, which will reduce CPU load when the DIP switch is not expected to change very often (typically at all.)
  • Many mechanical refinements such as trying to align SMD components wherever possible to aid in the automatic placement thereof, etc.