Applies To:
  • CitectSCADA
  • CitectHMI
Summary:
My client intermittently shows #COM for some tags. Most of the time it is perfect, but it can randomly flicker #COM.
If I look at the tags in a generic client and they are perfectly fine. Why is CitectSCADA showing #COM?
If I open the PROBE window in the KERNEL, I see logs with an error 2019 reported. What does this mean?

Solution:
Firstly - The reason for the 2019 error shown in the PROBE window is that a tag data response packet that has been received, contains an OPC-Quality that is BAD. NOTE : There may be more than 1 tag in a response. Only one of those tags needs to be BAD for this error to be generated.

Secondly - In the OPC Driver, if the [OPC]FailOnBadData=1 (default) is set, then any response that has a BAD will make that response invalid and ALL tags that are covered by that response will show #COM.

Thirdly - The reason that the error occurs intermittently is that CitectSCADA will dynamically optimise requests for data. This means that while the tag is displaying perfectly, that may be the only tag being requested. When the #COM displays, you may find that CitectSCADA has decided to also request an additional tag (either shortly before or after the good one) in the same request packet. The response packet may now also contain a BAD Quality value and therefore the whole packet is discarded.

Finally - The most appropriate solution is to not have any BAD data coming into CitectSCADA. If you can identify the bad tag you can (a) remove it from the tag list or (b) move it to the end of the variable.dbf file to avoid being blocked with the good tags. You could also set the [OPC]FailOnBadData=0 (see the help and Q4082 for more information).

See Also : [OPC]FailOnUncertain and [OPC]SuppressDataNotYetValidError
 

Citect have confirmed this problem and are researching it for future versions.

 
Keywords:
 

Attachments