Alaising in RsLogix 5000

[andyhill 1]

Sorry to bu g on this but the previous answer still didn;t graps the problem If I define an array of Int;s in the controller Can I set an Alias to point to Array Element [1] = yes ( no probs at Design time) Can I get the PLC to alter the base Pointer of the Alias to Point at Array Element [2] at runtime = ?? If I could get this to work then all I would have to do is adjust the Alais snd re use code rather than have to to do MOV instruction to copy the data bout in the PLC proir to using it. The whole point of this is to make the same piece of code be used for multile Oil Well with out haveing to move masses of data.

[paulengr 44]

You can't alter the targets of aliases through code. There are three ways at least of doing what you are asking though. The first, most obvious method is to use arrays. This works but it has a huge problem in that you have to copy all your real data variables into the array to make it work. This smells like a lot of MOV instructions and seems very costly in terms of compute horsepower. In practice, it's very small and most Logix 5000 programmers that are doing structured programming don't worry too much about the computational cost. If you start doing modular programming in Logix 5000, you pretty much at some point have to accept the idea that you are going to be lots of data copying but that this is simply a small performance penalty that is balanced against the development/debugging time costs. You can't put aliases into your arrays and there are a number of other stumbling blocks that you've no doubt run into. If you are making reusable code and you put each well head in a separate program, put the aliases into the program variables. Then when you copy the program, you can walk through the alias table and fix up where each alias points while you are programming. There will be ZERO changes to the code itself, since the code operates entirely with aliases. If you develop your code initially with just aliases, then when you copy/paste the entire program, Logix 5000 will effectively prompt you to fill in the missing details. The third method is to code everything into add-on instructions and create a bunch of parameters (or a UDT) which represents your interface. This works even better. You can put an amazing amount of stuff inside an add-on-instruction. It takes a bit of effort to understand them but they operate effectively very similar to functions or methods in any other modern programming language. An add-on-instruction does not have to be a trivial example. The downside is that all of the code inside the AOI is effectively inside just a few routines. You can't fit an entire program inside one and maintain a lot of modularity, unless you create a hierarchy of AOI's. This latter method is perhaps the most powerful since you get the advantage of an alias that can be redefined very easily by simply changing the parameters that are passed to the underlying AOI. It's perhaps a "happy accident" that paradoxically AOI's are the closest thing to a real function call with real parameter references compared with traditional PC programming languages. The biggest downside is that any electrician that sees a program that is entirely contained inside a bunch of AOI's is going to probably go crazy trying to "figure it out" since a lot of the debugging techniques that you can use in Logix 5000 disappear inside the AOI machinery. I'm really, really tempted to use AOI's but I just haven't brought myself to coding this way yet. I'm still holding out on hoping that AB eventually makes aliases true pointers so that they are first class citizens, can be stored in UDT's, repointed on the fly, etc. I recommend a hybrid approach. I'm still mulling over using the AOI approach and haven't used it in my own code yet. I'm still contemplating that one. It works great though if you need a bunch of specialized code for interfacing to some atypical hardware. My hybrid approach is this: For each major type of process equipment, create a UDT with all the parameters to it, such as "WellHead". This UDT will have tags like "Pressure", "RunCmd", "StopCmd", "RunStatus", "PressureHiAlarm", "PressureLowAlarm", etc. Some are "read only" (Pressure, RunStatus), while some are intended as "write only" (RunCmd). Create a tag with your equipment in the controller scope such as "WellField[array]" or "NorthWellHead". You can create a separate task or simply create programs called "equipment" programs. Each equipment program represents one piece of equipment. When you write the program, all references to physical I/O are aliases that are in the program scope. In fact you can write the entire program and associated routines without actually having any references to I/O whatsoever. The equipment programs interact with their corresponding tags in the controller scope. Any internal variables are defined in the program tags area. Now, if you have say 10 well heads, then you can simply copy an existing well head and edit the alias table in the program scope. Creating additional programs is simply a matter of changing the aliased I/O references and creating the appropriate arrays and tags in the controller data scope. And yes, quite often these programs will be little more than 10-20 MOV instructions that are simply copying data back and forth. But the little data massaging things that you have to do such as conversions or zeroing or otherwise fixing up analog variables goes here. In addition, you may also want to consider embedding any low level interlock logic here. It's also a convenient place to put code such as timers which will stop a typical start/stop push button sequence in the event that the auxiliary contact back from the starter doesn't pull in (probably indicating either a disconnect is pulled, loss of power, or a motor protection relay was tripped). Everything else, all of your logic which controls when to start/stop equipment, runs control loops, etc., goes into separate programs. These programs are only allowed to interact with the "equipment" tags in the controller data scope. These programs will typically use indirect addressing through arrays of equipment rather than aliasing because at this point, all variables being pointed to are first class citizens. You don't have the quasi-reference of an alias to deal with.

[andyhill 1]

Thanks for the long reply that seems to clear up a lot of the points. For you information we have already taken the plunge and everything is written (well 95%) using addon instructions and passing in Custom UDT's. I was looking to take the program 1 setp futher and have a single well model being updated through Alaising but looks like I will have to CPS copy the data about if we utilize this unless I can come up with another intresting (& cunning) way of doing it. - Thinking caps on again.... So far our new design for the Wheel is certianly not circular but is working reasonably efficiently Long live the non circular wheel.