LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT FIFO results in 100% cpu load?

Solved!
Go to solution

Hi,

 

I'm trying to replace some queues with RT FIFOs on a cRIO9074 target (using LV2011), which should be rather easy as the API is very similar for both:

check.png

This example VI works for sure: the lower loop puts an I32 into the FIFO each 100ms, the upper loop should wait for "timeout" (set to 50ms) before attempting to read a new element from the FIFO. For this example the upper loop should run (about) 2-3 times for each iteration of the lower loop due to 50ms timeout.

 

The problem I have is: it reports 100% cpu load and I don't get why it says so:

check.png

Where does this example VI burn 100% cpu load? Does the RTFIFORead just poll the current FIFO state?

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
Message 1 of 5
(2,437 Views)
Solution
Accepted by topic author GerdW

Have you checked if a timeout of >100ms also creates 100% CPU load?

 

Please note that the Create FIFO provides configuration of reading and writing for polling vs. blocking. Refer to the help for detailed information.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 2 of 5
(2,425 Views)

Hi Norbert,

 

thanks for your comment on the blocking/polling behaviour. That's what I missed when replacing queue by RT-FIFO…

Default behaviour is to poll for both read and write access.

 

Results:

- setting timeout to >100ms still results for 100% cpu load for default polling modes

- setting blocking mode for atleast read access gives <15% cpu load for this example VI…

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
0 Kudos
Message 3 of 5
(2,416 Views)

Hi GerdW, Hi Norbert,

 

thanks a lot for sharing this problem and its solution. I searched two days for the reason of the high cpu load. And it really was "just" changing the r/w modes to blocking. I wonder, if it wouldn't be better to change the default value to blocking.

 

 

Kind regards,

 

skusie

0 Kudos
Message 4 of 5
(2,228 Views)

skusie,

 

the default setting is polling (with maximum speed, hence the 100% CPU load) is the fasted method to react on a new elelemt. For most RT applications, this is by far more important than 100% CPU load.

I am not sure, so please take care with the following:

The polling should have the priority of the caller, so if the FIFO Read is contained in a low(er) prioritized VI, it should create 100% CPU load, but other threads may preempt the polling.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 5 of 5
(2,214 Views)