[BUG] Marlin halts immediately after turning on with Err: MAXTEMP Bed

[lorenzodimauro97]

Printer

Ender 3 with SKR V1.3, TMC2208 on XYZE in UART mode, stock CR10 Display

Description

When you turn on the printer with a firmware compiled after commit 48d1bd29c causes the following issue:

Printer starts, Marlin logo comes in. Buzzer starts buzzing intermittently.

Buzzer now starts buzzing constantly, the following message appears on the LCD:

Err: MAXTEMP BED

PRINTER HALTED

Please reset

Steps to Reproduce

1) Build a marlin firmware on any commit after 48d1bd29c 2) Flash firmware and turn on the printer

Expected behavior: Printer turns on

Actual behavior: Printer halts

Additional Information

This happens regardless of configuration.h and / or configuration_adv.h you're using. The stock ender 3 configuration.h and configuration_adv.h were used, the only mods to it being defining the TMC2208 drivers.

Reverting Temperature.cpp fixes the problem altogether.

[Strahler85]

I have the same issue after pull latest changes

[thisiskeithb]

I just ran into the same issue with this board on an Ender-3 after killing a print with the power switch and turning it back on.

Using files from the df77334 commit.

[rst00]

I have the same issue. Reverted back to pre 48d1bd2

[UnderXirox]

hello with the mks sbase use Marlin bugfix-2.0.x also it bug

Sur machine cr10s carte MakerSbase 32bits and DRV8825

avec

define TEMP_SENSOR_0 5 // E3DV6

define TEMP_SENSOR_BED 5 // Sensors Stock Creality3D

elle bip et avec un message sur le lcd Err: MAXTEMP Bed au reboot la carte idem la carte bip toujours mais avec dans le fichier Configuration.h et toujours la meme config

// Bypass bug thermistance //#define BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE

define TEMP_SENSOR_0 5 // E3DV6

define TEMP_SENSOR_BED 5 // Sensors Stock Creality3D

La machine boot normal et ne bip pas elle indique les bonne température pour le bed and hotend e3d

[Pilson66]

I have the same issue with SKR 1.3

[ghost]

For now, to bypass that error, you can add/uncomment this in your pins file ..

// Ignore temp readings during develepment.
#define BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE

Report back with your resting (cold) bed/hotend/chamber temperatures if you can.

[govido]

This 'solution' seems to be working for now. The temperature is at 52°C for the fraction of a second, and then drops to 26°C. Is it possible that the board measures way higher even before the lcd starts?

[ghost]

Trying commenting out that line again and try increasing the grace period from 1000ms to say 4000ms ..

So with ..

// Ignore temp readings during development.
//#define BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE

grace period setting is in Marlin\src\HAL\HAL_LPC1768\HAL.h ..

// A grace period to allow ADC readings to stabilize, preventing false alarms
#define THERMAL_PROTECTION_GRACE_PERIOD 4000

Someone has reduced the grace period down to 1 second (1000ms). If it is that then I guess it needs increasing back up again (@Roxy-3D et all)

But yes, the temperature reading starts off high (very high) then settles down to what it should be @govido. It's the low pass filtering used in the ADC sampling that causes that, just that it takes a little time to converge to it's proper value.

[Patag]

Works as it should now. Thanks @doggyfan !

[ghost]

So the grace period was too short then (at 1 second) @Patag ?

Using a longer grace period (4 seconds or so) fixed it OK ? .. this is the proper fix

[ghost]

DON'T leave BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE uncommented ladies, gents, non-binaries etc, it's ONLY meant for testing with.

[Patag]

No worries @doggyfan. The printer is still under assembling and testing. It has never seen any piece of filament yet :) Anyway, I performed a test with THERMAL_PROTECTION_GRACE_PERIOD set to 4000, BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE disabled, a bed preheating to 80°C and a short (about 10 secs) cooldown via LCD then a manual RST. The reboot went strait to MAXTEMP BED/PRINTER HALTED. It looks like the bed temp threshold triggering the halt is wrong a initialization (Only a feeling, I'm a noob in 3D printing and even more in Marlin programming :)) Edit : Anything with °C vs °F ?

[govido]

So... I tested 2000, 3000, 4000 and even 8000ms the error is still present. Any other ideas? Or is there something in platformio I have to do to get the change compiled correctly? I already deleted the .pioenvs folder...

[ghost]

In that case, I think the problem might be that their is no grace period applied to the min/max testing, but not sure.

Try this temperature.cpp. It has the grace period applied to the min/max testing. Make sure that you have BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE disabled.

Temperature_test.zip

[govido]

This works 👍 I left the HAL.h at default 1000ms and changed the temperature.cpp. What is different in your version?

[ghost]

I simply added the grace period to the min/max temperature testing, which just means it lets things settle at boot-up before it starts testing the min/max temperature.

I've had the same problem myself in the past week or two when testing stuff. I think it might be best if it's added to Marlin then.

[ghost]

OK, I've put in a pull request to add the change/fix into Marlin.

[ghost]

OK, the fix has been done.

Try the current Marlin release. If it's fixed it (should have), then you can close this @scippo97.

[lorenzodimauro97]

I'll try today and let you know

[UnderXirox]

Ok thx ✔ Merci pour le correctif probleme regle pour moi aussi thx 👍

[lorenzodimauro97]

Ok, can confirm new changes properly fix this bug on SKR V1.3, Can close this issue.

[Genosystem]

I've the bug today in commit e4260a4 Using BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE works

[ghost]

@Genosystem Can you post your config files ?

I'm actually very surprised that the LPC1768 boards are the only boards to need the grace period, because their ADC system is no different to any other board. I don't get why the 8-bit boards don't need the grace period too, it doesn't make sense because the very same LPF is used on all systems, and that LPF's output still needs time to converge to it's proper value. I don't get it.

I think the grace period #define should be moved to the Configuration_adv.h file, which I've done in https://github.com/MarlinFirmware/Marlin/pull/14204.

[Genosystem]

I've attached the configs. I can see that when I turn on the printer, temperatures drop from 37-45 degrees to room temperature. I've disable the "bogus" setting and I've set #define THERMAL_PROTECTION_GRACE_PERIOD 4000 and works too.

Config.zip

[ghost]

@Genosystem try increasing the grace period time length to say 4000 (4 seconds).

So in the Marlin\src\HAL\HAL_LPC1768\HAL.h file, set the grace period ..

#define THERMAL_PROTECTION_GRACE_PERIOD 4000

See if that helps.

[Genosystem]

Yeah, I edited the message above to put that.

[ghost]

That's OK then.

Try some shorter than 4000 grace period values (1500, 2000 etc) if you can, see how low you can go without Marlin throwing a temperature error at boot-up.

[Genosystem]

Hello 3000: OK 2000 OK 1500: OK 1000: FAIL

Can't you reopen reopen this issue? More users have the problem in other forums

[ghost]

I can't reopen the issue, but looks like it's fixed. Use double the lowest value that worked for you.

So 3000 or so looks like a nice reliable value to use for probably everyone.

[lorenzodimauro97]

Reopened by request, however I can't see why a grace period of 4000 is such a bother, my printer works flawlessly after the patch

[ghost]

I think you can re-close the issue @scippo97, it's very much fixed I think, just needed a slightly longer grace period for some people is all.

[Genosystem]

When has fixed? I'dont see any commits of this

[ghost]

@Genosystem you're right of coarse,, though I do have a pull request in (3000 grace period for all hardware types) for it to be committed to Marlin, which hopefully will go through.

[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.