Heated bed always registers 1c below set temp

So I am new to the TAZ 4 (but not to 3D printing). I am trying to control the printer in software (Simplify 3D and Repetier host) but there is an issue with them waiting to heat up the bed. You see if I set the bed to 85c (per Lulzbot) it only goes to 84c.

The problem with this is that both programs won’t do anything (like print) until the set temp is reached. I let it set 10 minutes after reaching 84 and it never gets to 85. If I set it to 86 it gets to 85 and so on.

I can of course manually bypass this in in Repetier but not Simplify 3D (at least not that I know of). But the point is I should not have to go to those extra steps each and every time. I assume the controller is being cautious about overshooting the bed temperature or something. The hotend does overshoot then corrects itself so why not the heated bed and more importantly how can I fix this?

You can turn that off in S3D as well. It is on the temp tab in the process. That said, you should be hitting your set temp…

We’ve seen this with a couple of units in our fleet, and have a slightly tweaked version of the firmware. I’ll have a link posted soon.

In the meantime, try PID tuning your bed! A guide can be found here: https://www.lulzbot.com/support/fine-tune-your-marlin-pid-settings as well as remove the temperature settings found in your slicing software of choice. If your Gcode file contains the M190 command it will wait until that temp is reached and stabilized for over 10 seconds prior to starting. Removing the line with M190 will prevent that.

Just received a new Taz 4 with Q3 2014 firmware and after making a few successful prints (octopus & phone case) I’m having exactly the same problem with any file sliced with Slic3r or Cura. No matter what bed temperature is set it stops heating at about .6 degrees below the setting keeping the print from starting. Help.

I “think” I solved this issue when using Slic3r. I had read that it was better to have a slightly higher bed and hot end temperature for the first layer so I set the bed about 5 degrees higher and the hot end an additional 10. When I made the first layer and “rest of print” temperatures the same the issue went away (at least for 1 print). After that I switched to SImplify3D as SLic3r was taking a reaaaaaallllly long time on this file http://www.thingiverse.com/thing:19104. Simplify3D takes about 20 seconds (Slic3r was over a half and hour) so I’m basing this on one go.

I got the TAZ4 earlier this month. Life got busy but finally got to play with it on the weekend and I have the same problem. The heated bed never reached the desire temperature. Spend the whole weekend to figure it out. I have never owned or used a 3d printer before.

It was a very frustrating two days but I end up learning a lot. I learn a lot about g-code, eeprom setting, flashing firmware, Slic3r setting, embedded g-code and the configuration.h file. I also found some error in Lulzbot’s support pages.
I wanna share what I learn but please excuse me for a very long post.

The reason why the heated bed never reach the desire temperature is because the PID value for the heated bed stored in the firmware were uncalibrated.

If you are not familiar with PID, these are value that allows the printer to stabilize the heated bed’s temperature. With the wrong PID value the heated will never reach the correct and stable temperature. Not only it has to reach the temperature it has to be stable.

Every Lulzbot is supposed to be calibrated and come with the optimum PID value in the firmware.

One can check the printer’s PID value for the heated bed by sending g-code M304 to the printer
One can also figure out the ideal PID value for one’s printer by doing an autotune.
This is outlined in the following support page:
https://www.lulzbot.com/support/fine-tune-your-marlin-pid-settings
The only problem is there is error in the page in regarding to saving the pid setting in the eeprom which I’ll explain later.

So first I send m304 to my printer and I got the following;
“ok p:20 i:5 d:275”

I then do the auto tune
This is what I got:
“Clasic PID
Kp: 120.89
Ki: 11.05
Kd: 330.77
PID Autotune finished! Put the Kp, Ki and Kd constants into Configuration.h”

Hey!! That’s way different from what’s in my printer.

Turns out the PID value for the heated bed in my printer is the default value for the Marlin firmware.
My printer never got a set of calibrated value put in.

At this juncture of my adventure I did not know how to flash a firmware or know anything about the file configuration.h.

So I follow the instruction listed in the support page and entered the PID value using the m304 follow by m500 assuming I can just store the proper value in eeprom without flashing a new firmware.
Everything work until you turn off the computer. The PID value never got stored in the eeprom. The support page is in error in regards to storing the heated bed PID value in the eeprom.
The heated bed PID values are NEVER stored in the eeprom. It has to be hard code into the firmware configuration.h file.

If one do a M503 to query what’s stored in the eeprom, one will find out only the extruder PID values are stored in eeprom and not the heated bed PID values.

That took me a full day to figure out!!! :cry:

So next thing I have to do is to figure out how to flash the firmware.
Lulzbot have a support page for that:
https://www.lulzbot.com/support/re-flashing-your-3d-printers-firmware

i do play with arduino so I have no issue with installing and using the ide. I also find out according to the support page that version 1.01 has to be use.
No luck with the 1.01 version downloaded from the lulzbot site. Keep getting compiler error.
Turns out I need to use a new U8glib libraries for the arduino ide. It is actaully included in the SD card that came with the printer. I just copy the U8glin library from the SD card and paste into the arduino library folder and voila it compiled and I was able to flash the firmware.

Also if you search hard enough in their website there is two version of firmware for the TAZ4. One is the 2014Q2 and the other the newer 2014Q3. The only difference after comparing the two is the value for the setting of the Z-axis and Extruder. Anyway both firmware did not have the correct value for my version of TAZ4. I have to manually put in the correct value listed in the paper work that came with my printer.

