02-26-2015 03:00 AM
Hardware: CRIO 9068, CAN module 9862
Software RIO 14.0, XNET 14.0 (also happens with 14.1)
My software structure:
C/C++ programming with Eclipse
XNET: 4 single frame output sessions, 9 single frame input session which are used in one 10ms cycle
When running, after an undefined time i get this error
NI-XNET: (Hex 0xBFF63001) An internal error occurred in the NI-XNET driver. Please contact Natio
nal Instruments and provide the information from the file %LOCALAPPDATA%\National Instruments\NI-XNET\log\niXntErr.log. On
Windows XP, the file can be found at %USERPROFILE%\Local Settings\Application Data\National Instruments\NI-XNET\log\niXntEr
r.log. Please note that this location may be hidden on your computer.
when calling nxWriteFrame.
I found a niXntErr.log in the root of the CRIO but I didn't find helpful information in it, and it seems not to be updated every time when I get this error.
What are possible reasons for this error?
Where can I find further information to identify the problem?
Thanks in advance,
Jens
05-04-2017 03:21 PM
Hi, JensT.
I'm having the same problem. I see you didn't get any replies here. Were you able to eliminate the problem on your own?
I have a similar code structure and the error happens maybe once every two weeks. I don't think C code is causing the problem - I've seen when just running LabVIEW.
08-16-2017 11:54 AM
Hi
I'm also having this problem, running LabVIEW 2016 with XNET 16.1.
I can reproduce that issue within 1 minute.
You just need to use the vi "LIN Frame Input Output Same Port.vi" or "CAN Frame Input Output Same Port Single Point.vi", remove the timing of the While-Loop and then start the VI, but without an partner that's connected to your LIN or CAN module.
Within a very short time you'll first get an buffer overflow (don't know how to avoid that) and after that the error code Hex 0xBFF63001.
This will crash the scan engine, and for a complete reset I have to reboot my cRIO and disconnect the power from the transceiver of the XNET-module.
08-18-2017 11:53 AM
Over here we resolved the issue by implementing a better shut down process. Our C# was just killing the thread for our LabVIEW executable. We haven't seen the problem since we created a way for the executable to run to completion.Thanks for the tip about using Frame Output Single Point. That's a better fit than Frame Output Queued which we are using.
08-21-2017 09:27 AM
I have to add a few new insights to my last reply:
There are several hardware requirements for the error to occur as fast as described:
1) cRIO type must be 906x (ie ARM-9 dual core with Zynq 7020 FPGA)
2) It is not enough to just install a XNET module in the cRIO. A non-XNET module has to be installed too. In my case it is a 9403-DIO Module. But it does not matter if that DIO module is used by the software or not. YOu just need to install it.
08-25-2017 04:20 AM
A final reply:
I seem to have found a severe, but also very rare error. NI support could only reproduce my issue with the combination XNET-module & 9403 in cRIO 906x. Combination with other DIO-modules does not lead to that failure of the scan engine.
Working solution: Use FPGA-mode to interface to the 9403, than it is working.
Regards, Jens