Fault Handling

In NI-XNET, the term error refers to a problem that occurs within the execution of a node in the block diagram (VI or property node). The term fault refers to a problem that occurs asynchronously to execution of an NI-XNET node. For example, passing an invalid session to a VI is an error, but a communication problem on the network is a fault. For more information about errors, refer to Error Handling.

Examples of faults include:

• The CAN, FlexRay, and LIN protocol standards each specify mechanisms to detect communication problems on the network. These problems are reflected in the communication state and other information.
• If you pass invalid data to the XNET Write VI , in some cases the problem cannot be detected until the data is about to be transmitted. Because the transmission occurs after the XNET Write VI returns, this is reported as a fault.

NI-XNET reports faults from a special XNET Read VI instance for the communication state. For CAN, this is the XNET Read (State CAN Comm) VI , for FlexRay this is the XNET Read (State FlexRay Comm) VI , and for LIN this is the XNET Read (State LIN Comm) VI.

The information returned from these VIs is not limited to faults. Each VI provides information about the current state of communication on the network. Because the XNET Read VI executes quickly, it often is useful within the primary loop of your application to ascertain the current network state.

Each XNET Read VI returns a cluster with various indicators. Most of the indicators provide state information that the protocol specifies, including faults (communication stopped). Faults specific to NI-XNET are reported in fault? and fault code. fault? is similar to the status of a LabVIEW error cluster, and fault code is similar to the code of a LabVIEW error cluster.

To detect a fault without stopping the execution of your VIs, you read and interpret the communication state separately from the LabVIEW error cluster flow. For example, you may want to intentionally introduce noise into CAN cables to test how your ECU behaves when the CAN bus off state occurs. The following figure shows an example block diagram for this method.

Restart on CAN Bus Off State

The block diagram detects the CAN bus off state, which means that communication stopped due to numerous problems on the bus. When CAN bus off state is detected, the block diagram increments a count and restarts the NI-XNET interface. It then waits for the interface to be reintegrated with the bus before continuing. This process of reintegrating into a CAN bus after going bus off is known as bus off recovery. Because the CAN bus off fault was not propagated as an error, the test continues to execute.

To detect a fault and propagate it to an error to break the LabVIEW flow, use a diagram similar to the following example.

Propagating CAN Faults to an Error

The block diagram in the figure above first checks for CAN bus off state, which indicates that communication stopped due to a serious problem in the CAN protocol state machine (data link layer). Next, the block diagram checks for a fault in the CAN transceiver (physical layer). Finally, the block diagram checks for a fault in NI-XNET. If any of these three faults are detected, it overwrites the previous error in the standard LabVIEW error cluster. If a fault or error occurs, execution of subsequent VIs ceases, effectively stopping the LabVIEW application execution.