It is important to understand how data flows between AOIs since we have been using them extensively and there are some tricky caveats that can make programming or debugging more difficult.
The misleading names of “External Access” and “Local” probably explains why there is inconsistent behavior on the “External Access” selection in Studio 5000. Even AB doesn’t seem to understand it because even their documentation states “Local Tags are not viewable as members of the data type structure for instances of the instruction” which is only partially true. They are viewable on the HMI as long as External Access is set to Read or Read/Write, which is just not the default value for a new Local tag.
“External Access” cannot be modified for local tags using the tag properties dialog, but can be modified in the “Parameters and Local Tags” list. It seems that the UI designer for the properties dialog did not understand the difference between external PLC and external HMI access. PLC external access being determined by IN and OUT. HMI external access is determined only by the External Access tag of it and its parent tags, regardless of IN, OUT, or Local usage.
Here’s how I suggest to think about it:
| AB Name | More accurate | Explanation |
| Required IN | Copy IN | In the background, the system is going to copy from the required tag specified in the call into the AOI instance of the input parameter before the AOI logic executes. As a result, any changes to a required input from inside of an AOI will not be propagated to the external version because that data exists in two places, and is not copied back out at the end of AOI execution. So, an AOI should never write to a required IN parameter. It is “required” in that there must be a source for the system to copy from. An HMI should never write to an AOI’s instance of a required input tag since it will be overwritten immediately prior to AOI execution. |
| Required OUT | Copy OUT | When an AOI finishes executing its logic, the system is going to from the local instance tag to the one originally specified in the call for that execution Any changes to the external tag will not be copied into a required output parameter, since the system will always overwrite the external version with the internal version. It is “required” in that there must be a destination for the system to copy to. |
| INOUT | Direct external | Reference to external data is set during the AOI call. Nothing is copied, so values do not exist in AOI instance data. HMI cannot read data that does not exist. Since no data is copied, complex data may be passed. |
| Non-Required (Both In & Out) | Interface | Non-required parameters can be modified by external logic. Non-required IN parameters are actually identical to non-required OUT parameters. As convention, assign either IN or OUT in the direction of their flow as if required. Ex: HMI button or configuration settings are IN, HMI state or HMI numeric display are OUT |
| Local | Logic Protected | Local tags may not be accessed by external logic, but the HMI can. Complex tags may be stored here, but will only be accessible to the HMI (if External Access) |
| External Access | HMI Access | Tag property does not affect logic at all. Is used to enable or prevent HMI read/write. |
| Visible | Show on call | Only changes whether the IN or OUT parameter shows up on the call. Most parameters should be visible since it makes debugging easier. Even if your tag won’t be used by external logic, if it might be useful to have for debugging in Studio 5000 or to display on the HMI, making it a visible non-required parameter is a good convention. |
There is also an ability to alias IN or OUT tags to local instance data. This can be useful when using nested AOIs to avoid extra MOV or OTE instructions. This is not possible with INOUT or Local tags.
All Aliased tags have the same External Access as the destination because there is only one copy of the data. It is a reference that persists because the tag it refers to cannot change if the AOI was called multiple times with different parameters. This behavior closely follows how Alias tags work elsewhere.
I actually see no reason why complex data types couldn’t be non-required non-visible IN or OUT parameters. They can’t be easily displayed on a call, so it makes sense they can’t be visible. Since they can be quite large it makes sense that they shouldn’t be copied every call wastefully. However, I don’t see a reason why external logic couldn’t access a complex data type in AOI instance data. Currently, since local protects against external logic access, strings and dates are quite hard to work with.