Of OPC, DataSocket, ActiveX, LabView, VB, etc.

[sal]

Hi,
Can someone help me clear up some confusion I'm having concerning connecting to OPC servers. Here are my questions/assumptions. Any comments are appreciated.

When using LabView to connect to OPC servers via Datasocket, why is it beneficial to use the "sync" datasocket vi's? Does LabView not handle activex events properly?

Isn't using Datasocket just using activex?

If my OPC server has an activex control to access the server, would it be better to use this control or to use datasocket?

How do other programming languages connect to OPC servers? Only through activex or a custom low level .dll?

Thanks fo any help.

[JeremyB]

Sal,

I can answer several of your comments regarding DataSocket and I hope they shed some light on the subject:

>>Does LabView not handle activex events properly?
My experience has been that there are no fundamental problems with using ActiveX events with LabVIEW. This functionality was only introduced in LabVIEW 5.1. Does your question mean that you are currently having problems in this area? There are several posts on Developer Zone that relate to ActiveX events in LabVIEW - most problems that I have had have been resolved by running the LabVIEW application on a single thread, rather than multiple threads by default.

>>Isn't DataSocket just using ActiveX?

The short answer is no. ActiveX is currently a communication method used solely on the Windows platform. DataSocket is NOT platform specific, for example a VB application running under Windows could communicate using DataSocket to a LabVIEW application running under MacOS. DataSocket provides a simplied API for users wishing to share information between two or more applications. The underlying protocol (TCP/IP, ActiveX, ftp and so on) is hidden from the programmer, making the development of such applications a simpler task.

The following white paper provides a good introduction to DataSocket, its history and comparisons with existing communication protocols:
http://www.ni.com/pdf/wp/wp1680.pdf

>>If my OPC server has an activex control to access the server, would it be better to use this control or to use datasocket?

The answer to this question depends a number of areas.
1. How much documentation is provided with the ActiveX control?
2. How much experience/comfort do you have using ActiveX objects inside of LabVIEW?
3. How much functionality is exported via the ActiveX control?
4. Might you need to port your application to another OS in the future?
5. How stable is the ActiveX interface provided? Microsoft went through a process of changing their ActiveX model for their Office applications (Word, Excel and so on) such that you needed to recompile/make mods to your software if you upgraded from Word 97 to Word 2000.

