LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx Task Questions

Solved!
Go to solution

These are probably Sir Jeff B questions, but anyone who is a DAQmx guru feel free to chime in.

 

An aside for any newbies reading the post, in case you did not know the knights/soon to be knights specialties, here are some:

  1. Jeff B - Knight of DAQmx and fearless predictions
  2. Altenbach - Knight of optimization
  3. GerdW - Knight of quick replies and quick wit
  4. Bob Schor - Knight of channel wires, report toolkit, and include your %&#(* code
  5. Hooovahh - Knight of TDMS, xnodes, and cheerful responses
  6. rolfk - knight of LabVIEW, Windows, Linux, internals. Answers questions like poetry, beautiful to read, but hard to understand.

Anyway I need to stop digressing. Here is a summary of my program, I cannot include it due to company policy.

 

I have built a general purpose DAQ program for voltage analog input tasks. The user hooks up a DAQ to the computer, usually through USB, and starts my program. The program dynamically queries the DAQ and find the allowed voltage ranges, sampling ranges, etc. The user then chooses how to run the DAQ by changing the voltage range, sampling rate, number of channels, etc. Note we are in an R&D environment, the task is not static and may change from day to day or even hour to hour. (Note I am running the DAQmx device in continuous acquisition mode, basically my program is like a tape recorder.) The compiled exe is set to allow multiple instances, so multiple programs and devices may be running at the same time.

 

So previously, whenever the user changed a DAQ parameter, I would STOP, then CLEAR the DAQmx task and start a new DAQmx task. However, after updating to DAQmx 17.6.1, and running the program on 32 bit systems, I would sometimes get the unable to allocate resource error, or not enough resources error. Something like that.

 

So I decided to change my program somewhat due to the advice in the forums here. So please correct the following where I am mistaken as this is what I understood from the forums:

  1. Reusing a DAQmx task is better than starting a new one. Reusing a task is possible for the following conditions
    1. Adding channels to the task
    2. Changing the sampling rate
  2. Once a DAQmx task property is set is impossible to unset it.
    1. For example, I can reuse the task is the user decides to save the data, in Log and Read mode. However, if the user saves the data in Log mode only, and then tries to switch back to Log and Read mode, any properties that were set in the task for Log mode only are not erased and I get an error.
  3. In order to reuse the DAQmx task I use the following sequenceSnap1.png

     The DAQmx Stop has to be right after the abort VI otherwise any modifications to the task do not work. After the abort VI the task is in an unstable state and only Start or Stop will put it in a stable state according to the help file.

  4. If I need to start a new task I will use the above followed by a Clear Task VI.

 

So I guess my questions are:

  1. Is there anything wrong in my logic here?
  2. Are there any other situations where a task can be reused?
  3. I cannot get around closing and starting tasks, is that always going to be a problem?

Thanks to anybody who has read this long post. Kudos to you.

 

Cheers,

mcduff

0 Kudos
Message 1 of 20
(6,187 Views)

While it has been a long time since I last did it...

 

We were able to configure multiple tasks that use the same resource but could only have one active at a time. That feature would allow quickly changing tasks by just stopping one before we start the other task.

 

So as long as you only have one active task associated with a DAQ resource, you should be allowed to have more than one task configured but just not more than one running.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 20
(6,163 Views)
Solution
Accepted by mcduff

My comments:

 

1. Reusing a task is *generally* better than clearing and recreating.  An environment like yours with multiple executables and multiple devices may be an exception.  

2. Many properties would persist across a Stop->Restart sequence that would *not* persist across a Clear->Recreate sequence.

3. I don't like the looks of this at all.  I wouldn't include the "abort" action anywhere in the sequence.  I've also never attempted an "unreserve" on a task before stopping it.   

   Unreserving a stopped task that you later intend to restart may open you up to problems.  By keeping the same task ref, the task knows what hw resources it *wants* to use when started, but during the time the task is unreserved, some other task could lay claim to them.  Then you get an error on the attempt to restart.

   I've also seen problems when tasks were cleared and recreated too rapidly.  Some of the cleanup was still in progress in the background, preventing the newly created task from getting access (yet) to some needed resources.

4. Stop and Clear are plenty if you want to create a new task.  No need for special "Control Task" operations.

 

I have not explored all the nuances of the DAQmx Task State model.  For example, if I'm in the "reserved" state and attempt to add a channel to my task, I'm not sure whether:

