Advanced Synchronization Techniques for Data Acquisition

Application Note 128 Advanced Synchronization Techniques for Data Acquisition Introduction Brad Turpin Many of today s instrumentation solutions require sophisticated timing of a variety of I/O functions (such as analog input, analog output, and digital I/O). PXI and data acquisition (DAQ) hardware offer an ideal solution to many of these timing needs with their very precise, modular, and easy-to-program synchronization features. A common class of test systems with some of the most demanding timing requirements is the stimulus-response system. The stimulus-response system is characterized by reacting to one or more simultaneous excitation pulses by emitting one or more simultaneous signal pulses, usually after a known and very short time delay. In many cases, this stimulus-wait-response cycle repeats rapidly and continuously. In all cases, the instrumentation challenge of creating such a stimulus-response system is synchronizing the various output stimulus signals with respect to the acquisition of the response signals with a precisely timed delay. PXI and DAQ answer the need for test systems that require precision synchronization and timing. You use the RTSI bus, which exists natively on the PXI backplane and automatically connects every PXI module inserted into the chassis, to route timing control signals between one or more PXI DAQ modules. This ensures perfect synchronization of your various acquisition and control processes, even when they occur on separate PXI modules. For test applications that require precise timing delays, such as stimulus-response systems, use the DAQ-STC (24-bit, 20 MHz) programmable counters on our PXI multifunction I/O DAQ to perform retriggerable pulse generation. With retriggerable pulse generation, you can generate pulses at a user-specified delay from your stimulus timing signal. With the DAQ-STC, your delay is accurate to within 50 ns. Product and company names are trademarks or trade names of their respective companies. 341575A-01 Copyright 1998 National Instruments Corporation. All rights reserved. October 1998

There are many ways to implement a system like this, but we will demonstrate the techniques required by walking through a specific example, Synchronized AI, AO, DI, DO, CTR.vi. In this example, the measurement system stimulates a unit under test (UUT) with both analog output (AO) and digital output (DO). After a user-specified delay, the system measures the UUT response by taking analog input (AI) and digital input (DI) data. This application also hardware time-stamps each stimulus-response cycle. The way to view this application is as a template. Pay particular attention to the structure of the program and the concept of establishing two system pulses (stimulus and response) from which all operations take their respective clocks. The functioning of this particular application will be explained in detail here, but you will likely need to adapt it to your particular measurement needs. There is a list of possible adaptations at the very end of this document to assist you in that effort. The Synchronized AI, AO, DI, DO, CTR.vi can be found on our ftp site at: ftp://ftp.natinst.com/support/labview/demos 2

Hardware Requirements One E Series board [multifunction I/O] One 6533/DIO-32HS board [high-speed digital I/O] All boards should have their RTSI lines connected together; for non-pxi systems this means physically connecting all boards with external RTSI cables; for PXI systems the RTSI connection is made automatically across the PXI Trigger Bus. Analog Output Digital Output Buffered Time-Stamping RTSI 1 (stimulus) Analog Input Digital Input RTSI 2 (response) Time Delay Synchronization Scheme There are two RTSI lines that are used to synchronize the various activities (AI, AO, DIO, CTR) of this application RTSI 1 and RTSI 2. The fundamental timing principle of this application is that there are two classes of activities: Those that stimulate or set the state of the UUT, clocked from RTSI 1 Those that measure the state or response of the UUT, clocked from RTSI 2 There is a brief, user-selectable time delay between the stimulus pulse on RTSI 1 and the response pulse on RTSI 2. The figure above illustrates these relationships. This time delay is achieved by setting up a general-purpose counter (GPCTR1) to send out a retriggerable delayed output pulse to RTSI 2 every time the RTSI 1 stimulus pulse arrives at its gate. Program Structure The fundamental programming structure used in this application is a State Machine (Case Statement inside a While Loop). The State Machine is a splendid construct and is used extensively in complex instrumentation solutions. Its main advantages are: 1. It divides your code into logical groups (frames). 2. In G programming, it uses a fraction of the screen space for easier viewing. 3. It is very modular in design, enabling you to add frames of code as new ideas arise without confusing the appearance of the code. 4. Most importantly, it gives you complete control over the execution order of the individual frames, even allowing frames to be revisited more than once or the entire process restarted without ever leaving the State Machine structure itself. This is particularly helpful in the debugging phase of creating a program. 3

