Station Globals editor for run-time deployment?

[Station3]

Hi, folks.  Has anyone coded in Labview a stand-alone Station Globals editor that can run successfully on a test station with Teststand base deployment (run-time only)?

Thanks very much.   -Joe

(I'm running TS 2014 SP1 f1 and LV 2015 SP1 on Windows 7.)

[~jiggawax~]

I think the entire point of Station Globals is that they should never change.  My personal preference is that you never use Statioin Globals.  I have yet to see a situation that warrants them.

That being said....

You could try opening the sequence editor on a deployment machine and see if it will even allow you to do so with the deployment license.  My guess is No but I haven't ever dealt with that.  This way you aren't chasing down the rabit hole if the license won't even allow it.

[Station3]

Hey jigg, that's an interesting take, that Station Globals should never change and that you should never use them.  I like the separation of test-sequence-specific settings (File Globals saved within the seq file) and station-specific settings saved in Teststand's app config folder.  That separation comes in handy in my mass-production situation, and my station configurations do change on occasion.  But yah Station Globals are sure a pain to use.

If no one has a stand-alone VI that allows editing of Station Globals in a run-time deployment, then I should ask, does anyone know if it's possible for me to code one?  There are many editor functions that can be done in Labview through the Teststand API in run-time.  I tried using the VariablesView control and the TS Engine.CommitGlobalsToDisk function.  I could not get the VariablesView to allow changing values - I can only read them.  And calling CommitGlobalsToDisk causes an instability where I get a pop-up saying that references were left open.

Thanks.   -Joe

[~jiggawax~]

Do you just want to edit the values?  If so then there's a chance you would need to create something.  I've attached a very simple crude way to do this.

Hope this helps,

[warren_scott]

If you are just looking at modifying a few determinstic simple StationGlobals.* variables it's very doable.  If you're looking at an arbitrary editor of any/all variable of any/all structures possible (arrays of typedefs of typedefs of arrays, etc) then it is still doable but I would guess not worth your effort.

For the first part (editing a few specific known simple quantities, like a string or boolean or number, or even a specific string value in a typedef container) you can create a LabVIEW UI to do this. 

There are 2 basic ways to do it.  One is to pass the values in/out as inputs/outputs to the VI (like assigning StationGlobals.MyBoolean to the input and output of an item) and then call this VI in a subsequence that is called by a customized tools menu, or add the subsequence as a configuration entry point in your process model.  Either way make sure after calling the VI you call the TS engine to commit the SG to disk.

The other way is to just pass SequenceContext into your VI, and then use SequenceContext to reference in to read/write the specific StationGlobals.* variable values based on what the user is doing.  All the reads are done in an initialization step for the UI, and the writes in the "exit" step (and then wrap that VI in a subsequence just like above).

Neither of these gives you full edit ability to StationGlobals on the runtime station, but allows you to selectively edit chosen items.  To some extent that is better because it restricts the users on the runtime stations to only be able to edit what you want them to be able to change, and you can do some value verification on the user input.

[Station3]

Jigg, Warren,
Thanks for the advice and ideas. Jigg, thanks for the sample sequence. I understand now the different ways to change StationGlobals in a run-time installation, and yes I can see the difficulties in making a general tool to edit the variables, especially variables of different data types and array & container structures (which we use here at my company).

My group met on this subject and decided to stop using StationGlobals, to general applause and head nodding. We'll use FileGlobals instead. For those FileGlobals that are station-specific, we've put a Property Loader step in the ProcessSetup callback to set those variables from a text file upon test start-up.

-Joe

[~jiggawax~]

What version of TestStand are you using?  I 2016 they redid the property loader so it should be a lot better.