MakerBot Industries

Solution was to delete the .replicatorg folder in my user folder and have it recreated when repg started up again. Was then able to update like normal to the firmware I needed.

Hello! I can upload the V3.0 to my V2.6 extruder version sucessfully. However, I met a new problem about V3.0. I find this v3.0 version can not work with my machine. The version i upload is "v3.0 for stepper extruder w/ relays", As long as i connect to the power supply, the leds on extruder driver board will keep on lighting, so my extruder motor can not move.
In a word, if i upload the V3.0, the extruder motor could not move , but the V2.6 is no problem. I have tried it many times,I don't know why this happen.
Any suggestions would be greatly appreciated!

Yea ran into this problem also. Looks like you need a gen4 motherboard in order to use the 3.0 firmwares. My firmware installs but the extruder would not work during build and the interface in the control panel was not able to run it manually.

There was another thread on this forum about this issue with some tips but I cannot find it at the moment

Thank you for you reply! So you also think the V3.0 has a bug in G3? I have tried this many times and also being "insane" by this problem. I also tried to look into the source code to find out the bug, but i can not find it yet. I don't know if anyone have the same problem.

Look, it's not a bug in the code.
Very simply, we have a couple of points of failure.
#1 is the FTDI usb to serial port driver
#2 the flashing program is actually avrdude located in the tools folder of the replicator-g
#3 the arduino itself must have a WORKING bootloader that emulates properly the STK 500v2 protocol for flashing
#4 there is a often hidden folder replicatorg in the documents and settings folder of the user logged in that contains the firmwares. Incorrect permisions or other issues can affect this.

Almost every time, simply using my Adafruit USBTiny and Arduino IDE to reflash the bootloader solves the problem. It's to the point I think everyone should have one if you even think about touching a Makerbot in the long term. Best $22 you will spend
http://store.makerbot.com/usbtinyisp-avr-programmer-kit.html

Again, understand it really has nothing to do with replicator-g and EVERYTHING about the bootloader and avrdude.
http://www.ladyada.net/learn/avr/avrdude.html

Also, you can install another GUI such as AVR-Burn-O-Mat
http://avr8-burn-o-mat.aaabbb.de/avr8_burn_o_mat_avrdude_gui_en.html
You need to point the avr dude settings at the files located in the tools folder of replicator-g, then ensure you have the STK500v2 protocol and serial port chosen. Those setting require you close and reopen AVR-Burn-O-Mat to take effect.

Again, I want to be clear your frustrations are not the fault of the board-but rather the very open source microcontroller base we use or AVR in general. Anybody using AVR runs into this occasionally.

Also, not clear but I was trying to elude to it is that you can delete the replicatorg folder in the documents in settings/"your name"/ folder causing rep-g to re download the latest versions and possibly "fix" your issue.

Almost every time, simply using my Adafruit USBTiny and Arduino IDE to reflash the bootloader solves the problem.

Could you post a list of steps on how to do this? I just put together my kit from adafruit and am not sure how to proceed. I have tried all the other suggestions in this thread.

Thank you,

TOm

To flash the bootloader is just way too easy.

Step 1 install Arduino (the IDE Integrated Development Environment)http://arduino.cc/en/Main/Software
Step 2 install the driver for the USBtiny
For windows, we use a modified LibUSB driver. You can download it here:
http://www.ladyada.net/make/usbtinyisp/download.html
•Windows USBtinyISP driver built with libusb v1.12. The windows binaries below are built for this driver. If you want to use the latest WinAVR use this!
•If you are using 64 bit windows Vista or 7 (or you're just plain having annoying problems with the driver above), try the Windows 7 x64 bit driver. You'll still need to click the button taht says "install anyways" when it complains its not verified.

Step3, Connect the USBTinyISP
Unplug all wires going to the EC board. Ensure the jumper on the USB tiny is set to POWER the board (jumper over the 2 pins on the USBtiny)
Plug in the USBTinyISP and connect the 6-pin ISP header to the board. Do not use the 10-pin header. The 10-pin connector on the extruder is for the quadrature encoder, not burning firmware!
You should no see at least the 5 volt LED light up on the EC (Extruder Controller) board.

Step4 Start the Arduino software. From the Tools>Board menu, select "Arduino Deicimila, Duelminove, or Nano w/ Atmega 168". Then, from the Tools>Burn Bootloader menu, select your ISP programmer (USBtiny). The Arduino software will begin to upload the firmware. Ordinarily, this will take two to three minutes to complete, so be patient.

Again from Adafruits site for the USBtiny
There are two LEDs, a green one near the USB port and a red one near the cables.

The green LED indicates that the USB connection was sucessful. If the green LED doesn't ever light and you're sure its in right, there was a problem with enumeration. If you're using a Windows or Linux machine and the green LED does not light up when you plug it in, theres a problem. If you have a newer Mac OS machine, try sending it commands via avrdude - the LED should light up then (strange but true!)

The red LED indicates that the USBtinyISP is 'busy' programming. You probably don't want to unplug it or the device being programmed while it's lit. However, if there's a software crash the LED may remain on even though its not doing anything.

When you're done, you'll see the "debug" LED on the board flash periodically.

NOW you should be able to use replicator-G to upload the firmware normally after you unplug the USBtiny and plug in your FTDI cable

Thanks for the walkthrough. Everything went great up to the debug light blinking. However I can still not update the firmware. I have tried using Burn-o-mat to see what the console was saying. it's just :
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500v2_getsync(): timeout communicating with programmer
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
avrdude.exe: stk500_2_ReceiveMessage(): timeout
etc.

not sure what to do.

looks like I was able to update the firmware after a reboot. It seems windows 7 has a real problem releasing com ports once a program that uses one is closed.

thanks again.

Tom

Cool, Glad it worked. Quick tip-to release com ports-unplug the uSB and restart the application (Arduino IDE, AVRdude, or AVR Burn-O-Mat). Easier than rebooting Windows.