Communication with a remote OPC server in LabVIEW - Use of DataSocket and performance

[jihef]

Hello,

I have several questions about how to implement the communication with an OPC server in a LabVIEW application.

1. I have made a little VI to test how to read a value on a remote OPC server. I have the following problem : if the timing between the "DataSocket Open" and the "DataSocket Read" is too short (typically no wait or wait less than 100ms), the execution of both "DataSocket Open" and "DataSocket Read" is done without any error , but after the execution of "DataSocket Read" no value has been read. If the wait is long enough, the "DataSocket Read" gives the good result. Is this normal ?

2. When I use a "DataSocket Open" and then a "DataSocket Read", what happens in terms of OPC communication?  Is there a creation of one OPC group and then this group is read ?
If I want to access several OPC items and I make several "DataSocket Open", is there at each time the creation of an OPC group ?

3. I have seen that there was a library called dataskt.llb. What is the purpose of this library ? In LabVIEW 8.20 what interface is preconized ? (use of  "DataSocket Open" / "DataSocket Read" or use of the VI's of datask.llb ?).

4. On NI forums, I have seen some exhanges showing that there were some performance issues with the utilization of DataSocket for OPC communication (when the number of items was too important). Is it still true with LabVIEW 8.20 ?
In this case I read that the use of DSC could be a solution.
Isn't there an intermediate solution that would be to use from LabVIEW the Data Access Automation of the OPC Automation wrapper ?
Has someone an experience of this implementation ? Is it better, in terms of performance, than the solution with DataSocket ?


Thank you by advance for your response.

--
jihef

[ClementG]

Hello jihef,

1. You said that you are using a remote OPC server. I think that is the explaination of the delay you are seing before the data can be read,

I don't think the data socket functions are responsible for this delay. Indeed, if you want you can try to connect to a local OPC server, the National Instruments OPC demo server that ship with LabVIEW for exemple and you wil see that the connection is really fast, actually I didn't have to add any delay between the datasocket open and datasocket read functions ( I attached the VI I made below). I think the delay you encountered is due to the time for the connection to be made between the open client (LabVIEW) and your remote OPC server.

2. You are right, one OPC group is created for each datasocket OPC connection, every access to a single item acts like a single client connection to the OPC server. So if you open 1,500 DataSocket OPC connections this equals to 1,500 clients connected to the OPC Server. Datasocket is not really good when you want to access more than 100 items. Thats why we have the DSC module that allows to handle thousands of items. The way it works is quite different to the datasocket connection. Basically you are using shared variables to link to your OPC items. All shared variables are grouped into a common library which is deployed at once for all the variables.

3. I don't know the library you are talking about, I didn't find it on my computer, even after using a windows search. Is it something you found somewhere on the web? Could you tell me where you found it, or where is it located on my computer and i'll try to help you more with it.

4. Last point, I may have answer in the previous points, the use of DSC is the best solution when you want to use LabVIEW as an OPC client. Datasocket is another solution but offers less functionalities and has lower performance, that also why the DSC module is sold as separate product as the core version of LabVIEW whereas the datasocket ship free with LabVIEW.

The DSC module also add much more functionalities for SCADA systems than connectecting to OPC server as the datasocket does, like the ability to log data into database, configure alarms and add security features to your applications.

I think what you wanted to say in your last point was the use of some intermediate server that will connect to your OPC and then allows the data to be transfered to LabVIEW. If it is what you mean, this is possible but it's not the best solution. Again, for me the best solution would be the use of the DSC module.

If you want more information on the DSC module, I attached below he link to the NI webpage:

LabVIEW Datalogging and Supervisory Control (DSC) Module

Best Regards,

[ClementG]

jihef,

Just to complete my previous answer, I found the library you are talking about.

In fact the VI located in the library are the datasocket functions and the subVIs used by this functions that were used in previous versions of LabVIEW. This librairy is present in your hard drive for backward compatibility, that why you cannot see them in your functions palette. In other words the VIs are still shipped with LabVIEW in case you would open a VI with datasocket functions which have been created with an earlier version of LabVIEW.

The functions you see in this library have been improved and replaces by the one you have in your function palette. Basically they were doing the same things you can do with the new functions. So I would advice you to use the new functions ( which are improved and less subjected to bugs).

Hope this will help.

Regards,

[jihef]

Hello,

Thank you for your answers, ClementG.

1. I think your explanation is probably right. I agree that there can be a delay due to the fact that the access is done to a remote OPC server, but this delay should interfere with one of the functions "DataSocket Open" or "DataSocket Read" (either the connection or the first read should be a little longer, but here there is a problem of synchronization).
I hadn't read in the documentation, that, to access a remote OPC server, it was necessary to introduce a wait between the function "DataSocket Open" and the first call to "DataSocket Read". I think it's not very secure : what is the "good" duration of this wait ? Does this value depend of the performance of the client ? ...of the server?...

2. Ok : it confirms what I had understood.

3. Ok.

4. My explanation was not clear : I don't want to use an intermediate server, but to implement the automation wrapper of the OPC foundation. In other words, I want to use the DLL "OPCDAAuto.dll" which exposes an Automation COM interface (more details here).
I have to develop an application treating a certain number of OPC items (typically one or two hundred items). From what I read, DataSocket API doesn't suit very well in this case. Concerning DSC the inconvenient is the price of the license and I think DSC has many functionalities that I don't need.

That's why I am searching for an intermediate solution and that's why I wanted to know if someone had already implemented this kind of solution and what were the capacities in term of performance.

Thank you by advance to anyone able to give me an advice on this topic.

Best regards.

--
jihef

[ClementG]

Hi,

Sorry but I can't help you with the use of the dll you are talking about, i've never used such a way to communicate with OPC elements.

regards,

[Ahmad12]

Dear jihef and ClementG

Using your experiences, now I'm going to use DSC module. But I have some trouble with using DSC. Here is my problems:

1- It seems I have no control on creating OPC group within DSC module (at least with mine: DSC module v.8.0). I mean I want to name and create one OPC group and create my own shared variable within this group. Could it be overcome using DSC Module v. 8.2+ by creating Library (and hence OPC I/O server) and shared variables dynamically?

2- ClementG has mentioned that by using DSC module solution, only one group will be created, but in my OPC Server source code I've seen many calls to AddGroup method by browsing OPC items and groups. and the strange thing is the name of group passed to this method (AddGroup) which is an empty string!!!

3- And the last: My OPC DA Server is a 2.05 one. I have no problem with it using OPC clients other that LabVIEWs, e.g Matrikon OPC explorer and my own OPC client implemented in C++, I can browse to its opc items and add them to my created group(s) and monitor them as well. but when I'm going to bind shared variables to OPC items (Bind to Source) and going to browse, it could do that but recognize my OPC items as OPC group (hence the OK button is still disabled). If I entere the path of my OPC items manually (replacing dots (.) with /), this will not work too (I got red indicator beside the controls bind to those shared variables). I'd like to emphasize that Matrikon OPC explorer recognize my opc items as well.

By the way, I'm going to upgrade to DSC v. 8.2 at least in order to launch ClementG sample code 😉 (and ofcourse because of creating shared variables and connection to OPC servers dynamically).

Thank you in advance for your help and advice(s).