Labview 8.0 - My main vi has started to hang!

[Ibbo]

Hello,

I have written some code in LabView 8.0 which consists of a main VI and several sub-VIs.  The code controls a DAQMx DI-6221 board doing some basic digital I/O.

I haven't made any changes to the main VI code for a number of days.  Gradually over the last few days the VI has started behaving oddly (ie. showing some of the front panel with a portion which is frozen).  This happened more and more each time I have opened the VI.  Today, when I try and load it the VI just hangs at the LabView splash screen.  I can load any of the subVIs which the main VI uses with no problems whatsoever.  The computer is not connected to a network and does not have a virus (I checked today).

Anyone able to help with ideas?!  I'm quite desperate but I don't want to resort to reinstallation of LabView just yet.  The fault really did seem to come on slowly getting worse every time the VI was opened.  Sometimes the front panel does appear but it can't be run and I just get the 'paint' effect where you can drag the window around the screen creating lots of outlines of the window.

Cheers,

Rob

[smercurio_fc]

You said you haven't made changes to the code "for a number of days", but you also said that the problem occurred "gradually over the last few days". This to me seems like it might be tied to the changes you made right before it started. You may have a corrupt VI. Try going back to a version that worked and work in your changes one at a time.

[Ibbo]

Thanks for the quick reply.

Are corrupt VIs common?  I would have thought any code that was no good would just cause an immediate problem which would flag up as a normal LabView error.  Why would any change I have made to the code cause LabView itself to be unable to open the VI?  If I post the vi here would anyone be able to tell if it is corrupt?

Edit: I've left out quite a few sub-VIs but no of them seem to be the problem as I can open and run them all normally.

[billko]

Sounds to me like something isn't letting go of its resources?

[smercurio_fc]

No, this is definitely a front panel issue. I see the same problem opening the VI in 8.2, and I can't run the VI because of the missing subVIs and no hardware. It appears that LabVIEW doesn't like one or more of the controls. Copying the contents of the block diagram onto another VI doesn't clean it up, so the problem seems to be inherent with the control(s) or indicator(s). Perhaps someone from NI may be able to pinpoint the problem - you may want to give them a call directly. Or, try what I said, and go back to an earlier rev.

[altenbach]

It opens fine in Lv2010, maybe I could downsgrade it back to 8.0 to see if things improve....

A few potential issues:

• The graph legend of "read waveform 2" is messed up. Did you customize it so the names overlap with the graphics?
• Do you really need the "XY Array"? It's not even visible.
• How big are the arrays? Are they larger than the visible elements.
• What's up with all the overlapping decorations in the bottom center?
• Why is the "mode" ring in DBL representation?
• How big does the data in the shift register get?

I think rewriting it as a clean state machine, you could get rid of all the hammering via property nodes.

[gt3000]

Hello Ibbo,

Corrupt VIs do not occur often, however, they do occur. I have been able to open your main VI in LabVIEW 2010 and then save it for a version 8.0 for yourself.  You should find it attached.  It should still be able to load your SubVIs and run when your click the 'Run' arrow. 

If you notice that the performance of a VI is degrading, and you believe it is corrupted, a quick trick that has known to work in the past, but not guaranteed, is:

1. Open a Blank VI
2. Open the Existing VI's Block Diagram
3. Press Ctrl+A to select the entire Block Diagram
4. Press Ctrl+C to copy all of the code
5. In the Blank VI's block diagram, press Ctrl+V to paste the code.
6. Save the new VI with a new, different name.
7. If the new VI still appears sluggish after the paste, press Ctrl+Shift+Run Button Click to recompile the code in the background.

Corrupt VIs can occur more often when using a newer Operating System with an older, unsupported version of LabVIEW, such as LabVIEW 8 on Windows 7.  Which OS do you have?

Looking at the code, I have also noticed that you have a While Loop in another While Loop.  Generally speaking, when you believe you require such function, or many Nested Case Structures, that VI is generally a good candidate for a State Machine architecture. 

I would also like to promote the comments that the users above have made about changes that can improve the code and make it more maintainable for the future.

Regards,

[Ibbo]

Thanks again for everyone's comments and suggestions.

smercurio_fc, I appreciate your comment about returning to an earlier version and trying again but I suspect I would just want to repeat the same code in exactly the same way.  Also it's interesting that you can copy the block diagram contents into a blank vi as I can't even open the block diagram.

Altenbach: thanks for your comments, I'll have a look at the potential issues and see if I can improve matters.

I'll then try and answer your questions in another post once I'm back on the LabView machine.

gt3000: thanks for the resaved VI, I'll give that a go first.  It seems to be a different size to the one I uploaded, I wonder why that is?    

I'll have to look into the state machine architecture as I haven't come across it before but thanks for the suggestion.  O/S is windows XP SP3.

I'll let you all know how I get on.

Cheers,

Ibbo

[Ibbo]

gt3000:  Thanks for the code.  It works again and when LabView compiled the vi for the first time it went back to being 96kb (same as the original file I uploaded).

Altenbach, here are some answers:

• The graph legend of "read waveform 2" is messed up. Did you customize it so the names overlap with the graphics?

Yes I did customize it but the names don't overlap with the graphics on my front panel.

• Do you really need the "XY Array"? It's not even visible.

I've removed this as you're correct that I don't need it anymore.

• How big are the arrays? Are they larger than the visible elements.

The arrays should be the same size as the visible elements.  In the boolean arrays each indicator represents a switchable element.  The rectangular section is all the groups available and the section with the overlapping decorations is the elements available within a group (which doesn't have corner elements).  The rectangular section also has two additional 1D arrays on the vertical and horizontal access which identify when a particular selection line is active. 

• What's up with all the overlapping decorations in the bottom center?

 See above.

• Why is the "mode" ring in DBL representation?

The control just defaulted to that when I created it.  I've changed it to U16 now which seems to be the default for ring controls.

• How big does the data in the shift register get?

The shift register is always 211 bits long.

[Ibbo]

Altenbach, sorry also wanted to ask:

You mention that the VI is getting a hammering from all the property nodes but I was taught that property nodes were the best way of interacting with indicators.  Is that not the case?