ViMoveIn Hangs on VXI Chassis/card

[speakers22222222]

I have a PC with windows NT and Visa/VXI 3.3.1.  There is a PCI-MXI-2 card connecting it to a VXI chassis with a card in it.
The software I've run on identical systems  before is hanging when trying to do a viMoveIn on the A24 address space.

I took the VXI chassis and card and hooked it up to a WinXP computer with the same version of VISA/VXI and it doesn't experience this problem.  I dumped its configuration to 2 cfg files (one for the PCI card and one for the chassis interface card) and loaded those files onto the WinNT machine and I still have the problem.  (I actually have two WinNT machines that are identical, they both were ghosted with the same image from the last working system and they both have this error).  I've tried multiple MXI-2 PCI cards, multiple chassis, and multiple VXI cards so I'm pretty sure its not bad hardware. 
I can successfully call viIn on A24 space and A16 space.  Its just viMoveIn16 that doesn't work.

Are there any other things I can check?  I'm stuck at this point.

Thanks!

[Brian F.]

Hello. 

Thank you for posting to the NI Discussion Forums. 

I would recommend taking a look at the following knowledge base article (KB).  It seems to answer your question or at least give a few good troubleshooting steps to take.  It is interesting that the behavior is not seen on XP while it is seen on NT.  My thought here is that the XP system probably executes commands much faster than the NT machine and thus is not seeing the conflict described in the KB.  Have you ever had the code working on an NT machine without this fault?

Why am I Getting "PCI-MXI-2 Error -1073807298 or System Hang" with VXI?
http://digital.ni.com/public.nsf/allkb/3688705B6D2A405486256E9F005953F6?OpenDocument

Let me know if this helps!

Brian F
Applications Engineer
National Instruments

[MDHarpo]

I'm seeing a similar thing on an NT4 system. According to NISpy, when any of various applications calls viMoveIn16 from various cards, the application hangs.

I've tried disabling syncMXI in the registry per the above reference (for NI-VXI 3.3.1) but it still hangs.

There must be something configured wrong in the PC because other systems with virtually identical hardware and software don't have this issue and the individual cards and cables have been tested as working.

I'm missing something but I don't remember my way around NT well enough to figure out what it is.

Any ideas?

[Ted_H]

Hi,

Can you elaborate a bit on the behavior you are seeing? To clarify, communication is working correctly until viMoveln 16 is called, is this correct?  Are you seeing any error codes?  Does Resman run successfully? Also, what versions of NI-VXI are you using and what hardware are you using?  Thanks!

Ted

[MDHarpo]

No communictions problems until a block move is done.

Resman runs consistantly without error.

NI Spy shows no errors.

I've tried NI-VXI 3.2 and 3.3.1.

Intel P3 2.6 GHz PC with Windows NT4 sevice pack 6.

I have a hunch that the PCI-MXI 2 card is not using DMA even though the hardware configuration says it's enabled because I've seen the block move hang on other systems when the card's DMA is disabled, but I don't know exactly how to test that hypothesis in NT.

...

Message Edited by MDHarpo on 01-29-2008 07:20 PM

[Ted_H]

Hi,

I'm going to look into this issue further. Just to be complete, what hardware are you using (VXI chassis, MXI card/cabling, etc). Also, what address spaces are involved?  thank you for your patience.

Ted

[MDHarpo]

After going through three previously working images of software for identical systems, I have found an image that doesn't hang for the system I'm currently working on.

However I'm still having a problem at the same point. Instead of hanging, viMoveIn16 returns a bus error. In a VISA session, it's giving a bus error for every card I try to perform it for in the system except the PCI MXI controller card. I can look at every address individually but if I do a block operation I get the bus error.

Since block moves use DMA I'm looking at the PC's PCI controllers (there are 12 PCI slots) and associated drivers. Will try a different PC tomorrow. 

To answer your question, the hangs were occurring if I had either of the HP 1413 A2D cards installed at the required address 2 or 4. It turns out that in the viSetup routine, those were the only cards that had viMoveIn16 called. In the selftest routine, only one card, Trig Tek vibration analysis card at address 106, in the second frame (frame 100), calls viMoveIn16 and it returns a bus error and fails self-test.

If the second PC works with the same software image, I'll will try to find a definative fault with the PC's DMA controller and return the PC to the supplier. If the second PC fails, I'll l'll start looking for a conflict between the chipset driver and the PCI-MXI-2 driver/firmware.

If you you know of anything other than DMA different from a block operation vice a single address operation, please let me know I could be barking up the wrong tree. 

Message Edited by MDHarpo on 01-30-2008 08:12 PM

[MDHarpo]

I found a workaround.

It turns out the motherboard's second Ethernet card was cause a DMA conflict with the PCI-MXI-2 card. Disable the Ethernet card in BIOS, and viMoveIn16 operates as normal.