- it will succeed, remain in "reserved" state, but now include the new channel among the things reserved

- it will succeed by automatically unwinding to an unreserved (or unverified?) state, adding the channel, and staying in that state rather than re-reserving

 - it will fail with an error that I can't do an "add channel" operation to a task whose resources are already reserved

 

 

Note also that actions like "unreserve" are only meaningful if you had perfomed a "reserve" or "commit" prior to starting the task.  A DAQmx Stop will unwind back to whatever state the task  was in when DAQmx Start was called.  By default, if you didn't explicitly set a task state with DAQmx Control Task before starting it, the task will unwind to the unverified state.  

 

A summation:

1. The fastest possible turnaround for a task Stop/Start requires you to "commit" the task before starting.  I only do this when I don't plan to change task config between Stop and re-Start.

2. Fully clearing a task and recreating it allows the maximum amount of changes to the task config.  Sometimes DAQmx Clear will return execution control to the app before all resources are truly cleared up.  An immediate attempt to recreate a similar task may result in an error.

   I'd be inclined to retry every 1/4 second for maybe 2 seconds before giving up.  Maybe set and unset cursor busy during this retry period.

3. An in-between position might be to "reserve" the task before starting.  Then a Stop will return the task to the "reserved" state.  You'll need to experiment to determine which task config settings are allowed to change while in "reserved" state to see whether this approach can work for you.

 

 

-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 3 of 20
(6,151 Views)

@Kevin_Price wrote:

My comments:

 

1. Reusing a task is *generally* better than clearing and recreating.  An environment like yours with multiple executables and multiple devices may be an exception.  

2. Many properties would persist across a Stop->Restart sequence that would *not* persist across a Clear->Recreate sequence.

3. I don't like the looks of this at all.  I wouldn't include the "abort" action anywhere in the sequence.  I've also never attempted an "unreserve" on a task before stopping it.   

   Unreserving a stopped task that you later intend to restart may open you up to problems.  By keeping the same task ref, the task knows what hw resources it *wants* to use when started, but during the time the task is unreserved, some other task could lay claim to them.  Then you get an error on the attempt to restart.

   I've also seen problems when tasks were cleared and recreated too rapidly.  Some of the cleanup was still in progress in the background, preventing the newly created task from getting access (yet) to some needed resources.

4. Stop and Clear are plenty if you want to create a new task.  No need for special "Control Task" operations.

 

I have not explored all the nuances of the DAQmx Task State model.  For example, if I'm in the "reserved" state and attempt to add a channel to my task, I'm not sure whether:

- it will succeed, remain in "reserved" state, but now include the new channel among the things reserved

- it will succeed by automatically unwinding to an unreserved (or unverified?) state, adding the channel, and staying in that state rather than re-reserving

 - it will fail with an error that I can't do an "add channel" operation to a task whose resources are already reserved

 

 

Note also that actions like "unreserve" are only meaningful if you had perfomed a "reserve" or "commit" prior to starting the task.  A DAQmx Stop will unwind back to whatever state the task  was in when DAQmx Start was called.  By default, if you didn't explicitly set a task state with DAQmx Control Task before starting it, the task will unwind to the unverified state.  

 

A summation:

1. The fastest possible turnaround for a task Stop/Start requires you to "commit" the task before starting.  I only do this when I don't plan to change task config between Stop and re-Start.

2. Fully clearing a task and recreating it allows the maximum amount of changes to the task config.  Sometimes DAQmx Clear will return execution control to the app before all resources are truly cleared up.  An immediate attempt to recreate a similar task may result in an error.

   I'd be inclined to retry every 1/4 second for maybe 2 seconds before giving up.  Maybe set and unset cursor busy during this retry period.

3. An in-between position might be to "reserve" the task before starting.  Then a Stop will return the task to the "reserved" state.  You'll need to experiment to determine which task config settings are allowed to change while in "reserved" state to see whether this approach can work for you.

 

 

-Kevin P


Be careful with that statement Kevin.  Its better to explicitly unreserve the tasks when switching between Tasks that share a resource.  Don't be fooled into thinking that the DAQmx state transition diagram is coded bug free.

 

Just saying........

 

With that minor proviso McDuff Kevin deserves kudos for a masterful statement

 

If you have a USB 6212 laying around.  you can poke though this example.

 

 


"Should be" isn't "Is" -Jay
Message 4 of 20
(6,147 Views)

Thanks for all of the advice! Wish that I could give more than 1 kudo.

 

