PID Loop to Create a Ramp

OK, I am stuck on this. I have 2 pids in an eb2 that is using 9.5c and talked to by S1, On of these is a heat loop and one is a cooling loop. In both cases, they have to do a temp ramp at a specific rate then a soak temp, then a down ramp (or an up ramp to new soak),

I am migrating this app from Mistic to ethernet and I managed to get the ramp to work fine in the past but it is not working in the Ethernet version. I have tried all the loop types but essentially no real change between any of them.

The challenge here is to get the PID setup right to track the changing set point and provide a stable ramp output. I have determined the lag time to be 18 seconds on the heat loop and 15 seconds on the cooling loop. The cooling loop isnt as much a problem, whereas the Heat loop when it reacts and increases output to meet set point, it drives the output past SP and then stays there. I can get some response to over reaction, but it is too little too late,

First of all, the scan rate is soooo slow in comparison to the rate at which the SP is being changed, that the PID over reacts to the delta T of the next update. Of course I can tune it really sluggish but then it ends up getting wound up and therefore never backs off.

I have achieved this in past but it was excruciatingly difficult to tune. It was also done with the previous version of ethernet PID algorithms that have recently been found to be wrong…which I imagine only added to the pain. I did this by using a set of tables and updating the P term continuously throughout the ramp about every 10 degrees. I eventually managed to get this to hold a +/- 1 degf all the way up the ramp, but it took many days of tuning.

Is there a better method?

Hi Barrett,

I have used two methods to do this, both are pretty similar, but am sharing both in the hope that one will be better for you than the other (if not, flip a coin - or do neither, but hopefully you will be inspired either way).

  1. The PID loop has been configured like usual. Analog input, analog output.
    Scan rate = 0.1
    Gain = 12
    Int = 0.7
    Der = 0.0001
    (Take or leave these numbers, they are what we ended up with in our system - YMWV).

Now, here is the fun part.

So you are just taking small bites at the end goal.
Don’t do this block again until you have reached this temporary small bite sized set point (that check is another condition block in the chart).
Once you are at this set point, then loop around and do this action block again, so in other words, only when you are at the set point, add a little more to the set point and loop again till the input is up to this new temp.
Clearly, you will need to think about and test what the ‘step_size’ variable and loop delay is for your application.
Also don’t forget that the step size will change your ramp slope.
Hint. You might need one set of PI&D values for this warm up ramp and another set when it gets to the desired temperature. This is pretty easy to detect and switch. (I think this is what we ended up doing).

  1. Configure the PID loop as usual, but have the PID output go to a host variable.
    In other words, we want to know what the PID output is, but we are going to read and change that variable in the chart and our chart is going to drive the heating valve, not the PID output.

As you can see, very similar to the first method, but now we are getting the error between what we want and what we are measuring.
Now we have a condition block that is looking at this error.
If we are overshooting, manually, but intelligently back off the output…

Right, so that’s the two ways we did it on our heating ramp.
The key to both is to make a ‘fake’ ramping set point based on where you currently are and over time, adding small bumps to the ramp set point. The PID loop happily sees and tracks those changes without windup or overshoot.

Hope that helps.

BTW, I feel your pain, we spend a looooooong time getting this sorted. Over shoots were expensive. ($100k+ and ~3 months work fixing the damage).

If you have a little money to spend, I’ve had really good luck using Expertune software as well, to speed up general loop tuning, which then might help you get a more accurate and efficient ramp. When we did our migration from Mistic to PAC, I had to retune ALL of our heater loops (which took forever). We bought a new version of Expertune midway through, and it really helped. It communicates via OPC, so it integrates easily, and you can tune in realtime. I know I sound like a commercial right now, but I’m not affiliated in any way, it’s just saved me a lot of frustration. In fact, Expertune didn’t have the “new” PAC PID loop algorithms programmed in to their software when we did our upgrade from Mistic – the had to add them just for us. Good luck!

All,

Ok the way things turned out, i found out that there was a little known problem with the PID algorithms in versions previous to 9.5…if you were having an impossible time, trying to tune your PIDs, this would be why. On a previous Oven in 2013, I was going stir crazy trying to get the PID to work. On that oven I created a table that retuned the loop every 10 degrees of the ramp and finally, after a massive number of attempts, got it to hold +/_ <0.5 degF all the way up ramps from 100 to 360 degF. Man was that painful.

