TestStand ATML Reports and LabVIEW

[mrbean]

Obviously, TestStand 3.5 offers ATML as one of the Report Formats (within Configure::ReportOptions).  Other than trial and error, is there a way to determine which ATML field goes with which TestStand ResultList (or other) item.

[RayFarmer]

Hi mrbean,

Maybe this link may help as a starter

http://zone.ni.com/devzone/cda/tut/p/id/3893

Regards

Ray Farmer 

[mrbean]

That link was kind of what started this whole thing.  Let me detail our situation (probably very common), and see if anyone has suggestions.  We're using TS3.5 and LV8.21.  We're working on an Automated Test Station that will (eventually) test a variety of UUTs.

We have to configure/control quite a range of test equipment, and take anywhere from 1-10000 readings, depending on the test.  Our initial plan was to use the propertyLoader step, but its lack of syntax checking and support scared us a bit.  Instead, we're using LabVIEW's Configuration Property Editor.  So what we did in our first UUT test (not really a UUT, it's just a self test of the test station itself) is implemented all our tests as passFail steps.  Then, within the 'Configure' state of our LV state machine, we open the appropriate config property file, extract the config data for the test equipment, then move along the state machine.  We take measurements (sometimes a few, sometimes many, many).  In that first 'Self Test' we didn't really have any data reporting/storage requirements.  For the upcoming UUTs we do.  Here's where the trouble begins.  For the self test, we merely analyzed the data at the end of our state machine and made the determination of pass fail (based on limits found in the config property file).  We also wrote out to some log file, the verbose data (various readings, text, etc) in case we wanted to look at it later.  We now are concerned with data collection, and report generation/format.  We've been looking at TDM, ATML, DIAdem, modifying the TestStand sequential model, updating the code behind the DLLs that generate the reports, etc.  We started to look at ATML because the IEEE folks already took care of a great deal of the content/format issues.  The problem (and this applies to any approach we take) is getting all the data back to TestStand, so it can build the report.  That's why we went with our original approach - We thought it pretty cumbersome to send all that info back (sometimes thousands of readings), and figure out in TestStand whether a test passed or failed.  Quite often it wasn't as simple as something being outside of a range. 

Also, our systems engr would like all data in one file (per UUT) so as to not have to look all over for test information.  That's why he thought the ATML approach might be best.  However, as I mentioned to him, if we use TestStand's ATML wrapper, it can only work with the data we've provided to TestStand (so we're back to square one).  Another idea is to continue with our current approach, where we summarize the results in LV and tell TestStand, but for mega-data that we're recording througout the test, write it to TDM files, and use DIAdem later on it if we so chose. 

We really aren't sure of the best approach.  Any suggestions?

[Dennis_Knutson]

Let me try to understand. You have one big state machine that you call, do not let TestStand make any pass/fail decisions, and are not using TestStand to log data. If that's the case, why are you using TestStand at all? I don't think your situation is very common at all. I pass all of my test results back to TestStand (sometimes many thousands) and let it make the pass/fail decision. I also keep the LabVIEW code steps very small and single purpose. I have one code module to instrument A, one for B, one for C, etc. I do not like the idea of having all the code for all of the instruments in one big step. I just think it makes it harder to maintain and support. All information is written to a SQL Server database and the html reports are only temporary. If the operator wants to see the results after a test, he or she may do so but then it's overwritten the next time the test is run. If someone wants to review the test results later, they enter in a specific serial number into the database query tool and the results are displayed. The idea of keeping thousands and thousands of individual files around seemed unworkable to me.

[mrbean]

(1) How do you configure your test equipment - do you use the Property Loader step type at all?

(2) If you have a test that has 1000 readings it has to perform, do you use the Multiple Numeric Limit Test type.  If so, do you enter each and every Measurement Set in the "Edit Multiple Numeric Limit Test" dialog?

(3) Related to 1&2, if you want to test at one setting (say three pieces of test equipment are involved), configure, take a measurement, store, then move on to reading 2 of 1000 (etc), each time having to adjust the test equipment slightly, how do YOU coordinate those efforts?

[Dennis_Knutson]

1) Every instrument has a custom step type. I wrote an edit step for each. The edit step is similar to the IVI edit step. Each of the UUT's that I test has a unique test sequence and all of the configuration is done in TestStand. that means that the step type itself has the instrument configuration. I don't use the property loader at all. The edit steps that I wrote also write the setup to the TestStand comment field. So, for example if I would set a DMM to 'Volts DC', this is shown. It's makes it easy for someone else to view the sequence and see what the sequence is doing. I can run the sequence file documentation tool and provide that to someone else (i.e. the design engineer) and the test sequence can be audited without providing a means of also reading an external file and trying to figure out what is associated with what. There are a few instances where one test sequence is designed to test multiple flavors of a UUT. For me, it was simpler to use a few preconditions in the sequence. Sometimes it's a different subsequence, sometimes it's just a different step.

2) I have not been able to make use of the multiple numeric limit test. You see, I began using TestStand 1.0 and that was before the multiple numeric test was available. My IS department helped set up the database and the test results are linked to a much larger corporate database and it has been difficult to get the test results database changed to support the multiple numeric limit. How I handle repeated tests is by using loops (and sometimes nested loops). I will group all identical measurements together. For example, If channels 1 through x are supposed to have a certain voltage reading, i will return all of those voltages to one TestStand array. If channels 1 through x are also supposed to have a certain frequency measurement, I return those to a different array. My custom steps include a few custom fields such as channel number. This is included in the log/report so it's simple to determine which part of the UUT failed.

3) Well, there a couple of ways. One way is to create an array of values (i.e. a voltage stimulus). As a pre-expression, I might do something like Step.Source.Voltage = Locals.SourceSetting[ Locals.LoopIndex ]. Often though, I will just copy the sub-sequence that was used for setup 1 into another subsequence and just change the custom steps that need it.

[mrbean]

You said "The edit step is similar to the IVI edit step" - I don't see anything by this name in TS3.5, do you know what it might now be called.

You said "the edit steps that I wrote also write the setup to the TestStand comment field.".  How exactly do you do this from TestStand.

you said, "My custom steps include a few custom fields such as channel number. This is included in the log/report so it's simple to determine which part of the UUT failed".  Are the custom steps the same as your edit steps.

Is there any snippet/example you can share of one of your custom edit step types?

[RayFarmer]

Hi,

Have a look at the Step Type example HP34401a in the TestStand\examples folder. I think that should provide some answers . Look at the Properties of the StepType, particular the General Tab for the Description field.

Regards

Ray Farmer

[Dennis_Knutson]

mrbean,

You can't right click and do a Insert Step>IVI? I've done a full install and maybe you haven't. I've just upgraded from 2.0 to 4.0 and they are now called IVI-C. The example that Ray points out is good as well. That updates the description instead of the comment. to write to the comment, I've been using the code below.

[Antonio Lie]

mrbean,

I was reading through your post and I noticed the following line:

"Our initial plan was to use the propertyLoader step, but its lack of syntax checking and support scared us a bit"

I would really appreciate if you could give me more details about your use case.

Why do you think the property loader lacks syntax checking and support?

Regards.

Antonio Lie