Minimize Switching Time in Scanning Systems

When you set up a switch card to operate as a scanner, you have more than one way to program it. You can use a software “for-next” loop or a scan list loaded into the switch card triggered by software. And VXIbus switch cards also offer a hardware option that moves your switches through a scan sequence.

To compare switching speed using various programming techniques, I programmed a switch card used in a burn-in rack and connected 16 device loads (UUTs) to a DMM (see Fig. 1). Although I used a VXIbus register-based switch card, you can use the same techniques on a PC-plug-in card or GPIB switch box.

Figure 1. Each UUT requires two DPST relays for a four-wire measurement.

The easiest way to program a switch card to scan through all the devices is with a “for” loop (see Fig. 2 and Listing 1). This technique relies on software to sequence through switch settings; the speed at which the code runs depends on the computer architecture and on the application development environment (ADE). I tested this technique using LabView 5 and Visual Basic 4 on the same PC. Table 1 shows the results for each program—the difference in speed was negligible.

A for-next loop may be the easiest method to program, but it’s also the slowest to execute. You can gain speed by loading a preprogrammed scan list into the switch card’s memory. On VXIbus systems, you also can load the scan list into the slot-0 controller. Then, a software trigger initiates the scan list to operate the switches.

You’ll find that there’s more than one way to program a switch card’s scan sequence. I compared the scan speed of a switch card by programming the registers through the card’s VXIplug&play driver, then through the VXIbus’ hardware triggers.

A VXIplug&play driver embeds the direct register calls in functions that you call from your applications program. I configured the card as a 1x16 four-wire scanner, the same configuration I used in the software-only approach in Figure 1. Listing 2 shows how to program a switch card using its VXIplug&play driver.

The VXIbus provides for tight timing coordination between instruments across the backplane through TTL trigger lines. Using the code in Listing 3 and the scan list from the first two examples, I programmed the card to advance through its scan list upon receipt of a TTL trigger (TTLT0) initiated by the slot-0 controller (see Fig. 3).

I also set the switch card to produce a trigger on TTLT1 once the relays settled, and I programmed the VXIbus DMM card to take a measurement upon receiving the TTLT1 trigger from the switch card. After that, the DMM card resets trigger TTLT0, which causes the switch card to advance to the next set of switch settings.

This technique almost completely “removes” the switch card from regular interaction with the host PC and your applications program software. The switch card advances through the scan list, initiating the DMM measurements under hardware control. As Figure 3 shows, the application program polls a register on the switch card that contains the current location in the switch scan sequence. When the application program detects the end of the scan sequence, indicating the DMM has taken the final measurement, the program reads the test results from the DMM’s internal memory. This readback process takes negligible time because you can gain access to the DMM’s memory through its hardware registers.

I tested switching times with a for-next loop, a software scan sequence, and a scan sequence using hardware handshaking. I heard an audible difference between hardware- and software-controlled scans as the individual clicks of the relays advancing through the sequence were much more noticeable using the software advance.

I measured switch times from the beginning of the first relay closure to the final DMM measurement. I didn’t include device setup times in the overall test time. Table 1 lists the insignificant difference between the for-next software loop and the scan list using a software trigger. When triggered by hardware, the switch card and DMM test times decreased from more than 300 ms to 80 ms.

The DMM can affect the overall throughput of the test system. I used my company’s VM2710A 6.5-digit DMM to record the load measurements. To get 6.5-digit accuracy with a DMM typically requires line-cycle integration, which occurs over 1 to 10 power-line cycles. Therefore, at least one cycle of power (16.7 ms) must occur before the DMM provides 6.5 digits of resolution. I set my DMM to 4.5-digit mode with a software command, which reduces the DMM’s impact on throughput. In most high-throughput applications, this resolution setting is more than adequate. T&MW

Tom Sarfi is technical support manager for the East Coast at VXI Technology. He has a B.S.E.E. from Case Western Reserve University, Cleveland, OH. tsarfi@vxitech.com.