I'm working with a counter output task with a PXIe card and I am noticing that when i call clear task, the output pulse train doesn't stop outputting. I would like to do this in my 'close.vi' wrapper which handles the task generically at this point, and adding a 'daqmx write' call to that vi requires me to know exactly the type for the polymorphic selector.
Is there any way to reset this generically so it would work for any counter out task type, digital out etc.?
Solved! Go to Solution.
I've done a lot with counters and this is not a symptom I've observed or heard of before. What device are you using? What version of DAQmx?
A generic approach you might try is to call DAQmx Stop and DAQmx Clear in sequence. Neither are specific to task type, so your wrapper preserves its generic nature. Note that stopping and clearing DO and AO tasks may leave the output terminal at the state/voltage you last left it. It won't necessarily revert to its default power-up state.
Further note: I used to call DAQmx Clear without first calling DAQmx Stop. Some years ago, I changed that habit for a specific reason I can't now fully recall. I think it related to the idea that DAQmx Stop behaved synchronously -- all actions related to stopping the task were completed before the function call returned. Whereas I believe that DAQmx Clear includes some asynchronous aspects. The function call can return before *all* resource clearing operations have run to completion.
- Kevin P
Sorry i should clear up what i was saying - the counter output pulse train does stop on clear task, however, it still pulls the line low to ground. My UUT has bidirectional IO lines and leaving the PFI line its connected to pulling the UUT line low can affect other readings.
Now if i call a DAQmx reset device, this clears it all up and the PFI line returns to open, allowing my UUT line to reach its true max and min values, but i'd rather not reset the whole device if i can avoid it. Really i'd like to reset a channel instead, in DAQmx is that an option somewhere?
You might be running into a side effect of a behavior known as "lazy uncommit." I'm not personally an expert on it, but earch that term & you'll find more info, hopefully including a direct solution.
[Edit: here's one particular useful article I just browsed.]
Yeah i found that discussion too and the DAQmx Tristate call was exactly what i was looking for, thanks so much!