Applies To: |
|
Summary: |
Many may be familiar with an OPC quality value of 192 or 0xc0 representing "good", but how, why and what are all the other possible values. Well the quality value actually contains three seperate bit fields each with its own meaning. It makes much more sense if you convert this 192 decimal value into binary, which is 11000000, then apply that to the following excerpt from the OPC DA 3.00 specification (section 6.8 OPC Quality Flags) |
Solution: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Quality FlagsThese flags represent the quality state for a item's data value. This is intended to be similar to but slightly simpler than the Fieldbus Data Quality Specification (section 4.4.1 in the H1 Final Specifications). This design makes it fairly easy for both servers and client applications to determine how much functionality they want to implement. The low 8 bits of the Quality flags are currently defined in the form of three bit fields; Quality, Substatus and Limit status. The 8 Quality bits are arranged as follows: QQSSSSLL The high 8 bits of the Quality Word are available for vendor specific use. If these bits are used, the standard OPC Quality bits must still be set as accurately as possible to indicate what assumptions the client can make about the returned data. In addition it is the responsibility of any client interpreting vendor specific quality information to insure that the server providing it uses the same `rules' as the client. The details of such a negotiation are not specified in this standard although a QueryInterface call to the server for a vendor specific interface such as IMyQualityDefinitions is a possible approach. Details of the OPC standard quality bits follow: The Quality BitField
Comment: A server which supports no quality information must return 3 (Good). It is also acceptable for a server to simply return Bad or Good (0x00 or 0xC0) and to always return 0 for Substatus and limit. It is recommended that clients minimally check the Quality Bit field of all results (even if they do not check the substatus or limit fields). Even when a `BAD' value is indicated, the contents of the value field must still be a well-defined VARIANT even though it does not contain an accurate value. This is to simplify error handling in client applications. For example, clients are always expected to call VariantClear() on the results of a Synchronous Read. If the server has no known value to return then some reasonable default should be returned such as a NUL string or a 0 numeric value. The Substatus BitField The layout of this field depends on the value of the Quality Field. Substatus for BAD Quality:
Comment Servers which do not support Substatus should return 0. Note that an `old' value may be returned with the Quality set to BAD (0) and the Substatus set to 5. This is for consistency with the Fieldbus Specification. This is the only case in which a client may assume that a `BAD' value is still usable by the application. Substatus for UNCERTAIN Quality:
Comment Servers which do not support Substatus should return 0. Substatus for GOOD Quality:
Comment Servers which do not support Substatus should return 0. The Limit BitField The Limit Field is valid regardless of the Quality and Substatus. In some cases such as Sensor Failure it can provide useful diagnostic information.
Comment Servers which do not support Limit should return 0. Symbolic Equates are defined for values and masks for these BitFields in the "QUALITY" section of the OPC header files. |
Keywords: |
Related Links
Attachments