differences in datasocket update rates

[stephen s]

I am seeing a major difference in the update rate between two methods of updating the values from an OPC server via datasockets. The first method, subscribing to a value, is relatively fast, but appears to be very difficult to program with (for multiple channels). The second method, reading a datasocket, is much slower, but easier to program with (FOR loops for multiple sockets and such).

I ahve attached a VI to show what I mean. I am seeing a major difference in the time for the two frames to operate. Frame A completes in an average of ~ 0 ms, and frame B often takes much more, often on the order of 50 - 100ms, and in extreme cases closer to 600ms.

What is the difference? What am I doing wrong? And most importantly,
I want to write a routine to flexibly update many (~100) different datasockets, how can I do this correctly and efficiently?

For the record, I am using LabVIEW PDS 7.0 on Windows 2000.
I also have recently installed the Datalogging and Supervisory Control Module, but am not yet totally familiar with it.
The hardware is a Beckhoff system over Profibus. The OPC server is Beckhoff TwinCAT v2.9.0 (Build 940)

[Ben]

"how can I do this correctly and efficiently?"

Use LV DSC!

There used to be a white paper discussing DSC vs datasockets. Datasockets were OK up to 100. After that DSC blew away datasocket performance.

IN DSC you can browse to a URL that is similar to what you use in datasockets to define a DSC tag. Each tag can then be configured as to its datatype, logging, update interval, deaband, alarms, etc.

Once a tag is configured and the DSC tag engine is running, it will "flexibly update many (~100) different datasockets [tags],...correctly and efficiently".

I have done thousands!

Ben

[Evan]

The difference in time is a very subtle one that comes from your test. When you are using front panel datasocket, the numeric connects to the server then it stats polling the server for data.

However, and this is the important part, LabVIEW does not wait for the connection to be made before it reads the value from the control. So your test is comparing the time it takes LabVIEW to get a value from a terminal versus pulling a value off the datasocket server. As expected it takes LabVIEW 0 ms to read from a control terminal, in this case the front panel datasocket is totally unrelated. I am attaching your VI slightly modified that shows 1 method to see how long it takes the Numeric to connect to the server. There are a lot of different ways to measure that
time, and I am not sure which is the most accurate. Another method would be to see when the value changes from the initial value.

So the answer to why the times are so difference is the test. Now to answer the best way to have flexible code: I would suggest the block diagram method, because of how easy it is to increase the tag count. For example you can build up arrays of the data socket URLs or Connection IDs. Therefore you can use loops etc to build up IDs, and then you can index through them to get to the data. If you where using front panel datasocket you have to place a new control and enter in its URL etc. In addition front panel datasocket polls the server, whereas block diagram Datasocket you control when

[stephen s]

After a few hours learning and starting to setup DSC, and very basic tests, I can already see an improvement. I expect to have more questions later, but DSC is an improvement over the method I was using (i.e. the methods in the vi previously attached).

Thanks

[m_min]

 Dear Ben,

I have used vi with datasocket (~50) located in RT module. Then Datasocket server and main VI located on PC. It took like 3 min to finish updating all datasocket values. I also use DSC but it is mainly used for interfacing with PLC via lookout server to get (~100) data. 

 It's an old project and done when i first using labview. 😄 .. I guess i should go back and change all DS connections to DSC tags.

min