Accessing OPC/DDE Servers W/O LabVIEW DSC Module?

[Bryan]

Is it possible?

We're going to be developing a rather large application using multiple computers, all of which will have OPC servers running on them. Currently, we're using LabVIEW with the DSC module to access the OPC tags. DSC licenses are rather expensive, and cost is definitely a factor in our case.

Does anybody know if there is a way to access OPC Server objects/tag values in LabVIEW without purchasing the DSC module? An option we're keeping in the back of our minds is using the OPCDAAuto.dll and essentially creating our own little version of it, but it requires time (of which we don't have much) and a learning curve.

If anybody's done something like this, I would much appreciate a point in the right direction, example code or anything I can get my hands on.

Thank you much-ly!

[Yair]

I believe that you can use Datasocket to connect to OPC data, but as far as I know, this is highly unrecommended for anything more than a fairly small number of tags. You can search NI's site for quite a few posts about OPC.

Another option I saw recommended there was to use the OPC server from Kepware.

[Bryan]

I believe that you can use Datasocket to connect to OPC data, but as far as I know, this is highly unrecommended for anything more than a fairly small number of tags. You can search NI's site for quite a few posts about OPC.

Another option I saw recommended there was to use the OPC server from Kepware.

5652[/snapback]

We're going to be using quite a few tags I believe, so datasocket would be out.

I forgot to mention. We're using profibus cards from a vendor that supplies both DDE and OPC servers to use with their cards. Is the OPC server from Kepware more "friendly" to use with LabVIEW?

[Khalid]

Is the OPC server from Kepware more "friendly" to use with LabVIEW?

5655[/snapback]

Not sure how a friendlier OPC Server would help...? Because with DataSocket (and DSC) ruled out, I don't see any other way of making LabVIEW an OPC Client. Unless of course you plan on making your own OPC Client and calling it from within LabVIEW.

Is there inetrest enough for an OpenG "OPC VIs" project?

Regards,

-Khalid

[viSci]

What is wrong with using Datasocket for OPC? I use it all the time and it works great.

[JohnRH]

What is wrong with using Datasocket for OPC?  I use it all the time and it works great.

5660[/snapback]

I heard there are performance problems when accessing many (hundreds) of tags. Bryan's worst case is something like 250 tags on a single server computer. With 63 server computers and one or two client computers. Having to put the DSC engine on all 63 computers is what we are trying to avoid. (I only know this because Bryan and I are working on the same project)

I wonder if we could use datasocket on each of the server computers, to make the data available to the client computers in a different form (plain UDP or something)?

This would also allow us to put some intelligence into the server computers, which could minimize the traffic over the network to the client computer.

Hmmm...

[Yair]

I suggest you try posting to NI's forums. At least 2 regular users there (Unclebump and Donald) have some experience with these things and can probably help you.

[Michael Aivaliotis]

Ok, just set the record straight. OPC communication is just fine with Datasocket. I've done it and worked with it on about 200 tags.

Also, OPC servers are a dime a dozen. Pretty much any OPC server you can think of will work with LabVIEW. The job of the OPC server is to provide a constant communication path to the hardware. It is responsible for hardware communications and protocol management. So, the most important question for you in an OPC server is: Does it communicate with the hardware you are using? LabVIEW is ignorant to this.

OK, so the next question is: what's the deal with DSC module? The deal is that everytime you open a Datasocket tag connection to the OPC server, it opens up a new communication pipe between LabVIEW and the OPC server. 200 tags mean 200 connections. The DSC module opens up 1 sigle communication pipe to the OPC server regardless of how many tags you are reading. This can significantly speed up the update rate of your tags. This is not the only feature. DSC gives you automatic dataloging plus there are smarts like updating values only they're changed etc. One thing to note, Datasocket is free. You can easily try this theory right now (if you have the hardware).

I've worked with both and can comment more, however one important lesson I learned is that you should try to get the fastest IO pipe you can get. For example, if you have a choice between serial or ethernet, choose ethernet. Whatever's the fastest option with your hardware. The money spent is worth it for the response you will see and feel.

[Bryan]

Thanks for the detailed information Michael. That helps me understand it more.

To date, I think I've been using the DSC module waaaayyy below it's capabilities, but not having time to really get familiar with it has me using it in the way I've been able to initially get it to work.

Using DataSocket will probably be the least efficient way for us to do what we want, but like you said, will be the cheapest and require far less time to implement than other solutions I've been looking at.

[Karl Rony]

I have interfaced LabVIEW to OPC servers from Automation Direct (PLC) and Softing (Profibus-DP). The Automation Direct logic uses DataSockets. The Softing logic uses an OPC client toolkit from OPCWare (www.opcware.com).

My OPCWare solution is far superior to my DataSockets solution. The OPCWare solution is faster, can change links by loading an XML file, and I easily created a callback Vi that I use to update values on an indicator in another Vi.

[BChandler]

Not sure how a friendlier OPC Server would help...? Because with DataSocket (and DSC) ruled out, I don't see any other way of making LabVIEW an OPC Client.  Unless of course you plan on making your own OPC Client and calling it from within LabVIEW. 

Is there inetrest enough for an OpenG "OPC VIs" project? 

Regards,

-Khalid

5658[/snapback]

Good idea. I've used OpenG, very good stuff.

I have a related problem. I'm looking for a cheap (free)

OPC server to let me simulate the server for a device I don't have acess to.

I plan to use DataSockets to be the OPC Client and I have the spec. for the target OPC

server and need to write a Labview device driver.

But the customer does not want to ship the unit here and the vendor won't

send me a copy of the server s/w. I hate to write a bunch of untested code.

My only option now is to try something, send it to the customer for testing

and try again. He has limited Labview experience.

So a simple OPC Server written in Labview so I could customize it, would be nice.

But even an OpenG project would take too long. But it would be good to have.

Also can we write one without a copyright problem with NI's DSC?

-Bill

[Khalid]

I plan to use DataSockets to be the OPC Client and I have the spec. for the target OPC

server and need to write a Labview device driver.

5970[/snapback]

Hi Bill,

Will there be other clients commnicating with this device? I am just wondering, if it's only LabVIEW that will be communicating with this device, you can write the device driver for it in LabVIEW and use it as-is in the client portion of LabVIEW (without making it an OPC Server). Writing an OPC Server in LabVIEW is definitely more difficult than an OPC Client. And that too without proper documentation and device to test.

As for the OPC OpenG toolkit, I am not sure if it will be infringing upon DSC Copyrights. May be we should start a discussion for this on OpenG.

Regards,

-Khalid

[BChandler]

Hi Bill,

Will there be other clients commnicating with this device?  I am just wondering, if it's only LabVIEW that will be communicating with this device, you can write the device driver for it in LabVIEW and use it as-is in the client portion of LabVIEW (without making it an OPC Server).  Writing an OPC Server in LabVIEW is definitely more difficult than an OPC Client.  And that too without proper documentation and device to test.

As for the OPC OpenG toolkit, I am not sure if it will be infringing upon DSC Copyrights.  May be we should start a discussion for this on OpenG.

Regards,

-Khalid

5974[/snapback]

Khalid:

This was just an idea to help in me test the Client s/w. So Labview is the only client.

Probably not worth the trouble. I'm going with plan B, work by phone with the customer in front of the device.

Once I have a single DataSockets data point working I should be able to guess at the rest.

But thanx for the reply anyway.

I've just started looking around this forum. Lots of cool stuff! wish I'd found it sooner.

-Bill