Problem with real time in sbRIO-9606

[diego_perez]

I found some problems concerning the real time module of the sbRIO-9606 board.

In the following example there's a timed loop which I cannot execute with a period shorter than 1ms.

What's more, if we compare the timing results obtained in the controls "Real Time Loop Time [ticks][us][ms]" we found that the clock which is generating the tick count is running at:

f_clock = 1/period_clock = 972468 / 967us = 1005 MHz which can't be possible since FPGA runs at 40 MHz and Processor runs at 400 MHz

I'd find useful any advice or documents that will help me to understand timing control in the sbRIO-9606 platform. If further details are needed to tackel the problem I'll quickly provide them.

Thank you for the attention. 

[Bhat_Maanay_Rice]

You can't run the loop faster than 1ms because the timed loop is configured that way. You can double click on the top left corner of the loop and reconfigure it to whatever speed you want it to run in. But keep in mind that the loop time must be sufficient for atleast once complete run of the codes within the VI.

Another thing is that your calculation of the tick count frequency is wrong. Each counter is actually giving you the same time but in different units.

[Spex]

The tick unit used by the RT OS clock is nanoseconds:

http://zone.ni.com/reference/en-XX/help/373123B-01/lvtextmath/msfunc_rt_tickcount/

[diego_perez]

thank you for the fast answers,

I tried configuring a faster clock (e.g. 1MHz) to no avail. I guess the reason is the code inside the loop (the read/write operation to the FPGA) cannot be executed in less than 1us (loop period) as Athapa explained.

However, if we do some back of the envelope calculations, we estimate that the data rate that would need to be transmited after the first iteration in this example is aproximatly

R = (number of bits read* / loop period) x (1+overhead**)

*if no controls are modified, write operation only takes place once.

**estimating a 20% of overhead in the data transfer.

R = (15 * 16 / 1us) * 1.2 = 240 Mb/s = 30MB/s

Does somebody know the actual transfer bandwidth between fpga and RT-processor using the read/write VI? would this figure improve using FIFO-DMA VI?

Any details on the performance limits (or at least some approximate figures) of the sbRIO-9606 will be welcome.

Thank you for helping

[LabviewingToday]

It may just be a loop rate limitation on the RT processor. I have had issues working with loop rate <1ms in the past as well. You may try creating a simple loop on the RT without FPGA read/write and see what is the fastest you can run that.

[biscay]

Hi everyone,

I have recently had a similar experience when I was trying to solve the challenge: "how fast (i.e. frequently) can you instruct a timed loop to run?" (with no negative impact on determinism; otherwise I know you are advised to use ordinary while loops with timing blocks inside)

Thus, I have created a 1MHz-fed timed loop, with loop rate = 80us, and a trivial content (see image). When run on my RMC-equipped sbRIO-9606, NI Distributed System Manager reports >90% CPU usage, of which 73% is due to "Miscellaneous: Timed Loops".

My conclusion is that Timed Loops introduce a lot of computing overhead, which is largely undocumented; as a result, it is does not make sense to use them with loop rates below 1ms, as "Labviewing Today" rightly points out.

Regards!

[BMac]

Timed Loops in LabVIEW Real-Time do have a lot of overhead unfortunately. However, there are convenient ways to specify the priority of the code inside within the real-time operating system. Here are two alternatives that work well:

1. Create a subVI and place a normal while loop inside of it. Then go to the properties of the subVI (File>VI Properties>Execution) and set the execution priority as needed by selecting from the available choices. Keep the top level LabVIEW Real-Time application set to normal priority so your low priority loops execute as background tasks.

2. Place a normal while loop inside the timed loop and insert your code in the while loop. The timed loop only executes once, therefore it does not add overhead to each iteration of the internal while loop. The advantage of this approach is that the timed loop allows you to specify an unlimited number of priority values. A higher number indicates a higher priority. To set the loop rate, use the microsecond precision loop timer on the palette here: Real-Time>RT Timing>Wait Until Next Multiple. You must include sufficient sleep time in your time critical while loop for lower priority tasks to function (like networking to your development computer). As a rule, avoid front panel controls and indicators in your time critical loops. Instead, use RT FIFOs to communicate with lower priority loops.

For development best-practices like these, you might find the CompactRIO Developer Guide (https://www.ni.com/compactriodevguide/) to be really useful. I recommend downloading the complete guide PDF and browsing through it.

By the way, the standard interface to FPGA controls and registers can involve a lot of CPU overhead as well. Each item in your Read/Write Control represents a separate serialized communication with the FPGA front panel registers. On the other hand, the new Host Memory Buffer uses local processor RAM that can be read or written with virtually no CPU overhead. It works a lot like reflected memory, but with very low latency. On a Zynq-7020 target, the FPGA and RT processor can share 32 U64 channels, which can be updated in less than 3 microseconds.However, the Host Memory Buffer is currently only supported when programming the Linux RT application using Eclipse C/C++ tools, and currently there are no LabVIEW Real-Time wrappers around the C code calls. However, it would be a relatively small project to create a LabVIEW Real-Time API for it. Using the Host Memory Buffer combined with the techniques above would enable much faster loop rates in LabVIEW Real-Time.

[biscay]

BMac,

Thank you for your answer. You know, I come from the control engineering community, and for us it is very important to be able to sample as fast as possible, subject to some determinism (and jitter, to less extent) constraints.

Regards,

Biscay.