SUMMARY

Cross-node encrypted SuiteLink requires both nodes to be joined to the same System Management Server (SMS) server. In some cases, even if SMS is properly configured, a system may encounter the following error and the encrypted SuiteLink connection will fail, even though a Troubleshooting Scan within the AVEVA Common Service Portal may return without errors:
[Multi-Line Message] - Encrypted SuiteLink connection cannot be established.
Problem: SuiteLink connection request was received from un-authorized node <CLIENTNODENAME>.
Possible Reason: Security configuration on node <CLIENTNODENAME> is incorrect.
Possible Solution(s):
1. Ensure the node designated to be the 'System Management Server' is available.
2. ***[IMPORTANT]*** Ensure your applications are using the same 'System Management Server'.
3. For each node, launch the Configurator Utility -> Select the Management Server -> Press Configure -> Verify that the workflow configured successfully (Green configured Icon)
4. For additional details, refer to the 'Security Configuration' section in the product documentation.

CAUSE

This issue can be caused by the suggested problems in the error itself; however, in this case, if the computer name contains lowercase characters, the above error and symptoms may be encountered.

In Platform Common Services (PCS) 7.0.1, the current implementation assumes the following:

1. Letters in the Windows hostname (or Computer Name, or NetBIOS name) must be all capital letters (numbers are permitted)
2. The hostname part of the FQDN (Fully Qualified Domain Name) must be the same as the short hostname

APPLIES TO

• Platform Common Services (PCS) v7.0.1
• Communication Drivers Pack (CDP) 2023
• Application Server 2023
• InTouch 2023
• Historian 2023

RESOLUTION

Rename the computer hostname with all capital letters (A-Z) and numbers (0-9), using a total of 15 or less characters and avoiding Unicode characters.

• All numeric is not a valid name.
• Hyphens and longer names are permitted, but this is not recommended, as not all software and systems support this.

This is considered a best practice, as computer names in certificates are case sensitive, but DNS names are not case sensitive. A hostname query against a computer with a lower-cased name can return an all-caps result, which will not be an exact match when compared to the name in that computer’s certificate due to the difference in casing.

SUMMARY

Within the Operations Control Management Console (OCMC, previously called the SMC or System Management Console), you are able to connect to a remote node within the Operations Interface Server Manager section and access the configuration of the OI Servers installed and running there.  However, it is possible to encounter an issue where the diagnostics of the remote OI Servers does not appear within the OCMC.  The root cause of this behavior is DCOM authentication hardening settings that are part of newer versions of Windows.

This tech note will provide  steps with some recommendations to resolve the issue.

NOTE: These changes will revert modern OS and System Platform default security settings back to older OS and System Platform default settings by enabling the ANONYMOUS LOGON identifier, allowing access to DCOM without providing credentials. It is strongly recommended that you test this in a lab environment and conduct a risk analysis before considering implementation in a production environment.

APPLIES TO:

• Operations Interface Servers

PROCEDURE:

Add Anonymous_Logon to the Local Computer

1. Open Component Services from command line by running DCOMCNFG or search in Windows for Component Services.

2. Expand the tree to find My Computer.
3. Right click on My Computer and select Properties.

4. Go to the COM Security tab. In the Access Permissions section, press the Edit Default button.

5. In the Access Permissions window, press the Add button.

6. In the user selection window, type in first few letters of Anonymous_Logon, then use Check Names button to validate.
7. Click OK to confirm.

8. After the Anonymous Logon access type is added, grant both Local and Remote Access permissions.
9. Press OK to finish.

10. Repeat these steps on the remote computer.

After all steps are completed on both the local and remote computers, open the local Operations Control Management Console (OCMC), attach to the remote computer, and activate the OI servers in the OCMC (if not already activated). You should now be able to access the remote OI Server Diagnostics.

In some cases, the Diagnostics will still not open and pop-up warnings for Access Denied can appear. If so, continue to the next steps.

Enable Local Security Policy Network Access

Complete the following steps on both the local computer, and on the remote computers running OI Servers.

1. Search for Local Security Policy in Windows and open the utility.

2. Expand Local Policies – Security Options

3. Select Security Options and find the entry Network Access: Let Everyone permissions apply to anonymous users.

4. If this entry is set to Disabled, enable this option by double clicking or right-click Properties, select Enable and then Apply.

