What's the importance and Value of the Project environment?

[LAVA 1.0 Content]

QUOTE (ASTDan @ Mar 18 2009, 09:08 PM)

My main complaint/misunderstanding is if I organize all my files properly on disk why do I need the project? What value does the project give me if I orgainize all my code and suporting documentation on disk?

Another plus:

Conditional Diagram Disable

Most likely you currently work with a 'tree.vi' to encapsulate all your code and prevent cross-linking issues, if you are customized to this routine, stepping over to the project should be quite easy.

One other plus that a colleague intoduced:

A projects project.

The sole purpose of this project is to keep all the (current) projects in one spot. It only contains other projects, and is an easy access to them.

One other point, the project allows you to have multiples projects open at the same time without any collision between them, you can move a VI from one project to another with a single mouse click.

Dan, my advice, go with it.

Let it bug you for a week, than never look back.

Ton

[ASTDan]

So it looks like if I import my File layout into the project first, and select autopopulating files. I save off new vi's in my folders the newly created VI's will be reflected in the project in the correct folders.

It looks like in Version 8.5 Projects became much easier and more intuitive.

"NI introduced autopopulating folders in LabVIEW 8.5 to automatically reflect the contents of folders on disk." From web

This gets rid of my main concern of the project not matching what is on disk in real time. I may need to look at this again.

QUOTE

The auto-populating thing really cheeses me. I creatle little test vi's all the time during development to test out ideas before I intigrate them in the main code. These show up in my project when they don't belong, and I have to go into the project to delete them.

I am referring to when I create a New vi it just sits in the project on the main level and I would have to manual move it. It looks like with LabVIEW 8.5 there have been improvements to the project.

Would anybody care to comment on how the project has evolved since its release until now? I am wondering if I have a negative impression from the initail release and the subsequent releases have been much better.

[Neville D]

QUOTE (ASTDan @ Mar 18 2009, 02:28 PM)

"NI introduced autopopulating folders in LabVIEW 8.5 to automatically reflect the contents of folders on disk." From web

Amid all this project goodness: one annoying thing with auto-pop folders is that everytime you open the project it has an asterisk * for save changes even if there are none. It has something to do with the auto-pop folders.

Just a caution.

N.

[Jeff]

Another really nice feature of projects is that you can rename a VI, and all referencing VIs get updated to reflect the change. And in LV 8.5+, you can also move VI locations on disk (in the Files tab) and have referencing VIs automatically updated. (Just make sure you save the changes to the VIs when you close your project.)

Jeff

[gmart]

QUOTE (Cmal @ Mar 18 2009, 03:36 PM)

Here are some of my thoughts on projects that I hope will help make a believer of you:

• One of the nice things about the project (in my opinion) is that all VIs are loaded into memory when a project is loaded. This helps ensure that there are no missing VIs, and it has saved me a lot of confusion more than a few times.
  
• The project integrates nicely with source code control. You can see which VIs are checked out, or which ones haven't been added to SCC from the project window. Once again, this has saved me the pain of accidentally creating VIs and forgetting to submit them the SCC.
  
• Auto-populating folders are not required. I personally use virtual folders instead.
  
• If you ever decide to use native LabVIEW classes (and you should), then the project is pretty much required. The same goes for XControls, Shared Variables, and many more LabVIEW features that don't come to mind right now.
  

Chris M

A clarification. A project ,by itself, does not load VIs into memory when it is loaded. It is able to determine what dependencies are needed/used without loading VIs into memory. The project does load project items such as libraries or classes which may load VIs.

[Michael Aivaliotis]

QUOTE (gmart @ Mar 18 2009, 03:13 PM)

A clarification. A project ,by itself, does not load VIs into memory when it is loaded. It is able to determine what dependencies are needed/used without loading VIs into memory. The project does load project items such as libraries or classes which may load VIs.

This is important to note. Thank you gmart for reminding everyone. If some of you see the "loading VIs" dialog popup when you are opening a project, this is because you either use LV classes or lvlibs. Only VIs called by the classes or contained in the lvlibs are loaded into memory, other VIs are not. Watch out for this.

[Jim Kring]

QUOTE (gmart @ Mar 18 2009, 03:13 PM)

A clarification. A project ,by itself, does not load VIs into memory when it is loaded. It is able to determine what dependencies are needed/used without loading VIs into memory. The project does load project items such as libraries or classes which may load VIs.

Hi George,

