RSL5000 PID & general best practices

[wildswing 0]

Helo again fellas, This post builds on questions I asked in my recent post asking for advice on how to write "cookie cutter" ladder logic for multiple PID loops. Turns out there's only going to be 18 or 19 PIDs, not 80 like I was originally told. Sorry for the length of this post. It's a brain dump that just kept getting longer. Since this is my first CLX solo, in-house, from scratch, I want 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 for going in/out of manual with bumpless transfer? * .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, I've received suggestions to create 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 (or some sort of incrementing loop). 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? 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.

[Michael Lloyd 85]

If I were you I would take a look at the PIDE function block. I can send you an example of how I do pId loops in CLX if you are interested. From what I just read your about to make something simple needlessly complex

[wildswing 0]

That's exactly what I'm trying to avoid. I'd like to make it as short & sweet as possible, but still keep it readable & user friendly for the guys at 3 am. Edited 12 Oct 2011 by wildswing

[Michael Lloyd 85]

Bummer. When you don't have FB and Structured Text language in CLX you lose a lot of functionality and power. I've honestly never heard of anyone that didn't have the capability to use FB and ST. Especially an integrator. I'm pretty sure I called PIDE in ladder when I first used CLX. What version are you using? I'll put an example together for you.

[wildswing 0]

v16. Seeing just a basic example of how others (the pros) do it right would go a long way. Thanks. Edited 12 Oct 2011 by wildswing

[Michael Lloyd 85]

Ah... I understand. I'll put something together and send it to you. IMHO the worst thing you can do to yourself is program the CLX like an SLC or PLC 5.

[PLCMentor.com 60]

I was going to suggest the PIDE also. I must admit, the CLX PID instruction does have enough bits and words to make it a little confusing. A little like directing a client to which version of programming software they need. I agree that as an integrator you need to have all the programing languages at your disposal. There are times that I am limited due to the clients restrictions however. I have often thought that putting the PIDE in a AOI would be interesting, but have never had to do it. Those thoughts aside, there are several points that you mentioned that I can make an immediate response to: 1. Do not use timers to handle your PID timing. The CLX has wonderful abilities for periodic program files - use them. 2. I do not copy my I/O in and out of tags to get around the async. read/write of the CLX and have never had problems. I know many programmers that do and I guess it works for them. For me it seems an unnecessary additional step. I do use aliases for all my I/O to give them meaningful tags. 3. Use UDTs, use UDTs and use them some more. It will do wonders to simplify your programming. Just the load it takes off of putting descriptions in your program is enough to make them worthwhile. They do need to be well thought out. 4. If you are stuck with ladder, there is an AOI for scaling that is useful. You should grab it. 5. Be careful with AOI's. Something simple like the scaling example mentioned above is great. More complected AOI's such as what you look to be working towards are a pain. There are times that they are OK, but they better be well tested because you are not changing them on a running system. You will have to change them offline and dump the program back to your processor. You do not want that. I would be interested on hearing from anyone that has a strong opinion on AOI's versus a standard subroutine. I really dont see the advantage to the AOI when I should be able to call a subroutine from multiple routines as needed. I guess you would have to have a copy of the subroutine in each task if it is necessary across different tasks. I dont really see a huge advantage in the AOI's for most circumstances. 6. I dont use real world I/O in my UDT's by copying. Never have seen an advantage in that. I use the UDT for the bulk of the variables needed, and name my tags for the I/O similarly to the UDT tagname. So for a motor, I might have M100_out for the output and M100_aux for the aux and then M100 UDT for all timers, command bits, permissive bits, pushbuttons from the SCADA, etc. @Michael, I would also be interested in seeing how you handle your PID in the CLX. From what I have seen, there seem to be as many ways to handle PID's as there are programmers. High amount of flexibility I guess yields a high amount of variation.

[Michael Lloyd 85]

I agree with all of the above points. I recently started building AOI's and I like using them. I can't say they are much if any faster to implement but they are clean and simple. Another plus is being able to build a routine using ST and then protecting it. Doing so let's me share the routine without being concerned that the user might change it have problems. I have a Rev 19 file that I could send you, if you're at a lower rev I can create something that you can open. Pm an email address and rev level and I'll send you something. I'm in the field today so there might be a delay There are a lot of ways to skin a cat in CLX and most of us think our way is the best. I like look at other people's programming style. I've learned a lot from that.

[wildswing 0]

Excellent post Russel. Thanks very much. That's the kind of feedback I'm looking for. Everyone here has become comfortable in our "always done it that way" PLC5 bubble, so I need to push our envelope a little with the programming for this project, but do it in just the right way. Writing something that only I will understand might satisfy my inner geek, but won't do me any good when others refuse of dig into it and would rather call me at 3 am.

[wildswing 0]

Michael, check your email.

[Ben 1]

Gentlemen, I was reading this interesting post as I am also working with PIDE for the first time. PIDE has many advantages line cascade/ratio control, bumpless transfer etc. But, as correctly pointed out, there are so..many parameters, difficult to digest all at once. I guess putting the PIDE in periodic task, the easiest way to run but it asks for the input (PV) update to be faster then the periodic task. Depending upon the filter setting for the channels of AI card, the Real Time Sampling would be some number. I guess the periodic task timer should be set higher then this value. If you guys can share the PIDE you used, it would be great help.

[wildswing 0]

Hi Ben, I haven't decided on exactly how we're going to do this yet. I've been sidelined with another project. I'll be coming back with more questions very soon. For everyone else, in the mean time, can anyone comment on one of my original questions please... FYI, I ask because when we first come ahead with this system, all control will be either ON or OFF, so PIDs will be in manual and valves will be either 0% (closed) or 100% (open).