Marlin: bed temperature readings incorrect

[dbotos]

Ultimaker Original with 1.5.6 mainboard. Bed temperature from heated bed upgrade kit not reading correctly. Efforts to investigate and correct documented here:

https://ultimaker.com/en/community/21256-temperature-sensor-setting-for-ultimaker-original-heated-bed-upgrade?page=1

Thanks,
David

[thinkyhead]

Just yours, or are all of these upgrade kits failing to work with Marlin?

What version of Marlin are you testing with?

What version of Arduino are you using to build/upload with?

[dbotos]

Just mine, that I know of.

Marlin is 1.0.2-1. Arduino is 1.6.0.

[thinkyhead]

Since we aren't patching 1.0.x anymore, can you test with 1.1.0-RC6 or RCBugFix and see whether one of those versions works?

[dbotos]

With Marlin 1.1.0-RC6, bed reads 68.8 °C (ADC value of 286) via M105 command in RealTerm. Actual temperature is ~22 °C. Cura reads 68 °C.

Side note: noticed that pin assignments are now in motherboard-specific files (mine were in pins_ULTIMAKER.h). I also had to change the define for TEMP_SENSOR_0 (first hot end) in Configuration.h, as it was no longer defaulted to -1 (thermocouple with AD595).

[thinkyhead]

If it's a hardware issue, then I'm not sure how you can correct the temperature reading except perhaps making your own custom temperature table.

Try the tool at https://bultimaker.bulles.eu/ and see if it generates a Marlin that works with your setup. If it does not, then it may be that there is too much resistance or some other issue with the AD595, and you could try getting a replacement heated bed kit to see if it works differently.

This article at Instructables might be using a different bed kit. It sets the TEMP_SENSOR_0 to 5.

[dbotos]

