Using actual clock rate results in "The specified resource is reserved" error.

[Baturin]

Hello!

I am using DAQmx 9.8, win10 x64, NI 6221 emulated board, labview 2012 32bit.

I need to set AO sample clock rate, check actual clock rate, calculate pulse based on new rate value and write it to the board for output. The sample code is attached.

Everything is ok when I use only one timing command (as usually people do) during task setup, but when I am trying to set clock rate and then number of samples I receive "Error -50103 The specified resource is reserved. The operation could not be completed as specified". The error occurs after DAQmx Write.vi. I have tried use two timing commands or a combination of timing property node and timing command with the same result.

Is there are any ideas how to solve this? Probably, there is some more convenient way how to obtain actual rate which I dont know.

I have not tested it yet on real hardware, only on emulated board.

[Kevin_Price]

When I ran your code I got error -200673 "Multiple samples cannot be written using a single sample write".  Using the drop down menu for DAQmx Write, I changed to the 1Chan NSamp version and ran without error.  Worked fine for simulated M-series (like yours) and real X-series.

You should be fine if you just call DAQmx Timing first then query the Timing property node for actual sample rate to have a total of 2 timing-related calls instead of 3.  I often do that with no issues.  But either way should work without an error, especially the particular error you reported.  Might you have been doing test panels in MAX at the same time as running this code?

-Kevin P

[Baturin]

Kevin,

Thank you for your reply. It is strange, but today morning the sample code is working correctly. But the actual code is not :(. There is nothing else related to AO, only one AI task in this software.

Screenshot is attached. AO channel is the same as in sample code, the size of the array equals the number of samples wired to timing vi. Reload LV, reset device in DAQmx didn't help either.

I am going to check it with actual hardware.

[Baturin]

Real hardware showed the same result. I think I will rewrite this part again...

[Baturin · Accepted solution]

Finally, I dindn't reveal the source of the prolem. It was definitely not related to timing vis. Just simplest setup of analog output generated the same problem in this VI, but working without errors when copied to new file.

Rewriting the whole project from scratch helped to fix it. Initially I was trying to modify  someone's else existing program to change signal generation from benchtop standalone generator to DAC.

Now everything is fine. Due to the software is not complicate it takes only several hours to rewrite