Station Globals Are Not Showing Up In Deployment

[trosier]

I have a deployment I have built and included the TestStand.cfg file in my WorkSpace and have the StationGlobals.ini selected in the Deployment Utility. It appears to be the correct destination path. In fact when I check the path on the deployment machine the SationGlobals.ini file is there. It is the only one on the machine. However when I run the TestExec with my sequence file the station Global variables are not populated. This of course causes a runtime error as expected. What am I doing wrong with trying to include my station globals with my deployment?

Thanks in advance for any help with this.

Troy

[~jiggawax~]

StationGlobals.ini will get created if it doesn't exist.  So the fact that it is there doesn't mean that you put it there.  If you open it up in notepad or an ascii editor can you see that your expected variables are in there?  If not then chances are it isn't the one you deployed.

Also, you can look at the timestamp.

Also, you can generate the globals dynamically in your code to avoid the error.

Also, you shouldn't use station globals.. 🙂 personal preference.

Also, you can look at where your cfg folder is pointed to in Station Options.

Hope this helps,

[trosier]

OK I got it working actually a few days ago. You can't just deploy the Station Globals from the .../cfg directory. You have to deploy other files from that directory as well. The only thing that I have to be cognizant of is the LabVIEW adapter that I am using as the TextExec.ini grabs that from your development suite according to what you are using. I do not have Labview on my deployment machine. So by default the deployment machine is looking for the Labview Development system when starting the TestStand Test Executive. My work around for that is to set my development Labview adapter to the Labview Runtime Engine, build, then set it back to the development system. Or leave it on my development machine and set it correctly on the deployment machine after installing the deployment. I tried not including the TestExec.ini after having it set correctly after the first time the deployment is installed. If one is not included in the deployment one is created which overwrites what was previously in there for the adapter. Unless someone knows of a better way to handle this it is working fine keeping the correct adapter in mind whether it gets switched on the development machine or after the deployment is installed. Thanks for all the help.

[~jiggawax~]

One thing you can do is set all your configuration up the way you want to see it on the deployment bench.  Then go make a copy of your Cfg folder.  Then when you deploy, deploy the copy of the Cfg folder.  Not the actual Cfg folder. This way you can do whatever you'd like on the development but always build with the default deployment settings.

This is how we do it and it works wonderfully.

Regards,

[trosier]

Jigg - That is a good idea. OK so lets say I copy my .../cfg folder to .../cfg_d for deployment. I know I can get that into my deployment via the Deployment Utility. I would then have to tell the Utility that this is the .../cfg folder for the deployment image. Is that how it is done? I haven't done that before so I just want to make sure I have the process correct.

Thanks for your help.

Troy

[~jiggawax~]

Add cfg_d to your workspace and then it will show up in the deployment utility as files.  Then you can just use the TestStand Application Data Directory as the Installation Destination and make the subdirectory Cfg.

I've attached a screenshot.  You can also uncheck cfg files you don't want to deploy such as the Deployment Utility ini files.

Hope this helps,

[trosier]

Jigg - Yep I was aware of how to get the "new" ...cfg_d directory in there and selected I was just wanting it to be clear on how to make sure it went to the correct place. Awesome, this will work just fine. Thanks again for the help.

On a personal note I love to grill and would offer you the BBQ however I would bet that chances are we are not within driving distance of each other so I will give the Kuddo. 

Troy