Archived: Performing Digital Data Transfers in Visual Basic with NI 6533 Family Devices

NI does not actively maintain this document.

This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.


This application note explains how to implement handshaking and pattern I/O – two ways you can transfer digital data between a DAQ device and a peripheral device, including another DAQ device – in any ActiveX control container using the Measurement Studio Digital ActiveX controls and National Instruments DAQ hardware.

With the NI 6533 Family (DIO-32HS) devices and Measurement Studio, you can use your computer for high-speed PC-to-PC data transfers and transform your data acquisition system into a digital I/O tester, logic analyzer, or system controller for laboratory testing, production testing, and industrial process monitoring and control.

Note: Measurement Studio consists of tools for building virtual instruments with Visual C++ and Visual Basic. The Measurement Studio Visual Basic tools were formerly known as ComponentWorks.



The NI 6533 Family devices have control lines that dictate when data transfers occur, and these control lines carry digital TTL (transistor-transistor logic) level signals that indicate when one device is ready to send data and the other is ready to receive the data. Handshaking devices use the Acknowledge (ACK) and Request (REQ) control lines to coordinate digital data transfers between the two devices. The input device uses a control line to signal that it is ready to receive new data. The output device uses the other control line to indicate that new data is available on the data lines. The timing of the ACK signal that is sent to the peripheral device and of the REQ signal that is expected from the peripheral device is determined by a handshaking protocol. Handshaking protocols define how a buffer of digital data is transferred between two devices. Data transfer occurs only when both devices signal that they are prepared to provide or accept new data.

Note: To learn about handshaking protocols and the corresponding behavior for the control lines, refer to Digital I/O Applications.

Measurement Studio supports both asynchronous and synchronous handshaking. In asynchronous handshaking, each device controls one control line that it uses to inform the other device that it is ready for data transfer. The exact protocol you select determines the timing of the control lines. Measurement Studio includes the following asynchronous handshaking protocols: Level, Edge (including Leading Edge, Trailing Edge, and Long Pulse), and 8255 emulation.

Note: Check the documentation for your peripheral devices to determine which protocols are valid.

Each mode specifies the conditions for a single data value to be transferred between two devices. The control lines must change state and be reactivated before additional data can be transferred.

Synchronous handshaking uses three control lines for data transfer -- one control line from each device and one shared clock line. Use synchronous or clocked protocol to achieve a higher data transfer rate. The NI 6533 Family devices perform synchronous data transfer through the burst mode protocol. In burst mode, the ACK and REQ lines are used in addition to a shared clock (named PCLK) that one of the devices controls. When both the ACK and REQ signals are active, data transfer occurs on each rising edge of the PCLK signal. Either device can pause the data transfer by de-asserting its control line. Transfer is sustained at the frequency of the clock signal when both lines are asserted.

See Also:
Digitial I/O Applications

Pattern I/O

Pattern I/O transfers data at a predetermined frequency. It is not a handshaking mode, but rather a method of transferring digital data at a predetermined frequency without control lines. You can use pattern I/O to perform both input and output operations. The frequency at which data is transferred is determined by the signal connected to the REQ line. This timing signal can be generated externally or the DAQ device can generate its own internal REQ pulse. When the DAQ device generates internal requests, the request pulse is present on the REQ line by default.

Tip: Use pattern I/O only with devices that can sustain the data transfer rate.

Handshaking and Pattern I/O with Measurement Studio

Measurement Studio offers two controls for handshaking and pattern I/O. Use the Measurement Studio Digital Input (CWDI) ActiveX control to perform buffered handshaking and pattern input operations, and the Measurement Studio Digital Output (CWDO) ActiveX control to perform buffered handshaking and pattern output operations.

Begin by placing either the CWDI or CWDO control on the user interface form. Use the CWDI control for digital input operations and the CWDO control for digital output operations. Right click on the control and select Properties. This section explains how to use the property pages to configure the controls for handshaking and pattern I/O. The rest of this application note uses examples to demonstrate how to control digital data transfers programmatically.

Configuring Your Device and Digital Operation

Use the General property page to select a digital device, the ports for the data transfer, and the buffer size and duration (continuous or finite) of the data transfer, as shown in Figure 1. The configuration in Figure 1 sets a CWDI control to input a continuous buffer of data through ports 0 and 1 on a PCI-DIO-32HS board.

Note Make sure your device can perform buffered digital data transfers

