Using a process model and configuration NOT in the standard directory

[SimpleJack]

Hi all,

I know I have touched on this before but never really resolved the issue.

I have this love/hate relationship with TestStand. I love using it in development mode....but when it comes to building an installer....I truly hate it.

Here is my problem...

I work in Manufacturing where I need to create installers for my distributions. It keeps everything clean, and nobody has the cash to purchase a full development system for each machine. The problem is that no distribution is the same....models are different and so are globals. When I develop I create a folder where I keep my new process model and my CFG folder. This works fine in development, everything is located because I can specify the path to the model and the CFG folder in Station Options.

When it comes time to build the installer, and when installed, it seems my CFG file and process model are not located. The application will go right to the main sequence (instead of the model first) then tell me that it cant find my globals. The only way around this is to move the model back to the default Teststand directory and same goes for the CFG file.

The question I ask is why, if I specify these directories in Teststand, does it not carry over to the installer? And secondly, how do I get it to identify the correct path. This is very frustrating. What am I doing wrong?

Labview 9

TestStand 4.2

Thanks,

Ryan

[~jiggawax~]

Ryan,

Station Globals are bad.  Never use them.  However, assuming that you did use them then you will find them in an ini file.  You have to deploy that ini file.  That file can be found in the Cfg folder inside your TestStand folder.  It should be named StationGlobals.ini.  Since we are on the subject all of your ini files are located in that folder.  One of them, TestExec.ini, contains your search paths.  These are important because they tell TestStand where to find things.  You need to set those up correctly for your deployment computer and deploy those with your installer.  In fact in the TestStand Deployment Utility there is a checkbox which allows you to deploy the public directories.  That is where the ini files are stored.  So look for the checkbox with From TestStand Public Directories.  Be careful though because now the deployment pc will be setup just like the dev machine.  Including users.ini.

The other thing you can do is include these in your workspace and then just make sure you put them where they belong one by one when you set the distributed files from the TestStand Deployment Utility.

Also, if you have customized the process model you will have to include the new one in your workspace when you deploy.  Then you will have to make sure that the TestExec.ini includes the search directory for where the new process model will be located on the deployment machine.  To change it simply go to Configure>>Search Directories either from the sequence editor or the UI.  Then change the paths to include all necessary paths.  I believe you have to be an admin for that.

Deployment can be a pain if you haven't done it a lot.  I've found a couple tips that make my life a whole lot easier.

- Create a baseline installer.  This can include all your ini files, drivers, runtime engines, process models, User Interfaces, etc... Basically anything that is common accross the board.  Install this first on the deployment machine.  Don't include your test or VIs.  Then when you deploy your test all you need is the sequence and immediate dependancies.  Build time is dramatically shorter.

