Overview
XNET systems have core components that can be separated into 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 the Interface is Listening
Ensure that the device's interface is ready to receive incoming frames by starting the XNET session beforehand. If the Auto Start? XNET Session property is enabled, performing a Read or Write operation will transition the interface from Stopped to Started. Alternatively, if the Auto Start? setting is disabled, you will need to manually start the Session or the Interface using the XNET Start function.
You can also check the interface state anytime by using the XNET Read State Communication function. This includes the communication state, transceiver's errors, faults, and sleep state.
Compatibility and Upgrading Driver
Assess if you can upgrade your driver version. Newer versions of NI-XNET contain bug fixes that may resolve the behavior you are seeing.
- Check the version of NI-XNET against your version of LabVIEW using the NI-XNET compatibility chart
- 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
- 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 the 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 the 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 the proper operation of the following components of a system:
- The XNET hardware
- The XNET Driver
- The physical layer used in the test
By confirming the 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 that occur at the driver level. There is 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. Additionally, if you observe that after starting the session the interface loses frames during the first reading iteration, consider executing the XNET Read or XNET Write function once beforehand to ensure that the interface transitions earlier to the Started state.
A good way to confirm that the hardware is functioning properly is to use a known piece code such as a NI-XNET shipping example or perform 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 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.