Heater Decoupled since updating to latest firmware

This is for general discussions. Also FAQ can be found here.

Moderator: speedake95

Post Reply
Dreide
Posts: 176
Joined: Sun Sep 29, 2013 12:32 am
Location: Lausanne, Switzerland

Re: Heater Decoupled since updating to latest firmware

Post by Dreide »

Ahem, just had a look at the firmware code and it is rather confusing, so I could be wrong with the following.
There are two methods for checking for decoupling, "full" and "hold". "full" is the one using DECOUPLING_TEST_MIN_TEMP_RISE and e.g. EXT0_DECOUPLE_TEST_PERIOD and is activated when the temp is below target temp and outside the PID_CONTROL_RANGE interval (so heater will be fully on, hence "full"). As soon as the temp is within PID_CONTROL_RANGE, the PID control becomes active and the "hold" decoupling check might be activated. But this happens only when the temp is entering the DECOUPLING_TEST_MAX_HOLD_VARIANCE tolerance band. From then on, the firmware checks every second whether the temp is still within the DECOUPLING_TEST_MAX_HOLD_VARIANCE tolerance band, no matter at which PWM level the heater is operated. A decoupling event is detected when the temp falls outside the tolerance band (even if it also falls outside the PID_CONTROL_RANGE band). BTW, the decoupling check method is deactivated/reset whenever the target temp is changed.
So when the decoupling happens during the print, it is more likely to happen while the "hold" method is active, so DECOUPLING_TEST_MAX_HOLD_VARIANCE would be the relevant parameter. In the worst case the heater cartridge would drop out of position slowly, so that 100% heating would be still sufficient to keep the temp within the tolerance band.
Obviously, such cases are hard to detect no matter which method is used. A less drastic scenario would be that the extruder temp is at 185°C and the temp sensor works fine but the cartridge suddenly drops fully out. The temp would drop and the PID control would rather quickly start heating at 100%. Still, the temp would need to drop to 15°C below target temp before the decoupling would be detected, which might take too long to prevent damage.
Felix 2.0->3.0dual * Repetier (host+firmware) * KISSlicer Pro, Simplify3D * Cubify Design

User avatar
DDME-Marc
Posts: 71
Joined: Sun Nov 24, 2013 11:04 pm
Location: New Zealand

Post by DDME-Marc »

Hi All,

I have now completed several more runs since my last post, using the same PID values and progressively lowering the decoupling time parameter each run. The very last run was completed using a decoupling time parameter of only 8 seconds, and still free of decoupling faults.

From what I understand regarding extruder commands suggest it is normal to have a delayed response (dead-time) when it comes to heating up. looking at the graphs in the Repetier interface I would estimate in the order 7 seconds, which suggests going below this value for the decoupling time parameter value is unrealistic.

My goal for pushing the decoupling time parameter right down to 8 seconds was to see if a decoupling fault could be triggered on a relatively short 3 hour print. [Edit]Since this has been repeatedly achieved free of decoupling errors I will now reset the time parameter to around 10~12 seconds and attempt a long print.

Settings and results (complete with extruder swap over) to date are:
Configuration-h_1.jpg
Configuration-h_2.jpg
Output_extruder_1_black.jpg
Cheers,

Marc
Last edited by DDME-Marc on Fri Oct 24, 2014 8:14 am, edited 1 time in total.
Felix 3.0 Dual Head * E3D Titan V6 * Repetier-Host V2.1.3 * Repetier-Firmware 0.92.9 (01/08/17 - Modified) * KISSlicer Pro - 1.6.3 * Arduino 1.8.5 *

Dreide
Posts: 176
Joined: Sun Sep 29, 2013 12:32 am
Location: Lausanne, Switzerland

Post by Dreide »

DDME-Marc wrote: My goal for pushing the decoupling time parameter right down to 8 seconds was to see if a decoupling fault could be triggered on a relatively short 3 hour print. Since this has been repeatedly achieved I will now reset the time parameter to around 10~12 seconds and attempt a long print.
See my previous post. At least for the extruder switches, all it needs to trigger the decoupling event is the overshoot to reach a temp 15°C above target temp after heating up (DECOUPLING_TEST_MAX_HOLD_VARIANCE 15). If the temp raises that high only for very short, the event could go undetected because of the sampling period of 1sec while in "hold" mode.
EDIT: the event could be also triggered when there is a big undershoot when cooling down to the "hold warm" temp of the inactive extruder.
Felix 2.0->3.0dual * Repetier (host+firmware) * KISSlicer Pro, Simplify3D * Cubify Design

User avatar
gfeliksdal
Site Admin
Posts: 405
Joined: Sat Feb 25, 2012 10:40 pm
Location: Netherlands
Contact:

Post by gfeliksdal »

Hi All,

On the basis of DDE-Marc's pid values, I've changed the PID values slightly to decrease the overshoot. The response showed good results in more situations.
- Heating up 1 or 2 heads, with or without the bed on/off
- Turning bed off, 1. then heating both extruders at the same time, 2. Heating one at a time seperately.
- Did this with the bed on also.

