crio cpu load

[Hamilton_Woods]

Good morning!

I am using a cRIO 9074 and LabVIEW 2012.  The cRIO is in scan mode at 1kHz.  I have a shared variable engine, an ftp server, and a web server running on the cRIO.  This is not a complete list of "built-in" software running on the cRIO.  I do not have time synchronization turned on.

With no user application running on the cRIO, the Distributed System Manager reports 58% CPU utilization.  When I add my program, CPU usage shoots to 100% and the cRIO "freezes" for several seconds occasionally.  I am confident that this situation is not acceptable.  I suspect that an "idle" CPU usage of 58% is not to be expected.

How do I determine what "built-in" software is loading the CPU so tremendously?

Followed immediately by the question, is there anything that I can do to reduce CPU usage of "built-in" software?

Thanks,

Hamilton Woods

[GerdW]

Hi Hamilton,

the cRIO9074 is rather "small" in terms of CPU power and available memory. So using this small baby to drive several web services additionally to your own (very demanding) usage of the ScanEngine at 1kHz (!) isn't the rigth way to use the cRIO.

You should:

- consider using the FPGA on your own instead of stressing the ScanEngine (if your LabVIEW license permits)

- consider stripping down the installed software on your cRIO. You can do so using MAX.

- consider using one of the bigger cRIOs. Ask your regional NI representant or the technical support for suitable targets...

#7750

[0utlaw]

Hello Hamilton,

Out of curiosity, how many channels are you publishing with the scan engine?  Gerd's suggestion of removing nonessential background processes is spot-on, if you've selected to install *everything*, there are probably quite a few components you could remove without affecting your application- your options here will depend on what you have installed on the dev machine, but start with taking out things like foreign language support and run-time drivers and toolkits you're not using (Vision, WSN, and Control Design & Simulation, etc.).  TimeSync and SysConfig Remote support (which is another web service in itself) are other likely targets and will more likely bring down your background overhead. Refer to this for instructions on how:

KnowledgeBase 56PGFF4A: How Do I Install Different Versions of Software on My Real-Time Target?

http://digital.ni.com/public.nsf/allkb/2BAD2D3A7DE25EB2862576D6007EDB22

Do remember that this is still a single-core 400 MHz target, so if you're finding that you're constantly at 90%+ CPU usage, it may not be powerful enough to keep up with your demands. I'd recommend doing some benchmarking to determine what proportion of your processor time is taken up by the various things you have running- try deploying with the scan engine disabled, then removing your web service and re-enabling the scan engine to get an idea of how resource-intensive each of those is, for example.

Regards,

[Hamilton_Woods]

Sorry it took so long to get back to the discussion.  I just got back in town from working on another project.

NI suggested the 9074 CPU for this project.  We are logging to 97 channels to memory (writing to compact flash

would work except that compact flash has a limit on how many times it can be writtten to) at 10 Hz.  The data

are logged continuously and the old values are overwritten after a little more than 30 minutes (20,000 samples).

I am using a functional global (VI with an uninitialized shift register) to hold an array 97 channels by 20,000 sample

(a little over 30 minutes, at 10 Hz) and an array of timestamps..  In the functional global, there are three actions

(Initialize - create arrays; Store - replace array elements; and Get - access the data and timestamp arrays).  

Initialize happens once.  Store happens every 100 milliseconds.  Get happens so infrequently it could be 

considered that it never happens.

Apparently array allocation is happening in the replace array subset function calls.I changed the execution

property of the functional global VI to inline the VI, which required that the VI be re-entrant.  When I did this, the

CPU load went from 100% to 50%.  I know that I don't want to use a re-entrant VI; I just wanted to observe the

effect.  When I unchecked the box for inlining the VI (leaving the VI re-entrant), the CPU load went back to

100%.

It has been suggested that I consider using an in place element structure with a reference to the data array and

to the timestamp array to eliminate allocating buffers in the Store action case.

Any thoughts?

Hamilton Woods

[Lewis_G · Accepted solution]

One thing to be careful of is front panel execution mode (when you run your RT code with a front panel).  I had really high CPU usage because I had some array indicators on the front panel.  Once I built it to exe it went from 100% to about 30%.  You could try building it to exe and then using distributed systems manager to monitor the CPU usage.  System state publisher must be installed to do that.

[nathand]

---

Hamilton_Woods wrote:

It has been suggested that I consider using an in place element structure with a reference to the data array and

to the timestamp array to eliminate allocating buffers in the Store action case.

Any thoughts?

---

Any chance you can share your code? If so, we can probably offer good, specific suggestions about how to make it more efficient.

Proper use of an in-place element structure can often eliminate excess data copies, but it all depends on exactly what you're doing with those arrays.

[Hamilton_Woods]

Thanks for all the helpful suggestions.

I think I have most of the CPU load issue resolved.  I had a lot of VI front panels open

while executing on the cRIO.  When I closed the front panels, the CPU usage went

down to 43%.

Thanks again for your help,

Hamilton Woods