TestStand 4.1.1 vi search path

[Neurotikart]

    This is so low-level I'm almost embarassed to ask.  I'm using TestStand 4.1.1 over LabView 8.6, both of which are licensed as full development systems.

    In order for our organization to make better use of (non-NI or Labview) source control, we've created a common directory structure for several developers over several large TestStand/LabView projects.  This includes areas for "common VIs" that are reused across projects.  So I'm in the process of migrating a rather complex project into a new directory structure.  The sequences and VIs in question were working perfectly under TestStand 4.0/LabView 8.5 prior to this attempted migration.

   My test sequences (and sub-sequences) can't seem to find needed VIs, even though they exist in directories that are included in the search paths I configured.  (An annoying sub-problem is that TestStand appears to "hang" while the LabView interface underneath the TestStand window is prompting for a VI's location.  I have to click the LabView item in the Windows menu bar to get LabView "on top" and see what the problem is.)

   I've already added several paths to both the LabView and TestStand VI search paths, and I've even checked the "search subdirectories" box, but the items are not being found.  It's going to take weeks to lead TestStand and LabView by the nose to find all this stuff.

   I can't believe this would really be a bug.  I tried searching the forums for an answer and had no luck.  I can't be the first one with such a problem, so help me out with some search terms so I don't have to clutter the forum with such basic stuff.  Thanks.

-M

[trosier]

I am doing the same exact thing as Neurotika. I am at the point that I tested putting in the exact path of the VI that TestStand could not find in the search directories options. TestStand could still not find the VI.

[Josh_W]

trosier, Neurotika,

It appears as if LabVIEW is having trouble finding your VIs, not TestStand.  When TestStand loads the VI you have designated as a code module into memory, if you have the LabVIEW development environment designated in the LabVIEW adapter settings, we tell LabVIEW to load the VI via its ActiveX interface. 

If TestStand is unable to find the top-level VI, you will see a dialog like this:

If LabVIEW is unable to find a sub-VI, you will see a dialog like this:

Notice that the TestStand dialog has an additional checkbox at the bottom that allows you to select an absolute path.  Also notice that TestStand specifies what file its looking for in the Files of Type box while LabVIEW allows you to choose All LabVIEW Files. Which dialog are you seeing?

Another way to test this is to try to open one of your VIs from disk (by double-clicking on it).  If you get a Searching for SubVIs dialog, then it is LabVIEW that can not find the dependencies. 

Or if you open the specify module pane of the sequence editor, if TestStand cannot find the top-level VI, you will see a file not found warning like this: 

 

If TestStand can find the file, but LabVIEW cannot find a sub-VI, then you will not get a warning or error until the VI is loaded.

The reason that this matters is that TestStand and LabVIEW do not share their search directory lists.  If you have moved files, you will need to know which application cannot find its files. 

Message Edited by Josh W. on 04-23-2009 11:27 AM

[Josh_W]

One other thing:

You should try mass compiling your VIs as a troubleshooting step.  After a successful mass compile, LabVIEW should be able to find all VI dependencies. 

When you mass compile, make sure your VIs are not read only, as this prevents the mass compile tool from resaving them.

[trosier]

OK folks here goes one more time...

I have the search paths for Labview and TestStand setup exactly the same. All of our VIs and sequences are in a common directory structure to be shared among developers. The problem I am having IS that TestStand cannot find the top level VIs regardless of the search paths. There are times when it does this and I browse for the VI, the browse dialog opens to the directory in which the VI resides. I select it and then all is fine. Why couldn't it find it by itself?

I ran a couple of scenarios to prove my point that TestStand is not finding the VI and will not until I manually find it and save the sequence.

1) I have a step that I selected and, like most after the directory restructuring, in the Module tab for that step it states: File Not Found.

2) I then open up that VI in Labview, not Test Stand, and Labview found all dependencies and recompiled with the new saved path. I did not save but went back to TestStand, clicked off the step then back on. The VI still could not be found.

3) I again opened up the VI in Labview, not Test Stand, and left Labview find all depenencoes again and this time I saved the VI. Went back to TestStand, clicked off the step and back on. The top level VI still could not be found.

