Why do you not use projects? When to use them.

[JÞB]

I responded to a post about what mistakes novice LabVIEW developers commonly make.  One I feel is a common problem is not wrapping up closely coupled reuse code into projects that modularize code sections.

As examples there are nice Instrument drivers that contain all of the functionallity of a specific piece of test equipment.  Keeping these vis that work together in a single reusable project is quite helpful.  Other reusable pieces of code that are less related together might be more of a problem.  For example a "Delay.vi" and a subvi that calculates a CRC for your company's propriatary communications bus have little cohiesion.

Yet namespacing might suggest that those vis sort of go together.  Delay.vi on MyCorp.lvproj does change the problems Delay.vi from Mycorp has when YourCorp has another vi named "Delay.vi" and neither is in any sort of project.

The real issues seem to show up when we forget how each type of LabVIEW containers affect the "fully qualified name" of that peice of code asnd that the FQN effects what we really want...... I want my code to be protected from accidental change because I want to use that other code too!

That make sense.....Lets chat.

[tst]

The project does not provide namespacing, because it is not a container. You can think of it more as an execution sandbox, although being a sandbox is only one (relatively small, in my personal experience) reason to use a project. What you're thinking of is a project library.

In general, you would want to avoid having your entire reuse library in a single .lvlib, because as you said, there is no real connection between VIs which perform unrelated reuse functions. The obvious answer is to use VIPM - it automatically renames the VIs with whatever namespace you choose, so that each package can be completely separate.

Another alternative would be a packed library for each component, but that has its own set of problems.

[crossrulz]

As Tst said, Jeff just gave reasons for using library files.  But this thread is supposed to be about PROJECTS.

The most basic reason to use projects to organize your code in a single window.  You can see where your VIs are located on disk (if setup correctly), you can drag your VIs onto block diagrams, you can resolve conflicts (!!!).  You also need projects to build executables, installers, and code distributions.

The only time I do not use projects is for very small applications (5 VIs max).

[JÞB]

---

@tst wrote:

The project does not provide namespacing, because it is not a container. You can think of it more as an execution sandbox, although being a sandbox is only one (relatively small, in my personal experience) reason to use a project. What you're thinking of is a project library.

In general, you would want to avoid having your entire reuse library in a single .lvlib, because as you said, there is no real connection between VIs which perform unrelated reuse functions. The obvious answer is to use VIPM - it automatically renames the VIs with whatever namespace you choose, so that each package can be completely separate.

Another alternative would be a packed library for each component, but that has its own set of problems.

---

Exactly the points I wanted free discussion on!  Things I would point out.:

A  *.lvproj does in fact aid with grouping logically related functions and, does provide some namespacing.  That "On<target ,project> in the FQN is not known to the vi itself but can make a huge difference to the caller!  Lets use A TestStand proxy as an example caller and a UUTxxx.lvproj would be a common grouping of test steps, objects and methods that act to test functionality of "xxx" units.  Say we use a DAQmx device to test these units, create our DAQmx Task and persist it to UUTxxx.lvproj (yes we can do that, Task creation at run time should be avoided but that is another topic).  When calling the lvproject item from TestStand the proxy asks the project for the vi and its dependancies encluding any DAQmx tasks only that project knows about.  Quite powerful namespaceing can be achieved with a simple *.lvproj!

[crossrulz]

That's an interesting concept.  But it only applies to the TestStand world.  In a pure LabVIEW world (most of my development), this doesn't work.

---

Jeff·Þ·Bohrer wrote:Task creation at run time should be avoided but that is another topic

---

It is another topic, but I like creating DAQmx tasks at run time.  I define the tasks in an ini file, which makes editing and source control very easy.  But again, that's another topic.

[JÞB]

---

@crossrulz wrote:

That's an interesting concept.  But it only applies to the TestStand world.  In a pure LabVIEW world (most of my development), this doesn't work.

---

Jeff·Þ·Bohrer wrote:Task creation at run time should be avoided but that is another topic

---

It is another topic, but I like creating DAQmx tasks at run time.  I define the tasks in an ini file, which makes editing and source control very easy.  But again, that's another topic.

---

I define them in a xml file with a *.lvproj extension,  easier for deployment, editing is done by a wizard, source control is integrated

But back on point, I used a TestStand proxy as an example caller.  In a pure LabVIEW world I can open a vi named "Tree.vi" or "Initiallize.vi" from any number of projects at the same time.  There is no conflict.  without having the projects open and opening those vis from the projects LabVIEW lets you know you did something to confuse it.  there is no need to decorate vi names when the project is open!

Librarries take that namespacing a step further since the vis, (or ctls or globals or xcontrols) know they are members of the llb, lvlib or ppl.