11-17-2005 11:25 AM
11-17-2005 11:34 AM
11-21-2005 03:14 PM
11-22-2005 09:14 AM
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
11-23-2005 04:24 AM
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?
11-23-2005 04:47 AM
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
01-10-2006 09:15 AM
Hi Markus,
download and install the newest DAQmx driver Version 8.
http://digital.ni.com/softlib.nsf/websearch/4C9E45F6EE5C29F98625708900712CBC
best regards
Klaus
01-11-2006 01:06 AM
01-11-2006 07:27 AM
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
01-12-2006 04:36 AM
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