In this VI, the execution order of the State Machine is constant and sequential it was chosen over a regular Sequence Structure only because of the superior appearance of the shift registers in the While Loop compared with the equivalent solution using sequence locals in a Sequence. The nine code frames of this program are, in order: Frame 0: Initialize STC 0 Initialize GPCTR 0 to generate retriggerable delayed pulses. Frame 1: Initialize AO Initialize analog output, using external hardware timing. Frame 2: Initialize AI Initialize analog input, using external hardware timing Frame 3: Initialize DO Initialize digital output, using external hardware timing Frame 4: Initialize DI Initialize digital input, using external hardware timing. Frame 5: Initialize STC 1 Initialize GPCTR 1 to perform time-stamping. Frame 6: Set and Wait Starts all the I/O operations and waits for completion. Frame 7: Read and Analyze Reads the input data (AI, DI, and GPCTR 1). Frame 8: Shut Down Clears all activities and RTSI line connections. Frame 0: Initialize STC 0 This frame contains the details of the phase delay between the stimulus pulse (RTSI 1) and the response pulse (RTSI 2). In CTR Mode Config.vi, RTSI 1 is mapped to the gate of GPCTR 0, which sets up the counter to output a single pulse each time a stimulus pulse on RTSI 1 is received. In CTR Pulse Config.vi, GPCTR 0 is then configured to wait a certain number of counter periods (at 20 MHz) between the high pulse at its gate (from RTSI 1) and its output pulse, resulting in a phase-delayed pulse train clocked by RTSI 1. In Route Signal.vi, the output of GPCTR 0 is mapped to RTSI 2, which completes the set up of the phase delay between RTSI 1 and RTSI 2. GPCTR 0 is now armed and waiting for RTSI 1 to start it pulsing on RTSI 2. 4

Frame 1: Initialize AO This frame is where the single-buffered analog output activity is set up and also where the stimulus pulse in this particular application originates. In AO Config.vi, the MIO board is configured to execute analog output on AO ch0, and in AO Write.vi, the analog output data is written to the analog output buffer. Because this application uses the analog output update clock to set the stimulus signal, the update clock is mapped to RTSI 1 in Route Signal.vi. For that same reason the final AO Start.vi that will begin the entire set of stimulus-response activities (analog output, analog input, digital output, digital input, and counter time-stamping) is not executed until all these other functions have been configured and armed. Any of these activities (except for the time-stamping) could have served as the stimulus signal source by simply routing their particular clock (AO update, AI startscan, REQ 1, REQ 2) to RTSI 1 instead of AO update and delaying their software start (AO Start.vi, AI Start.vi, DIO Control.vi) until all the others have been configured and armed. In this particular application, though, the analog output was selected as the source of the stimulus clock, and it is now fully configured and ready to be started. 5

Frame 2: Initialize AI This frame configures the single-buffered analog input to be clocked by the response pulses (RTSI 2) and arms the analog input operation to start as soon as that line begins pulsing. In AI Config.vi, the MIO board is configured to acquire a user-defined number of scans on AI ch1 and AI ch2. In AI Clock Config.vi, the scan clock of the analog input acquisition is mapped from RTSI 2, where the response pulse resides. In AI Control.vi, the analog input acquisition is armed, and it will start as soon the analog output update clock begins to send the stimulus pulses on RTSI 1 to GPCTR 0, which in turn begins the response pulses on RTSI 2. 6

Frame 3: Initialize DO This frame sets up a single-buffered digital output operation clocked by the stimulus pulses on RTSI 1. In RTSI Control.vi, the REQ 1 line, which clocks each digital state update, is mapped to the stimulus signal on RTSI 1. In DIO Config.vi, the DIO device is configured to execute buffered digital output on Port 0. In DIO Write.vi, the desired sequence of digital states for Port 0 are written to the buffer, and in DIO Start.vi the digital output operation is armed and now waits for the stimulus pulse on RTSI 1 to start it updating. 7

Frame 4: Initialize DI This frame sets up a single-buffered digital input operation clocked by the response pulses on RTSI 2. In RTSI Control.vi, the REQ 2 line, which clocks each digital state latch, is mapped to the response signal on RTSI 2. In DIO Config.vi, the DIO device is configured to execute buffered digital input on Port 2, and in DIO Start.vi the digital input operation is armed and now waits for the response pulse on RTSI 2 to clock the digital state latch. 8

Frame 5: Initialize STC 1 This frame sets up your remaining general-purpose counter (GPCTR 1) to execute buffered time counting and read the count value every time a stimulus pulse occurs on RTSI 1. In CTR Group Config.vi, GPCTR 1 on the MIO board is configured for buffered counting, while in CTR Buffer Config.vi the counter buffer size (equal to the total number of analog output updates) is allocated. In CTR Mode Config.vi, GPCTR 1 is set to be gated by the stimulus pulse on RTSI 1, so that each time a stimulus pulse occurs the count value at that instant will be logged in the counter buffer. In this way the counter is used to perform hardware time-stamping of each stimulus pulse. Finally in CTR Control.vi, the time counting of GPCTR is started, prior to the beginning of the actual stimulus-response processes. The count value of the first item in the counter buffer will therefore reflect the amount of time between the software call of CTR Control.vi up to the hardware event of the first stimulus pulse. The entire synchronized process is now armed and waiting on AO Start.vi to begin. 9

