Scan Classes

Scan classes dictate the execution of tags, and therefore play a crucial role in the design of large, high-performance systems. It will often make sense to have more than one scan class. Usually not all of your tags will need to be subscribed at the same rate. Some tags you may wish to see updated at 250-500ms, while others may not be so crucial and may only need to be subscribed at 1500ms. Creating different scan classes allow you to organize your tags into groups that subscribe at different rates. It is good practice to put some forethought and planning into the organization of your tags and scan classes.

Scan classes are created by clicking on the Edit Scan classes button in the Tag Browser toolbar. The window will appear with a list of configured scan classes on the left, and configuration settings on the right.

Scan Class Name	Unique name of the scan class.
Mode	Described below
Slow Rate	Base update rate, specified in milliseconds, at which tags will be executed.
Fast Rate	Used by the Driven and Leased modes, this is the faster rate that the tags will be executed at when those modes are active.
Stale Timeout	How long to wait before the tags in the scan class are determined to be "stale" (not running). This is calculated off of the last expected execution time of the scan class, and is particularly important for scan classes executed by other drivers through the external SQLTags provider. This property is not used by internal providers.
Driven Properties	Used by the driven mode to determine when the scan class should run at the fast rate.
Advanced Properties	Settings that subtly affect how the scan class operates.

Note on rates: If the rate is set to 0, the scan class will not be executed. It is common for leased and driven modes to use 0 as a slow rate in order to achieve an "on/off" effect.

The scan class executes at the fast rate when any of the tags it contains are subscribed and visible in a client window. If no tags are subscribed, the scan class runs at the slow rate.

The rate of the scan class is based on the value of a driving tag. The condition is a simple comparison between an a tag value and a number. If the condition is true, the scan class will execute at the fast rate. If false, it will run at the slow rate. There are two exceptions to this: the any change operator, and one-shot mode. Using either of these, the scan class will not run at a rate. Instead, it will be triggered by a change in the driving tag's value. "Any Change" will execute each time the value changes, and "one shot" will execute once when the comparison condition is true, and not again until the condition become false, and subsequently true.

It's useful to keep in mind that the driving tag can be an Expression tag that performs complex calculations and references other tags. In this way, it's possible to create robust scan class triggering.

This mode dictates how OPC values are obtained. The default mode, "Subscription", is generally recommended.

•

Read - Tags will not be subscribed, but will instead be synchronously read each time the scan class executes. This operation is less efficient, but allows more precise control over when values are obtained. This mode is particularly useful when collecting data over a slow or expensive connection for display. When combined with the "one-shot" execution mode above, and a static tag tied to a momentary button, it's easy to create a manual refresh button on a screen that pulls data on-demand.

Historical scan classes are simply standard scan classes used by tags to store history. By utilizing separate scan classes for status and history, it's possible to maintain a tag's status at a fast rate, without storing large amounts of history unnecessarily.

Despite the fact that there is not a technical differentiation between standard and historical scan classes, it is recommended that you create separate scan classes for each purpose and name them in a manner that indicates their usage. It is common to modify scan classes in order to affect a large number of tags, and without a consistent distinction it may be possible to affect tag execution in unexpected ways.

A scan class executes all of the tags contained in it in a single thread. Therefore it is occasionally important to understand how different types of tags are executed, in order to understand the implications of configuring scan classes in a certain way, or with certain items. For example, a scan class with many SQL Query tags should likely not also be used as a historical scan class- the execution of the sql queries may take an unpredictable amount of time, and could delay the collection of historical values.

For OPC tags, the scan class defines the rate at which data is subscribed or read (based on the opc data mode). If set to read mode, the read is executed as part of the scan class execution. This operation can be expensive (usually on the order of 50-500ms, though large numbers of tags can take longer). In subscribe mode, though, the value updates occur asynchronously, outside of the scan class execution. Alarms and History are evaluated when the value changes, and may be evaluated as well when the scan class executes.

Values for memory tags are applied instantly, and do not wait on the scan class.

Expression and Query tags execute according to the scan class. Even if an expression function has a poll rate, the value of the tag will only be updated during the scan class execution.