RT timing problem after using counter pulse train

[MarcDub]

We have a fairly complex application running on a PXI-RT8108 (Phar Lap Labview 2011) at 400 Hz without problem. We are now trying to upgrade the whole system to run at 600 Hz. The main loop is using a "Wait until multiple" to get the 600 Hz. The application consists in several triggers using several counters from two NI-6602 that are all timed from a single digital output that is software generated from the main loop. Timing is excellent until another counter is used to simulate the main loop. We use "DAQmx connect terminal" to replace the software trigger by a counter generating a continous pulse train at various rates up to 600 Hz. This is done so that we can simulateo the normal operations to do maintenance on the individual components of the system.

When we run the application at 600 Hz after rebooting the RT system, the timing is excellent. After we run the simulation with the counter pulse train at low rep rate (like 20 Hz), the main application will still run fine at 600 Hz. However, after we run the simulaton mode with the counter pulse train at 600 Hz, the main application will run erratically around 600 Hz. The average repetition rate is around 560 Hz but instanteneous rate varies between 500 and 600 Hz. How is it possible that the use of a counter generating a pulse train can affect the timing of a RT application after the counter is not used anymore? Does the counter use a thread on one of the C
PU?

I have a corollary question: is there a tutorial or an actual manual that explains how to interpret the data from the RT trace toolkit? I recorded the Trace data in the various cases in the hope to understand what's going on but there is no way to interpret the data without more explanation than the poor manual (dating from 2007) provided with the toolkit.

[Bob_Schor]

Several comments.  I recommend using the Timed Loop structure instead of "Wait on multiple" -- it runs directly on the PXI's internal clock, doesn't need the Counter/Timer module (which I frankly find a little confuusing and intimidating), and can easly scale up and down in frequency.  On the RT Target, you can specify a 1MHz clock to get a better approximation to 600 Hz (1667 microseconds) than the 1KHz clock of the Timed Waits.

We recently had a timing issue on our LabVIEW RT system, and attempted to track down the problem with the RTETT.  We were similarly underwhelmed with the lack of documentation and "intuitiveness".  We eventually resorted to periodic writing to an Error Log (known to FORTRAN programmers as "Inserting a Print Statement").  Another problem was that, most of the time, we only were able to gather a second's worth of data (or less), despite creating what we thought were large data buffers (it seemed to max out at 2000000).

Bob Schor

[MarcDub]

Hi Bob,

Actually, on the RT system, the "wait until next multiple" and the "wait" RT functions have µs accuracy. When we started the development, we tested using a timed loop versus timing with a "wait until next multiple". The timed loop had a timing accuracy better than 1/1,000,000 while the "wait until next multiple" had a timing accuracy of only 1/10,000. However, in our application, we are happy with anything better than 1/100 timing accuracy. There are a few drawbacks in using a timed loop. The most important one is a 10% cost in CPU speed. We could not reach our goal to run a demonstration at 1kHz with the timed loop while we could with the "wait until next multiple".

The RTETT seems like a good idea but I suspect that not that many people use it, probably because it is so hard to understand... and it is hard to understand because not so many people use it.