Honestly, I think I am getting more confused the more I think about it.

 

@Ben

Unfortunately we cannot configure tasks beforehand, too many possible configurations.

 

@Kevin

Reusing a task is *generally* better than clearing and recreating.  An environment like yours with multiple executables and multiple devices may be an exception.  

 

That is what I thought and did before DAQmx 17.6. It worked, and worked well. Only after DAQmx 17.6 did I start to have problems on 32 bit systems, (32 bit Win7 and LabVIEW RTE). These problems did not manifest or maybe take a longer time to manifest on 64 bit systems. That is why I went and changed my model.

 

I don't like the looks of this at all.  I wouldn't include the "abort" action anywhere in the sequence.  I've also never attempted an "unreserve" on a task before stopping it. 

 

The reason I went with that route was that the abort explicitly releases all of the resources, at least according to the help file. Each exe has only 1 task applied to a specific DAQ device. In my program I have a window that shows all the DAQ devices and the user double-clicks the one they want. If the DAQ device is used by another exe it is "grayed out" in the selection table. (I find devices in use by trying to start a simple task with them and if I get an error, in use.)

 

I've also seen problems when tasks were cleared and recreated too rapidly.  Some of the cleanup was still in progress in the background, preventing the newly created task from getting access (yet) to some needed resources.

4. Stop and Clear are plenty if you want to create a new task.  No need for special "Control Task" operations.

 

What is too rapid? I have a State Machine it goes to DAQ stop, DAQ Clear, then starts the DAQ configuration sequence. I have always assumed that when the error propagates out of the DAQ clear VI, the VI is finished. Is is running in the background still? I would assume no, because you would not be able to catch the error then. No idea.

 

Fully clearing a task and recreating it allows the maximum amount of changes to the task config.  Sometimes DAQmx Clear will return execution control to the app before all resources are truly cleared up.  An immediate attempt to recreate a similar task may result in an error.

I'd be inclined to retry every 1/4 second for maybe 2 seconds before giving up.  Maybe set and unset cursor busy during this retry period.

 

To reiterate never a problem until DAQmx 17.6, and only on a 32 bit system. My program can ignore the error, but the error never goes away. I can wait and try to reconfigure, I get the same error. To get over the error I needed to restart Windows.

 

@Jeff

Thanks for the example and chiming in. I will look at your example in more detail when I have time.

 

Cheers,

mcduff

 

 

0 Kudos
Message 5 of 20
(6,136 Views)

Thanks again for all of your help.

 

I probably should have added this tidbit.

 

When I get the "Not enough resources" error, I do not think it is due to the DAQ device. It is my impression, (correct if wrong), that resources for the task are allocated in the "kernel" memory of the OS. I think it is these resources that are not being cleared when I call Clear Task. For example,if I allocate a big buffer I get the error relatively soon, if not, I need to Create/Clear multiple times before I get the error. I was/am hoping by reusing the task, no new resources in the kernel memory are allocated.

 

Cheers,

mcduff

0 Kudos
Message 6 of 20
(6,121 Views)

Consider this speculative, but trying to help.

 

Can't speak to DAQmx 17.6 or use of "kernel" memory in particular.  I would fully expect that reusing a task that remains reserved or committed when stopped would reuse the same memory.  I'd also expect (with less confidence) that a task that was stopped, unwound to an unreserved or earlier state, and then soon restarted would often end up reusing the same memory (assuming no task config changes demanded more memory such as higher sample rate, more channels added, etc).  But it would not be guaranteed.

 

Do you see the "not enough resources" error even *after* getting rid of all the "abort" actions?  Or have you not done trials after removing them yet?

 

Another caveat: the large bulk of my DAQmx experience comes from desktop and PXI boards.  I've been aware of a number of limitations and quirks with the USB DAQ boards (sometimes due to Microsoft more than NI) and avoid them when I can.  It's quite possible that the *nature* of resource reservation and allocation for a fleet of USB DAQ's is just inherently more problematic than with a chassis full of PXI cards.  I don't *know* that, but would not be surprised if it's one of the elements at play here.

 

Does any device *require* DAQmx 17.6?   Maybe it's worth the pain and effort of reverting to an earlier driver version as part of your troubleshooting? 

 

