How large of a VI can you make in LV?...

[B Harrington]

How large of a VI can you make in LV?... i have made one that is 10.5 meg, and it makes the program dog way down while coding... now im at the point that if i add anything it wont save... any please leave a comment on my problem

[Jochem]

I never had the problem of not being able to save the VI. But first of all if the 10,5 meg is real plain labview code you might want to consider to rewrite the VI by regrouping the code into several subvi's. It will increase the readability of your code and besides that make it easier for someon else to read it. By using subvi's you would avoid the being to large problem.

The other option is that the meg's are the result of using pictures in the userinterface. Playing around with the different option to import the pictures can help to reduce the vi size.
One of my projects has a lot of picture controls in it and that doesn't seem to be a problem. Using pictures can result in long saving times, add indepentimagedepth=-1 into the labview ini file.
Where did y
ou get the size of 10,5 meg, is that the real file size? or is it the information from "memory usage" with the VI's properties?
Hope it helps,
Jochem

[Mads]

10.5 MB....is that just pure code, or have you saved it with e.g. a graph loaded with a huge array of data (made default value). If you have any large amounts of data stored directly in the VI I would save them in separate files and load them when necessary instead, then the VI will be much easier to work with...and it's a better solution anyhow.

If you have large pictures e.g. in the background then you could load them during run-time as well.

[B Harrington]

Thanks for the reply, I was just wondering if anyone has actually reached a maximum size of a VI, or if there is a maximum size setting that I can change.

The VI I have created does take advantage of sub VIs. Under the browse menu, if I look at the hierarchy there is 30. If I look at the "this VIs subVIs" there are 10.
Under memory usage, it says
Front panel 2789.6k
Block diagram 5915.2k
Code 2445.5k
Data 659.3k
Total 11809.6k
Size on disk 10847.3k

If any of this looks out of the ordinary please let me know.

This VI is pretty intense; it is used in pump testing. It records 10 different flow points of 38 channels of data... and stores mean values, standard deviation, and a variety of test setup parameters t
o a pipe(|) delimited file for import into an access database for number crunching. There are a lot of bells and whistles to alert the operator of high temperatures, flow rates, vibration limits and pressures.

Any thoughts about my dilemma are appreciated

Thanks again

[paul_s]

Personally, I have heard of VI's being 100's of MB. One thing to watch out for is deep nesting of subvi's in time critical apps. We were taught that the deeper the subs go, the slower the app gets. This certainly panned out on a project we completed - to the point where ALL subvi's were removed and placed on the main block. This was on relatively slow computers, with fairly time-critical hardware.

Paul.S

[Al_S]

All those numbers look out of the ordinary to me. They're huge! You have some sub-VI's: create more. It will make you job much easier. As you see with the huge VI, even simple changes become a problem. With a diagram that big, it can be hard even to find the area you need to change, hard to make room for the change, hard to follow the wires to verify the change, etc., etc. Try to use more sub-VIs. Loops may help too.
There's some additional discussion on huge VI's here.

[Al_S]

I'm very surprised that a VI that's 100's of MB works. Not only from a system standpoint, but also from a development and debug standpoint. I would never want to try to develop anything that big or (even worse) try to maintain anyone else's VI that big. How can you debug it? How can you modify it? Even with today's PC's where 256 MB of RAM is pretty common, you're running out of memory with a VI that's 100's of MB's.
NI's Web Event Optimze your VI performance didn't tell us to remove sub-VIs to improve performance. If you have the sub-VI front panels open and you're writing a lot of data to the front panels, it will certain
ly affect performance. If you're repeatedly making copies of data as you go deeper into nested VI's you'll see slower execution. If you have a sub-VI that spends a lot of time waiting for data and that VI isn't reentrant, you'll spend even more time waiting for data. But please don't ask me to give up my sub-VIs.

[paul_s]

Hi Al - the 100's I have heard of was actually from a recent posting...

