read buffered network published shared variable

[christian_w]

I use a buffered network published shared variable to write data to from a RT target and read the buffered data by the Host application.

I monitored a different behaviour regarding reading the buffered data using the Read Variable Function vs. read the Shared Variable Node.

There's no problem using the read shared variable node but using the read variable function results in loss of data, like unbuffered access. I can only read some of my data values.

I see no difference regarding the buffered access in the LV2009 help.

    versus           

Any help is appreciated

Christian

[MarkBlack · Accepted solution]

Hi Christian,

The behavior you are describing is due to the fact client side PSP buffering was not implemented for the Shared Variable API in LabVIEW 2009.  This was a design decision, but we hope to eventually include this functionality in a future release of LabVIEW.  This bug here as you pointed out is the lack of documentation for this.  Corrective Action Request # 202159 has been filed for this issue.  

Let me know if you need help working around this issue.  

Cheers, 

[christian_w]

Hi Mark,

thanks for your reply. In fact this issue was my workaround for another problem regarding name resolution of shared variables used from GAC registered LV interop assemblies.

I had to GAC register a LV interop assembly build. By doing that the assembly lost connection to the *.aliases file, because the assembly will be registered ( copied to the GAC folder ) without it's required *.aliases file. The missing *.aliases file results in wrong name resolution due to the use of a cached system alias (Warning -1950678971). If I had a wish it would be a cached "localhost" instead of an IP address  as the used cached system alias. This would solve my problem because I use a local SVE.

As a workaround I thought I could use the full resolved shared var name that is used by the shared variable functions and run into the buffering problem.

I'll now have to check if I can put the aliases file manually to the corresponding GAC folder.

Please let me know if you see a better solution.

Thanks again and best regards

Christian

[viScience]

What!!!  You mean that I cannot use a API based NSV on a RT target to function as a buffered message queue?

Can I still use the Datasocket API and preserve buffering?

[MarkBlack]

---

sachsm wrote:

What!!!  You mean that I cannot use a API based NSV on a RT target to function as a buffered message queue?

Can I still use the Datasocket API and preserve buffering?

---

Yes, you can still you DataSocket to perform buffered reads.  Christian, this might also be a solution for you since it will allow you to use a G API instead of the SV Node.

 

Cheers,  

[reddog]

If you right click on the Variable Node, you should be able to change the access type from absolute to machine relative.  It seems like this may also solve your problem if you're always trying to access variables deployed to the local host.  In machine relative mode, the absence of the .aliases file shouldn't be an issue.

[christian_w]

Many thanks to the Proven Veterans BLAQmx and reddog !

The target relative mode of the shared variable node solved my problem. The *.aliases file is no longer needed.

Christian

[LabBEAN]

The aforementioned behavior is documented in this KB:

Read Variable VI Only Returns Last Value Written to Shared Variable
http://digital.ni.com/public.nsf/allkb/0FF258D48A6B91C9862576AA004DDE3E

Someone should probably update the KB to include DataSocket as a workaround.

---

BLAQmx said:

client side PSP buffering was not implemented for the Shared Variable API in LabVIEW 2009

---

Mark-

Are there any caveats for "Write Variable" in the new API?  And... any plans to add a timeout like DataSocket has?

Thanks,
Jason

[MarkBlack]

---

LabBEAN wrote:

Are there any caveats for "Write Variable" in the new API? 

---

 The write performs more as you would expect.  In this case.

 

 

 

The output array from the Shared Variable node is as follows:

  4,0,1,2,3

The reason the first value is 4 is because this was the value of the Shared Variable before I ran my test and therefore is the first value in the network buffer.  The rest of the values were the ones added to the network buffer in the first For loop.  If I were to run out the second For loop for 10 iterations instead of 5 the output would look like this:

  4,0,1,2,3,4,4,4,4,4

---

LabBEAN wrote:

And... any plans to add a timeout like DataSocket has?

---

 There are certainly plans, but I cannot say if this will or will not be there in a future release of LabVIEW.  

[LabBEAN]

---

BLAQmx wrote:

If I were to run out the second For loop for 10 iterations instead of 5 the output would look like this:

  4,0,1,2,3,4,4,4,4,4

---

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?

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