Integrator Sum in RSLogix PIDE

Hi guys,
I'm hoping someone here has dug into this before. I've been tasked with trying to "figure out" why a barrel heating/cooling system has never worked very well. It takes too long to heat up, overshoots the setpoint, and the temperature feedback is erratic.

Here's the set-up:
1756-L61 processor v15.3 talking to 4 remote flex i/o racks over RIO (1794-ASB, 2 racks for digital i/o, and two for the thermo cards).
We're using PIDE FB's feeding SRTP's to pulse the heating and cooling of each zone.

I'm pretty new to RS5k, and to FB's, but I've already found quite a bit wrong with the programming, such as the Block Transfers to move the thermocouple data to the PIDE's is set-up on a 5 second loop(!) while the the PIDE's are called in a periodic task every second.

A bigger issue, I think, is the large amount of dead-time inherent in the system, which is causing the integrator to wind-up before the PV even changes. There's lots of things I could do to try to correct this, like setpoint ramping, and gain scheduling, but before I do that, I want to be able to monitor the integral sum so I can see when would be a good time to enable and disable integration.

I haven't been able to find the I sum in the controller tags or in the PIDE configuration. I also haven't been able to find anything in the literature or online help that points to it.

If anybody has any info on where to find the I sum, or any advice on dealing with the PIDE in these kind of applications, I'd appreciate hearing it. This is also my first time working with a velocity-type PID equation.

Thanks in advance,
Dustin

Bmacattach33
This is something I do often and have worked on several extrusion lines.
This tech note is quite helpful in using PIDE for Extrusion barrel temperature control:
22870 - ControlLogix MultiZone Temperature Control - Plastics Industry
I have found several small issues can accumulate and cause issues. Example: temperature inputs from Flex are limited in that you only have .1 degree resolution. Sure that seems like plenty but I have found that to be an issue. I have also used Spectrum Universal Analog input modules (cost per point is much better than the AB 1756-IT6I2). But, now will only use the more AB module.
Finally, if you are adventurous and have a good relationship with your local AB distributor I would suggest consideration of an Add-On instruction that AB has on limited release.
I am not sure I can’t do justice to an online discussion about this subject but would be willing to speak with you about my experiences. If you are interested please shoot me a PM with your contact info.

Rich

With the PIDE, I don't think there is any way to get to the integral term. Even with the huge number of things in it you can access, you can't get to the root of the instruction data.
I'm not very fond of the PIDE by the way, it's overly complicated.

That said, you cannot clear the integral term, but you can prevent it from accumulating, by setting the bool inputs "WindupHIn" and "WindupLIn" true. If you set those true, before enabling the PIDE, the integral term will be at it's default value. Release them when you approach your setpoint to enable the integrator again.

I generally don't even bother enabling the PIDE myself, until the PV has approached the setpoint. On a run command, I just slam the heaters on manually until I'm reasonably close to the setpoint, and then enable the PIDE in auto and let it take over.

rdrast said:

With the PIDE, I don't think there is any way to get to the integral term. Even with the huge number of things in it you can access, you can't get to the root of the instruction data.

Click to expand...

That seems like a major oversight, and is unfortunate.

That said, you cannot clear the integral term, but you can prevent it from accumulating, by setting the bool inputs "WindupHIn" and "WindupLIn" true. If you set those true, before enabling the PIDE, the integral term will be at it's default value. Release them when you approach your setpoint to enable the integrator again.

Click to expand...

That is kind of what I had in mind, only there would be less trial and error involved in setting up when you set those bool's if a guy could monitor the integral sum.

I'm beginning to get the feeling that I could do better for this particular application by ditching the PIDE and just writing my own PID algorithm and keeping the SRTP instruction. I like how that is set-up.

I generally don't even bother enabling the PIDE myself, until the PV has approached the setpoint. On a run command, I just slam the heaters on manually until I'm reasonably close to the setpoint, and then enable the PIDE in auto and let it take over.

Click to expand...

I think this would help quite a bit. Just set-up a compare, say if SP-PV/SP > .10 or < -.10, then disable the PIDE and feed 100% to the SRTP. I'll probably give that a try before doing anything else.

Thanks,
Dustin

Run the PIDE in "Velocity" Mode

There shouldn't be a separate integrator term. Just limit the CV.
BTW, I downloaded the documentation for the PIDE and there is an error in the formula for the velocity form of PID.

The formula should read
E=SP-PV
CV=CV(n-1)+Ki*Δt*E+Kp*(E-E(n-1))+(Kd/Δt)*(E-2*E(n-1)+E(n-2))
Basically this formula can be broken down in to three parts. The I, P and D parts like this
CV=CV(n-1)+Ki*Δt*E
CV=CV+Kp*(E-E(n-1))
CV=CV+(Kd/Δt)*(E-2*E(n-1)+E(n-2))
One can see that it is the CV that is holding the not the sum of errors but the
sum of errors Ki*Δt*E. There is no sum of errors to zero out so you can just limit or zero the CV term.

