Specify a process model with a relative path

[MichaelAivaliotis]

I specify a model to use from the sequence file properties. The only 2 options I have when specifying a custom process model is:

- Add this folder to the search paths.
- Make it an absolute path reference.

I don't have the option of adding it as a relative path. How can I do this?

[RayFarmer]

Hi Michael,

If you dont enable Absolute Path, then it will be treated as relative.

Regards

Ray Farmer

[MichaelAivaliotis]

Cool, thanks. The reason why I didn't assume this was that TestStand "usually" pops-up a dialog with questions to this effect. It seemed inconsistent, thus the confusion.

Anyway, now I understand. Thanks again.

[Adam B.]

Hi Michael,

I just wanted to clarify why you are seeing two different set of options.  You usually get the dialog with three choices (Add to search directory, Absolute, or Relative) because there is a path between one of the existing search directories and the file for which you are specifying.  However, if there is not a path between a current search directory and your file, you will either have to use the absolute path (which is not recommended) or add the directory to search directories to ensure that there is a path between your file and a search directory.  Depending on your particular situation, it may be best to cancel out from said dialog, open up the Search Directories (Configure >> Search Directories...) and add a directory that makes sense (e.g. If the file you are are specifying is in C:\Projects\ThisProject and you add it to the search directory, then your search directories will then have that exact path.  If you then add a file from C:\Projects\AnotherProject, then you will still not have a path to this file from your search directory.  It probably would have been best to simply add C:\Projects to your search directory).  Hope this clears some more things up for you.  Thanks and have a great day.

[MichaelAivaliotis]

Ok, this clears up everything. Unfortunatly, my preference is to NOT add a search path into the TestStand search paths config. The default: "current sequence file directory" search path is all I want. I want to minimize edits to the Test Stations configuration. I want to have the process model in a directory parallel to the sequence file and just have the sequence file find it. We use Perforce and rely on that for getting files to the test stations. Each user on the Test Station has their own workspace directory named any way they chose. The user launching the sequence file need not worry about the process model. Also, I don't want to put the custom process model in the Teststand\components directory because then it is out of source code control.

Any suggestions?

Message Edited by Michael Aivaliotis on 02-13-2006 05:08 PM

[MichaelAivaliotis]

Well, after some experimentation, it seems I cannot get what I want. In the end, I ended up defining a standard Perforce folder on each machine which is designated for deployment of new versions. I added this to the search path of every Test Station.

[mhousel]

---

@Michael Aivaliotis wrote:
Well, after some experimentation, it seems I cannot get what I want. In the end, I ended up defining a standard Perforce folder on each machine which is designated for deployment of new versions. I added this to the search path of every Test Station.

---

I guess if a "Proven Active Veteran" can't make it work then a village idiot like me is pretty well hosed

What I want to do and have found no way to do yet is:

1) Use the customized process model that exists at Path_A within the directory tree that contains my Labwindows/CVI code and TestStand sequence files and my customized Process Model sequence file.
This is my normal development environment on a system with a full development version of Labwindows/CVI, TestStand, LabVIEW, etc.
This all works perfectly well on my development system.

2) Deploy that on another machine that Path_A does NOT exist on in a location within Path_B (e.g. C:/Program Files/..). that I specify in the deplyoment.
This system will have a deployment verison of TestStand and the CVI runtime libraries necessary.

3) Launch the sequence file from within Path_B and access CVI code in my .dll in that tree.  This works sometimes, on some computers.  It seems inconsistent.

4) Have my sequence running from Path_B use the customized Prosess Model sequence also deployed within Path_B

This seems to be an utterly obvious scenario that I've found no way to accomplish WRT the process model. 
Is this actually a purposely designed limitation of TestStand??  Or, am I missing something obvious??

Thanks

[nickb]

Hello mhousel,

If the custom process model that you have created is located in a directory or subdirectory of a search path on your development machine, and if you specify it to be a relative path when you select it as described above, it should find and use the customized process model when it is moved to Path_B.  Is your experience different than this when following these steps?  The running of your C .dll functions should also behave in the same manner.  If your code is located in a folder or subfolder of a search path, and you select the use of a relative path when prompted, it should find and run the CVI code regardless of computer it is installed to.When you say that the CVI code sometimes does not work on some computers, what type of failure are you seeing? 

NickB
National Instruments
Applications Engineering

[mhousel]

---

@nickb wrote:
Hello mhousel,

If the custom process model that you have created is located in a directory or subdirectory of a search path on your development machine, and if you specify it to be a relative path when you select it as described above, it should find and use the customized process model when it is moved to Path_B.  Is your experience different than this when following these steps?  The running of your C .dll functions should also behave in the same manner.  If your code is located in a folder or subfolder of a search path, and you select the use of a relative path when prompted, it should find and run the CVI code regardless of computer it is installed to.When you say that the CVI code sometimes does not work on some computers, what type of failure are you seeing? 

NickB
National Instruments
Applications Engineering

---

Nick,

I called today and spoke with a gentleman by the name of Jett who gave me some solutions that worked around the problem.

In trying to figure out what the problem was I was not getting the dialog that allowed me to select relative paths.  When I selected the DLL for actioins in my sequence and the custom process model to call, I simply browsed to the file and selected it without selectiting the 'absolute path' checkbox in the File Open dialog.

And than it put the file name in the module field and showed the full path to the file in the greyed out field below it.  Jett seemed perplexed by the lack of this 'relative path' dialog everyone talks about.

I have seen this dialog before but the choices didn't seem to make any sense to me a the path was always relative to the file I was choosing??.

Jett's solution for the custom Process Model was a sequence configuration that I was unaware of.

The problem with the DLL always being called from my development path was one of configuring the search paths more carefully and placing everything in one bucket, rather than using the directory structure of my development environment for deployment.

I know enough now to fiddle with the search paths to likely make the other directory structure work, but it DOES NOT come automatically by any mechanism I've found.  It always involved opening the TX after the deployment and manually changing the search paths.  Not very elegant.
Also, by default the search paths to my development seem to always be first in line unless I manually re-configure them.

If the development path doesn't exist, it prompts me to look for the files and that fixes up the search paths, but again it's not elegant or automatic for someone that doesn't know how to do these things or why it just doesn't work straight away after running the installer.