What’s New in QuickOPC 5.31

Previous: What’s New in QuickOPC 5.30

Key changes:

• Improvements in user interface components
• Support for OPC XML-DA specification

User Interface

• We have introduced two new components, OpcBrowseControl and UABrowseControl. These are browsing controls that can be placed onto your forms, configured to provide different kinds of OPC browsing, and cooperate with other controls on the form. Their functionality is similar to (parts of) OpcBrowseDialog and UABrowseDialog, respectively. Unlike with the dialogs, you have full freedom in creating your own visual appearance and behavior of the form, in case that the standard browsing dialog is not enough, or when you need closer integration with other parts of your application.

The controls can be configured to provide a tree view only, a list view only, or a combined tree view and list view. Examples of the controls in action are on the pictures below:

• The OpcBrowseDialog and UABrowseDialog dialog components (and the new OpcBrowseControl and UABrowseControl controls) now support multi-selection. It can be enabled by setting the MultiSelect property inside OpcBrowseDialog.Mode or UABrowseDialog.Mode to true.
• In relation to the multi-selection support described above, the relevant members of OpcBrowseDialog.InputsOutputs and UABrowseDialog.InputsOutputs have been moved to a new CurrentNodeDescriptor property, so that the multi-selection data can be placed into the SelectionDescriptors collection alongside it. Analogically, the relevant members of OpcBrowseDialog.Outputs and UABrowseDialog.Outputs have been moved to a new CurrentNodeElement property, so that the multi-selection data can be placed into the SelectionElements collection alongside it.
• There are new ways to control some finer aspects of the OpcBrowseDialog and UABrowseDialog. For example, the Mode.ShowListBranches property (defaults to true) controls whether the branches of the tree are also displayed in the list view.
• The browsing dialogs now have splitters that allow the user to influence the sizes of various parts of the dialog.
• When you set the Simulated property of the OpcBrowseDialog or UABrowseDialog to true, the dialog will provide its contents from a pre-defined, simulated view of the world, with fake networks, computers, OPC servers, and their contents. This can be useful for experimentation and testing, either by the developer during the design (right in Visual Studio), or by the end-user (if you expose this functionality in your application), when the environment is not accessible.
• In browsing dialogs, the context menu (right-click) on the computer or host nodes now provides a command to make a PING test to the selected computer or host.
• In browsing dialogs, when entering names of new nodes manually (such as for computers that are not listed on the network, or for servers or endpoints that are not discoverable), a tooltip appears below the edit box, explaining the type of information that needs to be entered.
• The browsing dialogs now contain additional small buttons above the tree view. The buttons allow to expand all nodes below the current node recursively, and/or to make the current node expanded, but collapse all its sub-nodes.
• All browsing dialogs now offer a choice to cancel any long-running operation (such adding a large number of nodes to the selection set).
• All browsing dialogs now change the mouse cursor when some operation takes longer time.

OPC XML-DA Support

• QuickOPC.NET now directly supports OPC XML-DA Specification Version 1.01 (Released). There are no new public components for this – the XML-DA support is seamlessly integrated with OPC Data Access. You can work with OPC XML-DA servers just as with COM-based OPC Data Access servers, simply by specifying the server’s URL in place of the usual machine name and server class (ProgID). Accesses to OPC-DA and OPC XML-DA can be freely mixed, even in the same method call. This transparency has been achieved by several generalizations in the object model and API, described further below.
• The ServerDescriptor (which previously contained mainly the MachineName and ServerClass properties) has been generalized to be able to describe both COM and XML based servers. The primary information in the ServerDescriptor is now its UrlString. For OPC COM servers, the URL is composed in such a way that it contains the original MachineName (now named Location) and ServerClass properties. For OPC XML servers, their URL can be used as the UrlString directly. This design makes the ServerDescriptor backwards compatible, and developers that use COM servers only do not have to make any difficult changes.
• The ServerDescriptor now contains an additional NetworkSecurity property. This object can optionally specify the network credentials used when connecting to an OPC XML server.
• The ServerElement now has additional UrlString and Location properties.
• The ServerDescriptor and ServerElement have a new Technology property, indicating whether the server is an OPC COM or an OPC XML server.
• At some places (where both OPC COM and OPC XML are covered), the MachineName property has been renamed to Location (and can contain either the machine name or a host name, which are essentially the same thing, but a common term covering both was needed).
• The [Server] attribute (ServerAttribute) for Live Mapping now has a UrlString property (a named argument), allowing you to specify an OPC XML-DA server for the mapping.
• The ServerElementCollection is no longer keyed by the server’s Guid (because OPC XML-DA servers do not have a GUID), but instead it is keyed by a ServerUrl (for COM servers, the server URL contains the GUID in it).
• OPC XML-DA does not identify OPC items by a single string as OPC COM. Instead, it uses an additional string, and only the combination of the two identifies an item in an OPC XML-DA server. The original string that roughly corresponds to OPC item ID is called “ItemName” in the OPC XML-DA specification; in QuickOPC, we use the existing ItemId property for it. The additional string is called “ItemPath” in the OPC XML-DA specification; in QuickOPC, we have introduced a new NodePath property for it. This property appears both in the DANodeDescriptor and DANodeElement. When you use the information received from the OPC XML browsing, both ItemId and NodePath are filled in the DANodeElement, and you can easily convert it to a DANodeDescriptor and it will “just work”. If you are getting the nodes (items) from elsewhere, you need to create a DANodeDescriptor that contains both these strings (at least in general case; some OPC XML-DA server do not use them both).
• The DAItemIdTemplateAttribute.TemplateString has been renamed to ItemIdTemplate, and a new property covering a template string for the OPC XML-DA “ItemPath” has been added, named NodePathTemplateString.
• OPC XML-DA identifies properties by a string (a XML qualified name), instead of the numerical code used in OPC COM. For this a reason, a DAPropertyDescriptor and a DAPropertyElement now have an additional QualifiedName property. When the component returns the DAPropertyElement from browsing, it fill is the information it knows about. When you pass the DAPropertyDescriptor to the component, you can fill in either PropertyId, or QualifiedName, or both. The component will use whatever is available and at the same time usable by the underlying technology. For the most common case, standard (well-known) properties can always be identified using their numerical ID, and the component will look up their qualified name automatically.
• The DAPropertyElement now contains an additional ItemPath property. For properties coming from OPC XML servers, if the property can be accessed as an item as well, the property is filled in with the string that together with the ItemId identifies the OPC item that corresponds to the OPC property.
• The DAPropertyDialog now has a PropertyDescriptor property instead of a PropertyId property.

