Datasocket and Shared Variables

[Garvacious]

I am curious if there is any advantage to using Datasocket to read/write shared variables (as opposed to a direct read/write).  I'm specifically talking networked shared variables here.

Is there any speed advantage to accessing shared variables thru the Datasocket functions?  Since both a direct read/write and a Datasocket PSP read/write talk to the same variable engine I assume they are equally efficient but I'm looking for confirmation here.  I've seen benchmarks for shared variable performance but none of them use DS/PSP to access the variables.

Normally I would not even think of using Datasocket to access shared var's but where I currently work we have a large app that does this and it works great.  I suspect that this functionality only exists in LV8.x for backward compatibility and non-Windows OS compatibility and is not really meant to be used for new, Windows-based apps?   Am I off base on this?

I am working in LV 8.5, BTW.....

[Jared_B]

Garvacious,

There is technically a speed performance advantage with accessing Shared Variables via Data Socket when you start to get above 20-30 variables.  However, there will be a large hit in CPU usage.  Now, if your shared variables are working with an OPC Server, then the Shared Variable has the speed advantage over Data Socket.

And you are correct regarding Data Sockets, they are able to be used on Windows, Mac OS, as well as Linux, where the hosting of Shared Variables is just on Windows.  You can still use Data Sockets on newer apps just fine, but the Shared Variables just make life so much easier!

[Garvacious]

Thanks Jared-   since I posted that question I noticed there seems to be a few more advantages to Datasocket actually:

1.  Synchronization (sort of)-  you can use DS Read to wait on new data, seems with a shared variable read it will always read as fast as you clock the read loop, even if there is "stale" data in the variable.

2.  You can feed a path into the DS Read and not worry when the read VI moves to another computer on the network.  It seems to be a big pain to change this with a shared variable read (alias files, binding, etc.).  I am not binding directly to front panel objects so it would be nice to have an easy way to direct a shared variable read to map to a certain machine always without a lot of extra work.  It just seems like DS Read gets around this easily.

Am I wrong here?  Can these same things be accomplished with a shared var. read and I have just not figured out how to do it yet?

[Ipshita_C]

Hi Garvacoius,

1. You are definitely right on this.

2. This depends on how your variables are set up. If your variables are bound to source and the source is set up on an I/O server your other machine has to be able to access this I/O server for the shared variable to work.

Hope this helps.

Ipshita C.

[Vaibhav]

A bit old thread, but the information (rather "confirmations") I needed are here. Hence gave kudos above. Just using this space to further clarify things.

I have always used Datasocket, and recently a functionality, as I anticipated it, found to be non-existent, made me use DS with Shared Variables. And have used PSP URLs to pass to DS (as this allows multiple writers at the same time, as contrary to DSTP URLs referring to DS items). It could at least help me overcome one issue, but I still won't use SVs. 

Because, as it was good to know that DS has some good points over SV, I am also afraid of "data overwrite" in SV before they are actually read at a Client application. The DS works like a queue (with networking, but not allowing two or more writers at the same time on the same item), so multiple values being written to the same item doesn't make the old items lost. Right? I still get to read each item one by one at a client machine, right?

[jareds]

Hi Vaibhav,

I believe that you are correct about DataSockets acting like queues.  They should have a buffer that will allow you to ensure that no items get lost.  However, shared variables can have buffers as well.

[Vaibhav]

Hi Jared,

Thanks for the reply.

If Shared Variables can have buffers as well, as I have also seen in properties and other threads, why don't they maintain the old values? Where do I make those specific changes or perhaps, how do I read those older values in order to take advantage of the buffer. Currently reading some articles on this, but not sure if they will have clear answers on this. 

[Vaibhav]

Ok, just finished reading a KB article "Using the LabVIEW Shared Variables" - the most comprehensive article on LV SV I have read so far. Many doubts cleared.

But, this makes me curious why my "String Array" Network Published Shared Variables with buffers enabled (with value of 10) did not have all the updated values at the readers. 

