search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
15.97k stars 19.09k forks source link

[BUG] Weird MPCTEMP behavior #27083

Closed thomas374b closed 1 week ago

thomas374b commented 3 weeks ago

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

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

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

Additional information & file uploads

config.zip

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

thomas374b commented 2 weeks ago

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 commented 2 weeks ago

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

This isn’t a universal issue. As mentioned in https://github.com/MarlinFirmware/Marlin/issues/27068#issuecomment-2102706254, 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 commented 2 weeks ago

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

[...]

This isn’t a universal issue. As mentioned in https://github.com/MarlinFirmware/Marlin/issues/27068#issuecomment-2102706254, 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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

perhaps they are using the obsolete mks_robin_e3_maple environment?

thomas374b commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 1 week ago

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