LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Scan backlog fills in one sample period causing Error 10846

I am doing continuous buffered position measurement using a PXI-6602 counter which is gated at 1kHz with another counter on the 6602 whose output is routed via RTSI0. I am using a PXI-8156B controller in the chassis; software includes LabVIEW RT 6.0.3, NI_DAQ 6.9.1. My host machine is a 1GHz Pentium running Windows 2000 w/ 256MB of RAM.
The problem is that I keep getting the buffer overwrite Error 10846. I have monitored the scan backlog which will go from a backlog of 0 to a backlog of (buffer size + 1) in on sample period (1ms). I have increased the buffer size from as small as 100 points to as large as 100,000 points and the problem remains, although it takes longer for the error to occur with larger buf
fer sizes. I believe there is a problem in the drivers or LabVIEW because it would take 100 seconds to fill the buffer of 100,000 pts. at 1kHz and I am not observing this time period.
I have changed the read/search mode setting for the "Counter Read Buffer" vi from "relative to read mark" to "relative to end of data" and the problem persists. Also, the problem remains regardless of execution priority.
Another observation is that if I use DMA as the data transfer method the problem occurs. If I use interrupts for data transfer, the problem does NOT occur. I obviously would prefer to use DMA.
I have Observed this problem in my own VI's as well as the "Measure Buffered Position (NI-TIO).vi" example which ships w/ LabVIEW set to continuous buffer mode and set to receive its trigger from RTSI0 (1kHz).
Are there any documented problems with continuous buffering using DMA? Does anyone have any suggestions?
Thanks!
J. Strahler
0 Kudos
Message 1 of 7
(3,722 Views)
J. Strahler,

Please contact National Instruments Technical Support regarding this issue so we can work with you to investigate this further. Visit www.ni.com/ask and select either "Call NI Engineers" or "Email NI Engineers".

Regards,
Chad H.
Applications Engineering
National Instruments
http://www.ni.com/ask
0 Kudos
Message 2 of 7
(3,723 Views)
I am having the same problem with buffered period measurement and a PXI-6602. What's the answer?
0 Kudos
Message 3 of 7
(3,722 Views)
I am having the same problem. Have you got a solution.

Thanks,


Shawn
0 Kudos
Message 4 of 7
(3,722 Views)
Hi, J. Strahler:

I am haveing similar problem with PXI-8176 controller and PXI-6052E DAQ. Have you found a solution for it ?

Thanks,

Best Regards,

S. Gao
0 Kudos
Message 5 of 7
(3,723 Views)
I too am having this problem. I am using NI-DAQ 7.3, with PCI6033E and PCI-6602 cards. My counters (counters 0-3 on the 6602) are gated off of RTSI0, and RTSI0 is driven by the SCAN clock on a PCI-6033E card. The sampling rate is 1Khz; I've monitored the RTSI bus with a scope to verify that the gating pulses are OK (they are). I am using continuous buffered acquisition. The buffers are 5-seconds deep (5000 samples for each counter).

The basic algorithm is as follows:

1) I have a thread that sleeps for 5 milliseconds, then wakes up. When it wakes up it...

2) Reads the available samples from the PCI-6033E card (using DAQmonitor() to determine where in the ring buffer to read from)

3) Reads available samples from PCI-6602 card, channel by channel, using GPCTR_Watch(ND_AVAILABLE_POINTS) to determine how many samples are available, followed by a GPCTR_Read_Buffer(SlotNum,chan,ND_READ_MARK,0,avail,0,@countval,@buffer).

4) Writes any necessary outputs.

5) Goes back to sleep, then back to step 1


After a few hours of operation, I get a -10846 error. After this, all bets are off and I have to reset the software. Inicdentally, (and I don't know if this is related), I can swap the 6602 card with a 6601, and I get periodic "-10013" errors from GPCTR_Read_Buffer(), although unlike the -10846 errors, I am still able to keep the acquisition going.

I am running a HP/Compaq P4 2.8 Ghz, 512MB ram. I don't believe that CPU power is an issue, and the machine is not heavily loaded (CPU runs at about 6% capacity). The development envirnoment is Borland Delphi 5.

Any clues? Is there a bug in NI-DAQ or in the 6602?

Any help is most welcome!
-cfgmgr
0 Kudos
Message 6 of 7
(3,673 Views)
Sgao and Cfgmgr,

Please contact National Instruments Technical Support regarding this issue so we can work with you to investigate this further. Visit www.ni.com/ask and select either "Call NI Engineers" or "Email NI Engineers".
0 Kudos
Message 7 of 7
(3,646 Views)