Printer increases temp to 325C when set to 235C on second layer WITH thermal runaway enabled

[landodragon141]

Description

Printer increases temperature to 325C on the second layer when it is set at 235C This occurs on the latest stable branch downloaded 2018-08-24 This happened to me first on the initial release of 1.1.9 so I downloaded the latest revision from the stable branch yesterday and tried it again with the same result. I only noticed originally because the filament which was orange was becoming more neon yellow and started stringing like crazy. I'm so glad I stayed to watch the first couple layers.

Steps to Reproduce

1. Sliced this file.
2. Start print
3. wait for layer 2 and clench

Expected behavior: [What you expect to happen] Printer switches from 240C (first layer temp) to 235C

Actual behavior: [What actually happens] Printer increases to 325C while oddly still showing that the set point is 235C on the screen.

Additional Information

I'll attach a picture of the LCD screen if desired showing that it still thinks it's set to 235 although the temp reading goes up to 325C also I do not have thermal runaway disabled. MarlinIssueFiles.zip

[thinkyhead]

Try a different slicer and see if it makes any difference.

[landodragon141]

I can. I also I have the G code and my configuration attached in that zip if anyone feels like trying to run the gcode dry. I actually checked the raw gcode and the values for the M140 are correct.

[landodragon141]

So here's an additional question. How is it getting to 325 when my max hotend temp is set to 300? (I'm using an e3d pt100) To my understanding the thermal runaway should be triggered way before it gets to 325.

[thinkyhead]

You're right that it makes no sense. You might want to rebuild and re-flash Marlin to see if it corrects itself. Also, M502, M500 after the flash.

[landodragon141]

Well the reason I posted is that I was having the issue with the original release of 1.1.9 so I updated to the latest hoping it would be resolved. Alas the rest is history. Also I always do the M502 M500 thing when I re-flash. Also while I am personally concerned I'm mostly pursuing this as it could be a potential loophole that could endanger those not as technically savvy.

[AnHardt]

Temperature table 20 is relatively rarely used - compared to the normal thermistors; so not very well tested. Table 20 has the opposite slope than the normal thermistors. Low ADC-values correspond to low temperatures here. That may change the way the raw max- and - min-temperatures have to be calculated. It also changes the test for what is in- and what is outside the good interfall. In one of the both there may be an up to now undiscovered error.

Happy macro expanding.

When 20 ist used together with normal thermistors the scope of the compare-macros becomes important.

[AnHardt]

Maybe I got it. Either it needs an extra condition to prevent 'HEATER_0_USES_THERMISTOR' from being set in Conditionals_post when 20 is selected. Or it needs a condition not to redefine the in table_20 already correctly defined HEATER_0_RAW_HI_TEMP and HEATER_0_RAW_LO_TEMP in thermistortables.h .

Logically this has to be applied for all heaters.

[AnHardt]

I did not, but have an other suspicion what i'm investigating.

[AnHardt]

    const bool heater_on = 0 <
      #if ENABLED(PIDTEMP)
        soft_pwm_amount[e]
      #else
        target_temperature[e]
      #endif
    ;
    if (rawtemp > maxttemp_raw[e] * tdir && heater_on) max_temp_error(e);

If we have PIDTEMP and the current temperature is already high enough for the PID to decide, we don't need any further heat, so adjusting the soft_pwm_amount to 0, we can't get a max_temp_error. If the heater got stuck ON, we have a problem. Switching off the power supply, by kill(), would have been the last chance to stop the heater automatically.

@thinkyhead Can we base the decision upon heater_on on target_temperature always? Can't find why we do use soft_pwm_amount.

[AnHardt]

Was introduced with #8126 "Fix M303 thermal protection" because of #8103 "Marlin 115 tried to burn my house down during PID tuning".

How about someting alike

    const bool heater_on = (0 < target_temperature[e])
      // for the case of PID-tuning
      #if ENABLED(PIDTEMP)
        || (0 < soft_pwm_amount[e])
      #endif
    ;

[AnHardt]

Booting with a stuck heater is still undetected because of the changes needed for the fu**ing "high temperature thermistors".

[AnHardt]

See further comments in https://github.com/MarlinFirmware/Marlin/pull/11718#issuecomment-418394884

[thinkyhead]

The patches have been merged, so try the bugfix branch to see if it's behaving better now.

[thinkyhead]

Can we base the decision upon heater_on on target_temperature always? Can't find why we do use soft_pwm_amount.

Probably just preserving existing behavior from long, long ago. We can follow the Git Blame history to trace back to the first commit where this was used and see what the justification was at that time.

[AnHardt]

Since yesterday i can. See the links one comment later.