I also find out why if you use slic3r that it takes forever for the print to start or never start if the PID value is off. If you set bed temperature in the filament setting to a certain value than slic3r will send the following embedded g-code:

“M190 S90 ; wait for bed temperature to be reached”

The print will not start until you can pass this line.
The printer will wait until the bed reach the correct temperature and stabilize for 10 secs before it goes to the next line of the code.
If the PID value are not the right one than obviously it won’t work. Even with the calibrated PID value set in the firmware it still take one to two minutes for the temperature to stabilize once it get within 0.2 degree of the set value.

One way around it is to set all the temperature setting to zero and preheat manually through the LCD or Pronterface. No embedded g-code will be sent and the print will start immediately you hit print. Just make sure the extruder and bed are at the right temperature before you start. You can adjust the temp down manually after the first few layers are print.

Sorry again for the long post.
I have posted a lot of information and please feel free to ask if you need any clarification.

BTW if you have Netflix don’t miss “PRINT THE LEGEND”

Ken Lam
Mentor
Team FRC4719
FIRST ROBOTICS Western Canada Regional Champion 2014

Thanks for the info on the heated bed PID not being updated through EEPROM. We’ll update the guide to state the need to change the heated bed PID values if updated in the firmware.

An updated link on installing firmware for the TAZ and other printers can be found here: https://ohai-kit.alephobjects.com/group/firmware-flashing/

We’re moving guides out of the original format into an easier guide/assembly documentation system, OHAI-Kit (Open Hardware Assembly Instructions), found here: https://ohai-kit.alephobjects.com

Thanks!

I encountered the same issue - at higher temperatures, the bed temperature approaches but never reaches or exceeds the set point. The heater is obvously capable of reaching the setpoint, because it had no problems when the set point was changed to a higher value.

I had updated the firmware as part of building my KITTAZ, so there may or may not have been different PID values before I started. It is now whatever was included with version of Marlin I had downloaded. (bedKp=20,bedKi=5,bedKd=275)

The integral term for the PID controller is the most interesting and relevant here.

  • The proportional term will tend towards zero as the actual temperature approaches the setpoint
    The derivative term will tend towards zero as the actual temperature remains stable
    The integral term SHOULD slowly increase as the actual temperature remains below the setpoint

With a Kill-A-Watt meter monitoring the power consumption, I could see the inital surge of power draw to heat the bed up (~340W) had dropped down and hovered around ~140-180W. This was actually when I realized it was using some kind of PWM control, and is a clue.

So - try tweaking some PID variables. I cranked the proportional and integral constants, and set the derivative to zero. It reached setpoint - but still didn’t quite behave as expected (I expected a very unstable control system).


Looking into the code -
For reference consider the #define MAX_BED_POWER 206 - limiting the PWM time to the bed to 206/255 counts.
The actual PWM time requested by the controller is the summation of the three variables, and is bounded by this value.

In my case, I wanted a bed temperature of 110C - and it was hanging out around 108C.
The proportional term works out to 20 * (110 - 108) = 40 (40 of 206 maximum possible counts)

Since the temperature never reaches setpoint - the integral term should count up to infinity, unless it is bounded somewhere. Turns out that it is

  • temp_iState_max_bed = PID_INTEGRAL_MAX / bedKi = 70/5 = 14 for the defaults

The corresponding term for the controller is iTerm_bed = bedKi * temp_iState_bed - maximum of 70.

Derivative term should tend to zero with a roughly steady state actual temperature.

So - for a 110C setpoint, the PID controller should be calling for (70+40)/208 = 52% of maximum allowable heater power.
Which aligns with the power draw measurements and is, by observation, not enough to overcome the heat transfer to ambient.

Give the integral term more authority - either by increasing the coefficient, or by increasing the maximum limitation it can do.


The one-liner change I made:
Change
#define PID_INTEGRAL_DRIVE_MAX 70 //limit for the integral term

to
#define PID_INTEGRAL_DRIVE_MAX 140



It’s not tuned, and not super pretty, but it works.

It is possible that this upper limit might interfere with the assumptions that go into the calculation of the PID autotuner. Speculation only - I didn’t actually look at that routine.

This change will also affect the behaviour of the extruder temperature control.


During ongoing tweaking, I did end up using M301 and M304 commands to bump up the derivative coefficent to try to reduce the intial overshoot a bit.

I was having this same issue. I followed Iamk’s advice a couple posts up, and now everything is working beautifully! Thanks!

Glad to hear.
K Lam

Has anyone looked at changing the code to save/load the bed PID settings from EEPROM?

The code in ConfigurationStore.cpp looks like it would be easy to do, but I don’t see any comments on if there is extra EEPROM space for the additional three values.

Once you send the gcode command to set your PID settings you can send the M500 command to save the updated PID settings to EEPROM.

I’m not finding that to be true for the bed heater PID settings.

I send M304 P178.76 I20.06 D398.33 to set the bed PID settings, send M500, wait, power cycle and then issue a M304 and I get back the old settings.

Inspecting the firmware source (both from Lulzbot and the main GitHub repo), the variables that contain the bed PID settings are never used outside of the temperature code. The PID settings for the extruder are loaded and saved from EEPROM, but I don’t see any code loading saving the bed PID values.

You can always set the desired PID temps in the Configuration.h file of the firmware and reflash, or just add the bed pid temps to your start gcode.