StationGlobals Shared Between Multiple Engine Instances

[bienieck]

StationGlobals are shared by all instances of the TestStand engine within a single TestStand environment (typically a global environment). So I can run several independent TestStand engine instances and exchange information between them via StationGlobals.

I would like to know the opinion of more experienced people on whether the use of this feature can be considered a bad practice, and if not, what would you justify that it might be a good idea after all.

Also, I would like to understand why the StationGlobals.TS.LastUserName is not shared by all instances of the engine. If I log in as user A in the first instance of the engine and call Engine.CommitGlobalsToDisk(), the LastUserName of the second engine instance does not change but still shows the user used in the second instance. The behavior seems reasonable but somehow deviates from the way it should work (or as I understand it).

[~jiggawax~]

I'm a huge proponent of not using Station Globals for anything.   In general it creates laziness and bad habits and developers misuse it causing race conditions and other bad things to happen.  That being said I get that people feel the need to use them.  So here is my list of dos and donts:

• Station Globals should only be used in a set once, read many setting.  Use queues or notifications to share dynamic or asynchronous data if absolutely necessary.
• Using an "*" at the beginning of a queue, notifier, semaphore, rendezvous, etc. name will make it global to all instances of TestStand on that station.
• Never directly call a Station Global inside of a Blue (Cyan or normal) sequence.  Any data should be passed in and out via parameters.  I would also argue this holds true for File Globals
• If there is a datatype or information about a specific test run, do not store it at the station global level.  Instead consider passing it as parameters.  The problem with storing at the Station Global level is that now you've forced everyone on the station to see, and potentially conflict, with your needs.
• Look into Temporary Globals.  They are created on the fly and for that instance of the engine.https://forums.ni.com/t5/Example-Code/Using-TestStand-Temporary-Globals-Engine-TemporaryGlobals/ta-p....

As for the user manager stuff in station globals I think NI treats it differently.  But that is an interesting observation you've made there.

Hope this helps,

[bienieck]

---

@~jiggawax~ wrote:

I'm a huge proponent of not using Station Globals for anything. 

---

That's what I thought 😄

---

@~jiggawax~ wrote:

• Using an "*" at the beginning of a queue, notifier, semaphore, rendezvous, etc. name will make it global to all instances of TestStand on that station.

---

This is a good hint!

---

@~jiggawax~ wrote:

As for the user manager stuff in station globals I think NI treats it differently.  But that is an interesting observation you've made there.

---

I double-checked that, and the problem is that StationGlobals (including StationGlobals.TS.LastUserName) are automatically committed only during engine shutdown. So, when using StationGlobals with multiple engine instances, you might have a hard time dealing with file conflicts. Just try to open multiple instances (and log in with different logins) and close some of them. You will see dirty dots everywhere, and I'm almost certain that in the end, you will see this:

So, I think you might at one more bullet point to the list: Avoid using StationGlobals when using multiple instances of the TS engine simultaneously. 

[stefanha]

While I completely agree that using StationGlobals when using multiple instances of TS engine at the same time should be avoided, I want to point out that there is this method, which does save the StationGlobals during runtime:

Runstate.Engine.CommitGlobalsToDisk

We have cases where one instances of TS engine is opened in SeqEdit and another one in an TestStand OI, where this is useful to avoid the dialog you mentioned.

On a side node, we also use this method to make sure the value of a "total number of tested parts on this machine" counter, which is stored in a StationGlobal, is somewhat reliable, even if the TestStand application is taskkilled (where the StationGlobals would not be saved to the ini file).

[bienieck]

Yes, commit and ReloadGlobals might come to rescue if you really need to use Station Globals.

[DerrickB]

Why are the different processes separated to begin with? If they need to share data, do they need to be separated?

Regardless, this sounds like an application specific mechanism that's needed and I wouldn't try to shoehorn in a use-case that station globals weren't intended for; that usually leads to people getting near the end of a project and being upset that the support case they open turns out to be a feature request or "don't do that" once they need to make some adjustment to the system that brings the house of cards down.

If you have specific data sharing needs, you'd likely be better served implementing what you need. Full control, good fit, etc.