OPC .NET 3 (Xi) SDK for OPC DA/HDA/AE/UA/Xi Client Applications

The development of interoperable OPC .NET 3 client applications is greatly simplified. The PaXi classes handle the server access with detailed error checking. All Xi methods can be called synchronously and asynchronously. The PaXi classes make asynchronous server access as simple as synchronous calls. However, asynchronous server access improves the behavior of user interface applications. The application is responsive even if a server access is slow as it may happen in server access through the Internet.

PaXi supports access to different generations of OPC servers thru the same API. Classic OPC DA/HDA/AE OPC .NET 3 (Xi) OPC UA servers. No external converters are required, simplifying the application deployment and maintenace. Only one type of communication is used, DCOM for classic OPC server access, WCF for Xi server access and UA for OPC UA server access.     For Xi server access PaXi implements an innovative endpoint management. In Xi the communication configuration is defined in the server. The clients can only select among the server configured communication endpoints. Different servers likely have different configurations and different endpoint naming. PaXi collects the information about the available endpoints and selects the endpoints that bes match the application defined preferences.

In addition to the server access methods PaXi also provides components that are available in the Visual Studio toolbox and can be dragged to the application form as it's done with Windows controls and components. The components can be configured by setting their properties. Professional Xi client applications can be realized with only a few lines of code.

For example the components for Xi lists can be configured with a set of object names and objects can be linked to user interface control, such as a text box. The control is then updated with current values without need for any user code.

Xi client applications can be developed using either the PaXi Visual Studio Designer components or fully coded using the PaXi API classes.

How OPC .NET 3 Client Applications are developed
PaXi is designed for application development with Visual Studio and can be used in different ways.

• PaXi Components Based Application Development
  The easiest and fastest way to create Xi clients is by using the components provided by PaXi in the Visual Studio designer. Each component has a set of properties that control the behavior and the Xi server method being called at start-up and during operation. The amount of application code required is greatly reduced. Only a few code lines are required if the Xi objects are linked to UI controls.
• Fully Coded
  Xi client applications can be developed based on the PaXi API classes.
• Mixed
  The basic server access can be handled with components and still all Xi features can be used from application code.

PaXi Features

PaXi offer classes with methods for access to all Xi specified methods and additional methods that simplify the server access.

All methods are provided an a version for:

• Synchronous Server Access
  This methods block the calling thread until the response is received from the server. In server calls from background threads this is fine. However, when used in a user interface thread then the application becomes unresponsive for the duration of the server call.
• Asynchronous Server Access
  User interface threads should always use asynchronous server access. The application doesn't become unresponsive, even with slow server access.

For UA server access PaXI a configuration utility for the management of the UA configuration and certificates.

For XI server access PaXi handles the selection of the communication endpoints in a flexible semi-automatic way. The application sets preference declarations and PaXi selects the best fitting endpoint available in the server:

• Endpoint Name
  The endpoint with this name is used if it exists in the server configuration.
• Security Yes/No
  Determines is a secure or non-secure endpoint is selected in case the server has endpoints configured with both kinds of bindings.
• Scheme (http, https, net.tcp, net.pipe)
  Determines the selected endpoint in case the server has endpoints configured for different bindings. The selected endpoint also depends on the location of the server. The NamedPipe binding can only be used in local server access and endpoints with the net.pipe binding are ignored in the selection process if the server is not on the local machine.

Requirements

• Visual Studio 2008 or 2020
• .NET 3.5 or 4.0 with WCF activated
• Windows XP or newer




Vendor: Advosol

view complete profile

Advosol Inc. is the leading provider of .NET components for the developer of OPC DA, AE, HDA and XML-DA client and server applications. Advosol’s client components are up-to-date with the latest technology. They work in 32-bit and 64-bit systems and are Authenticode signed to ensure quality and to simplify Windows Vista Certification. The server toolkits reduce the OPC server development to a .NET assembly for the ‘device’ access. The OPC system integrator can use our XML DA Gateways and Bridge to eliminate DCOM issues and achieve secure remote access. All Advosol products include extensive documentation and 90 days support.