Figure 1. Configuring Your Device and Operation

Use the Channel string property to specify the group (or list of ports) involved in the data transfer. In this example, the CWDI control is retrieving data from ports 0 and 1. You can specify multiple ports with a comma-delimited list.

Note: Search for ChannelString in the Measurement Studio Reference for information about which ports can be used for buffered digital I/O.

Continuous indicates that the data will be transferred in a buffer and Measurement Studio will continue reading or writing data until the Reset method is called or an error occurs.

The Number of patterns property specifies the number of patterns per port that are stored in the buffer. For two or more port operations, the buffer size is calculated as (Number of patterns)* (number of ports specified in Channel string). For example, if Number of patterns is 1000 and there are two ports, the buffer contains a total of 2000 patterns.

According to the configuration shown in Figure 1, as soon as the buffer contains the requested number of patterns, the AcquiredData event is generated and the whole buffer of data is returned to the event. Alternatively, you can use the Progress event with the CWDI or CWDO control to return an intermediate number of patterns that have been transferred from or written to the buffer.

When you are reading from two or more ports, keep in mind that data is interleaved by port. For example, if you want to process data from only one port in a two-port operation, extract one item, skip the next, extract the next, and so on.

If you are writing data to two or more ports, you must interleave the data by port. For example, imagine that you are generating 100 patterns of data for ports 0 and 1 in an array named Waveform. Waveform needs to be an array of 200 points. During the first update, Waveform(0) is written to port 0 and Waveform(1) is written to port 1. During the next update, Waveform(2) is written to port 0 and Waveform(3) is written to port 1, and so on.

Setting Handshaking Properties
Use the Handshaking property page to set the handshaking mode and properties for timing and behavior of the control lines. For example, Figure 2 sets handshaking properties for leading-edge handshaking with a 100 ns delay in the Acknowledge pulse.

Figure 2. Setting Handshaking Properties

Note: You don’t need to set any properties on this page if you are using pattern I/O.

The following list describes the handshaking properties you need to set on this property page:

  • Signal mode specifies the handshaking protocol as Level, Edge, 8255 emulation, or burst mode. If you set signal mode to Edge, you must specify Edge mode and Acknowledge modify mode, as listed in the following table. Edge mode indicates whether the leading or trailing edge of the pulse on the control line will initiate data transfer.
    Edge mode
    Acknowledge modify mode
    Leading EdgeLeadingDelay pulse or No modification
    Trailing EdgeTrailingDelay pulse or No modification
    Long PulseLeading or TrailingChange duration
  • With the Acknowledge modify mode property, you can delay the acknowledge pulse or change its duration. Set the delay time in Acknowledge pulse delay and the pulse duration in Acknowledge pulse duration. The delay occurs at different times depending on the protocol. Refer to Application Note 131, Digital I/O Applications, for information about the programmable delays for different protocols.
Note: To configure a long pulse protocol, select Edge signal mode and specify the duration of the ACK signal.

If you want to set the acknowledge pulse delay or the acknowledge pulse duration programmatically, use the AcknowledgeModifyAmount property, as in the following examples:

'Delay Acknowledge pulse by 100 ns
CWDI1.Handshake.AcknowledgeModifyMode = cwdioAckModeDelay
CWDI1.Handshake.AcknowledgeModifyAmount = cwdioAckAmt100ns

'Set the acknowledge pulse duration to 200 ns
CWDI1.Handshake.AcknowledgeModifyMode = cwdioAckModeDuration
CWDI1.Handshake.AcknowledgeModifyAmount = cwdioAckAmt200ns
  • Acknowledge polarity and Request polarity specify the polarity of the Acknowledge and Request handshaking signals as either an active high signal or an active low signal. Refer to the documentation for your peripheral device to select a setting that is compatible with the device. The 8255 emulation protocol defines the polarities, so you can’t set or modify properties for 8255 emulation.
  • Ack Req Exchange puts the ACK signal on the REQ pin and the REQ signal on the ACK pin to facilitate transfer between two NI 6533 devices. On one group, exchange the ACK and REQ lines so that ACK lines on each device can be connected together and the REQ lines on each device can be connected together.
  • Clock Reverse changes the PCLK from its default setting for burst mode. The default setting of the PCLK is internal for burst mode input operations and external for burst mode output operations. You can programmatically set ClockReverse to True if your application requires an external PCLK for burst mode input operations or internal PCLK for burst mode output operations. For an external PCLK, connect a clock signal to the PCLK pin on the I/O connector. The following input example uses an internal PCLK frequency of 10 MHz:
