Shared Memory Melds Tester's Dual Controllers

Why use two computers? For two reasons, says Matt Wright, senior electrical engineer for CACI, the San Antonio, TX, contractor assigned to the job: high performance and ease of update. “We wanted something that was fast enough to handle the data, not just when collecting it during tests, but afterward when doing in-depth analyses, too.” Having one computer run the system software while another runs a test program also makes it easier to change instruments and update software, especially since, in the Air Force, two people usually manage system software and test program software.

The resulting system, Engine Test/ Trim Automated System II (ETTAS II), comprises two 13-slot VXIbus chassis mounted in one 19-in. rack. An MXI-2 extender connects them. In all, the two chassis hold 14 VXIbus instruments, two MXI-2 interface modules, and a 200-MHz Pentium Pro embedded computer. The external computer, a 266-MHz Pentium II machine, also sits in the rack. The software in both computers runs on Windows NT.

Wright and other test engineers wanted two computers so each of the two major parts of the software could run on its own processor. They rejected an approach using one dual-processor computer because of a lack of COTS software that could take full advantage of a dual-processor system. Moreover, the test system’s twin main roles—an interface to the engine under test and to the operator—guided the decision to have one embedded computer and one external computer.

In Figure 1, the embedded computer runs the system software that manages the engine interface. That software controls and monitors the instruments by configuring them, checking for error messages, and placing the acquired data into the shared memory. The embedded computer’s location—directly on the VXIbus—affords fast access to the test instruments.

Figure 1. The embedded computer in the dual-computer VXIbus test system acquires data from all channels on every instrument and assembles that data in shared dual-port memory. The external computer reads that data, parses it, and extracts those parameters needed for the UUT-specific test program. (Courtesy of CACI.)

System Setup
The external computer is the system’s slot-0 (logical address 0) controller; it connects to the VXIbus through an MXI-2 interface. To simplify resource management, the engineers set the external computer to operate as a register-based, rather than a message-based, device. A 2-Mbyte segment of VXIbus memory on the external computer serves as fast, temporary storage for up to two hours of acquired engine test data depending on the number of parameters and scans per second.

The embedded computer uses logical address 2. Because it’s not at logical address 0, the embedded computer’s VXIbus timeout and arbiter timeout are disabled; the MXI-2 slot-0 controller arbitrates the VXIbus. Like the external computer, the embedded computer is configured as a register-based device, letting its resource manager run asynchronously to the external computer.

Were the embedded computer configured as a message-based device, the engineers would have needed some means to ensure that the computer’s resource manager program started before that of the external computer. But the embedded computer’s system software resides in the startup folder. That’s a requirement for the computer to boot up automatically, without the need for someone to enter a user ID or password. As a register-based device, the embedded computer’s resource manager can run at any time.

Unfortunately, configuring the embedded computer as a register-based device creates a problem. Because it’s not the slot-0 controller, the embedded computer’s resource manager doesn’t set up the system’s instruments. In fact, the resource manager doesn’t even know they exist or if the embedded computer has been assigned to share memory with the external computer. In effect, the computer is just another instrument on the VXIbus. But it does need a way to control instruments.

Multistep Solution
Solving this problem takes several steps. First, the embedded computer opens a Virtual Instrument Software Architecture (VISA) session (the VISA library provides a generic way to communicate with different instrument types). In that session, the external computer’s software monitors the embedded computer’s status/control register until the external computer sets the register’s 15th bit high, enabling the A24/A32 address space shown in Figure 2. Next, the session reads the Device Type and Offset registers (defined in the VXIbus specification) to determine the size and assigned addresses of the embedded computer’s shared memory. Finally, the embedded computer modifies its resman.tbl file to include the data from those registers. At this point, the embedded computer is aware of, and has access to, its own shared memory.

Figure 2. The shared memory space contains the resource manager (resman) table from the external computer, setup data for the instruments, and the current test values. (Courtesy of CACI.)

The Air Force test engineers found the asynchronous data exchange acceptable because the embedded computer, which updates the memory about 200 times a second, sets a memory-error bit after writing the data to memory. The external computer retrieves data about 150 times a second. By reading the memory-error bit, the external computer knows the data it is reading is fresh. After reading the data, the external computer resets the bit. What’s more, both computers run fast enough so any data missed by the slower retrieval rate isn’t critical to the tests.      T&MW

Acknowledgement
I wish to thank Matthew Wright, senior engineer with CACI (San Antonio, TX), for his kind assistance.

Gil Bassak is a freelance journalist and former test engineer. He lives in Ossining, NY.