With advances in technology, ATE systems are becoming more widely used across a range of industries including manufacturing, avionics, aerospace, military, and defense. ATE systems are efficient and can be incredibly useful, allowing quick and accurate testing that communicates across a set of devices. However, it can become a complicated task to properly set up an ATE system to achieve the user’s desired outcomes.

Figure 1. Switch/measure sequence flow chart.
When multiple test instruments are required to work in conjunction with one another to acquire a measurement or sequence of measurements, the ATE architecture becomes even more complex and difficult to design. For example, a test may require triggering a digital multimeter (DMM) to take a measurement when a relay is closed, triggering a switch module to close a relay when a signal is successfully generated, or triggering a DIO to output a signal after the DMM takes a measurement. Engineers can choose from different triggering methods to find the best approach to achieve their goals. Each triggering method has its own level of efficiency as it relates to execution time and implementation simplicity. Some more deterministic triggering methods can decrease program overhead and latency by allowing devices to communicate directly, outside of the program.

There are various methods for LXI instruments to communicate with one another in a test sequence. An engineer can pace the sequence of events in an ATE system through his or her application code (software triggering). This is very simple to implement in code; however, there is a high degree of dependency on the host to manage the test sequence.

Alternatively, the LXI specification provides various means through extended functions for handshaking between instruments to reduce the amount of host intervention required, thereby minimizing any latency attributed to host-instrument communication.

LAN events can include trigger messages that are sent over the Ethernet wire from one device to another, indicating events such as when an instrument has completed an operation. A second LXI device can be programmed to interpret that message as a trigger event for it to take action.

Another approach is to use the LXI wired trigger bus, which is an 8-wire hardware trigger bus analogous to the PXI or VXI backplane trigger bus. The LXI wired trigger bus can be used as a vehicle to send physical signals from one device to others in order to pace the test sequence.

Test developers can take advantage of modular switch and I/O instruments, with embedded scanning capability and an internal analog backplane to reduce external cabling requirements, making test systems operate more efficiently.

Triggering Method Setup

Each triggering method — software, LAN event, and LXI wired trigger bus — can be easily set up and efficiently used by LXI instruments to perform accurate and timely measurements in an ATE system.

Figure 2. The switch/measure sequence using a DMM as the measure device.
Software Triggering. In comparison to other triggering methods, the software approach is the easiest, but slowest and least efficient method to trigger an action among LXI instruments. The user simply sends a command through a program to trigger an action, and repeats these actions in software until all measurements are recorded. The flow chart in Figure 1 describes a switch/measure sequence that is paced by the application code where a single measurement device is used to make multiple measurements through a multichannel switch. Due to the number of commands given by the program, and particularly the need to add a software delay, latency can become an issue.

Another way to illustrate the sequence is shown in Figure 2 using a DMM as the measure device with an integration time of 1.67 ms, and an electromechanical switch module settling time of 5 ms.

Removing all variables, and considering an example in which 400 measurements are made through the switch, the best-case scenario for execution time is (1.67 ms + 5 ms) 6.67 ms per measurement. At the rate of 150 readings per second, the test will complete in approximately 2.7 seconds. However, due to the variables in time consumed in sending commands across the host-instrument communications bus, as well as the variability in wait statements, the efficiency in execution of a software-paced program is much less than the theoretical maximum.