Big latency in PID for temperature controling

[St007]

I have tuned PID for hot-end and bed with MK4DUE works pretty fine, for hot-end deviation is about +/-0.2 C, for bed it is less then 0.1 C. But with Klipper with same PID settings I have +/- 2 C for hot-end and more then +/- 0.5 C for bed, which causes bad print results

[sapell]

I'm not sure if one should expect the PID controls of two different firmware to be identical. I recommend a fresh PID tune with Klipper, it won't take that long. I just did that with results like yours were originally.

[St007]

In general, definitely yes, same PID for same closed heater system must work same. But in case of Klipper we add some reaction lag, because temperature computing is made on the host. It is like if try to drive Ferrari on the Mars with FPV staying on the Earth.

[hg42]

I don't think this short delay does matter for those slow temperature changes. Perhaps fans have different speed or something like that.

[lenne0815]

Agree, its highly unlikely that feed back to the raspi is the cause, we do endstop probing with it which needs be to somewhere in the ms range.

[KevinOConnor]

The PID parameters are closely tied to the polling interval, the oversampling rate, the ADC range, and the PWM range. PID values from other firmwares aren't going to transfer well, because of these differences in the implementation. There's nothing inherently less stable with Klipper's PID implementation.

That said, the documentation should be updated to make it clear PID tuning should be done. Also, the M303 command needs to be updated to report to the user the new PID values (instead of having to grep the values from /tmp/klippy.log).

[hg42]

I want to add, it's the first PID implementation (mainly the autotuning) that was able to handle my bed. Most never get to the 8. cycle (stopping with a timeout I guess) and therefore the values don't match. Also, Klipper is able to heat it up fast within 5 deg Celsius which is very good for this bed.

[TylonHH]

How do I run an PID Tune for the Hotend and one tune for the BED?

[KevinOConnor]

On Tue, Jan 02, 2018 at 04:58:45PM -0800, TylonHH wrote:

How do I run an PID Tune for the Hotend and one tune for the BED?

Run an "M303 E0 S170" command with parameters as described in the standard reprap g-code documentation. (For example, use "M303 E-1 S50" for the bed.)

Unfortunately, for the time being, after running the test, you'll need to extract the Kp/Ki/Kd parameters from the klippy.log file by ssh'ing into the host machine and running: grep Autotune /tmp/klippy.log

And then update the printer.cfg file with those parameters and issue a RESTART.

-Kevin

[sgraber]

@KevinOConnor : Is this being looked at as a future enhancement (spitting out the PID results to the terminal instead of having to grep it from a log file)?

[sapell]

This was addressed yesterday in commit https://github.com/KevinOConnor/klipper/commit/5caff594c5d78edd6da114d0d9e8d5f78ad31cdf

[sgraber]

@sapell : Awesome! Now I'm going to ask a dumb question, but how do I go about upgrading Klipper to the latest git code? I assume I just do the following?

git clone https://github.com/KevinOConnor/klipper ./klipper/scripts/install-octopi.sh

While keeping my .cfg file untouched?

[KevinOConnor]

On Fri, Jan 12, 2018 at 11:39:23AM -0800, Shane Graber wrote:

@sapell : Awesome! Now I'm going to ask a dumb question, but how do I go about upgrading Klipper to the latest git code? I assume I just do the following?

git clone https://github.com/KevinOConnor/klipper ./klipper/scripts/install-octopi.sh

While keeping my .cfg file untouched?

A good question. I've added an item to the FAQ for it:

https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#how-do-i-upgrade-to-the-latest-software

-Kevin

[sapell]

The printer.cfg isn't affected by the update. Even the initial installation does not write any printer.cfg in the /home/debian folder where Klipper by default expects to find it.

[PRouzeau]

