PCI6534 with DAQmx - Error 200621 - OnBoard Memory Underlfow

[Markus W.]

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

[Jonathan Brumley]

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.
 
 

[Markus W.]

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

[K_Dinnes]

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?
 

[Markus W.]

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

[Markus W.]

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

[K_Dinnes]

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

[K_Dinnes]

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

[Markus W.]

Dear Klaus
Many thanks for this explanation.
Good to know that a delay can resolve the issue. My only problem is, that my application is testing thousands of devices a day in production so of course I have to avoid any unnecessary delay. Further I am executing several digital patterns (so performing several writes to the PCI6534) for every single device, so if I'd have to add a delay for each of them that would add up significant test time.
I don't actually need the full 20MHz or even 10MHz performance BUT I need something which runs stable for a production environment. So if the problem depends on the overall load of the PC production might run into the problem any time.
As I am trying to run a finite pattern I would expect the output of data only to start once the tranfer of the whole pattern to the card has been finished. As this apparently is not the case for the code I use, isn't there any way to force such a behaviour (e.g. using properties)?
best regards  Markus

[K_Dinnes]

Hi Markus,
 
USA wrote:
"Even with the delay, the application should still be fine. You don't actually begin generating or acquiring data until after the delay and the samples will still be synchronized. With a finite application, the CPU peformance will not be as much of an issue as it was with my customer since their application was continuous. My customer had to worry about the possibility of Windows giving processor power to other programs in the middle of their program executing.Right now, the delay is only 250ms. You could probably make this number even smaller. Also, with lower rates, the delay may not even be necessary. However, for high rates, a delay between the write and the start is the only way to solve this problem. The rates themselves will be system specific. Also, you are correct in that data is output after the transfer to the card is completed."
Best reagards
 
Klaus