CWDI1.Handshake.SignalMode = cwdioSignalBurst
CWDI1.Handshake.ClockReverse = False
CWDI1.Handshake.PCLKFrequency = cwdioPCLK_10MHz

Example -- Burst Mode Input with External PCLK

The following code example demonstrates how to configure a burst mode input operation using an external PCLK signal. Before you run this example, connect the clock source to PCLK1 (pin 5 on the 32HS connector). Connect the control line from the external device to REQ1 (pin 2). Connect ACK1 to the external device. To simulate an external device, you can set REQ1 to active low. REQ1 is always asserted and ready for data transfer.

CWDI1.Device = 1
CWDI1.ChannelString = "0:1"
'Number of patterns
CWDI1.NPatterns = 1000

'Generate AcquiredData event to return data
CWDI1.AcquiredDataReturnData = True

'Set handshaking properties
CWDI1.UpdateClock.ClockSourceType = cwdioCSIOConnector
CWDI1.Handshake.SignalMode = cwdioSignalBurst
CWDI1.Handshake.AcknowledgePolarity = cwdioActiveHigh
CWDI1.Handshake.RequestPolarity = cwdioActiveLow

'Set the PCLK to an external source
CWDI1.Handshake.ClockReverse = True

'To use an internal PCLK, you would need to modify
'the example as follows:
'CWDI1.Handshake.ClockReverse = False
'CWDI1.Handshake.PCLKFrequency = cwdioPCLK_10MHz


After the buffer contains 2000 patterns (1000 from port 0 and 1000 from port 1), the AcquiredData event is generated and the data is returned. From the AcquiredData event, you can display the data in a Measurement Studio CWGraph ActiveX control, analyze it, or save it to a file.

Setting Pattern Generation Properties
The update clock controls when data is transferred. For most handshaking operations, you’ll set the clock source type to I/O connection because data transfer is usually driven by the ACK and REQ lines on the I/O connector. However, you can route the ACK and REQ signals from another device across the RTSI bus. Pattern I/O can use the internal clock or receive an external clock signal on the REQ line or across the RTSI bus from another device.

For pattern I/O, use an internal clock source and specify the clock settings either in terms of scans/second or seconds/scan or specify a frequency and divisor for the internal clock. Figure 3 shows how you might configure pattern output with an internal clock at 500,000 scans/second.

Figure 3. Pattern I/O Using the Internal Clock

If you use an external clock for pattern I/O, connect the clock source to the REQ input on the I/O connector or route it to the REQ input through a RTSI line.

Example -- Pattern I/O

This example shows you how to set up a pattern output operation programmatically. You do not need to set any properties on the Handshaking tab or on the Handshake object for pattern I/O. To generate data at a specified rate, select an internal clock frequency:

CWDO1.Device = 1

CWDO1.ChannelString = "0:1"
'Number of patterns
CWDO1.NPatterns = 2500

'Generate Progress event each time half the
'buffer is written
CWDO1.ProgressInterval = CWDO1.NPatterns / 2
CWDO1.Continuous = False

CWDO1.UpdateClock.ClockSourceType = cwdioCSInternalClock
CWDO1.UpdateClock.Frequency = 1000

'wfm contains interleaved data patterns
'One routine that can be used to build these data patterns is BuildDIOData().
CWDO1.Write wfm

You can modify the example to perform continuous generation of the same digital patterns. The following code configures the CWDO control to output the entire buffer and continuously loop back to the first point in the buffer and output it again:

CWDO1.Continuous = True
CWDO1.AllowRegeneration = True

Now that the generation is continuous, you can use the Progress event to supply new waveform data to the buffer. The Progress event is generated when the number of patterns specified by ProgressInterval has been written out. Use the Progress event to notify your program that a portion of the data buffer (equal to ProgressInterval) has been generated and needs to be updated, as in the following example:

Private Sub CWDO1_Progress(PatternCount As Variant)
     Dim wfm

     'Write new data to the buffer. wfm contains interleaved data patterns.
     'One routine that can be used to build these data patterns is BuildDIOData().
     'For example, wfm = BuildDIOData(CWDO1.NPatterns / 2, CWDO1.NPorts)

    CWDO1.Write wfm
    ‘Display the data on a graph
    PlotIndividualDigitalLines_CWGraph1, wfm
