We use two NI USB 8502 to communicate with 2 DUT in a project.After Run about 10 times, there will be an error 0xBFF63001 Error in TestStand, the CAN communicate fails,and the NI USB 8502 will loose communication in MAX.Attached error pictures and the VIs.
We use FileGlobals in TestStand to pass the session name and session number.
We am using Industry PC Advantech 510. We also try two USB 2.0, two USB 3.0 and one USB 2.0 and USB 3.0, still failed.
Is there someone met this error before. please help, thanks
I don't see any major issues with your programs that would likely cause the internal error. That being said, there are a few minor race conditions that we should eliminate to be sure. I serialized operations in the two VIs to make sure we are controlling the order of execution. In the CAN Frame I/O Same Port code, serialization eliminates a race condition bug where the interface could start before you attempt to set the interface properties which would then generate an error. This could happen when XNET Start is called implicitly by the XNET read and thus starts the interface before the property is set.
I don't expect these simple modifications to have an impact on the internal error but we should test them to rule them out. The next step is to create a top level VI that calls all three sub-VIs in the same way that TestStand does to see if that also causes the internal error. This will help us to focus on TestStand or the LabVIEW side of things.
At the beginning, we have only one VI combine the three VIs together ,to create, write ,read, stop and clear in one VI, there is an error, then we change to three, still have error.
Your code is simple enough and it should work fine in any XNET hardware either separately as three sub VIs or combined into a single VI. I don't see anything wrong with the code and it works fine on my tests with my system.
I don't see any mention of what operating system you are using? There were some known issues with Windows 7 and USB devices. Are you using Windows 7 or something newer?
As I mentioned in the other thread, the internal error reported by XNET originates from the Windows OS at the kernel driver level. We simply pass the error along and display an internal error. There are a few tests we can do to isolate the issue.
1. Attached the USB drive pictures
2.We are using Win7 in the production line.We have the following question, the NI-8502 has been sold for many years, and as I know these years, I can not believe it is a Win7 system issue. Win7 is still the most popular system specially in the production test, so this NI-8502 should be work on Win7. Fortunately, we could not test in with Win 10 system.
3. I also attached the TestStand Code made by one NI guys from china, the structure is very similar. We work together, fail to find the root cause and could not reproduce the error without DUT.
4. We borrow one PCI-8513 from NI, it works fine for about 90 times now with the same LabVIEW and Teststand code. But 8502 has the error after running about 10 times. If PCI works, Probably, as you say ,it is an USB issue, but we do not know where it is.
5.By the way, we are using LabVIEW 2015, TestStand 2014, XNET 17.5, since this issue has been exist for a very long time, from September, during the time, we try everything we can, including changes the VIs a lot of times, and we try XNET driver 16.1 and XNET 18.0, all these drivers have the same issue.
The mass production will be coming in the end of this month, November, Hope you guys can check all the things the 8502 hardware and firmware, the XNET driver, PC USB drivers and so on.
Thank you very much!
We are setting up some test systems to try and reproduce these errors that are reported in the log file. So far we have not been able to reproduce the issue on Windows 7 VMs so we are now gathering physical devices to do some additional testing. I will keep you informed of any progress.
Do you have another Windows 7 machine to test with? It would be nice to know if say a specific motherboard shows the issue while another does not. If we can isolate little differences like that, it can help us to find a reproducing system faster.
Actually, we have two station, one station have one pc of Windows 7 with 2 8502 cards.both of the two station have same loose communication issue. We unplug and plug USB, it can be fixed. Is it possible for us to implement unplug and plug USB port through software, to do the same job as unplug and plug USB hardware?
So far I have done testing on multiple physical PCs and haven't been able to reproduce any issues with your code.
I would like to do some additional tests to see if we can narrow down the issue to a specific USB chipset. Here are some more things we would like you to try...
Unfortunately, there we don't currently have a programmatic way to unplug or plug in the USB-850x.
1. we have already tried powered USB 3.0 HUB (UGT-AH700U3-3C), has the same issue
2. Not yet try, could not try currently.
3. yes, we use the USB ports from motherboard, not in the front panel