CPU Utilization

[WILLY888]

I have a question about high CPU Utilization on a 1756 L7xx processor V19, the processor sits anywhere from 75% to 90% at any given time.

I believe we have tried everything as far as cleaning up the programming and communications to try and bring the % down to a better number.

I am looking for some suggestions that I may have not thought about.

A second processor is not out the question but would very tricky to integrate into system at this time.

 

[Peter Nachtwey]

The question is too broad and general but I would approach the problem like this:

Use the real time clock to measure the time it takes to execute sections of code. If necessary break the section of code that takes the longest into 2 sections and repeat to pin down exactly what code is taking the longest time. Keep track of the maximum time as well as a filtered average. This will tell you where to look first. Once you determine that you need to tell us what the code does and what algorithms you are using in the code.

 

[PLC GURU]

if you have a continuous task running your cpu utilization should always be close to 100%. If you have planned tasks its a different story

 

[rdrast]

What PLC Guru says is correct. A continuous task will use just about every last bit of the CPU timeslice.

How are you checking the utilization? If you don't have it, get the Logix Task Monitor tool from Rockwell (free).

 

[WILLY888]

The PLC in question is on periodic task, there are three types of routines being run 300ms non critical tasks i.e(indication only information) 100ms critical tasks i.e(motor protection) 50ms speed sensors( cant be set any higher or it does pick up the pulses)

There are 11 racks communicating via ethernet (ENBT V6.xxxx),14 devicenet scanner cards communicating to LV MCC's,1 EN2T communicating to 14 rockwell VFD's, 2 ENBT cards communicating to the DCS (FDSI modules very inefficient driver but highest version currently available)/ MV motors ethernet IP/wonderware historian (very efficient driver)/inter communications with 6 vendor PLC's (produce and consume tags/programming access.

Are testing has attributed a large amount of CPU use to communications.

The EPC delivered this system originally with a 1756 L6x processor which was found to at a 100% half way through commissioning and startup, it was then bumped up to the L7X processor in hopes it would elevate the CPU usage issue, which it did for a short time.

There are 2 to 3 users at any given time online ( this shows to add a small load 2% unless uploading)

We are using task monitor to track the cpu usage.

Known issues, the EPC contractor has used tag names longer then 14 characters in most cases, this not recommended by Rockwell but we do not no the effect on messaging as far as CPU usage.

EPC has suggested moving to EN2T cards for DCS communication, again we do not know the effect it would have if any on the CPU. current ENBT cards are sitting at 50% and 75% load.

Task monitor is showing comms at 58% mem at 15% cpu is 75% to 90%

 

[arlenjacobs]

To start out this is a math exercise, but you need some more data.
You'll want to know exactly where your CPU time (ms) is going.

For each periodic task you will need to know (during normal runtime operations, not during downtime):

• the periodic rate
• priority level
• average & max scans times

If you find scan times over your set periodic rate, that indicates periodic task rate issues.

Any motion tasks? Check the update rate and scan times as well.

If you had a continuous task, you would need avg/max scan times.


After all of that code is run, then you have time left over for class3 messaging (historian, HMI/DCS, development). The system overhead time slice tells you what % of that remaining time will go to class3 messaging vs. your continuous task.

What is your system overhead time slice set to, for background communications? If you have no continuous task, then that setting is a non-factor.


Now you are ready to calculate what your cpu loading is for your L7.
At that point you should have a good understanding where the controller is spending its time and where to start troubleshooting.
Page 13
http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm005_-en-p.pdf


Caution: unfortunately using Logix monitor or designer will take communication time in the control system. that could slow down any class3 messaging to HMI/DCS, historian, etc.