Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How to query DAQmx task state in LabVIEW?

I have a question about DAQmx,

 

DAQmx task state model is described in DAQmx help, and the task state could be set with DAQmx Control Task.vi, or DAQmx Start Task and DAQmx Stop Task, etc..

While I want to know how to query the task state in LabVIEW?

 

I opened these VIs to find what was going on in them, and I found that these VIs call 'nilvaiu.dll' with Call Library Function Node.

 

In the function name list of this Call Library Function Node, I found a function contained in the dll with the name of 'DAQGetTaskState', and I believe this function could solve my problem. The remaining difficulty is, I don't know the exact prototype (input and output parameters) of this function, so I can't use it...

 

Anyone can help me with the prototype of this function, so I can call it with Call Library Function Node?

Or anyone has a better solution to query the DAQmx task state?

 

Thanks.

Message 1 of 20
(10,325 Views)

Hi Wang Shen,

 

The task state is not that difficult to derive from what you are doing with the task.  Users should not need to query the current task state, as they only need to know a few of the basics.  Also, the task state is set implicitly by using the API, and set explicitly when using the "DAQmx Control Task.vi". 

 

The only time you need to use that VI is when you are going to be doing a DAQmx Start and DAQmx Stop in a loop.  In this case, you want to use the "DAQmx Control Task.vi" to set the task to the "Committed" state before you enter your loop that uses the start and stop functions.  This gives you better performance since the task knows that nothing will have changed between loop iterations.

 

Other than the case described, you should not need to worry about the task state.  It's nice to have users aware of it, but unless you really need to tweak it, there's no need to worry about it. 

 

Enjoy using DAQmx!  Keep on the forums if you have other questions...

 

-gaving

0 Kudos
Message 2 of 20
(10,313 Views)

Thank you so much for your reply.

 

Because I'm teaching LabVIEW (with DAQmx) in a course, I want to know the details of the DAQmx Task State model. I believe the knowledge about this model will help to understand and explain the working mechanisms of DAQmx. Unfortunately,the details are so limited, even in the help file.

 

I hope that NI could provide a task state query VI in the future, maybe as an advanced VI just like DAQmx Control Task. From the nilvaiu.dll, it seems that the desired function is just there but not available to the users...

 

I'm using LabVIEW 8.5 with DAQmx 8.x, so I don't know whether this functionality is already available in the current newer versions of LabVIEW and DAQmx.

 

Thank you again for your reply.

 

Shen Wang

0 Kudos
Message 3 of 20
(10,303 Views)

I'd have to agree that it seems pretty odd that there's a method to Set a task state but no method available to Get a task state.  In fact, I kinda already *did* agree in this recent thread.

 

Is there any more thorough explanation for not exposing a Get method?  Even if I end up agreeing that that users shouldn't concern themselves with such things (and to be fair, my bias is to want to decide that for myself thankyouverymuch), I'm still at least curious.

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 4 of 20
(10,294 Views)

I'm guessing you've found the documentation in the help file?  Open the NI-DAQmx help file and search for task state model. (you should see what I have made a pdf of and attached here)

 

Let's do this since everyone's curious: We can use this thread as a starting place and discuss specific questions about the model.  If we ever begin to tread into the realm of "that information is not public" we'll simply say so.  Let's work together here and see if we can appease your curiosity. 🙂

 

deal?

 

-gaving

0 Kudos
Message 5 of 20
(10,281 Views)

Deal.

 

I've *thought* that I had at least moderate familiarity with the state model for some time and have used it in a

few apps when I knew I'd want to stop and restart quickly.  Things I'd read either in the help or on this site

suggested that by committing a task before starting it, a subsequent stop and re-start would require less

work by the task state machine than if I started the task without an explicit "commit."   I don't recall whether

I ever tested the turnaround speed in different cases or whether I took it on faith.

 

I had been under the impression that on a "stop" action, the task state machine would revert back to the

last state explicitly set by the developer prior to the "start" action.  Thus, when states are not commanded

explicitly, the task would revert all the back to "unverified."  But if a commit action preceded the start, then

a stop would merely revert back to committed.

 

Judging by the diagram, this impression isn't quite right.  It now appears that a "stop" can *only* revert back

to the "committed" state.  It is also unclear to me what would constitute an "abort" action -- I presume this

would be things like internal errors and that an explicit "abort" is not directly available?   Further, it's unclear

exactly what path a "DAQmx Clear" would take through the state model if issued to a running task.

 

Finally, and getting back to the original point of curiousity, why not allow the ability to simply query a state

considering that the much more intrusive ability to SET a state *is* being allowed?  It seems awfully