I don't like the term velocity mode. Who ever coined that phrase should lose his control creds.
There is nothing that has to do with velocity unless one considers integrating velocity is the same as a position error.

Peter Nachtwey said:

There shouldn't be a separate integrator term. Just limit the CV.
BTW, I downloaded the documentation for the PIDE and there is an error in the formula for the velocity form of PID.

The formula should read
E=SP-PV
CV=CV(n-1)+Ki*Δt*E+Kp*(E-E(n-1))+(Kd/Δt)*(E-2*E(n-1)+E(n-2))
Basically this formula can be broken down in to three parts. The I, P and D parts like this
CV=CV(n-1)+Ki*Δt*E
CV=CV+Kp*(E-E(n-1))
CV=CV+(Kd/Δt)*(E-2*E(n-1)+E(n-2))
One can see that it is the CV that is holding the not the sum of errors but the
sum of errors Ki*Δt*E. There is no sum of errors to zero out so you can just limit or zero the CV term.

I don't like the term velocity mode. Who ever coined that phrase should lose his control creds.
There is nothing that has to do with velocity unless one considers integrating velocity is the same as a position error.

Click to expand...

Thanks for the explanation, Peter.
Since the integrator is basically just adding the current E to CV(n-1) on each iteration, what is the actual function of the WindupHIin and WindupLOin bits? Do these just zero the I gain if the error is positive, or negative, respectively? If there is no integral sum to zero, then what is the point of Windup inhibiting?

The PIDE's I'm dealing with are currently set-up as "dependent" gains, with a cycle-time of 60 seconds driven by the SRTP. I plan on changing to independent gains, and a 5-10 second cycle time. I also plan to change the update rate on the thermocouple inputs from 5s to .25 s, and possibly run the input through a LPF before going into the PV.

I notice in the documentation that for both independent and dependent gains, the manual states that the "velocity" type equation is used. Is this true, or is there a way to switch between "positional" and "velocity"? I ask because the PIDE's in my application act like a traditional, error-summed positional equation. Even several minutes (and 10-20 degrees) after a zone has reached its setpoint, the CV may still be 100% and calling for full heat.

I haven't used the PIDE myself.
I thought the Micrologix and SLC5 PIDs were implemented poorly.
I don't know what is true but try to use the velocity mode whenever you can.
For temperature control try to use any PID where the proportional and derivative gains work on changes the PV only

CV=CV(n-1)+Ki*E*Δt-Kp*(PV-PV(n-1))-(Kd/Δt)*(PV-2*PV(n-1)+PV(n-2))
I call this the I-PD form of PID. It will not suffer from the derivative kick like a PID will.

Thats basically the same for the PIDE uses.

You can clear the value of CV_n-1 (or set it to any value you wish) by writing that value to PIDETag.CVPrevious and setting the PIDETag.SetCVPrevious input bit. This is close to clearing the integral sum.

Alternately you can write a value to CVInit and set the CVInitReq bit.

bmacattack33 said:

The PIDE's I'm dealing with are currently set-up as "dependent" gains, with a cycle-time of 60 seconds driven by the SRTP....... Even several minutes (and 10-20 degrees) after a zone has reached its setpoint, the CV may still be 100% and calling for full heat.

Click to expand...

I think your 60 sec. cycle time is your main problem. It is too coarse for your system. You should reduce this as much as practical to get finer control (probably less than 5 sec). Also minimum on (heat) time should ideally approach one cycle of the mains.

Ya know, the plain old PID instruction still exists on the Logix platform too... I use that more often then the PIDE version.

Just sayin'

Well, I got some time to work on this today.

Fairly quickly, I found some problems with grounding on the 24V com side of the thermocouple modules. That cleared up a lot of the "bouncing" of the temperature readings. I also found the cooling solenoids gutted on a couple of zones. Same old story, we see this kind of stuff all the time.

This got the alarms to stop going off, which made the operators happy. But I noticed that several zones still had erratic temp feedback, and therefore wild CV's, which caused genuine oscillation. On these zones I changed the cycle time of the SRTP to 10 secs instead of 60. (10 secs was a compromise I had to live with, this old machine is still using mechanical contactors for the 3-ph heaters, and they take a helluva beating, I'd like to put in some SSR's but mgmt doesn't want to spend the money )
I also sped up the BTR's from a 5-second to a .5 second update cycle, then ran the PV through a MAVE block which is set to 50 samples if the temp is within 10 degrees of setpoint, and 5 samples for quicker response if out of setpoint. This really smoothed out the PV and CV.

Another thing that helped was setting the CVHalarm to 95 and CVLalarm to 5. I then tied these bools back in to WindupHIn and WindupLIn, respectively. That seems to help with saturation on SP changes.

If I get time, I'd like to do all the zones this way, and add "Force Manual" full heat outputs on cold starts or if more than say 50 degrees below SP, like rdrast was saying.

Thanks again to all for the help and advice, you guys rock!

Cheers,
Dustin