Compactlogix PID bias/feedforward

[Old No. 7]

I'm working in implementing a bias into logic for a Compactlogix PLC using the PID instruction. I have it close to working but there's one part that seems like it could be an issue.

Basically I want to move the PID output to zero when an event occurs. I added a bit for the event, a one shot, and then I calculate the BIAS. BIAS = BIAS - PID.CV.

For the most part this works ok. If I'm at 35% out and the event occurs the BIAS becomes -35, the output moves to zero and the loop keeps running.

The potential problem I see is that the BIAS is additive. So if the event occurs and the BIAS becomes say -35 and then the loop controls for a while and works itself back up to 40% out and the event occurs again the BIAS is now -75%. Again it still works properly, but if this happens hundreds or thousands of times can it cause a problem?

I did add logic that clears the .BIAS when the loop goes into manual which should minimize the odds that it becomes a major problem.

Anyone have a better way to do this?

 

[saultgeorge]

Anyone have a better way to do this?

I'm sure that drbitboy and Peter will weigh in soon, as well as others who have forgotten more than I know and I don't know if it would be a "better way", however I did quite a few PID loops in an air handler project a few years ago.
I wanted the output (CV) to go to zero also at times. My old boss wanted me to use a MOV and move a zero into .SO, and the output% (CV) when this event occurred. One instance was when the setpoint and loop were placed into "manual override" (customer spec). Another instance was when the unit was in either heat or cool and the opposite mode would come on, either by manual means or from a defective transmitter, etc. I could send you a screenshot of that logic if it would help.
When the event was over, the loop would return to where is was before or do a ramp up or down depending on conditions. Hope this helps.

 

[Jlandwerlen]

Basically I want to move the PID output to zero when an event occurs.

I believe you want to use override for this.

 

[destination unknown]

Another option would be tieback mode

 

[Old No. 7]

I believe you want to use override for this.

I'm not seeing an override in the PID instruction. Is that just for PIDE?

 

[Jlandwerlen]

I'm not seeing an override in the PID instruction. Is that just for PIDE?

I believe so. I highly recommend using the PIDE.

 

[saultgeorge]

I'm not seeing an override in the PID instruction. Is that just for PIDE?

I think if you look at the instruction help for PID override is .swm or software manual. I've used it but not much. You'll need FBD language for PIDE.
Hope this helps.

 

[Peter Nachtwey]

First I want to know why because there may be a totally different and better solution.


Given what we know I would override or just set the controller in manual until the event has past and then re-enable closed loop.

 

[mylespetro]

I think if you look at the instruction help for PID override is .swm or software manual. I've used it but not much. You'll need FBD language for PIDE.
Hope this helps.

Looks like the software manual bit is bit 26 of the PID CTL word, so if your PID tag is PID1, you could set PID1.CTL.26 to a 1 to enable software manual.

 

[g.mccormick]

You can set the .SWM bit and then set the .SO to 0. This will put the control loop into manual mode at 0.

 

[Old No. 7]

You can set the .SWM bit and then set the .SO to 0. This will put the control loop into manual mode at 0.

Yes, I'm aware of the .swm and .so fields. I though the bias would be a more appropriate way to do it rather than forcing the loop into manual, writing 0%output, and then putting back into auto.

First I want to know why because there may be a totally different and better solution.


Given what we know I would override or just set the controller in manual until the event has past and then re-enable closed loop.

I knew Peter would demand more info. lol

This is a temperature control loop. During normal operation the control works ok but if parts stop getting loaded abruptly, the system can't respond fast enough and tends to overshoot.

 

[Peter Nachtwey]

I knew Peter would demand more info. lol

That is because there have been too many times when I have given a sub optimal or even wrong answer because the OP didn't give all the facts.

This is a temperature control loop. During normal operation the control works ok but if parts stop getting loaded abruptly, the system can't respond fast enough and tends to overshoot.

Yes! This problem is similar to other problems similar to this one where the rate of change in the load occurs.


If your system only stops and starts then just going into open loop and holding the current output will not work because now there is no load that removes heat. Going in to open loop mode and setting the CV to 0 may work while the line is stopped but then you should restore the control output to its previous value when the line starts up again. This is NOT a static application.


If the line speed changed I would use a feed forward to supply most of the heat in proportion to the line or product rate. If the feed forward gets the PV within 5% by itself then a little proportional gain should be able to reduce the remaining %5 error to an acceptable amount. If not the the integrator must be scaled based on rate as has been discussed on recent threads.


Temperature PID is only simple when the system is static. How is a stand alone controller going to know the rate of product flow?

 

[drbitboy]

If you go with the so-called "velocity" form of PID equation (cf. here), there is no separate bias and I think there is a way to write the CV directly (maybe only in PIDE?).

Also, if it is known when parts start getting loaded again, or perhaps even if not, the code could gradually shift the bias back towards 0, and the integral action would gradually move that bias back into the integral accumulation term.

Or, perhaps an adjustment to the integral accumulation term can be calculated and applied directly cf. here, and below.

P.S. my brother calls me the sub-optimizer, which is why I have so much fun with Peter.

 

[Peter Nachtwey]

One can add a bias to the "velocity" or incremental form of PID. Just don't integrate the bias.

 

[drbitboy]

One can add a bias to the "velocity" or incremental form of PID. Just don't integrate the bias.

The thread is trying to reverse engineer the bias; my point is that with PIDE "velocity" form, there is no bias, or perhaps it's more accurate to say that the last-calculated CV is the bias (i.e. when error is zero).