On this oven, about half way through this, Josh found out that the bug existed and then I used the correct PID and managed to get it to hold the same level of control all the way up the ramp using just one tune. Gee, when the PID works correctly it works just like in the movies.

The ramp I use is required by spec, so I generate the set point based on dividing the total ramp temp by the time required for a 5 deg/min ramp rate.

One interesting caveat here is that instead of using the actual lag time of the process of 18 seconds, I found that with respect to the ramp, the lag time is probably associated with the time between set point changes, in the case probably about 1 second. I set the scan time to 0.5 and 1 second and found that these worked perfectly even though the actual process response time is 18 seconds, and that’s because the controller is updating the set point much faster than this based on the ramp slope. In order for a PID to keep up with the changes in set point, the scan time has to be related to that and not the process reaction time.

Another thing that did not occur to me at the time, was that this oven versus the earlier one, has the wrong kind of burner for this application. The burner is a Immersojet, meaning that it’s designed to heat water, not air therefore the heat exchanger creates even more lag time versus a direct fired burner.

Barrett,

Thanks for the update – that’s good info. When you say “versions previous to 9.5” I’m assuming you mean the Firmware version? Also, which PID algorithm are you using?

If they changed the PID algorithm in version 9.5, does that mean that my loops will behave differently if I upgrade to a newer version of firmware? I’m using version 9.2c right now.

Thanks!
Katie

Actually, FW 9.5 provides the corrected as well as the incorrect PIDs so that if you had successfully tuned a PID with the bad versions, you can continue using the bad PID’s. All of the PIDs that were incorrect are now labled as “Obsolete”. Therefore if you need to upgrade the fw, then after doing so, make sure you go into the strategy and select the appropriate PID Algo. I suggest checking to see which one you were using before converting since the new ones may have slightly different names, it may come up unselected.

Yes all versions prior to 9.5, have incorrect algorithms probably going back through the IO Control platforms. The Opto Control platforms had no such issues and this was my case where I upgraded from Opto Control where everything worked fine to Pac Control 9.3 or so where I had a heck of a time trying to retune something that should not have needed anything…to Pac Control 9.5 where I was confused about “Obsolete”??? That’s when I got hold of Josh and he got me on the straight and narrow again.

Any details on what the bug was and when it reared it’s ugly head? I can’t recall of anytime I ran into an issue with the PID not working properly and I am not running 9.5 firmware on anything out in the field yet.

Check out this OptoNews item on the topic (what? you’re not subscribed? sign up now!!)

Well I would call Josh on that, he’s the one that told me. Weird things happening during tuning might depend on the system you’re tuning and the particular algo you selected, however if you open up 9.5 and set up a PID, you’ll see that all four PID types have an “Obsolete” version of it that you can still use.

The way the bad PID reacted to process control was way different than the corrected ones. When you set a PID up and it doesn’t react in the classical PID sense, either your scan times are way off or there is something wrong with a sensor or actuator. However, you’re making the assumption that the stinkin PID algo is correct…I just about went mad trying to get that prior oven working…and this one too. On this latest oven rehab, I had so many weird issues going on at the same time, I can’t believe I got it straightened out.

This oven has the proportional regulator that uses a pilot air pressure from the manifold. The lower the manifold pressure, the higher the gas pressure (not sure if it’s not the other way around but you get the point). Anyway I would watch the oven temp ramping up at the prescribed 5 degf/min, and all of a sudden the oevn temp would be dropping off and the actuator (controlled by Opto22) would be opening up to max fire…after much aggravation I have concluded that the DUNGS regulator is not capable of operating accurately at 60degC and starts to fail at 50degC which was indeed the real problem.

Sounds like it was a real hair puller. Glad you got it all sorted.

Thanks Mary, I missed that one but it was about the time I came across this when I was working on that oven. And yes mine was affected because I usually do supply the input value from the host for one reason or another. In this case I was averaging 4 RTDs. So I gather it was not that the algo itself was incorrect but that the fw logic was incorrect and overwriting the input?
Yah Phil it was bad, in fact i’m still dealing with it. This is a bag oven that cures composites for aircraft and the way the cooling system was designed was that it has a fresh air damper for cooling control and it was positioned within inches from the product. Therefore everytime the damper opened to pull the temp down, it was blasting cold air (somethimes 0-20 degF) right on the curing part at 300 degF or so…so now I managed to get the job of fixing that as well.
You can put lipstick on a pig, but it is still a pig…