I guarentee that if I browse from TestStand and load the VI which Labview already knows about then it will be fine.

The is completely unacceptable and is leading me, as the team lead for our automation deleopment team, to start evaluating the value added by using TestStand. This has been happening since I started using it thinking how nice it would be to use TestStand and not have to develop test executives. I consider our sequences above novice level however I am sure there are ones out there that are very complicated in comparison. I could not imagine making the directory structure change that we did, which was to help us all, and having to go through a complex sequence step by step and telling TestStand where all of the top level VIs are. My management is getting a little impatient on how long this merge is taking and is forcing me to rethink continuing our use of TestStand. By the time I get all of these steps reconfigured I could write a test executive.

Why can this not work like Labview does, which I think has the process down pat? You set up search directories. TestStand finds the top level VIs and then gives the user a warning that the VI was not found in the saved location. The user will then have to decide if that is the correct location, VI, etc. In our case I would know the reason for the new path and move on with my day. If someone has a doubt and maybe has a duplicate named VI then they will have to resolve that issue and learn to live by the rule that you should not have duplicate filenames for VI modules. At this point I am just not seeing what value of having the search directories setup in TestStand buys us.

[trosier]

OK folks here goes one more time...

Forgot the spell checking, below it is corrected...

I have the search paths for Labview and TestStand setup exactly the same. All of our VIs and sequences are in a common directory structure to be shared among developers. The problem I am having IS that TestStand cannot find the top level VIs regardless of the search paths. There are times when it does this and I browse for the VI, the browse dialog opens to the directory in which the VI resides. I select it and then all is fine. Why couldn't it find it by itself?

I ran a couple of scenarios to prove my point that TestStand is not finding the VI and will not until I manually find it and save the sequence.

1) I have a step that I selected and, like most after the directory restructuring, in the Module tab for that step it states: File Not Found.

2) I then open up that VI in Labview, not Test Stand, and Labview found all dependencies and recompiled with the new saved path. I did not save but went back to TestStand, clicked off the step then back on. The VI still could not be found.

3) I again opened up the VI in Labview, not Test Stand, and left Labview find all dependencies again and this time I saved the VI. Went back to TestStand, clicked off the step and back on. The top level VI still could not be found.

I guarantee that if I browse from TestStand and load the VI which Labview already knows about then it will be fine.

The is completely unacceptable and is leading me, as the team lead for our automation development team, to start evaluating the value added by using TestStand. This has been happening since I started using it thinking how nice it would be to use TestStand and not have to develop test executives. I consider our sequences above novice level however I am sure there are ones out there that are very complicated in comparison. I could not imagine making the directory structure change that we did, which was to help us all, and having to go through a complex sequence step by step and telling TestStand where all of the top level VIs are. My management is getting a little impatient on how long this merge is taking and is forcing me to rethink continuing our use of TestStand. By the time I get all of these steps reconfigured I could write a test executive.

Why can this not work like Labview does, which I think has the process down pat? You set up search directories. TestStand finds the top level VIs and then gives the user a warning that the VI was not found in the saved location. The user will then have to decide if that is the correct location, VI, etc. In our case I would know the reason for the new path and move on with my day. If someone has a doubt and maybe has a duplicate named VI then they will have to resolve that issue and learn to live by the rule that you should not have duplicate filenames for VI modules. At this point I am just not seeing what value of having the search directories setup in TestStand buys us.

[Josh_W]

trosier,

I'm sorry that you're having so much trouble with migrating your directory structure.

If you give us permission, I'll have the forum administrator pull your e-mail from your forum ID so that we can contact you directly about this issue.

[trosier]

We will in the future have other sequence files that will need their directory structure remapped just lakie my current one. I have finished that one and took a total of about 6 hours to do. This is one of our shorter sequences. You may pull my e-mail if that is the route you want to take to help resolve the issue.

[Krunal_K_Patel]

Hello Trosier and Josh.W

Any updates on the problems faced, is it resolved?

Kindly post the solution to this thread if you are there.

Regards,

Krunal K Patel

Captronic Systems Pvt. Ltd.

Bangalore, India

[trosier]

No solution is in place yet.