This document contains the NI-XNET known issues that were discovered before and since the release of NI-XNET 20.5. Known issues are performance issues or technical bugs that NI has acknowledged exist within this version of the product.
Not every issue known to NI appears on this list; it is intended to show the most severe and common issues that you may encounter and provide workarounds when possible. Other technical issues that you may encounter could occur through normal product use or system compatibility issues. You may find more information on these issues in NI’s Product Documentation, Knowledgebase, or Community.
|
Bug Number |
Legacy ID |
Description |
Details |
|---|---|---|---|
| 210421 |
Installing a New Version of NI-XNET To Older LabVIEW Can Break I/O Control DialogsNI-XNET (full version) and the NI-XNET Runtime Engine include the four most recent versions of the XNET LabVIEW driver library. If you build an application with a version of LabVIEW that is more than four years old, after you install a new version of NI-XNET your deployable installer will not include support for NI-XNET.
Workaround: Do not install a new version of NI-XNET to use with a version of LabVIEW that is four years old or older.
|
Reported Version: NI-XNET 19.0 Resolved Version: N/A Added: Jun 17, 2020 |
|
| 419486 |
Inserting a USB-850x Device Can Result in an Unusable Device with Internal Errors on Phar LapSometimes when plugging in a USB-8502 on a Phar Lap system, the ports are visible, but XNET internal errors will occur during use.
Workaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 17.0 Resolved Version: N/A Added: May 29, 2020 |
|
| 199635 |
NI-XNET CAN FD Sessions (non-BRS) Require CAN FD Baud Rate To Be SetWorkaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 17.0 Resolved Version: N/A Added: May 29, 2020 |
|
| 201375 |
NI-XNET Does Not Import the DBC BO_TX_BU property from DBC files, Prevents a TX frame from Being Mapped to Multiple Transmit ECUsWorkaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 17.5 Resolved Version: N/A Added: May 29, 2020 |
|
| 199608 |
The J1939 Address Claim Procedure Does Not Detect Conflicts Between Two ECUs Running on the Same XNET InterfaceWorkaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 18.0 Resolved Version: N/A Added: May 29, 2020 |
|
| 199657 |
XNET Read (Frame CAN) Can Return Fewer than the Requested Number of J1939 Frames Without Reporting ErrorWorkaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 17.0 Resolved Version: N/A Added: May 29, 2020 |
|
| 199702 |
Frame Output Queued Sessions Only Retransmit Cyclic J1939 Frames When Session Starts And When New Data Is WrittenJ1939 cyclic frames with a payload over 8 bytes only transmit once at start of session, and when data is written to the session. Frames with 8 bytes or less re-transmit at the specified interval, as expected.
Workaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 18.0 Resolved Version: N/A Added: May 29, 2020 |
|
| 199696 |
Switching a J1939 Session to a Different ECU Node Name Does Not Use the Address from the New ECUSwitching a J1939 session to a different ECU Node Name does not use the address from the new ECU, even if that ECU has already claimed an address. The node address must be set after the node name to properly configure the session. Workaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 18.5 Resolved Version: N/A Added: May 29, 2020 |
|
| 199598 |
If XNET Read (Frame Raw) Times Out While Reading Ethernet Frames, Frames Successfully Read Are DiscardedIf XNET Read (Frame Raw) times out partly through reading Ethernet frames, the subset of frames that were successfully read are discarded and are no longer available from the NI-XNET session. Workaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 19.0 Resolved Version: N/A Added: May 29, 2020 |
|
| 199704 |
727473: XNET Signal Single-Point Output Sessions Always Write Mode 0 Subframes by Default, Even If No Mode 0 Subframe is PresentWhen creating a signal output single point session containing signals on multiplexed frames, the session always begins transmitting mode zero subframes. Workaround: Avoid this issue by writing initial signal values, including the multiplexer signal, prior to starting the session. |
Reported Version: NI-XNET 19.0 Resolved Version: N/A Added: May 29, 2020 |
|
| 197052 |
Ethernet PHY State and Port Mode Properties Are Not Reset After NI-XNET Is ReinstalledWorkaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 19.0 Resolved Version: N/A Added: May 29, 2020 |
|
| 1004118 |
J1939: PS Field Is Included in the PGN When Sending TP.CM_RTS FramesThe J1939 protocol allows for data payloads greater than eight bytes by splitting them across a single packet comprising multiple frames. SAE J1939-21 specifies that "the least significant byte of the PGN is set to zero" when the PF value is less than 240. However, in NI-XNET, the least significant byte contains the destination address.
Workaround: There is currently no known workaround for this issue. |
Reported Version: NI-XNET 19.6 Resolved Version: NI-XNET 21.0 Added: Jun 17, 2020 |
|
| 1100525 |
A Hardware Error Occurs After a CPU Spike on the CompactRIO ControllerA CPU spike on a cRIO-906x controller running an NI-XNET session can cause the error "A hardware error has occurred" to appear, and leave the XNET module in an unrecoverable state that requires a reboot of the controller.
Workaround: Mitigate CPU usage on the CompactRIO controller. Other CompactRIO platforms seem not to be affected.
|
Reported Version: NI-XNET 20.0 Resolved Version: N/A Added: Jun 17, 2020 |
|
| 989923 |
Signal to CAN Frame Conversion Does Not Set Extended FlagCAN frames use arbitration identifiers that can be either standard or extended formats. In a Conversion Session, when a signal is converted to a CAN frame that uses an extended ID in the database, the extended flag is not being set
in the frame data.
Workaround: Programmatically set the extended? flag to True after the signal is converted by reading it from the database.
|
Reported Version: NI-XNET: 19.6 Resolved Version: N/A Added: Jul 1, 2022 |
Issues found in this section will not be listed in future known issues documents for this product.
There are currently no issues to list.
Explore Support Content and Product Documentation
Ask the NI Community
Request Support from an Engineer
A valid service agreement may be required, and support options vary by country