- Search Directories are the key to a successful deployment.  I find it nice to create a folder for my specific test (let's say MyTest).  Directly in MyTest I place my main sequence file.  Then all dependancies (vis, dlls, etc.) go in folders inside of MyTest.  Then all you need is for your search directories to contain Current Sequence File and check the search subdirectory option.  If it doesn't make sense to put it there (like a customized process model) then put it in the TestStand folder.  Those are always included in your search directories.  Then instruct users to only have one sequence file open at a time.

The reason Station Globals are a bad idea is because lets say you have multiple developers deploying to a station and they accidentally named a station global the same thing (i.e. MyVISASession).  Then sequence files are constantly fighting over it.  Not good man.  I find the best thing to do is create my own ini file and write my configuration settings out to that.  Then I can keep that ini file in the MyTest folder (see above).  Then when my test runs it reads those in from that ini file and populates FileGlobals (which don't get tromped on by others).

Hopefully this helps some.

[SimpleJack]

Jiggawax,

First of all I would like to thank you for putting this response together....I really appreciate it. This information helps emensely. Unlike Labview, there seems to be no books out there for TestStand. When it comes to Labview, I have no issues with creating an installer...piece of cake.

I have some questions though.....

1. I know Station Globals are bad...however, I need a way to pass variables from the process model to the main sequence. Is there an alternative?

2. You mentioned an .ini file to create the globals when the sequence is ran. Does this mean you do use globals but just create them this way or do you avoid them all together? Also, do you have a sample .ini file that I could look at. How do you insert it into the sequence so it creates the globals?

3. A baseline installer is genius. Never thought of that....great idea.

4. I will take all your suggestions to figure out my problem. I think I should be able to correct it. However, I am up for getting rid of the globals if there is a way to send variables from model to main sequence.

Thanks,

Ryan

[~jiggawax~]

Ryan,

I didn't realize that's why you were using Station Globals.  I find that most people use them to store config settings such as instrument addresses and variable settings.  However, that being said I still believe that Station Globals are a bad idea.  Of course this is my own personal preference.  Sometimes they are just easier and make development quicker.  There is probably a better way to get information from your process model to your sequence file and vice versa.  In general this is done through callbacks and the parameters passed to and from those callbacks.  It kinda depends on what you are doing.  If you could explain the situation a little more I could offer suggestions.  Otherwise, I generally find that you can use a callback or something like that to get the trick done.  Please note that it is not recommended to modify the process model such that it is strongly linked to a sequence file.  i.e. every sequence that you "throw" at a process model should be able to run.  This is a general rule of thumb and fortunately TestStand is so customizable that we can do tricky things to get desired behavior.  So in some cases it is ok to do this.

Regarding number 2 on your list.  If you understand object oriented programming and realize that TestStand is built on objects and classes then I should point out that everything (ok most things) in TS inherits from the Property Object class.  One of the methods of that class is Write.  You can read about it in the TS help.  So what I do is set up a data type with all the config settings that I need.  Then I put a step in my sequence with a call to that Write method.  So lets say I had a Data Type with 4 VISA  resources, 3 numbers and string.  Then in my sequence file I create a fileglobal called MyConfigSettings.  Then in the step I would put something like FileGlobals.MyConfigSettings.Write().  Then I just run that step.  What this does is create what's called a property object file.  You can also read about those in the TS help.  Then I skip that step because I don't want to write it during runtime every pass.  Then I add a step with something like FileGlobals.MyConfigSetting.Read().  This will read the property object file (an ini file except I give it the txt extension) and populate my FileGlobal with whatever is in that file.  Now in my process model I can add a Configuration Entry point with a VI that pops up.  Users can then select values and click Save Settings.  This will then come back to TestStand and I will have a step in there that will write the file with the new settings.  The file will retain values and users will only have to do it once whenever they change out an instrument or need to change certain settings.  Everytime they run my sequence file it reads in the settings and populates the fileglobals which are then accessible by anything in my sequence file.  I attached a simple example using a Person object.  See if you can figure it out.  Let me know if you have any questions.

Hope this helps some,

[Teds]

Hi everyone,

Where's the love for StationGlobals?  They have worked well where I work, but again my situation may be different.  We have 5+ functional test system that are contain almost the same hardware.  We use StationGlobals to setup the hardware configuration ( GPIB Addresses, Switch Names & Topology, any other hardware configurations ). 

I like them for the following reasons:

1.) The developer of a test sequence does not have to worry about these settings or keep an external file for use in their program.

2.) StationGlobals are easily accessible from expressions and the connector pane.  For example,   just type 'StationGlobals.DCPS1.GPIBAddress' to use the value in the connector pane to for our DCPS1 to initialize your VI.  Again, I don't have to worry about what the value actually is.

3.) If any of the values change, you ONLY have to change the StationGlobals INI file, not every single INI file for specific programs.  It is a hassle where I work to go through the process of releasing updated software, especially only if an INI file changed.

Other comments:

1.) We keep the names specific to the hardware:  We have DCPS1.GPIBAddress, DCPS2... etc.. then ACPS1.GPIBAddress etc....   I would recommend setting a naming convention that is agreeable to all developers.   We have had systems where we have multiple switch cards of the same type, example: NPXI2569, so in that case we setup NIPXI2569_1 and NIPXI2569_2 as stationglobals.

