Use of Shared Variables for data transfer from a RT traget to a desktop application

[tillb]

Hi,

I want to adopt the shared variables to share data in an existing distributed application comparable with the T3 Benchmark configuration in this document:
[1] http://zone.ni.com/devzone/conceptd.nsf/webmain/5B4C3CC1B2AD10BA862570F2007569EF

The current implementation uses a well tuned solution with RT FIFOs and TCP/IP communication with a desktop-PC which monitors and stores the data.
The desktop application runs with a much slower execution rate than the TCL. So the TCP/IP packets are used to buffer the data with a package size dependent on the data send rate.

To use the shared variables instead of this RT FIFO + TCP/IP implementation I need to read the shared vairable buffer at once each time the desktop application reads the shared variable.

But according to this quotation from [1]:
"With buffering, you can account for temporary fluctuations between read/write rates of a variable. Readers that occasionally read a variable slower than the writer can miss some updates."
this seems to be impossible. Am I right?

Are there any suggestions to circumvent this problem? Or are shared variables not made to share data between unsynchronized processes without data loss?


Regards Till

[Andre_Saller]

Shared Variables can buffer your data as well, so instead of buffering your data in the TCP/IP connection, your data can be buffered in the shared variable.

[tillb]

Of course Shared Variables can buffer data. But not in the way it is needed to exchange data without data loss between unsynchronized programs. With the Shared Variables I have no controll of the buffer. But I need to access all values in the buffer at once or leastwise get notified when data in the buffer is lost.

Is there a workaround or did I miss something in the concept of shared variables?

[bradh]

I have this same question (and have found multiple threads that end at this same point).  All the threads say you can use shared variables with buffering for asynch communication - but none tell you how to read the whole buffer on the slower (i.e. PC) process.

If I have a high priority process writing to a shared variable on a RT PXI chasis at say 5ms rate... I have a PC reading this buffer running at 100ms loop, how do I read the whole buffer? 

The shared variable FIFO only gives you the oldest sample.  For example if I want to plot the samples on a chart; I don't want the PC to update the chart every 5ms; I want it to plot the 100ms worth of buffer at each iteration.   

[Andre_Saller]

You will have to read the shared variable multiple times from the same process, to get "older" values. You could use a for loop inside your timed loop for that.

I made a small example (for windows), and attached it.

[bradh]

It looks as if you are using LV8.5, I am using 8.2.1 unfortunatly.  So I can not view your VI.  could you jpeg it?

With regards to the for loop, how do you know how many interations to run?  As far as I know, there is no way to get the buffersize of the Global Variable FIFO?  For that matter, I can not even use a while loop that runs till it is empty?

What I would like to do is have my RT controller collect at a deterministic fast rate dump into a Global FIFO buffer and the host PC running in a slower loop empty and plot the buffer at a slower rate.

[Andre_Saller]

You can use the error-cluster to detect the end of your queue. The erroroutput of the shared variable will return a -2220 Warning, if it reads a value it has read already before. I attached a modified example and saved it for 8.2 I hope you can open it.

[bradh]

Andre,

Thanks - that worked.  I had to make 1 small change, in 8.2 I needed to use error code 180121602. 

I also needed to run the check on the error to a case structure.  If the error is false I append my waveform (from the network variable) to the waveform in a shift register inside the loop.  I had some odd things happeing otherwise.

For the NI folks - It would be nice if there was some easier way to just say "give me everything currently in the buffer".

Regards,

Brad