Noisy thermocouple input

[robcazzaro]

Not sure if this is a real issue, but I thought that in any case you would be interested in more data.

I'm building a hot plate for SMD soldering with a k-type thermocouple connected to a MAX6675 and a plate heater controlled by a SSR. I use a relay-like control for the SSR, with 2 sec window and the SSR on for a fraction of that time. I built an Arduino program to auto tune my physical setup.

Unfortunately the MAX6675 output is very noisy, due to the thermocouple limitations. The output can easily change by a degree centigrade just due to noise. When looking at Brett's old autoune library, there was a specific note about noise http://brettbeauregard.com/blog/2012/01/arduino-pid-autotune-library/. The library had a setting for dealing with noise SetNoiseBand()

You are clearly using a different algorithm, and I'm not sure how impacted it is by noise. I also mentioned in another issue that it's very hard for a setup like mine to reach steady state. So even if I'm trying to use always the same conditions (5% output stepping up to 20%, but since I use a 2000 msec PWM window, the values you will see are 100 and 400), the actual values change quite a lot.

I modified your library to also print the thermocouple input value, not just the average, so you can see how noisy the system is. I'm attaching 4 different runs with identical settings but different starting conditions. The suggested K values are actually very consistent, considering the noise and starting conditions

//user settings
const uint32_t testTimeSec = 600;
float outputStart = 100; // 5% start
float outputStep = 400; // 20% step
const uint16_t samples = 600;
const uint32_t settleTimeSec = 300; //5 minutes to settle

pid2.log
pid3.log
pid4.log
pid5.log

[Dlloydev]

Oh, I'm always interested in test results, the log files are very helpful. I see the resolution is ±0.25 and as I scroll down through the settling mode data, it jumps by 2 resolution-steps max, but follows a very gradual warming trend.

Yes, this test algorithm is quite tolerant to noise ... on the TCLab I was able to get results with a step change of 1, but had the board in a covered case so any moving air wouldn't cause a disturbance. In the next release, It shouldn't be a problem to add a reset function, option to print instantaneous values and a looser tolerance for settling so the next step test can begin sooner.

[robcazzaro]

I'm afraid that the auto-tuned parameters did not work at all. I think it might be a scaling problem.

Let's say I use the values from the pid4.log file, Kp 0.0230 K 0.0013 Kd 0.0145

The output went from 100 to 400 (out of a possible 2000). But when I use those values in my program, the PWM out value is around 3 (out of 2000) even if the temperature is 30C away from the goal and dropping. after 100 seconds, PWM out is 5, and the temperature keeps dropping fast (it requires at least 300 to keep an higher than room temperature stable)

What am I doing wrong? Is there a scaling parameter I'm missing?

[Dlloydev]

Not sure what board you're using ... is it 8-bit PWM?

Seems that the process gain is too low .. might need to scale the output range and/or min and max output limits.

This is sTune's internal calculation for process gain:

// calculate the process gain
_Ku = abs((pvMax - pvStart) / (_outputStep - _outputStart));

Also might need to use Arduino's map() function to scale the output.

I'll have a new revision ready shortly that addresses the issues (tested on my TCLab setup) ...

• updated the Reset() function.
• the Configure() function now runs reset()
• serialMode printALL or printDEBUG now prints both pvInst and pvAvg values
• the print test results now reports if the sample rate is adequate
• updated dead time algorithm
• can run consecutive step tests with a shortened settling period in between

[Dlloydev]

I've pushed an update to the repository.
I'll create a new release if it checks out OK and after I get a chance to update the readme.

[robcazzaro]

Sorry, I mentioned it elsewhere. My system is made of a 300w heating plate controlled by an SSR. Since you can't really PWM an SSR, I used what most people do: I selected a 2000msec window, and the PWM range is 0 to 2000. When the output is, say, 1000, the SSR is on for 1 second, off for one. With 1500, on for 1.5 seconds, off for 0.5 seconds. I read the temperature every second.

