02-04-2010 03:27 AM
I am using shared variables for their built-in OPC server functionality. I have configured some of my SVs as strings, as arrays of doubles, as arrays of booleans, and as arrays of strings. When I connect to the NI shared variable engine using the MatrikonOPC Explorer OPC client application (a free app recommended for OPC troubleshooting on the NI website), I see data for all of the shared variables EXCEPT the SVs that happen to be arrays of strings, which show no values and a quality of "Uncertain, non-specific". If I use DataSocket to connect to the same SVs using their OPC URL, I see the same quality result (Quality=64). Is there something I need to do to ensure that SVs configured as arrays of strings work properly as OPC tags? (string lengths?, termination characters? etc). In MatrikonOPC "Array of Strings" is listed as a possible Data Type, so I assume that what I'm trying to do is not impossible. The reason I'm trying to have OPC tags as arrays of strings is because my system has a variable number of channels, and I want to transmit the channel name list to an OPC client. Does anyone have experience with this?
NI Software : LabVIEW version 8.6.1
OS : Windows XP
02-04-2010 05:15 AM
Hi Dan,
I must say that I have not seen normally that array of strings is supported data type. I guess that because length of string may vary it is difficult build memory handling for such datatype.
I don't understand your system configuration LabVIEW is OPC server but which application is normally OPC client?In which application reads these channels?
02-04-2010 06:26 AM
I've downloaded a couple of free OPC client apps (MatrikonOPC and CAS OPC) and they both seem to list an array of strings as a possible data type, though I can't say if that is a commonly implemented one or not.
You are correct that I would like the LabVIEW shared variable engine to act as an OPC server in my application. Data will be acquired on the PC running LabVIEW, and written to OPC tags for sharing with another PC on the network. I'm actually not positive what the client application will be, since it will be supplied by the customer that is purchasing the software. It might be Wonderware, but I'm not 100% on that.
If I am unable to solve this problem then I guess I can always create a separate SV/OPC tag for each DAQ channel and pass data that way, rather than my current method of creating only two SVs: one that is an array of channel names (strings), and one that is an array of channel values (doubles). It just seems a bit inefficient to create a whole bunch of OPC tags that may or may not be used, since the number of channels enabled and their names will all be based on a user-supplied configuration that may change from one run to the next. I'm not much of an OPC expert though, perhaps creating a whole mess of OPC tags is the normal methodology that people use.
02-04-2010 06:38 AM
I see. In my use cases I have never used string data type even in scalar format. If channel names are constant you might use some kind of coding e.g 1= channel 1, 2= channel 2 etc... then you can use integer typed array and convert values to strings on client side.