UDTs with AOIs for Required Parameters

Why not use UDTs to group AOI required?
Then reference the UDT tag instead of external reference of AOI parameters. AOI inout parameters not accessible externally.

Seems like there’s a fear of combining these.

Nested data types create one larger data type that works well with an AOI with nested AOI.

I would like to do this type of stuff, but company only hears about AOIs and believes unnecessary. Sticking with AOIs really complicates the call level code if you want to dynamically change the AOI parameters in the code.

If you change a input parameter that is not required but visible in the preceding rung of the AOI call does the value on the AOI overwrite your modification. Must you make that parameter required and tie it to the AOI variable, parameter passing it to itself?

1 Like

AOI’s are good, but the development can take more time. To prove that the code works in different situations takes lot of testing. AOIs cannot be edited on line (while the program is running), but the edit need to be done off-line and downloaded. In many process situations, stopping the PLC is not simple. So when AOI needs to be edited, it becomes one of those down the line jobs. UDT’s are good, often it is baggage (meaning number of tags are useless for specific device but had to be there as they are part of UDT), but when we encounter same device 100’s in the project, UDT is the way to go. Finally arranging the type of tags in UDT is important as wrong order consumes more memory. My experience is from Rockwell PLCs, so what I have written is in reference to that. Other who have different experience can contribute.

1 Like