PID with controlled ramp

[nathand]

Might be helpful to add a chart to your front panel that shows setpoint, measured temperature, and the controller output. You could also log that data, and then feed it to one of the PID Autotuning (Design) functions. Without seeing neither data nor code, it's hard for me to understand what's happening and what is and isn't working in your system.

Start as simple as possible - get the PID working at a steady state temperature before you add the setpoint profile.

I don't think that example has separate gains for increase and decrease; instead it has two separate controllers that are cascaded (the output of one is the input to the other). That's why you're seeing two separate sets of gains. While your heating and cooling probably have different dynamics (I assume only the heating is driven actively), you shouldn't need multiple sets of gains.

[RudyBu]

A little bit of background before I explain an observation; maybe it has some relevance but I won't be able to test until tomorrow. 

The temperature reading of the furnace comes from an IR thermometer/pyrometer that is mounted above the furnace. It has a minimum temperature of 550 C, below which it doesnt not register a temperature (it transmits 0). To make up for this, I have set up my program to only trigger the PID once the temperature is above 0. 

What I noticed was that, despite having a starting power of 1.5 kW, as soon as the temperature was over 550, the output dropped to 1kW (via the PID). The gain also drops to maybe 10%  of the original value. 1 kW is barely above the minimum power to sustain a given temperature level so, rather than seeing a steady increase in temperature, the system stalls a little bit. In this stall time, the gain starts increasing but at a very slow rate. Towards the end of both my test runs, the auto-tuned gain never quite caught up to my initial value. Maybe this low gain is keeping the power from increasing?

In any case, I will take your recommendation and start with just the PID tomorrow and see how it does. If that doesn't work, I'll try Zeiger-Nichols.

[nathand]

