Windows 7 vs XP PCI bus problems

[CoastalLabVIEWER]

We recently upgraded are machines that are running our test stands from ~2007 year Core 2 Duo machines running Win XP 32 bit to 2012 year i7 machines running Win 7 32 bit.

The exact same software and drivers that was running on the old system is resulting in buffer overflow errors in a non NI (it's a Measurement Computing DAS16JR/16) data acquistion card that we use.  This board has a 1k on board FIFO and after doing a bit of reading I feel like it is this FIFO and not the LabVIEW buffer (which I specify to be 20000+  samples) that is doing the overflowing and generating the error as the problem definitely gets worse the higher I turn up the sample rate.  It also seems to get worse when the VIs interfacing with these boards are called from a Test Stand instance versus just the VIs running by themselves.  We have two other boards in our system from Measurement Computing (DAS6071) that have 8k onboard buffers and I've yet to get any buffer overflow problems.   When I look at the CPU processor it is only in the 10-15% range during execution (where-as on the older systems it was in the 85% range).

I tried very briefly today to changing the Preferred Execution system of my top level VIs to 'data acquisition' but that didn't help.   If the LabVIEW buffer is plenty large (5 seconds worth and the overflow error message happens within 1 second of when I see the samples stop changing) then it seems like to me the Measurement Computing code (a .NET instance) isn't being given the chance by the OS to get the samples out of the board.

Any ideas on what I can do either in LabVIEW or the OS to make sure the data gets off the board in time?  Worst case I'll likely go back to Win XP but I'd like to make 7 work if possible.

[CoastalLabVIEWER]

This can probably now be moved to the serial port section as it turns out when I turn off the code talking to RS-232 devices all my data acquisition board problems go away on the Windows 7 install, so the problem is to now figure out whats up with the serial code that is different on Win 7 vs XP.  I'm using 2 Quatech 8 port PCI serial cards.

I used this tool quite a bit today http://www.thesycon.de/deu/latency_check.shtml

And with just LabVIEW running talking to the data aq boards I was seeing DPC delays in the 1.5-3ms range, which is fast enough for our application.  When I would run it with our full test executive running I'd see spikes in the 8ms range and then when I'd see the buffer overflows mentioned in the previous post happen I saw DPC delays of 40, 60, and 250ms.  Running our full executive but turning off the sections for the serial saw the DPC delays drop back down to more or less what they were with just the few LV VIs talking to the data aq boards.

[dsFlux]

Hi SmokeMonster,

-What version of LabVIEW were you running on the Windows XP machines?

-What version of LabVIEW are you running on the Windows 7 machines?
-What drivers are you using for your Measurement Computing devices?

As for the CPU usage, the Core i7 processor is much newer and processes information faster than the older Core 2 Duo. This decrease in CPU usage should be expected.

You say you are using the same drivers on the Windows 7 machines that you used on the Windows XP machines. I recommend updating your serial driver to the latest NI-Serial driver - NI-Serial

[CoastalLabVIEWER]

Hi David,

I'll have to check the serial driver when I get back to work, but I'm inclined to think it isn't actually the driver because if I run the serial port code by itself the latency as measured by the DPC tool is really low, 100-200 microseconds.  It's only when I run the the serial port code at the same time as the Mesurement Computing board code do I have weird problems that didn't exist on the older machine running XP.

On both systems I'm running the 2012 f3 patch.

I've been in contact with Measurement Computing but they don't have a solution yet.  If it isn't actually a driver problem is it possible this could be some kind of weird IRQ issue?

[CoastalLabVIEWER]

After turning off everything imaginable in the BIOS that could affect latency and moving the suspect data aq board into our so called Main PC motherboard and still having the same issue I managed to find a NI PXI-8430/16 and my problems went away instantly.

For our application, it would be better to have the PCI version of this card to install in our Main PC as opposed to a PXI rack we are using because we have a 15 232->485 converter boxes located physically close to the Main PC, not close to the PXI and we'd have to move quite a bit of wiring in an already type electronic cabinet to make this work well.

Does anyone suspect that the PCI version of this card would behave any differently?  I'd hate to give up what is now a working solution for yet another one that doesn't.

[dsFlux]

Hi SmokeMonster,

That's great you found a setup that will allow your application to work. There could be a slight performance difference between the PXI and PCI cards, but it doesn't seem like it should affect this application much. You also said that the PCI cards you were using were third party? I just wanted to double check again on your serial driver version. What version are you using? Having the latest serial driver could possibly help alleviate these issues.