Very slow parallel execution

[Stefo]

Hello every smart heads.

I’m using LabView 7.1, traditional NI-DAQ, Windows XP

I have two different VIs. Both of them work in a while loop. The first one is acquiring data from analogue input, and another one measures period of an input TTL signal. When I run analogue acquisition alone, is running very fast. Processor is loaded up to 80%.

But, when I run period measurement in parallel to this analogue measurement, execution of analogue acquisition is very slow, but processor is loaded maybe up to 10% . I would expect, that after run another program, I will load processor more !?

I tried to change delay times in those loops, but it stayed without result. I’ve tried to change priority, and execution in VI properties, but still without success.

Can somebody help me optimize the parallel execution ?

[DFGray]

There are a lot of ways you could be having problems.  Please post your code or a piece of it and we can try to help you.  My current guess would be that one or the other of the acquisitions is locking the PCI bus waiting for a data ready.  This blocks program execution, but does not use much CPU time (assuming a wait on interrupt or slow poll).  However, without code, I don't know.

[Stefo]

Ok, I've found the reason.

I think (I'm almost sure) that when I read count from buffer, and time limit of Counter Read Buffer.vi is not exceeded yet, acquisition from analogue inputs is not executed, but another VI waits till Counter Read Buffer.vi will finish.

I though that execution should be parallel. Why is it like this ? I can solve problem if I put time limit very small. However, I need timeout indication (code 10800).

Any Ideas ?

[TJW]

Stefo,

The programs should run in parallel so it sounds like there is a
hardware issue. Are your analog input and counter on the same card? My
guess is that your two programs are using a common resource on the
board. I don't know of way to check this with traditional NiDaq but
some of the hardware jocks at NI could probably answer whether the
analog input and digital I/O should collide on whatever board you are
using.

By the way, the "insert into array" function you are using is a very
slow way to append data to an array. If you just want to append the
data (which is what you are doing since you don't wire the index), you
should use the "build array" function. It is approximately 10 times
faster.

TJW

On Wed, 2 Aug 2006 04:10:08 -0500 (CDT), Stefo <x@no.email> wrote:

>Ok, I've found the reason.
>I think (I'm almost sure) that when I read count from buffer, and&nbsp;time limit of Counter Read Buffer.vi is not exceeded yet, acquisition from analogue inputs is not executed, but another VI waits till Counter Read Buffer.vi will finish.
>I though that execution should be parallel. Why is it like this ? I can solve problem if I put time limit very small. However, I need timeout indication (code 10800).
>Any Ideas ?
>&nbsp;
>
>
>Measure Buffered Period (DAQ-STC).llb:
>http://forums.ni.com/attachments/ni/170/198645/1/Measure Buffered Period (DAQ-STC).llb
>
>
>measurePmode.llb:
>http://forums.ni.com/attachments/ni/170/198645/2/measurePmode.llb

[DFGray]

I believe traditional DAQ is single-threaded at the driver level (it has been awhile since I used it), so if you have an acquisition which is inside the kernel level taking data, no other acquisitions can run.  You can get around this by reimplementing in DAQmx (highly recommended) or by polling for status and doing the interleave yourself, taking data only when it is actually available.

[Stefo]

Well. So rebuild my programs to DAQmx can be solution? We thought that we can add one card more. Could it solve my problem? I know that solution like this is not the best (at least for financial aspects), but if I would rebuild hole program to daqmx, could take much more time 😞

thanks

[DFGray]

What card are you currently using?

[Stefo]

Very good question. I want to apologize that I've forgotten attach this information.

PCI-MIO-16E-1 (6071E i think is equivalent name)

[DFGray]

I thought you had an E series card, but just wanted to make sure.  I confirmed with the designers that there is no hardware reason for your problem.  DAQmx or polling would probably cure it.  At this point, however, I have to plead incompetence, because I haven't worked with DAQ in years.  I will try to find someone with recent experience to answer your question.