As in the article, one thing also confuses me - if my shared variable is not real-time FIFO, will multiple write nodes not overwrite the single buffer queue (unlike in the case shown in Figure 14 in the above article)?

And another thing, how do I measure "bytes" for buffer capacity for String Array type of the shared variable. In Double type, they have number of elements, but in String Array type, there is number of bytes which is difficult to measure.

Thanks for your attention. 

[jareds]

Vaibhav,

I believe multiple write nodes will not overwrite the single buffer.  This happens in RT to maintain determinism, since blocking on a write wouldn't be deterministic.

The number of bytes simply refers to the total number of characters that are in the buffer.  You should base this on the average length of each string in the array you'll be writing multiplied by the number of strings per array and the number of arrays you would like to have in the buffer.

[Vaibhav]

Hello Jared,

Thank you for the reply with clarification. 

Based on your comment, I changed the buffer parameters and also tried the programs with two different data types, previously StringArray and now String.

In the attached LV8.6 project, you have all the programs, and shared variable library to review my tests. 

There are two sets of two files - each set has a Write Shared Variable and Read Shared Variable file. One set is for StringArray type Shared Variable (named StrArr in the library), and the other set is for String type Shared Variable (named Str in the library).

String Array example:

MultipleDS-Write-SharedV-StrArr.vi / MultipleDS-Read-SharedV-StrArr.vi

In my String Array shared variable, I use only 4 element array, each having 4 character strings - meaning 16 bytes per String Array data. I have two loops in the write file, writing to the same variable, an array of 4 strings, each loop continues until the loop index is >0. This means, sometimes, depending on the processor speed, the variable will be written 3 times or 4 times (the variable could have a new value before the loop condition is checked).

So this means, if I have buffer of 100 bytes (16*4=64<100), it's enough for 4 such arrays (of 4 elements, each element with 4 characters) could be buffered to have sufficient time at the client (Read) program to read them. 
I am putting 2048 bytes in buffer, which is much more than sufficient in my case. 

The writer loops run with 200 ms to wait for each iteration. The reader loop runs with 100 ms in DS timeout and 100 ms in wait timer. This gives results without any loss. However, if I run the reader loop with 1000 ms to wait for each iteration, the data is lost. The buffer is not maintained for 2048 bytes.

In the read program, just to make sure if all data is read or not, I am showing data in two different string indicators, showing data of each loop.

String example:

MultipleDS-Write-SharedV-Str.vi / MultipleDS-Read-SharedV-Str.vi 

The String Array shared variable didn't show values in the Distributed System Manager. Hence, I created another simple variable with String datatype.

The writer program writes strings of 4 characters, one-by-one, in two loops. Meaning, total 8 strings of 4 characters each are written in the "Str" Shared variable. 

The reader program, however, doesn't always display all the 8 strings. Although the wait timer is not high (slow) it still misses some data usually. Data is overwritten even before the buffer is filled (in buffer, I have defined 50 strings with 4 elements in each).

In both of the Read programs, I read using datasocket. I think thought datasocket has more ability to buffer. Earlier I had "BufferedRead" in DataSocket, which I have changed to just Read, because BufferedRead didn't give any special buffer advantage in the Shared Variable reading.

---- This is an update on the issue. 

Ok, just while typing the last paragraph above, regarding datasocket, something clicked in my mind, and I changed the DataSocket functions to simple Shared variables (completely eliminating datasocket functions) in the read programs as well. And bingo, the buffer works as expected, even if I have reading loops very very slow, there is no data loss in any of the program sets. 

The two changed Read programs are also included in the attached project - MultipleSV-Read-SharedV-Str.vi and MultipleSV-Read-SharedV-StrArr.vi

So this means, I can completely eliminate DataSockets (not even using PSP URLs in DataSocket Open/Read functions) from my programs. 

One question here, what will be an advantage of this (or any side effects that I should be keeping in mind)?