Frame Input Queued Mode

This mode reads data from a dedicated queue per frame. It enables your application to read a sequence of data specific to a frame (for example, a CAN identifier).

You specify only one frame for the session, and the XNET Read VI (LabVIEW) or nxReadFrame function (C) returns values for that frame only. If you need sequential data for multiple frames, create multiple sessions, one per frame.

The input data is returned as an array of frame values. These values represent all values received for the frame since the previous call to XNET Read VI or nxReadFrame.

In LabVIEW, if the session uses a CAN interface, the XNET Read (Frame CAN) VI is the recommended way to read data for this mode. This VI returns an array of frames, where each frame is a LabVIEW cluster specific to the CAN protocol. If the session uses a FlexRay or LIN interface, the read selection for that protocol is recommended. For more advanced applications, use the XNET Read (Frame Raw) VI, which returns frames in an optimized, protocol-independent format.

Example

In this example network, frame C is a cyclic frame that transmits on the network once every 2 ms. Frame E is an event-driven frame. For information about cyclic and event-driven frames, refer to Cyclic and Event Timing .

Each frame contains two signals, one in the first byte and another in the second byte.

This example uses CAN. The following figure shows a timeline of a frame transfer on the CAN network, followed by two calls to XNET Read VI or nxReadFrame, one for frame C and one for frame E.

The following figure shows the data returned from the two calls to XNET Read VI or nxReadFrame separate sessions for frame C and frame E.

The first call returned an array of values for frame C, and the second call returned an array for frame E. Each frame is displayed with CAN-specific elements. For information about the data returned from the read function, refer to Raw Frame Format. The example uses hexadecimal C and E as the identifier of each frame. The first two payload bytes contain the signal data. The timestamp represents the absolute time when the NI-XNET interface received the frame (end of frame), accurate to microseconds.

Compared to the example for the Frame Input Stream mode, this mode effectively sorts received frames so you can process them on an individual basis.