After making these changes, the OI Server Diagnostics on the remote node should be available in the OCMC on the local computer.

SUMMARY

Occasionally, making modifications to the tags in a ControlLogix/CompactLogix PLC will result in the AVEVA ABCIP OI Server having one topic that is not showing the correct information. It may appear to be good data but it is reading the wrong tag data or the tag data may have bad quality.

If you encounter this issue, you may be able to resolve it by downloading a new copy of the tag database from the PLC to the OI Server.   Toggling the $Sys$UpdateTagInfo item to “true” forces an update of the entire controller tag database.

This tech note provides two methods than can be used to toggle the $Sys$UpdateTagInfo item.

SUMMARY

When a Device Integration object gets disconnected from its data source (e.g. an AVEVA OI Server), it must be manually triggered to reconnect when the source becomes available again.  By using some basic scripting, you can configure the DI Object to automatically reconnect to the data source when the connection is lost. This tech note will instruct you on how to set up an auto reconnect feature and add additional diagnostic information that will indicate the number of disconnects the object has experienced since it last went on scan.

PROCEDURE

Section 1 – Add the Auto Reconnect Functionality

First, you will create a script that will automatically reconnect to the data source when the connection is lost.

1. In the IDE, create a derived template from the DI Object base template you will be using (in this example, we are using the $DDESuiteLinkClient). Open the derived template in the configuration editor.

2. On the Scripts tab, click the Add Script button.

3. Name the new script Reconnect and press Enter.

4. Configure the Reconnect script as follows:

Aliases: locked
Declarations: locked
Execution type: Execute and locked
Basics: locked
Expression: Me.ConnectionStatus <> 2
Trigger type: WhileTrue
Trigger Period: 00:00:05.0000000
Script body: Me.Reconnect = true;

This script will attempt to reconnect every 5 seconds, when not connected to the data source.  You can adjust how often the object attempts to reconnect by modifying the Trigger Period setting.

Section 2 – Add an Attribute to Count the Disconnections

5. On the Attributes tab, create and configure a new attribute as follows:

Name: Disconnect.Cnt
Data type: Integer
Writeability: Calculated

6. On the Scripts tab, add a script named Disconnect.Monitor.

7. Configure the Disconnect.Monitor script as follows:

Execution type: Execute and locked
Basics: locked
Expression: Me.ConnectionStatus <> 2
Trigger type: OnTrue
Script body: Me.Disconnect.Cnt = Me.Disconnect.Cnt + 1;

This script will increase a counter by one every time the condition is true.

Now you will add code within the same script under a different execution type that will run when the object goes on scan.

8. While still in the Disconnect.Monitor script, change the Execution type to OnScan.

9. In the script body, enter:
   Me.Disconnect.Cnt = 0;

This script will reset the counter to zero every time the object goes on scan.

10. Save and Close the object.

N-Tron series of managed and un-managed switches are bundled with an OPC-DA (v1.X) server that can collect network and switch diagnostics. These diagnostics can be interfaced into the InTouch HMI so that diagnostics can be visualized, historized or alarmed. This tech note describes the process of integrating these switch diagnostics via Wonderware OPCLink.

Software Pre-requisite Installation

• InTouch HMI must be installed. Although this example is done using InTouch version 10.1, this process should work for versions going back to 7.0.
• Wonderware OPCLink I/O Server must be installed. This software component bridges OPC-DA protocol to DDE/Suitelink which is supported by InTouch HMI. OPCLink can be installed via the Wonderware Device Integration CD-ROM or downloaded directly from: http://www.wonderware.com/support/mmi/comprehensive/ioserv/OPCLink80.zip
• N-View OPC Server must be installed. This software is provided with N-Tron industrial switches.

N-View OPC Configuration

1. Start the N-View OPC Configuration software. Available switches should be automatically recognized:

2. Map the appropriate switches by selecting the switch MAC address, switch model and clicking on the ?Map? button. When completed click on the “Save & Close” button.

Wonderware OPCLink Configuration

1. Start OPCLink via Start > Programs > Wonderware > IO Servers > OPCLink.

2. Click on the “Configure” drop-down menu and select “Topic Definition”.

3. Click on the “New…” button.

4. Enter an appropriate topic name (NTRON708TX for example).

