Delay a Synchronous AI Read after an AO sample write

[LabGuyA]

Hello all,

I have two issues I'm trying to work out in the attached sample VI (sorry in advance for how large the screen is). In a continuously cycling loop, I monitor three AI channels on wavecharts. Once I toggle a record control, it switches the read loop to a wait state and initiates a sequence where a series of voltages are written by the DAQ and I want to read data from the same three AI channels I monitored in the loop after each voltage is written in sequence. I'm having the following issues:

a) When i switch the initial monitoring loop off I still get an Error -50103 occurred at DAQmx Start Task.vi:7220015 message although the read task should have stopped running.

b) I want the reads to occur at the same frequency as the writes but with a delay of 500uS.

Does anyone have any suggestions as to the source of the error?

LabGuyA

[replyall_ia]

Hi LabGuyA,

Before we address the frequency question, I'd like to talk about the error that you're received when you stop the task and then try and record. Can you possibly edit your code such than the stopping and clearing of the DAQmx task is outside of the while loop? 

Here is a forum post that address the problem -- http://forums.ni.com/t5/Multifunction-DAQ/Err-200088-When-I-using-DAQ-for-analogue-output/td-p/20110...

.... specifically the forum post stating:

"You're doing a DAQmx Create Channel (AO Voltage), which creates a task, outside of your loop, then doing DAQmx Clear Task inside of the loop. On the next iteration, the task you created no longer exists, which is why you're getting that error.

You can either move the DAQmx Create Channel inside the loop (which means that you're creating the task anew every iteration, which incurs some overhead) or you can move the DAQmx Clear Task outside of the loop."

Let me know if that helps!

[majoris]

I haven't looked too closely at what is going on, but I would like to note that you only clear one of the two tasks in your Record Samples event. Is that intentional?

[LabGuyA]

Thank you both for your responses to my questions.

Aulia V. I've taken a look at the other forum post you recommended and while it is helpful, it does not seem to get at the heart of my issue. I believe my previous error was due to the task stop condition being false with the DAQ Assistant VI. However, in the attached VI I setup and start the task outside of the loop. After the record event is registered it stops the task in the dynamic display loop which should allow it to be passed/referenced in the record loop. However, now when I run it, I get Error -50103 occurred at DAQmx Start Task.vi:7220016 saying that the resource is reserved. It does not occur every time which leads me to believe I have a race condition although I'm not sure where.

Majoris - Yes, I intentionally do not clear the Read task because it needs to persist to resume the "real-time display" in the while loop. I use this same task in the record samples loop with slightly different read properties (which are modified when the record is initialized).

[majoris]

Oh yeah, this is obvious now. Clearly that stop command is not being run before that new AI Voltage task is setup on the same channels. I recommend you actually ensure that the stop command is run by signally it is done. I'm not a big fan of how you've set up your communication between loops. However, if you want to keep it exactly as is, you can synchronize the stop with the new create task by adding a wait on notification (or you can use an occurrence) instead of the Wait (ms) vi. And the send the occurence or notifier after the stop task in the bottom loop. In general though, I'm not even sure you need event case up top. You could handle the event down below (you could just use a latching boolean and no event structure at all) and use a wait on notification up top. Add a short time out, and only run the top loop's contents when there isn't a Wait on Notification timeout. 

Hope that helps.

[LabGuyA]

Majoris,

Thank you for the suggestion! I've used notifiers in past revisions where I was performing single point reads (I had a loop that fed in one write position waited and then performed the read within the loop) but decided to leave them out because of the overhead computational costs. I also think I'll change the loop communication and will move the data collection completely out of the event structure and into the "producer" loop. This way I can eliminate the race condition by having all of the tasks held in the same loop and toggle between "modes". In regards to my other question about the frequency delay, I found a Daqmx trigger property that allows you to set a delay in seconds. This delay should cause all of the reads to begin x seconds after each write occurs if the frequencies are the same, correct?

Thanks again,

Frank