OPC .NET (Xi) Client Base for .NET OPC Applications_Develop Controls_Develop Controls Versioning

PaXi (OPC .NET)

PaXi

OPC .NET (Xi) Client Base for .NET OPC Applications

The OPC .NET specification defines a .NET application interface for current data (DA), historical data (HDA) and events (AE).

PaXi implements the OPC .NET (Xi) Express Interface specification for access to Xi, Classic OPC DA, HDA, AE and OPC UA servers. PaXi based client applications can access all types of OPC servers through the same standardized application interface.
The development of interoperable OPC client applications is greatly simplified. The PaXi classes handle the server access with detailed error checking. The application can access any number and combination of servers.
All Xi methods can be called synchronously and asynchronously. The PaXi classes make async server access as simple as synchronous calls. However, async 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.

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. High quality Xi (OPC .NET) 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 the objects can be associated with user interface controls, such as e.g. a text box. The control is then updated with current values without need for any user code.
Xi (OPC .NET) client applications can be developed using either the PaXi Visual Studio Designer components or fully coded using the PaXi API classes.

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 best match the application defined preferences.

The PaXi software is structured into layers.
The Proxy classes are WCF generated from the Xi Contracts and provide the WCF data exchange interface. Additional methods implement features necessary for Xi (OPC .NET) compliance.
The embedded wrapper routes the client requests to Classic OPC DA,HDA,AE and OPC US servers.
All types of OPC servers can be accessed thru the same API.

The upper layers implement convenience features such as list management and intelligent Xi endpoint handling.
The top layer integrates into Visual Studio and reduces the amount of necessary application code.

How Xi 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 (OPC.NET) 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 startup 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 in 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 Xi server access PaXi handles the selection of the communication endpoints in a flexible 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.

Sample Applications

Sample client applications provided in C# and VB.Net source code

with projects for Visual Studio 2008 (.Net3.5) / 2010/2012 (.Net4) include:

Windows Form applications
WPF applications
Windows Service
Excel AddIn

Requirements

Visual Studio 2008, 2010, 2012 or 2013
.NET 3.5 SP1 or 4.0/4.5 with WCF activated
Windows XP or newer, Windows Server 2003/2008/2012