[BUG] Weird MPCTEMP behavior

[thomas374b]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

The heater does not heat when setting nozzle temp via LCD nor via terminal "M104 S80". I get thermal runaway faults. The heater is not switched on at all as I can see on the corresponding LED for the heaters MOSFET (which is not lit).

I can rule out hardware or wiring faults for 2 reasons

• it works when I compile with PIDTEMP instead of MPCTEMP
• more weird, it works when I use MPC autotune "M306 T" after reboot/reset

Bug Timeline

2024-05-11

Expected behavior

If the machine comes out of reset and nozzle temperature is far below 80°C Commands "M80; M104 S80" should switch on the heaters MOSFET i.e. start heating.

Actual behavior

I need to run MPC Autotune (M306 T) each time after RESET to make the heater work.

Saving parameters after MPC autotuning (M500) doesn't help, the newly determined MPC parameters are already almost the same as the previous ones stored in the EEprom. Although it seems to be neccessary to run "M306 T" once after each reset for some (hidden) initialization to get the heater up and running.

Steps to Reproduce

• enable MPCTEMP in Configuration.h
• build for mainboard MKS Robin E3D v1.1
• upgrade board eeprom from firmware Marlin-2.0.x to bugfix-2.1.x i.e. [factory reset]
• restore delta geometry configuration "M665 ...."
• restore MPC parameters "M306 E0 P40.00 C17.53 R0.2509 A0.0848 F0.1096 H0.0036"
• save to EEprom "M500"
• verify EEprom entries "M503"
• press [RESET] button
• after machine has restarted type "M104 S80"
  result => heating error thermal runaway
• press [RESET] button
• after machine has restarted type "M306 T"
• after calibration has finished type "M104 S80"
  result => no heating error

Version of Marlin Firmware

bugfix-2.1.x (May 11 2024 14:59:10)

Printer model

Kossel

Electronics

MKS Robin E3D v1.1

LCD/Controller

REPRAP

Other add-ons

Neopixel LEDs

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

config.zip

I've added a log from serial terminal in the config.zip

[thomas374b]

I think the problem is in file
src/module/temperature.cpp

I uncommented line 1683 to see what is going on

I think the error happens on initialization of "modeled_block_temp". This looks very "strange" to me.
line: 2836 HOTEND_LOOP() temp_hotend[e].modeled_block_temp = NAN;

Later the condition in
line:1624: if (isnan(hotend.modeled_block_temp)) {
never comes true

For testing I added a
static bool mpcInitDone = false
outside of
float Temperature::get_pid_output_hotend(const uint8_t E_NAME)
and replaced the initialization with
if (mpcInitDone == false) {
mpcInitDone = true;
and it solved the problem

[thisiskeithb]

I think the problem is in file
src/module/temperature.cpp

This isn’t a universal issue. As mentioned in #27068 (comment), I can’t reproduce the issue.

I use MPCTEMP on all my machines here (STM32G0, F1, F4, H7) with varying hotends / heater cartridges and they all tune & work fine.

@tombrazier: Have you run into any recent issues with MPCTEMP?

[thomas374b]

Am Mon, 13 May 2024 15:36:32 -0700 schrieb Keith Bennett ***@***.***>: [...]

This isn’t a universal issue. As mentioned in #27068 (comment), I can’t reproduce the issue.

But I can reproduce it. With mainline-2.0.x as well as with bugfix-2.1.x. Same behaviour

[tombrazier]

When I initially wrote the MPC code I used NAN as a flag to indicate that hotend.modeled_block_temp has not yet been initialised.

I vaguely recall someone, somewhere recently observed that NAN and the isnan() function are not supported for all MCU compilers and C libraries. Maybe that is the problem here. (Although I would have thought that the STMF32 is used widely enough that we would have seen this elsewhere by now.)

Anyway, @thomas374b, you could test the idea by using a special value that will definitely never be the temperature, say -1000000.0. Then on line 1624 replace if (isnan(hotend.modeled_block_temp)) with if (hotend.modeled_block_temp < -999999.0).

[thisiskeithb]

Although I would have thought that the STMF32 is used widely enough that we would have seen this elsewhere by now.

OP’s motherboard uses the same STM32F103 processor as the SKR Mini E3 V2 that I use with MPCTEMP and of course there are tons of Creality motherboards with this processor. We would have a lot more reports if this was a widespread issue. MPCTEMP works really well.

[ellensp]

perhaps they are using the obsolete mks_robin_e3_maple environment?

[thomas374b]

Am Thu, 16 May 2024 00:17:50 -0700 schrieb tombrazier ***@***.***>: [...]

Anyway, @thomas374b, you could test the idea by using a special value that will definitely never be the temperature, say -1000000.0. Then on line 1624 replace `if (isnan(hotend.modeled_block_temp))` with `if (hotend.modeled_block_temp < -999999.0)`.

OK, I will try that and come back. Stay tuned ... OK, that solution works.

[thomas374b]

Am Thu, 16 May 2024 00:44:38 -0700 schrieb ellensp ***@***.***>:

perhaps they are using the obsolete mks_robin_e3_maple environment?

No, I checked that. It is using HAL/STM32. There are also no include dependencies to *maple*.h

[ellensp]

Please use vscode terminal. (note this presumes you have set default_envs in platformio.ini)
Clean out your current build with
pio run -t clean
Then log the entire build, so we can see full list of libraries, versions etc your using
pio run > run.log
Attach run.log

[thomas374b]

After installing the whole development environment on another PC it turned out that it was a problem with the build environment.

The errorneous environment had more compiler options leftover from an optimization trial.

The option causing the error was
-ffast-math

[github-actions]

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.