PXI-8431/2 always times out during Write or Read

[Chris1234]

Installed a new PXI-8431/2. It seems to have configured correctly, it comes up in Measurement and Automation Explorer. When I try to test the card by transmitting data out, the operation always times out (error code 0xBFFF0015) and no data is transmitted. The operating system is Windows XP.

Any suggestions? Thanks.

[NIDave]

Bump...

I've got the same problem with my 8431/4 cards.  They timeout when transmitting one byte and never make it past the VISA write.  They do initialize properly.  

I opened up a help ticked today but don't have the days to wait, any thoughts?

[JasonSmith]

Did you ever find a solution to your problem? Generally you should never timeout on a write unless you have flow control enabled with the other end either disconnected or not ready to receive. If flow control is enabled, you need to have a device on the other end which is utilizing the same form of flow control, or else you write could sit indefinately waiting to transmit to the remote device.

-Jason S.

[NIDave]

Hey Jason, I did find a solution to the problem.  Ironically the card would pass the sequential verification but then the ports would not verify.  I also could not read or write to/from the ports.  After restoring the system and verifying the functionality of the card I continued installing other components till they quit.  The cards quit working after the installation of 2 Z-Tec arbitrary waveform generators.  It seems that the Z-Tec cards caused an IRQ conflict with the PXI-8431 and also the PXI-4070 cards.  Ironically this IRQ conflict was not noted by windows or MAX or any other software and the ARBs still worked fine.  I'm not really sure why this happened or why it went undetected but if your 8431 cards don't sequentially verify the ports then manually retreive every IRQ number for all devices in the PXI and ensure there is no conflict.  Hopefully this will save someone some time in the future.

-Dave

[JasonSmith]

Could you tell me which model of PXI controller you are using, along with the models of the Z-Tec boards? Are you using a MXI connection with a remote chassis, or is this all a local chassis with a PXI controller?

-Jason S.

[NIDave]

It's not MXI, it's a chassis with a controller, all local.  Details below.
-Dave
NI-PXI-1042Q          PXI Chassis, 8-slot, 3U
NI PXI-8106           Core 2 Duo 2.16 GHz Controller
Ztec ZT530PXI         Dual Output 16-Bit Arbitrary Waveform Generator  QTY-2

[Steven_T]

NIDave,

Unfortunately we are unable to reproduce this issue here.  However we only have one Ztec device (a ZT500PXI).  However I did notice that they use NI-VISA as the driver.  Is this the way that you are using the cards?

Do you have any screenshots of the resource conflicts, these may be useful for troubleshooting?

Thanks,

Steven T.

[NIDave]

HI Steven,

We were able to reproduce it on all 4 systems here so I don't think it's a "one-of-a-kind" type issue.  We used the Z-Tec drivers rather than VISA.  Also as I stated there were no resource conflicts reported so I don't have any screen shots of them.  The only way to find it was to go to the device manager and check the resources and they all had IRD 19 (I believe)yet noone reported a conflict of that IRQ.  Only after manually changing one of them did it work again.

-Dave

[JasonSmith]

So with PCI/PXI this wouldn't normally be an issue, as they are designed to be able to share interrupts. When you say you had to reassign one of the interrupts, did you have to place both Z-Tec boards on one interrupt, and the NI boards on another, or were there still some Z-Tec and NI boards on the same interrupt?

At this point it is really up to you whether you want to delve into this further, or just go with your workaround and leave it at that. Basically it appears that the Z-Tec drivers are interfering with our serial board's ability to service its interrupts, but it would be difficult to isolate the root cause without the same hardware setup here.

If you want to investigate further, we may be able to learn something from the following questions:

1. When the NI boards are not working, do the Z-Tec boards on the same interrupt work?

2. If you disable the Z-Tec boards in the device manager (with the interrupts still conflicting), does it allow the NI boards to work?

3. When the NI boards do not work, are you actively using the Z-Tec boards, or are they just installed in the system?

4. If you are on a multi-core system, does one of your CPUs show 100% CPU utilization when you are trying (unsuccessfully) to use the NI boards?

Thanks,

Jason S.

[NIDave]

HI Jason,

At this point we have "solved" the issue although it would be nice to really figure out what caused it.  To fix it we choose different interrupts for both Z-tec cards and the NI cards were given a different IRQ as well.  To answer your questions..

1. The Z-tec boards still worked on when the NI cards were not working

2.  I don't remember 100% but I believe the NI cards still did not function when the Z-tec cards were installed but disabled.

3.  They were just installed in the system, not being used.

4.  I don't remember checking the CPU usage but it seemed as if they were.  When we tried to stop an application that was trying to use the 8431 cards it took a long time to stop it or perform any other function so I would assume the CPU was bogged down when that was happening but again I don't remember checking.

Hopefully this will help get to the root cause or at least save someone some time.

Regards,

Dave