Developer Forum

Hello,<br><br>Thank you again Ed for your help, I have tried your solutions yesterday, but unfortunaly it was not the time out. So i have still the error. <br>I have used a for loop to see if the error occurs during the first call, and in fact the error occurs during the second one. But i have no idea why. <br>To make it works : i start, stop and free the memory each time that i call the vi, and it works fine. Maybe it is not really a good use of the DAQmx, because i am initializing the acquisition each time that i call the vi and that consume CPU time. <br>I would like to initialize it only one time at the first call, I guess this is a better idea, is'nt it ? And at the end the memory will be free automatically because the vi is encapsulated in a DLL generate with the application builder of Labview and desalocated at the end of the program, so the task is freed... no ???? :/ <br><br>If anybody have an idea why a get this error (-200278) i am still interrested, thank a lot !!!<br><br>EricFinns

EricFinns,<br><br>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.<br><br>Hope this helps,<br>Dan


FirstCall.zip:
http://www.yqcomputer.com/