NI-XNET Troubleshooting Guide

Updated Dec 12, 2019

Reported In

Driver

  • NI-XNET

Issue Details

I am seeing an error or incorrect data when using NI-XNET driver or compatible hardware. What can I do to narrow down the issue?

Solution

Overview

XNET systems have core components which can be separated into being either Hardware or Software. Hardware includes XNET interfaces, the wires and cables that make up the physical bus, and other devices on the bus. Software includes programs and applications running on the hardware. 

When first confronting an error, narrowing down the origin of the error is important, whether it be hardware or software. For hardware, some steps are running shipping examples, conducting loopback tests, scoping the traffic on your bus, and self-testing hardware in NI MAX. When it comes to software for XNET applications, the main two components are the NI-XNET driver and the code you are developing. A good resource to ensure proper usage of the hardware and software is to reference and search the NI-XNET Manual .

This document explains some common troubleshooting steps when using the NI-XNET Driver.

Characterize the Problem

When seeing an error in your XNET program, first confirm that the hardware is in working order. To test whether the hardware is working, we must isolate those components by controlling the software to a known working state. Other methods of testing hardware include loopback tests, scoping the traffic on your bus, and self-testing hardware in NI MAX. 

When it comes to software for XNET applications, the main two components are the NI-XNET driver and the code you are developing. In rare cases, an installation error or driver corruption may be preventing you from executing XNET functions. Reinstalling the driver will often resolve an issue like this. For logical issues in the code, use common debugging methods, like breakpoints and highlight-execution, to narrow down where mistakes occur in your code. 


Troubleshooting Methods:


Ensure Device is Listening

Ensure that there is a device "listening". Be sure to Start the XNET session. If Auto start is set to False, then you will have to manually start the XNET frames sending out on the bus.


Compatibility and Upgrading Driver

Assess if you can upgrade your driver version. New versions of NI-XNET contain bug fixes which may resolve the behavior you are seeing. 
  1. Check the version of NI-XNET against your version of LabVIEW using the NI-XNET compatibility chart
  2. Check the readme of the latest compatible version of NI-XNET to see if your NI-XNET hardware appears in the list of supported devices
  3. If possible, install the latest compatible NI-XNET Driver


Shipping Example

Code in the LabVIEW Example Finder has been tested to work. If you are getting errors in your XNET program, it is a good test to see if errors also appear in example code. If you see errors in example code as well it may be that there is an issue with your XNET Driver, XNET Hardware, or physical layer. If example code does not show any errors, there may be an issue specific to your code.


Loopback Test

A loopback test is a common way to confirm the validity of different parts of your embedded network. During a loopback test, known test data is transmitted by a device back to itself. Successful transmission and reception of the test data can confirm proper operation of the following components of a system:
  • The XNET hardware
  • The XNET Driver
  • The physical layer used in the test
By confirming proper operation of these components, you have evidence to rule them out as being the source of errors you may be encountering. 

To conduct a loopback test, you must have a device with XNET interfaces. Connect your physical layer to both interfaces. You can then use either LabVIEW or the XNET Bus Monitor to send transmit a frame on one of the interfaces and receive it on the other. A prebuilt XNET Loopback test example is installed with XNET and can be found in the LabVIEW Example Finder


Common Errors


Internal Driver Errors:

Internal driver errors are errors which occur at the driver level. There are a broad range of possible causes, so it is best to gather as much information as possible when troubleshooting them. 

Questions to ask:
  • Did anything change in the context of your application when the error began appearing? 
  • What actions do you take to cause the error? Does it occur every time the code is run?
  • Does the error occur when running NI-XNET shipping examples?
  • Does the code cause the same error when deployed to other computers?
Based on some of the answers, you can try to isolate the problem by testing sections of code out and/or revert back to an older set of code to continue troubleshooting. Sometimes an internal error will only occur in either NI MAX or LabVIEW. If you are seeing the error in your LabVIEW code, try Self-Testing the NI-XNET hardware in NI MAX. Self-Testing also resets the firmware of the device so occasionally, Self-Testing can be a way to recover from an internal error.

To self-test, click on your device in NI MAX and under the first tab, there is an option to Self-Test at the top. 


Unexpected Data, Frames, or No Data

If you are seeing incorrect data, or lack thereof, transmitted or received in your NI-XNET application, the best first step is to determine whether the issue is being caused by the hardware or the software. Use common LabVIEW debugging techniques to ensure that your code is executing as expected. Probing wires can be a good way to confirm that data being passed to NI-XNET functions is what you expect. Use proper error handling to ensure that no upstream errors in your code are causing cascading effects. 

A good way to confirm that the hardware is functioning properly is to use a known piece code such as an NI-XNET shipping example or performing a loopback test with the XNET Bus Monitor. If in these tests you are not seeing your expected data, you may be receiving bus error frames which are indicative of an issue with the bus. Monitor the traffic on your bus using the XNET Bus Monitor and ensure that Bus Error Frames are enabled in the Interface and Database Settings. You may see a Bus Error Frame which will have ERR as the frame type. You can reference the data in the frame payload against the Bus Error Frame chart on page 4-553 of the NI-XNET Manual to see the type of Bus Error that is occurring.

Often, Bus Errors can be explained by poor quality of electrical signal on the bus due to attenuation, reflections, or noise. Attenuation is the weakening of signal strength over distance, if you believe your signal is attenuating test a shorter cable length. Reflections occur when an electrical signal encounters an abrupt change in cable characteristics such as at the transceiver of an ECU. Termination is key to reducing signal reflections and is implemented by including resistors at either end of the bus. Some devices have software selectable termination. See the Termination Guide for more information on bus termination.


Bus Power Error

Ensure that the bus is powered. It is recommended to use a breakout box in prototyping settings to help inspect voltages or power the bus. It is important to remember that even though transceivers may be powered, they are driving the bus voltage to a logic level low, and the excitation voltage still needs to be applied elsewhere. 


Other NI-XNET Errors

When encountering errors in your NI-XNET code be sure to read the full error description. Try searching google for knowledge base articles referencing the same error number. Post to the NI Community Automotive and Embedded Networks Discussion Forums.