It's a very slow system. If the temperature is dropping, say from 100C and I apply 100% power, the temperature keeps dropping another 5-10 seconds (2-3C drop) before it starts stabilizing, and it takes at least another 5-6 seconds to cross 100C again

So I need to understand what range your code uses (i.e. what is 0% and 100%), and map it to my values. That is for both the range and the pvStart/pvStop values. And also select the right values for pvStart and pvEnd

It would be very easy for users if your code always assumed, say, 0 to 100 range, so that I could map 0 to 0 and 100 to 2000. And, once the parameters are calculated, then I could use the same scaling in the code (basically, in my case, multiply everything by 20). It might be already the case, btw, I'm just a bit lost at this point, I'm afraid

[Dlloydev]

Ah, sorry ... I was mistakenly thinking of hardware PWM and PID output range and limits.

sTune only directly sets an output value as entered. In this case, its just a slowly timed output with an on time of 0-2000ms. sTune works with seconds for time units, so this might explain the low tuning values. After manually recalculating results from pid4.log, I get:

Output Control Range is 0.000 to 2.000 seconds

Output Start:    0.10
Output Step:     0.40
Process Gain:    38.33

Kp:              23.0
Ki:              1.3
Kd:              14.5

No mapping required as the process gain is just ... input difference / output difference
or more specifically ... _Ku = abs((pvMax - pvStart) / (_outputStep - _outputStart));

[Dlloydev]

The part I'm still not sure about, is if the above are values are out by a factor of 60.

