Reads data from a session as an array of LIN frames. The session must use a LIN interface and a mode of Frame Input Stream, Frame Input Queued, or Frame Input Single-Point.


icon

Inputs/Outputs

  • cgenclassrntag.png session in —

    session in is the session to read. This session is selected from the LabVIEW project or returned from the XNET Create Session VI. The session mode must be Frame Input Stream, Frame Input Queued, or Frame Input Single-Point.

  • ci32.png number to read (-1) —

    number to read is the number of frame values desired. If number to read is positive (or 0), the data array size is no greater than this number. If number to read is negative (typically –1), all available frame values are returned. If number to read is negative, you must use timeout of 0. This input is optional. The default value is –1. If the session mode is Frame Input Single-Point, set number to read to either –1 or the number of frames in the sessions list. This ensures that the XNET Read (Frame LIN) VI can return the current value of all session frames.

  • cdbl.png timeout (0) —

    timeout is the time to wait for number to read frame values to become available. The timeout is a LabVIEW relative time, represented as 64-bit floating-point in units of seconds. If timeout is positive, the XNET Read (Frame LIN) VI waits for number to read frame values, then returns that number. If the values do not arrive prior to the timeout, an error is returned. If timeout is negative, the XNET Read (Frame LIN) VI waits indefinitely for number to read frame values. If timeout is zero, the XNET Read (Frame LIN) VI does not wait and immediately returns all available frame values up to the limit number to read specifies. This input is optional. The default value is 0.0. If the session mode is Frame Input Single-Point, you must leave timeout unwired (0.0). Because this mode reads the most recent value of each frame, timeout does not apply.

  • cerrcodeclst.png error in (no error) —

    The error in cluster can accept error information wired from VIs previously called. Use this information to decide if any functionality should be bypassed in the event of errors from other VIs. The pop-up option Explain Error (or Explain Warning) gives more information about the error displayed.

  • igenclassrntag.png session out —

    session out is the same as session in, provided for use with subsequent VIs.

  • i1dcclst.png data —

    data returns an array of LabVIEW clusters. Each array element corresponds to a frame the session receives. For a Frame Input Single-Point session mode, the order of frames in the array corresponds to the order in the session list. The elements of each cluster are specific to the LIN protocol. For the Frame Input Stream session mode, LIN frames are read in their raw form, without interpretation of their elements using the database. For the Frame Input Single-point and Frame Input Queued session modes, information from the database is used to interpret the LIN frames for ease of use. The following cluster description applies to session modes Frame Input Single-point and Frame Input Queued. For these modes, the cluster elements are:

  • iatrn.png timestamp —

    timestamp represents the absolute time when the XNET interface received the frame (end of frame), accurate to microseconds. The timestamp uses the LabVIEW absolute timestamp type.

  • i1du8.png payload —

    payload is the array of data bytes for the LIN data frame. The array size indicates the received frame's payload length. According to the LIN protocol, this payload is 0–8 bytes in length. If the frame payload is used within an event-triggered schedule entry (slot), the first byte of payload is the identifier of the frame in its protected form (checksum applied). This is required by the LIN standard even if the frame transmits in an unconditional or sporadic slot. For this type of LIN frame, the actual data (for example, signal values) is limited to 7 bytes. For example, assume that frame ID 5 is received in an unconditional slot and an event-triggered slot of ID 9. When you receive from the unconditional slot, identifier is 5, event slot? is false, event ID is 0, and the first payload byte contains 5 with checksum applied. When you receive from the event-triggered slot, identifier is 5, event slot? is true, event ID is 9, and the first payload byte contains 5 with checksum applied. Regardless of how the frame is received, you can use the identifier to determine the contents of the actual payload data contents in bytes 2–8.

  • iu32.png identifier —

    identifier is the LIN frame identifier. The identifier is a number from 0 to 63. This number identifies the content of the data contained within payload. The location of this ID within the frame depends on the value of event slot?. If event slot? is false, this ID is taken from the frame's header. If event slot? is true, this ID is taken from the first payload byte. This ensures that the number identifies the payload, regardless of how it was scheduled. Regardless of its location, this is the unprotected ID, without parity applied.

  • iu8.png type —

    type is the frame type (decimal value in parentheses):

  • iu8.png event ID —

    event ID is the identifier for an event-triggered slot (event slot? true). When event slot? is true, event ID is the ID from the frame's header. The event ID is a number from 0 to 63. This is the unprotected ID, without parity applied. When event slot? is false, this value does not apply (it is 0). For a stream input session only, if Interface:LIN:Checksum to Input Stream? is false (default), event ID contains 0 for each frame. If true, event ID contains the received checksum for each frame.

  • ibool.png event slot? —

    event slot? is a Boolean value that specifies whether the frame was received within an event-triggered schedule entry (slot). If the value is true, the frame was received within an event-triggered slot. If the value is false, the frame was received within an unconditional or sporadic slot. When this value is true, event ID contains the ID from the frame's header.

  • ibool.png echo? —

    echo? is a Boolean value that determines whether the frame was an echo of a successful transmit (true), or received from the network (false). This value is true only when you enable echo of transmitted frames by setting the XNET Session Interface:Echo Transmit? property to True.

  • ierrcodeclst.png error out —

    The error out cluster passes error or warning information out of a VI to be used by other VIs. The pop-up option Explain Error (or Explain Warning) gives more information about the error displayed.

  • i1dcclst.png unused payloads —

    payload is the array of data bytes for the LIN data frame. The array size indicates the received frame's payload length. According to the LIN protocol, this payload is 0–8 bytes in length. If the frame payload is used within an event-triggered schedule entry (slot), the first byte of payload is the identifier of the frame in its protected form (checksum applied). This is required by the LIN standard even if the frame transmits in an unconditional or sporadic slot. For this type of LIN frame, the actual data (for example, signal values) is limited to 7 bytes. For example, assume that frame ID 5 is received in an unconditional slot and an event-triggered slot of ID 9. When you receive from the unconditional slot, identifier is 5, event slot? is false, event ID is 0, and the first payload byte contains 5 with checksum applied. When you receive from the event-triggered slot, identifier is 5, event slot? is true, event ID is 9, and the first payload byte contains 5 with checksum applied. Regardless of how the frame is received, you can use the identifier to determine the contents of the actual payload data contents in bytes 2–8.

  • i1du8.png payload —

    payload is the array of data bytes for the LIN data frame. The array size indicates the received frame's payload length. According to the LIN protocol, this payload is 0–8 bytes in length. If the frame payload is used within an event-triggered schedule entry (slot), the first byte of payload is the identifier of the frame in its protected form (checksum applied). This is required by the LIN standard even if the frame transmits in an unconditional or sporadic slot. For this type of LIN frame, the actual data (for example, signal values) is limited to 7 bytes. For example, assume that frame ID 5 is received in an unconditional slot and an event-triggered slot of ID 9. When you receive from the unconditional slot, identifier is 5, event slot? is false, event ID is 0, and the first payload byte contains 5 with checksum applied. When you receive from the event-triggered slot, identifier is 5, event slot? is true, event ID is 9, and the first payload byte contains 5 with checksum applied. Regardless of how the frame is received, you can use the identifier to determine the contents of the actual payload data contents in bytes 2–8.

    • Description

    The data represents an array of LIN frames. Each LIN frame uses a LabVIEW cluster with LIN-specific elements.

    The LIN frames are associated to the session's list of frames as follows:

    Due to issues with LabVIEW memory allocation for clusters with an array, this XNET Read VI instance can introduce jitter to a high-priority loop on LabVIEW Real-Time (RT). The XNET Read (Frame Raw) VI instance provides optimal performance for high-priority loops.