The Utlimaker heated bed (at least the one I have) has a PT100 RTD sensor (choice "20" in the firmware - the add-on heated bed temperature measurement circuitry for the motherboard I've got is functionally identical to that on the 2.x motherboard). I've verified that the sensor has correct resistance at ambient. The INA826 amplifier circuit that measures the sensor's resistance is also putting out the correct voltage at ambient. The output voltage of that amplifier circuit is fed directly to the ADC (no 4.7 kΩ resistor). I re-derived the ADC digital values for the PT100 table in thermistors.h from scratch (actually had to correct two rows that were wrong in the downloaded firmware, but those are well below ambient). I also checked to make sure that Vcc was correct (5 V).

I have tried both Ginge's and Bulle's firmware builders with the same results.

So if the voltage coming into the ADC is correct, Vcc is correct, and the table that the firmware is using to convert digital value(s) to temperature is correct, does that just leave hardware as the culprit?

[dbotos]

I have strong doubts that it is hardware. The 1.5.6 main board has three temperature inputs: TEMP 1, 2, and 3 (which correspond to the 0, 1, and BED temp sensors in the firmware, respectively). I've had the bed temp cable plugged into each of the three inputs (with corresponding changes in the firmware to swap ADC pins as needed) and it reads ~70 °C on all three of those ADC channels. Furthermore, the hot-end temp sensor reads fine when I put it on TEMP 3, which suggests that ADC channel being fine.

[thinkyhead]

By "hardware issue" I mean with the bed itself. Your board is probably fine. But the bed's temperature sensor is screwy.

[dbotos]

I've verified that the sensor itself has correct resistance (at least at ambient - 108.8 Ω). I've also checked that it responds in the correct direction to a cold stimulus (ice pack placed on the bed made it read low 60 °C in RealTerm / Cura instead of it's normal low 70 °C at ambient). I suppose I could check resistance at known cold and hot temperatures be removing and placing in the refrigerator and just-warm oven.

Everything so far points to the ADC or something ADC-related in the firmware. What makes me skeptical that it is hardware is that when I swap the hot-end and bed temperature cables (on main board TEMP 1 and TEMP 3), the hot-end still reads correctly on that other ADC channel (the one that the bed sensor's amplifier output is normally feeding), which suggests that channel is fine.

[dbotos]

So just to understand something about the behavior of the firmware: if the PT100 sensor is selected, is it just a straight A-D conversion and table lookup to get the temperature (i.e. no gain and offset applied)?

I'm assuming there are no potential problems with having the hot end and bed temperature sensors being different (thermocouple with AD595 for hot end / PT100 with INA826 for bed)?

I have some plans to test hardware. See Jun 20, 2016 post here:

https://ultimaker.com/en/community/21256-temperature-sensor-setting-for-ultimaker-original-heated-bed-upgrade?page=2

[dbotos]

Well, it looks like it's a hardware issue after all. AREF on the Ardunio 2560 is low, so it's causing the digital values to be artificially high, hence the high temperature readings. See page 2 and 3 of thread on Ultimaker forum for details:

https://ultimaker.com/en/community/21256-temperature-sensor-setting-for-ultimaker-original-heated-bed-upgrade?page=2

https://ultimaker.com/en/community/21256-temperature-sensor-setting-for-ultimaker-original-heated-bed-upgrade?page=3

[thinkyhead]

So, you might be able to just multiply the value you're getting back by 0.87 (4.35V / 5V) to get the adjusted value…? It would be funny if this just worked (for PT100):

#define AREF 4.35
#define AFAC (5.0/AREF)
const short temptable_20[][2] PROGMEM = {
  {   0                      ,    0 },
  { 227 * OVERSAMPLENR * AFAC,    1 },
  { 236 * OVERSAMPLENR * AFAC,   10 },
  { 245 * OVERSAMPLENR * AFAC,   20 },
  { 253 * OVERSAMPLENR * AFAC,   30 },
  { 262 * OVERSAMPLENR * AFAC,   40 },
  { 270 * OVERSAMPLENR * AFAC,   50 },
  { 279 * OVERSAMPLENR * AFAC,   60 },
  { 287 * OVERSAMPLENR * AFAC,   70 },
  { 295 * OVERSAMPLENR * AFAC,   80 },
  { 304 * OVERSAMPLENR * AFAC,   90 },
  { 312 * OVERSAMPLENR * AFAC,  100 },
  { 320 * OVERSAMPLENR * AFAC,  110 },
  { 329 * OVERSAMPLENR * AFAC,  120 },
  { 337 * OVERSAMPLENR * AFAC,  130 },
  { 345 * OVERSAMPLENR * AFAC,  140 },
  { 353 * OVERSAMPLENR * AFAC,  150 },
  { 361 * OVERSAMPLENR * AFAC,  160 },
  { 369 * OVERSAMPLENR * AFAC,  170 },
  { 377 * OVERSAMPLENR * AFAC,  180 },
  { 385 * OVERSAMPLENR * AFAC,  190 },
  { 393 * OVERSAMPLENR * AFAC,  200 },
  { 401 * OVERSAMPLENR * AFAC,  210 },
  { 409 * OVERSAMPLENR * AFAC,  220 },
  { 417 * OVERSAMPLENR * AFAC,  230 },
  { 424 * OVERSAMPLENR * AFAC,  240 },
  { 432 * OVERSAMPLENR * AFAC,  250 },
  { 440 * OVERSAMPLENR * AFAC,  260 },
  { 447 * OVERSAMPLENR * AFAC,  270 },
  { 455 * OVERSAMPLENR * AFAC,  280 },
  { 463 * OVERSAMPLENR * AFAC,  290 },
  { 470 * OVERSAMPLENR * AFAC,  300 },
  { 478 * OVERSAMPLENR * AFAC,  310 },
  { 485 * OVERSAMPLENR * AFAC,  320 },
  { 493 * OVERSAMPLENR * AFAC,  330 },
  { 500 * OVERSAMPLENR * AFAC,  340 },
  { 507 * OVERSAMPLENR * AFAC,  350 },
  { 515 * OVERSAMPLENR * AFAC,  360 },
  { 522 * OVERSAMPLENR * AFAC,  370 },
  { 529 * OVERSAMPLENR * AFAC,  380 },
  { 537 * OVERSAMPLENR * AFAC,  390 },
  { 544 * OVERSAMPLENR * AFAC,  400 },
  { 614 * OVERSAMPLENR * AFAC,  500 },
  { 681 * OVERSAMPLENR * AFAC,  600 },
  { 744 * OVERSAMPLENR * AFAC,  700 },
  { 805 * OVERSAMPLENR * AFAC,  800 },
  { 862 * OVERSAMPLENR * AFAC,  900 },
  { 917 * OVERSAMPLENR * AFAC, 1000 },
  { 968 * OVERSAMPLENR * AFAC, 1100 }
};

[dbotos]

That should definitely work. It does fine with the table lookup portion from what I've seen in my testing.

My worry is that whatever caused the AREF to be low may be unstable. It may be 4.35 V now but what if what changes and goes even lower or shoots up above 5 V? For the relatively small cost to replace the 2560, I'm going to do that.

[dbotos]

Got the new 2560 installed the other day. AREF measured 5.05 V. Seems to have fixed the temperature measurement issue.

[thinkyhead]

Amazing. Are you able to replace the problem component on the bad 2560, or are you just tossing it into the bin?

[dbotos]

I believe the default reference voltage comes from within the big 100-pin ATMEGA2560 chip. By the time you risk desoldering the old one and soldering on a new one ($5), you could just get a whole new board for ~$10. I think the old one will remain a paperweight / reference piece. ;-)