after upgrading from a slow Dell PC to a new Dell GX-280 (~ 3 GHz, hyperthreaded), our MXI-2/VXI card has stopped functioning properly. The correctness of read results from VME now depends on the readout frequency. Reducing the readout frequency by inserting a 1 ms wait time period in our LabView program serves as a workaround, yet renders VME access almost unusable to us. We have seen on your published lists that there are other issues with that cards related to state-of-the-art PCs faster than 2.5 GHz and hyperthreading. We need a fast workaround to
a) Keep VME readout speed b) Get correct Read/Write Results when operating on VME
Kind regards Thomas Hirschmann Master of Physics, PhD
Can you elaborate on the correctness problem? We have seen performance problems and, in some cases, errors in certain combinations of PC chipset, controller hardware, and software settings, but we have not seen any correctness problems.
we are reading out VME data using a LabView application and the VISA library. On fast subsequent readouts, only the first data is stable. All following data is (nearly) random. Using NI spy with active capturing we observe that the interference of this debug tool creates a delay which seems to be large enough to inhibit the malfunctioning. Inserting a millisecond delay in between subsequent readout obviously has the same beneficial effect.
This is the Ultra DMA driver version of the Optiplex GX-280 we have been using
Title : Chip Set:Intel Chipset Software Installation Utility Driver Version : A09 OEM Name : Intel OEM Ver : 18.104.22.1682 Computers : Dimension - 4700, XPS Gen 3, 8400, XPS Gen 4; OptiPlex - SX280, GX280; Precision - 370, 670, 470 Oses : Windows 2000 Professional,Windows XP Home Edition,Windows XP Professional Languages : Brazilian Portuguese,Chinese-S,Chinese-T,English,French,German,Japanese,Korean,Spanish Created : Mon Nov 8 18:14:53 CST 2004
The chipset is an Intel 915G/P/GV, with an Intel 82801 PCI bridge.
Do you have access to a VME logic analzyer that you could use to compare the data present on VME to the data received?
I looked at the Spy capture. Are all of the reads in your application done using viIn, or are there viPeek or viMove[In] operations as well, that are perhaps not shown in the Spy capture? Do you have your system configured to share host RAM for dual-ported access with viMemAlloc?
Also, feel free to attach the original Spy capture file (.spy) and not just the .txt file. The .spy file contains more details that may be useful in debugging.
Just to clarify and hopefully ease your concerns about your setup, we do test and use the MXI-2 system on many modern computers including hyperthreaded, multi-GHz machines like yours. We have never seen a problem where the MXI-2 starts returning incorrect data. The known issue we have had with certain recent chipsets affects DMA on our older drivers (although the problem can occur on newer drivers), but the result is not bogus data. Instead, the result is that a viMove or Fast Data Channel viRead/Write operation (never viIn) might be unusually slow or fail with a VI_ERROR_IO (or possibly other errors in older drivers). There are additional details in various knowledgebases such as document 2MIFSIPG on ni.com.
unfortunately we are not able to apply a logic analyzer at the moment. The read access in our LabView application is as follows: o viIn() is called repeatedly in a loop, no other vi calls placed inside this loop o No viPeek or viMove() calls are used.
We are using default settings according to the "Getting started" manual (no memory shared, see table A-5, line 1). Please note that we do not receive any bus errors when we get the bogus data.
Thanks. With the simple setup you've described, there are relatively few things that could be going wrong with the software. Have you tried a different MXI-2 controller?
We can continue investigating along a few different paths, but I think it would be helpful to get in more direct contact with you. Please submit an email request at ni.com/ask so we can get into further details. I think my next step might be to try using viPeek instead of viIn (you'll need to use viMapAddress first, if you're not already familiar with how viPeek works) because viPeek is extremely simple from the software side. If that doesn't change anything (or even if it does) we can simplify the software further by writing a C-based version of the test program's read loop. Let's have you get in touch with us by email to discuss these and other diagnostic options.