What is the difference between a AOI and a UDT in RS Logix 5000 ?

Join Date
Aug 2016
Location
Virginia
Posts
343
Good Evening ,

I still have many "Mental Blocks" when it comes down to programming. Could you tell me the difference between a UDT and a AOI , and why would they be used ? I understand the AOI , a little . I guess it is a pre-canned code that you know that works , and you insert that into your code without re-writing it , correct ?

What is the purpose of a UDT , and it's benefit's ?

Thanks so much in advance.
 
A UDT (user defined type) is a memory structure that can be used to aggregate different bit of information into a single block. It is especially useful where you need to have the same information available for multiple instances. You can make arrays of them and even include UDTs inside UDTs. You can copy from one instance of a UDT to another of the same type. You can pass a single UDT instead of a bunch of separate bits.

An AOI is effectively an UTD with logic associated with it.

Practically everything you access in RS5K is a structure of some type. There are definitions for IO and all the instructions. The only difference is they are system defined structures versus User Defined.
 
A AOI (Add On Instruction)is a (Function)block of code that can be used over and over. The only difference is what the input and output parameters are linked to in the user program.

An example would be valve control and alarming for position for 100 valves. Instead of creating say 15 rungs for every valve resulting in 1500 rungs you can create those 15 rungs once in an AOI. After creating an AOI you create 100 rungs AOI on each then just link the tags for each valve to the input and output parameters.

UDT (User defined Data Type)would be useful in the same way. instead of creating the Tags for each valve one at at time you can create your own structure with tags that can contain different data types. Then you only need to create a tag for each valve and associate the UDT with that tag and all the tags are created instantly. Also if you need to add a tag to the valve(s)you would only need to add to the UDT and all of the tags that are using that data type update automatically. If you have 100 valves that is a time saver!
 
Forgot controller to controller communication. If controller A is in controller B communication tree and controller B in in controller A communication tree. After configuring the Module Properties in each you create a UDT in each controller with the EXACT name and EXACT tag structure they will populate data to each other without any other setup or programming. Provided that they are on the same network of course.
 
Could you tell me the difference between a UDT and a AOI , and why would they be used ?

While it is tempting to just point toward a bunch of Rockwell manuals, which explain these topics in great detail, that would be someplace to go when it is time to put these tools into practice.

Instead, I will take the approach of pointing out what is common: both the User Defined Type (UDT) and Add-On Instruction (AOI) allow the programmer to extend basic building blocks in the Logix environment into more complex elements that can be easily dropped into your programs.

In the case of a UDT, you are taking the basic data types -- integers, reals, booleans -- and combining them to create a new, more complex data type. Then you can create a Tag using the UDT just like you create tags of native types like DINT, REAL, BOOL, etc.

The STRING data type is an example of a UDT, though it is supplied with the Logix programming environment. Nevertheless, it is UDT-like because it consists of an array of short integers to hold the characters, and a separate integer to hold the length of the string. So when you create a STRING tag, you are actually getting an 80-element array of SINTs and a DINT tag to store the string's actual length.

A primary reason to bother with UDT-based tags is that it allows you to collect related data in one unit. You can then pass that collection as a single tag to subroutines, other processors, and instructions, including AOIs. Even if not used for sharing data, the UDT is a method to make programs more readable by keeping closely related data items together.

Similarly, with the AOI you are extending the Logix environment, but from an instruction/logic standpoint rather than data type/collection. The AOI is basically a collection of logic -- like a subroutine -- that performs a specific task common to your application. Unlike a subroutine, Logix allows you to package AOI logic in a such a way that you can drop into a program just like it was a native instruction that came with Logix. It will typically have input parameters, output parameters, and maybe status bits.

I am glossing over many details, especially related to subroutines and AOIs. These are well covered in the Rockwell manuals, as wells as threads in this forum. The general idea is that the AOI should do specific task, is well-tested, and not subject to frequent change. It can then be reliably used in multiple places in your application environment, as well as shared with others.

I hope this attempt to "scratch the itch" of UDT versus AOI was helpful. I'm sure there will be other perspectives toward understanding these topics.
 
