DAQmx Apparent Memory Leak

[JÞB]

---

@mcduff wrote:

Can't post the VI here. Attached are picts that show where it freezes.

An abort then stop, freezes in the Stop VI, unreserve, then abort, then stop, no freeze. Undocumented state transitions??

---

You realize a stop is implied by abort right?  Without a task name and with autocleanup default your code just absolutely makes no sense!  Yup- that is shooting yourself in the foot!  Ready...Fire, Aim!.  Nope, FIRE, Aim for the Dr. office wincing the whole way hopping on the good foot and yelling "Ouch, Ouch Ouch!"

Yes, I'm only laughing at you because you should know to ask first and shoot second.

[JÞB]

---

@BertMcMahan wrote:

@Jeff why would the Boolean read timeout affect how long the VI takes? The Read VI doesn't wait until the end of its Timeout period to do its read, it returns immediately if it's able to, which in this case it will be able to do right away.

Also @Jeff, sorry to potentially sidetrack the thread, but in an earlier post you mentioned only creating tasks at development time. While I've seen this is something that "can" be done, none of the examples ever mention it, and I've never seen a reason to do it in practice- I always create tasks with the Create Task VI.

What does creating the task do for you at dev time? Got any good examples of that?

---

The examples don't mention it because they are POC, Proof of concept,  At no time should you see an example that creates a task more than once. unless the vi goes idle.  Even the Project templates for xxxMeasurement and logging. create any task once.  Doing at at development time just gives you better control of the task properties by placing them in a human readable file that can be read and edited by any text editor like notepad, or, in an NCE file that just befuddles me why they did that.

[JÞB]

---

@crossrulz wrote:

---

@JÞB wrote:

We see, after creating the constant that the default bool read timeout is 2000 (that is Two Thousand) times greater than the event loop will queue up timeout events. No other events are registered and you cannot limit the timeout case to 1 event queued so you are in deadlock  

---

I don't think so, Jeff.  The timeout for the Event Structure does not even start timing until the Event Structure is reached again on the next iteration.  Here is the proof:

---

So THAT is why those options are greyed out on a timeout case!  {Lock front panel, limit to one)

Still, Can you show how that behavior is documented?  Or will that behavior be subject to change?  We can discuss that side note elsewhere;}

[mcduff]

@Jeff

The original code/thread was not posted by me. In a related thread, I had a similar problem and tried using primitives, and reusing tasks where possible, and seemed to work. Here is the link  you replied to that thread also.

What you said earlier about the DAQmx transition diagram made sense, so I went back and changed my code according to your advice, and ended up with a frozen LabVIEW. I am not saying what I did previously was right as I agree with what you are saying, but for whatever reason it works, and the what is shown in the diagram I sent does not work.

When a task is aborted, it is returned to the Verified state. If the task is running, it is stopped as soon as possible and is then unreserved. After a task has been aborted, you can continue to use the task. However, you might need to transition the task back to its previous state before continuing the specified operation. (This is what the Stop is for. )

Unfortunately, I cannot use the same task over and over. This is not a production environment but a R&D environment, so tasks/devices change all the time.

mcduff

[JÞB]

---

@BertMcMahan wrote:

@Jeff why would the Boolean read timeout affect how long the VI takes? The Read VI doesn't wait until the end of its Timeout period to do its read, it returns immediately if it's able to, which in this case it will be able to do right away.

Also @Jeff, sorry to potentially sidetrack the thread, but in an earlier post you mentioned only creating tasks at development time. While I've seen this is something that "can" be done, none of the examples ever mention it, and I've never seen a reason to do it in practice- I always create tasks with the Create Task VI.

What does creating the task do for you at dev time? Got any good examples of that?

---

Well, apparently crossrulz just schooled me on that

. but the "Unnamed Task" means there is no name to look up against to see if some mememory is allocated to remember that task.  and that memory gets abandoned until the vi goes idle because something might wish to re-use that Task.  Name the task and prove me wrong again!

[Kevin_Price]

Oops, I finished editing my post after it was already quoted so I'm now going back and editing again to highlight the edit part.

@mcduff:  I went back to that original thread and admittedly only skimmed it.  Did you ever go back and try to test methods with *NO* calls to abort the task?   I've never run into a need for the abort task option, continue to be doubtful that it's a necessary or important step, and pretty strongly suspect it to be at least potentially harmful.   Does it not work to stop the task without an abort, like this?   (And unless you explicitly reserved or committed the task before starting, you might not get any benefit out of the call to "unreserve."   At least according to the DAQmx state model as I understand it.)

@Jeff þ Bohrer:  I too am curious why you advocate for creating tasks at development time.  I've been used to creating them programmatically at run time for so long that I don't even give it a second thought.  What do you see as the pros and cons?

   Part of my bias may be that I tend to work on test systems where MAX's user-friendly ability to redefine global channels, tasks, or scales is considered a risk & detriment for test configuration control.   So maybe I'm not *all* ears, but I'm at least curious to the point of half ears.

-Kevin P

 [EDIT:  I'm legitimately curious whether there really are situations where there's something to be gained by doing an "abort" that can't be done with a normal "DAQmx Stop" (plus perhaps an "unreserve" or other explicit state transtion via "DAQmx Control Task").  I start from a standpoint of skepticism, but am willing to learn & be convinced.]

[crossrulz]

---

@JÞB wrote:

Still, Can you show how that behavior is documented?  Or will that behavior be subject to change?  We can discuss that side note elsewhere;}

---

From the help: "The Timeout terminal specifies the number of milliseconds to wait for an event before timing out."  That seems mostly cut-and-dry to me, especially when you think of it like a queue.

[JÞB]

---

@Kevin_Price wrote:

@mcduff:  I went back to that original thread and admittedly only skimmed it.  Did you ever go back and try to test methods with *NO* calls to abort the task?   I've never run into a need for the abort task option, continue to be doubtful that it's a necessary or important step, and pretty strongly suspect it to be at least potentially harmful.   Does it not work to stop the task without an abort, like this?   (And unless you explicitly reserved or committed the task before starting, you might not get any benefit out of the call to "unreserve."   At least according to the DAQmx state model as I understand it.)

@Jeff þ Bohrer:  I too am curious why you advocate for creating tasks at development time.  I've been used to creating them programmatically at run time for so long that I don't even give it a second thought.  What do you see as the pros and cons?

   Part of my bias may be that I tend to work on test systems where MAX's user-friendly ability to redefine global channels, tasks, or scales is considered a risk & detriment for test configuration control.   So maybe I'm not *all* ears, but I'm at least curious to the point of half ears.

-Kevin P

---

This seems to be a common call out for a Community Nugget: How does Jeff Use DAQmx.   

I'll put it in a queue! and release this topic back to others.  Bug me PM with specifics about that statement I'll ask for feedback on the nugget

[crossrulz]

---

@Kevin_Price wrote:  I've been used to creating them programmatically at run time for so long that I don't even give it a second thought.

---

Same here.  I just keep a library floating around to build up the task from a configuration file.  I have also had to do too many dynamic setups, hence the configuration file.

[mcduff]

@Kevin_P

Your suggestion works! My real problem came on a 32 bit machine that I do not have here to test. Just stopping the task would eventually lead to a resource problem, where if I am remembering correctly, abort did not have that problem, or that problem arose more slowly.

mcduff