Frame 6: Set and Wait Finally, AO Start.vi gets executed, and the whole process begins AO update pulses, marking the first stimulus pulse on RTSI 1, beginning the analog output and the digital output and causing RTSI 1 to pulse, which gates GPCTR 0 to output a time-delayed response on RTSI 2. The second function of this frame is to wait until both the analog and digital data buffers are full, and hence the stimulus-response process is presumed to be over. This is accomplished by feeding zero scans to read into AI Read.vi, DIO Read.vi, and CTR Buffer Read.vi and monitoring the analog input scan backlog. When the scan backlog equals the number of scans in the analog input buffer, the data buffers are full and can be read in the next frame. If at any time during the stimulus-response process an error occurs in either the analog input, digital input, or counter input, this frame is exited, the acquisition process is aborted, and an error message is reported. If the expected number of scans is not being reached in the data buffers even though the stimulus-response process has finished, pressing the abort? button on the front panel manually causes the While Loop to be exited and the various clear functions (AI, AO, DI, DO, CTR) in Frame 8 to naturally shut down the acquisition and show any error messages. 10

Frame 7: Read and Analyze Now that the stimulus-response data is complete, this frame reads the three data buffers that were being filled in the previous frame and posts these results to indicators on the front panel. AI Read.vi returns the analog input data, which is split into two separate arrays and displayed in separate columns on the front panel. DIO Buffer Read.vi returns the digital input data, and CTR Buffer Read.vi returns the time-stamping data in raw count format. The count values are then converted to relative time values and displayed on the front panel in seconds. 11

Frame 8: Shut Down In this last frame, all the stimulus-response configurations on both boards are cleared, and the data is displayed with the array indices tied together for easier viewing. In AI Clear.vi and AO Clear.vi the analog input and output configurations are cleared from the board, in DIO Clear.vi the digital input and output configurations are cleared, and in CTR Control.vi the delay pulse settings in GPCTR0 and the time-stamping settings in GPCTR1 are cleared. Finally, in RTSI Control.vi the RTSI connections between the RTSI bus and the DIO board are reset. 12

So, Where Do I Go from Here? Remember that this application is one example of a stimulus-response program. You may not want to run all of the operations (analog input, analog output, digital input, digital output, counter time-stamping) included in this application. With the State Machine structure used in this application, it is relatively easy to eliminate operations to create a smaller application that does only what you want. The first step is to remove the frame that configures that operation (say, digital input). The next step, if it is an input operation, is to take out the read routine from Frame 7 (for example, the DIO Buffer Read.vi). Finally, remove the clear routine in Frame 8 (in this case, DIO Clear.vi). Instead of taking out operations by deleting frames, you may in fact need to add operations not included in this application by adding frames. For instance, in order to synchronize IMAQ acquisitions or motion control movements, add a frame for each to perform the configuration, clock routing, triggering, and so on; then start each action waiting on either the stimulus or response signal. For an IMAQ acquisition, you will also need to add a routine in Frame 6 to read the video images out of the RAM buffer. Another change you might need to make is to add external triggering. This application begins all operations when the AO Start.vi is run in software. You could configure the analog output (and with it the rest of the synchronized operations) to start only when an external 5 VDC digital trigger is fed into the AO Start Trigger. This can be added by changing the trigger settings in AO Start.vi in Frame 6 from the current default setting (no trigger) to the desired trigger action. A fundamental change you might need to make is to have a different operation be the master operation. This application is set up to have all operations begin when the analog output operation commences. The triggering available for analog output is limited. If you wish to do more advanced triggering, say analog triggering from PFI0 of the MIO board, or digital pattern recognition from the DIO board, then you need to change the master operation from analog output to, respectively, analog input, or digital input. An activity becomes the master operation when all other operations have been started and are waiting on the clock signal of the master operation to begin. Currently, the AO Update Clock is routed to RTSI 1, and from that all other slave operations follow. In order to make, say, the analog input operation the master, you would need to route the AI Start Scan signal to RTSI 1 instead of the AO Update signal, and then leave the AI Start.vi or AI Control.vi call to the very last after all other operations are started. Other changes you might need to make include data display, data analysis, and data logging. Currently, all data is shown on the front panel in array format. You might want to send some or all of your signals to a Waveform Graph, or perhaps use the time-stamping from GPCTR 1 as your X-axis values and put the data in an XY Graph. You may want to analyze your data first in order to display it more meaningfully, or in the case of IMAQ, to pick out a particular feature of interest and calculate its dimensions and orientation before displaying. Finally, most real-world applications have at least the option of logging the acquired data to disk. This application has no such provision, but you could certainly add a Frame 9 to take the data gathered and save it to one or more data files for future use. 13