NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Why TS searches the directories for LV modules called using relative paths?

Highlighted

According to the http://www.ni.com/white-paper/7559/en/#toc3 we read:

(...)When TestStand loads a code module that has been specified by a relative path, it starts looking for the file based on the search directory listings in the Edit Search Directories dialog box. (...)

So my question is why is that? Why TS needs to search for something what is unambiguously defined? Why searching directores mechanism is engaged in the calling the module? Should it not be changed?

0 Kudos
Message 1 of 20
(3,255 Views)

If you look into the (default) search directories, the first is "Current sequence file directory". So essentially, the first place to look for code modules is indeed the expected location (or "unambiguousl defined" as you call it).

 

But in certain situations, it might be suitable to change that perharps during runtime (e.g. depending on serial number of the UUT). So modification of search directories before looking for the module makes it more flexible.

 

Also, if the first location is not containing the correct module, maybe the other search directories do.... simply looking into a single location might be insufficient.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 20
(3,254 Views)

Hi Norbert,

 

I understand what you written, however I don't think it is a proper approach.

 

Basically, when I code something, I want the FIRST location to be ONLY ONE location for the VI. I don't know like others do but I think developers are using only one location for every VI with the same name.

 

Next, when I develop the solution I know where my VIs are and I don't want ANYTHING to search for it. However, I still would prefer using relative paths.

 

And last but not least. If the location doesn't contain correct module I expect the error to be thrown rather than relay on automation of finding something on the HDD which can coincidently have the same name.

 

Message 3 of 20
(3,249 Views)

What are you expecting your relative paths to be relative to? Perhaps you can configure your seach directories such that the only place where the vi would be found is relative to the sequence file (assuming that is what you are wanting, if not, please explain what path your relative paths are relative to).

 

Hope this helps,

-Doug

0 Kudos
Message 4 of 20
(3,228 Views)

To the position of caller which is the sequence file, of course. For me it is quite "natural" and obvious.

TS recognises the position of the sequence file as default, too.

 

For me is just not right to involve searching directories features to something which is unambiguously defined.

 

K.

0 Kudos
Message 5 of 20
(3,225 Views)

@MimiKLM wrote:

To the position of caller which is the sequence file, of course. For me it is quite "natural" and obvious.

TS recognises the position of the sequence file as default, too.

 

For me is just not right to involve searching directories features to something which is unambiguously defined.

 

K.



I argee, it seems that TestStand will only find a code module using a relative path IF the code file is directly down the heirarchy from one of your designated "search directories".  I find this a strange restriction. 

 

For example:

 

Lets say I have a code module sitting at C:/Documents/My Project/Code Files/Code I Want To Call.vi  and my sequence file is at C:/Documents/My Project/Sequence Files/My Sequence.seq.

 


I then use a relative path when calling the code file in a sequence step and save the sequence.

 

Another colleague then opens the same sequence file and he has his sequence file in the same location relative to the code file as I do.  TestStand will not be able to locate the code file UNLESS he has C:/Documents/My Project as one of his search directories.

 

I find this weird- LabVIEW itself doesnt have this problem.  I can specify a relative file path in a LabVIEW vi and as long as the path of that file is always the same relative to the vi calling it, there is no need for "search directories".

 

I don't see why TestStand cant behave the same way.  TestStand claims to be able to use relative file paths, but to me, if it needs to go to the search directory list to locate a file, that's not really using a relative path.

 



0 Kudos
Message 6 of 20
(3,213 Views)

@Garvacious wrote:

 

Another colleague then opens the same sequence file and he has his sequence file in the same location relative to the code file as I do.  TestStand will not be able to locate the code file UNLESS he has C:/Documents/My Project as one of his search directories.


 

Yes, I can confirm. If I remove the directory of the VI which is called using relative path TS cannot load the VI.

 

 


@Garvacious wrote:

I don't see why TestStand cant behave the same way.  TestStand claims to be able to use relative file paths, but to me, if it needs to go to the search directory list to locate a file, that's not really using a relative path.

 


Agree, it looks like in relaity calling VIs by reference path is just an empty statement.

0 Kudos
Message 7 of 20
(3,198 Views)

@Garvacious wrote:

@MimiKLM wrote:

To the position of caller which is the sequence file, of course. For me it is quite "natural" and obvious.

TS recognises the position of the sequence file as default, too.

 

For me is just not right to involve searching directories features to something which is unambiguously defined.

 

K.



I argee, it seems that TestStand will only find a code module using a relative path IF the code file is directly down the heirarchy from one of your designated "search directories".  I find this a strange restriction. 

 

For example:

 

Lets say I have a code module sitting at C:/Documents/My Project/Code Files/Code I Want To Call.vi  and my sequence file is at C:/Documents/My Project/Sequence Files/My Sequence.seq.

 


I then use a relative path when calling the code file in a sequence step and save the sequence.

 

Another colleague then opens the same sequence file and he has his sequence file in the same location relative to the code file as I do.  TestStand will not be able to locate the code file UNLESS he has C:/Documents/My Project as one of his search directories.

 

I find this weird- LabVIEW itself doesnt have this problem.  I can specify a relative file path in a LabVIEW vi and as long as the path of that file is always the same relative to the vi calling it, there is no need for "search directories".

 

I don't see why TestStand cant behave the same way.  TestStand claims to be able to use relative file paths, but to me, if it needs to go to the search directory list to locate a file, that's not really using a relative path.

 


If you specify your code modules as:

 

..\Code Files\Code I Want To Call.vi

 

Then you will get the behavior you are asking for because that path is relative to your sequence file.

 

Hope this helps,

-Doug

0 Kudos
Message 8 of 20
(3,188 Views)

@MimiKLM wrote:

To the position of caller which is the sequence file, of course. For me it is quite "natural" and obvious.

TS recognises the position of the sequence file as default, too.

 

For me is just not right to involve searching directories features to something which is unambiguously defined.

 

K.


The current sequence file directory is the first search directory by default, so if your code module exists there it will be found there. I'm not sure why the existence of other search directories would cause you any problems with this. If it is, please explain how in more detail.

 

As far as why the possibilities of other search directory options exist, not everyone wants to keep their code modules in the same subdirectories as their sequence files. Some people prefer to have them stored at a different location, yet still would like the paths in the sequence files to be relative so that they don't have to be changed when the root directory changes.

 

-Doug

0 Kudos
Message 9 of 20
(3,187 Views)

"If you specify your code modules as:

 

..\Code Files\Code I Want To Call.vi

 

Then you will get the behavior you are asking for because that path is relative to your sequence file."

 

 

-That only works if your code files folder is a child folder of your Sequence File folder, like:

 

Sequence File Directory\Code Files\Code I Want To Call.vi

 

...if your code is in a directory parallel to your sequence file directory, or in a completely different place on your hard drive, then that won't work.

 

 

So, I guess that relative paths DO work, but in a limited way.  Otherwise you must use the search directory method.

 

 

 



0 Kudos
Message 10 of 20
(3,179 Views)