DAQMX task ID with local variables?

[rmp]

Hi folks,

Long time Labview programmer (although I don't do consumer/producer)... new to DAQMX.

I've been able to test out my new myDAQ by writing a vi that sets up AO (transmit a frequency pulse out to a speaker); and AI (receive the reflection of the pulse thru a microphone). And, I can use a while loop to repeat the AO & AI without having to reconfigure the AO & AI each time (the two Task IDs are looped through shift registers).

But, I'd like to now build my application with labview "states" (cases within a while loop). So, I'd like the AO/AI config in one state and the AO/AI start/execution/stop in a different state. It's hanging up in the very first wait for AO completion (start/execute/stop state)... I don't why or how to resolve this... can you help? I'm suspecting that I'm not handling the Task IDs correctly.

I've tried putting the TASK ID OUT into an indicator in the config state and using it's local variable in the start/execute/stop state. That doesn't work.

So, I just tried putting shift registers in all of my states and passing the Task IDs through those shift registers. Same problem. Stumped!

Richard

What am I missing here???

[Kevin_Price]

Hard to say without code.  What you're working on is generally eminently doable.  One guess:  Maybe AO is configured for continuous sampling, thus "wait until done" never ends?

But post the code and it'll likely be easy enough to solve without guessing.

-Kevin P

[rmp]

Thanks Kevin,

OK, I'm posting screen grabs... I can also post the vi (I think) if that is more useful.

[Kevin_Price · Accepted solution]

I don't love everything I see in the run state, but I also don't see an obvious reason to get hung up on DAQmx Wait Until Done.  Are you *sure* that's where things hang?  Did you see it stuck there with highlight execution on?   Spend a little time stepping through the code in highlight execution mode and look for unexpected values or execution sequences.

Other comments:

1. AI task first.  You call DAQmx Read which will implicitly start the task and either return the requested # samples or give a timeout error.  Because it started implicitly, it will then stop the task implicitly as well.  After that, you start it explicitly, wait for it to end, then stop it without ever reading more data.  This looks odd and unconventional, though it still ought to run without hanging.

2. AO task next.  You first wait for an unknown (to me) amount of time, then you start the AO task, wait for it to finish, and stop it.  Other than the leading wait time, this looks more conventional.

-Kevin P

[rmp]

Thanks Kevin,

I did have trace on after I saw it hung up (the counter was not incrementing). At that point in time, it was hung up on the wait until completion in the AO path. I'll investigate this further.

I had a hard time finding examples that would loop through AO and AI after AO/AI set up. So, the impression I had was that the READ would NOT implicitly start (this was based on the "auto start" property for the WRITE). But, now that I look back at the code, I see that the READ does not have an "auto start" property. So, yes, I see that it looks strange.

I'm pretty sure that I need the "wait until complete" if I'm going to be in a tight loop (from my testing it seems that the housekeeping/overhead associated with the READs/WRITEs are huge (10s of milli-secs)... without the wait I think I get errors because I'm trying to execute the READ before the prior READ has completed. Attached is what was working, and what I'm trying to achieve with two states.

I think I've tried looping without the wait_until_complete and without the STOP, but I'll try some more combinations.

[rmp]

Bummer... I was misinterpreting the trace. It not hanging at the wait_until_complete (thanks for pointing me there). Simple bug where I was supposed to programmatically change the event timeout from -1 to 10 ms (to loop the execution state via the timeout event... this allows me to change AO/AI params during looping if I want to).

OK, now I'll play with the wait/start/stop functions to see what I "need" (and if I can get better loop speed... I'm only getting about 4-6 passes/sec, with 200kHz rate, 1024 AO samples, 6000 AI samples and AO wait of about 6 ms).

I hate wasting help forums with stupid bugs on my part. To salvage some "good" out of this, I'll post the working two states so that others can get a simple example of config and then looping thru AO/AI (that I could not find). I think my example is a basic app that many would want (simultaneous AO and AI).

[rmp]

OK, some good news... this is working:

• attached is run state without some wait_until_complete, and STOPs
• the loop time is quicker... probably 10/sec. Of course I have some large FFTs, cross correlations and plots happening in realtime... this is probably taking 10s of milli-secs.

I think I HAVE to have the STOP in the AO path; and I'm pretty sure that I need the wait_until_complete in the AI path.

I'm guessing that local variables for the TASK IDs are going to work. I like the look of that code better (these are small size variables so I choose cleaner looking code over this slight loss in efficiency). I'll try that next

[cbutcher]

Read will autostart, and autostop, unless you manually call Start before you call Read. If what you want is to read a certain duration at a specific time, you could use a trigger (perhaps linked to your AO pulse) and finite samples acquisition for the AI. Then, Start before the loop, Stop after the loop, and place the Read inside the loop.

You'd want to make the task retriggerable, which is found in the DAQmx Trigger Property Node a few sub-menus down - you can use the search to simplify finding this by clicking Browse then hitting the magnifying glass, alternatively (having just found it) it's under Start > More > Retriggerable.

However, I'm also not sure why the DAQmx tasks should be hanging - with the timeouts they should at worst just error out after 1 second.

As a side note, you can put the error wires in shift registers too and avoid the local variables if you want 🙂

Edit: I see that you already found the problem, which was about to be my next question looking closer at the pictures - how is the state transition handled. However, regarding your comments on Local Variables - the reason people often avoid using Local Variables is not so much a cost in execution speed (which is quite small, although does exist) but that it makes it much harder to trace around a block diagram. With local variables, it's harder to find out who writes something, who reads it, in which order, and so on. With wires, you can just follow the wire 🙂

[rmp]

Thanks cbutcher,

Unfortunately, I don't think triggering and retriggerable properties are supported with my myDAQ Student device... but, this is probably changing the topic of this post. I have another post on this exact subject (https://forums.ni.com/t5/LabVIEW/Student-myDAQ-audio-radar-sync-transmit-and-receive/m-p/3638826/hig...).

[cbutcher]

Ah. Sorry - I read that thread and thought it was pretty interesting, but failed to make the connection here. Sorry additionally for the unhelpful suggestion!

[JÞB]

without looking at ALL of the code we cannot see where you may have race conditions.  Excaples those error locals should be on Shift Registers  (Just trust me OK?)

A lot of the other locals have no write method shown... that can be a problem if you have independant loops.

Personally, I use a Resource Module (a special type of Action Engine that holds a specific reference to a Resource) for DAQmx Tasks.

[Kevin_Price]

A few more quick hit-and-run thoughts:

1. It appears you have AO and AI running at the same rate.  To sync them in hardware, try sharing a sample clock.  I usually sync tasks via sample clock and relatively rarely need or bother with triggers.  (I would let AO be master and configure AI to be sensitive to the trailing edge, probably the falling edge.  This allows time for AO to propagate and system to respond before AI gets measured.)

2. You can speed up the turnaround time needed by DAQmx to Stop and re-Start a task if you call "DAQmx Control Task" with a "commit" action before the first time you start it.  Search for things like DAQmx Task State Model for more info.

3. With a shared sample clock and finite sampling, you shouldn't need to use "DAQmx Wait Until Done" at all for either task.  DAQmx Read will inherently wait for all defined finite samples before returning (when in finite sampling mode *and* with default input of -1 for # samples to read).  And because the sample clock is shared and the same # samples are used in both tasks, they'll both be done when DAQmx Read returns.

-Kevin P

[rmp]

Very cool, thanks Kevin,

Is the attached diagram the technique to share clock sources? Note:

 - I arbitrarily picked PFI0 because I saw somewhere that this could be used as a clock output (from an internal counter), and somewhere else I saw that some devices allow you to virtually connect an output to a different pin. So I'm hoping that this connects the clock used for AO to PFI0; then AI uses that same PFI0.

 - I didn't initially have the AO #samples = AI #samples, but I 0-padded the AO samples to be = AI #samples

 - the diagram is pretty messy, because I'm still experimenting with DAQMX functionality

I haven't yet investigated your other two points but I will.

[Kevin_Price]

Your use of Export Signal to push the AO clock signal onto PFI0 (and your AI config to use it) look right to me.  There are ways to let DAQmx figure out routing for you though.  My snippet below illustrates both that *and* the other things I was talking about, including some timing code to show how quickly you can stop and restart the tasks when they've first been committed.

-Kevin P

[rmp]

Wow Kevin, thanks so much for putting this together! I can't wait to try this out (bummer, I don't have time tonight!). I really like what you've put together... it looks like it has a chance of working with my little myDAQ Student device.

