ControlLogix general + PID "best practices"

Hey fellas,

First off I must I apologize for the length of my post. It's kind of a brain dump I kept adding to as I read through some Rockwell literature and tried different things out in RSL5000 offline.

This all builds on questions I asked in my recent post asking for advice on how to write "cookie cutter" ladder logic for multiple PID loops.

Since this is my first CLX solo, in-house, from scratch, I'd now like to ask for your advice on best/common/accepted practices for such a setup, and some questions in general as well. They may not be in a logical order. It's just how they fell out of my head.

* Rockwell's examples all show actual analog input and output module tags in the PID.PV .CV .SP etc. Is this common practice? We have always used intermediate reals or integers in our PLC5s between actual I/O and the PID, that is. MOV analog input to N7:# to use as the PV and SP and MOV PID output to N7:#, then to the analog out BTW. What accepted or best practice with the CLX?

* I need to be able to give us manual control of each PID output from our hmi. What's the difference pros/cons (and proper use of) of .SWM vs .MO? Both seem to accomplish the same thing. One using the .SO and the other as the tieback for operator input. There's got to be a deeper difference that I'm just not understanding. Maybe I don't completely get tieback.

To do a bumpless transfer from auto to manual and back in our existing PLC5s, I must admit we're stuck in the "we've always done it that way because way back when the OEM did it that way" rut, where .so is moved to .out and vice versa depending on the state of .swm and some other funky stuff. That was 16 years ago. This being a clean slate I want to do it right. What's the accepted or correct method?

* .BIAS is just an offset used for feed forward, correct?

* Triggering the PID by either having it in an STI or Timer.dn? What are the pros/cons? As mentioned before, if I use intermediate tags between real I/O & PID, should those MOVs or COPs also be in the STI? For clarity (thinking 3 am troublehooting here), I'm leaning towards putting everything in subroutines of the main program, then triggering the PIDs with a time.dn.

* If I trigger using a timer I must ensure all the loop update times in each PID are the same as the timer preset. Anything wrong with moving or copying the timer.pre to each PID.UPD? Since the .UPD is buried within the PID tag array, this can't be done with a single COP can it?

* Since I have 18 identical injection nozzles to control, some here have suggested creating an AOI. I've never created one of those. How hard is an AOI to troubleshoot? Can it be modified in run mode? Consider, each injection nozzle has a resin flow meter and control valve, steam flow meter and control valve and a flush water valve. Resin will be PID controlled, although we'll start either fully open or closed. Steam is a slave (percentage) of resin. Some here are worried about me over-complicating things (from the shift techs perspectives) just for the sake of using new functions like this. Me too. I want to make it as simple as possible not just to write but to understand a year from now as well. Since I've only got 18 to do, writing it all out "old school" isn't as bad as I original thought.

*Another suggestion was, once I have one nozzle system figured out, to copy and paste the text for that one nozzle system control to Excel, then run a VB script to replicate it 18 times, incrementing the UDT element number each time. I did this as a test, although I used a test Intouch app script instead of Excel VB. Worked fine. I created the UDT as suggested, made up a bunch of possible rungs including he PID. then ran the copied text through my Intouch app, pasted it back in, and voila, 18 versions. Cool. Thanks.

* Relating to my original question about intermediate tags between I/O & the PID, using these UDT tags, since everything is still in the UDT tag form, I must then tie each to the I/O with either MOVs or making aliases. Any suggestions, tips, tricks?

* If I were to go with the UDT idea and I needed to change something globally, like the update time or tuning values, I'd have to do 18 separate moves or copies. I'm thinking in some instances it would be simpler if I didn't create a UDT but instead created separate tag arrays for each repeated value. Then I could do global changes or move analog inputs to each PV & SP and CV to outputs using COP commands in blocks like this (for 8 ch analog in and out)...

COP(Local:6:I.Ch0Data,AnalogInput[0],8)COP(Local:7:I.Ch0Data,AnalogInput[8],8)
COP(Local:8:I.Ch0Data,AnalogInput[16],2);

or

COP(Nozzle_PID_CV[0],Local:1:O.Ch0Data,8)COP(Nozzle_PID_CV[8],Local:2:O.Ch0Data,8)
COP(Nozzle_PID_CV[16],Local:3:O.Ch0Data,2);

Does that make sense? Is there another way to do stuff like this and still use the UDT? I realize I only have 18 "cookies" to cut out, so it's not like it's the end of the world if I have to move or copy PID I/O individualy.

* Two OEM installations we have here using CLX use MOV or COP blocks at the beginning and end of the main program to mimic the traditional scan flow of a PLC, that is, scan inputs (MOV inputs to input tag array), run through ladder logic using the input tag array and assign outputs to output tag array, set real outputs (MOV output tag array to real outputs). Is this common or accepted practice? I can see how it maintains I/O conditions throughout the ladder scan. Any Pros or cons? I remember this being mentioned in the basic CLX training I took at Rockwell.