I apologize, in advance, for not reading this whole thread (or testing to answer my own question, below). I just have a quick question:

Are lvlib members really also loaded into memory when the project is loaded? I thought that only class members were loaded into memory when the project was loaded.

Thanks,

-Jim

[gmart]

QUOTE (Jim Kring @ Mar 18 2009, 06:44 PM)

Hi George,

I apologize, in advance, for not reading this whole thread (or testing to answer my own question, below). I just have a quick question:

Are lvlib members really also loaded into memory when the project is loaded? I thought that only class members were loaded into memory when the project was loaded.

Thanks,

-Jim

In general, no. I was trying to cover my bases since it's possible that a library owns a class and such. In that case, loading a library would load VIs but only due to a class being a member of the library.

[mje]

QUOTE (Jeff @ Mar 18 2009, 05:42 PM)

Another really nice feature of projects is that you can rename a VI, and all referencing VIs get updated to reflect the change. And in LV 8.5+, you can also move VI locations on disk (in the Files tab) and have referencing VIs automatically updated. (Just make sure you save the changes to the VIs when you close your project.)

Jeff

This. Best feature ever.

A close second is conditional disable structures (or rather the definition of symbols). The only reason they're not first is I don't think they belong exclusively in the project scope to begin with...you really ought to be able to define them in class/libraries in my opinion, possibly even at the VI level. Just have the hierarchy sort out any conflicts and allow me a clear way to see which scopes are overriding what.

[Jim Kring]

QUOTE (gmart @ Mar 18 2009, 06:20 PM)

In general, no. I was trying to cover my bases since it's possible that a library owns a class and such. In that case, loading a library would load VIs but only due to a class being a member of the library.

Thanks for the clarification.

[bsvingen]

Another thing is that all dependencies is listed up automatically. This can be extremely usefull sometimes.

[Ale914]

I use project when work with FPGA i suppose that is impossible work whit FPGA without using project becouse of the dependecies of resource (memory, FIFO, pins) with the FPGA code and FPGA HW descriptor

[Cat]

QUOTE (Michael Aivaliotis @ Mar 18 2009, 07:01 PM)

If some of you see the "loading VIs" dialog popup when you are opening a project, this is because you are using LV classes.

Ohhh, that explains it. I wonder about that everytime it pops up. I'm not using classes (which I have a Q about but will post on another subforum), but I guess something I'm calling does. Thanks for the info!

[Grampa_of_Oliva_n_Eden]

QUOTE (ASTDan @ Mar 18 2009, 03:08 PM)

I was having a conversation on facebook with crelf regarding the project in LabVIEW.

Personally I only create a project at the end of projects to build exe, source code distributions, etc. Whenever I have tried to use it during development I throw my hands up in frustration.

The auto-populating thing really cheeses me. I creatle little test vi's all the time during development to test out ideas before I intigrate them in the main code. These show up in my project when they don't belong, and I have to go into the project to delete them.

My main complaint/misunderstanding is if I organize all my files properly on disk why do I need the project? What value does the project give me if I orgainize all my code and suporting documentation on disk?

Auto-populating:

A single developer may keep this on but in a team you run into issues with dirty projects (asterisk).

I use the "auto-populate now" occationally but usually place the VIs manually where i want them.

For the most part I use the virtual folder view since I can oraganize the VI differently than they are araanged on disk (very useful when working with LVOOP).

THe Right-click option "Find in Folder View" is also sueful sometimes.

Project are an absolute must very useful for distrbuted apps. to mangae and control all of the nodes and their options.

Source Distributions can help with cleaning up your floders (Old Save with Options)

Documentation and support files come along with the Source Distribution (a plus over the old Save with Options).

What I don't like about the project...

It has about ten zilliion save options! I still don't know which flavor of save saves what.

The tools in the project are only in the project. Say I have an app that has to talk to 500 cFP units. Without bending over backwards (which I did) you wil need a project with 500 cFP nodes configured to be able to load the same software on each but with different IP addresses and config files. Yes this is an edge case.

It combined with Shared Variables done in the DSC Engine and all of its processing power and efficeincy. I know cringe when faced with tag count apps with more than 500 I/O points. At high channel counts DSC would shine but I simply don't have the confidence in the Shared Variables to "look a customer in the eye" and tell them that Shared Variables will be able to handle the I/O reqs.

Support of the SV placed a heavy load on cFP units and some of the earlier version of LV 8, the goobled all of teh CPU to make them work. (Oh bother!).

