Static Efficiency of Point Management Requests

To develop an efficient application you will usually design the application so the least number of messages are passed between the application and Point Management.

In general a message is sent from:

  • The application to Point Management when you send a request to point management,
  • Point Management to the application when your application receives a data value (multiple requests and data values do get packed into the messages when possible).

From this you can assume the following about requests.

Requests Comments
SNAPSHOT Most efficient way to get a value required only once. However, when a value must be retrieved multiple times, SNAPSHOT requests will be staticly inefficient. This is because two messages are required to collect a single data value: one to send the request; and another when the data value is sent to your application.
TIMED more efficient when a value is required periodically, because once your application makes the request of Point Management, it never has to do so again. On the other hand, if the time interval specified in the TIMED request is short (a few seconds or less), your application will consume substantial CPU resources because it will be receiving data values frequently.
ONCHANGE (Like timed requests) are more efficient when a value must be monitored in an ongoing fashion, because once your application makes the request of Point Management, it never has to do so again. Since your process will be informed whenever the point value changes, you receive the data only when necessary. Depending on the frequency of changes in point value, the polling rate for the point, and the requirements of your application, ONCHANGE requests may be more or less efficient than TIMED requests.

Consider the following for point types.

Point Type Comments
Digital There should be no reason (other than programming convenience) for requesting points on a TIMED basis. Your application should always request that the point be requested ONCHANGE.
Analog Consider the frequency at which you really need to track the data. If your analog values tend to change slowly with small fluctuations, it may be better to make timed requests.
Example You have configured an analog point that it is sampled every 5 seconds, i.e. the base scan rate for the device is 5 seconds and the point is configured to be scanned at 1 times the base scan rate. The dynamics of the point are such that it changes every 5 seconds, but within a range that is insignificant to your application. In this case it may be better to request the values on a TIMED basis at 1 minute intervals if small fluctuations in value matter little to your application. Note that although your application receives the point every minute, status monitoring screens will continue to receive the point whenever it changes. If you think that under no circumstance is it necessary for the point to be sampled at 5 second intervals, you should consider changing the scan rate for the point.