Best approach for adding configurations to deployed system

[gizmogal]

I have been using Property Loader steps to accomplish three things on a deployed system:

1. Define equipment ID,s calibration, slots, etc. for the hardware of the deployed system
2. Define behavior for the deployed system station (paths, test multiple versions of a module or only the most recent, allow x seconds for UUT boot up time)
3. Define limits for the multiple versions of a module (K uses board 1, M uses board 2, each with different images for connection instructions, each version has a combination of software revisions and a different path to find the software to load to the module, component limits may change with each rev)

We need to load all these properties because we intend to build a duplicate of the system and once it's on the production floor we are not allowed to change it without going through a lengthy verification and validation process.

I am finding that especially items 2 and 3 are cumbersome to maintain and may actually work against my intent - each time a new rev or behavior is needed, I have to build a new deployment containing the latest information. I've come to the conclusion that I need to provide a utility to change these settings on the fly, so that the utility can be validated once and the settings can be changed and confirmed for future releases without requiring a new deployment to be built.

Ideally what I would like to do is:

• Read the current file (which is in Property Loader format)
• Display a UI showing the current file contents
• Allow the user to change the contents
• Provide Save command to change the file, or Save As command to write a copy of the file (for new revs of the same module). Keep these files in the same Poperty Loader format.

My questions:

1. Is this achievable in TestStand only?
2. If not, what would be best practice?
3. Should I switch to INI files so I can use the Write and ReadEx methods, and if so, how does one write/read multiple variable mixed between FileGlobals and StationGlobals?

Thanks in advance!

Gizmogal

[snowpunter]

A few thoughts:

NI has an internally-built TestStand framework known as Ultimate II (since updated to Blue Night) that would download sequence files from a server based on the UUT being tested. Thus, rolling updates was easy as all you had to do was update the sequence file on the server and you were set. You could also store all test values in the sequence file and do away with Property Loader/INI/Write ReadEx files.

We're actually in the process of heading towards storing the values in sequence files rather than external files ourselves, hence our recent feature request.

If you have the ability to access an updatable server from your test beds I would recommend moving to an approach like this, though your V&V team may not like having this type of function, unless you have some type of version control of the sequence files on the server.

[gizmogal]

Ah, well, we are off the network completely to avoid rogue updates going on behind the scenes, invalidating the V&V results. The value of the external files is that the sequence will work regardless of minor changes to the UUT which don't affect tests upon it.

[RaviShrigiri]

You can try modifying the process model to add a configuration entry point.A menu item will be added in the configuration item which in turns calls the sequence you have added.In the sequence you can call a vi/DLL to display or modify the parameters you want.

You can make this menu item visible only say for adminstrators to prevent misuse.

This requires you to develop a GUI to display/modify all the existing properties

Other method possible is :

Keep a seperate property file for each models.The name of the model and the property file can be same.

Whenver a module is running it should automatically pick the corresponding property file from a fixed location.

So whenever a new module is a added you have to just create a seperate property file and not deploy all the files.

Additionally you can put this files under checksum to avoid misuse.

[DowNow_]

Hi,

If you have validation requirements I think you definitely want to isolate and minimize just the part that changes, and separate that from the validated, unchanging part. Sounds like you are doing that. I also think separating the "station" properties from test-related "limits" properties makes sense.

You should be able to swap out property files without doing a deployment. In the part where you said, "Ideally what I would like," you have two choices in implemeting that. 1) translate the property loader file to the UI, then back again as you describe. or 2) write your own property loader. Many have done this. You get the Property Loader source code with TestStand, I've written a couple in LabVIEW. You can make either tool available in the Configure or the Tools menu.

The difference between property loader and Write and ReadEx is, I think, Write and ReadEx serializes a single property, which is usually a container. Property loader recurses through a bunch of containers in a bunch of steps. Also the file formats are different. I use both depending on the project. If you look in the process model sequences you can see that Write and ReadEx is used to copy values between Locals and Parameters of different sequences. Maybe you could use those for StationGlobals and FileGlobals and Property Loader for steps.

cc

[gizmogal]

Thanks for the comments... After much trial and error with property loader and Write and ReadEx, I decided I needed to write my own interface that will only be available when an admin is logged in. I'm going to switch to LabVIEW configuration files and set the values using the sequence context passed in by TestStand. I might have been able to use the property loader if I didn't have some arrays of containers already heavily used by the system.

I agree with keeping the different files for the different revs, I just want to be able to create them on the fly!

And then I have to worry about how to deploy a new version without changing the configuration, but if there's no configuration yet, create a default...