NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

What are the advantages of using LabVIEW projects in TestStand, as apposed to just a path to a vi

What are the advantages of using LabVIEW projects in TestStand, as apposed to just a path to a vi ?

I am modifying an existing workspace for a new product, and it seems like more work to add the vi's into a LabVIEW project

 

does it gain anything in the long run

0 Kudos
Message 1 of 10
(6,493 Views)

The greatest gain is in Namespacing.  A Lot of LabVIEW Plug and Play (project style) drivers make use of this feature.  By having Projects for your LabVIEW code you can establish "common themes" for the functionallity you write.  Most instrument drivers have "Init.vi" and Close.vi" and since tey are in projects the LabVIEW RTE does not get confussed by them having the same name.  Projects can permit you to use common naming conventions for the various UUT's in the same way.

 

Another advantage to using projects is that it helps coordinate developers efforts by providing seperate namespaces for seperate code structures.  This is most often a major advantage in multi-developer situatons but, a good programmer will use this as well to enforce good design practices so that projects X and Y have specific purposes and therefore are scoped better for maintanence.    


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 10
(6,466 Views)

So I gather that you are saying that it may be necessary to have multiple LabVIEW projects in the same TestStand workspace in order to use vi's that have the same name but are different and in different projects (different device drivers etc.)

 

I thought it may have something to do with deployment and conflict resolution or even using the vi analyzer

 

Like I said before I am re-using a TestStand project for a new product, none of the vi's were in a LabVIEW project in the old TestStand project and I am trying to keep my development cost and time down

 

if I don't have issues with duplicate vi names (the old project seems to have worked fine (I did not develop it)), do I really need to do the extra work of putting all of the vi's in a project and then changing how the TestStand steps locate the vi's (100's of steps/vi's)

 

Is it considered bad style not to use the LabVIEW projects?

 

Message 3 of 10
(6,464 Views)

LabVIEW projects are a relatively new feature in LabVIEW that were introduced to provide specific benefits going forward.  (the ones I listed among them)

 

Style is not your only concern- development price seems a priority as well.  I do not know your business case so I can only offer that there are long term benefits for maintainance that projects offer and there are short term cost considerations for refactoring working code. 

 

(see, I copped out and won't give you a straight answer)


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 10
(6,460 Views)

Thanks Jeff

 

I am new with the company I work for, and will need to do it the way they want me to

 

 

0 Kudos
Message 5 of 10
(6,457 Views)

Glad to help-

 

Us est engineers need to stick together

 

P.S Kudos and "accepted solutions" are the forum prefered "Thanks"  They give the poster a sense of accomplishment but, more importantly, they set off valuable information for the community at large to aid others in finding pre-existing information.


"Should be" isn't "Is" -Jay
Message 6 of 10
(6,453 Views)

A couple things:

 

While projects (*.lvproj) are a good thing for organizing LabVIEW code they are not needed for a TestStand project if you do not have any duplicate code.  In fact, I found out that having the same named VIs just in projects is NOT enough for TestStand to deploy the same named VI to different locations during a build.  The deployment utility will still give errors indicating duplicate names.

 

It actually necessary to put VIs with the same name in separate *.lvlib ( LabVIEW project libraries ).  This gives TestStand the necessary namespace to resolve conflicts with VIs during the deployment.

 

Rusty, my suggestion would be to keep the project the same.  It is a lot of work adding all the VIs to different projects and then libraries.

 

Thanks,

 

PH

Message 7 of 10
(6,421 Views)

I talked with my associate were I work, and he told me that the reason for using the project was for the advantages that projects have for LabVIEW development, and not so much for TestStand

 

It turns out that if I use auto-populating folders in the LabVIEW project the vi's are in the project relatively easy, it's just a matter of changing the path that TestStand uses to find the vi's that is time consuming

 

I have found that  a find and replace can be used for vi's that are use more than once

 

it would be nice if TestStand could search for vi's in the project, but it does not seem to work that way

 

 

 

0 Kudos
Message 8 of 10
(6,417 Views)

Rusty,

 

You may want to make a product suggestion regarding this here:

 

http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/idb-p/teststandideas

 

Regards,

 

Kyle Mozdzyn

Applications Engineering

National Instruments

Regards,

Kyle M.
Applications Engineering
National Instruments
0 Kudos
Message 9 of 10
(6,398 Views)

Hi Rusty,

 

I wanted to quickly clarify on the integration between TestStand and LabVIEW Projects.

 

As Jeff mentioned, some of the big benefits of using LabVIEW Projects is to organize code and to namespace them.

 

For instance if you had a project called "Power Supply" that housed all your power supply code and had a VI in that called "Initialize", and another project called "Temperature Chamber" that also had a VI called "Initialize", both these VIs are namespaced by the project, so there is no longer confusion about which "Initialize" VI is being used.

 

 

Now from a TestStand point of view, in prior version of TestStand, we lost some of this benefit because TestStand did not know about TestStand projects and called VIs simply as un-namespaced VIs. However, in TestStand 2010 (released last year, free eval available at ni.com/teststand), we added the ability to (optionally) call VIs within the context of their projects. This means that:

  • VIs are now namespaced by their project, even when called from TestStand
  • VIs can use project specific constructs like NI-DAQmx tasks and conditional compilation settings

Note: When creating deployments, the VIs maintain their projects and namespacing, so this benefit holds true for deployments as well.

 

 

Additionally, someone had mentioned looking into using lvlibs to namespace your VIs for deployment. Two comments:

  • With TestStand 2010, this is no longer neccessary since the project itself namespaces the VIs
  • You might also want to look into LabVIEW Packed Project Libraries, which combined several VIs into a single file. Think of it as a DLL specific to LabVIEW that is as easy to call as normal LabVIEW VIs. TestStand 2010 can call VIs that are exposed by PPLs. In addition, the deployment utility can automatically pack your VIs into PPLs for deployment.

 

Hope this is helpful!

Jervin Justin
NI TestStand Product Manager
Message 10 of 10
(6,361 Views)