Want to know if it comes under bad programming style or somethinga?

A VI that is being called Dynamically also has some controls that need to be updated on the calling VI . I was using globals and accessing them in this dynamic VI . Now this as expected works fine but when i have to open the dynamic VI just by itself it can not locate these globals and i have to point them to the appropriate location.i tired using refrences also somehow felt the response was much better and also the source code loooked neat.

In article <[email protected]>,
"sumitrishi" wrote:
> A VI that is being called Dynamically also has some controls that need
> to be updated on the calling VI . I was using globals and accessing
> them in this dynamic VI . Now this as expected works fine but when i
> have to open the dynamic VI just by itself it can not locate these
> globals and i have to point them to the appropriate location.i tired
> using refrences also somehow felt the response was much better and also
> the source code loooked neat.
You've brought up a very good point. I've converted all my apps so that
they call VIs dynamically. It's almost like a test executive. I think
that use of globals is fine as long as you use them so they will be
utilized in the app efficiently. The only time I use globals is to store
static data like references and constants. I typically write to them
once, at start-up.
Data management gets real fun in dynamically loaded VIs. I have what
could be called a data buffer server running in the background. Fresh
data is tagged and then dumped into a promiscuous buffer (queue) as a
variant. Tagging could mean a number of things: time stamp, UUT #, test
ype, status, etc. The buffer server sits around waiting for data to come
in. When it does receive data, it reads the tags and dumps them into
another buffer that's more specific to the kind of test data. These
secondary buffers have a predefined cap. When they are full, then the
data gets dumped, processed, and then stored to disk.
Sounds chaotic but it works great. By passing the data management to a
buffer server, I can let my daq VIs continue collecting data without
interruption.
Errors are handled by another buffer server. By using notifiers I can
tell my dynamic DAQ VIs which test I want to stop, pause, or restart. It's
also good to make a server that continually checks on the status of your
synchronization VIs (good for trouble shooting). I use rendezvous to
verify that VIs have trully finished and exited when I tell them to.
Take a look at this sample program at
http://exchange.ni.com/servlet/Redirect?id=9601926
Has the basic framework. I could build up a generic example if you're
interested.
-Methis

Similar Messages

Maybe you are looking for