On 25/05/2004 at 8:54 AM, Jason Dunham <[EMAIL PROTECTED]> wrote: > Presumably you are more of a DAQ-centric person than a LabVIEW-centric > person at NI.
I'm more of an operating-system-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. I'm certainly not an expert on LabVIEW's Execution Engine. In fact, much of my understanding is based on various NI Week presentations as well :) Regardless, I'm still very confident that the thread that invokes a DAQmx VI will not execute other VIs on the diagram until the DAQmx VI completes its operation. However, other parallel nodes on a diagram may continue to be executed in other threads that LabVIEW creates transparently. > 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". It is my understanding and experience that parallel code on the same diagram may be executed by multiple threads on modern multi-threaded operating systems (Windows NT, Mac OS X, Linux). You don't need to worry about these threads; the magic of LabVIEW makes it all transparent! The "Measurement Multithreading in NI-DAQ 7" article on NI Developer Zone <http://zone.ni.com/devzone/conceptd.nsf/webmain/ 111A3167AB05E5C286256D2600728203> describes the multi-threading improvements of NI-DAQmx in more detail. In addition, the NI-DAQ 7 vs. Traditional NI-DAQ Performance Improvements VIs featured at NI Week last year are also available <http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid= BDAB2417D6772B77E034080020E74861&p_node=200509&p_source=external>. > 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. The DAQmx VIs should behave in the manner that you desire despite the fact that they are not implemented in the fashion that you envision. Hopefully, this will result in DAQmx continuing to hold the title of "Great Leap Forward" :) geoff -- Geoffrey Schmit Senior Software Engineer National Instruments [EMAIL PROTECTED] www.ni.com