The tuning rule constants (I'm quite sure) are based on minutes. In sTune.cpp lines 193-194, I've already divided by 60 to convert to seconds which works well with true PWM based control.

However, controlling a digital output based on time might require a different conversion ... I'll need to do some research on this as I'm not a PID guru.

[robcazzaro]

One thing I'm noticing, using Kp 23, Ki 1.3, and Kd 14.5 is that the system overshoots (expected), then slowly turns the output lower until 0% output.

Let's say my set temperature is 100C. The PID algorithm starts from output 20%, say, al the way to 100%. at around 90C, the output starts dropping, but not fast enough, and it overshoots by 15-20C. Then the output goes to 0 and the temperature drops. I would expect that around 105C or so the PID output started rising, to slow the undershoot. But it stays at 0 until the measure temperature drops below 100C, and only at that point it slowly starts raising the output, and it undershoots by at least 10C. My system is such that to maintain a 100C temperature, it needs a constant 20-25% output. So now it starts again to increase the output until it overshoots to, say 110C. But from this point on it never converges, as it always waits for the temperature to drop below 100C to start heating again

I have an espresso coffee machine with a PID, which in many ways it's similar to my plate heater: very slow to heat, and requires constant output to maintain the temperature once reached. That PID was auto tuned, and it works exceptionally well. IT overshoots target by a bit on the first rise, starts slowing down the drop before the setpoint, undershoots and overshoots once more by 2-3C, then it's rock solid. The key is that I can see its starting to increase the output while the temperature drops, well before it drops under the setpoint. That is a commercial PID, and it uses an SSR as well

I have an encyclopedic ignorance when it comes to PIDs (i.e. what I don't know can fill a volume :), so I have no idea what changes I should make to help "brake" the descent below the setpoint.

[robcazzaro]

To add: the PID for the espresso machine is a Fuji PXR3 (https://americas.fujielectric.com/files/prod_selector_v/Micro%20Controller%20X%20Operation%20Manual%20Model%20PXR3%20(ECNO%20409d).pdf?r=false) and according to the manual the ranges for P, I and D are

P 0.0 to 999.9%
I 0 to 3200 seconds
D 0.0 to 999.9 seconds

and my autotuned values for that are P=4.3, I=95 and D=18.3

But P doesn't seem to be the same as in your library, since the manual says "When is too small, control will be unstable, and when is too large, the response will be delayed.", and from what I can see this behaves differently in my code

[Dlloydev]

One thing I'm noticing, using Kp 23, Ki 1.3, and Kd 14.5 is that the system overshoots (expected), then slowly turns the output lower until 0% output.

This sounds good. Should expect up to 25% overshoot using zieglerNicholsPID
There is a no-overshoot tuning rule available.
Some progressively less aggressive rules are tyreusLuybenPID, someOvershootPID and noOvershootPID

[robcazzaro]

The overshoot is not the problem, sorry if I was not clear. That will get smaller over time, if the undershoot also improves.

The current problem is that it always undershoots by 10C, no matter what the starting point is. Since it always undershoots the same amount, it never converges. And the problem is that the output doesn't start increasing until after the input temperature goes below the setpoint. To avoid undershoot, the system should start increasing the output once the temperature is dropping and it's 2-3C above setpoint. Instead it only starts after the drop. And the system inertia means that it wll always undershoot the same amount unless the PID output starts increasing sooner

[Dlloydev]

To add: the PID for the espresso machine is a Fuji PXR3 (https://americas.fujielectric.com/files/prod_selector_v/Micro%20Controller%20X%20Operation%20Manual%20Model%20PXR3%20(ECNO%20409d).pdf?r=false) and according to the manual the ranges for P, I and D are

P 0.0 to 999.9%
I 0 to 3200 seconds
D 0.0 to 999.9 seconds

and my autotuned values for that are P=4.3, I=95 and D=18.3

But P doesn't seem to be the same as in your library, since the manual says "When is too small, control will be unstable, and when is too large, the response will be delayed.", and from what I can see this behaves differently in my code

In this case, P = 4.3 x 100 = 430%
The "I" value (I think) refers to time integral. So the autotuned I needs to be inverted (1/I) = 0.0105
The "D" value (I think) refers to time derivative. So the autotuned D needs to be inverted (1/D) = 0.0546

[Dlloydev]

The overshoot is not the problem, sorry if I was not clear. That will get smaller over time, if the undershoot also improves.

The current problem is that it always undershoots by 10C, no matter what the starting point is. Since it always undershoots the same amount, it never converges. And the problem is that the output doesn't start increasing until after the input temperature goes below the setpoint. To avoid undershoot, the system should start increasing the output once the temperature is dropping and it's 2-3C above setpoint. Instead it only starts after the drop. And the system inertia means that it wll always undershoot the same amount unless the PID output starts increasing sooner

I'll take a closer look at the code when I get a chance later ... perhaps the output temporarily reverts to outputStart value in between step tests or from step test completion to initializing and starting the PID. Or perhaps the PID needs to start with the outputStep value so it doesn't try to climb from 0 output.

[robcazzaro]

I ran a few tests using the old Autotune library https://github.com/br3ttb/Arduino-PID-AutoTune-Library.

The average of a few runs (even when using wildly different tuning ranges) was Kp=33, Ki=0.17 and Kd=0. Using those parameters, I get really good performance: minimal overshot, stabilizes without oscillations (even if the output stays at 0 when dropping). I'm enclosing the data from my program (not the autotune)

I first set a holding temperature of 100C from room temperature. Once it stabilizes at 100C, I drop the setpoint to 70C and wait for stable output again. Considering how slow my system is to cool (and can heat much faster than cooling), a great performance. Not sure why the original algorithm found much better values. Happy to run any test for you if you like

pidQuick.log

[Dlloydev]

Interesting. I haven't used the PID-AutoTune-Library before but I have seen it. Do you have an example of how you're using it in code? Also curious how long the AutoTune test run takes.

If you're using QuickPID, note that it defaults to a more advanced anti-windup mode that reduces overshoot, so this could partially be the cause of the minimal overshoot and no oscillations.

Not sure why the original algorithm found much better values. Happy to run any test for you if you like

Thanks ... I still need to catch up a bit with more testing with my setup. Ive just finished comparing several settle time values here.

It looks looks like you have the PID-AutoTune-Library controller mode set to PI, which uses different constants than PID mode. I think its using Ziegler Nichols rules for a relay step test ... I'll look more closely later and compare with the reaction curve method and constants that sTune uses.

So far, sTune seems to be working great with others and on my setup with PWM control, but has some issue with the constants when using "bang-bang" output control for a relay.