Because the (early batch) CupCake circuit boards are assembled by the customer (me), they’re unprogrammed and the customer (me) has to use an in-system programmer (ISP) to burn the bootloader and then an FTDI USB-serial cable and Arduino development environment to program the firmware. Happily, the prerelease kit included both a USBtinyISP and the necessary FTDI cable, so I was good to go.
I got the bootloader programmed into the motherboard just fine, but I couldn’t get the Arduino IDE to program the firmware into it (and yes, I did install the Sanguino support). The motherboard has a switch to signal the (PC ATX) power supply to turn on and feed all the peripherals; but it’s emphasized that standby power is always provided to the ATmega on the motherboard, so there were no steps needed to power up the ATmega for firmware download. Further, the motherboard power switch didn’t power up the power supply, so I figured it must not be needed yet.
But every time I tried to upload firmware, I kept getting a long timeout and:
Binary sketch size: 15002 bytes (of a 63488 byte maximum)
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
as though the Arduinoness of the motherboard wasn’t there.
Lots of MakerBot forum posts identify the same problem and talk about jumpering the power supply cable to make it turn on.
C’mon, that can’t be for real. The programming instructions don’t say anything about needing to mess with your power supply cable, and that would be a massive omission.
Maybe another look at the motherboard power switch? Switching it didn’t make anything happen, and the schematic for my V1.1 motherboard shows that the power-on signal to the ATX power supply is under the control of Arduino digital pin 14 — a chicken and egg problem.
After about an hour of searching CupCake and RepRap forums, poring over the schematic for anything I might have missed, trying different random things, and generally getting pretty good and angry, I gave up and used Wikipedia’s ATX power supply entry to help me jumper the power supply’s power-on lead. The power supply came on and the motherboard programmed on the first try.
You’re kidding me. This is a necessary step, it causes so much trouble that everybody posts about it in the forums, and it’s still not covered in the assembly instructions? I honestly still think I must be missing something.
Fool me twice, shame on me. When it was time to load firmware on the extruder controller, I found that leaving the USBtinyISP connected from the computer to the PC board’s ISP header is a great way to supply the microcontroller with power for the first Arduino firmware upload.
Yes, by this point the motherboard was correctly controlling the power supply; but this was a handy trick I need to remember.
This sort of thing happens a lot. You design something, document the steps to build it, then add a feature after the fact. Problem is, the new feature changes the build sequence in unexpected ways. It’s likely that the MakerBot folks never went through the assembly instructions with the final version of the board and just assumed that it would still work.
There was a similar issue with the RepRap Darwin instructions where one of the test steps would fail intermittently because of a floating input on the MCU. At the time the instructions were written, that pin wasn’t an input. No one ever went back to verify that the test still worked with the latest firmware.
Steve, I take your point; but it’s dulled by the facts that MakerBot seems to be building a CupCake for their own use from almost every batch and if this is a general problem they must have run across it themselves, and that it keeps coming up in the forums but no one has done anything about it. That’s why I think I must be missing something and it’s not really as simple as outdated/missing instructions.
It’s easy to develop habitual procedures and not think at all about that they’re not documented for others.
Here’s how we avoid this at work.
The first person to develop a new procedure takes notes onto the internal wiki as they’re researching and exploring. When they’ve refined the process, they edit the notes into a set of instructions.
The second time the procedure it done, it’s strongly encouraged to have a different person do it. Regardless of who does it, they follow the wiki instructions strictly, to identify gaps, errors, and other shortcomings. Because it’s a wiki, they correct the instructions on the spot, as they go through.
Every subsequent time the procedure is performed, it’s done by following the instructions, even if it’s routine and commonplace. It’s too easy to get distracted, called away, or whatever, and skip a step; then you deliver something to the customer (in my case, thousands of people who use the university network; in MakerBot’s case, people who build the CupCake) that doesn’t work. For procedures that are totally routine, we may make an abbreviated checklist at the top to streamline things, but we still use at least the checklist.