Avoiding pid blocks for contrologix 5000

[snapsalive]

HI ALL,

I am trying to write a program with rslogix 5000 for contrologix is there any other ways to modulate a valve with out using PID blocks.

from the control narratives it is stated that an input functional block receives analog signals from flow transmitter and a reverse acting PI controller modulates the valve and gives out signal to an output functional block. please what are these blocks

 

[snapsalive]

please i need you guys to guide me on this i have exhausted every material i have

 

[Ron Beaufort]

I am trying to write a program with rslogix 5000 for contrologix is there any other ways to modulate a valve with out using PID blocks.

some folks here will suggest "roll your own" ... personally I'm curious as to why you want to avoid using PID ...

from the control narratives it is stated ...

can you post a link to that source? ... maybe it will help us understand your questions ...

an input functional block receives analog signals from flow transmitter and a reverse acting PI controller modulates the valve and gives out signal to an output functional block.

almost certainly they're talking about "blocks" which are available only in the Function Block Diagram programming language – but NOT in the Relay Ladder Logic programming language ...

do you have the FBD option installed? ... if you bought the lowest priced flavor of RSLogix5000 then you probably don't have this option ... (you have to pay extra to get it) ... the screen shot below will show you how to tell how much horsepower you have available ...

TIP: as with many of life's experiences, just because you CAN do something doesn't mean that you SHOULD do it ...

please what are these blocks

technically speaking, of the "items" you mentioned, only the PIDE and the PI would be referred to as "blocks" - since they can be used in Function Block Diagram programming ... on the other hand, the PID can only be used in Relay Ladder programming - so most people wouldn't call that a "block" ... the term "instruction" would be more common ...

