06-05-2007 09:26 AM
06-05-2007 11:16 AM
One thing that tripped me up when first using DAQmx is the automatic garbage collection it does. It doesn't sound exactly like your problem, but it may be a possibility.
I often wrapped up my data acq tasks in action engines. Using the traditional DAQ drivers under Windows, I could test the action engine as a top-level stand alone vi. I'd run it with the "Config & Start" action, then run it again a few times with the "Read" action, then run it yet again with the "Stop & Clear" action. The DAQ task ID was held in a shift register, available for reference on subsequent runs.
This technique failed under DAQmx because all open DAQmx task refnums are cleared when LV completes execution. So I'd run the action engine with the "Config & Start" action, and all was well. When I tried to run it next with the "Read" action, I was pulling a no-longer-valid DAQmx task refnum out of the shift register, producing an error. The workaround is simply to make a non-terminating test vi that calls the action engine as a sub-vi.
Here's a link so I can stop typing sooner.
"Clear Task" will will indeed clear a task even with an error wired in. I'm not sure about "Stop Task."
Finally, FYI, your end goal definitely sounds feasible under DAQmx.
-Kevin P.
06-07-2007 12:30 PM
06-08-2007 10:24 AM
06-08-2007 10:40 AM
I'm not sure if this is related but you are start the AI before you config the AO and DO, if synchronization is an issue you will have issue because the sample clock source is set to the AI. If you want to make sure that everything is synched, then move the AI start vi after the Config AO and DO vi's.
Charles
06-08-2007 10:43 AM
06-08-2007 11:07 AM
B. ...I have observed that the results sometimes seem to vary from one run to the next. I have not been able to identify any correlation with anything which might cause this effect.
... Would a named task behave any differently?
B. Yeah, my vague memory is similar -- results from attempts to display Task ID text would vary with no apparent rhyme or reason. However, I eventually became convinced that the actual functional behavior of the code using the Task IDs was reliable whether or not the text displayed as expected, and pretty much just moved on with things without pursuing it further.
Dunno if a named task would behave differently, but shouldn't hurt any. (I generally haven't named my tasks and am not aware of any particular benefit. Unless maybe it would enable some parallel process to lookup tasks by name rather than needing wired task ID's, analogous to named queues. Never tried it and only just thought of it while typing.)
-Kevin P.
06-11-2007 08:38 AM
06-30-2009 03:52 PM
Lynn,
Did you ever find a remedy for this issue?
I have the exact symptoms you describe in this post on LV8.5 in the development environment.
In my case, I'm attempting to clear an analog load task in order to ressert a hardware null. I pass arrays of tasks (AI, AO, Counter, DIO) around my statemachine in a cluster. When I arrive at my clear state, and call the DAQmx Clear Task.vi, the task value passed to the funtion is empty and the task is not cleared, because when I go to reconfigure, I get error -50103 stating that the resouces for the specific hardware location are reserved.
The task name will also randomly show up in a probe on the task array but the majority of time it's MIA.
Yet in the acquire state, after initial hardware configuration, the DAQmx Read.vi sees the task and executes accordingly. I haven't been able to locate this as known LV issue but I've seen it in both 8.2.1 and 8.5.
Thanks in advance.
Steve
07-01-2009 08:37 AM
Steve,
I have not worked on that project since shortly after my previous post and I do not have access to the computer on which it is running.
Looking at my archive copy, I see that I named the tasks from string constants in the configuration VIs. I did not wire the task out terminals from those VIs. I placed Task I/O constants containing the names at the inputs to the subVIs which used those tasks.
My conclusion form looking at the code was that I never satisfactorily resolved the issue but was able to get it working by dropping the Task I/O constants all over the diagram. Of course this makes a maintenance nightmare, but I already told the client that the program would be rewritten, not modified, the next time something needed to be changed.
Lynn