See below the list of FAQ regarding TestExec SL software:
1. The testplan does not run to completion. What is wrong? 2. Can I use NI Labview or LabWindows/CVI with Test Exec SL? 3. What Is the error sequence? When is it run? 4. What test steps should be in the error sequence? 5. Can I generate my switching topology files programmatically? 6. Can I generate a testplan automatically from my test spec? 7. Do I have to exit TxSL when I change the system.ust file? 8. What does "Pass/Fail Only Affects 'On Fail Branch To'" mean? 9. The Profiler doesn't display any results. What's wrong? 10. How do I interface to a database? 11. How do I turn datalogging on and off dynamically? 12. How do I use datalogging? 13. How can I configure the system to boot up automatically to TxSL? 14. How do I set up test steps to run only the first time the testplan is run? 15. How do I control automation? 16. Why do I see question marks in my switch paths?
1. The testplan does not run to completion. What is wrong?
TestExec SL is shipped with the Options/Testplan Options' Execution tab's Sequencer Halting value set to halt on first failure. Sometimes it is more desirable to let a testplan run to completion and let the built-in exceptions cause aborts. Change this setting to "Ignore all failures." Note that this only affects the sequencer, not datalogging. Failures are still reported and logged normally.
2. Can I use NI Labview or LabWindows/CVI with Test Exec SL?
The answer is a qualified "yes". You can create actions (precompiled measurement routines) from either of these languages, and TestExec SL can run them. This also applies to actions written in HP VEE. Note, however, that you must be careful not to access the same instrument from both NI Labview (or NI LabWindows/CVI, or HP VEE) AND from Agilent-provided actions. To do so would clobber the state tracking and cause unpredictable results. You can also load the TXSL ActiveX control into those languages (as well as Visual C++, Visual Basic, and others) to develop an operator interface.
Use of any languages other than Visual C++ (VC++) to develop actions, and VC++ or Visual Basic to develop operator interfaces, while possible, is not recommended because it can slow down testplan execution and can chew up memory in order to load the runtime execution engines for those languages. Agilent's support structure is also better equipped to help you with VC++ and VB, which are more widely available programs.
Note that in many cases, the hundreds of supported and tested actions that are provided with the system are sufficient to develop a testplan without the need to write your own actions, and that Agilent or third parties can be contracted to write custom actions, should they become necessary. Typically, such actions are needed only when special results analysis is needed or drivers for new instruments are required.
In the upper left corner of the Testplan Editor window is a selector that allows you to edit either the Main Sequence, which is your testplan, or the Exception Sequence, also often referred to as the "Error" sequence. The error sequence is run automatically if it contains any statements, whenever an exception (an unrecoverable error) occurs. Typically, it is used to clear variables, reset instruments and power down the supplies. Note that you cannot explicitly run the error sequence. If it is displayed when you press the Run button, the main test sequence is run instead.
4. What test steps should be in the error sequence?
Typically, any variables that must be initialized, global reset and power supply shutdown are needed in the error sequence. If you have an automation system connected, you may also need to reset the handshake lines or at least set a flag that can be tested by the automation or operator interface to allow the I/O to be reset properly. Basically, you can put anything in the error sequence that you need to bring the system to a known, safe state.
5. Can I generate my switching topology files programmatically?
Yes! A contributed library allows you to specify your fixture and DUT connections in a text file and then run a small 3-line testplan that will read the file into Agilent TestExec SL and write a fixture.ust and uut.ust file. The text file can be generated from a spreadsheet or any text editor.
6. Can I generate a testplan automatically from my test spec?
Yes you can, but you will have to write some of the necessary code yourself, since Agilent cannot know in advance how your test spec is constructed. To access the feature, add the following to the tstexcsl.ini file in the Tool section:
(All on one line; replace the "xx" with the next number in sequence.)
You'll also need to create at least one test library. First, create a new directory (anywhere) called "Test Libraries". Go into TxSL and start a New Testplan. Create an empty test (no actions). Name the test "dummy". Go to "File/Save Test Definition" and name the file dummy.utd. Save it in the Test Libraries directory.
In Notepad, create a file named, say, autotpa.txt and put the following in it (for example): "1.0.1 Initialization",0,:Library,0,dummy.utd "2.0.1 Input parametric",0,:Library,0,dummy.utd "3.0.1 Output parametric",0,:Library,0,dummy.utd "4.0.1 Power up",0,:Library,0,dummy.utd "5.0.1 Download",0,:Library,0,dummy.utd "6.0.1 Output loads",0,:Library,0,dummy.utd "7.0.1 Functional",0,:Library,0,dummy.utd "8.0.1 Power down",0,:Library,0,dummy.utd
(replace dummy.utd with the complete path including dummy.utd)
Now, if you're still in TxSL, delete the dummy test you just created. Then select Tools/TestGen and double click your autotpa.txt file. The text inside the quotes in the autotpa.txt file should now be in the left pane of the TxSL window. The report window will tell you if there are any errors. Note that if the dummy.utd file actually has useful stuff in it, all relevant actions and parameters will have been copied into TxSL as well.
By writing a program that reads your test spec and then writes the autotpa.txt text file, it is thus possible to automatically generate at least the names of the tests automatically. If you want to go farther, you could scan the spec looking for particular types of measurements and then load UTDs that are closer to what might be needed (say, one with a switching statement and a MeasureDCV, for example).
Special Notes: 1. If you use ",," to specify the unused parameters in the autotpa.txt file, you'll get the error message "Field missing". Use ",0," instead. 2. ":Library" is case sensitive. 3. If a testplan is loaded already when you run this, it will put the items contained in the text file at the end of the testplan, but it will rename the test contained in the first line of the text file to whatever the UTD file used as its name. 4. If the testplan that's loaded is the one you just created by running TestGen and then you make a change in the text file and run TestGen again, nothing will change and no errors will be generated.
8. What does "Pass/Fail Only Affects 'On Fail Branch To'" mean?
Normally, when a test fails, its results are logged and reported. If you check this box, failing tests will not cause data to be logged or reported, but the normal sequencer branching will be unaffected. This can be useful when you want to use this as a way of branching by forcing a failure. Another interesting use of this function is to allow a test to be executed at some quasi-real-time point in the execution. You do this by creating a test that is set to "On Fail Branch to" itself. Only when it passes will execution resume. If the test result is a time, say the results of the "UsecsElapsed" timer, with the low limit set to the time you wish to exit the routine and the high limit set to some very large number, the routine will loop until approximately the time of the low limit. But you do not want all the timer failures logged, so you check the "Pass/Fail only affects 'On Fail Branch to'" box.
9. The Profiler doesn't display any results. What's wrong?
First, the profiler must be turned on. It is enabled in the Options, Testplan options menu selection. The "Profiler" tab has a checkbox that allows the profiler to be turned on and off.
Second, all tests that have limits assigned must pass before profiler results can be displayed. If some tests are failing and you still want to see the results, disable the limits temporarily, widen the limits so the test passes, or set the skip flag on failing tests.
There are two reasons you may want to interface to a database. One is to get test parameter data or limit data from the database into your testplan. The other is to put the datalog records into a database for analysis by an SPC or SQC software package. Let us look at each of these needs.
Getting database information into the testplan. There are two ways to get external data into a testplan. The "product versions" capability built into TS-54xx family software allows you to read test parameters from a text file. The testplan creates the text file using TestParm symbol table entries and test skip information. When read back in, the values that need to be changed are updated by the product version action (ParameterLoad). You could get the data values that need to be changed from a database by writing a standalone program that would query the database (probably using an SQL interface) and write the data into the text file.
Another common way of getting data into a testplan is to use an external symbol table. These tables can be created from within TestExec by selecting File/New/Symbol Table, entering the desired names, data types, default values and description of the variables, and then saving the table as <name>.sym. When a testplan is loaded, that symbol table can then be loaded by selecting View/Symbol Tables and clicking "Link to External Symbol Table," then selecting that name. If a testplan is saved while linked to an external symbol table, that information will be restored the next time it is loaded. You can access this table from Visual C++ or Visual Basic. From VB, using the TestExecSL ActiveX control, the statement is: TestExecSL1.SymbolTables("filename.")Symbols("symbol name.")Value = x
Instead of the value x, you could use other VB ActiveX controls to access relevant database information.
Getting testplan information into the database. This generally means converting the spreadsheet comma-separated-variable format of the log file into the necessary SQL command that will store the data in your database. See the "How Do I Use Datalogging" FAQ for information on file format. From VB, you would simply read this text file, parse the information and execute a database command to store the data. It is beyond the scope of this FAQ to explain how to get data in and out of a database. Commonly used databases are Microsoft Access, Btrieve, and Oracle, and there are many others. Your needs will dictate what you put in your database. Agilent's SSV division can quote custom software that will allow you to create and manage a database.
Although it is easy to tell when there are failing tests from the operator interface, it is not a trivial problem to determine from within the testplan if it has passed or failed.
There are two reasons for this: 1. If the "halt on failure count" option is set to something other than 1 (instead of selecting "ignore all failures"), then, has the testplan passed if the failure count is less than this? This is a subjective condition whose answer depends on your interpretation of failures. 2. If the testplan aborted, including operator abort, exceptions and so on, but no tests had failed to that point, is it a failure? (normally, the answer would be yes, but the count of failing tests would be 0, so you need to take other things into account).
Here are a few ideas to decide if the testplan has run to completion and passed all the tests:
1. Add System.TestStatus (which is 0 if the test passed and is unchanged if the test had no limits) to a variable after each test, if it stays 0, the testplan passed. This requires placing "if" statements after each test.
2. Use the "on fail goto" flag (in the options tab on each test) to cause any failing test to go to a common cleanup routine, which will be the last test in the testplan, will have no limits, and will not affect the TestStatus variable.
NOTE: this cleanup will be executed whether the last test passes or fails. Follow this cleanup routine with an "if" statement that checks the TestStatus variable, which will be the one for the last test that has limits. If the variable is 0, all tests passed and you can write the text file out<p> In this example, the code looks like this:
test A (on fail branch to test Cleanup) test B (on fail branch to test Cleanup) test C (on fail branch to test Cleanup) test N (on fail branch to test Cleanup) test Cleanup if System.TestStatus = 0 test WriteTextFile end if
NOTE: you MUST set the sequencer halting option to "Ignore all failures" for this to work.
3. Write a separate program that would read the datalog file after it is written, and check the BoardStatus variable, which is "0" if the testplan passed. The trick here is to figure out the name of the datalog file and know when it is available for reading.
4. RECOMMENDED: Create a file with 2 routines in it - one you register as an action and one that will be a special routine that estExec will call after the testplan has finished running (called a "callback"). The action that you place in a test at the beginning of your testplan would make a call to a function in pubapi (see pubapi.h in the Agilent TestExec SL\include directory) called VRegisterSequenceEnd. It takes one parameter: a pointer to (address of) a routine that you will write and put in this same dll, called, say, "DeterminePassFailStatus". This routine contains the code to write the text file once it determines if the testplan passed, and will call VUnregisterSequenceEnd to remove itself from the callback list. Your routine is called automatically when the test sequencer ends, so you don't make it an action - it exists in the same dll as the action that registers it. Test Exec passes the state of the sequencer into your function:
NOTE: LIMIT_ERROR means the "halt on failure count" limit was reached. HALT_NO_ERROR can be caused by programmatically asking the sequencer to halt.
If the sequencer status = SEQ_OK, then the sequencer made it to the end of the testplan without any abortive conditions. Once you have determined that the sequencer is happy, you can call the function VGetTestplanFailureCount to determine how many tests failed.
12. How do I turn datalogging on and off dynamically?
Sometimes it is desirable to turn on data logging for selective tests, and then turn it off for other tests. This feature is not available as an option settable from the development environment of Agilent TestExec SL. However, data logging can be turned on and off at a test level by use of a simple action.
A setup/clean up style action called "overrideloglevel" can be used to change the data log level of tests. The action definition file is called LogOverride.umd.
Calling the "overrideloglevel" action will cause the existing testplan log level to be changed from its existing state to a new level. Passing a parameter of zero to the action will result in the log level being set to none. Passing anything other than zero will result in the log level being set to all. Note that action is a setup/cleanup action, which means that the log level will automatically be reset to its original condition once the conditions to execute the cleanup action are satisfied.
If it is desired to change the behavior of multiple contiguous tests, it is recommended that the multiple tests be grouped into a single testgroup, and the "overrideloglevel" action be inserted into the test group.
(Quotes are necessary because of the spaces; alternatively you can use the Progra~1 form).
Place a shortcut to this file in whichever Startup directory is appropriate given your login system. For example, placing it in the C:\WINNT\Profiles\All Users\Start Menu\Programs\Startup directory will cause it to be run for all users.
14. How do I set up test steps to run only the first time the testplan is run?
Place test statements inside an if-then statement of the form:
if System.RunCount <= 1 then test A test B ?n end if
Note that RunCount will not be incremented if you enable sequencer looping from the testplan options menu. If this presents a problem, create your own variable in the SequenceLocals symbol table and increment it yourself (or simply set it nonzero to eliminate potential problems if the count hits 2^32) at the end of the testplan.
Typically, the types of actions you would place in these tests are global reset, arb downloads and serial initialization calls.