MakerBot Industries

No dice. ReplicatorG has a "Rescan serial ports" menu item and I can confirm I'm using the right port, because it disappears when I unplug the USB cable and hit re-scan, and then when I plug it in and hit re-scan again, it re-appears, and then I select that port when I try to update the firmware. This also reproduces after a reboot of the machine.

If you're trying to update the extruder firmware, you have to physically plug a USB cable directly into that board, not the motherboard. It will have a different USB ID than the motherboard.

Aside: I have a second USB cable permanently plugged into my extruder board so I don't have to open up the bottom to access it for firmware upgrades.

I think I'm confusing people. Here is the exact sequence of events I've followed:

1. Plug in motherboard
2. Scan for serial ports
3. Find the one the motherboard is using
4. Update the firmware successfully
5. Unplug the motherboard from the usb cable
6. Plug the EC into that cable
7. Re-scan for serial ports
8. Find the one the EC is using, which appears to have the same ID as the one the motherboard used
9. Try to upgrade the firmware, to no effect

I've tried rebooting between steps 5 and 6 too, to no effect. Should I try a different cable? I am pretty dumb when it comes to usb-serial stuff.

The sad thing is - it could just be you. I tried and tried to get mine (ours) to update when new. I had supervision too. My young boy watched and we read and I continued to fail. Then I gave up and said - "OK, Mr. Magic. Make this work!" The kid took it. Plugged it in. Punched buttons a couple of times. Got the uploading and success notifications and we were done. - ? - Try a different sequence and timing. Wait longer. When my kid gets home today from school I'll ask him and maybe he will remember what he did.

Fixed, Ethan gave me a new EC.

Well, it's pretty simple-the bootloader on the Arduino has a certain time after pressing reset to connect to the serial port and "act" as the bootloader mode before it begins it's normal routine.

You simply must try different variations of timing on the reset press after you hit upload in the control panel. I hit reset twice-more of a timing thing than the acual number of button presses.

If you get the

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

I've tried everything and it doesnt seem to work. I've got a parallel programmer. If I burned the Makerbot Extruder Firmware hex code as the bootloader through icsp, would that do the same thing as through replicatorg?

Yes, but the better answer is to burn the standard Arduino bootloader to it via the ICSP header, and then try replicator G again. I've done this many times and it works much better.

http://www.arduino.cc/en/Hacking/Bootloader

Also worth noting, the v3.x extruder controller used by the Thing-O-Matic shouldn't need a manual reset button push to trigger the firmware update. Only the motherboard needs a synchronized reset button push.

The Cupcake electronics were the opposite. Getting the extruder controller reset button timing was very tricky; the motherboard didn't need the reset button push.

I have a similar problem, mother board firmware updates but extruder controller will not connect.

No luck. The EC is connected solely to the USB cable and ReplicatorG still says "The firmware upgrade did not succeed." I'm not pressing the reset button when I send the firmware. Is there a trick to this? It seems like there are a lot of people who managed to do it without problems and a lot of people who have tried everything and are still stuck.

Okay, I feel like I'm doing something wrong. I've been at it for a good 45 minutes trying the reset button at different times before, during, and after I hit the upload button. Nothing's worked. This is really frustrating.

Tried from another machine without success.

Okay, so here's what I've tried:

• Disconnecting all cables to the extruder controller except for USB
• Uploading the firmware without pressing the reset button
• Pressing the reset button as I hit the "upload button"
• Pressing the reset button immediately before I hit the "upload button"
• Pressing the reset button slightly before I hit the "upload button"
• Pressing the reset button immediately after I hit the "upload button"
• Pressing the reset button slightly after after I hit the "upload button"
• Pressing the reset button 10 seconds before I hit the "upload button"
• Pressing the reset button 10 seconds before I hit the "upload button" and then again right as I hit it
• Pressing the reset button 10 seconds before I hit the "upload button" and then again a second after I hit it
• Pressing the reset button 10 seconds before I hit the "upload button" and then again a few seconds after I hit it
• deleting the ~/.replicatorg directory and letting ReplicatorG re-download the contents
• …All of this with a different USB cable
• …All of this from another machine

I have to say, this process is thoroughly unacceptable. There are many threads on this forum full of people who have had the same troubles and are given voodoo solutions, none of which are on the wiki, and some of which seem to solve some subset of the issues some of the time. None that I've found have solved my issue, so my TOM is a brick. Does anybody else have any ideas?

During the forum for your issue it reads like you never phoned MBI for technical support. That is a viable and generally acceptable method for a solution. They do have very attentive, friendly and knowledgeable technical support who are into the machines all the time.

Don't hold back - pedal to the metal - goggles on - all windows down!

Call MBI on Monday. Or - actually - AND Fire up the e-mail (moc.tobrekam|troppus#moc.tobrekam|troppus) and send your recent posting listing what you have done to try and correct your issue. Don't forget some vitals like your name, number, bot #, what machine and configuration, your OS, the RepG and SF versions, yada, yada, blah, blah….

Call MBI on Monday and send them an e-mail (moc.tobrekam|troppus#moc.tobrekam|troppus) today.

I've emailed them but they're not open over the weekend. I was hoping that I was just doing something stupid and you folks could set me right, and I didn't want to unnecessarily gum up their support line with dumb questions.

Well this is one more option but man, it's a long process to explain the steps unless you search yourself.
Download AVR burn o Mat which is a GUI for avrdude (the application rep-g is using to flash the firmware).
You gotta configure the burn-o-mat under the avr dude to point at the files in the tools folder of rep-g where the config and exe are located. Restart burn o mat, now choose the programmer type (stk500 v2) and the com port your extruder contoller grabbed (check windows device manager under com ports). Now, browse and find the hidden replicatorg folder which will have downloaded the firmwares as .hex files. Choose one for MB2.4 I meant EC3.6 and the latest version. under the flash option.
now try to flash the thing using AVR burn-o mat.

It a learning experience for sure-so have fun and try not to get too frustrated. Once you figure it out-it will be a great tool to you-just the learning curve is steep.

That program seems like it just wraps the CLI in an ugly interface. I'm quite comfortable with the CLI, and I've tried running the command myself:

$ /Applications/Replicatorg/tools/avrdude -C /Applications/Replicatorg/tools/avrdude.conf -c stk500v1 -P /dev/tty.usbserial-A40080Sv -b 19200 -D -U flash:w:/Users/nate/.replicatorg/firmware/EC-ecv34-v2.8.hex:i -p m168 
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

I tried replacing "stk500v1" with "stk500v2", but then I just get:

avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout

So here's the resolution on this. An electrical engineer friend of mine was kind enough to take a look and he found that there was no bootloader on the chip. As soon as he put one on there, he was able to send the firmware over using avrdude without problems. And that solved the "Toolhead 0: not found" issue!

Good thing you have friends. Do you have a short description how he installed a bootloader?

thanks very much. informations helped me .