Yes, "unreserve" was the right choice. I was away from LV and picked up the "unverified" term from the online docs about the task state model. Didn't remember that you can't set that state explicitly with DAQmx Control Task.
The code looks just like I was trying to suggest, sorry it didn't seem to help. I haven't explored the nooks and crannies of cDAQ as much as I know desktop MIO boards. With a desktop board, you wouldn't be getting errors nor would you need to muck about with reserve / unreserve stuff.
You seem to be bumping up against a fairly unique scenario, given that the article about that error was pretty specific about identifying the one particular cDAQ module (9401) you're using.
I still tend to suspect there's a better way to avoid or prevent the error, but am out of ideas for what that might be. Much as the "configure and start twice in a row" feels like an undesirable workaround, it *does* at least seem to work. At the end of the day, that's gotta count too.
If anyone's out there from NI, is there a better solution?
-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.
