800xa-single line cross mark (like underflow)on element and faceplates
Hi, we are using xa5.0 sp2 rev D system.
A single line cross mark obsreved on faceplate and graphic elements(few tags of different controllers), Like we use to observe incase of underflow.
value is not under range as configured in system.
cross mark is observed in clients using OPCDA of primary connectivity server.
at the same time affected tags are obsreved in clients using OPCDA of Redundant connectivity server and found in healthy condition.
Once we refresh the faceplate or concerened graphics of affected tags, the tag becomes healthy.
It seems like broken OPC subscription gets resolved once we refresh the faceplate or graphics.
checked controller logs, didnt found any relavent info regarding OPCDA abnormality.
Checked RNRP found OK.
What could be the probable causes of such single line cross marks.
Thanks in advance
Answers
>"It seems like broken OPC subscription"
Yes, The OPC connection is resoved properly - but the data quality from the primary connectivity server is "bad".
There could be a lot of possible reasons, but theres not enough info here to troubleshoot.
IIRC, single dash correspond to OPC quality code "Uncertain".
"Uncertain" can only be set from the OPC server.
Background fact: 99.5% of quality codes originate in server - I believe only "Not connected" can be *injected* by the 800xA framework, eg if affinity, network issue or an expired domain password prevent client computer from reaching the Connectivity server.
The AC 800 OPC Server will set "Uncertain" after a number of failed attempts to communicate with a controller (I believe in the range of 3-5 MMS cycles).
Application download is known to temporarily suspend MMS; but then both OPC servers should have been affected. But sporadic problems with FSD file set propagation or synchronization is known to be able to strike out singular servers. Given the recovery method I deem FSD problems unlikely.
Check if any history trend log recorded any bad quality.
With current info available, I recommend concentrating your efforts on the controller and network communication between controller and OPC server. Check switch port statistics for higher than expected fault rate (at half duplex, a couple of percent out of total traffic volume in respectively out may go lost in CRC and collisions but accept NO Late Collisions). MMS uses TCP transport - hence a tool like Wireshark will be able to sniff for abnormal telegrams (TCP Reset, Checksum, Out of sequence, etc).
Source:
Add new comment