Jitter with timed sequences on cRIO 9004 controller

[jumpinkiwi]

I would like to do the following:

(1) A/D sampling at a certain rate in the FPGA (works fine)
(2) Periodically triggering the controller to do some computations (works fine with interrupts)
(3) Trigger the FPGA for analog output with a certain defined delay without jittering

Without timed sequences step (3) does have a very low jitter (but not a defined delay - ok I could just use a wait function) (see attachment).

By using a timed sequence for step (3) the jitter explodes to > 2 milliseconds! Are timed sequences really real-time capable? Or did I something wrong with it. I tried to use 1MHz clock with and without restart for the frame timing. This does not really change anything.

System Setup

• Compact RIO backplane 9104
• Compact RIO controller 9004 (setup into microseconds timing as described by (http://digital.ni.com/public.nsf/allkb/5B1A53C9A9B46D48862570A00067C913)
• NI 9263 D/A Converter
• NI 9215 A/D Converter

Parameters

• Rectangle signal with 100 Hz at the input.
• Sampling rate of the FPGA of 500 Hz

Attachment

File	Description
block_CONTROLLER_noTimedSeq.png	Loop on the controller without timed sequence
noTimedSeq.jpg	Low-jitter measurement of the analog input and output using a Tektronix TDS 210 with 5 sec afterglow
block_CONTROLLER_timedSeq.png	Loop on the controller with timed sequence
withTimedSeq.png	High-jitter measurement

Furthermore are there the two VIs for the controller and the FPGA attached.

[aasenjo]

jumpinkiwi,

I believe the jitter you are seeing is actually caused by the fact that the Timed-Sequence is taking more than 2 ms to configure/run/clean-up, therefore your I/O loop is late (you should be getting some timeouts in your code) and subsequent iterations are triggered immediately, causing the large variation at the output. The actual SW jitter of the Timed-Sequence on that controller is actually not that much, below 150 us, but that's besides the point, since it is taking so long that you can't even have it in your I/O loop.

It's important not to confuse jitter with determinism. Determinism means that the feature executes within a bounded amount of time. In the case of the Timed-Sequence, determinism is guaranteed for anything inside its frames, but set-up and tear-down of the structure is not guaranteed to be, nor is, deterministic. The trace tool shows plenty of memory allocations going on at the set-up and clean-up stages of the structure.

I attach the benchmark code as well as a screenshot of the 9002 benchmark

I also ran the same test on two other targets:

Controller	Average Timed-Sequence (us)		Jitter (us)
cRIO-9002	2100		145
cRIO-9014	1400		64
PXI-8106 / Single-Core Mode	43		4

I think that a Timed-Sequence is overkill and also incorrect for what you are trying to accomplish. It is overkill because it provides quite a lot more functionality than you are currently using  (timestamps, feedback, dead-lines, multiple frames). It is also incorrect because you are using it inside your critical loop, and its setup and tear-down are not deterministic, therefore execution time is unbound. The better solution would be, as you suggest, using a simple microsecond wait and standard sequence structure.

On a related note, I noticed that IRQ_Update (Controller).vi was set to run at normal priority. Assuming that it doesn't have any callers with higher priority, you might want to increase the priority of this VI so that other system threads don't interfere with this task.

I hope this helps,

Alejandro



Message Edited by aasenjo on 11-06-2007 06:15 PM

[jumpinkiwi]

Alejandro, thank you very much! An awesome report. That helped alot, indeed! There are multiple time critical loops running in parallel in my project - so it is probably best to set the execution priorities on the more important sub VIs higher. However, it would be nice to have an "offline" pre-allocation of all the resources of a timed sequence/loop and trigger the structure in real-time. I would like to use such goodies as the deadline and timeout functionality of those structures ... Probably there could be other features for real-time applications in order to influence the scheduler ... Kind regards