Execution times in ControlLogix

So a few years ago I jumped on the structured text bandwagon in ControlLogix as I wanted to structure some of our code in an easier-to-read fashion for some of the newer guys. It made sense when we would run loops on large sensor arrays and do different types of evaluations based upon the index to use the case statement; it sure makes it a lot easier to read than a bunch of ladder.

For a number of reasons, I've had to become concerned with making the code execute as fast as possible. I turned to the execution time document, 1756-RM087, ran some numbers and discovered that on paper the ladder would be most efficient for my needs.

I just finished testing some code on an L73 and it sure does run quicker on ladder. I have an array of 5000 sensor UDTs that I'm performing some simple alarming on (High High, High, Low, Low Low) and it takes into account a few BOOL statuses such as "out of service" or "I/O failure".

In ladder it executes at ~80 milliseconds while in structured text it is ~113 milliseconds. That probably wouldn't sound like a large difference to many of you but the way we use ControlLogix is a bit unorthodox here (i.e. no periodic tasks, tons of unconnected message transfers, etc.)

I just wanted to share my experience here in case some others run into execution time issues or just want to optimize as much as possible. The Rockwell document is a very good guide to use for this purpose.

You should consider removing your loops all together. Convert that the loop logic into an AOI. Then create 500 rungs each with an AOI instance to match your UDT array element as a substitute for your looping logic.

Use "brute force" and see if you improve your performace some more over your loop structure.

Also, the way you prioritize tasks and time them you can achive higer performace for the logic that requires it, and slower performace for the logic that does not.

PCMusicGuy said:

......

I just finished testing some code on an L73 and it sure does run quicker on ladder. I have an array of 5000 sensor UDTs that I'm performing some simple alarming on (High High, High, Low, Low Low) and it takes into account a few BOOL statuses such as "out of service" or "I/O failure".

........

Click to expand...

If you are using ControlLogix Analog Inputs, you can reduce your controller overhead using the process alarms on the analog module itself. You can do Scaling on the modules as well if you are not already doing so.

Paully's5.0 said:

You should consider removing your loops all together. Convert that the loop logic into an AOI. Then create 500 rungs each with an AOI instance to match your UDT array element as a substitute for your looping logic.

Use "brute force" and see if you improve your performace some more over your loop structure.

Also, the way you prioritize tasks and time them you can achive higer performace for the logic that requires it, and slower performace for the logic that does not.

Click to expand...

Thanks for the suggestion. Experimenting with AOI's was next on my list. I tried what you suggested and brute forced 5000 rungs of calling an AOI and the execution time dropped to 30 milliseconds. I also tried modifying my original ladder routine with the loop and just called the AOI inside of the loop instead. That dropped the time to 29 milliseconds. This is using an AOI and passing the sensor UDT element in using an InOut parameter. I could try making an AOI using inputs and outpus only but it is not feasible for me to program that way. As it is, I discovered you can only copy/paste about 800 or so simple rungs into RSLogix5000 v20 before it fails.

daba said:

If you are using ControlLogix Analog Inputs, you can reduce your controller overhead using the process alarms on the analog module itself. You can do Scaling on the modules as well if you are not already doing so.

Click to expand...

We have virtually zero analog inputs or any other hardwired inputs, but thanks for the suggestion.

PCMusicGuy said:

Thanks for the suggestion. Experimenting with AOI's was next on my list. I tried what you suggested and brute forced 5000 rungs of calling an AOI and the execution time dropped to 30 milliseconds. I also tried modifying my original ladder routine with the loop and just called the AOI inside of the loop instead. That dropped the time to 29 milliseconds. This is using an AOI and passing the sensor UDT element in using an InOut parameter. I could try making an AOI using inputs and outpus only but it is not feasible for me to program that way. As it is, I discovered you can only copy/paste about 800 or so simple rungs into RSLogix5000 v20 before it fails.



We have virtually zero analog inputs or any other hardwired inputs, but thanks for the suggestion.

Click to expand...

Create the logic as a .R5X file and import all the rungs you need.

PCMusicGuy said:

We have virtually zero analog inputs or any other hardwired inputs, but thanks for the suggestion.

Click to expand...

I'm confused, you mentioned "sensor", and you are performing analog process alarming.... What "sensor" data are you processing ?

Paully's5.0 said:

Create the logic as a .R5X file and import all the rungs you need.

Click to expand...

Yes. Much easier after copy/paste didn't work so well.

daba said:

I'm confused, you mentioned "sensor", and you are performing analog process alarming.... What "sensor" data are you processing ?

Click to expand...

I work in the offshore subsea controls field. We interface with control modules that read all of the actual hardware sensors and interface boards. The "sensors" we work with are from the large data buffers we read from these control modules. Depending on the protocol/hardware we are interfacing with, it will either be already scaled or not.

PCMusicGuy said:

I work in the offshore subsea controls field. We interface with control modules that read all of the actual hardware sensors and interface boards. The "sensors" we work with are from the large data buffers we read from these control modules. Depending on the protocol/hardware we are interfacing with, it will either be already scaled or not.

Click to expand...

Got it, thanks for the explanation.

PCMusicGuy said:

For a number of reasons, I've had to become concerned with making the code execute as fast as possible. I turned to the execution time document, 1756-RM087, ran some numbers and discovered that on paper the ladder would be most efficient for my needs.

I just finished testing some code on an L73 and it sure does run quicker on ladder. I have an array of 5000 sensor UDTs that I'm performing some simple alarming on (High High, High, Low, Low Low) and it takes into account a few BOOL statuses such as "out of service" or "I/O failure".

In ladder it executes at ~80 milliseconds while in structured text it is ~113 milliseconds. That probably wouldn't sound like a large difference to many of you but the way we use ControlLogix is a bit unorthodox here (i.e. no periodic tasks, tons of unconnected message transfers, etc.)

I just wanted to share my experience here in case some others run into execution time issues or just want to optimize as much as possible. The Rockwell document is a very good guide to use for this purpose.

Click to expand...

PCMusicGuy said:

We interface with control modules that read all of the actual hardware sensors and interface boards. The "sensors" we work with are from the large data buffers we read from these control modules.

Click to expand...

Your sensor data is being MSG'd into the Logix5000, are you synchronising the processing of this data with the MSG .DN bits, or trying to execute it every scan?

You presumably have multiple messages, how frequently are they reading the data?

There is no point processing the data asynchronously to the data arriving into the controller.

I also assume your messages are not cached (unconnected), because you have so many of them and you've reached the limit to the number of connections. You can put multiple comms modules and "spread the load". How many messages are there, typically?

Originally posted by PCMusicGuy:

This is using an AOI and passing the sensor UDT element in using an InOut parameter.

Click to expand...

This will result in your fastest execution when using an AOI. InOut values are passed by reference, basically a pointer interface. So no data is actually moved. In and Out parameters are actually copied over. So passing parameters that way adds overhead.

Keith