Just to throw a kink in things -
We are still swapping the USB-VXI controller with a MXI-2 controller, meanwhile we are moving on to other integration tasks. With the USB-VXI still installed, we added an additional ethernet card, and the original problem with the USB-VXI controller went away. We cannot reproduce the problem now that we have the 2nd ethernet card installed...
Since I have not been able to sit down and work with your system both before and after, it is a little challenging to place my finger on exactly what caused the change. I still believe that the issues you were seeing before were related to the data transfer rate of the USB device. I am not sure, however, why this changed after installing a second ethernet card. My best guess is that there was some strange installation issue, and the second card forced a reinstallation and may have fixed a slight error.
I am glad that the system is working for you now, and I am sorry that I do not have any conclusive answers for you.
Due to scheduling issues, we are sticking with the VXI-USB for now, so the problem reported in this forum still remains, and we would appreciate any assistance you can offer.
I still think that the issues you are running into have something to do with the throughput capabilities of the USB device, so I am not sure how much can be done to fix the issue. You did mention before that you could not reproduce the problem after installing a second ethernet card. Are you implying that the problem has returned? Or are you trying this on another system and running into the same issues?
At this point, I recommend trying the setup on different computers to see if it functions the same way. Also, I need as much information as you can give me. What are the exact modules you are using, what chassis are you using, what computer are you comunicating with, at what point does the error occur, and what exactly is the "bad data" you are seeing?
Installing the NIC only delayed the problem. We still have bad data during register reads on the switch matrix card installed in slot 1 of the Racal chassis. I'm sure that it is a timing issue but I'm not sure how to isolated it any further. I will try modifying the driver to repeat the read if the data is not correct the first time. The PC's and VXI chassis's are the same on all systems.
CPU: HPxw4400, 3.4Ghz, 1G ram, XP Pro 2002SP2
NI-MAX 126.96.36.19901, NI-VXI 4.0
VXI Chassis Racal 1261
Slot 0 NI VXI-USB Controller
Slot 1 Ascor 3000-511
Slots 2, 7 and 8 SMIP Switch
Slot 4 Teradyne Bi410
Slot 6 E1420
Slots 9 and 10 Ri3152a
Slot 11 E1412
Slot 12 Na5388
If the cause of the error is indeed due to the throughput limitations of the USB-VXI controller, then the only real suggestion I have at this point would be to slow down the data transfer. If you can incorporate a short wait function on every read, it should not run into errors in the throughput.
In terms of emulating the timing of a faster device, you cannot force the USB device to operate beyond its limitations.
Since you have multiple systems with this same setup, is each one experiencing the same problems?
I did at one time add a wait after the read but this did not solve the problem, only delayed it. It is very random and happens on all systems. The only thing other than using the MXI controller that seems to work is to have the driver read the register a second time if it does not get the correct data the first time. I hesitate to make this change since the same ViIn16 function is being used to read the register prior to updating it with the new value. If this read returns incorrect data we could end up with relays closed that we did not want closed.
Are you saying that the USB controller operates the VXI communications slower than the MXI controller? I was thinking maybe it was the other way around and that the USB controller was retrieving data from this instrument before the instrument made the data available.
Based on the specs for each device, the VXI-USB controller has a maximum throughput rate of 32 MB/s while the VXI-MXI-2 controller has a maximum throughput of 38 MB/s. The fact that adding a wait after the read delayed the error supports the theory that slower throughput rates are causing backup. At this point, I would recommend playing around with different wait times, since it appears that the over time the connector gets backed up, resulting in bad data.