It's interesting that you can force the error sooner when your task has a bigger buffer.  That seems like a useful clue.  Your thought that the kernel resources aren't clearing when you do a Clear/Create sequence seems plausible.  I *think* I recall a discussion here someplace confirming that some of those resource clearing jobs are queued up but not yet necessarily complete when DAQmx Clear returns execution control back to the app.  That's what led me to suppose it could be worth retrying the re-Create/Start until a little bit of time passes.  The 2 seconds was merely a guess based on gut feel that less than 1 second seemed premature and more than 10 is likely pointless.

 

Again, both the *nature* and the *timing* of task clearing may be different for USB DAQ's, my thoughts come primarily from desktop board experience.

 

Sorry it's a bit of a ramble.  *Do* be sure to remove the "abort" actions, and very carefully consider (and probably experiment) whether your explicit task state transitions are helpful or necessary.  If there is a subtle bug in DAQmx 17.6, it's more likely tucked away in the corners of the lesser-used features such as explicit task state transitions rather than in the default behavior of simple task operations.

 

 

-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 7 of 20
(6,094 Views)

I do read between the lines that there may be a bug in the newer version of the DAQmx drivers. To prove it and get some attention for a fix will require some work to confirm id did NOT happen in earlier versions.

 

If it turns out that the "feature" appears in more than the most recent version of the driver then a more drastic approach may be available. Think about separating the configuration from the code that does the collection. Then you can pass a file path to a dynamically load "collection" routine that reads the config from file, does the work, close and then exists. This would let Windows clean up all of the resources as the Collection code exits.

 

Just thinking out loud...

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 20
(6,088 Views)

@Kevin_Price wrote:

 

Do you see the "not enough resources" error even *after* getting rid of all the "abort" actions?  Or have you not done trials after removing them yet?

 

 I've been aware of a number of limitations and quirks with the USB DAQ boards (sometimes due to Microsoft more than NI) and avoid them when I can.  It's quite possible that the *nature* of resource reservation and allocation for a fleet of USB DAQ's is just inherently more problematic than with a chassis full of PXI cards.  I don't *know* that, but would not be surprised if it's one of the elements at play here.

 

 

Again, both the *nature* and the *timing* of task clearing may be different for USB DAQ's, my thoughts come primarily from desktop board experience.

 

Sorry it's a bit of a ramble.  *Do* be sure to remove the "abort" actions

  

-Kevin P


I'll agree with Kevin on removing all aborts!  Use the timeout property to prevent "hung" tasks and handle the errors.

USB is a PnP tech that can be troublesome.  I have a sneaking suspicion about "Resources" that do not physically exist. (e.g. timing sources on software timed tasks are....in software.) Implict forward state transitions all seem to work just fine but... Look into the DAQmx Examples.  None use a predefined "Task" and Commit / Run/ run/ run/ run/ such as you see in the Action Engines in my example code.  So the full state transition diagram may not be fully addressed in testing  on when software resources are implicity released.  They are released when  the vi goes to idle state but, the vi is not left in the idle state.  Instead it is reserved for execution by the caller.

 

Destroying and Recreating the Task requires Windows garbage collection to finish "Destroying" the task.  That is not necessarilly the way to go in a tight loop.  You'll start to see issues like Kevin described and perhaps the reason you needed to change your model because of the undestroied resources pending destruction.  Moreover, Remember each instance of DAQmx driver vi's is really a CLONE.  so having a lot of Creates, Aborts and Destroiys requires a clone namesspace for each task.

 

Creates really are not necessary nor are destroys and aborts are evil.  You may be better off teaching the User how to use the DAQmx Wizard to define the "Task of the Day" and save a whole lot of memory footprint for creates aborts and destroys which actually are expensive for memory allocations / deallocations.

 

$0.02


"Should be" isn't "Is" -Jay
Message 9 of 20
(6,080 Views)

One additional little tidbit worth of chiming in:

 

This is somewhere between an impression and a recommendation.  I *think* that your particular scenario with volatile, user-determined, short-term configurations is one where you don't truly *need* lightning fast turnaround on a Stop/Start or a Clear/Create sequence.    That's one of my mostly hidden assumptions when recommending the Clear/Create/Start approach with multiple retries on error.  Making the user wait up to a few seconds for the system to clear its brain might make the programming more straightforward and reliable, which is probably more valuable in the long run.  Attempts to micro-manage the DAQmx task state may not pay enough dividend to be worth the extra effort.

 

On the other hand, it isn't entirely clear that a Clear/Create/Start sequence *will* be more reliable on your system the way I'm inclined to expect it *should* be.

 

 

-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 10 of 20
(6,068 Views)