You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old January 12th, 2018, 08:49 PM   #1
Baker in Virginia
Member
United States

Baker in Virginia is offline
 
Join Date: Aug 2016
Location: Virginia
Posts: 193
What is the difference between a AOI and a UDT in RS Logix 5000 ?

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.
  Reply With Quote
Old January 12th, 2018, 09:45 PM   #2
Geoff White
Member
Australia

Geoff White is offline
 
Join Date: Oct 2005
Location: Brisbane
Posts: 272
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.
  Reply With Quote
Old January 12th, 2018, 09:49 PM   #3
matthew1
Member
United States

matthew1 is offline
 
matthew1's Avatar
 
Join Date: Feb 2011
Location: virginia
Posts: 78
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!
  Reply With Quote
Old January 12th, 2018, 10:04 PM   #4
matthew1
Member
United States

matthew1 is offline
 
matthew1's Avatar
 
Join Date: Feb 2011
Location: virginia
Posts: 78
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.
  Reply With Quote
Old January 12th, 2018, 10:06 PM   #5
Mispeld
Member
United States

Mispeld is offline
 
Mispeld's Avatar
 
Join Date: Feb 2017
Location: VA
Posts: 345
Quote:
Originally Posted by Baker in Virginia View Post
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.
  Reply With Quote
Old January 13th, 2018, 07:07 AM   #6
jstolaruk
Member
United States

jstolaruk is offline
 
Join Date: Dec 2004
Location: Detroit, SE Michigan
Posts: 3,244
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.
__________________
"You can live to be a hundred if you give up all the things that make you want to live to be a hundred." Woody Allen
  Reply With Quote
Old January 13th, 2018, 08:53 AM   #7
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 4,384
Quote:
Originally Posted by matthew1 View Post
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.
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
nil illegitimi carborundem


  Reply With Quote
Old January 13th, 2018, 09:09 AM   #8
Rob S.
Member
United States

Rob S. is offline
 
Join Date: Sep 2008
Location: Maryland
Posts: 632
Thanks so much for the helpful information. I need to study up more . If I did more programming it would probably sink in more.
  Reply With Quote
Old January 15th, 2018, 07:42 PM   #9
matthew1
Member
United States

matthew1 is offline
 
matthew1's Avatar
 
Join Date: Feb 2011
Location: virginia
Posts: 78
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)

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?

Quote:
Originally Posted by daba View Post
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.
  Reply With Quote
Old January 16th, 2018, 04:34 AM   #10
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 4,384
Quote:
Originally Posted by matthew1 View Post
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.
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
nil illegitimi carborundem


  Reply With Quote
Old January 16th, 2018, 07:37 AM   #11
Mispeld
Member
United States

Mispeld is offline
 
Mispeld's Avatar
 
Join Date: Feb 2017
Location: VA
Posts: 345
Quote:
Originally Posted by daba View Post
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.
  Reply With Quote
Old January 16th, 2018, 07:47 AM   #12
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 4,384
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).
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
nil illegitimi carborundem


  Reply With Quote
Old January 16th, 2018, 08:46 AM   #13
Mispeld
Member
United States

Mispeld is offline
 
Mispeld's Avatar
 
Join Date: Feb 2017
Location: VA
Posts: 345
Quote:
Originally Posted by Mispeld View Post
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.
  Reply With Quote
Old January 16th, 2018, 09:46 AM   #14
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 4,384
Quote:
Originally Posted by Mispeld View Post
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.
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
nil illegitimi carborundem


  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 11:10 AM.


.