Advanced communications management

Good question. Richard Köhlerstrand might be able to shed some light on this, as he just commented: "[...] please verify the setting for Advanced Communications management, by default it should not be enabled." on How to script a "refresh" of a $UserDefined instance with attributes which are stuck with Bad data quality.

Hi, Aveva has described this in some articles, but to summarize.

Advanced Communication Management can help to manage CPU and network load for nodes hosting DAServers and DI Objects when DI Object attributes are currently being subscribed, but whose value is not currently shown by a client.

You can utilize the DI Object Scan Mode setting of ActiveOnDemand to allow an InTouch client to scan for updated values from DI Object attributes. Then, while the window is minimized or hidden, you can suspend the scanning without deleting the subscription. This can help to eliminate the time required to remove and add subscriptions, making the InTouch® windows load faster, while keeping the load on the DI Object and its data source as low as possible when switching or minimizing/restoring windows.

To ensure that attribute data saved to the historian is always current and continuous, Application Server registers a reference to the attribute. By registering a reference to the attribute, it prevents Message Exchange from suspending historical updates during the period when the client application has minimized the window containing the object. Historical data continues to be saved to the Historian even during the period when the object is in an Advanced Communication Management Suspended state.

The thing is that the above is not generally needed for a System Platform setup, and is disabled by default, only exception is in a specific upgrade scenario where a galaxy is upgraded to the version where this feature were introduced, (I believe it was 2014), where it was forcefully turned on for some reason.

The issue with this setting is that it can cause a lot of stage behavior if you are not careful, its up to the Galaxy to deem if the value should be updated or not and this has caused some problems in various versions of Application Server,
also, if you are using indirect bindings in your logic you could end up binding to a attribute that has been inactivated by the system (since it does not count it as in use) thus you end up in values not updating or logic not executing as expected.
I have seen Attributes being stuck in Initializing, not working until you open them in Object viewer, (Schrödinger's cat behavior  ) 

So as best practice I would state that this is something that you ensure is turned off and only utilized if you are in need of the load reduction on the system and are fully aware of the effects and needed configuration to ensure full communication to your data sources.

https://softwaresupportsp.aveva.com/en-US/knowledge/details/000022611?lang=en_US

If you are an InTouch Workstation developer this can compare to the 'Advise server: All Items/ Only Active Items' - feature on your Access name.

I hope it clarifies things for you.

Richard

The ACM model has been greatly improved in the later versions.  It definitely had some issues in earlier builds, but post 2017 U3 the stability is night and day since it's initial inception. 

If you set the mode to "Active", there isn't a performance hit to using the ACM vs having it off.  

Some people will tell you to use "ActiveAll" - this isn't a good idea IMO, unless you NEED to always have points subscribed to, even if you undeploy the corresponding object.

ActiveOnDemand = Like "Advise only active" in Intouch

Active = All IO that is requested by appserver is always on scan.  If no references to a particular register exist anymore (i.e. objects undeployed), that register is unsubscribed in the DI object.

ActiveAll = same as active with an important caveat - whatever registers in the PLC are subscribed to, they STAY subscribed, even if you undeploy all objects requesting it.  The only time these get unsubscribed is on undeploy of the DI object itself.

Back to the ACM, I leave it on, and set any topics that I am doing things that require some of the exceptions Richard makes above (indirects in scripts, for example), I set the mode to "Active". I haven't had reliability issues with it across my customers in several years now.

Also, if you are using some of the advanced AVEVA products with App Server as the basis (MES, Batch Management, etc), it is recommended that you use "Active" mode for any DI objects or app objects being referenced.

Hope this helps!

-P

Thanks for your response Richard. 

As you say there is some information on the topic in articles and manuals. But it isn't very informative on why it's disabled out of the box. When creating a new scan group / topic in a DI object the scan mode is defaulted to "ActiveOnDemand". So these "defaults" don't correspond in my world. And that's why I started thinking that enabling ACM could lead to some sort of performance hit even if all of the scan groups / topic's in a application is in scan mode "Active" or "Active All".

I agree with you that this feature isn't needed for a general System Platform setup. But from a PLC perspective it could make a difference on the communication load and how powerful the PLC has to be to handle the load. 

Given that ACM doesn't create a performance hit by it self or creates any unexpected behavior, I think it would make more sense to leave it on and handle the behavior in the DI objects scan mode setting.

Again, thanks for you clarifications.

Hi Phil,

thanks for the reply and sharing of your experience. 

Good to know that the ACM is improved in later versions. At my site we are at version 2023 R2 SP1 P01.

In general we use "Active" as scan mode, but for some cases it makes sense to use "ActiveOnDemand" to lighted unnecessary communication load on a PLC.

But because ACM is turned off by default and that it's typically advised to turn it off as a step in troubleshooting, I have been hesitant to turn it on.