Benefits of using tags/aliases vs direct addressing in RSLogix5000

[hboyer90 3]

Hello guys, just had a few questions, wanted to get your opinions on addressing in RSLogix5000 on a CompactLogix L36ERM. So, a little background, we have around 40ish die cast machines in our facility. Up until recently they have all been run by PLC5/30s running RSLogix5. We recently have upgraded 4 of them to CompactLogix L36ERM. For the very first one that I did, I used the program conversion tool so that I could keep the same logic. I had to make lots of tweaks to it and finally got it working correctly. We used direct addressing for that, as in if I have a "Die Open Limit Switch" wired to input module 1, input 5 I would address it in the program as Local:1:I.Data.5 rather than making a tag called "Die_Open_LS" and aliasing it to that address. So, everything was direct addressed, got it running fine, then did the next machine. The next machine had some different i/o so we had to change the addressing a little, maybe now the die open ls was wired into module 3, instead of 1, etc. All of the machines are a little different setup, but mostly the same logic so we just use the last program and make any necessary changes to it and then download it into the newly upgraded machine/plc. So my thinking is that we should just make tags of all of the inputs/ outputs and alias them to whatever address that they are wired into and then address them as the aliased tags in the program. That way whenever we move onto a new machine upgrade we only have to specify the aliased address in one spot, rather than all over the program, and it would be a lot easier. I figure I can even export the tag database and open with Excel and create new tags in there, which would be faster. My question is what are the advantages of using tags/aliases vs direct addressing, other than when the wiring of an input/output changes? Thanks!

[Paullys50 2]

Personally, I use alias tags but not directly on IO. For IO I always buffer it to the AOI that controls the device. I have various input mapping routines for my digital inputs, analog inputs, device feedacks...etc. Same for the output side. I also have AOIs for all of my field devices, as that logic adds additional functionality to my system such as delay on/off, simulation logic, alarms..etc. From a basic perspective, my IO mapping logic for a digital input would be a simple XIC (Local:1:I.Data.5) OTE (LS001.Field_Input) where LS001 would be a tag for my digital input AOI representing Limit Switch #1. LS001.Field_Input is where I feed the field digital input into my AOI logic for processing. The LS001 children are used throughout my program. Child tags might be: LS001.Field_Input (This is where the field IO signal is buffered too) LS001.DelayOn_SP (This is a delay time setpoint, perhaps I want to debounce the signal) LS001.DelayOn_Timer (This is the delay timer) LS001.Simulation_On (This is a simulation bit where I might need to use it during testing, it just a software bypass of the Field_Input) LS001.Alarm_Active (Maybe I want some type of alarm for the deivce) LS001.Delay_Input (This is the state of the Field IO signal AFTER a time delay). Doing it like this gives me additional options for my device, plus if my IO changes, I only have to update the IO buffer routine. I can do this manually, or easily with some scripting in Excel or Python. On large projects, using Excel or Python to create the logic and importing it as an .R5X file can be a real time saver. Edited 26 Oct 2015 by Paullys50

[hboyer90 3]

Thanks for the reply, this may be a newbie question, but what is the "AOI "? How do I buffer it to that? The majority of my modules are either 1769-IA16 (16 Point 120VAC Input) or 1769-OW16 (16 Point AC/DC Relay Output) just in case that helps at all. Thanks

[kaiser_will 65]

I agree with Paullys50...map I/O to controller tags; he is also correct in that I/O changes only require changes in the mapping routine. I also like to make User Defined Tags (UDTs) with fields for items such as alarms (tied to inputs or outputs) and HMI status, such as Paullys50 notes. Where I have been burned before...someone uses direct I/O tags and incorrectly forces an input OFF or ON by using it as a coil. There are many ways you can skin this cat.

[hboyer90 3]

On an unrelated, I want to know where this horrifying saying come from. Who skins cats? How many ways can there be? So many questions.

[hboyer90 3]

But on a related note, can someone help explain to me what user defined tags are and how to use them, same with AOI? All i have ever used on RSLogix5000 is direct addressing and alias tags. Is a user defined tag just when I create a global tag? Thanks

[Paullys50 2]

User Define Tags (UDT) are custom datatypes that you can create. This allows you customize your logic, and make it more legible. UDTs are related to AOIs (add on instructions) as when you create an AOI, by it's definition, it creates a UDT for the specific AOI. AOI - This is like a 'function block' of code, or a custom instruction a user created. Just like the native Timers, Counters and Math instructions, an AOI instruction can be added to your logic like any built-in instruction. The AOI is completely user created, so you can create reusable code. It's an object that you can instantiate over and over again in the logic. So if I have 100 motors in a system, I will need all the control logic for those motors. Start, Stop, speed commands, running feedback, motor disconnect feedback..etc. This is tedious and prone to copy/paste errors. With an AOI, you can write all of this code one time, and turn it into a reusable instruction. So for all of your motors you just call your motor AOI instruction with its pre-built motor control logic and off. It contains all the logic to control your motor. UDT - This is at the tag level. You can create tags already and assign them a built-in datatype (BOOL, DINT, REAL...etc). Well, by creating a custom data type you can create tags with custom datatypes. Say you have a analog input. You know that you will always need the following tags for any analog input in y: Raw_Input : DINT Scaled_Value : REAL Raw_Min : DINT Raw_Max :DINT Scaled_Min :REAL Scaled_Max : REAL If I have 100 analog inputs, it's a chore to define all of these tags for each analog input. By creating a single 'Analog_Input' UDT that contains the tags I require I can create a new tag using my 'Analog_Input' udt as it's datatype. Level_Sensor_1 : Analog_Input. This automatically will create child tags: Level_Sensor_1.Raw_Input Level_Sensor_1.Scaled_Value Level_Sensor_1.Raw_Min Level_Sensor_1.Raw_Max Level_Sensor_1.Scaled_Min Level_Sensor_1.Scaled_Max I can create another tag: Temperature_Transmitter_1 : Analog_Input And it would automatically generate: Temperature_Transmitter_1.Raw_Input Temperature_Transmitter_1.Scaled_Value Temperature_Transmitter_1.Raw_Min Temperature_Transmitter_1.Raw_Max Temperature_Transmitter_1.Scaled_Min Temperature_Transmitter_1.Scaled_Max Read up on AOIs and UDTs in the manuals. They are quite valuable.

[Mr.Lewis 0]

What does everyone think about just rewiring each machine so it has matching I/o? I don't know how many points each machine has, but if it isn't many maybe streamlining you I/o is a good idea too.

[Mickey 71]

On 10/28/2015 at 5:22 AM, hboyer90 said:

On an unrelated, I want to know where this horrifying saying come from. Who skins cats? How many ways can there be? So many questions.

https://www.google.com/search?q=ways+to+skin+a+cat+orgin&rlz=1CAACAQ_enUS727US727&oq=ways+to+skin+a+cat+orgin&aqs=chrome..69i57j0l2.9751j1j8&sourceid=chrome&ie=UTF-8