09-03-2019 02:01 PM
Hi, just a simple DAQmx question. I would like to create 2 different tasks that use the same analog input physical channels. Maybe I could create them and pop them into a little cluster. I would only *USE* 1 task at a time. I'd like to create a task that can be used to (quickly, immediately, as in tout de suite!) fire a DAQ event when an analog input exceeds a threshold - my DAQ loop would sleep until that occurs. Then, in response to the event, I would "switch tasks" and go into a more leisurely loop mode of grabbing N finite samples, say, maybe 20 samples per millisecond. I might need to "Clear Task" or "Stop Task" or "Obliterate Task Forever" or whatever to the 1st task before starting the 2nd task, and that's OK as long as it doesn't take forever to do it. Does this make any sense? Much thanks to this great community! paul
Solved! Go to Solution.
09-03-2019 02:19 PM
Yes only one task for a given channel can be active at a time so you will have to stop the first task before starting the second task and vise versa.
Ben
09-03-2019 03:44 PM
What do you consider "forever"?
09-03-2019 09:14 PM
Hah! Guess I ought to think about that... a few single digit milliseconds shouldn't bother me - your thoughts? Paul
09-03-2019 09:31 PM
Do you really need 2 separate tasks? I don't see a need for it in your description.
You could simply monitor the data from your 1st task, ignore everything *before* the threshold crossing, then only retain some # of samples *after* it. What do you gain by shutting down the task and starting up a new one?
-Kevin P
09-04-2019 09:18 AM
Maybe - I'm trying to respond as quickly as possible to an analog input trigger (maybe use a DAQ event?). That is, after triggering, quickly set an analog output, and change states in the software state machine. After that, I want to 'change control modes' and constantly/forever loop, taking, say, 20 finite samples and sucking them into the code for 'more leisurely' processing. After 'changing modes', I no longer need the analog triggering (no need for the DAQ event any more) - i'm just looping, grabbing a batch of input samples every millisecond or so. Does this clarify my scheme? paul
09-04-2019 10:30 AM
For fast reaction, I'm supposing you're using a device that natively supports analog triggering.
I don't believe there's direct support to "catch" a DAQmx analog comparison event with a LabVIEW event structure. But if you can configure your task to use an analog start trigger, you can know that sampling will begin immediately after the triggering condition is satisfied.
From there, you can try to register for a "sample complete" or "sample clock" DAQmx signal event. I haven't dabbled with DAQmx events much, but both sound like they ought to work for you.
In the event case you can set your new AO value, presumably as part of an unbuffered, software-timed task. I'd next terminate the loop containing the event structure, remove registration for the DAQmx event, and proceed into a "normal" while loop that services the task via DAQmx Read.
Something like that. There's other fancy things you could try like switching event registration over to "Every N Samples..." and staying in the original event structure loop, but I don't expect it to be worth the extra trouble. Let the triggering condition alert you 1 time via event.
FWIW, 1 msec loop rates aren't really "leisurely" for DAQmx under Windows. You can get the speed, but not super consistently.
-Kevin P
09-04-2019 12:27 PM
Much thanks, Kevin - yep, I've ordered a cDAQ 9185 with 9205 AI card and 9263 AO card. The 9205 supports analog triggering, so I ought to be able to pull this off as you've outlined. I'm pretty fuzzy on NI's tutorial on DAQ events - they say about 'software events': "Signal Event—Occurs when the specified hardware signal occurs. Supported signals include the counter output event, change detection event, sample complete event, and the sample clock." Gonna have to play around & see what's available with the 9205/9185 hardware. Wish their docs were better on this stuff. You'd think I could just look it up in either the hardware or DAQmx manuals, sigh. Thanks for your suggestion, Kevin
09-04-2019 12:31 PM
@PaulOfElora wrote:
.... Wish their docs were better on this stuff. You'd think I could just look it up in either the hardware or DAQmx manuals, sigh. Thanks for your suggestion, Kevin
Ben