Simple example:

Timers and Counters are UDTs (system defined). RSLogix 5 and 500 had them.

RSLogix5K allows you to create you own.

AOIs are the next step - attach code to your UDT.
 
Forgot controller to controller communication. If controller A is in controller B communication tree and controller B in in controller A communication tree. After configuring the Module Properties in each you create a UDT in each controller with the EXACT name and EXACT tag structure they will populate data to each other without any other setup or programming. Provided that they are on the same network of course.

You mentioned "Module Properties", and I assume you are talking about IO Modules.....

This has absolutely nothing to do with UDTs, and there is no reason or need to put either controller in the others configuration tree.

You are talking about "shared ownership" of I/O modules, so that both controllers can use the same module....

Firstly, you can only do this for INPUT modules. You put the Input Module into the configuration of both controllers, and providing module configuration is identical bot controllers will become the "owner" of the module. It will continue to produce Input data when it has at least one owner-controller still connected. To ensure identical configuration, it is easiest to create and configure the module in just one controller's project, then copy/paste it to the other controller IO configuration.

The ONLY time you need to put controllers in the IO Configuration tree, is if you want to use Produced and Consumed tags.

If your mention of "Module Properties" was in error, and you were talking about Produced/Consumed tags, then your statement that "they will populate data to each other" is not correct - it is not a two-way thing.

As stated above, the "Producer Controller" always needs to be in the "Consumer Controller's" IO configuration, and the respective tags, Produced tag in the Producer Controller, and Consumed tag in the Consumer Controller, have to have the same size and structure, the names need not be the same, but I find it helps keep things clear if they are. Produced/Consumed tags can be any data type (except BOOL), and can be Pre-Defined types, or User-Defined types.

There is a little more set-up than you infer.....

In the Producer, you have to configure the tag to be produced, and specify for how many Consumers.

In the Consumer, you have to configure the tag to be consumed, and specify the name of the producer controller, which you get from the IO Configuration tree.
 
Thanks so much for the helpful information. I need to study up more . If I did more programming it would probably sink in more.
 
Yes Im talking about setting up for produced consumed tags. The "Module Properties" I refereed to were for the Ethernet module properties. Yes I skipped the producer and consumer tag set up using the UDT as a data structure. Mentioned this use as a example of what they are/can be used for not as a guide on how to set up the communications. (Obviously)o_O

My mistake on stating there is no other programming/setup required, took for granted the tag configuration. Thank you for the correction so as to not mislead anyone.

Im not going to edit my post because you did a better job explaining it anyway.

Also no the tag name does not need to be the same BUT the UDT name and structure does. When you stated that "the names need not be the same" were you talking about the tag name?

You mentioned "Module Properties", and I assume you are talking about IO Modules.....

This has absolutely nothing to do with UDTs, and there is no reason or need to put either controller in the others configuration tree.

You are talking about "shared ownership" of I/O modules, so that both controllers can use the same module....

Firstly, you can only do this for INPUT modules. You put the Input Module into the configuration of both controllers, and providing module configuration is identical bot controllers will become the "owner" of the module. It will continue to produce Input data when it has at least one owner-controller still connected. To ensure identical configuration, it is easiest to create and configure the module in just one controller's project, then copy/paste it to the other controller IO configuration.

The ONLY time you need to put controllers in the IO Configuration tree, is if you want to use Produced and Consumed tags.

If your mention of "Module Properties" was in error, and you were talking about Produced/Consumed tags, then your statement that "they will populate data to each other" is not correct - it is not a two-way thing.

As stated above, the "Producer Controller" always needs to be in the "Consumer Controller's" IO configuration, and the respective tags, Produced tag in the Producer Controller, and Consumed tag in the Consumer Controller, have to have the same size and structure, the names need not be the same, but I find it helps keep things clear if they are. Produced/Consumed tags can be any data type (except BOOL), and can be Pre-Defined types, or User-Defined types.

There is a little more set-up than you infer.....

In the Producer, you have to configure the tag to be produced, and specify for how many Consumers.

