Define Specific Critical Limits and Responses with Alarms in VeriStand

NI recommends that you use alarms to configure the system to capture when instruments or DUTs exceed critical limits.

Alarms define operational limits in the VeriStand system definition so that the system can appropriately react when the limits are met or exceeded. Use alarms to capture safe operational limits for the elements of your test system. Procedures define the desired system behavior to occur in response to an exceeded limit that is defined by a corresponding alarm.

Define alarms on the BTS Server for your implementation so that multiple test stations can make use of them.

To simplify the application of alarms and procedures across multiple DUTs in the test system, you can use the Socket %SOCKET% token in folder names for alarms and procedures. When you include Socket %SOCKET% in a folder name, the Battery Test System software does the following:

  • Duplicates the addition of that user channel, calculated channel, or alarm folder into folders for every socket that is defined in your test plan.
  • Replaces %SOCKET% with the actual socket number being scripted within these folders.
Tip Instead of hard-coding values within your alarm definition, NI recommends implementing any socket- and DUT-specific alarms in your system through user channels. In this way, you can provide alarm values from different sources, such as from the Battery Test System Web UI or an input file. This functionality is especially useful if the DUTs in your Battery Test System implementation have different critical limits.
Tip NI recommends setting alarms to be disabled by default. This option causes alarms to engage only when the test sequence begins.

Alarms apply to both calculated channels and user channels.