Home Downloads Buy Now !



The Local IO assembly provides the functionality needed to get data to and from process instrumentation via OPC DA servers. Other protocols will be supported in the future. The main class that provides the application interface is the TagServer class. Tag data can come from local OPC servers or OPC servers located on any other network host on the current domain. The terms Local IO and TagServer generally refer to the functionality contained in the 'IDN IO.DLL' assembly. The following diagram illustrates the basic topology and components used.

 Data Flow

The basic tree data structure starts with a TagServer object as the root object. A TagServer references IONodes, IONodes reference IOServers, IOServers reference IOSchedules and IOSchedules reference IOTags. Each of these classes derive from a base class called IDNBrowsable. IDNBrowsable provides Parent and Children relationships as well as other common properties and methods, (such as Name), needed for creating and browsing the tree structure. There are also some commonly needed methods included in the base class such as is needed for searching up or down the tree for specific objects. PropertyChanged events are provided by the base class so all of the IDNBrowsable derived objects can be treated as much the same as is possible.

An assembled and running TagServer can be largely event driven although in some cases it is better to poll for tag Updates. Data comes in from the OPC server's Groups to IOSchedules where applications can subscribe to receive Updated events. IOSchedules also feed IOTags with updates so subscribers also have the option to subscribe to individual IOTags' Updated events. The IOTag's current values are kept up-to-date by data coming in from the OPC Groups according to the IOSchedule's Period and PercentDeadband settings. Although it is very easy, it is not necessary to receive events to retrieve the most current data. You may wish instead to poll for the most resent values by simply checking the IOTag's Value in the case of updating the screen on a timer or generating a report. IOTags have a Changed property that is always set when a new value arrives from the OPC server in which your application is free to clear once your destination is updated. You can keep separate lists of IOTags or IOSchedules, you can get all of a schedules tags via its Children list, you can search the tree for them, or you can let the user select one of either with the TagServer's SelectItem method.

 To UI or not to UI

A complete UI is provide by simply calling TagServer's Show() or ShowDialog(). There are also several separate forms that can be used that are provided by the various classes. However, there are a number of reasons for not using the built in UI. For example, if your application simply reads a file for configuration information and executes an operation (such as a one time report or recipe download), your application is a Windows service or, if you prefer to write your own UI for better integration into a larger application. There are no MessageBoxes or other popup that occur unless you are already in a provided form so there is no problem running a zero UI like a Windows service. Error messages are sent to the application via the TagServer's Errored events or can simply be routed for you to the Windows Event log by the TagServer.

 A Word about Performance

It has been our experience that the performance of getting the OPC tag data into the IOTag is very fast even when using a remote OPC server. However, once you try to use the data, things can slow down. DataGrids and other controls must be looked at if speed is an issue. This is why our TagServer and Quick Data main forms update their grids based on a screen timer. The one exception is Quick Data's IOTag Data sheet (Tab) which updates and stores the value in the circular buffer when the tag's event fires. You can compare the performance by looking at the percent of the CPU used while displaying grids vs. hiding the grids or viewing the tag's Data sheet.

Copyright © 2004-2017 Industrial DOT NET, Inc.