03-18-2010 09:48 PM
Does the "Flush Shared Variable Data.vi" flush one shared varialbe or ALL deployed variables? The only input is an error cluster, so I assume it flushes all of them. The description says: "Flushes the buffer of a network-published shared variable immediately." Note buffer is singular.
Bill
03-18-2010 10:46 PM
What does context help say?
Are you sure that VI is doing what you want it to do?
03-18-2010 11:27 PM
Context help is as stated above for description.
And no, I'm not sure it's doing what I want, hence my question...
03-19-2010 12:04 AM - edited 03-19-2010 12:09 AM
Well, there is more to it than that.
"Flushes the buffer of a network-published shared variable immediately. LabVIEW uses an 8 kilobyte buffer for all shared variable values, and LabVIEW automatically flushes the 8 kilobyte buffer either when the buffer fills up or after 10 ms have passed. If you write less than 8 kilobytes of data, it can take up to 10 milliseconds for LabVIEW to send that data over the network. You can use the Flush Shared Variable Data VI to flush the buffer immediately and eliminate this delay."
When I read your question, I interpreted you wanted to flush out a buffered shared variable, much like flushing out a queue. A buffered shared variable that maintains all the writes to it in order, to be read in order. And you want to clear it out to only get the last piece of data.
Reading the help on it, it sounds like it is flushing out the network communicaitons process, the complicated publisher/subscriber protocol that shared variables use to transfer their data efficiently to other network nodes. So instead of writing a handful of bytes very frequently and clogging up the network, the communication protocol bunches together the data to send more data less frequently. So this low level VI basically speeds up the transfer of data in the event you have a small number of bytes, but you want to get that data transferred right away.
I think this VI is going to only be useful to someone who has really high performance demands for their data communication and really understands what it happening behind the scenes. And if their application really demands that kind of performance, they are probably going to write their own TCP/IP protocol communications rather than relying on shared variables.
I think if you want to flush out the data that is buffered in a network shared variable, the best bet would be to read the shared variable continuously in a loop until you detect the timestamp coming out of the variable has not changed between two reads.
03-19-2010 12:15 AM - edited 03-19-2010 12:17 AM
You're right, I have high performance demands.
Here's what I'm doing:
UI has 2D array bound to a shared variable. Part of the array is populated by VI 1, the other part by VI 2. These 2 VIs are executed one right after the other (always in the same order) in a background thread that is executing up to a 60msec rate.
VI 1 writes its data to the shared variable, e.g, rows 1-8, then exits. VI 2 READS the variable, writes his part of the data, e.g, rows 9-10, then writes the entire 2D array back to the shared variable. The data then is displayed in the UI indicator.
Problem is that the data written by VI 1 doesn't have time to make it to the SVE and get published before the read in VI 2.
So my hope was to use the FLUSH to get it back to VI 2 quicker.
I mitigated this for one set of data by using a queue which is obviously much faster than SVE. VI 1 writes his data to the queue. VI 2 reads the queue, appends his data and writes it to shared variable. Wah Lah...works great.
I was trying to use the FLUSH as an alternative because I have six or seven sets of data and wasn't keen on creating that many queues, particularly when the data types aren't the same (precluding me from creating an array of queue references to manage them easier). Lastly, I haven't tried the FLUSH yet, hoping to get a definitive answer before coding it.
Oh, I do have one other alternative....split the array into 2 pieces and use another bound shared variable, but it's more complicated then that and I can't go into it here.
Bill
12-06-2011 01:54 PM
I realize this is a very old post, but it was one of the first results that came up on Google when I searched for my answer to this same question. I found a guide on the NI website that had the following information.
"However, because as was noted above, all shared variables connecting one machine to one other machine share the same transmit buffer, by calling Flush, you are going to affect many of the shared variables on your system. If you have other variables that depend on high throughput, you will adversely affect them by calling Flush.vi"
I found the information in this article "http://zone.ni.com/devzone/cda/tut/p/id/4679". Just in case someone else is looking for the same information.