5. Enter the node name of the NTron OPC Server (e.g. the name of the computer that).

6. Select the NTronOPCServer.Server.1 from the list of available OPC Servers.

7. Click on the “Browse” button. In the OPC item browser select the top of the hierarchy and click on OK.

8. Next, confirm the OPC Path has been populated in the topic configuration.

9. Click on the “OK” button. Click on “Done” on the topic definition list.

Wonderware InTouch HMI Configuration

1. Using the InTouch Application Manager, create a new application and open it with WindowMaker (or if there is an existing application, open it directly with WindowMaker).

2. Click on the Special > Access Names… from the drop-down list.

3. Click on the “Add…” button. Configure the Access Name as shown below:

4. Click on the “OK” button.

5. Click on the “Close” button.

6. Open the tagname dictionary by selecting Special > Tagname Dictionary from the drop-down list.

7. Click on the “New” button and configure the first tag as shown below:

Note: the Item field must be prefixed with a data-type indicator. d = discrete, i = integer, m = message.

8. Another example, this time looking at the link speed for port 1 on the switch:

9. Once tags have been created, we can now create animations to indicate the live values coming from the switch:

10. Other tags can be created for further diagnostics. Some typical ?items? that can be configured on InTouch tags are (Where X = Port number):

mPortX.Duplex

dPortX.Port_Enable

iPortX.Usage

For a more complete list of diagnostic tags, please refer to the N-View OPC Server documentation.

SUMMARY

The AVEVA Operations Integration Servers (OI Servers) all have the ability to serve clients using three built in protocols: DDE, Suitelink, and OPC. The Matrikon OPC Explorer is a free product from Matrikon (provider of many IO OPC Servers) and can be useful in verifying connectivity an displaying values when troubleshooting communications to an AVEVA OPC Protocol. The way to connect to the different AVEVA OI Servers is the same, only the name of the server and the tags you are looking for may change. This document lists the steps necessary to connect to the AVEVA OI Server via OPC item naming using the Matrikon OPC Explorer (in this example we use OI.MBTCP Server for Modbus Ethernet protocol).

APPLIES TO

• Wonderware OI Servers – All versions
• Matrikon OPC Explorer – version 4.0

Note: Optionally you could enter Device Items here (like in the figure below) this would make these items available for browsing from an OPC Client.

2. Verify Suitelink or DDE (not OPC) communication to the PLC using the WWClient described in Tech Note 62 “How to monitor and troubleshoot communication using Wonderware Client utility”. In the figure below, you can see the DAServer is communicating to a memory register in the PLC with good quality (0x00c0).

3. Be sure to close your WWClient application before continuing.

4. Start your OPC client. This example is using MatrikonOPC Explorer. The picture below shows that the utility found five OPC servers on the local machine (localhost) and displays them in a tree view. It will find all the locally installed OPC servers and display them in this list.

5. By selecting the OI.MBTCP.1 server on the left, then under the OPC Server Connection Options listing to the right, the “Connect” option becomes selectable.

6. Click Connect button to initiate the connection to the OPC Server.

Note: OPC clients can connect to OPC servers using one of the following modes:

• In-Proc – in this mode the OPC Server becomes a part of OPC Client process, one user at a time and this connection mode wants to start the OPC server. In-Proc connection can only be run locally on the same PC and is usually a .dll file type.
• or Out-Proc – in this mode the OPC Server is a standalone application, which multiple users/clients can connect to and the connection expects the OPC server to already be running; the Out-Proc connection can work either on local PC or across network and is usually a .exe file type

Connection mode is a client-side setting. The default setting for most OPC clients is to locally connect In-Proc. To check or change the connection mode in the MatrikonOPC Explorer go to View -> Options -> COM tab. To enable Out-Proc connection mode (if needed) un-check the boxes for In-Proc and In-Proc Handler (see the screenshot below for reference).

7. Once connected the icon should turn into a receptacle plug icon with an red “X” on it and the “Add Tags” selection should now be available (not grayed out), under the OPC Server Connection Options listing to the right.

8. Click the “Add Tags” and create a group name for the tags. In this example the group name was called OPC DEMO. The rest of the options you can leave as default. Click OK.