You'll definitely get some weird and undesired behavior if there's a sudden discontinuity at 550 degrees. How are you triggering the PID only above that temperature? I highly recommend that you not put the PID inside a case structure; instead, any time the temperature is 0, set the reinitialize input to true. In addition, you might consider using the In Range and Coerce function so that the PID block never sees a temperature below 550 (I don't know whether this will be better or worse in your situation than setting it to 0). Sounds like you should also change the lower limit for the output so that it's sufficient to maintain temperature.

[RudyBu]

I do, in fact, have the PID inside a case structure. Right now, there is "is temperature > 550" check. When that returns true, it executes the pid. I remember noticing the reinitialize input in the help this morning and thinking that it would be another way to achieve the same result but if having the PID inside the case structure is inadvisable then retooling that should not be an issue.

I have built-in insurance incase the pryometer gives me a faulty read so the PId block never sees a value less than 550 but I will look into In Range and Coerce.

[nathand]

---

@RudyBu wrote:

I do, in fact, have the PID inside a case structure. Right now, there is "is temperature > 550" check. When that returns true, it executes the pid.

---

The reason this is a bad idea is that the PID internally maintains some state. Among other things it maintains the value of the integrator, and the time since the last run. If you have a bunch of loop cycles where the PID doesn't run, then the next time it does run it may add a disproportionately large value to the integrator, since it will assume that the current error has applied since the last time the PID ran (that's overly simplified, I'd have to look at the code to see exactly how the integrated error is calculated, but the idea is right).

The reinitialize input clears the integrator and tells the PID to ignore the elapsed time since the previous run.

[RudyB]

Update:

After running again this morning and seeing that PID vi did not once drop it's output below 1 kW, I decided to turn off the autotuning and just see if it would behave like a PID control at all. Ran it without the setpoint profile and I was pleasantly surprised at how well it ran. So I then added the setpoint profile back and did another test run. I've attached a picture of that run. Fairly satisfied with it so far. There are some odd plateaus during cooling but that was because, at those points, the power was already at my minimum value. So a minor tweak will fix that.

Incidentally, the run was 5 minutes @ 30 C/min ramp to 700C. Then hold for 5 minutes and finally cool to 550 C over another 5 minutes. With only PI control, the ramp and cooling looked good and the hold stage bounced between 701 and 699. I'm going to try adding a derivative term to see if helps the steady state response any. Also, one thing to note is that the pyrometer only outputs integer values that are rounded up so I hopefully changing that will rounding down will mean I don't have to mess with the derivative term.

I took your suggestion about reinitialzing the PID if temperature was below 550. I also wired the same true/false check to the manual control at the top of the PID vi so that if ever the temperature was below 550, it would swap to manual power control and use a static value (1.5 kW).

Last thing, while everything seems to have worked fairly well, the one thing that did not was the d(t) on the PID. Despite having set it to 10 seconds, the PID module was firing constantly. Is this because I turned off the autotuning? If it matters, my pyrometer reads every 60 ms and, currently, feeds that value straight to the PID. This is because there is some kind of de-sync effect if I attempt to delay the temperature reads. I had thought maybe this was the problem last night and I imagine I can feed the temperature reads into an array and then have the PID just pull the newest value in that array when it needs it.

[nathand]

---

RudyB wrote:

Incidentally, the run was 5 minutes @ 30 C/min ramp to 700C. Then hold for 5 minutes and finally cool to 550 C over another 5 minutes. With only PI control, the ramp and cooling looked good and the hold stage bounced between 701 and 699. I'm going to try adding a derivative term to see if helps the steady state response any. Also, one thing to note is that the pyrometer only outputs integer values that are rounded up so I hopefully changing that will rounding down will mean I don't have to mess with the derivative term.

---

Derivative control is intended mostly to speed up a slow process during times of large changes (it "sees" that the system is responding slowly and adds additional power to compensate). It will have little effect on a relatively fast system and at steady state.

EDIT: sorry, I described this poorly (incorrectly and backwards). Derivative control allows you to use a larger integral gain (smaller integral time) in order to speed up a slow system. The derivative terms acts against the integral term, helping prevent overshoot. It has the greatest effect when the temperature (and therefore the error) is changing rapidly. At steady state, there is little variation in the process variable and therefore the error, so the derivative is near 0 and the derivative term in the PID has little effect.

---

RudyB wrote: 

Last thing, while everything seems to have worked fairly well, the one thing that did not was the d(t) on the PID. Despite having set it to 10 seconds, the PID module was firing constantly. Is this because I turned off the autotuning? If it matters, my pyrometer reads every 60 ms and, currently, feeds that value straight to the PID. This is because there is some kind of de-sync effect if I attempt to delay the temperature reads. I had thought maybe this was the problem last night and I imagine I can feed the temperature reads into an array and then have the PID just pull the newest value in that array when it needs it.

---

Do not wire the dt term at all. It's only used when you want the PID to execute as though it's running at something other than the real loop rate, usually for speeding up a simulation without affecting the actual values generated. The PID executes every time it's called, so for every iteration of the loop that contains it. That's why it's "firing" constantly. With dt unwired, the PID will calculate the elapsed time since the previous call and use that in the calculation. When you remove the fixed dt, you'll also need to recompute the integral time (which will then be real minutes, versus what you're using now).

Why do you want it to run only every 10 seconds? Why would you want to delay the temperature readings? Of course you won't get good control if there's a delay between the time you take a reading and the time the PID acts on that reading. I don't understand your comment about feeding the pyrometer value into an array, either. Normally the way you have it - connect the reading directly to the PID, and the PID output directly to your output device - is the correct way to do it.

[RudyBu]

I remember reading that derivative control was meant to reduce overshoot and in my skimming, I must've assumed it would help the steady state response so thanks for clearing that up.

With regards to dt, the last time you explained it, I assumed you were talking about the setpoint profile. When I started on this project, I was told that I probably wouldn't need a d(t) less than 10 seconds and so that notion is still somewhere in the back of my head but you are absolutely right; my system responds very quickly and introducing any delay would only be counter-productive.

Now, to redesign my UI.