05-19-2011 01:34 PM - edited 05-19-2011 01:41 PM
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
05-21-2011 12:35 PM
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.
05-21-2011 01:14 PM
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?
05-21-2011 01:21 PM
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)
05-21-2011 02:06 PM
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.
05-24-2011 09:06 AM
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.
05-24-2011 09:37 AM
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
05-26-2011 10:28 AM
You may want to make a product suggestion regarding this here:
05-31-2011 03:18 PM
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:
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:
Hope this is helpful!