[Logix] UDT and lack of aliasing

defcon.klaxon

Lifetime Supporting Member
Join Date
Feb 2015
Location
Far NorCal
Posts
616
Hi guys,

I'm experimenting with creating UDTs but am coming across some challenges, and thought I'd ask for some help after some unsuccessful Google searches.

So I've created a UDT for all the different hardware instances in my project; Pump, Ultrasonic Level, Flow Meter, etc. Since each instance has very similar tags, creating one UDT can essentially create all the tags I need, so great. I've also created UDTs for common functions, like ETM and NOS for pumps, and Alarms and include those inside the hardware UDTs. It creates everything I need very nicely, but I'm having issues with getting data into those tags now that they're created. I'll focus on the Alarming UDT for the sake of discussion.

So every alarm in my system has a boolean condition, a time delay to prevent false triggering (DINT), a timer that counts up to that time delay (TON), and then an alarm output (BOOL). In my UDT I've created exactly that, so when I expand the alarm tagname I see:

-Alarm.Condition [BOOL]
-Alarm.TimeDelay [DINT]
-Alarm.Timer [TON]
|---Alarm.Timer.PRE
|---Alarm.Timer.ACC
|---Alarm.Timer.EN
|---Alarm.Timer.TT
|---Alarm.Timer.DN
-Alarm.Output [BOOL]
The problem is, I need the Alarm.TimeDelay value to be the Alarm.Timer.PRE value. This was easily done when I manually created every tag and simply aliased the tags. But now I can't do any aliasing with any UDT tags and I'm at a total loss for how to deal with this. Do I have to create a slew of MOV instructions to manually do this? Is there any easier way? It seems very odd that they'd provide this fantastic time saving resource, but then require you to manually move data around instead of being able to alias. Seems very odd to me, but I could be missing something and I'm by no means an AB expert so maybe there's a good reason, I dunno. Hoping there's a better way than manually moving everything. Thanks for any help guys.
 
Now that you understand UDTs, move onto AOIs.

As for your setting the .PRE on your alarm timer, do you set all of your alarm times in ms? Personally my alarm times are in seconds, and are able to be manipulated from the HMI/SCADA as a set point. Regardless of the timer function, I always us a MUL to convert my time set point to ms for the timer .PRE. So MOV/MUL for each timer will be required on some level.

But this is where AOIs become so valuable. For all of your devices you have created UDTs for, chances are they will need some logic. An AOI combines UDTs and logic as an object in your instruction library. Create the AOI one time, with a MUL/MOV to your timer and just use it over and over again. Graduate to AOIs for devices, keep udts for logic that can't be nicely packaged and repeated.
 
As for your setting the .PRE on your alarm timer, do you set all of your alarm times in ms?
Personally my alarm times are in seconds, and are able to be manipulated from the HMI/SCADA as a set point. Regardless of the timer function, I always us a MUL to convert my time set point to ms for the timer .PRE. So MOV/MUL for each timer will be required on some level.

Great point, so the MUL is needed and that incorporates the move since you can select a destination for the equation output.

But this is where AOIs become so valuable. For all of your devices you have created UDTs for, chances are they will need some logic. An AOI combines UDTs and logic as an object in your instruction library. Create the AOI one time, with a MUL/MOV to your timer and just use it over and over again. Graduate to AOIs for devices, keep udts for logic that can't be nicely packaged and repeated.

I see; so the whole idea seems to be that UDTs and AOIs go hand in hand. Generally I get the concept, but getting everything to work together is something I'm going to have to work on (which is why I'm posting from the office on a Saturday morning). Thanks!
 
Correct. I put in say 3 seconds as an input to the MUL, x 1000, output to the Timer.PRE.

When you create an AOI definition, it inherently creates it's own UDT. So if you create an AOI, you will always have an associated UDT.

However, creating a UDT does not necessarily mean it will have an AOI.
 
Correct. I put in say 3 seconds as an input to the MUL, x 1000, output to the Timer.PRE.

When you create an AOI definition, it inherently creates it's own UDT. So if you create an AOI, you will always have an associated UDT.

However, creating a UDT does not necessarily mean it will have an AOI.

Thanks for the input, it's definitely something you need to have a strong command over to do it right. I'm getting there, though.
 

Similar Topics

Hello, Wondering if the following setup would work. 1. Local PLC on the network has an array of 25 REALs 2. Supervisory PLC on the network needs...
Replies
14
Views
1,804
I have a task that could easily be solved using a 2-dimensional array using a ControlLogix processor, V32+. Basically it will loop through two...
Replies
23
Views
4,315
Can I not access locally defined UDT data? Scope.. Task>Prog1>Parameters and Local Tags(Test1 = real)(UTD.Test2 = real) #To access the local...
Replies
10
Views
1,487
Hi there, I am doing work for a customer who has a UDT that uses parameters like this: PLC_REG_TO_SEND.GROUP_15.1234_DINT[1].0 I believe these...
Replies
5
Views
1,786
Hello, I'm writing an interface program to a machine and because the bit data is packed into 16 bit variables, it's nicer to create an UDT to...
Replies
16
Views
4,902
Back
Top Bottom