2.) The configuration and maintenance of StationGlobals is kept up in the Operator Interface application, I have a tool where I can automatically write the stationglobals file based on a INI file of set values.  Hence on new systems I don't have to manually setup the INI file via the sequence editor.

Again we less than 10 test engineering, so coordinating this effort is not a major ordeal. 

StationGlobals = Good.

Thanks,

PH

[~jiggawax~]

Sorry Teds but you're wrong.... 😉  Ok not wrong but I just disagree.  It's all opinion so how can you really be wrong.

IMHO- Station Globals are a lazy way to program and maintain that program.  What you've explained is exactly how most people use them.  But guess what- now your sequence will only run on a machine with those station globals set up.  It's no longer an independant test.

That being said they are obviously there for a reason.  So I guess they have a use case somewhere. I have yet to find it.

The beautiful thing about TestStand is that there are thousands of ways to use it.  Everyone can find a way to make it work for them.  Honestly when it comes down to it I think that whatever works for you is the best way to use it.  I love debate more than I really care about using station globals.

I guess one of my other main hesitations is that I've seen too many people abuse station globals.  Both in TestStand and in LabVIEW.  And the worst is when they combine them both and have a massive test that depends on both.  ugh!!

[SimpleJack]

Jigg,

I use teststand to program and test 16 PCBA's at a time using a clamshell fixture.

I have a text file called comm.txt that my process model parses (using a VI) to set a station global array of 16 comport values. I then have anothe VI in the process model that generates and assigns serial numbers to each of these 16 boards. I need the serial numbers assigned in the process model because I need the logfile serialized from the beginning.

I will check out your example and see if I follow. Thanks for the example. I havent had a chance to try the other recommendations yet, but I will let you know.

[~jiggawax~]

Sounds like you should probably use Callbacks to accomplish what you want.

Here is info on them:

http://digital.ni.com/public.nsf/allkb/E9BA6B7ABE026D7086256FD4005C0F7A

http://zone.ni.com/devzone/cda/tut/p/id/6605

http://zone.ni.com/devzone/cda/tut/p/id/2694

Also, this will eliminate having to deploy a customized process model.  There are also some examples in the example folder that demonstrate callbacks: C:\Program Files\National Instruments\<TestStand>  Then click on TestStand Examples>>Callbacks.

Although in your case not sure what "logfile serialize" means but maybe it is necessary for you to modify the Process Model.  Probably can be accomplished by overriding the PreUUT callback which there is an example of in the example folder.

Good Luck!

[CoastalLabVIEWER]

Rather than make a new thread I thought I'd ask my question here as I think it is related.

Is the process model explicitly or implicitly linked during a deployment/build?  We inherited some LabVIEW based code that uses Test Stand and there are tons of files in the build and either I wasn't patient enough and overlooked where the process model was linked or it is done in some other fashion.

[~jiggawax~]

---

@CoastalLabVIEWER wrote:

Rather than make a new thread I thought I'd ask my question here as I think it is related.

Is the process model explicitly or implicitly linked during a deployment/build?  We inherited some LabVIEW based code that uses Test Stand and there are tons of files in the build and either I wasn't patient enough and overlooked where the process model was linked or it is done in some other fashion.

---

I'm not quite sure what you are asking.  Are you asking if the sequence file containing your test is linked to the process model?  Or are you asking if your VIs are linked to the process model?  Or if the VIs are linked to your sequence file?

If it is about your sequence file containing your test (referred to as a client file) being linked to the process model then there are several ways that can occur. 

Option 1 - If you open a client file and don't change anything it automatically uses the Station Model.  The station model is defined in your Configure>>Station Options>>Model tab.  Out of the box it is SequentialModel.seq.  If it is linked through the station model then you need to also include your station options configuration file in your deployment along with the process model and all of its dependencies called out there.

Option 2 - You can explicitly link your client file to a process model by going to the sequence file properties and changing which model it uses.  If you do this then you need to include that model and all of its dependencies in your deployment. 

Hope this helps,