Marlin: [BUG] Bed Temp with 10°C offset (2.0.x-bugfix)

[retikulumx]

Hi.

I think there's a heat bed bug with current bugfix-2.0.x build:

When I set the temperature to 60°, the bed will heat only to 50°. Marlin notices that and throws a " Heating failed, printer halted, please reset" error.
Temperature setting to 80°C heats up to 70°C and throws an error.

No matter if I use Octoprint (and Terminal) or Printer Display.

Funny thing is, that Bed PID Autotune works with 60°C, no problem.
A previous version of bugfix-2.0 (from November I guess) worked until today.

My setup:

• Ender 5
• SKR Mini E3 Dip

default_envs = STM32F103RC_btt_512K

#define MAX_BED_POWER 255

#define BED_MAXTEMP 125

#define TEMP_SENSOR_BED 1

[GMagician]

That's not a bug. bed max reachable temp is your value - 10 while in hotend is your value -15.
This is done to be able to read a valid temperature above target and raise an error if they become too hot

Edit: You should not be able to set more than valid values...

See now your max is 125

[retikulumx]

Back to the 2.0.x non-bugfix version (copied all the config files I changed) works well. So it looks like a bug in bugfix-Version (sounds a bit ironic :-D).

[GMagician]

Can't see any commit that may affect temp from 2.0.5.3 to current bugfix, but I can't go deep since I don't have any SKR to test with (my mega2560 works ok with bugfix)

[retikulumx]

Strange. I might pull it again and make it from the scratch.

[XDA-Bam]

There's some info about similar problems on reddit. Basically, the early configs for the SKR Mini boards had #define PIDTEMPBED enabled, but didn't have tuned PIDs. If you use the latest Marlin 2.0.x bugfix, but still use your old configs, that might be the problem. If so, either disable PIDTEMPBED, or run PID autotune on the printer.

[retikulumx]

I did an PID Autotune of course, as I said in my initial post. ;-)
And for the first compile I added my previous PID settings, so...

Anyway, that wouldn't make sense. An offset about exactly -10° at any temperature doesn't sound like a PID problem.

But thanks.

[XDA-Bam]

Sorry, overlooked the autotune remark. Nonetheless, those 10°C are exactly the default value of #define PID_FUNCTIONAL_RANGE. The PID controller only comes into play when you reach T_target - 10 K. That's why I asked. Maybe the autotune gave you inaccurate values, or there is a bug when storing those values to EEPROM. Have you tried compiling the autotune results in as default PIDs?

Further question: Are you using EEPROM emulation, or are you storing EEPROM values on the SD?

[Enric580]

I have the same problem and now I have tried to modify this parameter and the result is that the bed stays at -5 ºC and then the printer does not give the error.
But i can't print

[retikulumx]

Hi! Sorry for the delay.

Maybe the autotune gave you inaccurate values, or there is a bug when storing those values to EEPROM. Have you tried compiling the autotune results in as default PIDs?

The autotune looked accurate (just almost the same values as the values I used before).
And yes, I compiled them too.

Further question: Are you using EEPROM emulation, or are you storing EEPROM values on the SD?

No idea. How to check this?

[XDA-Bam]

EEPROM emulation is on by default in recent builds and is set in pins_BTT_SKR_MINI_E3.h with the line #define FLASH_EEPROM_EMULATION. If you're using a recent build and didn't know this existed, it's probably on for you. You could try commenting that line out, which forces the board to store all settings to the SD card (if I'm informed correctly - I don't own a Mini E3 myself).

If storing to SD helps, there's either a bug with the EEPROM emulation, or the part of the EEPROM where the settings are stored might be faulty. Using STM32F103RC_btt_512K as target on the SKR Mini E3 bears some risks, because the F103RCT6 found on that board is technically specced with 256K of flash. The "missing" 256K you're currently using are out of spec - they might work fine, but it's not guaranteed. If storing settings to SD helps, you could also try to compile with the default STM32F103RC_btt target and see if that helps.

[Enric580]

I've compiled Marlin again, and I think there were two problems

• I could not initialize the EEPROM and no matter how much I compiled again I kept the settings saved in the EEPROM

• The bed did not go up because the PID values ​​were not "adequate".
  I entered the PID values ​​that autotuning indicated. But when I started heating the bed, when it reached -10ºC the bed stopped heating, although curiously, while I was autotuning, I kept the bed at the correct temperature.
  I have put some values ​​that I had in my previous plate and it has already worked for me

PID old bed Kp 145.10 Ki 5.59 Kd 941.98
PID bed according to autotuning Kp 40.71 Ki 1.25 Kd 885.87
the bed is a 12v MK42

[retikulumx]

@XDA-Bam I'm back to the normal/release 2.0.x which runs perfectly with the settings I copied from the bugfix version. Just checked: Yes, #define FLASH_EEPROM_EMULATION was on.
I might gonna compile it again on weekend. Or maybe I'll just stay with the working version.

@Enric580
Yes, same behaviour. Which version are you using?

[Enric580]

I use Marlin 2.0.5.3.
It has already started to work well.
It was my problem that I did not modify the EEPROM values correctly.
Now the sequence that I have done
M303 E-1 C8 S70,
Modify values in Marlin
I have compiled
And then I have entered the code M502 and M500 to record and now it works

[retikulumx]

Ok, strange. With 2.0.5.3 I don't have this issue. Only with the bugfix branch.

Does the M502 M500 survive a restart? If yes, I'm gonna try to deactivate the EEPROM emulation on bugfix version too.

[Enric580]

I cannot guarantee if it happens with all the data, but with the PID data
it has happened to me

El jue., 23 abr. 2020 22:34, retikulumx [e-mail] escribió:

Ok, strange. With 2.0.5.3 I don't have this issue. Only with the bugfix
branch.

Does the M502 M500 survive a restart? If yes, I'm gonna try this on bugfix
version too.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/17547#issuecomment-618652878,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APHKIA27HDDI5EV2SSW7AUDROCQ57ANCNFSM4MIBIB4Q
.

[retikulumx]

Using STM32F103RC_btt_512K as target on the SKR Mini E3 bears some risks, because the F103RCT6 found on that board is technically specced with 256K of flash. The "missing" 256K you're currently using are out of spec - they might work fine, but it's not guaranteed. If storing settings to SD helps, you could also try to compile with the default STM32F103RC_btt target and see if that helps.

Regarding using the 512kb: The firmwares directly from the developer BigTechtree are also using the 512kb option, so this shouldn't be a problem.
https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware

[XDA-Bam]

>

Regarding using the 512kb: The firmwares directly from the developer BigTechtree are also using the 512kb option, so this shouldn't be a problem.
https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware

That only means that BTT themselves run the chip out of spec. STMicro advertises the STM32F103RC6 with 256 kB - I rather trust the actual chip designer than the user (BTT) when it comes to hardware specs.

I'm also guessing that STMicro only produces a single chip type with 512 kB and they sell them at different prices as 256/384/512 kB versions. The chips are probably tested and those with faulty flash cells are "demotet" to 384 or 256 kB ones. That doesn't mean all of the 256 kB ones are faulty - they could have much more perfect 512 kB chips than they've got demand for. In that case, they might relabel those and sell them as smaller 256/384 kB versions, although they would work perfectly fine with 512. If I'm correct about this: How are you gonna know if your STM32F103RC6 chip with official 256 kB is a "good" one or a "bad" one?

That problem put aside, this is a possibility to test and gain more info: Try original Marlin bugfix-2.0.x with STM32F103RC_btt_512K and see if it works. Then, try the BTT 512 kB version and see if it works.

[boelle]

@retikulumx still an issue?

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.