wildswing
Member
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.
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.
Last edited: