How do you use projects?

[CoastalMaineBird]

I am an old hand at LabVIEW, but new to LabVIEW projects.

I've used projects in other languages, and understand them fine.

But I'm having real trouble making LV projects work FOR me.

The ONE good thing I found is that I can place a VI into the HOST target or the PXI target, and LV knows to run it on the host, or run it on the PXI,

Great.

Beyond that, what do they do FOR you?

1. If I double click on my main LLB file, the LOADING box comes up after about 420 VIs, and shows progress up to about 950, then PRESTO, my main window is there, ready to go.

   If the PROJECT that contains this VI is open, though, after the LOADING is done, I get 10-12 seconds of an empty window frame (the size and title of my main VI), before it draws the front panel and is ready.

   If that's a benefit, then somebody explain it to me, because I just don't get it.

2. If I drag an LLB into the project, I don't understand what happens. I get a FOLDER with the current CONTENTS of the LLB in it. But if I put something new into the LLB, it does NOT show up in the project folder for that LLB. Isn't it obvious that I want to put the whole library into the project?
3. If my MAIN vi is in the project, and it calls subVIs A,B, and C, what benefit is there to putting "A" into the project, versus leaving it out? Everything still works, as far as I can tell.
4. In what circumstances should I leave OUT subVI "A"?
5. Do I have to put all 950+ VIs into the project to enjoy a benefit? Since it's unable to follow libraries properly, that becomes a giant PITA.

Basically, how do you make them work FOR you?

[Ben]

Hi Coastal,

I use project for what I HAVE to use them for.

Source Code Distribution is the big benefit. I used to use a "tree.VI" to hold all the VI's in an application. The Project does that for me (hidden in dependacies are all of the VI that are included elsewhere in the proj)

Support Files can now be tracked by the project where I used to have to do this manually.

With DSC, RT and cRIO apps the project makes things pretty easy. Without the project.....

Other benefits are public and private libraries.

Now the dirty little secret.

Under normal circumstances, I don't work form the project. It prevents the State Diagram Toolkit (did I mention I love the SDE?) from working properly in execution highlighting mode. And one more thing. I can not remeber experiencing the "slow to edit" problems I have heard so many people mention.

Trying to help,

Ben

[CoastalMaineBird]

Hi Ben - you must have a lookout for my posts because you're always there.. Thanks.

Source Code Distribution is the big benefit. I used to use a "tree.VI" to hold all the VI's in an application. The Project does that for me (hidden in dependacies are all of the VI that are included elsewhere in the proj)

I just did a REFRESH on the DEPENDENCIES item for my main program. 60+ seconds later, I have a list of 1200+ VIs (including all 47 variations of DAQmx CREATE CHANNEL.vi, of which I use only two or three).

I don't see that as any more useful than the old HIERARCHY window (which in 8.2 comes up blank for my biggie, rather than the 800 lines per inch of the old version).

Anyway, I have everything within one folder, so I "zip it and ship it" for my clients. Is there an improvement on that?

Support Files can now be tracked by the project where I used to have to do this manually.

Not sure what you mean by "tracking" them. Anyway, they're in the "zipped" folder, and all my paths are relative to the main, so I don't see a benefit.

With DSC, RT and cRIO apps the project makes things pretty easy. Without the project.....

Yeah, it IS easier than the old "switch execution target" model. That's the one thing I discovered.

Other benefits are public and private libraries.

Don't know about that; will investigate.

Thanks.

[Ben]

"...you must have a lookout for my posts because you're always there..."

No I do not look for your posts just interesting questions. You just happen to to post "Don't give me no crap" Q's that can be challenging to answer.

The "Source Distribution" is the new way to do "Save with options , preserve hiarchy, single prompt". I use this when I know there is extra stuff in my folders (things like Test1.VI, test2.vi) that I want to toss but I do not want to resort to finding each one manually. It just picks up everything I am using and puts in a new location.

Support files are things like configuration files, graphic files etc.

The project is not a replacement for the hiearch screen.

The project also permits multiple LV contexts to be used. Before the project, if you wanted distinct memeory spaces, you either had to run one VI as an exe and the other in the LV deve environment, or,

you had to create multiple copies of LabVIEW.exe to get multiple memory spaces. With the project there is a memory space for each proj open plus one for all VI NOT opened from a proj.

If I was working with LVOOP I would be able to rattle of more benefits. Maybe Tomi will reply.

Ben

[TCPlomp]

I'm quite a fan of the project (maybe because I naive (?) thought if NI thinks we need it, I'll probably need it)

The shift you have to make to embrace the project is that it is a storage room for everything related to your code. It's not a mirror of your desktop (for that we have explorer).
Just like every new feature it has its bugs....
One of the things I love, is the ability to have one installer for several executables!
The ability to have good tweakable bld file for distributions, easily adjust external routines for different tasks.

The project itself is quite accesible from within LV, the only thing I miss is  a 'get current project' method for VIs, but I can see why this is not available.

Ton

[Marc_A]

I'll just throw something out here. The one thing I wish projects had was the ability to create a folder in the project that linked to an actual folder on the drive. My projects are basically a mirror of the directory in which they reside. If I create a new VI and save it to a folder somewhere in the project directory (on the drive), I also have to move the file that was created in the project to its corresponding directory (in the project window). I wish this was automatic.

I found a way around this by right clicking the folder in the project and selecting new->VI, but i don't usually use this. I'd rather just hit ctrl+n to get a new VI.

It's a minor inconvenience, but it could be fixed by adding an option to create a linked directory. This also goes along with what was originally posted - adding a VI to an LLB that was added to a project does not add the new VI to the project.

I hope that made sense.

[CoastalMaineBird]

I use this when I know there is extra stuff in my folders (things like Test1.VI, test2.vi) that I want to toss but I do not want to resort to finding each one manually. It just picks up everything I am using and puts in a new location.

OK, I can see that. I have a LINT FILTER program which finds all the cruft and lets you delete it, but your way is just as good, I guess.

The project is not a replacement for the hiearch screen.

The project also permits multiple LV contexts to be used. With the project there is a memory space for each proj open

THAT could be useful in special situations. If PROJECT1 uses X.vi, and PROJECT 2 uses X.vi, you could run both projects and you have TWO copies of X, with separate data spaces.

[CoastalMaineBird]

I'm quite a fan of the project

TonP, can you comment on my original questions 3 & 4?

Why should I stick SubVIs A,B and C into my project?

Why should I leave them out?

[CoastalMaineBird]

I'm quite a fan of the project

OK, so how do you deal with the godawful slowness of it?

I just clocked it at 35 seconds between the time I hit the RUN button, until the time it started (STARTED) deploying.

During that time, the DEPENDENCIES list got updated, and as far as I can tell, that's completely useless. It already knew all the dependencies (it loaded the main, which calls subVIs, which call sub-subVIs), so why is it doing it again?

And there are 40+ instances of DAQmx WRITE in the dependencies list, of which I use 2 or 3. So why did it waste my time chasing all those? My program is NOT, in fact, dependent on them.

Yet, as far as I can tell, I can't run a PXI program without a project.

[CoastalMaineBird]

So, I created a folder called DEPENDS in my project, and I dragged all the files from the DEPENDENCIES folder into it. That basically puts them into my project.

BEFORE: 9.3 sec to OPEN the main VI (and all its descendents).

36.3 sec to dependency-check it.

4.0 sec to dependency-chack it the 2nd time (RUN again).

AFTER: 8.9 sec to OPEN the main.

29.5 sec to dependency-check it.

4.0 sec to dependency-chack it the 2nd time.

So there's SOME savings there, but not much. So what is the value?