Property Loader and Multiple Numeric Limits

[RayFarmer]

I’m using a Multiple Numeric Limits Step with 50 measurements. From these 50 measurements I would like to create a limits file. The problem I have is that when I export the properties to a tab delimited file text file it becomes unreadable. I have attached a file with an example of what I mean.

Is there any way to format the limits file so that it is more readable?

[Scott_Richardson]

Ray -
You are highlighting the issue that when you have cell values in one row that are wide and cell values in another row that are not, the columns do not line up nicely. The only suggestion that I have, and this is what other customers that I have talk to do, is to edit the contents of the file in a grid in a separate application such as Excel.

Scott Richardson

[RayFarmer]

Scott,

The problem comes when you dont have Excel on your target machine and you what to make some adjustment to the limit file on the fly.

Regards
Ray Farmer

PS the original query wasn't posted my me but its a good point to raise that maybe most people live with because they don't have some many parameters.

[dowNow]

Hi Ray and Scott,

This thread is closest to my challenge, so I wanted to reply instead of post a new thread.

I may have four or five different (multiple num lim) steps with 10 – 25 measurements each. So there’s a lot of columns AND Result.Measurement[3].Comp might be power limits for some steps, jitter for another and OMA for yet another.

I may also have two to five different custom steps that have 10 – 25 unique properties each.  This can stretch the top row colunn headings of a properties file out to 75 – 100 columns.

What is a good or common approach to make property and limits files more readable/editable by humans? I’ve tried a custom file editor and a custom property loader, is one approach better, any other ideas? Should I make steps with many properties or results into subsequences? Thanks

Sincerely,
Chris C.

more context:

1. I find reading Ray’s example.txt file in excel better than notepad, but still more cumbersome than I’d like. I also have the same problem with custom step types that contain 10 – 25 properties to load at runtime, though this is a little better because the NAME of the property is used in the column headers. If I exported properties from a seq with four different steps with 20 props each, the top property file row stretches out to 80 columns. If I use Markers I think I can “stack” the column headers in excel and not have such a wide file.
2. For the limits I’m going to need to see the measurement name in the file, Measurement[“Pave”].Comp instead of  Measurement[3].Comp. I tried changing this in the limits file and the Import tool but it wouldn’t work, is it possible?
3. I built a limits and property file editor app (jpeg attached) for one project to make editing easier and less error prone, and also maintain the native TestStand file formats and property loader. The leftmost column retains the order of the sequence.
4. I have experimented with my own property loader, however it is not based on the property loader code that comes with TestStand because I did it in LabVIEW. This produces a file that looks like the attached jpeg and is readable in Excel, a requirement (or was that a whine?) of my organization. (Can’t use a database.) However it seems a little dangerous to recreate TestStand components.

[Brandon_V]

This is one of those things that's just not easy to change. TestStand looks for these properties in a specific way and the only way to change this is to create your own property loader (which you can then decide on the actual look and feel of the property file).

1) Again, this is an easier way to view the data but changing the format will cause problems when trying load. So your way is pretty much the best way to use this.

2) These Measurements are referenced this way because they are in an array. This can not be changed to use the Step Name.

3) This is a great program and really helps editing, it seems this would be an easy way to edit properties.

4) Its not really dangerous to do this, you are pretty much just making your own custom property loader and there is no problem with that. Just be sure you have created the correct API calls and everything should work just fine.

Pretty much, you can go either way, your own property editor or your own property loader, either is fine. It really depends on what you want to do.