TN AppSvr157 Architectural Discussion using Gateway as an OPC Client with the Galaxy to an OPC Server

Description

In order to efficiently communicate from the Galaxy to an OPC Server, we must take precautions to try to eliminate any DCOM issues. OPC technology relies on Microsoft's COM and DCOM to exchange data between automation hardware and software; however it can be frustrating for new users to configure DCOM properly. If you have ever been unable to establish an OPC connection or transfer OPC data successfully, the underlying issue is likely DCOM-related.

• Author: Glenn Yancey
• Published: 09/29/2015
• Applies to: System Platform 3.1 and higher

Details

FS Gateway is a Microsoft® Windows® application program developed by Wonderware that acts as a communications protocol converter. It was built with the ArchestrA DAS Toolkit. FS Gateway can be used as an OPC Client to an OPC Server using the OPC data access protocol. The reason that we may use FS Gateway is because Wonderware may not have a driver to communicate to a desired end device. There are many OPC Servers such as Matrikon and SoftwareToolbox (Kepware) that can communicate to a variety of devices that are not in the Wonderware DA Server (driver) library. Some of these OPC Servers may not speak the Wonderware protocol called Suitelink. Because of this, we need to use the OPC protocol to communicate to these drivers for our targeted end devices.

In the Galaxy, we have two types of objects for communication to an OPC Server. 

The OPCClient object will be discussed in a future technote. This article only addresses FS Gateway.

DDESuitelink -> Gateway -> OPCServer

DDESuitelink -> Gateway

Uses the Wonderware Suitelink protocol with the request for data originating from the Galaxy that is requesting data from FS Gateway for OPC Server data. Inside FS Gateway exists all the information that we need to talk to the OPC Server. 

Gateway -> OPCServer

Uses the OPC Protocol from FS Gateway to the OPC Server.

So with this being said, we have two common architectures for allowing the Galaxy to communicate to an OPC server.

Scenario 1

In this scenario, the FS Gateway (OPC Client) is in charge of communicating to the OPC Server on another server. As mentioned above, the DDESuitelink object will be able to communicate fine to the FSGateway program (OPC Client) but the fact that the OPC Client and OPC Server means that we could have to content with DCOM issues. To get past these issues, the OPC training institute has written the article below as to what to do to prepare for this scenario.

http://www.sytech.com/download/OPC_and_DCOM.pdf

Scenario 2

For scenario 2, we had installed FS Gateway Program on the same machine as the OPC Server. This way, we don’t have to worry about DCOM issues since the OPC Client and OPC Server are combined. The only communication between these 2 nodes is through the Wonderware Suitelink protocol. As long as Port 5413 is open in any firewall, communication should be seamless from the Galaxy using the DDESuitelink object. This would be the optimal approach as configuration of FSGateway should be without issue as it discovers the OPC Servers locally in its configuration. 

* The 2^nd node DOES NOT require a Platform to be deployed to it.