In the RepRapFirmware versions from 1.09 to 1.14 (before abandoning PID algorithm), there was a fourth term added for the regulation, defined as 'T' . This parameter was characterizing the dissipation of the element (BED or Hotend) and was a coefficient proportional to temperature estimating the dissipation, [edit] so it was removed from the output, then the PID algorithm was applied only on the remaining part of the output and the estimated dissipation is added to the 'I' term. This is very logical as the system answer cannot be the same while heating or cooling, heating being slower due to the dissipation, while the PID algorithm is 'symetric'. In my experience, it greatly improved the control and was the only way to have something stable on my hotend. I had a Fisher delta, with a very powerful cartridge (50 or 60W) with half the mass of other hotends, which was very difficult to control. This added parameter, which was very easy to estimate, as you were able to look in real time at the actual PWM value for any temperature, so directly calculate the parameter, had solved my control problem. You can have a look on the RepRap Wiki here :http://reprap.org/wiki/G-code#RepRapFirmware_1.09_to_1.14_inclusive . [edit] See here : https://github.com/dc42/RepRapFirmware/blob/dev/src/Heating/Pid.cpp from line 357

With the advent of new ultra-compacts hotends with low inertia (Notably Deltaprintr and AIO Evo), we need a good temperature control and I think this is relatively easy to implement and proven. Shall I open a separate issue for that demand ?

[KevinOConnor]

On Sat, Feb 03, 2018 at 05:29:28PM -0800, Pierre ROUZEAU wrote:

In the RepRapFirmware versions from 1.09 to 1.14 (before abandoning PID algorithm), there was a fourth term added for the regulation, defined as 'T' . This parameter was characterizing the dissipation of the element (BED or Hotend) and was a coefficient proportional to temperature estimating the dissipation, so it was removed from the output, then the PID algorithm was applied only on the remaining part of the output.

FWIW, this is what I wish to do with Klipper - change the heater calibration command to return parameters describing something similar to a "first order approximation plus dead time" of the heater - heater gain, heater thermal resistance, heater time delay (or perhaps heater inertia). These parameters have the advantage of being measurable quantities (as opposed to the PID parameters which are effectively "magic numbers"). We can then generate reasonable PID parameters from them. They can also be used to verify that the heaters are heating at a reasonable rate (ie, detect thermistor failures).

I understand that RepRapFirmware does something similar to the above today. However, I find the RepRapFirmware code to be hard to understand and I don't agree with some of the details in their implementation.

-Kevin

[ghost]

I wonder if this is the reason im getting thermal runaway? my bed and extruder seam to be reading "room temp" ok, but as soon as i set a temp in octopirnt for either of them the temp just keeps climbing.

[JeanJacquesBluffobaque]

I just finished my 1st install (yay :-) ). In my case the room temps are 'suspect': T0:34.0 /0.0 B:39.0 /0.0. Those seem way too high. What can I do to make these base values more accurate?

When I heat the bed to say 60, it reportedly gets there but the bed is barely warm to the touch.

[cmock]

Assuming your hardware gave sensible temperatures previously with another firmware, the most likely cause is that you've selected the wrong sensor_type.

What hardware is it, and what are the sensors specified in the previous firmware?

[JeanJacquesBluffobaque]

@cmock It's a Wanhao Duplicator i3 V1.0. Sensors should be NTC 100K beta 3950. As mentioned here: https://groups.google.com/forum/#!searchin/wanhao-printer-3d/4.7k%7Csort:date/wanhao-printer-3d/71EiGQoPTOk/CG8u4icNBgAJ it might be the case that the fixed/sensing resistor on the temperature sensors on my board are 10k in stead of 4.7k. I don't know how to verify that to be honest.

My printer.cfg started as a clone of the generic Melzi config provided. That file has a EPCOS 100K B57560G104F sensor selected. I've since double checked but in my case room temp is not affected by which sensor_type is select in the printer.cfg.

Looking at Wanhao firmare source online I find:

define EXT0_TEMPSENSOR_TYPE 97

define USE_GENERIC_THERMISTORTABLE_1

define GENERIC_THERM1_T0 25

define GENERIC_THERM1_R0 100000

define GENERIC_THERM1_BETA 3950

[cmock]

That's an easy thing to try -- just set pullup_resistor to 10000 and see what happens...

[JeanJacquesBluffobaque]

That seems to fix it, thx!