Taking too long to load the VI's

[Pandiarajan]

Hi All,

                I am using LabVIEW 8.2.1 for my application development. My application vi's are taking longer time to load.

The loading window displays the loading of a vi from <vilib>:\Utility\Config.llb\Add Quotes.vi.

what could be the reason for this? and

How can I avoid this to improve the loading time of the vi's?

Thanks,

Pandiarajan R

[GerdW]

Hi Pandiarajan,

well I doubt you are able to speed it up (aside from taking a faster computer ).
And you didn't say what exactly is "too long" !?

This message only shows the last loaded item.
Maybe LabView is busy with initializations like checking 'VISA resource names'. This may take a while (especially when scanning GPIB or other communication buses for devices) and you just have to wait for finishing this step...

Message Edited by GerdW on 07-20-2007 10:43 AM

[falkpl]

Looks like you are loading this from test stand?  It is possible that your vi is looking for a vi which is not in the default place, but can be finding it in another library.  Try opening the vi (top level that test stand is calling) in Labview.  After the paths are updated, if this is the problem, save the changes and try it again.  This usually speeds up such problems.

Paul

[altenbach]

I don't think it is "searching", else it would show something interesting in the "searching..." panel of the dialog.

"add quotes.vi" is a tiny VI, and cannot be the problem in my opinion. Could it be the llb is currupt, for example? What happens if you start LabVIEW and open only "add quotes.vi"?

[LV_COder]

Hello All,

Can any body help me regarding the below issue.

1. In one of the toolkit example, i have used RF RIO instr. library(VST).

2. When ever i am opeing the example, its takes very long time  to load the VIs.

3. These driver RF RIO VIs have so many tyedef inside one other, due this typdef inside one other is the problem for long loading time or something different...(Not able to figure out what is the issue)

Can anyone help me regarding this issue.

Thanks in advance.

Hemant

[hfarley2]

Hi Hemant_LV,

As hinted in the above posts this is likely an issue with the location of the VI's that your example is calling. If for some reason they are not in the expected location then it will spend time looking for the VI's. You can try to run a force reinstall of the driver you are having issues with. This will help correct any issues with the examples and libraries the examples call. Refer to the following link on how to run a force reinstall.

Also, it may be helpful to open a new forum chain for your issue if this does not help. This forum is very old and few people will see it. By making a new forum post it will gain better visibility. 

Best,

hfar2

NI Applications Engineer

[LV_COder]

Thanks hfar2,

I will do the try as you have suggested and update the result in forum soon.

One more question.

Is Non-reentrant, Shared Clone Reentrancy,Preallocated Clone Reentrancy affect the memory consumption by LabVIEW.

Suppose i have a VI having Non-reentrant, Shared Clone Reentrancy,Preallocated Clone Reentrancy and calling a vi in two different loaction in another vi.. which behaviour(Non-reentrant, Shared Clone Reentrancy,Preallocated Clone Reentrancy) will take the more or less LabVIEW memory.

Actually when i am opening my SFP code then due to some large VI the LabVIEW memory is becoming full more about 1GB and after that loading of others vis become slow(as i have understood from the issue).

Can you please help me in the above issue.(I will do the way you have sugggested and update the results soon.)

Thanks 

Hemant

[udka]

-First of all, hfar2 suggested you to start new thread instead of posting in some old thread: Start new thread.

-You haven't posted your VI or Project, without which it is difficult to help you: So when you start new thread attach your VI/Project.

- Check Why Do I Get a "Memory is Full" Error in LabVIEW? and the links provided.

- Choosing Which Type of Reentrant Execution to Use

- Differences Between Reentrant VIs (Preallocate), Reentrant VIs (Share Clones), VI Templates, and Dyn...