The use of the LOWER limit (Step.Limits.Low) for “less than” (LT,LE or <, <=) comparisons also has implications for data logging and report generation. For a specification like "noise less than 1 mV", I would want the report to show no lower limit and an upper limit of 1 mV. Since TestStand uses Step.Limits.Low for the comparison, it is necessary to add some expressions to the database logging “Columns/Parameters” configuration in order log this limit as an upper limit in the case of LT,LE comparisons. Here are the expressions I added.
lower limit:
Expected Properties: Logging.StepResult.Limits.Low
Precondition: (Logging.StepResult.Comp != "LE") && (Logging.StepResult.Comp != "LT")
Expression: Logging.StepResult.Limits.Low
upper l
imit:
Expected Properties: Logging.StepResult.Limits
Precondition: (Logging.StepResult.Comp != "GE") && (Logging.StepResult.Comp != "GT")
Expression: ((Logging.StepResult.Comp == "LE") || (Logging.StepResult.Comp == "LT")) ? Logging.StepResult.Limits.Low : Logging.StepResult.Limits.High
For the lower limit, I added a precondition so that no lower limit would be logged in the case of a “less than” comparison. If you are using a stored procedure call here, the precondition will set the parameter to a SQL NULL if there is not a lower limit.
For the upper limit, I added a similar precondition so that no upper limit would be logged in the case of “greater than” comparisons. The key change is the expression, which logs the lower limit as the upper limit in the case of “less than” comparisons. Again, this is because of the backwards way that TestStand uses the lower limit for “less than” comparisons. Another note is that I omitted t
he “.High” in the expected properties. This is because in the case of “less than” comparisons, the “Limits.High” property does not even exist in the Results container.