Just my 2 cents,

Ben

[Yair]

QUOTE (ASTDan @ Mar 18 2009, 11:32 PM)

This gets rid of my main concern of the project not matching what is on disk in real time.

I'm surprised no one really said this explicitly (although Ben has alluded to it), but the project does NOT have to mirror the disk layout, and there are some advantages to it not doing so. Specifically, You can place only the stuff you want to access frequently in the virtual folders and thus ignore all the boring subVIs.

Also, you can have links to documents, etc.

[Neville D]

QUOTE (neBulus @ Mar 19 2009, 05:53 AM)

What I don't like about the project...

The tools in the project are only in the project. Say I have an app that has to talk to 500 cFP units. Without bending over backwards (which I did) you wil need a project with 500 cFP nodes configured to be able to load the same software on each but with different IP addresses and config files. Yes this is an edge case.

No, this is definitely NOT an edge case. I have an app where I have 12 PXI targets all running the same code at a customer site, and I had to individually build exe's and download them one by one.

I built my own tool to ftp the exe code to all targets simultanously, but that took a fair bit of work.

Also, the more targets you add, the longer the project takes to load, even though each target has pretty much same info. And making changes to these projects seems to take longer (like make copy of project).

N.

[Michael Aivaliotis]

QUOTE (Yair @ Mar 19 2009, 11:33 AM)

...Specifically, You can place only the stuff you want to access frequently in the virtual folders and thus ignore all the boring subVIs.

Also, you can have links to documents, etc.

Yes! You don't have to put all your VIs in the project. I typically put only my main user interfaces, process VIs and other toplevel code.

[jgcode]

QUOTE (Neville D @ Mar 20 2009, 05:25 AM)

No, this is definitely NOT an edge case. I have an app where I have 12 PXI targets all running the same code at a customer site, and I had to individually build exe's and download them one by one.

I built my own tool to ftp the exe code to all targets simultanously, but that took a fair bit of work.

Also, the more targets you add, the longer the project takes to load, even though each target has pretty much same info. And making changes to these projects seems to take longer (like make copy of project).

N.

neBulus and Neville D

Maybe this would have helped?

Real-Time Target System Replication

I haven't used the code personally but I know they exist as I was investigating for a similar thing for a project that went cold last year.

Now there is one for FPGA too.

FPGA Target System Replication

Cheers

JG

[Rolf Kalbermatter]

QUOTE (ASTDan @ Mar 18 2009, 03:08 PM)

I was having a conversation on facebook with crelf regarding the project in LabVIEW.

Personally I only create a project at the end of projects to build exe, source code distributions, etc. Whenever I have tried to use it during development I throw my hands up in frustration.

The auto-populating thing really cheeses me. I creatle little test vi's all the time during development to test out ideas before I intigrate them in the main code. These show up in my project when they don't belong, and I have to go into the project to delete them.

My main complaint/misunderstanding is if I organize all my files properly on disk why do I need the project? What value does the project give me if I orgainize all my code and suporting documentation on disk?

While you can get away not using the project for simple LabVIEW host applications it sure is a very handy tool to use when you start to do multi target applications (host, RT, and FPGA, and/or PDA targets in one project).

I also agree that the auto populating feature is rather disturbing than useful. My projects never contain the low level functions but only the top level functions of each target, the dynamic VIs in a seperate folder and any GUIs in another folder. Possibly I add another folder for some specific VIs etc.

I still organize my files on disk too but I find it useful to have another level of organization where I can maintain a somewhat different logic of how to organize my VIs than what it looks on disk. The feature that is called autopopulating folders by NI (just copy the disk hierarchy into a seperate tree view) is not useful at all in my view, and does cause all sorts of headaches for the NI developers too to avoid cross linking in the project.

That all said I still have projects that were developed in earlier LabVIEW versions and are currently maintained in LabVIEW 7.1.1. So I couldn't even throw away the traditional way of organizing VIs even if I wanted to.

QUOTE (jgcode @ Mar 19 2009, 10:56 PM)

neBulus and Neville D

Maybe this would have helped?

Real-Time Target System Replication

I haven't used the code personally but I know they exist as I was investigating for a similar thing for a project that went cold last year.

Now there is one for FPGA too.

FPGA Target System Replication

While I haven't used the latter the first one is indeed working. I didn't use it for multi target deployment but built them into the host application to have a user friendly way of updating the RT target with a new software version if that should arise.

