Real Time loop rate slows down if don't use Wait For Next Sample Clock

[Andrew Madry]

I'm trying to optimise the loop rate on my real time system PXI-8145

Using hardware timed single point mode.  In the loop there is a single channel Analog Input Read (single point), a single channel Digital Output, a write value to RT FIFO and a Wait For Next Sample Clock (WFNSC).  By playing with the wait modes for the read and the WFNSC I can get loop speeds up to 8kHz.  This is with both wait modes set to poll (although this starves any normal priority threads ie host user interface).  By changing the WFNSC wait mode to Wait for Interrupt the loop speed drops to around 5kHz but the normal priority threads get a go. 

According to the Dev Zone article " DAQmx Hardware-Timed Single Point Lateness Checking"  Application Case 3 there is a faster method than using WFNSC in the loop where you use the Report Missed Samples Real Time property and don't use WFNSC in the loop.  This should be faster as one less vi gets called.  This relies on you knowing all your operations in the loop fit in the sample clock time but it should be the fastest method (which is what I want).  However when I try taking out the WFNSC vi the whole thing seems to slow down and I get a loop rate of around 200Hz.  The Report Missed Samples property causes the missed samples error to be flagged up at higher rates than 200Hz.   It's as if not using Wait For Next Sample Clock in a real time loop when one is using sample clock timing causes the whole thing to fall over OR setting the Report missed samples property somehow bogs things down.

Any comments on what might be happening appreciated.

[Prashanth]

Hi Andrew,

What version of DAQmx and LabVIEW RT are you using? Are you able to run a simple example program that does hardware timed single point AI  and software timed single point AO as shown in case 3 of this tutorial http://zone.ni.com/devzone/conceptd.nsf/webmain/5b71e273769cbdd286256fd200677b70#6.  I suggest that you just add 1 to AI and then output the same value in AO when you do your testing.

Have a great day!

Regards,
Prashanth

[Andrew Madry]

Using DAQmx 7.5, LV RT 7.1 and LV 7.1

The link is the Dev Zone article I referred to and yes case 3 is exactly the example I am referring to. 

Note I've changed to using an Analog Output to generate a 0-5V TTL type pulse. Analog Outputs seem to offer a lot more control re timing.  See my other posting:

http://forums.ni.com/ni/board/message?board.id=170&message.id=163905

Regarding the strange behaviour I observed with Wait For Next Sample Clock taken out of the loop, lo and behold next day I boot up the system, the mode I referred to where WFNSC is not used and the read property set to report missing samples seems to work at normal rates.  The Real Time system must have got bogged down by something. 

I've gained a reasonable understanding of what is going on and for anyone's benefit I am attaching an analysis of the different loop speeds that may be attained using various combinations of functions and wait modes.