Interesting that you didn't need shift registers for the Task ID (I guess they're not variables that increment or change). By adding the STOPs you make sure that the AO/AI doesn't get invoked before the prior AO/AI completes.

Conceptually I understand your Time Source sharing. I don't yet understand the concept of "commit" but I haven't done any research on this yet (don't tell me, I want to dig into this a bit).

I was getting about 10 AO/AIs/sec. If I can get closer to 20/sec I'll be able to show kids very decent velocity detection. If your approach works for my device then my next technical issue will be to get the loop-to-loop time to be consistent. I might be able to handle non-constant pass to pass time period but it will add another layer of complexity. I've got an external function generator, but I don't think myDAQ will support external start-trigger.

More tomorrow...

[Kevin_Price]

I don't really know the myDAQ device, but the fact that it's USB is probably going to be a limiting factor.  Using a desktop card, I was measuring stop-restart times of around 2 msec, give or take about 1/2 msec.

I don't know for sure, but have a suspicion that the myDAQ will be at least an order of magnitude slower at stopping and restarting tasks.  Then you'll need to add the time to perform the acquisition as well.  Hopefully you'll have a shot at 20 loops/sec, but it might be that the myDAQ device itself has been the main limiting factor more than the code optimizations we've been focused on.

-Kevin P 

[rmp]

Bummer, I'm guessing that the myDAQ does not support "shared clock" or "commit" (see attached). I've attached the code snippets and errors just in case I'm missing a dumb error.

If I'm right, that the myDAQ doesn't support this shared clock feature, I think the reason is that the myDAQ doesn't have a DSP or sufficient CPU to provide the additional functionality. I can get the myDAQ for about $250 with the Student Labview. I can ask high school students to pay that for this advanced/after-school class. But I think that the CPU based DAQs are all > 2K$... that's a lot of fun tickets.

[Kevin_Price]

Yeah, bummer.   FWIW, you don't need a DAQ with an on-board CPU necessarily, but anything in USB with reasonably fast sampling rates for both AO and AI will be pushing $1k.

It might be worth doing some dabbling with your sound card.  I've not done much with them, and I doubt you'll be able to do hardware sync, but they're often capable of sampling at > 100 kHz.   One little bit of messing around I did recently sampled at 200 kHz using whatever "sound card" was built into the motherboard of an off-the-shelf HP desktop unit.

-Kevin P

[rmp]

Yup, all good points... really appreciate your help and insights.

I had originally planned on just using a builtin sound card, but when I saw the myDAQ for relatively $low, I thought I might be able to do more with that. Plus the DAQMX functions seemed pretty mature and rich. But, ultimately, I think you're right... all I really need is Labview data processing, sound I/O, external speaker and microphone. It'll take considerable processing gymnastics to get over the hardware weakness, but hopefully I can bury those topics in later classes... the basic linear FM homodyne, FFT, system response topics are tough enough (but this is such a cool application to show how it all works).

Anyway, you definitely got task IDs working with local variables, so I'll consider this topic solved. I'll come back to later to post a wrap up with the final/current implementation example for others.

[rmp]

OK, as a wrap up to this topic, attached is a code example:

• AO and AI in same loop
• use of local variables for Task IDs
• myDAQ device
• Labview 2016

To use: connect a TRS (Tip, Ring, Shield) male-to-male cable between your "Analog Out" and "Analog In", on your myDAQ device. Then follow the instructions on the front panel (some description also in the block diagram).