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!