Can't turn off Heated Bed after upgrading to .91 (Works fine in .82)

I have been using .82 firmware with my Azteeg X3 and VIKI LCD since it came out. No issues.

Today, I upgraded the firmware to .91 using the configuration tool. I also upgraded Repetier Host to 1.04.

In .82 when I enabled the heated bed in Repetier Host, the LED on the X3 as well as on the Viki LCD would come on to let me know that the heated bed was on. I could also see the temperature increasing and the target temp. Likewise, when I disabled the heated bed in Repetier Host, the LED on the X3 as well as on the Viki LCD would go off to let me know that the heated bed was OFF. I could also see the temperature decreasing and NO target temp.

The extruder heater LED works in the same way.

That is how I expect it to work.

However, with .91 Firmware and Host 1.04 (Windows) I have problems when I click the button to disable the heated bed the LED on the VIKI LCD goes off but the Heated Bed remains on and the LED on the X3 remains on. The LCD shows a target temp of 0. The only way to prevent this runaway heater condition is to reset the X3 via the Host software or by pressing the reset switch.

Normally, with those smptoms, I would suspect a bad X3; however, if I reload the .82 firmware (which, thankfully, I saved) everything works great.

I have compared the PINS.H, UI.H and as best as I can tell they are equivalent.

Am I missing something? Or is this a bug?

I would appreciate any advice you can offer.

Thanks in advance!

Eric

FYI: I made a donation when I first installed.

Edited 1 time(s). Last edit at 09/13/2014 04:12AM by Eric Mack.

---

Azteeg X3 Controller with Repetier Firmware, ViKi LCD, Repetier Host
RepStrap One:"http://www.ericmackonline.com/ICA/BLOGS/emonline.nsf/dx/erics-repstrap-3d-printer-trainer

Ok, the lcd tells you what the firmware thinks how the state should be, so the sending commands all work as expected.

The main problem is, why does the mosfet connected to heater doe snot react on the change. The typical reason is, that some other function is also using the heated bed pin. So the place to look is at is your Configuration.h and check who is using that pin. Maybe the heater is already on before you turn heater on? Or did it only start once you turned it explicitly on?

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Thank you for your prompt response.

You wrote: "Maybe the heater is already on before you turn heater on? Or did it only start once you turned it explicitly on?"

The heated bed is off when I first power up or reset the controller. This condition only happens once I explicitly turn on the heated bed. Once I turn it on, it stays on.

I have examined configuration.h and it looks like the heated bed is using HEATER_1_PIN which, as far as I can tell is mapped to pin 8 in pins.h.

I do not see any reuse of the above pin name in configuration.h so I guess I should be looking in pins.h. There, in the X3 section, I see that HEATER_1_PIN is mapped to pin. So, it "appears" OK.

Your theory that something else may be using that same pin makes a lot of sense - especially if it is something like a fan. Where should I look to find another feature using that pin ? I will start in pins.h.

UPDATE: I have reviewed the configuration.h and pins.h from .82 and .91 to see if I can find what's different. I'm lost. I DO agree with your theory that something else is using that pin but I do not see it. I have attached the Configuration.h and Pins.h from my working (.82) and non woirking (.91) configuration. Perhaps you can see something that I do not.

Eric

Edited 2 time(s). Last edit at 09/13/2014 03:54PM by Eric Mack.

I continue to examine this to try and find the problem.

I have established that the .82 configuration/firmware works for me and that my current .91 configuration/firmware does not.

The problem remains that when I disable the heated bed, the bed remains powered up and the LED on the Azteeg X3 remains on -- even though the Viki LCD LED shows the bed is off and there is no target temperature for the bed.

I decided to conduct an experiment to help me narrow down whether this might be a configuration issue or a software problem.

I edited the configuration.h to swap HEATER_0_PIN and HEATER_1_PIN. This way, when I turn the bed heater I will really be turning on the Extruder and vice versa. I recompiled and uploaded the firmware.

Guess what! The problem persists! If I enable the bed I see that the extruder heats up (because I swapped pins) and the LED comes on. If I disable the bed, I the extruder does NOT power off and the LED remains on. In the same way, if I enable the extruder the bed powers on/off -- as it should.

So, it appears that this problem, whatever it is, follows the code that controls the bed heater.

Any ideas?

Edited 1 time(s). Last edit at 09/13/2014 06:20PM by Eric Mack.

OK, so here is an update and an unlikely solution. I'm sharing this in the hope that it will save someone else the lost time.

Continuing with the above troubleshooting, I observed that:

I could set the bed temp to 1 degree and the bed would turn off, including the Bed LED -- as it should.

However, if I set the bed temp to 0 degrees the bed power (and LED) remained ON.

If I turn off Bed Heater from the host the bed power and LED remained on

If I turn bed heater back on and set the temp to 1 degree the bed power and LED would go off.

I was about ready to document what I thought could be a software issue when I stumbled on something else. I will post that as the next response so people can comment where they like.

Frustrated that I could not get my heated bed to shut off other than by resetting it, I decided to continue with my RepRap calibration. One of the next steps on my list was to calibrate the Hot End and Bed PID settings using the M303 Gcode.

I did that PID Calibration as follows:
M303 S200 for the Extruder Calibration at 200 degrees celcius
M303 P1 S100 for the Heated Bed Calibration at 100 degrees celcius

I tool the last set of each resulting PID settings and entered them into the Repetier EEPROM settings and rebooted the controller.,

Guess what?

The Heated Bed could not be disabled.

SO, it appears that it was not a pin issue at all, but rather a set of PID settings that caused the controller to behave badly.

Posting this here to save someone else the grief and perhaps learn from Repetier.

Thanks.

Great product!

I guess you did not mean

Quote
Guess what?

The Heated Bed could not be disabled.

but

Quote
Guess what?

The Heated Bed could be disabled.

Also I can not understand why. The first test is temp < 20 which turns output = 0 regardless of pid settings, which did not happen for you. It might still be a problem with eeprom values after updating beeing wrong which you corrected while adding new pid values, but I can't see what went wrong. BTW: There is only one temp control for all - regardless if it is a heated bed or extruder. Same function for all.

Anyhow, I'm happy it now works for you.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Thank you for your service and for the awesome Repetier products!

I wonder if it was the new PID or simply the fact that I saved the EEPROM settings (which I had not done after the move from .82 to .91)

So, is the lesson learned here that whenever we upgrade firmware we should open and resave the EEPROM?

If so, could that be automated in some way?

In any case, thank you.

In theory it upgrades with defaults to newer versions. But if some parts wer not enabled or something else I did not notice is wrong eeprom might have unusable values. So it is at least a good idea to open eeprom in host to see if there are some NaN and if values make some sense.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

A good idea would to ALWAYS change the EEPROM flag number EVERYTIME you upload new firmware. This will invalidate the eeprom and make use of the current compiled in settings for the first run.
I wonder if the locations for eeprom values changed from 0.81 to 0.91. That would be a problem if the flag number position was the same between both and other items moved!