In the Consumer, you have to configure the tag to be consumed, and specify the name of the producer controller, which you get from the IO Configuration tree.
 
Also no the tag name does not need to be the same BUT the UDT name and structure does. When you stated that "the names need not be the same" were you talking about the tag name?

Yes, I most definitely meant tag name, they can be different in the Producer and Consumer.

But I have just done a further test, and the data-type names do NOT need to be the same. I set up a producer tag, called "Produced" of data-type Prod_Data, that contained one SINT, one INT, one DINT, and one REAL.

I copied that data-type to the Consumer, and then changed the data-type name to Cons_Data. I created the consumer tag, called "Consumed", pointing it at the "Produced" tag in the producer.

So now I've got an identically structured Producer/Consumer where both the UDT structure names, and the tag names, are different in the Produce and Consumer, but it still works.

It just checks on the data size, which I tested by re-ordering the UDT member names in one CLX, (keeping the UDT size the same), and the connection still worked. This will obviously cause data corruption, but tells me that it is just size that is important.
 
But I have just done a further test, and the data-type names do NOT need to be the same. I set up a producer tag, called "Produced" of data-type Prod_Data, that contained one SINT, one INT, one DINT, and one REAL....
.

I'm curious as to the firmware rev of the consumer? In rev 20 and earlier I have definitely run into connection failure until I made sure the UDT was identically named on both sides.
 
They are both Rev 20.04

But let's be honest.... no-one in their right mind would create two UDT's of the same structure, and give them different UDT names.

The most easiest way to ensure identical structure is to create the UDT once in one project, then copy/paste it to the other. That way the name sturcture and size has to be identical.

It's a similar concept to when you want to share an INPUT module between multiple controllers. The configurations in multiple controllers must be the same - so you create and configure the module in one controller, then copy/paste it to the other(s).
 
I'm curious as to the firmware rev of the consumer? In rev 20 and earlier I have definitely run into connection failure until I made sure the UDT was identically named on both sides.

This is wrong with respect to produced/consumed tags. The problem I experienced was explicit message (MSG) failure when source and destination tags had differently named UDTs. (extended error code 16#0000_2107) It came up when one programmer preceded UDT names with "udt_" and another with "udt" without the underscore.

Should have checked before writing.
 
This is wrong with respect to produced/consumed tags. The problem I experienced was explicit message (MSG) failure when source and destination tags had differently named UDTs. (extended error code 16#0000_2107) It came up when one programmer preceded UDT names with "udt_" and another with "udt" without the underscore.

Should have checked before writing.

Yes, I have tested that aspect (Rev. 20.04) ...

For explicit messaging, the UDT names, and therefore the data-types of the messaged tags must be the same or you get the 16#0000_2107 error.

As I've already stated, I would only create the UDT once, and copy/paste it to the other project - guaranteed way to make the name, and it's structure, identical.
 
Simple example:

Timers and Counters are UDTs (system defined). RSLogix 5 and 500 had them.

RSLogix5K allows you to create you own.

AOIs are the next step - attach code to your UDT.

I think you've got it backwards here. Timers and Counters are system defined AOIs, not UDTs. They're AIOs because they have logic "baked-in" for the output parameters once you provide your input parameters.
 

Similar Topics

Good Evening , I’m probably entering the most challenging stage of programming I have ever attempted . It is probably easy , and easily...
Replies
8
Views
4,056
Hello, I have a problem with AO- and AA-Tags. When I use for example the tag AO_Test with the address 200 and type the value 1,2 in, the AA-Tag...
Replies
7
Views
1,386
As per the title. This might seem like a basic question to many, but I'm unclear about the difference between a coil ( ) and an application...
Replies
28
Views
3,931
Good Morning , I have 2 Frequency Drive panels to build and commission . It is for 2 pump systems . Just wondering , what is the...
Replies
4
Views
1,940
Hi Experts, Good day! What are the differences between PCS7 SIMATIC Batch and PM Control? Do you have any manual like "Getting Started "...
Replies
0
Views
775
Back
Top Bottom