Geoff: Presumably you are more of a DAQ-centric person than a LabVIEW-centric person at NI.
I think what Scott means by a "LV style wait" is that the thread continues to execute, so other parallel nodes on a diagram will continue to be executed, even though the node in question is synchronous, or doesn't return until its task has completed. The LV's Execution Engine, or whatever the task manager is called, uses a task scheduler to run nodes so that they seem like they are running in parallel even though it's all running in one thread. I think that's overly simplified because other threads are used for housekeeping, but that is all transparent to LV users. I remember all this from various NI week presentations. Other synchronous nodes may block the entire thread, preventing any other LV tasks in that thread from executing. Remember that we LV programmers can choose "execution systems" but we don't have direct control over threads. We are also limited in that parallel code on the same diagram is always going to end up in the same execution system, which probably puts it in the same thread. The term we LV programmers use for these kinds of nodes is "pure evil". There are plenty of nodes in LV which appear synchronous to LV programmers (nearly all the wait functions, queue functions, etc), but don't block the LV execution system from executing parallel tasks in the same VI. That's what we want from our DAQ and GPIB calls too, but we're at the mercy of the NI engineers who create the LabVIEW node. I'd guess that these kinds of nodes have to be internally asynchronous, so they don't block the thread, but must contain code to wait until the spawned thread finishes its task so that they appear synchronous to us. If the DAQmx nodes in LV don't have this capability, then I'm not sure DAQmx the Great Leap Forward which I've been led to believe. We can get the behavior we want by polling the status of AI Read, so why change to DAQmx if we still have to implement this workaround to get decent multitasking from our computers. Please correct me if I'm wrong about the details of DAQmx or the LabVIEW execution system. Most of the above is just educated guesswork. Jason Dunham SF Industrial Software, Inc. -----Original Message----- From: Geoffrey Schmit [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 5:26 AM To: Info LabVIEW Mailing List Cc: [EMAIL PROTECTED] Subject: Re: DAQmx, etc. On 19/05/2004 at 9:00 AM, Scott Hannahs <[EMAIL PROTECTED]> wrote: > At 7:58 -0500 5/19/04, [EMAIL PROTECTED] wrote: >> If the task acquires a finite number of samples and you set this >> input to -1, the VI waits for the task to acquire all requested >> samples, then reads those samples. > > Is this a blocking wait like the non-DAQmx call into a CIN (or LLB) or > is it a "LV style" wait where other LV nodes even in the same thread > can execute? That would be nice! Is there a way to do this threading > in our own created dlls (frameworks)?. I would like to make my PCI- > GPIB library non-blocking but that is not trivial because of this > limitation. Is there a way to set up a call back into LV for a non- > blocking wait from a CIN or framework? I'm not sure exactly what you are asking; so, I'll define some terms, explain a couple of things, and hope I get lucky :) For example, I'm not sure what you mean by a "LV style" wait. I'm not aware of a construct that would allow a thread to wait on a synchronization primitive and yet continue to execute. That is, a thread is either running or waiting. If my definition of an asynchronous call matches your definition of a "LV style" wait, great. If not, please let me know what you have in mind.