* PID Inhold bit & value. This is only for instances when going to run from program mode, right? Also this requires 1756 modules. The oem supplying the nozzle system has their own IO. I don't know if it'll be 1756, but they say it is Cnet compatible and comes with an EDS. I don't swing a very big stick, so that's what I've got to work with.

* Going back to tag organization, there's another point that I must consider. As in most other places, our field devices get assigned some kind of ID number. Here it's a 5 digit number with a 3 letter prefix device type designation. In the PLC5s we always make the input or output symbol match that ID number. That way it can be searched. Not so easy in the CLX is it since I/O are assigned tags. How do you do it? I assume this is where aliases come in.

Example, lets say I have an 8 channel analog input module. Each channel is wired to different devices, each having it's own unique ID number. I guess I have to create individual tags with those ID numbers and make them aliases for the input channels, right? How can those then be worked into the idea of using a UDT for the "cookie cutter"? Or do those aliases do nothing and just serve as searchable tags for troubleshooting, while the real data flow happens as described earlier?

Phew! That should be enough for now As I said at the start. This is my first CLX solo, in-house, from scratch, so I want to do it right. Thus all the questions. Thanks in advance fellas. Your input has and always will be very much appreciated.

On moving/copying data at the end of the program scan, there has been a lot of discussion on this board about that in other threads.

Personally, I only buffer analog input data, or data you will be making calculations on. The CLX will update I/O information not only mid-program, but also as the rung executes.

I first discovered this when I was using an input value to make a calculation on, and limited the calculation to when the value was non-zero. I noticed random spikes in my calculation, and determined that my input value was changing after the Limit instruction, causing the calculation to give invalid results. With digital I/O, it seems to be more a matter of preference.

FYI
Using a Logix Controller for Barrel Temperature Control on Plastic Injection Molding and Extruding Machines (Publication RA-AP015A-EN-P February, 2004)

http://samplecode.rockwellautomation.com/idc/groups/literature/documents/ap/ra-ap015_-en-p.pdf

Thanks for the feedback fellas.

Paul, I'd love to read those threads, unfortunately I'm at a loss for specific keywords to use in a search to find such discussions. Can you provide some links or somehow point me in the right direction.

Interesting example. I never thought of the effect of changes happening mid-rung.

Dan, thanks for the example. Unfortunately I'm not using the PIDE, I'm doing it in ladder with the PID. Interesting reading none-the-less. Thanks again.

Anyone else care to chime in?

I would not use the PID instruction. It is not nearly as stable and useful as the PIDE instruction. I dropped the PID a few years back in favor of the PIDE.

Just an opinion.

edit, I just saw your comment about doing it in ladder. Put the PIDE inside an AOI. Then it can be in ladder. I have done this several times for customers that are allergic to FB diagrams. I make an AOI with ONLY the PIDE inside it. this is then put in a ladder that resides in a program that sits in a periodic task. All the real interface work is in my management AOI that sits in the regular program. (ladder)

Honestly, with my method there is nothing to "see" at the PIDE FB itself anyway. They can go online and monitor the instruction in my ladder AOI.

I realize this may be a bit "over the top" but it works great and standardizes everything. I have several variations of my PIDE management AOI for different customers. Most of my customers have strong management of change policies in effect and like the AOI's.

RSL

RSL said:

...
Put the PIDE inside an AOI. Then it can be in ladder. I have done this several times for customers that are allergic to FB diagrams. I make an AOI with ONLY the PIDE inside it. this is then put in a ladder that resides in a program that sits in a periodic task. All the real interface work is in my management AOI that sits in the regular program.

Click to expand...

Can your AOI be used without the FBD license? Can you still make adjustments to it?

Used, yes. The function Block cannot be edited.

Again, the ONLY thing the PIDE FB does is put the PIDE in the scan. I have a separate management AOI that maps all the variables and manipulates the PIDE commands. Also, the PIDE control tag is ALWAYS available in the database.

I also use an enhanced version of the Rockwell Process face plates in FTView SE and ME to manage my PIDE's. I can setup all the behaviors and even run auto-tune from my HMI's as long as the user has authority, otherwise they do not even know it is there.

I am aware this is a body of work, but once completed it is totally drop in for PIDE control loops. We treat the PIDE as a "Control Module" just like we have AOI's for motor control and analog outputs etc. All of our core functions are AOI's now. The auto-sequence portion of our code is free form and can be in whatever style you like, but basic control functions are all in AOI's with corresponding HMI objects to operate them. We do a lot of S88 conforming jobs for pharma. The principles are still valid in any control problem though. I can go from an I/O list to a functioning ready for I/O checkout HMI/PLC in 8 hours or less usually. (no auto code, just MOA) This also lets us have beginning programmers or office staff map the I/O since it is standardized so well.

I am rambling on, sorry.

RSL