My vi file won't open

[jdvbmw]

I have created a large 8.7meg vi. I am not using any sub-vi's. The last thing I did was copy a large section of code and paste it in another area of the block diagram. I then made a few changes to the new local variables and moved a few of the new objects around on the front panel. When I went to save my work LabVIEW failed and closed out automatically. I did not read the error message it gave, I just clicked OK. I now cannot open the vi. The error given is "load.cpp",line 4835. I sent the file to NI and they cannot open it with their utility programs.

I had a similar problem once before when I had too many front panel objects, more than 555. When this happened LabVIEW failed to save the work but, the file could still be opened to co
rrect the problem. I used clusters to group similar objects togeter.

Any help would be appreciated.

[Dennis_Knutson]

If NI can't open your VI, I seriously doubt any LabVIEW user can open it either. Hopefully you've got a backup. In the future, you should probably rethink the design of your application. The fact that you copied a large section and pasted it into another section says to me that it should have been a subVI. A good rule of thumb has been to try to keep your diagram no bigger than one screen. Trying to maintain something and understand what's going on is hard enough without have to scroll several times to find where wires go. A state machine is an excellant way to keep diagram size managable. Having 255 fron panel objects sounds excessive as well - even if there wasn't some sort of LabVIEW limitation. There's a brief article on user interface design on the
LabVIEW Zone here and there's a link there to an NI Week presentation on the same subject.

No help on your present dilemma but even if you do manage to open the corrupt VI or restore from a backup, I think you're going to continue to have problems in the future.

[Al_S]

Sorry, I agree with Dennis. NI certainly knows the proprietary structure of a VI and has better tools than any of us to disect or repair a VI.
There is a concept known as modular programming that will make your life (or at least you job) much easier. The idea is to develope and debug a module (or VI) once and to use that module (as a sub-VI) in any number of places. Wherever in you calling VI you need what the sub-VI does, you have a copy of the sub-VI: not a copy of the code, but a copy of the sub-VI.
Here are just a few of the benefits of modular programming.
- If you need to make a change to the sub-VI, you need to do it in one place. You don't need to search through your large diagram for code that looks like it does the function you want to correct.
- It makes your upper level diagrams easier to read. You can see a better overview of the high level functions without seeing all the low level details.
- It gives you many more debugging options. If you're suspecting a problem in a sub-VI, you can put that VI into Suspend When Called (using the Operate menu). When the calling VI calls the sub-VI, the sub-VI panel will be displayed. You can then run that VI repeatedly, change the inputs and run it again, and then return to the calling VI, or you can skip the sub-VI.
- It is much less error-prone than copying code. You can see at a glance all the connections into and out of the sub-VI. You get consistent results: if you're having a problem with one section of code, you don't have to keep reviewing two sections of code that started as copies to see if they're still the same.
- It makes it easier to re-use and share code. It's much easier to pick a VI from a list than to copy a large section of code from one VI to another to copy the code within the same diagram. It lets other people benefit from your experience: they will be able to find a VI with a descriptive name much more easily than to scan your large diagram looking for a section of code that performs their desired function. You're the inventor: let other people use your invention. If someone asks you for a light bulb, give them a light bulb, not the whole system with power-generation and distribution, fuses, wires, switches, fixtures, and (somewhere in there) light bulbs.

When you start from your backup, start making sub-VIs. LabView makes it pretty easy to do: select a section of your diagram that you want to make into a sub-VI, then, from the Edit menu, select Create SubVI. You'll get a sub-VI with inputs and outputs assigned on the connector. You need to save that sub-VI with a descriptive name. Then start searching for anyplace else in your main VI where you used a copy of that code. Don't create new sub-VIs for those copies: replace the code with the new sub-VI.
I was amazed at the size of your VI. I have some applications that big, but they may be more than 300 VIs.
It will take a lot of work to get started, but you (and anybody that uses your program) will be pleased when you're done.

[JRA]

Dennis and AI S are certainly right on this. Breaking your large program into sub-VIs is one of the best things you can do for yourself and those developing with you. A common rule of thumb is that, if your VI gets to be over 500K, you need to break some into a subVI. Debugging will be a much more pleasant experience!

[jcrooke]

I am sorry that no one directly addressed your question.  I, too, would like to know the limits of LabVIEW 6.1 diagram size, total vi size, limits on the number of the various types of code structures, and so forth.  Rules of thumb are great, but when you are faced with a major rewrite at the last minute, you want hard answers.  Apparently, there are no direct answers to your question, just general advice.  The only hard number I have seen in print is the 555 limit on controls and indicators.  What happens when you use the recommended code structures, you don't have too many indicators, and your vi is still huge?  It works at say 140MB but not at 141MB.  How do you know when to look for different ways of doing things?  Why is there a limit at all?  If I have 2GB of memory, why can't I edit a 150MB vi?

[falkpl]

I have had similar problems with labview and I don't think it had to do with the size of the vi but a copy paste bug, each time my vi has crashed and not been loaded back properly, I was pasting in code.  I wonder if there is some problem with instances where wires don't match up correctly.  I rarely crash labview or corrupt files but have had the most problem with cutting and pasting code.  One other problem I have is with dynamic event registration, when I delete certain wires, the application crashes and it depends on the order of the wire removal (maybe its a bomb and not a bug?).  I would recommend backing up all code each morning since hard drive space is almost free, but time is not.  I have never been able to recover when I vi will not load, sorry if this is not a big help.  Why is the vi so big? Why not use subvis, it promotes reuse, simplifies code allows for easy refactoring, at least from my own experience.   

Paul 

[jcrooke]

Hi, Paul.

Thanks for responding to this old thread.  I submitted a new post

http://forums.ni.com/ni/board/message?board.id=170&message.id=137801

that explains why I have a large vi.  I may have to regroup and think about subvi-ing some of the code, but I was hoping for a positive answer to my question, rather than a negative answer. 

It seems to me that one obvious way out of my dilemma is to recode the project in a way that LV6.1 likes, be it reducing the number of diagrams, the number of controls and indicators, the number of control references, the number of structures, or any number of things that may be suggested.  I am sure I will receive plenty of general advice on better methods of programming that reduce one, some, or all of these components.  I appreciate all of this thoughtful free advice, but I am under a time crunch and I don't have a lot of time for code rewriting.  I really need to narrow my target for this project by knowing specifically what limit I have exceeded and reduce the code accordingly.

Your comment about cutting and pasting is intriguing.  I do it prolifically and my first problem with saving occurred when I deleted 5 User Event loops and replaced them with 5 state machines by cutting and pasting.  There were a number of broken wires (error cluster wire attached to the side of the state machine for data flow dependency).  I was able to unbreak all of the wires but one (one end dangling free) .  Every time I tried to delete this broken wire or attach it to something to heal it.  The healed version of the code would not save.

Thanks again,

Jayme