EricFinns,
I tried your example VI, and have a theory about what is happening. DAQmx will attempt to be fairly smart about how it how it controls state transitions within a task. In your ACQ.vi, you explicitly start the task on the 1st run. After it is read, the task is not stopped. The next time that the task is called, it has not been stopped from the last run, however since it is a finite acquisition, and all available samples were read in the last call, you see the error. Once the error occurs, the task is stopped and unreserved. Since start is not called again, executing the read call will auto-start the task, which automatically stops the task once read is complete. As such I believe you read successfully on your 1st call. Error the 2nd call, and run successfully thereafter. This leaves you with several options. First option is never to start the task, and let DAQmx do that for you behind the scenes. This is an easy implementation which should resolve the error you receive. However, it means that the driver will automatically transition through all of the task's states each time your sub-vi is called. The second option, which I have attached is as follows. On the first call only, configure the task, and explicitly transition it into the committed state. Then start the task, read your channels, and stop the task. This should prevent you from receiving the error you are seeing, as well as stop DAQmx from performing unnecessary state transitions on the task.
Hope this helps,
Dan