As for our project - this was an electric lift (elevator) simulation. The actual hardware is a replica of an electric lift - 4 floors, about 18" high. An optical sensor was placed on each floor, and one between floors. PC's were ~233MMX. The depth of subvi's made a huge difference to whether you could sense the lift had 'arrived', or if the lift sailed happily past the sensor before your vi could react - the more bells (literally) and whistles, the slower the reaction. Bear in mind, we were only 2nd yr engineers, and the code could undoubtably be better optimised, but it certainly drilled home the advantages of efficient code and fast computers. My implementa
tion was a finite state machine for which I won a prize for "best project - lift"

Here is a link to the lift project at UWA which you may be interested to look at, and may like to comment on:
http://www.mech.uwa.edu.au/courses/MD310/ms210liftlab.pdf

[Greg_McKaskle2]

> Personally, I have heard of VI's being 100's of MB. One thing to watch
> out for is deep nesting of subvi's in time critical apps. We were
> taught that the deeper the subs go, the slower the app gets. This
> certainly panned out on a project we completed - to the point where
> ALL subvi's were removed and placed on the main block. This was on
> relatively slow computers, with fairly time-critical hardware.
>

SubVIs do introduce some time overhead at runtime. This can be
minimized if the panels of the subVI are closed and the subVIs are
saved. Also, the Deallocate memory as soon as possible adds a huge
amount of overhead to subVI calls. When the subVIs are debugged, you
can also turn off debugging code to speed them up. Finally, you should
always try to use the profiler or smaller test programs to verify what
is causing your performance problem. I highly suspect that your
situation did not call for eliminating all subVIs, and in general, this
isn't good advice as it leads to the sort of source code issues this
person is having.

To address the large VI question, here are some comments on the numbers.
Front panel 2789.6k
This implies lots and lots of controls/indicators, or lots of imported
graphics. While this isn't necessarily a problem, you might consider
using popup panels to simplify your program and possibly simply using it.

Block diagram 5915.2k
This indicates lots and lots of diagram elements. As mentioned, subVIs
are key to making a VI easier to read and easier to maintain. The best
place to start is with any code that may have been copied. Often with
state machines or UI code, it is tempting to copy a sequence or loop and
change a Boolean or numeric constant. While the LV editor makes this
easy, this quickly leads to large diagrams, slower edits, slower loading
and saving, and more memory consumption during execution. The better
solution is to make this code into a subVI and pass the Boolean or
numeric in as a parameter. This means that changes to the code will
affect all uses, not just the ones you remember. By the way, the
easiest way to do this, though it does take some forethought, is to
select this code, and choose Create SubVI from the Edit menu. You will
likely need to move around some wires, and this tool cannot work when
certain nodes are contained in the selection, but this often simplifies
the work. Be sure to clean up the subVI, adding an icon, a description,
etc.

Code 2445.5k
This is a direct result of the diagram size.

Data 659.3k
This is a combination of default data and constants. This isn't
actually very large, and should shrink further as constants are moved to
subVIs.

Greg McKaskle

[mikeporter]

There are a number of factors that can cause the problem you are describing. The good news is that all the issues are under you direct control.

The biggest thing is DON'T USE LIBRARIES. The problem here is that LV has to rewrite the entire library when you save even one VI contained in it. Imagine what happens if you (for example) change a typedef and have to resave dozens of VIs....

The next thing is the size of your individual VIs. I just got finished with an application that has over 1300 VIs in it and it didn't load the computer down at all. The key is that rarely are any of my VIs larger than a few hundred k--and most of them are less than 100k.

A well-designed LV application will use lots and lots of small, very simple VIs. Remember that you don't
need complex code to generate complex functionality.

Consider as an example from nature, a common ant colony, and look at the complexity of their organizational structure. Now once you have your mind wrapped around that, consider further that none of the ants know how to make an ant colony work. Each individual ant has a very simply behavior, but when you combine all those very simple behaviors you get a great deal of complexity.

Well-designed programs are just the same.

Mike...