This is one of the key differences between the RI tester and other approaches. The RI test software models the testplan as a sequence of "states", not as a "process" to be executed step by step. "IF" statements do not exist in the Roos tester as such, because they are descriptive of process, not state.
The most common collision between the state and process models occur when you want to find a "setpoint" and return to it later. In the process model, you would change a value, measure the result, and then make a decision about whether to increase or decrease the value for your next try. The state model works by measuring a complete "sweep" of results vs. values and then choosing the operating point by interpolating the graph.
Your testplan may require conditional statements like "IF... THEN..." to branch to logically different paths. This is done by adding additional test sections and using the "Conditional Statement" section to determine if the tests in that section are performed. A "If... Then..." button does not exist because it would prevent the existing testplan optimization process that reduces the number of state changes in the test system from working.
The Conditional Statement section is used to make branch decisions on weather to skip that following test section, display some sort of prompt, or continue and run the tests in that section.
- If it is left blank then the entire Test Section is run unless some of the Tests are disabled.
- If there is a prompt placed in the Conditional Statement then that is displayed to the screen and an operator must enter a value or just hit OK ( enter ) to continue with the Test Section execution.
- If a logical flag is set ( True or False ) , then one of four operations can take place based on the button placed in the Conditional Statement
- Skip if True : Will skip the entire Test Section and go to the next Test Section if the Variable is "True" or else it runs the Test Section.
- Skip if False : Will skip the entire Test Section and go to the next Test Section if the Variable is "False" or else it runs the Test Section.
- Abort if True : The Test Plan will stop running tests and jump to the Disconnect Settings section and finishes if the Variable is "True" or else it runs the Test Section.
- Abort if False : The Test Plan will stop running tests and jump to the Disconnect Settings section and finishes if the Variable is "False" or else it runs the Test Section.
- To set the Logical flag and assign a variable you place the " Set Flag" button in your Test Plan in any Test that is in a previous Test Section to where the Logical flag will be used. This "Set Flag" button works very much like a Limit check but sets the value of the variable name assigned to either True or False.
All these buttons are found in the System Flow Control panel in the Tester View.
We do conditional testing buy setting flags (for the condition) and then a do if true (or false) in the conditional statement panel of a section. As such it works section to section. The buttons are self documented in the editor. It may not be ideal, but this restriction comes from running a compiled executable, as opposed to interpreted executable. Running compiled allows "real time" synchronous operation that isn't easily achievable with an interpreted implementation.
From constructing an application standpoint, it comes down to, "What are you trying to do?" It is comparatively very slow to work conditionally, compared to the sweep and search approach that we typically implement. For example, if you are looking at the bias sweep -- it is much faster (and easier to program) to sweep across a range of voltage values, measure the dependent condition (current), then find the voltage that gives the desired current in the array. See the article, "Curve fitting and interpolation" for more information.
We've been approaching test this way for the last 20 years or so and have yet to find a part we can't test this way. The state-based approach permits us to do optimization of the testplan and to execute the tests in the shortest possible time. The apparent limitation in test plan development is really a way to enforce "best practices" and achieve the best possible test for the DUT.