Does DAQmx Stop Task.vi need to be called before DAQmx Clear Task.vi?

[JKSH]

Hello,

The documentation of DAQmx Clear Task.vi says "Before clearing, the VI aborts the task, if necessary, and releases any resources the task reserved." Does that mean the end result will be the same, whether or not I call DAQmx Stop Task.vi before clearing a continuous task?

I'd like to minimize my VI calls where possible, but want to be sure I won't cause any leaks.

Thanks.

[crossrulz]

My preference is that I stop a task before clearing it.  But almost every example I have seen just uses the Clear Task.  So I would say that you do not have to call the Stop Task.

[Yamaeda]

As i've understood it, Stop task returns signals/outputs to 0, and Clear task, as it's an Abort, might not.

/Y

[Brad_K]

Hi JKSH,

Omitting DAQmx Stop Task.vi will not cause any memory/resource leaks, as long as you still call DAQmx Clear Task.vi. However, calling DAQmx Stop Task.vi is a good idea because omitting it may prevent some errors or warnings from being reported, such as warning 200010, "Finite acquisition or generation has been stopped before the requested number of samples were acquired or generated."

In general, DAQmx Stop Task.vi does not return analog/digital output channels to 0. There are a couple exceptions (specifically the NI 4431 and NI 4461 devices, which support the AO.IdleOutputBehavior property), but in most cases, output channels maintain whatever value they had before the task was stopped.

Brad

[JÞB]

The DAQmx state transition diagram should be your guide.  If you feel you need to clear a task programatically (I've never needed to but, I haven't done everything) clearing it will expressly unverify all resources the task needs.  This means that nothing is leaked into memory unless there is a bug we can't find (unlikely but, possible.)  So, any other task is free to reserve and commit the resources the cleared task held as long as all the new tasks resources can be verified.

Resources are Verified (yup there they are- the task is not insane.  If the Lords of DAQ ask, its possible!)

Resources are Reserved (Nope, the Lords of DAQ may need them, you can't share.)

"Abort task" will unreserve all resources a task reserved.  "Clear Task" will unverify those same resources.

[JKSH]

Thank you for all your replies.

It makes sense that Stop doesn't reset an output to 0 -- After I set a digital output to HIGH, I probably want it to stay HIGH without needing the task run forever.

The basic things I've learnt from your replies and links are (please correct me if I'm wrong):

• Abort ≠ Stop
• Abort unreserves resources; Stop doesn't
• Clear unreserves and unverifies a task; Stop doesn't
• Unreserving is sufficient for preventing resource leaks, but not memory leaks
• Stop before Clear ensures that all errors/warnings are caught (Question: Why does omitting Stop cause some errors/warnings to be lost?)
• For maximum DAQ efficiency, I should use explicit transitions to minimize verification operations

However, my current application is a test system which runs ~50 DAQmx tasks on each unit and (i) mainly performs low-speed generations/acquisitions, and (ii) shares some physical channels between test steps. Thus, (i) extra verifications wouldn't be a bottleneck, and (ii) I'd need to unreserve after each test step.

So, I'll just use the high-level VIs instead of explicit transitions to keep my BD clean and simple. My self-contained, reusable test VIs simply follow this pattern:

1. DAQmx Create Virtual channel.vi
2. DAQmx Timing.vi
3. DAQmx Read/Write.vi (auto-start)
4. (Do parallel- or post-processing, if any)
5. DAQmx Stop Task.vi
6. DAQmx Clear Task.vi

Next question, since we're now in low-level territory: Is there a difference between:

• Calling DAQmx Clear Task.vi
• Aborting + Unverifying a Task, and then letting its wire end (assuming that no branches exist)?

[JÞB]

Yes we are in low level territory, 

---

Next question, since we're now in low-level territory: Is there a difference between:

• Calling DAQmx Clear Task.vi
• Aborting + Unverifying a Task, and then letting its wire end (assuming that no branches exist)?

---

is not really a good question to ask.  DAQmx (Like VISA) does not really exist "On the wire"  Sure you can put a p-node down and access data members in the class but, the data members really exist in an external storage location.

When LabVIEW wants to work with a DAQmx task it sort of peeks into another world and sees if that definition exists.  If it does GREAT, if not you get an error.  management of all that "otherworldly data" takes place in DAQmx land so, its not so much "Letting the wire end" or "Branches" in LabVIEW (Or any other language calling into DAQmx) that determine the lifetime of DAQmx objects "What is the state of the calling application?" is a better frame for the question of "When does DAQmx release buffers?"

WHAT this means to the developer: Someone fairly bright took care of all those low level allocations and data management so you don't have to.  If you needed to, you could not get there easilly anyway.  So, "Close the hood, there is nothing to tinker with under there."  But do read the DAQmx help file.

[yanyi]

On a slightly different note, if you create virtual channel, then stop task when done and didn't call clear task at all, does that cause memory leak issues? Aka does this example benchmark code leak memory?

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019MGNSA2&l=en-US