Storage VI blocking on front panel interaction

[Matt_W1]

For some reason that I can't figure out, the "write data" storage vi (and perhaps others) will block during

front panel interactions. For instance clicking on a ring button will block until you select something.

The button doesn't have to be on the same VI either. Also editing a separate VI, when you right click

and start looking for the right function in block mode or widget (I forget the labview term) in the Front Panel, 

will block the write.

The problem with this is that my main program is saving data from a ring buffer, so if someone takes

too long making a selection, I've lost data. I attached a VI that can demonstrate the bug

(at least on what I can try it on). I've gotten the attached VI to work with labview 8.0 and labview 8.0.1

[Travis_M.]

Hello,

Thank you for posting this well written description and great small example which reproduces the problem!  This seems to be only occurring with the write data like you mention.  I’m not exactly sure the cause, but I filed a bug-report on it (3ZNC2Q3A), so we can investigate here.  I’m betting it has something to do with user interface interactions between the controls and the write measurement file VI, as components from each could run in the UI thread and block each other.  Unfortunately, I don’t see any immediate workaround without having to change a few things up with your program structure.  For example, instead of a ring, you could just have one or two checkboxes for the options and see which the user has pressed.  Because the write file VI is the only one that is blocked, you could conceivably separate your data acquisition thread and your file IO thread (many times it’s a good idea anyway).  Using the Queue datatype, you could add all the data to the queue in the non-writing loop, and write to file in the separate file IO loop.  If the write to file blocks the data will continue to queue and no data will be lost.  This is known as a producer/consumer VI design pattern.  Your consumer would be the file IO portion of your code.  Check out the tutorial of this structure here.

Are these alternatives acceptable?  Unfortunately, with the way the write VI interacts with the user interface thread I don’t see any way to avoid this problem.  I apologize for any problems that have occurred as a result of this behavior.

[Matt_W1]

I ended up seperating the DAQ and IO with a queue. Which will work just as long as noone leaves the program

setting there in a blocked state for extended periods of time.

The IO being tied to the UI isn't ideal, and probably  very bad for anyone needing high speed IO (In that case the storages

VI's probably aren't the best choice anyway). I read a little bit about when somethings run in the UI thread. Oddly

(to me at least) other UI elements (Like a counter in a seperate other loop) don't block when the Write VI does.  

The queue works well enough for my needs.