LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Longer loading time when the version is changed.

Hi all,
 
When i load the VI in LabVIEW 8.2 which is originally developed in 7.1 or 8, it takes longer time to load compared to a VI that is developed in 8.2 itself. Even after i save that VI in 8.2, i am able to find the diffterence in loading time.
 
For e.g, if we place a VI that is originally developed in 7.1 and saved in 8.2. if you have that VI as a subVI in another VI, and click that subVI icon to open its front panel, it take around 5 seconds to open it is FP. Where as the VI developed in 8.2 opens less than a second. It happens always. Any suggestions?
 
Thanks,
logic
0 Kudos
Message 1 of 7
(3,350 Views)

Hello,

You are definitely correct that loading a VI that's not saved in the current version takes longer (it has to get recompiled, among sometimes other things).  My first thought is that, when LabVIEW loads a VI, it also loads all its subVIs.  You mentioned you saved your VI and it still takes longer to load in 8.2.  Does that VI have any subVIs that are not saved?  An easy way to tell is when you close it, are you prompted to save subVIs?

I don't want to say you should just save all your VIs in 8.2 though as you might need some of them to remain in 7.1 for now for future development, so be careful!  🙂

In addition to opening the top-level VI, closing it, and selecting Save All, you can pick Tools - Advanced - Mass Compile.  This will do effectively the same thing for a whole folder of VIs.  Again, be careful if any of the VIs in that folder or any VIs that the VIs in that folder call, recursively should not be brought into the current version.

Good luck!

Message Edited by Jeff B on 10-18-2006 04:05 PM

0 Kudos
Message 2 of 7
(3,345 Views)
Jeff,
 
Thank you very much for the reply. But i feel something more than that is causing this problem. Even the VIs that has no subVIs inside is seems to be hang moment. I feel there is always a difference between carried over VIs from earlier version of LabVIEW and the new VI developed in the latest Version. Saving a VI or saving all the VIs makes a VI identical to a new VI developed in the same version in all respects? I doubt it. Only NI can answer that.
 
I have attached a sample VI, Place this in a block diagram of a new VI of the LabVIEW 8.2. Do the following Action repeat manner.
 
1. Double click the icon (To open the Sub VI's Front panel)
2. Ctrl + E (Open the Block diagram of the Sub VI)
3. Ctrl + W (Close the Block diagram of the Sub VI)
4. Ctrl + W (Close the FP of the Sub VI)
5. Move the position of a Sub VI in the Block diagram, do 1 to 4.
 
When i repeat this again and again, i can feel the momentary hang at least once in five steps. Let me know whether you can feel this issue.
 
Thanks,
logic
0 Kudos
Message 3 of 7
(3,337 Views)
Yes, this this is definitely w..a..y..... t..o..o.....s..l..o..w. 😞
 
(seems to be the property node).
0 Kudos
Message 4 of 7
(3,332 Views)
Hm...  I can definitely reproduce the behavior you describe.
 
Do you see this behavior on all VIs you save in 8.2 that were originally created in 7.1, or just this one?  I could not reproduce this behavior in a new VI created in 7.1.  It may be there is something wrong with this VI after being saved in 8.2 that's causing this slowness, but unfortunately given just the VI it is quite difficult to tell what that something is, and more difficult yet to tell what caused that something to happen.
 
I can file a bug report on this, but it would greatly increase our chances of us being able to isolate and fix the issue if you actually have a way to reproduce the problem starting with a new VI created and saved in 7.1.
 
I understand this can be hard to do, but let us know what you can provide, thanks!
0 Kudos
Message 5 of 7
(3,316 Views)

Jeff,

I can give you lot of similar VIs. But it is not necessary. I guess, I figured out the problem.

The problem is the VI is pointing to a help file which is not there (VI Properties>Documentation>Help Path). I am sorry about this. But it brings up an another point that VI is not validating the help file path. I agree that it is not so critical. But it will be good to prompt that problem rather than killing the developer each time waiting like this. Believe me lot of us using this for years like this without anyother way.

If you can confirm me that the problem i figured is correct, that will be great. Thank you very much for the help.

Thanks,

logic

0 Kudos
Message 6 of 7
(3,302 Views)
Ah yes, good catch, sorry I didn't look around much in VI Properties.  Not only is the path to the help file not found, but it is a network path.  I'm not a network expert, but I'm pretty sure you've gotta give network path resolution some non-trivial timeout duration in order to expect it to succeed (provided the network resource is available).  You could argue that on failure we should put up a dialog telling you it failed to find the help file, but that could upset people as well.  Kind of a tricky problem to solve.
 
Regardless, I verified on my machine that if you clear out the help path, the delay goes away.
0 Kudos
Message 7 of 7
(3,289 Views)