PCI-6602 with Massive Data Loss errors on a Pentium 4

[BryceMan]

I am having an unexpected problem with a brand new PCI-6602 card. I am trying to collect data on two counter/timer channels using interrupt transfer. I know I could be using DMA to transfer the data, but I'll need to use all 8 counter/timer channels eventually, so work with me on this. One channel collects 16K of data and the other collects 8K.

I am working in Visual Basic 6.0 using Traditional NI Daq. I have been developing my application on a Pentium 3 @ 800 MHz. Since I am using interrupt transfer, I continuously use the GPCTR_Watch command to monitor the channels for a -10920, ( "One or more data points may have been lost during buffered GPCTR operations due to speed limitations of your system." )

Occasionally, and really only when I have all 8 counters going at once, do I actually see this error. I am satisified with the reponse of this system. I understand the limitations of interrupt transfer, and most of the time I can get solid data out of all of the counters.

So I go to the field to deploy my application. I specifiy a Pentium 4 @ 3.2 GHz, expecting even better response using interrupt transfer. But all of a sudden I am having a phenominal amount of -10920 data loss errors. Even if only one counter/timer is active! They occur amost every second or third time I reset the counter and enable data collection. This is happening way to frequently for my application, and not what I have been experiencing during its development.

I do not know what is causing this error but I can tell you what I have eliminated:

    * It happens on two different PC's that are Pentium 4 > 2.8 GHz with Hyper Threading ( a Dell and a Lenovo).

    * It is not the operating system. I have tried Windows 2000 with Traditional NI DAQ 6.81, and Windows XP with NIDAQ 7.4.

    * It is not the PCI-6602 IRQ setting. I have tried cards with different and unique interrupt assignments (by installing two PCI-6602 in the PC).

    * It is not processor bandwidth, there are no other applications running and the processor usage meter from Task Manager does not even break a sweat.

    * I have been all through the BIOS settings disabling as much as I possibly can, all with no effect.

I have scoured the Knowledge Base, and the other online documents but I can find no other person who describes my problem.

Does anyone have any suggestions as to what the problem could be?

Thanks,

Bryce

[Laura F.]

Hi Bryce,

It certainly seems you have been pretty thorough in your troubleshooting!  The only thing that possibly comes to mind is any virus checker software, although from your description I pretty much rule this out.  Was your development machine hyperthreaded?  Would it be possible to disable hyperthreading on one of the pentium 4's and try that out? 

I wish I had more suggestions!

Laura

[falkpl]

Have you tried troubleshooting with MAX?  You can test one channel at a time under the measurement explorer.  Also what type of signal are you counting, how fast (mhz) is it coming in you mentioned that it is 16 and 8k worth of data but what is the time scale.  There is a possibility is not a hardware issue, but I need a little more info.

Paul

[falkpl]

I had a similar issue with an unstable signal that I was counting.  The falling edge of the signal was noisy, with a lot of ringing,  (impedance mismatch? All my electronics are self taught.)  The ringing acted like many TTL pulses arriving at the counter, causing the counter to overload and counts to be too high.  When I had a similar signal gating the counter the data collection caused massive amounts of apparent data to be collected and many data points caused a buffer over-run.  This took a lot of effort to understand, but the software and hardware were fully functional.  After filtering (home-made low-pass)the signal all the problems disappeared.  This might not be the problem but is is just some of my experiences with the 6602,  All programming was done in labview 5.1-7.0.

Paul

[Jamie Fraser]

Bryce,

I think Paul's answer may be correct. Look to your signal source if it is different to the one you were using during your development. Even if it looks clean with a scope you may find it is a higher impedence source than the counter inputs like. This can lead to the dreaded -10920 error.

You may need to buffer your input signal that you are counting if you can't modify the signal source in some other way. A simple Schmitt will do the trick.

One thing to watch if you are trying to reduce a voltage swing with a potential divider (e.g. reduce a 0-12V signal to 0-5V for connecting to your DAQ card) is that you may be using large-ish resistor values that will cause the overflow problem.

Reply if none of this helps. I've had a fair bit of experience with -10920 over the years!

Jamie