LabVIEW
read buffered network published shared variable
Solved!
I added a "plus 100" to the third For Loop:
...and got this result with the second run and each run after:
LabBEAN wrote:
In the past "warm-up" reads have been necessary, but this seems to persist into subsequent write-read calls. I ran the following code to put elements 0,1,2,3,4 into the buffer, read them out, and then repeat:
The results were 4,0,1,2,3 both times:
Is this a bug, or am I missing something?
I don't think this is a bug because the last value written the Shared Variable (when its buffer is empty) is 4, and since the Shared Variable always retains its last written value when we add additional values to the buffer they line up after 4. So in each case I would expect 4 to be the first value that is read out. Let me know if I am misinterpreting what you are getting at.
LabBEAN wrote:
Also, I edited your code to include the DataSocket API since you mentioned that DataSocket could be used to access client side buffering functionality:
When I ran it, I got these results:
Why am I not seeing buffered data coming from the DataSocket Read(s)?
Appreciate your input...
Jason
At first I though the DataSocket behavior was due to the face the DS Open was configured for ReadWrite instead of BufferedReadWrite. But even in the buffered case I received the same result. I will look into this for you.
Cheers,
LabBEAN wrote:I added a "plus 100" to the third For Loop:
...and got this result with the second run and each run after:
I think the output in this case is expected "the second run and each run after" following the same logic in my previous post.
Cheers,
As promised I followed up to why Datasocket didn't seem to be behavior as it should in my previous post.
In this example the Datasocket Read will read all of the items placed in the buffer by the datasocket write. This is done by explicitely setting the size of the client side buffer using the BufferMaxPackets property.
Cheers,
BLAQmx wrote:
In this example the Datasocket Read will read all of the items placed in the buffer by the datasocket write. This is done by explicitely setting the size of the client side buffer using the BufferMaxPackets property.
DataSocket appears to be functioning properly with the addition of a Clear Buffer read at the beginning. While odd that the Clear Buffer read is necessary, I understand that, for now (LV 2009 and before), this is intended.
The new DataSocket code:
Produced the expected result:
However, we still have unexplained behavior out of the equivalent code using the Shared Variable Node:
I'm not seeing 0,1,2,3,4 coming from the first read loop (like with DataSocket above). I'm also not seeing 100,101,102,103,104 coming from the second read loop (like with DataSocket above):
Can you explain the difference between the DataSocket API and Shared Variable Node in this case? Why the warnings? I'm attaching my files in case others want to try this (they would need to deploy the library from the LabVIEW project).
LabBEAN,
This is a very interesting point you have brought up and its worth noting that if you are using Shared Variable nodes previous to LabVIEW 2009 the behavior of the VI would be the same as your Datasocket example.
In 2009 the LV node changed so that instead of becoming initialized on this first call of the node the node begins initilizing in the back ground when the VI is run even before we access the node. That being said it doesn't explain the behavior of items not being removed from the buffer or the warning you are receiving.
The warning (-1950678981 LabVIEW: (Hex 0x8BBB003B) The shared variable client-side read buffer overflowed.) is because you are attempting to add more items to the network buffer than is allowed. If you increase your network buffer size (to 50 for example) you will not receive the warning. But this begs the question, "why are we overflowing the buffer if the buffer should be empty after reading the variable 5 times?"
The reason for this is the variable buffer will not actually empty until all of the client peers have left memory. In the VI you created all peers remain in memory during the run of the VI because they are all in the same VI and share the same buffer. Therefore after reading from the SV 5 times we do not clear the buffer because their are still peers on the block diagram that will access the buffer, and since we are writing to the SV before reading again we will add additional items to the buffer.
In this example the SV has a network buffer of 50.
As you can see the second set of reads iterate 15 times - reading out the first 11 elements in the first 11 reads and the last element for the remaining 4 reads. The value 104 is read out 4 times because the SV will always retain its last written value. Once this buffer is "empty" (all peers leave memory) this value will always become the first element in the buffer.
If I were to split the first two For Loops in this example into one VI and the second two For Loop into another VI and ran the first VI and then the second VI the output from the variables would more closely resemble the behavior in the Datasocket example, but if these two VIs were subVIs of the same calling VI they would behavior exactly as they do in my example above.
I think some of the weird things we can force Shared Variables to do epitomizes the phrase "Its not a bug. Its a feature!"
Cheers,
More buffer questions...
When accessing a buffered shared variable via DataSocket, is the BufferMaxPackets property node always necessary after an Open?:
What happens when the shared variable is configured to have a different number of elements? Can you elaborate on what's happening with the two buffers (one configured with DataSocket property node and the other configured when creating the Shared Variable)?
How and when do we use "Buffer Maximum Bytes" (e.g. with Variant Shared Variables only?)?
In the interest of space, continued in next post...
