Autoload a VI on project load

[Michael Aivaliotis]

I'm getting used to the new project view in LV8.x. A feature that I think would be neat is the ability to specify a VI or LLB that will automatically get loaded into memory when you open a project.

[LAVA 1.0 Content]

I'm getting used to the new project view in LV8.x. A feature that I think would be neat is the ability to specify a VI or LLB that will automatically get loaded into memory when you open a project.

It seems we want different things - I really don't want all my 1000 VIs to be loaded into memory on prject open. :thumbdown: This however is what happens in LabVIEW 8.20 (see this thread). So here what you can do to force your VIs to load at project open in LV 8.20.

Add a class to your project (all my classes belong to libraries, but I don't think this matters). Then add a method to your class. Drop all your VIs you want to be automatically loaded to the block diagram of this method. That's it. Since LabVIEW loads the class and everything it refers to on project start-up, all your VIs are in memory instantly. Well, not instantly. If you have around 1000 VIs referred as I do, it may take around 10 minutes to open the project. And it consumes quite a lot of memory too.

[i2dx]

It seems we want different things - I really don't want all my 1000 VIs to be loaded into memory on prject open. :thumbdown: This however is what happens in LabVIEW 8.20 (see this thread). So here what you can do to force your VIs to load at project open in LV 8.20.

Add a class to your project (all my classes belong to libraries, but I don't think this matters). Then add a method to your class. Drop all your VIs you want to be automatically loaded to the block diagram of this method. That's it. Since LabVIEW loads the class and everything it refers to on project start-up, all your VIs are in memory instantly. Well, not instantly. If you have around 1000 VIs referred as I do, it may take around 10 minutes to open the project. And it consumes quite a lot of memory too.

seems you need a new machine, eh?

but to be serious: I prefer to have all the VIs in memory, instead of loading them from disk, each time I open them. I have 2 GB Ram on my development machines, and that works fine, even with my largest projects. RAM is cheap, so why stress the disk - which is furthermore the slowest part of your PC ...

cheers,

CB

[LAVA 1.0 Content]

seems you need a new machine, eh?

I'm waiting for my new workstation to arrive (Core 2 Duo E6600 + 4GB + 1TB RAID). But seriously you should be aware that the problem really is that LabVIEW project loading time doesn't scale linearily with the number of VIs. The first 50 VIs take about the same time to load as the last VI alone when there are around 1000 VIs referred in LVOOP project.

[bsvingen]

In the general case I don't think VIs should be loaded either, but it would be nice to specify some VIs that loads. When you have many VIs and lots of folders it will be very difficult for others to find the main VIs.

[Chris Davis]

I'm getting used to the new project view in LV8.x. A feature that I think would be neat is the ability to specify a VI or LLB that will automatically get loaded into memory when you open a project.

We may have missed the idea here. I think Michael may want something like what happens in Vis C or even CVI. These IDE's keep track of the last file you had open and open it when you open the "project". I could see that being useful. I could also see having the ability to specify a certain file open up for editing when starting a project.

[Michael Aivaliotis]

We may have missed the idea here. I think Michael may want something like what happens in Vis C or even CVI. These IDE's keep track of the last file you had open and open it when you open the "project". I could see that being useful. I could also see having the ability to specify a certain file open up for editing when starting a project.

Even though your idea is also a good one, I was thinking something else. Actually, I always makes sure all my VI's are in memory. Is there any other way to code? Before the project view, I had a VI Tree vi that I used to place all my important vi's on the block diagram. I then open this single VI to make sure I have everything accounted for. There are several reasons I like this.

• The primary is that when you update typedefs, all VI's get updated automatically without later surprises.
  
• When you use the save as feature with rename, all refering VI's get updated without later surprises.
  
• When you do a search, all VI's get searched.
  

There are others that I can't recall right now. I'm not saying that this should be a default feature but something that can be turned on, on a per\project basis.

Perhaps there's another way to address the above uses-cases in LV8.x but right now, I don't see it.

[LAVA 1.0 Content]

I always makes sure all my VI's are in memory. Is there any other way to code?

I agree that currently you need to have your VIs in memory to be able handle inter-VI referencing. I however would prefer a more intelligent system. Each VI should contain a cross-reference table listing all cross refereces. Instead of loading all VIs into memory, only these tables would be loaded to construct a project cross-reference (hash) table. When something is changed, this table would be looked-up by LabVIEW to check which other VIs this change affects. These VIs would then be opened on-demand and recompiled. Then if recompiling affects again other VIs, these VIs would be opened and the process would go on. To speed up the process, once opened VIs do not need to be closed until project close or until too much memory is consumed (user could specify limit). There should also be a way to remove VIs from the memory excluding the cross-reference table to allow more memory for VIs during run-time. This kind of system would produce the same functionality that you Michael are looking for but would scale up much better when the number of VIs increases.

[Aristos Queue]

Even though your idea is also a good one, I was thinking something else. Actually, I always makes sure all my VI's are in memory. Is there any other way to code? Before the project view, I had a VI Tree vi that I used to place all my important vi's on the block diagram. I then open this single VI to make sure I have everything accounted for.

Perhaps there's another way to address the above uses-cases in LV8.x but right now, I don't see it.

The ideal would be to get to the point where we don't have to have everything in memory, even for the reasons Michael cited. The project is designed to scale from the simple "couple VIs utility" to the VERY LARGE APP. As such, it does not load into memory all the VIs listed in the project (though subcomponents, such as LVClasses and XControls do at this time).

What could be done when you open the project is for the project to do a quick glance at each of the VI files to get specific information about them and cache that information -- such as which VI calls which other VIs as subVIs. Then editor actions could load VIs as needed. If I renamed A.vi to B.vi, the project would know all the callers of A.vi and could load them into memory right before doing the rename so that the project stays up-to-date.

The project today has a dual existence as both an application definition and a deployment/file tracking tool. If dependency tracking were added, this would push the project more toward being an applciation definition and less of a deployment tool. There's quite a bit of pressure back and forth between app development LV features and target deployment LV features over what the project's job actually is. There was a sign on someone's desk a while back that said, "If you build something truly useful, people will use it for things you never intended then criticize you for shortsightedness." This has sort of happened within our team with the project. The couple original designers had an idea for the project, but now that its there, a lof of other developers are suggesting, "Hey, I could use that to help with feature XYZ if I just tweak the project like this..." The future should be interesting.