Can i create an OPC Server with Labview?

[IDILIO]

Can i create an OPC Server with Labview?

(note that is a server, and not the client)

[mfitzsimons]

My understanding is No, you need an OPC server running and LabVIEW can talk to it.  You can use NI's OPC Server, Lookout's OPC Server, DSC comes with an OPC Server, or there is a free or low cost alternative out there.  See what the others say but I believe my ansers are correct.

Message Edited by mfitzsimons on 10-23-2006 11:06 AM

[IDILIO]

ok, but my intention is to create my own OPC Server...

: (

(if labview isn't an option just with Visual C++, and isn't so easy)

[mfitzsimons]

Sorry, my bad!  I do not have any idea how complicated it would be to make an OPC Server because I am not sure what happens under the hood.  I would also say that unless this is a research project or you have a specific need, I would not try to make my own.  I believe it is complicated and a well established protocol that you can find for free or at a small cost. 

If I were to try to make an OPC server than my first choice would be to use LabVIEW.

[IDILIO]

See this Scenery:   
   
If I was the manufacturer of a engine, i need doing the reading of several sensors and publish them  in an OPC Server so that when i sell the engine, the customers easily  can obtain the data through an any standard OPC client.

Somebody has to do the OPC Server, so that later the customers can use and dispose of the simple that is.

There is no option to use a comercial OPC Server, because i need to build always my own diferent structure of node/itens.

[mfitzsimons]

Good Luck!  I think it will be rewarding when it is done but sounds like it will be a ton of work.  Anyone with OPC Server experience out there and want to chime in?

[cosmin]

the variable engine, that labview (or device drivers installer) ships with, is an OPC 2.0 compliat opc server.

cosmin

[IDILIO]

The SVE (Shared Variable Engine) is a unwind way to do it.

It would be a very bad practice of programming, for besides don't see as a viable and pacific solution  for the end user.

Maybe it could be good just for testing purposes.

Don't forget that the SVE is always running, and you need some process to update the "variables", and you don't have a way to launch this just when the client access the server (This is the way that an OPC Server should work).

[Soroush]

SVE is an OPC server, but only on Windows platforms. You may see it by yourself, using any OPC client and you'll notice that "National Instruments Variable Engine" is listed among OPC servers installed on your PC.

But this will not do if you are trying to communicate with an external device.

All OPC supported devices, will be shipped with an OPC server application commonly installed as a service. This is the manufacturer who builds this server or someone who knows about the low level protocols of communicating with that device, mostly prototypes of some DLL files.

[cosmin]

Hi,

take it from me, in labview the SVE is the best practice to do an opc server. The comercial opc toolkits are ment to be used in C/C++ or VB, so if you are doing a professional app, to use those toolkits in labview needs extensive tests and you can expose yourself to subtles bugs. I once use some toolkits to create an opc client (to connect to an A/E opc server, the datasocket does not support connection to A/E items) and is still working ok (after 2 years), but I've spent twice the normal time on testing.

The way tagsrv can be started (remotely or not) is stated in dcom configuration, as is the case for every opc server. Is allways running as it suppose to do!

From the client point of view, it does not matter how the opc server was created, only it's interface, this is the advantage of opc comunication.

cosmin