Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

PCI6534 with DAQmx - Error 200621 - OnBoard Memory Underlfow

Hi
 
I'm using a PCI6534 with DAQmx 7.4 in LabVIEW 7.1
 
I'm doing a finite 16bit pattern output synchronized with a 16bit pattern input. Basically it works but at  higher frequencies I do receive a 'ERROR - 200621 occurred at DAQmx Wait Until Done.vi' indicating as  possible reason an Onboard device memory underflow. My trial pattern contains only 72 vectors (U16  integer) and the PCI6534 has 32MByte OnBoard memory so theoretically this should not be a problem.
 
Please refer to attached VI that includes a screen-shot of the error message on the Front Panel.
  • Running the VI as is:                       error at 20MHz (running at 10MHz)
  • Disabling the switch 'Read Input':          running at 20MHz !
  • Setting property UseOnlyOnBrdMem to false:  usually running at 5MHz (sometimes I get the error)
  • Connecting the input 'samples per channel' of the DAQmx Timing (Sample Clock).vi of the output task to my array length (as done for input task):   error at 9MHz (running at 8MHz)
What I want to do is to download the pattern into OnBoard memory (to be sure this actually happens) and only then starting to output  the pattern to prevent being dependant on the bandwidth of the PCI bus.

Could someone have a look at this?
- can you reproduce the problem?
- can you tell me how to solve the problem?
- can you tell me how to fully control the OnBoard memory (apart from the property UseOnlyOnBrdMem) and see its status
- is this problem known
- is this problem solved in a more recent version of DAQmx?
 
Many thanks and kind regards
  Markus
0 Kudos
Message 1 of 13
(5,581 Views)
0 Kudos
Message 2 of 13
(5,569 Views)

Hi Markus,
 
When you call DAQmx Timing (Sample Clock), you are specifying Finite, but you don't specify a number of samples.  The default value is 1000, which may or may not be what you want.  Try wiring the total number of samples you are going to write to the "number of samples" parameter.  (Since you are just writing once, the number of samples should be the same as the size of your array). 
 
Hope this helps.
 
 
0 Kudos
Message 3 of 13
(5,544 Views)

Dear Jonathan

thanks for your hint.

The strange thing is that if I feed the length of the pattern to the input 'samples per channel' I get the onboard memory underflow error at even lower frequencies. This eventhough I would imagine that when not connecting this input the pattern gets downloaded once only anyway and then the card is then looping from onboard memory until the 1000 samples (default) are reached.

I'm still looking for a way to ensure my pattern gets transfered into onboard memory before it starts to be output.

regards

  Markus

0 Kudos
Message 4 of 13
(5,535 Views)

Hi Markus,

I couldn't reproduce the error -200621. Even if I choose 20MHz sample rate.

I also don't understand exactly the goal of your application:

Do you want to read in a pattern and output the same pattern simumtaneously with a synchronous sample rate?

Do you want to read in a pattern first and than output the same pattern with a synchronous sample rate?

Do you want to read in a pattern and output a different pattern simumtaneously with a synchronous sample rate?

Do you want to read in a pattern first and than output a different pattern with a synchronous sample rate?

 

0 Kudos
Message 5 of 13
(5,525 Views)

Hi K_Dinnes,

Interesting to know that you don't get the error 200621, so it somewere seems setup dependant. So now is the question on which parameter it depends on and how to influence it. 

I do want to read in a pattern and output a different pattern simumtaneously with a synchronous sample rate.
- the pattern output are the stimuli to the inputs of my DUT
- the pattern input are the captures from the DUT's outputs, in order to compare in LabVIEW to my expected response
(I am aware that when outputing e.g. a clock egde in cycle N I will only capture the new state of the DUT's outputs in cycle N+1, but this I take care off in SW)

regards
  Markus

0 Kudos
Message 6 of 13
(5,524 Views)

Hi Markus,

download and install the newest DAQmx driver Version 8.

http://digital.ni.com/softlib.nsf/websearch/4C9E45F6EE5C29F98625708900712CBC

best regards

Klaus

0 Kudos
Message 7 of 13
(5,445 Views)
Dear Klaus
 
Thanks for your reply.
 
So I understand that DAQmx version 7.4 has a problem (it's not just me) that has been resolved in version 8.0, correct?
As I have to support several applications in a production environment that use version 7.4 I can not easily change the release, but if you can tell me that this issue is resolved in version 8.0 I could plan for an upgrade of the drivers.
 
kind regards
  Markus
0 Kudos
Message 8 of 13
(5,439 Views)

Hi Markus,

first I thoght it is the driver, because on my system the DAQmx 7.5 driver is installed. I've only simulated the PCI 6534, but a simulated card doesn't produce the error. Now I've installed the PCI 6534 and I was able the reproduce the error.

When I run the VI without changes I'm able the adjust 14 999 999 Hz without the occurance of an error. If I increase the frequency the error -200621 occurs.

At the moment I'm in contact with USA to verify this behaviour. I'll let You know as soon as I get an answer.

regards

Klaus

0 Kudos
Message 9 of 13
(5,424 Views)

Hi Markus,

if got two anwers from USA:

"I've ran into a very similar issue before. 20 MHz rates are really pushing the limits of the  the DAQmx driver and LabVIEW. The speed of the computer used in the application also effects the maximum rates that can be used. I was able to achieve higher transfer rates than my customer simply due to the fact that my computer was faster and I did not have any other programs executing in the background.

So, this problem is reproducible, but it is due to overall system speed limitations. Some things that your customer can do to achieve faster rates are to use LabVIEW 8 with DAQmx 8 (this actually makes a noticable difference). Also, make sure that no other programs are running in the background and using the fastest available computer will also help. "

"I looked into this a bit further and I think the error may be due to another reason. I don't think that the program is allowing enough time to write the samples on the output task. I inserted a 250 ms delay between the DAQmx Write VI and the DAQmx Start Task VI and the error was eliminated. I hope that this helps your customer. "

If you have further questions, plase let me know.

regards

Klaus

0 Kudos
Message 10 of 13
(5,411 Views)