Fastest way to clear an error and re-start task - Help!

[ChrisK88]

Hi Guys,

I've developed a test that has two tasks:

Analog Task - 2 audio input channels

Digital Task - 3 digital input channels

The analog task is triggered off of an Analog Edge start trigger and digital task is triggered off of analog input start trigger with Digital task Starting first, then Analog task starting.

I then start a DAQmx read parallel while loop that just spins and reads a finite sample count and takes 1 second worth of data. Timeout is set to 2 seconds for this case. I clear any timeout errors I get -200284, and clear AND log any other DAQ errors. Here, I'm getting random errors and don't want to propogate them, just log them and move on to next acquire cycle. So in order to move on, if any error other than -200284 occurs I am calling Clear Task and then enqueuing to my main loop the configure timing state again which sets up the task from the input controls. I need to run 55,000 iterations, and around 9000 iterations in, I had an error, cleared the task, went to reconfigure and got a "Specified Resource is Reserved" error.. how can this be if I'm clearing the task before restarting it?

Is clearing the task the best way to handle a DAQmx error and re-start it, or should I be "uncommitting" and doing other DAQ API methods instead? I am now running with Stopping Task then Clearing to see if that helps. Mind you, I get errors literally every iteration due to me simulating it in MAX and having errors from simulate mode, so I know the clearing task/restarting state works, just had the one occurrence where the resource was reserved.

On another note, does anyone know how to set a Stop trigger off of an audio line that is going from On to Off. My analog task is starting on analog edge start trigger, but the audio is pulsed at 500 ms on and 500 ms off, and I'd like to only trigger on the start of it and when it turns off, instead of taking a finite sample size big enough to capture 1 second worth of the whole audio on and audio off..

[Kevin_Price]

1. After all the task config but before calling DAQmx Start, make a call to DAQmx Control Task to "commit".  When an error occurs, you should be able to simply DAQmx Stop and then DAQmx Start the task to get going again.  You shouldn't need to DAQmx Clear or redo all the preliminary config settings.  The original "commit" will make the Stop / Start sequence execute faster.  

   Dunno why you got the "resource reserved error" after Clear and reconfig.  My best guess would be that DAQmx Clear releases at least some task resources asynchronously, i.e., it returns quickly from the DAQmx Clear call before completely finishing at freeing everything up.  Then a subsequent reconfig might catch something that hasn't been freed yet?  Maybe the buffer memory?

   The simpler Stop and Start won't change those resources and may eliminate that rare resource reserved error.

2. If you're getting a lot of errors (aside from timeouts when attempting to DAQmx Read before the trigger condition has happened), try to address the root cause rather than rely on a Stop / Start workaround.  It may not be feasible, but it's a better goal to shoot for.

   Note: you could query a DAQmx Read property node "Available Samples" as an alternative way to determine whether triggering has happened yet.  It'll return a 0 value with no error during the time you're waiting for a trigger.

3. Here's some info setting up a Reference Trigger to act like a "stop trigger":

http://digital.ni.com/public.nsf/allkb/BA775B0E445BFA79482571FE0032CCEB

-Kevin P

[ChrisK88]

Thanks for the reply Kevin.

I will put the Control Task VI and commit prior to starting. I didn't know how to properly use this before so I just avoided it, but seems like if I Commit->Start->Stop->Start it will work instead of Start->Stop->Clear->Re-configure->Start like I'm doing now. I think you're right and my reconfigure state was running while the task was still being released and unreserved. I essentially don't want any errors other than timeout, so that's why I'm logging them now to find out what they actually are at the time of the event. In hind sight I would have implemented a central error handler due to my 4 paralell while loops, but hind sight is 20/20 and I did not do that to start. 

I tried using the property node for available samples and when the re-triggering happened (via property node for each task), the number of samples was always 0 yet I was reading valid data. I called NI advanced support through my company EA and they said that might be a bug..