Thermal runaway, mintemp error

[boaschti]

Hi,

I'm using Marlin 1.1.0 RC3. I built my Printer with a Ramps 1.4 (EEB), Max6675 and REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. CS of Max6675 is D22. On first starts i had the problem that always mintemp error occurs. The solution was a pullup DO-5V. Now the heater was working. While heating a mintemp error occurs (because DO/MISO is 0V) marlin detected it and stops the software, no reaction on incremental encoder ect.... BUT the problem: The Heater stays on and no measuerment is taken from software! I checked with my oszi reproduceable. I think the heater will heat until thermal dead or fire.

Best regards S.Weisser

[KiteLab]

Is the temperature showing room temperature. Does it react on warming with fingers/lighter?

[boaschti]

Hi,
No it shows 0. I tested also a broken wire on thermocouple. Then a Maxtemp error occurs and heater also stays on and it shows 000.

[boaschti]

If the PID regulation is active (near the set temperature) it is a 50/50 chance if the heater stays on or off.

[KiteLab]

As long your thermometer is not working proper - please don't try the heater. Your risking fire. No feedback - no regulation.
Is there any special reason for not using D66 for SS as suggested for RAMPS?
Can't find D22 on RAMPS. Arduino D22 is RAMPS D53 and already in use.for SDSS.
There are differences between Arduino and RAMPS (FastIO, Marlin) pin numbering.

Do you use a premade MAX6675 module, or a naked chip. Anyway a pull up should not be needed.

[boaschti]

Hi

much thanks for the answer. I use the pin D22 marked in schematik. Normally this pin is free on Ramps1.4. The temperature measurement is working with this pin as CS. But when a error occurs the software shows the wrong reaktion (in my opinion).
I'm using a MAX6675 "Module". The pullup I need because without pullup the VO doesn't reach until 5V and the slope is very bad. And tempmin always is shown.

The reaction (heater on on error) can cause with:
VO stuck at GND
VO stuck at 5V
Thermocouple open wire
other causes thinkable I'll continue testing

Best regards

[boaschti]

The heater stays also on if kill switch confirmed. With #define BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE the Heater switch off in case of above named errors.

[Grogyan]

Ensure that the thermocouple is the correct polarity.

Also use the SPI port pins mentioned in the header file. This gives the
most reliable results

On Tue, Dec 15, 2015 at 4:23 AM, boaschti notifications@github.com wrote:

The heater stays also on if kill switch confirmed. With #define
BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE the Heater switch off in case of error.

—
Reply to this email directly or view it on GitHub
#2844 (comment)
.

[KiteLab]

How is your heater connected? Direct, or with some additional electronic, like an SSR or solenoid? Is there any possibility the heater signal could be inverted there?

[boaschti]

I use the normal SPI Port. Only for CS i use D22. I tested for you D66 for CS (original in pins_RAMPS_13.h). It's the same reaction. I suppose before. The polarity of themocouple is OK.
The thermocouple and temperature reading WORKS. But in case of error or kill button is pressed the heater stays on.
I think there is a Bug in the Software.
disable_all_heaters() seems to work, tested with M81.
The heater is connected with original Ramps FET's.

https://www.youtube.com/watch?v=L29cI9Y7Mzs&feature=youtu.be

Here you can see the red light (Heater). The Oszi shows Sck and MISO. It stays on after kill Switch is pressed. Kill Funktion is also called if define BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE is not set and a temperature error occurs. (So same reaction).

[AnHardt]

Got it.
temperature.cpp line 1127

-  #if HAS_TEMP_0
+   #if HAS_TEMP_0 || ENABLED(HEATER_0_USES_MAX6675)

[boaschti]

Thank you, thats it. It works with kill button.

Best Regards

[thinkyhead]

This has been patched in RCBugFix so I will mark this and close it.

[Blue-Marlin]

@thinkyhead
Please have an other look at https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/temperature.cpp#L1118

[thinkyhead]

@Blue-Marlin Hmm, somehow I though @AnHardt's fix already got through. I will make sure it gets into RCBugFix forthwith.

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