Client polling timing

As with most drivers, the polling cycle timing is dependent on the number of proxy points currently in the “Dibs”, “Fast”, “Normal” and “Slow” polls. There are also properties of the R2ObixClient that may need to be adjusted from default values, in support of the oBIX “watch subscription”.

Watch Interval

An R2ObixClient device’s Watch Interval property controls the polling of the watch, and is found on its Points extension. The default watch interval value is 2 seconds. Typically on an R2ObixClient device, the watch interval should be increased to 10 seconds or more, to reduce the load on the R2 platform.

Watch Safety Factor

The parent R2ObixClient also has two related properties, as follows:

  • Watch Safety Factor — Often, you should also increase the watch safety factor (default is 10 seconds). This specifies the time added to the watch interval to calculate the requested “lease time” of the watch. Essentially, this is the “COV subscription lifetime” the AX client is requesting from the R2 server. This is more important if using a shorter watch interval, because the driver calculates two values to use as the requested lease time, choosing the larger of the two:
    T1 = watch interval * 2
    T2 = watch interval + watch safety factor

    For large watch intervals, the requested lease time is inherently big (2x). But the safety factor provides an independent way to control requested lease time, such that you could make it 3 or 4 times the watch interval, if desired.

  • Session Timeout — How long the NiagaraAX client waits on a particular request before giving up. If the R2 station takes longer than 15 seconds to return the watch once polled, you may need to increase the session timeout.
     NOTE: The sessionTimeout slot on an R2ObixClient device is hidden by default. Go to the device’s slot sheet and remove the hidden flag from the slot. Once visible, you can go to the property sheet of the R2ObixClient and adjust upward to tune, if needed. 

Debug notes

Enabling debug on the R2 server can be useful to diagnose initial problems, but should never be used unless necessary, as it greatly slows the server’s response time to the AX Client.

If you encounter errors similar to:

HTTP Error 503:Service Unavailable

this indicates the R2 host has run out of webservice threads.