_images/Bug72.jpg

What is the “read all” feature and what are its rules?

Each device interface has a new DeviceState property which will return, in a single read, a list StateValue objects, each of which is a name-value pair. The list must contain all of the device’s operational properties. Configuration information is not included because this is either set and known by the application or can be read once at the beginning of an operation.

Each device’s specified operational properties are defined in the documentation for that device, for example, Telescope.DeviceState. From both the client’s and the device’s perspective, DeviceState is a “best endeavours” call. This is to ensure that the maximum amount of available data is returned by the device to the client.

Important

Applications must expect that, from time to time, some operational state values may not be present in the device response and must implement a strategy to deal with such “missing” values.

Important

If you wish to report additional values to clients, beyond those defined as operational, implement an Action e.g. via Telescope.Action and Telescope.SupportedActions and return your items in this way rather than adding them to the DeviceState response.

This is to ensure that the DeviceState call is as performant as possible for both client and device and is not burdened with information that unduly increases its size and transmission time.

Conform will report non-standard StateValue items found in the DeviceState response as Issues.

Note

  • If a particular operational property is not available for any reason, its StateValue object must simply be omitted from the DeviceState list - do not throw a DriverException in this circumstance.

  • If no operational states are available for the device, an empty list (with no TimeStamp) must be returned.

  • The DeviceState property should only throw exceptions under the most exceptional circumstances such as losing connection to the physical device.