LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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.
0 Kudos
Message 1 of 4
(2,700 Views)
Sumitrishi,

If using refernces solved the problem and made the code cleaner, you should be happy. Sometimes programming styles are personal in nature. I try following simple rules.

I follow a coding style that is easy to read and follow. I try to stay away from having a huge vi by using sub-vi's.

As for a specific answer to your question, it is difficult to say anything without seeing the code. But one piece of advice: don't be harsh on yourself. Look at examples provided by NI and some equipment manufacturer's. You can follow their style.
Keep your code clean and have fun programming with LabView.
Message 2 of 4
(2,700 Views)
In article <5065000000080000001CAB0000-1066448259000@exchange.ni.com>,
"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
Message 3 of 4
(2,700 Views)
thanks for a deep insight into this issue and also quoting your suff to support your point.i have worked with NI for two years but was in a diffrent team that worked on Measurement Studio. so i never got a chance to discuss much on labVIEW then. but definitely this forum is coming to help me in a big way .thanks again.
0 Kudos
Message 4 of 4
(2,700 Views)