CAN Communication Using NI-XNET Causing Communication Stalling/Rushing on Host PC LAN Bus

Updated Jul 25, 2023

Reported In



Issue Details

I'm trying to communicate with a device using CAN and NI-XNET in LabVIEW, but whenever I run my NI-XNET program, I notice that the communication on my host computer's LAN bus occasionally stalls entirely, followed by a rush of frames from both my CAN communication and other communications occurring with my host computer. This behavior does not occur if I am not performing  NI-XNET communication - how can I address this communication stalling?


This issue is generally caused by either an incorrect or corrupted installation of the NI-XNET driver, or by the antivirus and firewall on your computer or network taking too long to analyze incoming network communication and creating a bottleneck. Try the following steps to identify and address the issue:
  1. Reinstall your edition of the NI-XNET driver , and upgrade to the latest version if possible. This will remedy any potential issues present in the installation of NI-XNET.
  2. If possible, disable your antivirus and firewall on your affected computer, and see if the issue persists. If the issue disappears after disabling your firewall and antivirus, then try to narrow down what process/combination of processes related to NI and NI-XNET are creating the bottleneck, and grant an exception/exclusion in your antivirus software to these processes. The process to do this will be different depending on your antivirus software, but this description of how to grant exclusions in Windows Security can be used as a reference. Also, be sure to configure your firewall to allow communication on ports utilized by NI software and hardware after re-enabling it.

Additional Information

You can confirm that this behavior is affecting your application by tracing the round-trip communication time in WireShark. After collecting your trace of the behavior, open your trace in WireShark and navigate to Statistics->Conversations on the WireShark toolbar to access packet conversations between your host and slave device. select a conversation which communicates with your NI-XNET port (in our case, it is port 31415), and click the Graph button in the lower right hand corner.

On the graph that appears, set Type in the lower left hand corner to Round Trip Time, and observe the graph - you can cycle through communication streams using the Stream control in the lower right hand corner if the behavior isn't present on the default zero stream.

The graph above shows NI-XNET communication time spiking up much higher than the stable speed during stalls, and down to zero during the rushes. If your communication graph exhibits a similar pattern to the graph shown above, then you are likely experiencing the stalling/rushing issue described in this article and could resolve your issue using the steps in the Solution section.