RT target is running at 99.8% CPU

[suni]

Hi,

I am using CRIO 9014 with 9103 chassi. My RT controller is running at 99.8% of CPU when i run my application. Is it Ok to run my CRIO under that much load? I am using Labview 8.6. Thanks.

[mikeporter]

Define "Ok". If you mean will it permanently damage something or will it rip a hole in the space time continuum, neither of those things will happen so, yes its "Ok". If on the other hand you're concerned about whether all the deterministic operations are going to take place on time, it may not be so "Ok".

Personally, I would be looking at why the CPU loading is so high.

Mike...

[Ben]

Thngs may have changed but ....

Prior to LV8 the CPU on the RT target was a good reperesentation of the apps CPU usage.

WIth the intro of the Shared Variables and the code to support that connectivity (it uses all spare CPU cycles), the CPU started running at near 100% for all apps.

So the bottom line now is "Is the app staying deterministic?" if yes, then OK.

Like I said this may have changed since I last looked. I did do a lot of complaining so maybe it has gotten better.

Just my 2 cents,

Ben

[Jeremy_B]

Hi Ben,

What version of LabVIEW did you see that behavior in?  I just ran a test on 8.6 and it definitely does not use 100% of the CPU with shared variables.  I only tested with a handful, I imagine if you have hundreds of them that would cause a problem.

suni,

What does your application do?  Running at 99.8% is often (but not always) an indicator of a problem, or potential problem.  Do you have any problems, or does your application work just fine?

[Ben]

---

Jeremy_B wrote:

Hi Ben,

What version of LabVIEW did you see that behavior in?  I just ran a test on 8.6 and it definitely does not use 100% of the CPU with shared variables.  I only tested with a handful, I imagine if you have hundreds of them that would cause a problem.

...

---

I think it was 8.0 or 8.2 and the target was a cFP something or other.

Ben

[LV_Pro]

As asked before, what are you trying to do. One thing to look for, in any version of LabVIEW, are any loops (FOR or While) that don't have some time delay element to signal the O/S to release their thread for something else to execute. This isn't a problem if you are using LabVIEW "timed loops", but a plain vanilla loop without either a "Wait (ms) or a Wait until Next ms Multiple" doesn't tell either LabVIEW when it is compiling, or the O/S to pause the thread (for that period of time) to allow other stuff to execute. Ironically, wiring a 0 ms to the Wait function will do the trick, although the loop will still be screaming, but in theory not using 100% of the CPU.

[suni]

Hi,

I am not experiencing any problems so far. I am using a timed loop. There are lots of processing going on in the loop. But I think loop is executing every function even with almost 99% CPU. May be you can show me any discrepancies in my code. Thanks.

[Hillman]

Hi All,

I hope your all well today and thanks for posting questions and working hard to keep the forum a great place to discussion problems.

The Compact Field Point (cFP) CPU uage is always at 100% due to the fact that by default the cFP controller continually polls the I/O modules when there is idle time. In MAX in you alter the Pause Time as well as in the LabVIEW project (the later updates the MAX setup). 

I was under the impression that in LV 8 and above, all availabe CPU cycles are used to maintain the various protocols.

Hope this helps,

[Ben]

---

Hillman wrote:

Hi All,

...

The Compact Field Point (cFP) CPU uage is always at 100% due to the fact that by default the cFP controller continually polls the I/O modules when there is idle time. ...

---

Confirming my statement above.

Ben

[Hillman]

Hi Ben,

I was indeed confirming - as you seemed a little unsure when I read the post yesterday. 

I was wondering if the question concerning the cRIO had be resolved?