Labview project size limit?

[hspec]

I have a large application that consists of a large GUI (state machine) and a couple other libraries with vi's and controls. The main GUI vi is 25Meg and the two .llb's are around 10Meg. I am finding that when I try to save the main GUI it can do one of three things:

1. Crash immediatly

2. Go non-responsive but still use 50 percent of processor resources

3. If I only make slight changes, it might save properly (takes a few seconds)

I am finding that the biggest problem seems to be related to making changes in the event case (there are currently 240 cases). I have run into situations where I cut and paste something into a new case, and the next time I save Labview crashes. Sometimes a broken wire in the event case can cause a lot of trouble if I do manage to save it. Once I remove the broken wire and try to save, Labview crash

Is anyone else seeing this problem, has anyone else found a way around this?

Any help would be GREATLY appreciated,

Thanks

Howard Spec

CMC Electronics

Canada

[yenknip]

25 meg main VI! Ouch! I can't think of any good reason why any VI would be that big, even with 240 cases. What code have you put into the cases? What other code do you have in the VI? With events, it is often a good practice to put the requests into a queue structure.

Bear in mind that the 25 meg will also include the front panel, so it is feasible you have a large raster graphic on your front panel

[hspec]

Ed,

Yes it is a very large chunck of code. The vi property for memory usage is as follows:

FP=1300K

BD=14998K

Code=3464K

There are over 80 cases in the state machine and 240 cases in the event case. The front panel has a tab control with 16 pages and each page has it's own tab control(s). The idea was to create one program with all the functionality. Are you saying that I need to break it up into popup windows and use queues to pass data?

Howard

[smercurio_fc]

That would be a good start. VIs should never be that large, as they can easily become corrupted. You should also not use LLBs unless you are distributing code. LLBs are a hold-over from the days when Windows was limited to 8.3 filenames. If one VI in your LLB gets corrupted, the entire library gets corrupted. If you want to use libraries, use project libraries (.lvlib).

[F._Schubert]

You don't need to create pop-up windows. If you have a set of releated controls, just pass them as references into a SubVi, which handles the appropriate events. Same can go for updating indicators (if they contain no array/cluster data, the 'value' property node will be ok).

Some posts in this forum suggest, that it is the huge number of event cases you have, that might cause the instability. The posted explanation was, that whenever you make a change in one of these cases/events, the compiler is recompiling the code of all cases behind the scenes.

So really find ways to reduce the number of cases/events. Propably the same code is executed for several events, that allows you to combine them. I also would not like to scroll down a list of 240 events when coding... 

Felix 

[hspec]

Felix,

I removed a few unused state machine cases and one unused event case and all of a sudden the code saves quickly again!  It does seem like there is a certain number it can handle, after which it quickly becomes a problem.

Also, yes 239 event cases are slow to traverse. I wish there was a way to get to the bottom of the list fast. It's usually not a problem since I always place the control in the event case and use "find control" to get to the case fast.

Thanks, 

Howard