timed loops - when did my subvi run?

[KlausS]

Hello,

in a full application with several parallel running top level VI's I'm experimtenting with timed loops and sequences. I am aware that 'timed' does not mean detereministic in this context. Millisecond resolution is sufficient here. Here is the problem of my measurement loop I'm trying to deal with (a screencopy of the measurement loop is attached):

I need to measure a certain quantity (PHA spectrum) with a constant rate. The aquisition VI itself executes fast (<1ms, makes a dll call). Then there is some processing of the data afterwards. Basically, difference spectra between the current and the previous aquired spectra are calculated. The full sequence is easily completed within one period (the proc. load is less than a few % while everything is running).  The measurement works fine if I dont move other VI's or open/close VI's . However if I try to use the app as usual (open analysis windows etc), I get errors in my data  because the aquisition VI is not called with the exact timing. If I could find out, when the aquisition VI was called I could compensate for this timing error by a suitable weighthing function as long as the whole loop is not delayed. The latter does not seem to happen. So my question is, what is the best way to get some information when the aquisition VI was executed and how to achieve the best results overall.  In the screenplot the aquistion VI is the one with the enum label 'get fast2 data'. I am grateful for any tips and hints!

klaus

Message Edited by KlausS on 05-18-2007 06:03 AM

[altenbach]

Since the acquisition is the first thing called in the loop and only takes 1ms, maybe you could just tap into the actual vs. expected start time of the timed loop as you already do?

What happens in the acquisition function? Is it just a dll that runs in the UI thread?

[KlausS]

I think I have solved the problem -  at least things have improved dramatically

The solution was to devide the task in 2 frames and then use the 'actual end' terminal to correct for the actual time. See attached the modified VI. There is still some additional noise caused by the remaining timing errors, but there are low enough for my application.

klaus