error 10843 with new PC

[lmtis]

After several hours reading posts on this problem I still can't figure out how to solve it.  I have a function generator VI that is supposed to run in the background while the main VI collects data.  It has been running fine for years.  The PC died, and we replaced it (with a P4 core Duo, up from a P3).  Now I am getting error 10843 (intermittently).  I cannot believe that this is actually an underflow error, but as I am new to DAQ...?  I am using a PCI-6110E card, and this VI to generate a continuous sawtooth waveform.  I thought that this VI writes the waveform to the buffer at the start, and each time the control settings are changed, and that otherwise the 6110 would continue to pump out the programmed signal.  What has my aged synapses failed to grasp here?

[lmtis]

If anyone has any fresh thoughts on this problem  I'd love to hear from you,  I'm in a real bind.  I have product to test, and the 12 hour test will never complete without the error occuring.

[Vanessa L]

Hi Jim,

Error -10843 is associated with using E series boards and NI-DAQ.  This link to an online knowledgebase explains this concept further and gives recommendations on how to get around the problem.  As it says in the knowledgebase, the output speed of the card is limited by the speed of the bus and the overall speed of the PC.  Although you got a faster processor speed, the speed of the bus transfer may be the same.  I'm not sure why you were not receiving this error with a slower processor and the same PCI bus unless the faster processor is making LabVIEW run faster and the update rate for your output is working more like it should.  Now the update rate is too fast for the bus to process the interrupts.  Regardless, slowing the update rate should fix the problem.  I hope this information is useful!

[lmtis]

Hi Vanessa,

I saw that KB article, but I am not using a low cost device so I didn't look too closely.  The PCI-6110E cards do have a FIFO buffer.  I don't completely understand how the process works as far as how data gets passed to the PCI-6110E card when and by what, but the waveform is 220K samples, and is running at 7Hz.  Normally this runs in the background while the main Vi reads in simultaneous data from 8 channels (2 PCI-6110E cards) ~288K samples.  Now I can't even run the function generator alone without getting this error.  I was under the impression that the card will autonamously pump out the waveform that has been given to it, and will request new data when it nears the end of the buffered waveform, which it will put into the buffer to be processed next (FIFO).  Is that correct?

My latest attempt has been to adjust the PCI latency timer.  The default setting is 64 cycles.  I tried 32 and 128 cycles to no avail.

With regard to the KB article that you referenced, I was going to try to force it to use DMA as suggested, but there is a problem.  We are using group 0 in our AO config for the waveform output, but the minimum group number in Set DAQ Device Information.vi is group 1.

[Vanessa L]

Hi Jim,

I took a look in the manual and saw that you are right about the 6110E having an onboard FIFO.  I can see now with your low update rate (7Hz) and the fact that the board has a FIFO, that KB I linked you to is probably not the issue. So if I understand you correctly you have a waveform with 220 kS that is being generated at 7 samples per second.  You explanation of the FIFO is essentially correct.  So in your case, the FIFO would store the number of samples that it could until it was available to be transferred from the FIFO to the board.  However, you are transferring samples so slowly that they would probably be almost transferred directly.  That's why it doesn't really make sense to me why this would have changed just by upgrading to a different PC.  Are you sure that there was nothing else that you changed in your program since you upgraded your PC?

As far as changing to DMA, you should not have any issues transferring group 0 in the Set DAQ Device Information VI.  This is because you can take the task ID from your AO config VI and wire it direcly into the task id/group number input of the Set DAQ Device Information VI.  This VI should be placed directly after the AO config VI in line so that everything (data transfer mechanism included) is configured before you start writing out the data.  I placed the Set DAQ Device Information VI on the block diagram and was able to wire my task directly in.

[lmtis]

Are there any good "DAQ for Dummies" tutorials available to help explain how this works.  I still cannot believe that the new PC is not able to transfer data to the 6110 card at 1.5MS/s when it has nothing else to do.  This Vi ran fine in the background on a 866MHz P3  while another VI collected 3000pts of simultaneous AI data from 8 channels on two 6110 cards at 320Kb.  The error message indicates that this error can also be returned when an overrun has occured, and this seems the more likely of the two.  My question is how do I control the speed of the transfer so as to prevent this from happening?

[lmtis]

Changing to DMA had no effect.  Still getting the same error.

[mallorim]

Hi Jim,

I am disturbed that this is an example program that is not working.

Some things to try:

1)     If you have the DAQmx installed on your computer, I would suggest running the DAQmx Example Cont Gen Voltage Wfm- Int Clk.vi. This is the same example, just with the different driver. For this example, you can just open and run it, just selecting you 6110 card as the device and not changing any other settings. Does it return the same error? If so this might be a problem with the PC.

2)     If there error does not occur right away or if you are able to get the DAQmx example to work, you can try running a test panel in Measurement and Automation Explorer (MAX) after wiring the Analog Output to an Analog Input. This will let you see if you are correctly outputting the waveform.

3)     The board could have been damaged when the previous PC went down, though this is rare. Have you tried this example with the second PCI-6110 to see if it exhibits this behavior? Do you have a second PC of the same specifications that you can try this card and example on?

4)     This could possibly be a bad Traditional DAQ installation. What version of Traditional DAQ did you install? You could try repairing the Traditional DAQ driver in Control Panel>> Add or Remove Programs>> National Instruments.

Regards, Mallori M.

[lmtis]

Hi Mallori,
Thanks for your response. 

1)This test station is running LV6.02, so I don't have DAQmx available.
2) "
3)The older PC did not go down.  The performance of the optical components that this test measures has increased to the point that I need to increase the sampling rate on the 8 analog input channels (we have 2ea PCI-6110 cards in the test set).  The P3 that we were using cannot handle the increased data rate.  I have to limit it to 4 channels for the required performance.  When the new PC failed to perform, I put the cards back in the old PC in order to keep production going for our end-of-year rush. 
4)I have uninstalled all of the NI software and reinstalled it.  Same problem.  I have LV6.02 with NIDAQ 6.8, the OS is winXP.

I too am disturbed that this is not working.  On the off chance that the problem is actually a buffer overrun rather than underrun I have tried simultaneously running a VI with nothing but a while loop with a 5ms pause in it, but this did not change anything.


Message Edited by lmtis on 02-14-2008 07:37 AM

[lmtis]

Hi Mallori,
I have an interesting bit of info.  I deleted the wait in the simultaneous vi, and the Function Generator VI has now run longer than it ever has on the new PC (>2hrs,vs. typically 30min.).  What could cause the buffer to be overrun, and what can be done to prevent it?