Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Running Two Time Loops in cRIO Real Time Application

Solved!
Go to solution

Hi there,

 

Our application has one major timed loop, running at about 4ms on a cRIO-0939

Unfortunately we have run out of loop time even with our four cores of the 9039.

I am trying to optimize, setting VI in loops to subroutine and/or In-line.

Because we do not have completely even CPU usage across the cores, I tried to break some duplicated heavy code into separate threads - but this runs more slowly.

 

Another option I might try is to move a read data from USB into another timed loop.

The CPU usage would be somewhat light weight, so it should not cause anymore jitter in the main Timed-Loop, however I read in a cRIO white-paper that best practices are NOT to have more than ONE timed loop to avoid jitter problems.  However I do recall seeing one NI example project that does discuss phasing between time loops, so I guess in some cases it is OK.  

 

any thoughts welcome.

Michael

0 Kudos
Message 1 of 12
(5,552 Views)

1. A timed loop forces everything in it into a single thread.

2. Instrument communications are not exactly deterministic.  So I would definitely move those to other loops.  Normal while loops with a simple wait will be just fine for those.  You can use RT FIFIOs or global variables to pass the data to your main loop.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 12
(5,528 Views)

1. This is implies that a timed loop does not take advantage of multiple cores.

I did try to check the performance assign just one core to the timed loop but it did not run as fast compare to assigned automatically.

 

2. Agreed instrument communication is not deterministic, but the cycle time from the instrument point of view is not fast, but new data is ready at definite intervals.

I will try as you suggest, with simple while loop and wait timer. We typically use functional globals as out means to transfer data inter-loop or inter subsystems.

 

I have plans to try the JKI State Machine Objects as the base framework

0 Kudos
Message 3 of 12
(5,523 Views)

1.  Multiple threads in Time Loop.

Perhaps I was confused where I rad here:

http://zone.ni.com/reference/en-XX/help/370622M-01/lvrtbestpractices/rt_priorities/

 

that one can have 1 Thread  per CPU.  

However perhaps this means physical CPUs and not individual CPU cores

 

Michael

0 Kudos
Message 4 of 12
(5,512 Views)
Solution
Accepted by topic author Michael.Proctor

@Michael.Proctor wrote:

that one can have 1 Thread  per CPU.  

However perhaps this means physical CPUs and not individual CPU cores


A single thread can run in a single core.  But the Timed Structure forces everything inside of it into a single thread.  So if everything is in 1 timed loop, you can only be using 1 core at a time.  If you don't set the affinity, then the core being used theoretically could be changing cores throughout the execution time of the application.

 

Just found the exact line I was looking for in that article you linked to:

When you place parallel code inside a single Timed Structure, LabVIEW serializes the code because each timed structure comprises one and only one thread.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 12
(5,509 Views)

 

Thanks.

 That line about auto serialization is very enlightening.

 

Of course the puzzle remains why when I do run my two main computational blocks in serial rather than in parallel, the total loop time is longer, and if I set the timed loop to run a given core, rather than choose any of the four cores I have it also takes the timed loop longer to run.

 

Anyway it seems to optimize using the power of the cRIO-9039 I should split more of the workload over separate loops... at the down size of slightly more complex data synchronization.

 

 

 

0 Kudos
Message 6 of 12
(5,503 Views)

Just a quick clarification, the purpose of timed loops is not to optimize CPU power, it's to improve determinacy. Sometimes those two forces work against each other and you might be discovering one such example.

0 Kudos
Message 7 of 12
(5,488 Views)

Ideally you have one timed loop fer core on your controller.  If you are having performance issues, you may want to bench mark your code in order to see if you have too much going on in one loop.  I wanted to cite the cRIO Dev guide as well to let you know there is a section on deterministic v non-deterministic functions!

 

-Bear

Regards,

Ben Johnson
ʕง•ᴥ•ʔง
Message 8 of 12
(5,483 Views)

@nanocyte wrote:

Just a quick clarification, the purpose of timed loops is not to optimize CPU power, it's to improve determinacy. Sometimes those two forces work against each other and you might be discovering one such example.


Thanks for the clarification.

In our case we are fighting the these two forces.  

However given that we have 4 cores, 3 cores somewhat under used and our need for more margin in performance to meet our determinacy requirement.  It just seems to me with 4 cores, one should be able to safely have more than one timed loop, given that they run in only one thread.

 

First I will try for the second loop, a simple while loop with timer as you suggested previously, and given that that CPU needs of this loop a low compared to our loop time it could work. The push to have two timed loops is that the incoming data and the main timed loop need to be synchronized  to avoid lag in our performance.

0 Kudos
Message 9 of 12
(5,469 Views)

Generally you should stay with 1 timed loop per core as TheEngineeringBear stated.  So, with a 4 core computer, you could run 4 timed loops. 

 

We generally like to stay with 1 timed loop per core to ensure each timed loop can run in parallel, which helps ensure determinism.  If we added a 5th timed loop, it would have to share processor time with another timed loop (as it can't get its own processor core).  This will add jitter to the system, as it is indeterminate which other timed loop (or loops) it will share a core with, and therefore how long its execution will take to complete.  For the same reason, the determinism of the other 4 loops will be affected: their core may (or may not) have to share processing time to complete the 5th loop.

Trevor H.
Technical Support Engineer
National Instruments
0 Kudos
Message 10 of 12
(5,430 Views)