suggestion: click the Help selection on the top menu for RSLogix5000 ... then Instruction Help ... next click the Alphabetical Listing link (it's green – in the text - near the top) ... then navigate to PID, PIDE, and PI ... note that you'll be told where (or where not) each instruction can be used ... for example: the plain-old everyday PID can only be used in Relay Ladder Logic – not in Function Block Diagramming ... etc.

suggestion: you're probably NOT going to like the PIDE and the PI ... I'm just guessing (based on what you've posted so far) that using the PID in Ladder Logic is going to be more attractive to you ...

if you'll tell us more about your project, then we might be able to offer more help ...

going further ... welcome to the forum ... and also please remember the time zone changes ... although the forum is world-wide, many (most?) of the regular members were asleep when you made your original post ...

.

 

[snapsalive]

Thanks for replying me,below are part of the narratives for a single operation
the program should be written in ladder not function blocks
please help me with the two sections


Process Control Objective

To maintain a continuous, rated seawater flow through each Injection line.


Implementation
It is assumed that a linear flow signal is received by the input functional block, FI-901 from the turbine flow transmitter FIT-801. A reverse acting PI flow controller, FIC-801, will modulate the flow valve by an output functional block, FO-801. The electrical output of FO-801 to the valve FV-801 shall cover the full input range of 4-20 mA to I/P transducer, tagged FY-801. Other functional blocks shall be added for PI tuning, Manual/Auto selection, error calculation and gain control.
The functional block of setting the set point of FIC-801 controller receives the output signal from the Min Selector FBS-800, implemented as per template 016.
On Manual, a functional block shall be accessible to operator for manual control of flow valve, for operational and testing purposes. If the flow controller is placed into manual, to enable bumpless transfer back to auto, its output will track the flow valve. On return of control to auto mode the valve that is being tracked will ramp to its selected controlled position.
Alarms and settings where applicable are as shown on the P&ID.
Action of the valve on controller failure: FV-801 Fail Closed






Process Control Objective

To control the inlet rate seawater flow through hyper-filter during normal filtration and to isolate the hyper-filter by closing the flow valve during backwash cycle.

Implementation
During normal process, the seawater flow rate through hyper-filter is controlled by a reverse PI flow controller FIC-720 with its set point able to be driven remotely by PIC-726A. When the backwash sequence of hyper-filter is initiated, the set point value of FIC-720 will be subdued by UC-001 to closing the controlled flow valve, consequently to shut off the inlet of hyper-filter. As long the flag of backwash cycle will be active for UC-001, the flow valve will remain closed. When the flag is deleted by the batch controller UZC-720, the logic controller UC-001 will not accept another flag till it opens the flow valve, 005-FV-720, at its initial set point and mode (local or remote). The flow controller, FIC-720, shall track the flow valve position to enable the bumpless transfer on Auto. A confirmation of this transfer to UC-001 shall make this logic controller ready to receive another request of backwash cycle for the next hyper-filter.

 

[Ron Beaufort]

DISCLAIMER: the following is all GUESSWORK based on what you've posted so far ... you should correct anything (point by point) that I've guessed wrong ...

(1) you've been given the task of programming this equipment ...

(2) someone has written a "functional specification" (the text that you've posted above) as to how the equipment is to be controlled ...

(3) the person who wrote the "functional specification" probably had some hardware platform in mind OTHER THAN Allen-Bradley's ControlLogix platform ...

(4) someone has now decided to use Allen-Bradley's ControlLogix hardware platform to control this equipment ...

(5) the "functional specification" probably was intended to use some type of Function Block Diagramming (FBD) programming language ...

(6) someone has now decided to use Relay Ladder Logic programming (instead of FBD) to control this equipment ...

(7) you're now forced to wonder how to satisfy the "functional specification" – written for a different hardware platform – and written for a different programming language – by using an Allen-Bradley ControlLogix system and the Relay Ladder Logic programming language ...

so ... am I even close? ...

questions for you:

(a) what's your deadline on getting this project done? ...

(b) has the bill of materials already been written? ...

(c) has any of the hardware already been ordered? ...

(d) why are you determined to use Relay Ladder Logic rather than Function Block Diagramming? ...

I'll be offline for most of the day, but if you'll answer the questions I've asked, someone else will probably be along to help ...

good luck with your project ...

 

[snapsalive]

dead line is december,hard ware has been ordered already

as to the original intent of the design spec,im not sure of this i only inherited this project at this stage.

i want help in knowing what the logic will look like in ladder

thanks

 

[Tom Jenkins]

I have hundreds of feedback control loops running all over the world. Very few of them are PID or PI, and those exist only because some desk bound engineer insisted that following the spec was more important than making the system work.

So, the answer to your initial question is: Yes, there are many other ways to modulate a valve.

I personally don't like PID control. It is too hard for the typical operator to tune, and a small industry has grwon up in tuning books, ariticles, and "self-tuning" PID software. PID is unstable if tuning isn't decent, it is poorly suited to slow response systems, and it doesn't work well with non-linear response. Unfortunately, many engineers think "PID" and "feedback control" are synonyms. They aren't!

Sometimes a simple deadband control, like a home thermostat, is sufficient. My usual preference is floating control with a bandwidth: http://controltrends.org/tag/floating-control/

I realize that for some tasks PID is just fine or even preferred. Mostly it is a historical artifact, a legacy of the days when most controllers were pneumatic.

 

[MasterBlaster]

I find that in may cases a simple proportional control works best. Simple ladder logic can be used to determine the amount of "error", then calculate a desired percentage of that error (example: 10%) and either add or subtract that percentage from the control signal (as appropriate).

Example: Flow is greater that setpoint by 15%. Ten percent of 15 is 1.5, so subtract 1.5% from the control signal to the valve. Repeat at a rate appropriate to the response of the system. Viola!

 

[Tom Jenkins]

And that, MasterBlaster, is essentially floating control with proportional output. It works great, and tuning consists of tweaking with the percentage and the time delay. Both are fairly intuitive for operators, and if you are off a little you don't get wild hunting up and down.

One refinement I add is to use a slightly different percentage going up from going down. That helps even more to eliminate hunting and overshoot, since if your percentage is off a little the output will work it's way to the right spot after two or three cycles. One other refinement is adding a tolerance. If the controlled variable is within plus or minus of setpoint I don't bother changing the output. This also adds to stability.

 

[snapsalive]

Thanks all for your replies but the template i posted is just two out of quite a number of them the method described by masterblaster might be a little difficult when there a various feedforwards, and cascade loops,
i am still open to advise

thanks

 

[Lancie1]

It is assumed that a linear flow signal is received by the input functional block, FI-901 from the turbine flow transmitter FIT-801. A reverse acting PI flow controller, FIC-801, will modulate the flow valve by an output functional block, FO-801.

Snapsalive, to me, these look like the standard P&ID "blocks" seen on process flow drawings all over the world. Someone (an instructor?) has chose to describe these as "functional blocks" which is technically correct but could be confusing to someone thinking in terms of PLC program function blocks.

For your ladder program, simply use the PID instruction and set the "D" (derivitive) parameter to 0 for the PI-only functions. It might help to look up the ISA definitions for some of those "functional blocks":
FI-901 = Flow Indicator #901 (simply scale the analog input and display it)
FIT-801 = Flow-Indicating Transmitter #801 (this will be a flow rate analog input to your PLC).
These two are simply inputs and all you need to do is get them into your PLC as analog inputs and then scale to the desired engineering units.

FIC-801 = Flow-Indicating Controller #801. Controllers need outputs. Use a PID instruction on this one.

Other functional blocks shall be added for PI tuning, Manual/Auto selection, error calculation and gain control.

This is a lesson or assignment to learn about P&ID drawings. You will need to learn how to make P&ID blocks for each function. I hope you have had some training in these. You definitely need some Instrument Society infomration. This drawing might help with the instrument block symbols:

http://www.google.com/url?sa=t&rct=j&q=instrument%20society%20of%20america%20symbols&source=web&cd=1&cad=rja&ved=0CC4QFjAA&url=http%3A%2F%2Fprojects.ch2m.com%2Fhnl_AFCEE%2Fto106%2FTO106_As-Builts_P%26ID.pdf&ei=lnJ1UN2BCpSK9gTVhIDwBA&usg=AFQjCNFY9nfhUahoTlndHAHqSprKPqDpJg

 

[Ron Beaufort]

I'm having to do a LOT of "reading between the lines" here – but –

(1) I'm GUESSING that somewhere there's an engineer who is in charge of a BIG project – and that the thread we're dealing with here represents just a small PART of that big project ...

(2) I'm GUESSING that sometime in December that engineer is going to show up on site – and expect this small part of his big project to be working ...

(3) I'm GUESSING that this small part of the big project is going to have to "mesh" or "dovetail" with other parts of the big project ... (note the reference to "batch controller UZC-720" in the specifications given in Post #4 – which I'm GUESSING is a separate controller external to the small system that we're discussing in this particular thread) ...

(4) I'm GUESSING that the engineer had some particular reason to specify things such as FIC-801 ... (which as Lancie1 has pointed out, stands for Flow INDICATING Controller #801) ... so now I'm GUESSING that the "indicating" part of that controller is going to be some type of HMI device – possibly a PanelView that we haven't seen mentioned yet ...

(5) I'm GUESSING that the engineer who wrote the specifications might possibly have intended that this system be built around "stand alone" controllers – specifically, NOT using a PLC at all ... in which case the FIC-801 specification would make a lot more sense – because those usually have the INDICATING function right there on the faceplate ...

Lancie1 is correct ...

Snapsalive, to me, these look like the standard P&ID "blocks" seen on process flow drawings all over the world. Someone (an instructor?) has chose to describe these as "functional blocks" which is technically correct but could be confusing to someone thinking in terms of PLC program function blocks.

and assuming that I am the "instructor" intended above, let me point out that we hadn't been given the functional specifications (in Post #4) when I made a good-faith effort to decode the OP's meaning in my Post #3 ... in other words, my crystal ball was cloudy ...

but ...

even now that we DO have the functional specs (at least SOME of them) I'm still not sure about some critical aspects of this thread ...

the thread's title is "Avoiding pid blocks for contrologix 5000" ...

I'm still forced to wonder WHY snapsalive wants to "avoid" using the PID ... and please notice that snapsalive himself was the one who cast the BLOCKS idea into the stew ...

moving forward ...

personally, I think it would be a good idea to fully identify the target – before shooting from the hip ...

I hate to make this next statement because I know that it might be misinterpreted ... but I sincerely mean absolutely no offense ... and - this is something critical if there's to be any chance of meeting that December deadline ...

I've got a hunch that our new member isn't ONLY asking about how to "avoid using PID" – and how to get his FLOWS under control ...

I've got a hunch that he's ALSO concerned (possibly even MORE concerned) with how to sequence all of the REST of the controls – such as those "flags" and "backwash cycle requests" and so forth mentioned in those specifications ...

personally, if I were you snapsalive, I'd get in touch with whomever is going to show up in December – and ask them just what they're expecting to see (hardware, etc.) and whether a ControlLogix is going to fit in with the overall plans for this project ...

for one MAJOR consideration, will there need to be an HMI (PanelView, etc.) and will you need to incorporate any logic for THAT into your part of the project? ...

keep in mind something that Tom Jenkins said back in Post #7 ...

... some desk bound engineer insisted that following the spec was more important than making the system work.

trust me ... you do NOT want to spend your time finding ways AROUND the specs – IF (that's a big IF) someone might arrive on "startup day" and tell you that your work doesn't meet the specs – and that it will have to be done over ...

suggestion: is this the FIRST system of its kind – or is there possibly some previous documentation that you might be able to use as an example of something ACCEPTABLE to help you get started? ...

 

[Lancie1]

the thread's title is "Avoiding pid blocks for contrologix 5000" ...

I'm still forced to wonder WHY snapsalive wants to "avoid" using the PID ... and please notice that snapsalive himself was the one who cast the BLOCKS idea into the stew ...

Ron, I think it was a bad interpretation by Snapsalive. The specs by themselves do not say that PID blocks should be avoided. In fact, this "lesson" is all about learning how to interpret P&ID blocks from engineering drawings. All we have about avoiding anything is this:

The program should be written in ladder, not function blocks.

Of course, that statement does NOT rule out using the PID instruction in ladder logic. The PID instruction has been a part of the Allen Bradley ladder logic as far back as I can remember, certainly long before PLC function blocks were available. But Snapsalive incorrectly thought that the statement means to avoid PID instructions totally! NO, big first mistake.

 

[snapsalive]

Thanks all for the very useful information
this project is a very huge one and as right said my initial thread is only a piece of the entire functional spec.

the functional spec was developed by an independent third party engineer hired for detailed engineering purpose and has been adopted by the company.

I realize that it is almost not possible to do without PID blocks but wanted to completely explore that option.

however i would still be needing help on simple techniqes to get this rolling

I thank you all

 

[Lancie1]

the functional spec was developed by an independent third party engineer hired for detailed engineering purpose and has been adopted by the company.

So he wants ladder logic. Give him ladder logic (with the included PID instruction that is a part of ladder logic).