Modify the interesting line of code and commit it locally. start gitk search for the red line in the uppermost commit. right click and select "show origin". git gui will jump to a green line where you can find the origin. Search around for the replaced red line and "show origin". If you can't find a related red line you got the introducing commit. With that, and some luck, you can find the PR and with some more luck the pointer to the original issue.

At least worked her for the two cases i tried to look up yesterday. gitk is a great tool if you prefer clicking - not the shell.

EDIT: Sorry meaned gitk all the time.

[thinkyhead]

I suspect the whole reason for using the PWM instead of the target temp is that the temp used to be a 4 byte float. Now it's a 16-bit integer, so using the PWM is no longer an optimization. So, we're all good!

[AnHardt]

Would you please follow my links. "Only issue MAXTEMP when heating" #5082. Was pure madness. Defing BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE (omitting the kill()) would have done the job.

[landodragon141]

@thinkyhead FYI I figured out what caused my temperature to go so high. I had enabled PID extrusion scaling with the default Pc of 100. I print infil at the same speed as a Prusa i3 MK3 about 180mm/s. Apparently that's enough to send the temps over 300. On a side note with the new fix it actually through an error and stopped my print so huzzah to that!

[landodragon141]

Crap I lied it still starts to increase on the second layer.

[thinkyhead]

I don't understand PID scaling very well, but it seems that we should throw an error and have the printer shut down if the temperature of the nozzle goes over the HEATER_n_MAXTEMP setting in any situation. There doesn't seem to be a check against that anywhere at the current time.

In the meantime, it's probably best to avoid using PID_EXTRUSION_SCALING since it's causing your heater to stay on for too long.

[AnHardt]

Crap I lied it still starts to increase on the second layer.

Next layer or part cooling fan?

I don't understand PID scaling very well, ...

The problem

It needs energy to melt filament. To heat the filament the heater block around the nozzle is cooled down. The cooling takes some time (dT1) to reach the temp. sensor. Now the PID can begin to work against that cooling and gives some more power to the heater. The additional heat starts creeping thru the heater bock. After some time (dT2) the heat reaches the nozzle and after an other time (dT3) the heat reaches the sensor. (dT2 can be larger than dT3 or the other way around. ) Magnitude for the dTs is usually ~seconds, depending on material, mass, distances and coupling (f.e. direct, thermal compound or air).

--------- Heater 
| H N S | Nozzle    Heaterbock. H,N,S can have any sequence and distance.
--------- Sensor

The idea

Avoid oscillations of the nozzles temperature by putting in the melt energy early, so the nozzle does not have to cool down until the energy is provided by the PID.

The code

        #if ENABLED(PID_EXTRUSION_SCALING)
          cTerm[HOTEND_INDEX] = 0; // cTerm[] is only used for debug output
          if (_HOTEND_TEST) { // Is this the right heater?
            const long e_position = stepper.position(E_AXIS);
            if (e_position > last_e_position) {
              lpq[lpq_ptr] = e_position - last_e_position; // amount of planed! extrusion
                                                           // since the last call ~1/5 second before
              last_e_position = e_position;
            }
            else
              lpq[lpq_ptr] = 0;

            if (++lpq_ptr >= lpq_len) lpq_ptr = 0; //lpw_len is a delay in ~1/5 second
            cTerm[HOTEND_INDEX] = (lpq[lpq_ptr] * planner.steps_to_mm[E_AXIS]) * PID_PARAM(Kc, HOTEND_INDEX);
            pid_output += cTerm[HOTEND_INDEX]; // PID_output is adjusted directly. No chance to throw
                                               // errors based on MAX_TEMP. Array could be omitted.
          }
        #endif // PID_EXTRUSION_SCALING

What is the code doing?

Determine how much filament is planned to extrude. Apply the energy delayed by some fixed time.

What's wrong with the code?

The code tries to delay the additional melt energy by some fix time. From the problem we can see we have to apply the heat before, to avoid the drop. So there can only be one reason for a delay - bridging the time between planning and executing (in the planner buffer). Sadly this time varies widely from a few ms to several seconds. Should work only on the current heater(s).

Conclusion:

Can't work as expected!

What's needed?

Provide more energy a fixed time before the filament is melted, delayed by the amount of time in the planner buffer. If the sum of these times becomes negative, apply the energy immediately. This will be to late but hopefully faster than waiting for the temperature drop. I have no idea for a correct implementation.

Suggestion

Drop for now.

shut down if the temperature of the nozzle goes over the HEATER_n_MAXTEMP

This is already fixed now. Except you mean we should hinder to order temperatures above MAXTEMP. I haven't looked that up now, but i remember we limited the input temperature in the menus to MAXTEMP - 15?, to avoid the overshot to go above MAXTEMP. I can remember this is different for setting the temp by g-code, but i don't, if not checked at all or only the margin is omitted.