It is a bit tricky to built it into a user application in a way that it can be used by people not familiar with LabVIEW or even programming at all. I made it basically a one button click operation in the maintenance screen of the application together with another button to discover any cFP target in the local network to fill in the IP address to use.

Seems trivial enough to use.

Rolf Kalbermatter

[Grampa_of_Oliva_n_Eden]

QUOTE (rolfk @ Mar 20 2009, 02:58 AM)

.....

It is a bit tricky to built it into a user application in a way that it can be used by people not familiar with LabVIEW or even programming at all. I made it basically a one button click operation in the maintenance screen of the application together with another button to discover any cFP target in the local network to fill in the IP address to use.

Seems trivial enough to use.

Rolf Kalbermatter

So its not an edge case after all.

Then our shared experiences having to fill this hole left exposed by the proj way of managing distributed LV apps highlights that fact the project can benefit form ... "Tinking outside the project".

Ben

[Neville D]

QUOTE (neBulus @ Mar 20 2009, 04:02 AM)

So its not an edge case after all.

Then our shared experiences having to fill this hole left exposed by the proj way of managing distributed LV apps highlights that fact the project can benefit form ... "Tinking outside the project".

Ben

Yes, I have been harping about this with NI engineers for a while, every opportunity I get.

jgcode, I am using the System Replication tool as part of my remote utility to deal with multiple targets, but like I said it took a while to get everything to run smoothly, when really, it should be part of the project setup to be able to download the same code to a number targets with a single "build & run as startup" option on the project somehow.

Another pet-peeve I have is the inability to update NI software on a remote target without NI-MAX. Customers don't know or care about it, but would like a CD (sent by us) that they could run to upgrade their NI RT hardware to the latest-greatest versions.

Neville.

[Matthew Zaleski]

QUOTE (Neville D @ Mar 20 2009, 12:44 PM)

Another pet-peeve I have is the inability to update NI software on a remote target without NI-MAX. Customers don't know or care about it, but would like a CD (sent by us) that they could run to upgrade their NI RT hardware to the latest-greatest versions.

Neville.

Did I misread the provide NI link to RT Target System Replication? It seems to imply that I could image the drive in my cRIO, drivers and all, then replicate it to other cRIOs. The tricky part would be the INI file controlling IP address.

Assuming I misread that, then yes, I'd love to be able to somehow script the whole device driver install for NI-MAX. I now have theoretically identical systems scattered worldwide. Explaining NI-MAX to someone half a world away isn't my idea of fun, hehe.

[Neville D]

QUOTE (Matthew Zaleski @ Mar 24 2009, 03:32 PM)

Did I misread the provide NI link to RT Target System Replication? It seems to imply that I could image the drive in my cRIO, drivers and all, then replicate it to other cRIOs. The tricky part would be the INI file controlling IP address.

Assuming I misread that, then yes, I'd love to be able to somehow script the whole device driver install for NI-MAX. I now have theoretically identical systems scattered worldwide. Explaining NI-MAX to someone half a world away isn't my idea of fun, hehe.

You can "replicate" the software setup of a target back to itself (if for example the hard drive was corrupted). But not to other targets of the same type.

Upgrading to LV-RT 8.6 on one target and copying that to another target is not allowed.

N.

[Aristos Queue]

QUOTE (gmart @ Mar 18 2009, 07:20 PM)

In general, no. I was trying to cover my bases since it's possible that a library owns a class and such. In that case, loading a library would load VIs but only due to a class being a member of the library.

XControls (.xctl) are another kind of library that load all their member VIs. I do not know the behavior of StateCharts (.lvsc).

[Matthew Zaleski]

QUOTE (Neville D @ Mar 24 2009, 06:41 PM)

You can "replicate" the software setup of a target back to itself (if for example the hard drive was corrupted). But not to other targets of the same type.

Upgrading to LV-RT 8.6 on one target and copying that to another target is not allowed.

N.

That's unfortunate.

Does anyone know if the NI-MAX CD/DVD installer can be fully scripted to only install the drivers I know are needed and not ask the user any questions?

And can NI-MAX itself be driven by a LabVIEW app to do all of the necessary driver updates of a cRIO target?

I need a way of automating this. My users don't know, nor do they want to know, how to configure the gobs of settings needed to support a cRIO target. And as I mentioned before, these units are now deploying worldwide; I can't walk up to them to update the software.