parallel execution of a c program and of a VI

[Kryer]

HI,

We are using Labview 7.1 and we run a c program to acquire data from a DSP system. Additionally, we need to synchronously (synchronizing clock frequency : 8 kHz) measure data from a PC-MIO-16E-4 card. We would like to handle this part of data acquisition using a VI. However, even if both programs (the VI and the c program) are nicely working when separately invoked, they don't behave correctly (with the good timing) once put side by size on the same VI :

in the same conditions, they separately execute in 8 sec. Once put together,  they finish there job only after 14 sec...

Thanks so much for any kind of answer !

Best regards

[shoneill]

Are both programs accessing the same hardware?

Are they both running in the UI thread?

Do all loops in the VI have a wait function included?

How high is the CPU load when running them seperately and together?

Shane.

[LucEstebanez]

Hi,

I'm the same guy who initiated this thread...

Actually, the DSP and the PC-MIO-16E-4 are two different boards, but they are running inthe same computer.

I just don't know whether they run in the same thread (I just don't know how to test this).

There are no loops in the VI that embeds both subVIs, and there is no loop in the "PC-MIO-16E-4 VI" (we acquire a precise amount of data with the traditonnal niDAQ system :  AI- config, clock-config, AI-start, AI-read, AI-clear).

The cpu load (PIV 3.6 GHz whith Hyperthreading, 3.5 Go RAM ) is 51% when running both, and 0-3% when only running the C program.    

[LucEstebanez]

oops, I send the message without an end

Hi,

I'm the same guy who initiated this thread...

Actually, the DSP and the PC-MIO-16E-4 are two different boards, but they are running in the same computer.

I just don't know whether they run in the same thread (I just don't know how to test this).

There are no loops in the VI that embeds both subVIs, and there is no loop in the "PC-MIO-16E-4 VI" (we acquire a precise amount of data with the traditonnal niDAQ system :  AI- config, clock-config, AI-start, AI-read, AI-clear).

The cpu load (PIV 3.6 GHz whith Hyperthreading, 3.5 Go RAM) is 51% when running both, and 0-3% when only running the C program.

The PC-MIO-16E-4 VI induces a 50-53% CPU load.

Best,

Luc Estebanez

[shoneill]

OK, I've just realized that you say you put them side-by-side in the same VI to get them to run together...

Can you post a picture of the block diagram of this program (no BMP please, PNG is better).  Maybe we can see something which might be of help.

Shane.

[LucEstebanez]

thanks for your reply,

here are two pictures : one of the VI that mesures stuff on the PCMIO16E4 and one of the VI that contains this VI and the "2" VI, that just contains the C program, on the form of a CNI.

http://www.eleves.ens.fr/home/estebane/vi_ECG.png

http://www.eleves.ens.fr/home/estebane/vi_global.PNG

Actually, after some tests, we found that vi-ECG eats almost all the CPU time, and that the C program is actually ruun, and eats a very low amount of CPU...

I'm gonna check this EGC VI and tell you what's up !

Best,

luc

[shoneill]

Firstly, I don't see a reaql reason for the flat sequence structure in one of your pictures.  I don't think  this actually does anything.

Secondly, can it be that the AI read is blocking the PC?  Is DMA activated for the card?

I don't have experience with using external triggers, but I've always worked with "Continuous scan" which does the acquisition in the background, freeing the PC up to do other work.  The only tricky part is allocating a buffer large enough so that it doesn't overrun during the acquisition.  I don't know if it's easy to couple this to a triggered acquisition, but it might be worth a look.  Try out the continuous acquisition VIs, they're under "advanced" I think.

Hope this helps

Shane.

[LucEstebanez]

Actually, it seems that after some serious investigation, the problem was lying in front of our eyes... There was a bad limit for the number of acquisition the Vi had to do...

Well, thank you so much for the advice, it helped a lot in the resolution of the problem (when you know none of the big troubles you was expecting happen, you start looking for smaller one...)

luc