9. The Tag Entry window should now be displayed. Now browse the Available items in Server section to find the OPC path to the available tags you are looking for. You do this by selecting the ‘+’ (plus) sign next to Port item you are looking for, in this example New_TCPIP_PORT_000.

10. Then continue to browse using the ‘+’ sign until you find the PLC item you are looking for and then select that item. In this example select the item in the tree under New_TCPIP_PORT_000, New_ModbusPLC_000.

11. Then drop down to the Available Tags section and select one of the available system tags, they start with $SYS$, ($SYS$Status was used in the example figure below).

Note: For a complete list of system tags available and their uses, see the OI Server User’s Guide.

SUMMARY

At times it is helpful to notify operators that communication has been lost between the HMI and a PLC. This tech note shows one method that relies on continual updates from the PLC to reset a counter tag. If the counter tag increases past a configured alarm set point, then it will produce an alarm.

APPLIES TO

• AVEVA InTouch

2. Next create a Communication Fail Counter tag (Memory Integer type) in AVEVA InTouch and configure the Hi alarm limit. Optionally, you can add a HiHi alarm limit to make the alarm change state after a longer period of communication lapse.

3. Create two application scripts:

• One to initialize the Communication Fail Counter tag on application start in the Application Startup script:

• Another to increment the Communication Fail Counter tag once a second while the application runs:

4. Finally, create a data change script to reset the Communication Fail Counter tag to zero every time the HMI receives an update on the PLC heartbeat tag from the PLC.

5. The following images show a window with an alarm display and a couple of discrete animation links pointing to the PLCComCounterAlarm.Alarm.

The .Alarm dotfield is used to determine the alarm state of a tag (“True” means the tag is currently in alarm). Also the alarm display shows the tag showing up as an unacknowledged alarm when the communication loss passes 60 seconds.

SUMMARY

This tech note details the procedure used to configure DDE (Data Dynamic Exchange) and AVEVA SuiteLink client connections using AVEVA Application Server and the System Platform IDE (Integrated Development Environment). The DDESuiteLinkClient object available in System Platform IDE provides a client connection to DDE or SuiteLink servers so that data can be read and written to external data sources such as a PLC (Programmable Logic Controller).

This tech note consists of three parts:

1.       Details the process of configuring and deploying a new instance of the $DDESuiteLinkClient template for communication with a data source,

2.       Details testing of the deployed DDESuiteLinkClient object

3.       Builds on the previous steps and configures an automation object which will reference data from the DDESuiteLinkClient object.

Specifically, this example will detail the procedure for connecting AVEVA Application Server to an OI-Server (Operations Integration Server) using the DDESuiteLinkClient object.

Applies to

• AVEVA Application Server 2.x and later
• AVEVA DA Server/OI Server

PROCEDURE

Part 1 – Creating, configuring and deploying a new instance of the DDESuiteLinkClient Object

