Compute statement instead of PID - easier?

nicksmick

Member
Join Date
Feb 2015
Location
Dallas TX
Posts
12
I have written control logic for several situations recently where I have used a compute statement instead of a PID loop. My statement looks like:
output = output + (setpoint - actual).

So a situation with a setpoint above actual (temp or pressure or...) will add to the output, a situation with the setpoint below the actual will add a negative, effectively subtracting.

So if I have a large deviation from my actual temperature, or pressure, or level... I change the output significantly. A small deviation changes the output minimally. I do usually add a multiplier to affect how much I change the output. Looks like this:
output = output + ((setpoint - actual)*multiplier).

The multiplier might be a fractional number (0.25) or it might be larger (16). It depends on how my output and input are set up. An input that varies from 0 to 100, with an output that varies from 0 to 100 might have a fractional multiplier, while an input from 0 to 100 with an output from 0 to 32000 might have a larger multiplier.

I use a timer to trigger the statement to execute every second or so.
Below the statement I will have rung to limit the output to a minimum and maximum valve (if output < 0, output = 0, if output >100, output = 100).

It works great and is easy to tune with just a multiplier change. I also can make two compute statements with different multipliers, one for if the actual is above the setpoint, another for if the actual is below the setpoint. (Use a couple of compares LES and GRT to trigger the compute statements. )

I feel that this give me control that I am able to manipulate better than a PID. It works particularly well where the input sensor reacts slowly to the output change.

It has its place. Sometimes PID works better. Sometimes, I prefer computes.

Thoughts?
 
I have written control logic for several situations recently where I have used a compute statement instead of a PID loop. My statement looks like:
output = output + (setpoint - actual).
...

output = output + ((setpoint - actual)*multiplier).

If you only want the integral control mode of PID, this will be sufficient if executed on a reasonably periodic interval.
 
You've written a very simple P controller. It will work in some applications, especially if there is no process lag or transportation lag inherent in your process.
 
it is an integral controller not proportional. a proportional controller would be

output = (setpoint - actual) * multiplier


For the integral term you could also multiply the change in output by time elapsed in seconds since the last time the output was updated so that you can change the execution period independently of the strength of the response.

I have settled on 4 or 5 different AOI/DFB PID forms that suit my applications rather than sorting through the documentation and understanding the interaction of all the different inputs for Rslogix PID and PIDE or forcing the unity PID* blocks to do what I need by manipulating the YMIN, YMAX, YMAN, MAN inputs.
 
it is an integral controller not proportional. a proportional controller would be

output = (setpoint - actual) * multiplier


For the integral term you could also multiply the change in output by time elapsed in seconds since the last time the output was updated so that you can change the execution period independently of the strength of the response.

I have settled on 4 or 5 different AOI/DFB PID forms that suit my applications rather than sorting through the documentation and understanding the interaction of all the different inputs for Rslogix PID and PIDE or forcing the unity PID* blocks to do what I need by manipulating the YMIN, YMAX, YMAN, MAN inputs.

You're right. I stand corrected. Didn't put much thought into that post.
 
I've written a few PIDs from scratch, but wrote one with some advanced features for a project recently using structured text. Scan time improved over using the built-in PID function. Probably never going to use PID again on anything but RSLogix, everything else I'll write it myself.

So yes, +1 to writing your own, so long as you know what you're doing and you get all the timing right.
 
That is cool to roll your own but you'll probably be well served to get familiar with the canned PID blocks. You'll come across them often if you work with other people's equipment and once you understand them, they're quite effective and have a lot of useful features.
 
I'm familiar with the RSLogix ones. I would've used them in the situation I was referring to, but it was on Renu hardware.
 
There are so many different types of PID. Do you know which one to use for any particular application? How about handling integrator windup? When do you need to use an integrator or derivative gain? What about the second derivative gain? The derivative gain is multiplied by the error between the target speed and actual speed or rate of change of SP minus the rate of change of the PV. How do you calculate an accurate rate of change in the PV? Do you need to?
What about derivative kick?

The SLC500 and MicroLogix PIDs are pitiful. I think they use integers for all their math. I wouldn't use the 'canned' PIDs that come with these PLCs.
I haven't played with a RSLogix 5000 type of PID. Hopefully they use floats.

If I were using a Siemens PLC I would write my own.
How much code can you put in a compute block?

Obvious, I write my own for our motion controller. We support a couple different versions of PID plus feed forwards.
 
What you describe is called ether "integral" control or "floating control with proportional speed". (See attached.)

I rarely use PID. I use floating control similar to yours, with either fixed increment or proportional speed output. In addition to the time delay between control iterations I also add a deadband (tolerance zone).

Some claim that the difference between PID and this method is minimal. I don't really care. My experience is that this provides control that is easier for operators to tune and more stable than PI or PID algorithms. I have found this to be particularly true for systems with long response times.
 

Similar Topics

I am trying to add 9 DINT values with the CPT instruction in ControlLogix and I keep getting errors. I am just choosing each tag with an add...
Replies
13
Views
2,256
I am using a legacy Allen Bradley PLC5/40E Series F CPU Having issue with compute instruction syntax with the expression Doing a divide by...
Replies
7
Views
1,719
I've got a print-out of old code (PLC-5/250) that I am trying to decipher. I am hung up on an expression in one of the compute blocks. The block...
Replies
7
Views
2,911
PLC: Compact Logic 1100 series b RS Logix 500: version 8.40 Issue: No compute Instruction, it is greyed out and I can't use it. Why? Thanks
Replies
6
Views
2,136
I have a flow meter that has pulses coming into a ML 1500 HSC at 3238 pulses per gal. Can someone give me a little direction on how I should...
Replies
5
Views
1,966
Back
Top Bottom