I got a brandnew NI DAQPad-6015 and tried the simplest LabView program (specs on environment are given below):
I place a one-channel-acquisition (DAQ-assistant) in a while-loop and
display the acquired data. Sampling-frequency and N-samples are
controlled by separate inputs to the DAQ-VI; no external timing is used.
After an unpredictable number of cycles (5-150) the VI crashes with error -200329 (lower number of samples seem to speed-up the crashing, e.g. 100 samples/5 kHz sampling rate vs. 2000 samples/5 kHz) I haven't been able to find a solution in the support-database -
some threads assume a broken hardware, but I ran the Diagnostic-Utility
DAQPad via USB 2.0
2.8 GHz CPU
LabView 8.0 (with according DAQmx)
Andre, thanks for the reply....
1) No, there is no message in the taskbar
2) If I stop the VI upon the error message I can restart it and it will crash again after some time, as before; but I just realized
that when I select 'Continue' from the error-message, the VI continues
without further error (at least for several minutes, i.e. thousands of
cycles without further error) However, strangely, after
continuing the VI the timing between analog-out and analog-in is
shifted by 20ms, which I can't attribute to a LabView-flaw.
I have attached an according VI which I used for testing. What it should do:
Loop two parallel sequences.
Sequence 1: Analog out (0 V for some ms [delay1] -> 5 V for some ms
[Trig-Dur]-> 0 V for a second delay -> 5 V again -> back to 0
Sequence 2: Acquire a defined number of samples -> display them
What it does (with 30 ms delay1 and 50ms delay2 -> AO-0 connected to AI-0):
At the beginning timing is ok (output signal starts at 30ms with a
jitter expected from the update-frequency of the analog-out) until VI
shows the error - upon selecting 'Continue' delay1 has shifted to 10ms,
i.e. the acquisition appears to be delayed by 20 ms (I don't think the
output starts too early...), but now the VI runs nicely.
I have still no idea what the error might mean (if it would be an
USB-problem I would expect the error to reoccur after continuing the
VI). Might there be another way to tackle the problem?