1. Open the System Platform IDE application (Start -> AVEVA System Platform -> System Platform IDE

Then, connect to the appropriate Galaxy (in this tech note the galaxy’s name is “Test”).

Note: A deployed Platform, Engine and Area will be necessary for this example.

2. Select the Template Toolboxtab and locate the $DDESuiteLinkClient object template under the Device Integration folder by default. Right-click on the object template and select “New -> Instance” to create a new instance of the DDESuiteLinkClient object.

You should now see a new instance of this object in the Unassigned Host area of the Deployment View. Rename as desired. In this example, the object will be named “DDESuiteLink1”.

3. Double-click on the newly created instance to open its configuration in the right pane.

On the General tab enter “Server node” and “Server name”.

3. • “Server node” field – configure with the node name or IP address where the OI or DAServer is located (in this example the OI Server is located on a host called WINDOWS10VM);
   • “Server name” field – configure with the application name of the DDE or Suitelink server (in this example the application name used is MBTCP; if the required application name for the data source is not known, please refer to the product documentation);

NOTE: The “Server name” naming convention for OI-Servers can be verified in the SMC -> Operations Integration Server Manager -> Default Group…Operations Integration Supervisory Servers. Then locate your desired OI-Server. The name used in DDESuiteLinkClient configuration will be the middle part of the server name here (example, “MBTCP”).

Next configure the rest of the fields for this object:

• Detect connection alarm generates an alarm upon connection loss
• Communication protocol determines whether DDE or AVEVA SuiteLink protocol is being used (NOTE – DDE is a legacy protocol. SuiteLink is the option you will want for OI and DA Servers.)
• DDE login allows a specific Windows user account to be used for DDE/NetDDE communication (NetDDE – Network Dynamic data Exchange). Legacy option for DDE protocol.

4. Switch the Topictab on the configuration window and click on the blue plus (+) sign above the topic list to add a new topic. In this example, our topic name will be “Topic1”.

Note: This topic name needs to exactly match the topic or device group that has been configured in the OI or DAServer. If the required topic name is unknown, please review the configuration of the associated OI or DAServer (below is an example of the MBTCP Device Group configuration)

5. Now, save and check-in the configured DDESuiteLinkClientobject. Assign this object to an engine in Deployment View.

6. Make sure the OI or DAServer being used is started before deployment. Then right-click on this object and select Deploy. Click on the OKbutton to confirm deployment.

Part 2 – Testing the deployed DDESuiteLinkClient object

1. Right-click on the deployed DDESuiteLinkClientobject and select View in Object Viewer from the menu.  This will open the Object Viewer window.
   In that window you will see a list of the attributes of DDESuiteLinkClient object. Locate ConnectionStatus and confirm its value is Connected.

If the ConnectionStatus value is not Connected, review the configuration of the DDESuiteLinkClient object for errors and make sure that the associated OI or DAServer is running and connected to the network.

Note: The values listed in the Object Viewer are not automatically updated.  To update the current value of an attribute, either click and highlight the attribute in the list, or right click on the appropriate attribute and add it to the watch window.

Part 3 – Configuring an application object to reference data from the DDESuiteLinkClient object

1. Select an appropriate Application Object from the Template Toolbox.  Right-click on this object and select “New -> Instance“.  In this example, the $UserDefined template will be used.

Move this new instance from the ‘Unassigned Host‘ area to an ‘Area‘ instance in Deployment View.

2. Double-click on this new object instance to open its configuration. Create a new Attribute (“IO_Test” in this example) and enable the “I/O” feature.

The OI reference should have the following format:

<DIObjectName>.<TopicName>.<Item/Register>   where:

• <DIObjectName> – the instance name of the DDESuiteLinkClient object
• <TopicName> – the exact topic name configured in the DDESuiteLinkClient object
• <Item/Register> – the data item from the data source, typically a PLC register or tagname

For example: DDESuiteLink1.Topic1.30001

NOTE: While not covered in this Tech Note, it is also possible to use “I/O Auto-Assignment” instead of manually entering the reference here.

3. Save and check-in this object. Next, right-click on this object, select Deploy, and click OK.
4. Once the object has deployed, right-click on it and select View in Object Viewerfrom the menu. Next, locate the attribute (“IO_Test”)in the list and confirm that both its value is correct, and the quality is C0:Good.

If the value is not correct and/or the quality is not good, confirm that the configuration for this item is correct and it is a valid data point in the PLC.

SUMMARY

For certain classes of critical alarms, it may be best to allow the PLC (Programmable Logic Controller) to notify the data clients immediately rather than waiting for a polling interval to update the alarm point at the HMI (Human Machine Interface). For this type of event, certain Allen Bradley PLCs have the ability to send unsolicited messages to clients. Once the PLC is properly configured via the RSLogix programming interface, an AVEVA ABCIP topic can be configured to accept unsolicited messages. Please refer to the Allen Bradley documentation for guidance on setting up the PLC network for unsolicited message configuration and support.

The ABCIP Communication Driver supports unsolicited messages from the following processors:

• PLC-5 and SLC 5/04 processors on the Data Highway Plus network.
• The following non-Logix processor configuration does not support unsolicited message handling:
  MicroLogix with 1785-KA5 via ControlLogix Gateway (1756-DHRIO and 1756-ENB).
• Logix5000 and MicroLogix 1100 processors on the Ethernet network.
• The following Logix5000 processor configuration does not support unsolicited message handling:
  CompactLogix going through the EtherNet/IP interface module (1761-NET-ENI).
• Logix5000, PLC-5, and SLC500 processors on the ControlNet network.
• The following SLC500 processor configuration does not support unsolicited message handling:
  SLC500 using 1747-KFC15 interface on ControlNet via the ControlLogix Gateway (1756-CNB and 1756-ENB) to RSLinx on Ethernet.

For more information about supported processors, go to the AVEVA ABCIP documentation in the System Platform Management Console (SMC → Operations Integration Server Manager → Right-click Allen-Bradley → ABCIP → AVEVA Communication Drivers Pack → Allen Bradley → ABCIP Driver Online Help → Configuring the ABCIP Communication Driver → Device Groups and Device Items → Unsolicited Message Handling)

APPLIES TO

• AVEVA DASABCIP version 2.0 and higher
• AVEVA Operations Interface ABCIP version 6.0 and higher

PROCEDURE

1. Open the System Platform Management Console (SMC) (Start -> AVEVA -> System Platform Management Console)

2. In the SMC select Operations Integration Server Manager Snap-in, and expand until target OI.ABCIP.X Configuration level is exposed.

3. Select and right-click on “Configuration” level. Create and configure the following objects (NOTE: These objects exist by default in the Communication Drivers Pack):

• PORT_CIP (logical representation of the Ethernet port for CIP communications in a computer),
• ENB_CLX (logical representation of the ControlLogix EtherNet/IP Bridge module),
• BACKPLANE_CLX (logical representation of the backplane communications bus of the ControlLogix rack) and
• LOGIX5000_CLX (logical representation of the ControlLogix processor)

Select the target controller (in our example it will be Logix5000).

4. In the right-hand pane of the SMC, you should see some configuration details related to the LOGIX5000_CLX object. Select the Device Groups tab from the target controller configuration and remove any topics there by default if you choose. Then, create a new topic (right-click on the pane).

5. The topic should be configured to accept unsolicited messages. To do that select the topic, right-click over the topic name and select Edit from the popup menu for additional configuration.

6. On the resulting Device Group Parameters window, select the checkbox Support Unsolicited Messages and click OK.

NOTE: Any topic can be configured to accept unsolicited messages. To configure a topic that only accepts unsolicited messages, you can set the topic’s update interval to 0. This will force the DA Server/OI-Server to poll the topic only once at startup and any update from the controller would need to be via unsolicited messages. This configuration could potentially cut down on message traffic in the process control network if properly implemented.

SUMMARY

When troubleshooting communications between your HMI and data source it can be useful to utilize the Wonderware Client (WWClient) utility to verify connection status and read values. This document lists the procedures necessary to install and use the WWClient utility to help troubleshoot communications.

APPLIES TO

• All AVEVA software packages that utilize SuiteLink or DDE communication protocols
• Wonderware Client Utility (WWClient)

PROCEDURE

1. Install the WWClient utility. You can download and install the utility from the link provided below:
   wwclient.zip

2. Unzip the utility and run wwclient.exe

3. To begin, select “Connections” > Create

4. This will open the “Create Connection” window. You will notice that the configurations here are very similar to that of an Access Name for InTouch. Configure connection and select “Create” button.

Description for our example:

Node:…………. localhost (we will be connecting to a OI Server installed on the local machine)
Application:…..mbtcp (we will be connecting to the Wonderware MBTCP OI Server)
Topic:………….Topic1 (this is the default name used when defining a topic in the MBTCP OI Server)
Connection Type:…….(for the purpose of this document the “IOT” connection type was used)

Definitions are as follows:

• DDE:…………….Dynamic Data Exchange
• IOT:…….I/O Talk (this was the original name/acronym for the SuiteLink protocol)
• IOT – Thread:..This will start the protocol in a separate thread (this is not the advised protocol to use)

5. Once the connection is created you will see a line of text populated within the “Wonderware Client” window, which displays information about the protocol in use, the path to connect to the end device, and an indication of the connection status.

The main concern here is that the hexadecimal value does not read 0x00000000

6. From the “Wonderware Client” window menu select “Item“. This will open the “Item” window. Select the connection in question in the “Connections” section, enter a valid data point and select the appropriate type in the “Item” section. Proceed by selecting the “AdviseEx” button.

7. You will now see the advised item information displayed under the connection information. In between the item name and the timestamp is where you will see the actual value of the item advised. To the far right is another set of hexadecimal values representing a quality, where 0x00c0 represents a good connection to the data source.

NOTE: A legend of these hexadecimal (and their respective decimal) values is located below in the “OPC Quality Code Legend” section.

OPC Quality Code Legend