Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
luotinen

Feature Suggestion: Nozzle Heater Runaway Protection

Recommended Posts

Problem:

If the connectors on the extruder become disconnected when the heater is on the nozzle heating will have a thermal runaway.

Steps to reproduce:

1. Set nozzle temp

2. Pull out the connector on the top of the extruder block

Suggested remedy:

If the software detects that the sensor is disconnected, emergency shut down and display error.

This happened to us with two printers. One lost the connection while printing (presumably it was already loose after filament change and became disconnected due the printing vibrations) and one lost the connection during a filament change (we did not notice it until white smoke started to appear).

 

Share this post


Link to post
Share on other sites

Usually "disconnection" means "electrical disconnection". But are you talking about physical disconnection in both cases? So that the sensor was reading room temperature?

Supposedly Marlin tests for this error but obviously it doesn't do a good job. I suspect this error is only caught maybe if the sensor falls out during the heating up step. I suspect once the nozzle is up to temperature, if the sensor falls out, it gets much harder to distinguish the problem using software.

 

Share this post


Link to post
Share on other sites

So based on the code -

The first requirement is that the current temp be less than the target temp being set by twice the watch increase value. The UM1 firmware comes with a increase vale of 10. So that means if the hotend is at say 180 and you set the new temp to be anything less than or equal to 200, the watch code won't be trigger.

The second requirement is that when the watch temp period elapses (the period by default in the UM1 firmware is 40 seconds), the temp must be ANY AMOUNT greater/equal to than the set temp plus the watch temp increase (10 for the UM1 firmware).

The third key point is that when the second requirement is met, the watch is DISABLE.

So for the UM1, this check won't help if

- The sensor reporting fails in a mode where the reported temp is a high value (10 more than the temp value set) or max value...

- If the sensor reporting fails in any mode after 40 seconds, the error won't be caught.

Obviously, this could and should be improved -

- There shouldn't be a check when the temp is changed that the hotend is less than the set point less twice the watch temp. If the set temp is changed, the watch temp should just be updated along with the watch temp check time to be the current time plus the watch temp time period.

- When the watch temp time period elapses, the temp should be checked to see if it is in the range of set temp plus/minus the watch temp increase. Hmmmm... well, see notes below.

- When the check is done, the check shouldn't be disabled. Instead, it should be set to the current time plus the watch temp period.

Note: After thinking about this a little - obviously, cooling down is a lot slower than heating. So the values might not work well and there might be need for a second set of cold down values used when the set temp is set below the current temp. However, an additional check should be implemented that when the cool down mode values are in effect, the temp should be checked at the heating check period to ensure that it hasn't INCREASED above the temp at the time of the temp change was requested plus the temp increase check value.

Not impossible to code. However, it's quite possible I haven't considered everything and could introduce all sorts if false "heating failed" problems...

Don't have time now but might attempt to implement if someone else (cough GR5 cough Daid cough illuminarti cough) doesn't....

Here is the existing code for the UM1 -

Marlin does this when you change the temp.

void setWatch()

{

#ifdef WATCH_TEMP_PERIOD

for (int e = 0; e < EXTRUDERS; e++)

{

if(degHotend(e) < degTargetHotend(e) - (WATCH_TEMP_INCREASE * 2))

{

watch_start_temp[e] = degHotend(e);

watchmillis[e] = millis();

}

}

#endif

}

 

Then during heating it does this check during the manage heater routine.

 

#ifdef WATCH_TEMP_PERIOD

if(watchmillis[e] && millis() - watchmillis[e] > WATCH_TEMP_PERIOD)

{

if(degHotend(e) < watch_start_temp[e] + WATCH_TEMP_INCREASE)

{

setTargetHotend(0, e);

LCD_MESSAGEPGM("Heating failed");

SERIAL_ECHO_START;

SERIAL_ECHOLN("Heating failed");

}else{

watchmillis[e] = 0;

}

}

#endif

 

For the UM1 version, the values involved

 

//// Heating sanity check:

// This waits for the watch period in milliseconds whenever an M104 or M109 increases the target temperature

// If the temperature has not increased at the end of that period, the target temperature is set to zero.

// It can be reset with another M104/M109. This check is also only triggered if the target temperature and the current temperature

// differ by at least 2x WATCH_TEMP_INCREASE

#define WATCH_TEMP_PERIOD 40000 //40 seconds

#define WATCH_TEMP_INCREASE 10 //Heat up at least 10 degree in 20 seconds

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Our picks

    • Taking Advantage of DfAM
      This is a statement that’s often made about AM/3DP. I'll focus on the way DfAM can take advantage of some of the unique capabilities that AM and 3DP have to offer. I personally think that the use of AM/3DP for light-weighting is one of it’s most exciting possibilities and one that could play a key part in the sustainability of design and manufacturing in the future.
        • Like
      • 3 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!