Novice TestStand Question: Best strategy for storing IPs, COM port locations, etc

[Mr._Jim]

Hi all,

I'm very proficient in LabVIEW, but I'm now joining the TestStand community.

As per usual, I performed a search but didn't find the information I'm looking for. Please forgive a redundant question...

What's the best way to persistently store IP addresses, COM port locations, serial resources and the like? When I write my LabVIEW applications, I typically use .ini or XML files.

The way I see it, I've got a couple of choices:

1. Use station globals
2. Write my own file IO and store the values the way I always have

Stations globals are an obvious choice, but there are multiple station types here with varying instrumentation. My concern is in having to version and track my station globals when some features will be the same and others will differ. There will also be a lot of these values in my typical use case. (a couple of dozen, perhaps?)

What's the "acceptable" practice and what do experienced developers do in this scenario?

Thanks very much,

Jim

[Mr._Jim]

Well, I was going to edit my post, but I ran out of time.

I forgot to mention a property loader as an option...

I realize that there are a dozen ways to do most things in TestStand. I'm just curious what experienced developers tend to do.

[Norbert_B]

Jim,

as with LV, the answer is mainly depending on the project environment and constraints.

When talking about IP:

1. Is that constant for a single machine (read: does a single tester have to connect to a static IP for server/client connection? Does that IP change to the next tester?)?

2. If not, what are situations where the IP might change? How does the tester know that such a situation occurred?

3. Does the user know about the stuff? Shall he be involved at all?

StationGlobals are OK as long as they don't change often but are specific for a single test station.

XML/INI/CFG/... files are good but require modules for loading. Should only be read once in a while. Store info as FileGlobal or Local (depending on use-case).

Storing in FGV also possible if you don't unload that FGV and usage only in LV.

Property loader is an option if you can re-use the required file format. You can write your custom property loader module covering that functionality in case you want to use a custom file format. Still, you have to consider where to place the value (StationGlobal, FileGlobal, Local).

My recommendation is: as local as possible without having too much overhead.

Norbert

[Mr._Jim]

Hi Norbert,

Thanks for the reply!

In further consideration, I'm more concerned with IPs of Ethernet (LXI, etc) instrumentation than with IPs of UUTs.

In the past I've tried very hard to avoid NI MAX configurations if possible, though that is always an option. I try to reduce the amount of places users have to go to configure things.

> 1. Is that constant for a single machine?

• Honestly, the static IP addresses wouldn't change too often, although they might from station to station.
• COM port mappings might well change and vary from station to station, as there are still USB serial adapters in use. (As much as one tries to standardize such assignments)

> 2. If not, what are situations where the IP might change? How does the tester know that such a situation occurred?

• If the station is adapted for different UUTs, the IPs or quantity thereof might change. I suppose a property loader may be appropriate in that case.
• For instrument IP addresses, if an instrument were swapped out, it may necessitate a config change. However, these IPs should ideally be standardized.
• For COM ports, if an instrument were swapped out, perhaps on a different USB port, that would necessitate a change in configuration.

> 3. Does the user know about the stuff? Shall he be involved at all?

• Probably not. This would all be transparent to the test operator, although test engineers would tweak things from time to time.

Thanks for reading all of this. I greatly appreciate the input.

[Norbert_B]

Well, i think the discussion is more like "guided self-awareness of the test system", isn't it?

Let's focus:

A configuration file (whatever its filetype might be: cfg, ini, xml, ..) is always an expectation of the software how/what hardware is available on the specific station.

A system i call "self-aware" doesn't need a traditional configuration, it does, however, require instructions.

Let's make an example:

- Using System Configuration in LV, you can identify NI hardware attached to the tester.

- Using "common" knowledge you can categorize devices (e.g. DMM)

- Using intelligent HAL you can make the test software independent of specific devices for a given category of devices

- Using potent HAL plugins (DSSP) enables full access to device functionality (maybe even specific ones)

Things to keep in mind:

1. Full hardware detection takes in average more time compared to "check expectation".

2. Without strict identification of device type and appropriate DSSPs the approach is no good.

3. What happens in case a device type occurs several times (e.g. two DMMs)? How is distribution done for parallel DUTs?

4. If an operator changes things to the worse, is the system still "self-aware"?

I think you might be interested in the idea driving ATML.

Norbert

[Mr._Jim]

Thanks Norbert! That was quite the detailed response - it's definitely given me much to think about.

I do appreciate it.

[warren_scott]

If you are more looking for instrument handle configuration, that should be managed by the MAX / session manager / IVI layer.

Basically, write your test code  / teststand sequence to communicate with "DMM1", and configure a alias/logical name in MAX / Session Manager / IVI configuration store to define "DMM1" is communicated through GPIB0::3::INSTR or TCPIP::127.0.0.1::INST0::INSTR, or whatever.

Makes your test code very portable.

It however does cause the standard problems of

 1) how to nicely get a MAX configuraiton onto the target station

2) if you want to run multiple different test procedures/programs that have a different idea of what "DMM1" should be an alias for you have a world of hurt waiting for you.

[Mr._Jim]

Hi Warren,

Thanks for your input!