counter-intuitive.

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 20
(10,268 Views)

Oops, quick follow-up.  I noticed that the API does provide for an "abort" action to be called by a developer.

I didn't remember that particular state being available before, but maybe that's just because I'd never had

a reason to want to use it.

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 20
(10,261 Views)

Hi Kevin,

 

I see how the diagram from the DAQmx Help does give off the impression that calling DAQmx Stop will always revert back to the "Committed" state.  However, this is not the case.

 

DAQmx Stop will revert back to the state that the task was in before it was last started.  The diagram should probably indicate this somehow, but I'm not sure the best way that NI could illustrate the behavior without killing the readability of the diagram.  Although, I suppose that a messy-but-accurate diagram is probably better than an organized-but-incorrect one.  The description of the actual behavior can be found in the Explicit Versus Implicit State Transitions section of the help:

 

  • Commit—If your application performs multiple measurements or generations by repeatedly starting and stopping a task, explicitly commit a task. Committing the task exclusively acquires the resources that the task uses and programs some of the settings for these resources. By explicitly committing the task, these operations are performed once, not each time the task is started, which can considerably decrease the time needed to start your task. For example, if your application repeatedly performs finite, hardware-timed measurements, the time required to start the task can dramatically decrease if you explicitly commit the task before repeatedly performing these measurements. Explicitly committing a task also is required if you need to perform additional read operations of the samples acquired by the task after stopping the task. For more information, refer to Using the Start Task Function/VI

 

 

For confirmation of the behavior, here's a benchmark that I put together for some training slides.  The benchmark was taken on a PCIe-6353, sampling 4 samples per trigger @ 1 MHz.  The input trigger signal was a 100 kHz sine wave. 

 

 

2011-04-11_151355.png

 

 

With the high sampling rate, low amount of data, and fast trigger signal, the observed loop rates are almost completely due to overhead from the task-state transitions.  I chose to use a reference trigger since start triggers are now re-triggerable in hardware for X Series.

 

 

The suggestion to make the task state queryable would be a good one for the idea exchange.  Does somebody want to post it there?

 

 

Best Regards,

John Passiak
Message 8 of 20
(10,241 Views)

@John_P1 wrote:

Hi Kevin,

 

I see how the diagram from the DAQmx Help does give off the impression that calling DAQmx Stop will always revert back to the "Committed" state.  However, this is not the case.

 

DAQmx Stop will revert back to the state that the task was in before it was last started.  The diagram should probably indicate this somehow, but I'm not sure the best way that NI could illustrate the behavior without killing the readability of the diagram.  Although, I suppose that a messy-but-accurate diagram is probably better than an organized-but-incorrect one.  The description of the actual behavior can be found in the Explicit Versus Implicit State Transitions section of the help:

 

  • Commit—If your application performs multiple measurements or generations by repeatedly starting and stopping a task, explicitly commit a task. Committing the task exclusively acquires the resources that the task uses and programs some of the settings for these resources. By explicitly committing the task, these operations are performed once, not each time the task is started, which can considerably decrease the time needed to start your task. For example, if your application repeatedly performs finite, hardware-timed measurements, the time required to start the task can dramatically decrease if you explicitly commit the task before repeatedly performing these measurements. Explicitly committing a task also is required if you need to perform additional read operations of the samples acquired by the task after stopping the task. For more information, refer to Using the Start Task Function/VI

 

 

@for confirmation of the behavior, here's a benchmark that I put together for some training slides.  The benchmark was taken on a PCIe-6353, sampling 4 samples per trigger @ 1 MHz.  The input trigger signal was a 100 kHz sine wave. 

 

 

2011-04-11_151355.png

 

 

With the high sampling rate, low amount of data, and fast trigger signal, the observed loop rates are almost completely due to overhead from the task-state transitions.  I chose to use a reference trigger since start triggers are now re-triggerable in hardware for X Series.

 

 

The suggestion to make the task state queryable would be a good one for the idea exchange.  Does somebody want to post it there?

 

 

Best Regards,


I like this option! But, I don't see a huge time saving as mentioned above. Start and Stop task adds overhead to my data Read. With committing the channel, I am saving about 25ms tops.

 

Without commit, Start and Stop task is doubling my loop time (200ms for a 1000 sample acquisition at 10kHz)

With commit, it brings it down to 170-175ms.

0 Kudos
Message 9 of 20
(7,250 Views)

 

Can you post a snippet of your code?   Are you sure all of that 175-200 msec is spent on the stop/restart loop?

 

100 msec is accounted for as acquisition time when reading 1000 samples at 10 kHz.  Could there also be

some idle time waiting for a trigger signal?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 20
(7,241 Views)