Verify DSC connection with OPC server and Ge Fanuc 90-30?

[VRspace4]

Hello,

I would like to continuously verify the connection between LabVIEW DSC, OPC server (KepServerEx), and the actual hardware (GE Fanuc 90-30)  in the background while LabVIEW is running. If there's a lost of communication between LabVIEW and KepServerEx, then LabVIEW would respond by changing the small LED at the top right of every control to RED. But what if the connection between KepServer and the GE Fanuc 90-30 is lost? How can I program LabVIEW to trigger an event when this happens? Or how can I retrieve the error messages output from KepServerEx log from LabVIEW?

I was also thinking about programming an event structure for every control to verify its new value to the actual Shared Variable which is mapped to the OPC server tag; if this value is different for more than a number of seconds then it means there is a connection lost with the physical hardware. But this way may be too time consuming as I have more than 200 tags.

What is the best way to do this? Please help.

- James

[RavensFan]

Will the OPC server report the quality of the data?  If so, you could look at that to see if the connection has been lost.

[VRspace4]

The OPC Server does report the quality of the data, but how do I program LabVIEW to retrieve it during run time?

[RavensFan]

I haven't done this before, so I had to figure it out myself.  See attached.

You can feed the Shared variable to a Datasocket read.  You can use the Variant get attributes to get the Quality of the data.  I found that I got a 64 for no known value and a 0 for a good value.  I don't know what the other codes would be.

There may be better and cleaner ways to do this.  If so, perhaps someone else can comment into this thread.

[RavensFan]

I found a NI document listing all of the shared variable error codes here.  They also attach zip file with a VI and enum control that you can use in your code to decode the shared variable quality from the numeric code it returns.

I did find 2 errors in their document and VI's that seem to be repeated throughout much of the documentation.

1.  A bit is set for each error present.  For some reason, they number the bits as 1 through 32 rather than 0 through 31, which goes against generally accepted practices of decoding bytes.  So no known value is error code 64.  That is 2 to the 6th power.  Yet they call that bit 7.

2.  For some reason they mispell the word existent (as in non-existent) as "existant". 

These are things that could be easily corrected in their VI's if you use them, or beware of when comparing their documentation to the returned numeric code.