---

@warren_scott wrote:

If you are more looking for instrument handle configuration, that should be managed by the MAX / session manager / IVI layer.

Basically, write your test code  / teststand sequence to communicate with "DMM1", and configure a alias/logical name in MAX / Session Manager / IVI configuration store to define "DMM1" is communicated through GPIB0::3::INSTR or TCPIP::127.0.0.1::INST0::INSTR, or whatever.

Makes your test code very portable.

It however does cause the standard problems of

 1) how to nicely get a MAX configuraiton onto the target station

2) if you want to run multiple different test procedures/programs that have a different idea of what "DMM1" should be an alias for you have a world of hurt waiting for you.

---

Well, the way I've handled this in my LabVIEW applications in the past is to map DMM1 to GPIB::3::INSTR using a config file of some sort. I did the same for DAQmx resources.

The reason for this is that I already had many other configurable items in the config file, which I included in my installer. (I typically had a handful of such files in a designated directory) As long as the hardware was set up with the right identifiers, (e.g. COM1 or Dev2) everything was fine. The same idea seems to translate well toward leveraging databases.

In fact, in the DAQmx cases I could just use the API to detect the right model of hardware and automatically generate the device identifier. Sometimes (not always) I could do this with GPIB or serial resources, too, if I could properly identify the instrument. Now, Norbert alluded to ambiguous cases where there might be more than one unit of a type, which gets tricky for auto-detection.

My personal preference is that I find importing and exporting MAX configurations especially loathesome. At a past gig, when someone else used configuration tied to MAX and a PC died, I had a heck of a time restoring the configuration properly. I learned very quickly to back up all of those configurations, and I consequently thenceforth avoided using configurations that had to be manipulated in MAX. This was also years ago, but at the time I found that importing MAX configurations yielded hit-or-miss success. I'm not saying that this is necessarily the case now, nor am I saying that my preference in LabVIEW necessarily translates well to the TestStand world.

You're also not the only one I'm hearing advocate IVI abstraction. However, at this point I'd lean toward leveraging LabVIEW classes and abstracting drivers that way, if only because I'm much more familiar and comfortable with LabVIEW classes than with IVI. I may change my mind use a combination of both, though.

I like Norbert's idea of leveraging DSSPs (Device Specific Software Plugins). I found this whitepaper that appears to have involved at least some level of Norbert's collaborative effort.  (Maybe not?)

I hope that my somewhat strong opinions don't inadvertently convey a lack of gratitude - I do appreciate your weighing in.

Jim

[Mr._Jim]

---

@warren_scott wrote:

If you are more looking for instrument handle configuration, that should be managed by the MAX / session manager / IVI layer.

Basically, write your test code  / teststand sequence to communicate with "DMM1", and configure a alias/logical name in MAX / Session Manager / IVI configuration store to define "DMM1" is communicated through GPIB0::3::INSTR or TCPIP::127.0.0.1::INST0::INSTR, or whatever.

Makes your test code very portable.

It however does cause the standard problems of

 1) how to nicely get a MAX configuraiton onto the target station

2) if you want to run multiple different test procedures/programs that have a different idea of what "DMM1" should be an alias for you have a world of hurt waiting for you.

---

[~jiggawax~]

Ok here goes my 2 cents:

StationGlobals = Bad (my rule is NEVER use them.  I've written thousands of automations and never needed one yet.  Trust me I've seen it all)

Property Loader = Clunky and useless for large amounts of data.  The file is too big for any end user to make sense of it.

PropertyObjectFile = OK but the end user has a hard time changing it if needed

MAX = multiple automations on the same bench might have hard coded different names for the devices.  This causes the user to change MAX every time they switch between a product.  Not good for high mix, low volume.

Configuration Entry Point = Has worked the best for us.

We have a Configuration entry point in our process model and put an empty callback call in there.  Then any client file can override that callback and put a call to LabVIEW GUI which allows the end user to configure the settings for that specific test.  The GUI saves these settings off to an XML file (can be anything really, pick your poison).  Upon execution the client file reads them in.

This way each automation on the bench has the flexibility to do whatever it wants.  Also, the file IO is done in LabVIEW which is more flexible than TestStand for fileIO.

It also adds a menu item under the Configure tag that the user can call at any time during edit time/non execution.

Just a thought.

Cheers,

[Mr._Jim]

Thanks Jiggawax, I really, truly appreciate the candor.

It's funny because as soon as I hear the term "Station Globals" I get an involuntary shiver down my spine. It just doesn't seem right! I get that everything is centralized, but it seems primitive and not very scalable long term. (Notwithstanding trying to keep track of it on stations where the products being tested will be changing all the time)

From the property loaders I've seen so far, I'm not thrilled and agree with your assessment. They work, but they don't seem optimal by a long shot.

 I like the idea of the configuration entry point override... That seems pretty analogous to how I set up my LabVIEW applications - and that way things can be as elegant and intuitive as you make them. I also like that I could implement the persistent storage of data in any fashion. (Either good or bad, depending on the forethought and planning of the developer)

My whole point in this exercise is to think through design decisions carefully before diving in to a new environment that has myriad options.