Classic off-the-shelf client/server interfaces like OPC are optimized for collecting information from any data source at some predefined cyclic interval. Within the client application, an end user can browse for information that is contained in one or more servers. The information of interest can then be selected and tied to UI controls for visualization, alarm and event objects for condition monitoring, or trends for historical analysis. As part of this, the end user will also set how often each piece of data should be polled from the data source. Although perhaps over-simplified, the rest of the scenario is as follows: the end user enters Run Mode, the server polls the data sources at the appropriate intervals and sends updates to the client when the value or quality of the data changes, and the client performs the necessary logic on the information as configured by the end user. The process continues until the client application is stopped.
In most cases, this streamlined communications configuration is all that is needed; however, there are some instances when an end user’s particular client application requires tighter control over the underlying communications between the server and the data sources. Although some of these off-the-shelf client/server interfaces actually support the notion of a “client controlled device read,” few client applications do. Fortunately, these same clients usually support a rich scripting environment that allows a clever server-based application to provide end users with the control they need via a simple tag-driven interface accessible to any client application that supports OPC Data Access (OPC DA).
KEPServerEX Version 5.13 Release
Our KEPServerEX version 5.13 product now supports a special System Tag called _DemandPoll for each device object that is contained in the project. By setting a device’s Scan Mode to “Do not scan, demand poll only,” an end user can configure the client application to reference one or more device I/O points (or tags) within the application. This also ensures that the I/O points are not polled until a write to the _DemandPoll Tag is initiated by the client (either driven by a button or some set of conditions that are monitored and controlled within the client’s scripting environment). Upon writing to the _DemandPoll Tag, the server will poll all tags that are referenced by a client application on the device associated with this System Tag. The server will then send the data updates to the client application, at which point no further device polls will occur until the next _DemandPoll write. If for some reason the server is unable to poll a particular item, it will send an update with a bad quality indicator.
Those of you who are familiar with OPC and compliant behavior may recognize that this design does not fully comply with the OPC specifications. First, the client application will be subscribing to a set of active tags and will never receive an update until the _DemandPoll Tag is written to. Second, any client that is subscribed to the device associated with this System Tag will also receive updates even though they did not initiate the _DemandPoll write. This behavior can be avoided if desired by creating a separate device reference in Poll Only mode to be used solely by the client that requires tighter control over poll requests. Furthermore, some client applications may not allow you to configure a group update rate (the rate at which the server sends data updates back to the client) that is fast enough for the poll on-demand operation that is needed. In those cases, you can tweak the OPC Compliance behavior by selecting “Ignore group update rate, return data as soon as it becomes available” within Project Properties. This option bypasses the group update rate and sends data updates to the clients as soon as they are available.
Meet Client-Driven Polling Requirements
With this added flexibility, KEPServerEX enables you to meet the client-driven polling requirements of your application. Furthermore, you can also configure the server such that existing client applications will maintain the same level of performance and behavioral characteristics as in previous versions of the product.
As always, we are interested in learning more about your communications needs and appreciate your feedback on this functionality.