Hello,
Recently I flashed some firmware for my taz 3.1 through CURA since it got streamlined…
Now when I try to flash something with Arduino again, it appears that it uploads the sketch but when I restart the printer, previous firmware is still in.
Trying to modify some firmware parts for my hexagon hotend. Since lulzbot firmware for TAZ 3.1 with hexa is not working for me
I have the same issue on my Taz 2.1. Although, I have never used Cura to flash.
I spent an hour or so on the phone with Claudio at Lulzbot a few months ago… He couldn’t figure it out either. Arduino would go through all the compile and upload steps and, seemingly, finish successfully but the settings were never saved in the Rambo firmware. His final suggestion was to make changes in the Arduino IDE and compile. Then, find the hex file Arduino outputs and flash it with Cura. I haven’t needed to make any changes since then but I am sure the problem still exists.
Another option would be to contact Ultimachine and see if they are familiar with the issue.
Could you tell me of those changes in the Arduino IDE that you needed to do? I am bringing a programmer over to take a look at things.
I am going through a mini hell to modify the firmware for my hexagon hotend…
I seem to be getting too much power and speed in z axis with new firmware they keep giving me. So I was thinking to compare stock and new, and change step by step. This way I would maybe find put in which code line it gets excess power. But for that I need to flash my test firmware several times
Thank you so much your answer shortens my road…
It would not save any changes made in Arduino to the Rambo. At that point, I was just updating my Z drive to Taz 4 lead screws so I was able to change the steps per mm from the printers control panel. Claudio was also wanting me to update the micro-stepping values in config.h or possible another file but we were unable to do that.
I had previously changed from the budaschnozzle to an E3D V6 and successfully changed and saved the thermistor type via arduino but, now I am stuck. If I make any changes that require a firmware flash, I am stuck. Like I said before, I have not tried to grab the hex file generated by Arduino and flash it with Cura. That is my only hope aside from contacting Ultimachine.
Please post a solution if you find it!
Ok, so things worked out for me somehow…
This is how it went-
maybe you can relate
When I had started to temper with hexagon hotend in the same time lulzbot have told me they plan to make it a stock tool head. So I waited a bit for their firmware to develop. At some point they gave me pieces of code to insert into stock. Nothing special just regarding maxtemp, thermistor, and for bang-bang mode. I was to flash it with arduino, since Cura wasn’t out at that time.
Then I got busy for a few months, and when I got back, they’ve streamlined flashing with Cura so I was not to bother myself with patching the code up.
Then they gave me the wrong code.
My lulzbot is TAZ 3 and I had got the .hex file for TAZ 5. Of course I didn’t notice…untill I’ve seen my prints being squashed, that is, because of the wrong Z movement.
That was the key moment I was sure this whole time!
We’ve been through all the hardware tweaks and zip ties… then we wen’t to LCD and made some changes in VmaxZ variable. We hit “store memory” (epiphany moment)
After that a month of hell became. Flashing the supposedly correct firmware for TAZ 3 with hexagon hotend; not understanding why Z axis makes noise and extra speed and overshots; flashing stock firmware-everything works fine; flashing hexagon firmware again- the noise is back;
Then I got an idea to flash with arduino, just those slight changes in stock firmware they gave me in code, so long ago. I wanted to see piece by piece where was the mistake.
I followed their instructions for which, among other things, they had told me to update my arduino version from 1.05 to 1.06 (another epiphany moment)
After that, I wasn’t able to flash with arduino anymore. It seemingly, like you’ve said, compiled and uploaded to the printer. But it actually wasn’t. When my programmer friend took a look at the compiling process with 1.06 arduino, he noticed that it wasn’t finishing and that it was giving some error in “wiring”, whatever that meant.
Then we reverted to 1.05 stable version of arduino (not 1.05 -r2 from the website, but the regular one here-https://code.google.com/p/arduino/downloads/list)
I was able to flash with arduino again!
Shortly after that, I accidentally took a look at my LCD to check the motion section (about my Z issue) because I got desperate. There I saw that Z steps per mm went to 1600 rather then 800 what should be on TAZ 3. Then I realized that when we had hit “store memory” after flashing TAZ 5.hex file, it saved those steps per mm.
Funny thing is that no flashing overrode that. That means that lulzbot keeps configuration files separate from firmware. Which is rather useful but it got me in trouble because I did not know. Funny nobody thought of that…
So a long post from me, but I had to release the whole thing in order to make clear the steps and their sequence, if someone ever experiences something similar.
nopick, keep mind on those Arduino versions for your printer. Maybe you need the specific original one you had used when you bought it! It worked for me
Hmmm. I think I have 1.05 installed since that is what the Lulzbot site says to use… It is possible another version is there for some quadcopter work I did. I will double check the version.
Thanks!
I am having this problem now. My arduino compiles and uploads the firmware to the Taz 5. The Taz 5 reboots and then nothing changes.
Are you folks saying you can’t update any parameter in the config.h file and reflash? e.g. I can’t get esteps to change by altering it in config.h I have to change it on the taz screen and then store memory?
I also can’t get things like default temp profiles to change either?
This is a really strange decision if true. But I suspect I am just not able to get the taz 5 to accept the new firmware. Besides how do I verify if other parameters have changed that I don’t have access to from the lcd screen? e.g. PID’s for the bed heater?
Do I have to revert to 1.05 from 1.05 r2? That’s odd because it used to work. I am wondering if it’s computer related. My next try will be connecting a different computer to it and seeing if that has an effect.
ps
I also tried flashing the hex file from arduino through cura and it still had no effect!
To be honest i have not read the hole thread. But if you flash a new firmware to change parameters that are stored in eeprom like esteps,then you have to execute some commands after the update. During startup,the firmware loads the old values from eeprom,not from you new code. That’s a normal behaviour. You have to load the defaults from your code, then store this values to eeprom. I have to look for the gcodes…
Edit:
Ok thanks that’s what I’ve been missing all this time I guess. I always assumed whatever was in config.h is what would get stored.
So basically any variable that I alter in config.h requires a M502 and an M500 after flashing to take effect? Or are some values changed immediately? There are many variables that are not editable at the LCD screen. Do those require M502 and M500 after flashing to change as well?
You need M502 & M500 for every variable that is stored inside the EEPROM. You can look inside “configuration_store.cpp” to see which one is stored.
The PID for the Bed heater is not stored in the E-Prom. That you change in the Arduino IDE and upload with the new code.
That’s what threw me off a little because I suspected some of the new values I was entering in config.h were being used so it was confusing that others were seemingly ignored. I can see why they did what they did, I just always assumed a reflash would take everything back to whatever the firmware had in it.
Thank you for the help.
The PID for the Bed heater is not stored in the E-Prom. That you change in the Arduino IDE and upload with the new code.
That depends on the Marlin version. If you update to the latest release, also the PID for all extruders and the bed are stored.
@billyd: If you flash a µController like the ATmega (that’s the “brain” on the board), you are usualy never overwriting the EEPROM. The EEPROM is used to store user values, so it makes no sense to erase them with every update. But I agree, a “load default values to EEPROM” option in the display or in the config.h would be a nice thing. 
Agreed. But really it’s just knowing that these values don’t get overwritten in a flash that is the only real hurdle. It would be nice if that was mentioned in the tutorials for flashing your Taz. Perhaps it is I just never noticed it.
Another cool thing I found out from this problem was learning where to find the hex file from arduino which is not super obvious. So now I can create different setups (e.g. for different extruders), compile them into different hex’s and just use Cura to send them, instead of the slower process of recompiling and reflashing with arduino.