Rockwell Instruction Efficiency

Hi All,

When programming for better efficiency, I like to use instructions that use less CPU - less time. Where can I find a timing list for ControlLogix instructions?

Thanks in advance.

Find document 1756-RM087.

https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1075737

or https://rockwellautomation.custhelp.com/ci/fattach/get/1401714/0/filename/1756-RM087L-EN-P.xlsm

Thanks AustralIan!

A link ...

https://www.google.com/search?q=175...=chrome..69i57j69i60&sourceid=chrome&ie=UTF-8

I don't know if it is listed in the documentation, but using constants in compares is slower than using a tag that contains the constant.
In the good old days, using the TI-500 series for instance, you had to use variables with fixed values, constants were not allowed. As CPU's got faster, and tags became the norm, everyone just plugged in the constant they wanted to use. In most cases the performance hit is not worth considering.
But in applications were 1 or 2 milliseconds matters a lot, these are some of the things that can be looked at to reduce your scan time.

I don't remember the exact language used to explain it, but it's something like this. Say you have a tag "Seven" which has a value of 7. The PLC scans Seven once and converts it to machine language, and stores it in memory. Anytime within the scan it encounters the tag "Seven" it used the value store in memory. However, if you use the value 7 instead, each time it is encountered in the scan, the PLC must convert it to machine language, then do the compare, the conversion consumes a small amount of time each encounter.

Lovell,

while writing efficient code is great, please remember the end user, MAINTENANCE !

code that only you understand is worthless when maintenance cannot understand the code and the machine is down at 2 am.
you need to understand what the maintenance tech(s) know and can do.
work with them, let them tell you their level of understanding.
Document the program with rung descriptions in detail every 4 or 5 rungs.
that way, they will at least try to find and fix the issue.
in the end, the program may not have the most efficient code and rungs that you feel are not necessary. if maintenance can work on the plc issues and keep the machine running with minimum downtime, job well done!

james

james mcquade said:

lovell,

while writing efficient code is great, please remember the end user, maintenance !

Code that only you understand is worthless when maintenance cannot understand the code and the machine is down at 2 am.
You need to understand what the maintenance tech(s) know and can do.
Work with them, let them tell you their level of understanding.
Document the program with rung descriptions in detail every 4 or 5 rungs.
That way, they will at least try to find and fix the issue.
In the end, the program may not have the most efficient code and rungs that you feel are not necessary. If maintenance can work on the plc issues and keep the machine running with minimum downtime, job well done!

James

Click to expand...

+1

+1 for James McQuade's response to Lovell. I have a lot of rung comments (A-B), detailed descriptors, logical routine titles, etc. I often call my logic "clunky" however, a program I wrote for a slurry dispensing machine last year must be doing well, because I haven't gotten a single call about the logic, or any other issues except they don't like CCW. It freezes up the HMI all the time, or used to. They bought 2 more machines, so I guess they liked something. Their 2nd shift tech, as per James' example, told me he "was fair" at looking at logic to troubleshoot, and I gave him several hours of "driving time" on my laptop on line with the program and showed him key rungs (motion fault timer presets, etc, that would shut down the machine, valve logic so he could troubleshoot any valve problems). Really helped him out. Now that I've said all this, my phone will probably start ringing off the hook because I started bragging Haha. I write logic like this mainly because I've worked with so much in previous jobs that had NO comments, vague or non-existent descriptors, weird tag names, etc. Made me just want to give up and re-write a program.