On 18/05/2004 at 11:24 AM, Info LabVIEW Mailing List <[EMAIL PROTECTED]> wrote:
> In LV6 the 'AI read.vi' hogs the CPU waiting for the number of samples > requested to be available. > someone (sorry for not remembering the name) came up with a > 'non-blocking AI read.vi' which i have been using happily. > i noticed the new DAQmx 'cont&graph.vi' is hogging the CPU also. is > there a cure for it ( i think it makes DLL calls)? While read operations in DAQmx consume 100% of the CPU, like reads in Traditional DAQ, there are a couple of critical differences: * In DAQmx, other threads in LabVIEW are not blocked and may continue to execute. In fact, even other threads performing DAQmx operations that involve other DAQmx tasks are not blocked and may continue to execute. * In DAQmx, read operations yield. That is, if there are other threads running on the system, they are not blocked and may execute. Basically, DAQmx read operations say, "Hey operating system, if you have nothing better to do, let me run so I can be more responsive." As a result, the CPU monitor is not an effective tool to measure the efficiency of the application. Another potential disadvantage is that your [EMAIL PROTECTED] client won't run during read operations :) As a result, replacement read VIs should not be necessary for most applications that use DAQmx. This knowledge base article discusses this topic: <http://digital.ni.com/public.nsf/websearch/ 09D80223FA84113D86256D6A004B97C3?OpenDocument> geoff -- Geoffrey Schmit Senior Software Engineer National Instruments [EMAIL PROTECTED] www.ni.com
