Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

NI USB 8502 XNET interface loose communication with MAX

        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

 

     Regards

     Vikke

0 Kudos
Message 1 of 9
(3,972 Views)

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.

Jeff L
National Instruments
Message 2 of 9
(3,956 Views)

Hi Jeff

    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.

 

   

Thanks

Vikke

    

0 Kudos
Message 3 of 9
(3,948 Views)

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.

  • We can try taking your LabVIEW code and moving it to another machine with a newer version of Windows to see if it reproduces the internal error. If the problems seem to follow the USB-8502 from machine to machine then maybe it could be a problem with the device and an RMA. If the code and device work fine on a different Windows 10 PC it would point to a problem with the specific computer being used and we can take a closer look at that.
  • We can make sure we have the latest USB drivers etc for the computer that generates the errors. 
  • We can check to see what type of USB hardware is on the motherboard and see if there are any known issues associated with that type of hardware etc.
Jeff L
National Instruments
0 Kudos
Message 4 of 9
(3,941 Views)

Hi Jeff

 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!

 

0 Kudos
Message 5 of 9
(3,934 Views)

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.

Jeff L
National Instruments
0 Kudos
Message 6 of 9
(3,911 Views)

Hi Jeff

    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?

 

Thanks

Vikke

0 Kudos
Message 7 of 9
(3,868 Views)

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...

  • Try using a powered USB 2.0 hub if you have one available.
  • Try using a PCI(e) to USB expansion card to bypass the chipset on your motherboard.
  • Ensure we are connecting to the USB ports directly on the motherboard and not USB ports on the front panel of the computer case.

Unfortunately, there we don't currently have a programmatic way to unplug or plug in the USB-850x.

Jeff L
National Instruments
0 Kudos
Message 8 of 9
(3,860 Views)

Hi Jeff

   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

 

thanks

vikke

0 Kudos
Message 9 of 9
(3,856 Views)