Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -200301

Solved!
Go to solution

Hello All,

I'm trying to generate continuous pulse train with fixed frequency and duty cycle, however every alternate time this simple program throws error -200301.

I've found some other related posts, however after going through those, they all seem to be unrelated as I'm not trying to update any property during the runtime still getting this error.

I'm using USB 6343 to generate the pulse train.

 

Error_-200301.png

 

 

PS: I've also included LabVIEW 2012 version code, but I'm currently using LabVIEW 2017.

 

Thank you.

Download All
0 Kudos
Message 1 of 4
(3,052 Views)
Solution
Accepted by topic author scofield

I think you can solve this with the following changes:

1. Get rid of the call to DAQmx Write.  The freq and duty cycle were already defined when you created the task so you don't need to write them again.  

2. Call DAQmx Start explicitly right before the loop.  (The old call to DAQmx Write probably defaulted to auto-start behavior, which may have contributed to the -200301 error.)

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 2 of 4
(3,027 Views)

Thank you Kevin,

Your suggestion worked well for me.

Though I'm still wondering, I'm using both DAQmx Stop Task and DAQmx Clear Task functions, why is that I'm getting this error, specially on every alternate run.
Is this a bug and CAR should be created for this.

0 Kudos
Message 3 of 4
(3,011 Views)

You're not still getting those errors when you remove the DAQmx Write and replace it with DAQmx Start like I recommended, are you?

  

I don't know exactly why you were getting an error on alternate runs with the code you posted.  While the use of DAQmx Write with auto-start enabled is an unconventional thing to do for pulse train generation (compare to the shipping examples), I'm not sure I'd have expected an error if you hadn't already posted about it.  I think I would have expected the write to happen first, then the auto-start.  I'd have thought this would be fine -- to overwrite the pulse properties one or more times when the task is idle.

 

But the fact you got the error combined with the unconventional nature of the construct now makes me suppose that my previous assumptions were wrong.  I just don't know exactly how and why.

 

I'm unsure whether this is a bug and whether a CAR should be filed.   I'm not at a LabVIEW machine, but maybe you could test the idea that pulse specs can be written more than once while the task is idle.  Try doing the DAQmx Write with auto-start set to False, followed by a call to DAQmx Start.   Then try doing the same kind of thing, but change the pulse specs with a call to a DAQmx property node instead of DAQmx Write (probably a channel property, possibly timing).   What do you observe with those 2 latter experiments?

 

To investigate further, change the order of those functions -- Start first, write pulse specs second.  Be sure to try it with both "easy" high frequencies like 1 MHz (a pulse is sure to have been generated with the old specs by the time the new ones are written) and "hard" low frequencies like 1 Hz (a pulse is sure *not* to have completed with the old specs when the new ones are written).   How did things turn out with *this* experiment?

 

These will probably serve as helpful clues for an AE to use to help determine whether there's a bug needing a CAR to be filed.

 

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 4
(3,004 Views)