error 10843 on faster machine (OK on slow machine)

[John McCulloch]

G'Day,

I'm getting error 10843 when using the Benchtop Function Generator vi (one of NI's solutions). I'm using a PCI6025E card.

The odd thing is that it works fine on my 800MHz PIII but on a 1.7GHz P4 it is giving me the error.

I spent a week developing an application (with one section based on the NI example) on my PIII only to find when I ported it to the target machine its not working.
After a bit of testing I discovered that NI's example was generating the same error as my code - even at low update rates (1ks). It usually takes a while to produce the error 10 - 30 seconds.

Can any one help me identify and fix this problem?

Thanks.

[Ben]

Hi John,

THe only idea that comes to mind is that the faster machine is "goofing-off" for too long between data updates.

Try making your buffers larger or update them more often.

If this does not help, post an example of your code for us to look at.

Ben

[John McCulloch]

Ben,
Thanks for your reply. From What I understand the 6025E card has no on board buffers so the DAQ driver software sends the waveforms out using DMA in the background. The Labview code instructs the driver to continuously send the waveform out and then returns to perform other tasks.

You already have the code I am using as it is a NI solution vi "Benchtop Function Generator" (installed in the "C:\Program Files\National Instruments\LabVIEW 6\examples\daq\solution\benchtop.llb" directory on my machine)

I am interested in seeing if other people have problems with this vi on faster machines.

-John

[Ben]

Yes but,

If the app does not keep an sufficient amount of data buffered, you will get that error.

Check the CPU and memory load.

Microsoft "FindFast" is notorious for causing these type of issues.

NILM (NI License Manager) is also a possible suspect.

Ben

[Spencer S.]

John,

Are you sure that your analog output operation is using DMA transfers and not interrupts? One thing to keep in mind is the fact that the PCI-6025E only has one DMA channel. If you are using this channel for analog input, your analog output will be required to use interrupts. Of course, interrupts are slower than DMA transfers. Try forcing your analog output operation to use your board's DMA channel with Set DAQ Device Information.vi.

You may have already considered this. Just a thought. . .

Spencer S.

[John McCulloch]

Ben,

Once again thanks.

I will try increasing the buffer size, but am still unclear as exactly why it may help when you are doing a continuous output.

The folowing is an indication of my understanding of how the daq driver works - am I mistaken somewhere?

I thought that with the continuous output of a waveform, the buffer is initially fully transferred to the driver where it remains unchanged. After this initial transfer, the driver simply DMA's the next output value to the card, wrapping around to the beginning of the buffer as required.

-John.

[John McCulloch]

This is a good question.

I was previously unaware of Set DAQ Device Information.vi.

I will look into it carefully as my application does both background sampling and waveform generation.

The Benchtop Function Generator.vi example however exibits the problem and it only does waveform generation. (But it is possible that sampling was set up with my vi and not cancelled before I tested the the benchtop vi!)

Thanks for the good info.