Components Core

• In .NET, the main methods constituting the functionality of EasyDAClient, EasyAEClient, and EasyUAClient components, have been extracted into IEasyDAClient, IEasyAEClient, and IEasyUAClient interfaces, respectively. The remaining methods and method overloads, which simply build upon the core interface methods, have been re-implemented as extension methods on the interface. Also, at many places, arguments and properties that used to accept the concrete EasyXXClient now accept the interface IEasyXXClient instead. In most languages (certainly in C# and Visual Basic), this refactoring does not cause any change in syntax of your code. The new design allows to supply a different implementation of the component’s interface where needed, and is currently used for simulation purposes in the browsing controls and dialogs.
• All parameter and policy objects (and their constituents) now consistently have a static Default property. This allows for a cleaner code where an arguments is needed, but you want to supply a default (there is now no need to call the default constructor).
• The ServerDescriptor has new properties, all related to the original ServerClass property, allowing to individually retrieve or modify parts of the server class designation. The ProgId property contains a ProgID of the server (and is an empty string if the ProgID is not given). The Clsid property contains the CLSID of the server in a form of a Guid (and is Guid.Empty if no CLSID for the server is given). The ClsidString property contains the CLSID string of the server (and is an empty string if no CLSID for the server is given). The ObjectId property contains the object ID, i.e. a ProgID, {CLSID}, or ProgID/{CLSID}.
• For ease of use, added ServerDescriptor.FromServerElement, and a corresponding implicit conversion operator.
• The overloads of EasyUAClient.DiscoverServers method that accept the “application types” argument have been renamed to DiscoverApplications, in order to better describe the actual functionality that they provide.
• The EndpointUrlString property of the UAEndpointDescriptor has been renamed to just UrlString.
• The DAPropertyDescriptor no longer derives from the DANodeDescriptor. Instead, property descriptor appears together with a separate node descriptor argument where needed. DAPropertyArguments now also have an additional NodeDescriptor property for this purpose.
• Renamed some UABrowsePath members: BrowsePathElements to Elements, GetLastBrowsePathElement to GetLastElement, AppendBrowsePathElement to AppendElement.
• Renamed the IsolatedAdaptableParameters property to just IsolatedParameters.
• Removed the DefaultIsolatedAdaptableParameters property. The isolated (adaptable) parameters are now always initialized to a constant default.
• Removed certain obsolete members.

Documentation

• The main documentation chapters are now primarily structured by the development models, and not by the OPC specifications.

Examples

• Added EasyOpcNetDemoXml: This is a source of the Demo application for OPC “Classic” (OPC XML-enabled) that ships with the QuickOPC.NET product. The application shows most product functions, including the browsing forms, OPC property access, and event-based subscriptions. The defaults are pre-filled for OPC XML-DA demo server, but the application is written in such a way that it can handle COM servers as well.
• Added ListView1 example in VB.NET: Shows how (Windows Forms) ListView items can be populated with OPC data, either using explicit Read, or with a subscription.
• Added SubscribeMultipleItems example in C++.

Packaging

• Some types have moved from the EasyOpcClassic assembly to the EasyOpcClassicInternal assembly. As a result, more projects will also need to reference the EasyOpcClassicInternal assembly.
• New assemblies (do not have to be explicitly referenced, but need to be deployed together with your applications): OpcLabs.EasyOpc, OpcLabs.EasyOpcClassicNative, OpcLabs.EasyOpcClassicNetApi, OpcNetApi, OpcNetApi.Com, OpcNetApi.Xml.