The DataSocket programming approach is very straightforward. Simply open a connection with the OPC server using a suitable URL (opc://xxxxxxx/xxxx) and then read and write to the appropriate tags/data items that have been created/exposed by the OPC server. Once you have finished, simply close the DataSocket connection. You do not have to be aware of the underlying actions that are taking place to allow communication to happen. It could be that the OPC server is not even located on the same PC - regardless of the set up, the DataSocket approach is the same.

>>How do other programming languages connect to OPC servers? Only through activex or a custom low level .dll?

The OPC Foundation has developed a unified OPC Automation API for the communication between OPC clients and servers. This approach may mean that suppliers of OPC-capable software may provide an ActiveX interface or a more traditional interface via a DLL. There is an example on Developer Zone discussing the control of an OPC server from Visual Basic using the OPC Automation API - in this instance the interface software is a DLL. The choice of interface is up to the software supplier.

My recommendation would be that if you have an OPC server and you are using LabVIEW, LabWindows/CVI, Visual Basic (with Measurement Studio), strongly consider the use of DataSocket to help simplify your application development process.

Jeremy

[sal]

Thanks Jeremy,
But your answers have prompted futher questions! Thanks for the help!!

>>Does LabView not handle activex events properly?
My experience has been that there are no fundamental problems with using ActiveX events with LabVIEW. This functionality was only introduced in LabVIEW 5.1. Does your question mean that you are currently having problems in this area? There are several posts on Developer Zone that relate to ActiveX events in LabVIEW - most problems that I have had have been resolved by running the LabVIEW application on a single thread, rather than multiple threads by default.

>>>I'm not using ActiveX events, so I can't say I'm having any problems. My question was generated by the fact that some Datasocket vi's were modified by NI to remove the "wait on activex event.vi" because of poor performance. Why was this removed, then?
Isn't running LabView on a single thread defeating the purpose? Won't performance suffer?


>>Isn't DataSocket just using ActiveX?


The short answer is no. ActiveX is currently a communication method used solely on the Windows platform. DataSocket is NOT platform specific, for example a VB application running under Windows could communicate using DataSocket to a LabVIEW application running under MacOS. DataSocket provides a simplied API for users wishing to share information between two or more applications. The underlying protocol (TCP/IP, ActiveX, ftp and so on) is hidden from the programmer, making the development of such applications a simpler task.

>>>I guess I don't understand. If Datasocket is not ActiveX, why is there a "Wait on ActiveX Event.vi" in the Datasocket Read vi's?


>>If my OPC server has an activex control to access the server, would it be better to use this control or to use datasocket?


The answer to this question depends a number of areas.
1. How much documentation is provided with the ActiveX control?
2. How much experience/comfort do you have using ActiveX objects inside of LabVIEW?
3. How much functionality is exported via the ActiveX control?
4. Might you need to port your application to another OS in the future?
5. How stable is the ActiveX interface provided? Microsoft went through a process of changing their ActiveX model for their Office applications (Word, Excel and so on) such that you needed to recompile/make mods to your software if you upgraded from Word 97 to Word 2000.


The DataSocket programming approach is very straightforward. Simply open a connection with the OPC server using a suitable URL (opc://xxxxxxx/xxxx) and then read and write to the appropriate tags/data items that have been created/exposed by the OPC server. Once you have finished, simply close the DataSocket connection. You do not have to be aware of the underlying actions that are taking place to allow communication to happen. It could be that the OPC server is not even located on the same PC - regardless of the set up, the DataSocket approach is the same.

>>>In theory, I guess that's great, but why I was asking about using the ActiveX control instead of Datasocket is because, as NI has posted, Labview can handle only a certain number of Datasocket OPC connections. Given that, I was trying to figure if the ActiveX control might give better performance with more OPC connections.

[JeremyB]

>>My question was generated by the fact that some Datasocket vi's were modified by NI to remove the "wait on activex event.vi" because of poor performance. Why was this removed, then?
Isn't running LabView on a single thread defeating the purpose? Won't performance suffer?

Can't comment on why NI removed the VI - have you spoken to them yourselves about this matter. And stating that your application runs using multiple threads is not an automatic indicator that the performance is greater than that of a single thread application! There are a lot more variables involved - the only true indication is to perform performance benchmarks yourself on your target platform if you feel that you may be experiencing performance related problems.

>>>I guess I don't understand. If Datasocket is not ActiveX, why is there a "Wait on ActiveX Event.vi" in the Datasocket Read vi's?

NI has developed Datasocket as a platform independent API for communication between two or more software applications. Datasocket simplifies programming considerations where you would otherwise have had to use (for example) TCP/IP to pass information between two systems. You have to decouple ActiveX from your thought process as this is native to Windows. Yes the VIs that NI provide use ActiveX and the easiest way to share code on a Windows platform is to use either ActiveX or a DLL (back in your original question you make this point). This means that the DataSocket software running on a Windows platform can be accessed by a Visual Basic programmer, a C++ programmer or a LabVIEW programmer. NI simplify the programming experience further by producing application development library of specific functions/VI. What I mean by this is that for environments such as Visual Basic, you work directly with the DataSocket ActiveX control. In LabVIEW and LabWindows/CVI you have VIs and functions panels that provide hooks into the lower level DataSocket code. This is the reason that you see ActiveX VIs within the DataSocket VIs you are examining. If you had/have access to LabVIEW on other platforms (such as MacOS) you will appreciate that the subVIs contain OS-specific VIs to call the DataSocket software.

>>>In theory, I guess that's great, but why I was asking about using the ActiveX control instead of Datasocket is because, as NI has posted, Labview can handle only a certain number of Datasocket OPC connections. Given that, I was trying to figure if the ActiveX control might give better performance with more OPC connections."

The answer to your question is stated in my answer 3 "How much functionality is exported via the ActiveX control?". From what you are saying is that the ActiveX control has greater functionality over the DataSocket approach. If you need to use this extended number of OPC connections, then it goes without saying that the ActiveX control approach would be a better solution for you. Similarly, if you had a smaller application with perhaps 5-10 OPC connections, you may find that it would be easier to develop your LabVIEW application using the DataSocket API.

As with most programming decisions, there is often never a single "right" answer. The "right" answer is often dependent on your (or your customer's) requirements!

Jeremy

[sal]

Jeremy,

Thanks for your explanations. The pieces are coming together...

Sal