[landodragon141]

Sorry let me clarify my previous comment. I thought that the issue that was causing the temperature to increase out of control was PID_Extrusion_Scaling. I failed to properly confirm my ASSumption before I posted here that I had identified the problem. After disabling PID_Extrusion_Scaling the moment the second layer starts the temperature just starts increasing for no apparent reason. As I previously mentioned the good news is that I can confirm that the fix to max temp works since it will now fatal error instead of continuing to print with the heater at full. Later tonight I'll do a test and start this same print while monitoring it with repetier server. That will let me see not just what the temperatures are doing but the heater itself.

This is what should happen: 1st Layer E0-240C Bed-67C 2nd Layer E0-235C Bed-67C

This is what actually happens 1st Layer E0-240C Bed-67C 2nd Layer E0-TO THE MOON! (Right now my max temp is set at 275C so it hits that and kills the printer) Bed-67C

[landodragon141]

@AnHardt I think there are two possible ways to really execute PID Scaling correctly. 1st cobble together a way of doing it in the slicer. This would require some kind of calibration to be run to inform the slicer about the printers heating and cooling characteristics. This method honestly seems overly complex and probably not worth trying to implement.

2nd we would need a much much much larger planner buffer so that we could actually compensate for temperature multiple seconds in advance of E movements. This method is likely impossible for 8 bit boards since they are so starved for memory as it is. However with the advent of 32 bit boards this could actually become a possibility.

[AnHardt]

I still don't understand. Is the target temperature set to infinity at layer 2, or is the right target temperature displayed but the is temperature rises until the printer resets.

Please cite the g-code at the layer change. What else happens when z is lifted and the temperature is lowered?

[AnHardt]

Please also append the config files and the used pins file.

[landodragon141]

@AnHardt The right target temperature is displayed but the actual continues to rise until it resets. With regards to configs you will find both the config files and the exact gcode file in the attachment posted towards the top of this thread.

[AnHardt]

...
G1 X90.238 Y87.501 E0.01531
G1 X90.760 Y88.023 E0.02088
M106 S255                                                     ;This is likely to be causing the evil
;BEFORE_LAYER_CHANGE
G92 E0.0
;0.35

G1 F8640
G1 X90.238 Y87.501 E-0.17034
G1 X90.238 Y86.960 E-0.12490
G1 X90.590 Y87.312 E-0.11493
G1 X90.590 Y86.771 E-0.12490
G1 X90.238 Y86.419 E-0.11493
G1 X90.238 Y85.943 E-0.11000
G1 E-0.04000 F2100.00000
G1 Z0.800 F10800.000
;AFTER_LAYER_CHANGE
;0.35
M104 S235 ; set temperature
G1 X13.369 Y19.262
G1 Z0.350
G1 E0.80000 F2100.00000
G1 F3000
G1 X13.692 Y18.725 E0.01348
G1 X14.157 Y18.300 E0.01356
...

Likely fan and heater share the same pin.

Please send pins_RAMPS.h and pins_MKS_GEN_13.h. Did you change something in there? Where is your hotend heater connected? Where your fan (if any)? Does the fan work?

[landodragon141]

Fan is on D9 Hotend is on D10 just as shown on the diagram I have made some changes to the MKS_GEN_13 file but not to the fan or heater. pins.zip

[AnHardt]

Yes. Your changes should not cause the problem. Will dive into pins_RAMPS.h tomorrow (Don't drink and debug - 2 am here). Would be a great help for me if you coud state where you connected fan and heater and if the fan works - to eliminate a few dozen cases. Could also be a physical short between them.

[landodragon141]

As I said earlier Fan D9 Hotend D10 Fan works although I have noticed that it is starting up when the hotend turns on..... I'll have to investigate a possible short.

[AnHardt]

Bingo!

[AnHardt]

As a workaround you could try to edit pins_RAMPS.h from

#ifndef RAMPS_D10_PIN
  #define RAMPS_D10_PIN     10
#endif

to

#ifndef RAMPS_D10_PIN
  #define RAMPS_D10_PIN     7
#endif

And connect the heater to D7.

[landodragon141]

Good point hopefully I'll have a chance to look into it tonight.

[landodragon141]

FYI - I discovered my problem and it turns out that once again I am my own worst enemy. What ended up happening is that I had a few wires switched around. Because I use 24 gauge ethernet cable for my wiring I use two pairs for the hotend heater but only one pair for the layer cooling fan. I some how made a bozo move and wired one hotend pair and the fan to the E0 mosfet while connecting the second hotend pair to the fan mosfet. So in the end it was entirely my fault although as a result we did fix a critical bug in the thermal runaway code so I feel good about that.

[thinkyhead]

Thanks for the update!

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