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.
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.
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.
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.