When trying to install & run a PXI-5402 Sig Gen installed in a 1033 chassis, with Max it does not respond and after 10 secs or so gives the error -200221 at SourcesConfig.ivib:DAQMX write (RAW 1D I16).vi:1,
Measurement: Amount of time allocated to perform this operation was exceeded. Task Name: unnamed Task<0>
I have swapped the 5402 card with another but they both do the same; I am guessing there is something wrong with the NI installation software?
What does this mean, what is going wrong?
Hi Steve H,
This is Ben from National Instruments Applications Engineering, thanks for posting.
It appears that the driver is timing out when trying to communicate to the device.
Could you detail the spec of the PC you are using to communicate with your 1033 chassis, have you tried moving the MXI Express controller to a different slot in the PC? Also have you followed the steps in the Signal Generators Getting Started Guide?
Could you please ensure you have the latest version of NI-FGEN installed?
On further investigation the fault is caused by the new type of NI PCIe-8361 MXI/bridge card. I have two PC's with this type card in and they both give the same problem, I then changed the NI PCIe-8361 cards to an old type version of the same card and this cured the problem.
Therefore there is a difference between the versions of the NI PCIe-8361 cards.
The new type NI PCIe-8361 is small, made in Hungary, has numbers 195315C-01L, 195317B-01, 2006 on it.
The old type NI PCIe8361 is large, made in USA, has numbers 191376C-02, 19137BB-01,2004 on it.
What is the difference between these two types of 8361 cards?
The most significant difference between the cards is that the older card has a PCIe switch on it and 195315C-01L has signal redrivers. A PCIe switch receives a packet, interprets it, then routes it based on the headers. It shows up in device manager as multiple PCI bridges. The other card simply buffers the electrical signals and drives them down the cable. It doesn't show up in the hierarchy.
One implication of this is that when you change to the old card it looks like you've changed slots (because of the extra bridge), so the drivers get re-associated with the cards. Have you tried other slots in your PC? Or multiple slots in the 1033? Also, what type of PC? Are both PCs the same model and using the same slot?
Adding the PCIe switch can change the interrupt, though it shouldn't matter unless the BIOS is bad. There could be an electrical issue with the 1033 that is masked by the PCIe switch. I'd like to hear more about your setup before concluding anything.
The PC's are both new Industrial types (Amplicon) with only one PCIe slot in each. I have also found that the GPIB 488 PXI card installed gives problems when using MAX on the new type 8361 PCIe card, whilst it works ok with the old type 8361 PCIe card!
I'm not entirely convinced this isn't the BIOS or the host, but I don't have a good way of proving or disproving it. I suspect it's a problem routing/configuring interrupts.
I saw a problem recently that looked very much like this. An interrupt from a chassis wasn't making it to the driver which led to a timeout. In that case we had a version of his card we could put directly in the PC and it worked fine. We used a PCIe analyzer to see that the interrupt was being sent correctly in the failing case. Eventually it came out that he had tried to update the BIOS, but it didn't complete successfully. The BIOS was sending bad information to Windows about how the interrupts were routed. He re-updated his BIOS and it fixed the problem.
I stumbled across another related problem with some motherboards (as reported by a 3rd party): some x16 slots only route int A. If this were the problem then 1 or 2 of the slots in the 1033 would work and the rest wouldn't. Because of the way PCI interrupts are swizzled the 4 actual interrupt lines are rotated between slots. This means that if you try 4 slots in a row then one of them will line up with int A in the PC's slot. (There are additional factors in larger chassis that change this because of how the bridges between slots are connected, but it's true for single-segment chassis like the 1033.)
Related to that is an experiment you could try that might show something. If you have 4 cards that you put in 4 adjacent slots that you start at the same time, they will assert all 4 of the interrupts. This should make it so the interrupt handlers get called even if they're associated with the wrong line. It isn't a bulletproof test, but I think it would work. If it works it would show that it's a problem with the host PC. I think that's the best I can do with the system, unless someone knows more about how interrupt routing works at the host level.
Let me know where this stands.
Problem solved. It was a design fault of the NI 8361 mxi card version that was suppied at the time. NI have since brought out a newer version of this card which works and have agreed to replace the older duff versions.