Logix5000 Programming Thought Question of the day, loops, jumps and AOIs ooOOoo!

[Paullys50]

Appreciate all the responses, it's got my mind thinking a little more outside the box, plus it gives me some more mechanisms to try and test. I think I've gotten the jump start needed to better tackle this and hopefully I'll come to a quick conclusion on where which direction I should concentrate on.

 

[dmargineau]

I appreciate the suggestions but if you already have the best engine there is what is next? This is all being processed on 1756-L7x processors. Can't do much better. I do appreciate the reference to firmware, and I do understand that different firmware could provide varying results in processing; however, how your logic is programmed, how tasks are prioritized and how a task is timed all play a part in the performance. No different than an engine. The wrong kind of gas, a poor engine tune, the wrong transmission gear ratios...will all make the best car in the world a poor performer.

I see now where you are currently "standing" and do not envy you one bit...
The point I was trying to make is that, if a CPU is already over-utilized, additional code intended to satisfy a noble cause will increase the already existing burden, not alleviate it...at least this is my $ 0.02 worth opinion...

 

[Paullys50]

I see now where you are currently "standing" and do not envy you one bit...

Meh, given the project commissioning I've been through this past year...where I am standing now is like looking at the horizon as the sun is rising on a perfect day. It's a new challenge and isn't causing any problem at this point. It's a nice brain exercise.

The point I was trying to make is that, if a CPU is already over-utilized, additional code intended to satisfy a noble cause will increase the already existing burden, not alleviate it...at least this is my $ 0.02 worth opinion...

Is this really the case? Go through Ron's examples and discussions about "brute force". Sometimes more logic of simpler execution is far more efficient and less logic of greater complexity.

 

[dmargineau]

Ron's "brute force" method is , in my opinion at least, the preferred way any application should be approached.
Going back to your OP, trying to improve a CPU's performance via " elegant", complex application components (such as the proposed AOIs)is an added burden.
What might improve the performance is the above mentioned "brute force" coding or the addition of another system processor, processor which would handle only specific tasks such as communications.

 

[Paullys50]

Ron's "brute force" method is , in my opinion at least, the preferred way any application should be approached.
Going back to your OP, trying to improve a CPU's performance via " elegant", complex application components (such as the proposed AOIs)is an added burden.
What might improve the performance is the above mentioned "brute force" coding or the addition of another system processor, processor which would handle only specific tasks such as communications.

Maybe I was not entirely clear with my objective. The objective is to restructure the code, using whichever means possible to achieve my goal of reduced CPU utilization. I threw AOIs out there as a possible method to evaluate, doesn't mean AOIs are a requirement, just was a brain-storming idea. If structured text, function block..etc would provide benefits I would explore that as well. Same if I can simplify and use a brute force I will explore that as well. It's the thought process of restructuring, which path should I explore and how shall I go about it that I'm looking for a jump start on.

I am not opposed to the realization of having to use multiple processors, just want to have assurance that I am, in fact, at a wall of sorts.

 

[daba]

Don't forget that optimisation could be achieved by simply re-structuring the code that you are calling nnnn times.

Executing less instructions per iteration could allow you the expense of iterative processing.

Take a careful look at each device handler and see if you can shave 10% off its instruction count. Or check to see if there's any "expensive" instructions used in the handler code, and modify accordingly.

Optimisation at the root level will be the most beneficial.

Another way you can improve scan time is not to "look at" your plant devices every scan. Obviously it depends on the application, but determining that a valve has opened/closed need not be solved every scan. You could look at half the devices on scan 1, and the other half on scan 2, etc. Your process sequences will be waiting for feedbacks from your plant items, and in most cases it will not matter if those feedback signals are delayed until (worst case) the next scan.

Just some thoughts that might allow you to use iterative processing, which has an overhead as already described.

 

[dcooper33]

If you are processing DeviceNet IO of different types in different periodic tasks, and you have the rates dialed-in for priority and performance, then you've gone a long ways towards optimization already.

Since the amount of tags of a given type is variable, this is where you can implement an "intelligent" form of brute-force processing. This way you can still have a variable parameter that defines how much data is processed, and get the speed benefits of the brute-force method. Just jump to the end of the routine when you've scanned all the tags you need.

You can further speed things up by not using JSRs within the periodic input-processing tasks. JSRs, especially when they involve input and return parameters, are relatively slow. The manual that Ron links to in the MRPLC is an indispensable tool for AB code optimization. I may be wrong here, I haven't done any tests to prove it, but I don't think that ST or FB is going to run your code any faster. Looking at execution times, in most cases a given instruction is faster in good ol' ladder logic.