So, what is the deal with Datasocket and OPC?

[tst]

I want to connect to an OPC server and read and write a large number of tags (hundreds or thousands).
Using Datasocket has three distinct advantages over using the DSC module:

1. No expensive run-time license.
2. No complicated setup of having to install whatever needs to be installed, run the tag engine, configure all the tags, etc.
3. Can build dynamic tag addresses, unlike the DSC module where you have to configure the tags in the tag engine.

The main problem is that NI says that "If you are going to have more than 30 I/O points, you will sacrifice efficiency using data sockets. At 30 I/O points, you should consider using LabVIEW DSC and the Tag Engine".

However, it doesn't mention what the efficiency loss is and that is what I want to know. Is it speed? Will it take too long to read them? Is it CPU consumption? Memory consumption?

My quick test has shown that trying to read 1000 tags using DS is producing a lot of errors in the beginning, but that they are dropping over time. Is this what's considered an efficiency loss? 
I haven't tried this with the DSC module (let's see you define 1000 tags there  ).

I would really rather use DS for the points mentioned above, but if anyone can satisfactorily explain why it's not good for I will unhappily switch and hope I can find a way to automate the generation of a large number of tags.

BTW, all this is on LV 7.0 and the method used was the Open\Read\Close method which is shown in the DS OPC examples (the ones using the ActiveX object).

[Ben]

NI used to have a white paper that had benchmarks.

I have seen the benifits myself (using LV 6.1  DSC).

DSC can monitor the tags much more efficiently that using datasockets.

In my case another developer had developed an app that monitored 30 tags to prove that we could do the job. After that is was turned over to me to scale it up. With 30 tags the demand on the CPU was above 70% (probably  a sub 400MHz machine at the time).

I converted all of the datasocket reads to DSC tag reads and was able to monitor 3000*+ tags with less that 30% CPU usage.

Ben

BTW: You can export tags to a tab delimited file, hack same, import hacked file and re-start DSC to avoid having to add 3000 tags by hand.

* The tags were all registers inside a collection of PLC with ethernet interfaces.

[tst]

Thanks, Ben.

So far I have only had a chance to do one single quick test and I didn't check CPU usage. I will have to get back to this next week and test more. In any case, I'll be sure to bench DS with the appropriate number of tags.

[tst]

Also, I will have to see about that export-modify-import thing. This is what I'm doing currently for the OPC server itself, so I should also be able to manage it for the tag engine, but I just really want to avoid the hassle of having to deal with it. Using DSC just seems like overkill for this application, because even though it can get to reading and writing a lot of tags, it would not need any of the other DSC features.

[unclebump]

The tag engine also lets you assign them to groups. Then you can read back all of the tags in a group with a single name. The tag engine includes Citadel to store historical data.. You can flatten clusters into binary strings and store them in memory tags and Citadel.

Excel is your friend when it comes to making/modifying the tags. Just remember to put 0001, 0002, .... ,xxxx at the end for consecutive addresses. It makes reading tags with a group name come out in the proper order. Also remember to import into an empty .scf file, otherwise you end up with duplicates and you have to use the trashcan to remove them.

If you have a ton of items in the OPC server program, you can use the tag import wizard to create all of the tags. Then export the tagfile, assign group names and import again.

[Ben]

Uncle wrote "You can flatten clusters into binary strings and store them in memory tags and Citadel."

Light bulb goes on!

This solves a problem I had always had with legacy versions of DSC (which I still support, and no I did not write them  ) when trying to cordinate event across multiple tags based on time!

Thank you!

Ben

[unclebump]

You can also do an array of plc registers with a single opc/dsc string tag if all of the values are greater than zero. A zero byte(Nul) terminates the string. If you are going to do stripcharting from plc registers, I would add checksum values for each 100 plc registers. Then labview can recalculate the checksums to guarantee the tags have been updated.

[tst]

Some more details about the system.

Basically, there will be an unknown number of PLCs (can change over time) which will all have the same program. The PLCs will be connected to a piece of hardware which will read the configured registers from them and send it to a server, from which it will be extracted using a local OPC server, from which I will get the values. The whole process works in reverse for sending, so essentially, I only see the local OPC server.

There may be multiple instances of the system, which will be different from each other.

I won't be needing any of the historical logging, just reading and writing tags. The speed will not be a major issue. I'm planning on writing a relatively small amount of tags automatically every X minutes and writing the other tags will only occur on user request. The normal automatic reading will also only happen on a relatively small number of tags and at a rate of minutes. Those are the main reasons why I'm thinking DS could do this.

In any case, I will probably write a small application which will generate the CSV (or TSV) files, so I don't have to manually use Excel whenever I have new PLCs.

[unclebump]

Ben,

Attached is my latest DSC application. I'm still using 7.0 for this. Not a very large application, but it saved me using another 800-1000 plc registers to hold information. Following the type def thread, I should make some changes to my programming methods.

[Ben]

You guys are a God send!

I just finsished up a week-end adventure (16 hours) where I utilized the concept you posted to handshake a dialog from a cFP to a PDA.

If it were not for a corrupted VI (Eventually found out the main while loop would not even loop and update a indicator from the imteration terminal), I would have been out of there in five hours (after copmpletely re-writng the interface*).

SO thank you tst for starting this thread at the perfect time and,

YOU Uncle for giving a nugget I have been searching for quite some time!

Ben

* Try to do that in another laguage.