You could see slight variations, but it seems stable enough. At least a lot better than it was before.

I'll try to lower the variance values coming days. Hopefully the error is a thing of the past then.

Repetier, reported that he changed the decouple routine and added extra reporting fields. So it should be easier to debug as you should be getting different error reports. He reviewed the code, but he couldn't point out why the decouple error would be showing. At least it should not show up randomly. He found one small error, but that wasn't related to the issue.

Also the error handling if it occurs, will be changed in the future, but on short term he didn't have time for it. So the printer will continue to go into dry-run mode instead of parking.

See attachment for latest version, configured for the dual head.
Repetier-Firmware-2014-10-22 - single.zip
(320.71 KiB) Downloaded 58 times
Repetier-Firmware-2014-10-22 - dual.zip
(320.91 KiB) Downloaded 64 times
You can also get it from the repetier-website configurator if you were curious.
http://www.repetier.com/firmware/v092. It contains the latest bug fixes. Just upload the config.h file and it will take over all settings. You probably have to change a few parameters at the temperatures tab.

Kind regards,

Guillaume

seaton
Posts: 291
Joined: Tue May 14, 2013 9:04 am
Location: Bunbury, Western Australia
Contact:

Post by seaton »

I Loaded new firmware this evening and half way through a four hour print it failed with the display reading "Killed"

No Power to fans etc it's as though it has timed out and shut off.

These were the last commands on the console


SENT: G1 X169.621 Y70.608 E556.0139
RECEIVED: ok 0
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Firmware unresponsive. Attempting to force continue...
WARNING: Device unplugged while connected to port
Total build time: 248.97 minutes
Stephen...

Felix 2.0 -> Felix 3.0 dual
Simplify3D Slicer, Kisslicer
Have you added your Felix to the Map? http://goo.gl/maps/HajnZ

http://blog.strobotics.com.au

User avatar
gfeliksdal
Site Admin
Posts: 405
Joined: Sat Feb 25, 2012 10:40 pm
Location: Netherlands
Contact:

Post by gfeliksdal »

Hi All,

I've updated the firmware with some sligtly changed pid values. P:17, I:0.25, D:80. I've put the window and decouple time at 15 seconds which should hopefully work for all the printers in the field. This gave good response when the printer is in operation, but when starting up from cold the setpoint takes a little longer to be reached.

I've tested it with 5 printers all running for a few days (single and dual). They haven't shown the decouple error. One printer which used to show this error, did not show it either. So my hopes are up that the problem is solved now.

If you have time, please test it and let me know your findings. Thanks for the already given feedback

Kind regards,

Guillaume

packman
Posts: 8
Joined: Sat Sep 22, 2012 2:02 am
Location: Cedar Grove, New Jersey, USA
Contact:

Post by packman »

Hi Guillaume, I am having the same problem. Tried the most recent update. any suggestions?

User avatar
gfeliksdal
Site Admin
Posts: 405
Joined: Sat Feb 25, 2012 10:40 pm
Location: Netherlands
Contact:

Post by gfeliksdal »

Hi Packman,

Can you tell me how and when it is happening? Also can you try to replicate the problem, connected with your pc? Then you will see a more elaborate error message.

Dreide
Posts: 176
Joined: Sun Sep 29, 2013 12:32 am
Location: Lausanne, Switzerland

Post by Dreide »

A screenshot of the temp curves would be also of interest, possibly with a high zoom level (as set in the Temp curve->Zoom tab in Repetier host) and a high update frequency (in Config->Printer settings->Printer->Check every XX seconds).
Felix 2.0->3.0dual * Repetier (host+firmware) * KISSlicer Pro, Simplify3D * Cubify Design

User avatar
DDME-Marc
Posts: 71
Joined: Sun Nov 24, 2013 11:04 pm
Location: New Zealand

Post by DDME-Marc »

Hi All,

Although revised PID values appear to have mitigated to a some degree the false errors, the more questions you ask, along with on going errors you begin to wonder if the thermistor circuits are still subject to high levels of noise.

And although I am not primarily involved with process control talking to a couple of colleagues who are, are telling me that when dealing with PID control it is the derivative value (the D value) which can have the largest influence during a phase of rapid change.

Any uncertainties with derivative computations can lead to increased gain at a high frequency, which can lower the signal and significantly increase noise.

The suggested feedback has been to try better filters for the signal or try lowering the D value.

Interesting that I have been fortunate to continue operating free of false errors with a D value of 46 compared to standard firmware 0.92 setting of 80.

Since 0.92 relies heavily on clean signals has anyone conducted noise comparisons between 0.91 and 0.92?

Cheers,

Marc
Felix 3.0 Dual Head * E3D Titan V6 * Repetier-Host V2.1.3 * Repetier-Firmware 0.92.9 (01/08/17 - Modified) * KISSlicer Pro - 1.6.3 * Arduino 1.8.5 *

Post Reply