End Sub

Tip: This example uses the PlotIndividualDigitalLines subroutine. This subroutine displays the data from each digital line as a separate plot.

Handshaking with RTSI Bus Signals

If you want to test your DAQ system before connecting it to external devices, you can connect two DAQ devices over the RTSI bus. When handshaking data between NI 6533 devices, you want the ACK signal from each device connected to the REQ signal of the other. If you use a standard SH6868-D1 cable to cable the two devices together, they are by default connected ACK to ACK and REQ to REQ. To make the correct ACK to REQ connections, set AckReqExchange to True for one device, and than program the remaining handshaking properties as normal.

Alternatively, it might be more convenient to route the REQ, ACK, and PCLK signals over the RTSI bus rather than wiring the signals into the I/O connector when working with multiple NI 6533 devices in the same computer. To make these signals available on the RTSI bus, set ClockSourceType to cwdioCSRTSI and call the RouteRTSI method on the CWDAQTools control for each signal, as in the following example:

'Set update clock to a RTSI connection
CWDO1.UpdateClock.ClockSourceType = cwdioCSRTSI

'Configure REQ1(signal 0) to be received on
'RTSI trigger line 0
CWDAQTools1.RouteRTSI deviceNum, cwRouteRTSIControlConnect, _
 0, 0, cwRouteRTSIDirBoardReceive, map

'Configure ACK1(signal 2) to be transmitted on RTSI
'trigger line 1
CWDAQTools1.RouteRTSI deviceNum, cwRouteRTSIControlConnect, _
 2, 1, cwRouteRTSIDirBoardTransmit, map

Note The Measurement Studio DAQTools (CWDAQTools) ActiveX control provides utility functions for the DAQ controls. The RouteRTSI method has the following prototype:

CWDAQTools.RouteRTSI Device, Control, Signal, Trigger, Direction, UseMap

Device is the device number of your DAQ device. Control specifies the operation performed by the function. Set Control to cwRouteRTSIControlConnect to connect the device signal to the trigger line as identified by these two input parameters. Signal is one of the signal codes shown in Table 1. Trigger is the RTSI bus trigger line that is connected to the signal (0 - 6). Direction specifies the direction of the RTSI connection. If Control is cwRouteRTSIControlConnect, Direction specifies whether the device receives the signal from the bus or transmits the signal to the bus. UseMap is an integer array that on output provides a list of free and busy RTSI trigger lines. Refer to the Measurement Studio Reference for more information about CWDAQTools and the RouteRTSI method.

The following example shows how to configure the second device to receive the REQ signal on line 1 and to send the ACK signal on line 0. When the application completes, call RouteRTSI to disconnect the signals from all four trigger lines.

'Configure REQ1(signal 0) to be received on RTSI
'trigger line 1
CWDAQTools1.RouteRTSI deviceNum, cwRouteRTSIControlConnect, _
 0, 1, cwRouteRTSIDirBoardReceive, map

'Configure ACK1(signal 2) to be transmitted on RTSI
'trigger line 0
CWDAQTools1.RouteRTSI deviceNum, cwRouteRTSIControlConnect, _
 2, 0, cwRouteRTSIDirBoardTransmit, map

The following table lists the signals that might be available on the RTSI line for NI 6533 Family devices.

Table 1. DIO-32HS RTSI Bus Signals
Signal Name
Signal Direction
Signal Code
Signal Description
Group 1 Request Line. In handshaking mode, a group’s REQ line carries handshaking status information from the peripheral device; in pattern I/O mode, a clock.
Group 2 Request Line. In handshaking mode, a group’s REQ line carries handshaking status information from the peripheral device; in pattern I/O mode, a clock.
Group 1 Acknowledge Line. In handshaking mode, a group’s ACK line carries handshaking control information to the peripheral device.
Group 2 Acknowledge Line. In handshaking mode, a group’s ACK line carries handshaking control information to the peripheral device.
Group 1 Peripheral Clock Line. In burst mode only, these lines carry clock signals to or from the peripheral device.
Group 2 Peripheral Clock Line. In burst mode only, these lines carry clock signals to or from the peripheral device.
Group 1 stop trigger. Currently not available with Measurement Studio.
Group 2 stop trigger. Currently not available with Measurement Studio.

Was this information helpful?