Table Of Contents

XNET Read (State » CAN Comm) (G Dataflow)

Version:
    Last Modified: February 22, 2017

    Reads the state of CAN communication using an XNET session.

    connector_pane_image
    datatype_icon

    session in

    The session to read. This session is selected from the LabVIEW project or returned from XNET Create Session.

    datatype_icon

    error in

    Error conditions that occur before this node runs. The node responds to this input according to standard error behavior.

    Default: No error

    datatype_icon

    session out

    An output that is the same as session in, provided for use with subsequent nodes.

    datatype_icon

    CAN comm

    An output that returns a LabVIEW cluster containing the communication elements.

    datatype_icon

    communication state

    A parameter that specifies the CAN interface state with respect to error confinement. The decimal value is in parentheses:

    Error Active (0) This state reflects normal communication, with few errors detected. The CAN interface remains in this state as long as receive error counter and transmit error counter are both below 128.
    Error Passive (1) If either the receive error counter or transmit error counter increment above 127, the CAN interface transitions into this state. Although communication proceeds, the CAN device generally is assumed to have problems with receiving frames.

    When a CAN interface is in error passive state, acknowledgment errors do not increment the transmit error counter. Therefore, if the CAN interface transmits a frame with no other device (ECU) connected, it eventually enters error passive state due to retransmissions, but does not enter bus off state.

    Bus Off (2) If the transmit error counter increments above 255, the CAN interface transitions into this state. Communication immediately stops under the assumption that the CAN interface must be isolated from other devices.

    When a CAN interface transitions to the bus off state, communication stops for the interface. All NI-XNET sessions for the interface no longer receive or transmit frame values. To restart the CAN interface and all its sessions, call XNET Start.

    Init (3) This is the CAN interface initial state on power-up. The interface is essentially off, in that it is not attempting to communicate with other nodes (ECUs).

    When the start trigger occurs for the CAN interface, it transitions from the Init state to the Error Active state. When the interface stops due to a call to XNET Stop, the CAN interface transitions from either Error Active or Error Passive to the Init state. When the interface stops due to the Bus Off state, it remains in that state until you restart.

    datatype_icon

    transceiver error?

    A parameter that indicates whether an error condition exists on the physical transceiver.This is typically referred to as the transceiver chip NERR pin. False indicates normal operation (no error), and true indicates an error.

    datatype_icon

    sleep?

    A parameter that indicates whether the transceiver and communication controller are in their sleep state.False indicates normal operation (awake), and true indicates sleep.

    datatype_icon

    last error

    A parameter that specifies the status of the last attempt to receive or transmit a frame. The decimal value is in parentheses:

    None (0) The last receive or transmit was successful.
    Stuff (1) More than 5 equal bits have occurred in sequence, which the CAN specification does not allow.
    Form (2) A fixed format part of the received frame used the wrong format.
    Ack (3) Another node (ECU) did not acknowledge the frame transmit.

    If you call XNET Write and do not have a cable connected, or the cable is connected to a node that is not communicating, you see this error repeatedly. The CAN communication state eventually transitions to Error Passive, and the frame transmit retries indefinitely.

    Bit 1 (4) During a frame transmit (with the exception of the arbitration ID field), the interface wanted to send a recessive bit (logical 1), but the monitored bus value was dominant (logical 0).
    Bit 0 (5) During a frame transmit (with the exception of the arbitration ID field), the interface wanted to send a dominant bit (logical 0), but the monitored bus value was recessive (logical 1).
    CRC (6) The CRC contained within a received frame does not match the CRC calculated for the incoming bits.
    datatype_icon

    receive error counter

    A parameter that counts errors for received frames. The receive error counter begins at 0 when communication starts on the CAN interface. The counter increments when an error is detected for a received frame and decrements when a frame is received successfully. The counter increases more for an error than it is decreased for success. This ensures that the counter generally increases when a certain ratio of frames (roughly 1/8) encounter errors.

    datatype_icon

    transmit error counter

    A parameter that counts errors for transmitted frames. The transmit error counter begins at 0 when communication starts on the CAN interface. The counter increments when an error is detected for a transmitted frame and decrements when a frame transmits successfully. The counter increases more for an error than it is decreased for success. This ensures that the counter generally increases when a certain ratio of frames (roughly 1/8) encounter errors.

    When communication state transitions to Bus Off, the transmit error counter no longer is valid.

    datatype_icon

    fault?

    A parameter that indicates that a fault occurred, and its code is available as fault code.

    datatype_icon

    fault code

    A parameter that returns a numeric code you can use to obtain a description of the fault.If fault? is false, the fault code is 0.

    A fault is an error that occurs asynchronously to the NI-XNET nodes your application calls. The fault cause may be related to CAN communication, but it also can be related to XNET hardware, such as a fault in the onboard processor. Although faults are extremely rare, XNET Read (State CAN Comm) provides a detection method distinct from the error out of NI-XNET nodes, yet easy to use alongside the common practice of checking the communication state.

    To obtain a fault description, wire the fault code into the LabVIEW Simple Error Handler error code input and view the resulting message. You also can bundle the fault code into a LabVIEW error cluster as the code element and use front panel features to view the error description.

    datatype_icon

    error out

    Error information. The node produces this output according to standard error behavior.

    Description

    You can use XNET Read (State CAN Comm) with any XNET session mode, as long as the session interface is CAN. Because the state reflects the CAN interface, it can apply to multiple sessions.

    Your application can use XNET Read (State CAN Comm) to check for problems on the CAN network independently from other aspects of your application. For example, you intentionally may introduce noise into the CAN cables to test how your ECU behaves under these conditions. When you do this, you do not want the error out of NI-XNET nodes to return errors, because this may cause your application to stop. Your application can use XNET Read (State CAN Comm) to read the CAN network state quickly as data, so that it does not introduce errors into the flow of your LabVIEW nodes.

    Alternately, to log bus errors, you can set the Interface:Bus Error Frames to Input Stream? property to cause CAN bus errors to be logged as a special frame into a Frame Stream Input queue.

    Where This Node Can Run:

    Desktop OS: Windows

    FPGA: Supported


    Recently Viewed Topics