Simplify these rungs
- Thread starter carlisn
- Start date
Steve Bailey
Lifetime Supporting Member + Moderator
In my opinion combining those three rungs into one complicates rather than simplifies.
Steve Bailey
Lifetime Supporting Member + Moderator
What sort of timing problems are you anticipating?
Saffa
Member
As others have mentioned, making it more efficient in terms of reduced instruction count will have the downside of making it more difficult to read. You could move bits that are common to all rungs to the left and branch after that. But it will make your manual control branches more messy to implement.
From the logic you've posted i can't see how you'd have timing problems? Does your PLC update I/O asynchronously? If not then it looks unlikely that you'd have problems.
From the logic you've posted i can't see how you'd have timing problems? Does your PLC update I/O asynchronously? If not then it looks unlikely that you'd have problems.
OkiePC
Lifetime Supporting Member
If you really need to trim scan time, one of the best things you can do is move "mostly false" bit instructions to the left. There are other things that can help, but don't be one of "those people" who starts using skips (jumps) and labels, MCR zones and conditional subroutines. You will be surprised how much processor time is wasted keeping up with the overhead you will create not to mention the headaches of troubleshooting it later.
I've only had one or two projects where scan time was so critical I had to be very cautious, but moving false logic to the left, doing all the math intensive scaling in the HMI and a couple of other small changes dropped average scan time from 26ms to about 10 in a PLC-5 with about 1000 rungs of code.
I've only had one or two projects where scan time was so critical I had to be very cautious, but moving false logic to the left, doing all the math intensive scaling in the HMI and a couple of other small changes dropped average scan time from 26ms to about 10 in a PLC-5 with about 1000 rungs of code.
carlisn,
You are making a fundamental mistake in how you are viewing programming inefficiencies.
It is not so much the number of rungs you execute, but more the execution of the instructions within those rungs that adds unnecessarily to the overall scan time.
Each rung added has an execution time of its own, Start Of Rung/End Of Rung (SOR/EOR), etc., and the total number of rungs in a program will add to the overall scan time. But this is usually negligible when compared to the time spent unnecessarily executing the same sequence of instructions more than once.
To use my Matrix view on it again...
Try not to view the logic before you as a physical construct. Where the perceived volume of logic, rung wise, automatically induces a sense of increased scan time. More, try to view the logic at the processor's execution level, where each instruction being executed is what is really increasing the scan time.
Your posted logic is a very good, and common example of where a programmer either does not realize, or realizes, but does not care, scan time wise, that they are re-executing the same sequence of instructions on multiple and consecutive rungs.
The first four instructions on each rung are an identical sequence of logic. This program is inefficiently executing this sequence three times. So that is twelve instructions being executed to give the same result when it can be done using less.
In fact, in this case, it will prove to you how actually adding another rung will improve the scan time, rather than add to it.
Insert a new rung above these three rungs and add the four offending instructions in sequence as they appear on the other rungs. Then add a new address bit to an OTE instruction at the end of this rung. What you will call this address is up to you, but it is a form of precondition to enable the logic on the original three rungs.
On the three rungs beneath, remove the first four instructions and insert an XIC instruction instead. Assign it the same address as the new OTE instruction.
Now when the program scan reaches the new rung, it executes the four conditional instructions and then executes the OTE instruction. This is now five instructions that have been executed.
On the first of the three original rungs it will then execute the new XIC instruction and if it evaluates true, the rest of the rung will carry on as before. Likewise, the other two rungs will do the same. This means you are now "inefficiently" executing one instruction three times, rather than the original four instructions.
So that is now eight instructions being executed instead of twelve, give or take the new rungs SOR/EOR execution time, which again is negligible when compared to the original setup.
The reason I said that the new XIC instruction is still being "inefficiently" executed three times is that it is possible to further consolidate the execution of the three rungs using parallel branching on a single rung. This is where a trade off between efficient execution and clearer programming is often decided. However, because the most inefficient aspect of the logic is now streamlined, you can start to consider further reducing the number of instructions executed by placing the new XIC instruction once on a single rung before branching out to the individual logic of the three original rungs. This removes the triple execution of the new XIC instruction, reducing the overall instruction execution from twelve to six.
It will now appear somewhat clearer than if the original logic was consolidated using branching on one rung. Whether one goes that far, or not, is up to them and whether the scan time saving is more important than the loss of clarity. It should not be too difficult to decipher this piece of logic though and good rung commenting always helps.
Lessons...
Increasing rung count can, at times, help to decrease the scan time. The consolidation method is used to reduce the number of instructions being executed and not the number of rungs being used. i.e. consolidation may involve increasing or decreasing the rung count.
Now that you know more, what else can be consolidated by going to one rung?
Regards,
George
You are making a fundamental mistake in how you are viewing programming inefficiencies.
It is not so much the number of rungs you execute, but more the execution of the instructions within those rungs that adds unnecessarily to the overall scan time.
Each rung added has an execution time of its own, Start Of Rung/End Of Rung (SOR/EOR), etc., and the total number of rungs in a program will add to the overall scan time. But this is usually negligible when compared to the time spent unnecessarily executing the same sequence of instructions more than once.
To use my Matrix view on it again...
Try not to view the logic before you as a physical construct. Where the perceived volume of logic, rung wise, automatically induces a sense of increased scan time. More, try to view the logic at the processor's execution level, where each instruction being executed is what is really increasing the scan time.
Your posted logic is a very good, and common example of where a programmer either does not realize, or realizes, but does not care, scan time wise, that they are re-executing the same sequence of instructions on multiple and consecutive rungs.
The first four instructions on each rung are an identical sequence of logic. This program is inefficiently executing this sequence three times. So that is twelve instructions being executed to give the same result when it can be done using less.
In fact, in this case, it will prove to you how actually adding another rung will improve the scan time, rather than add to it.
Insert a new rung above these three rungs and add the four offending instructions in sequence as they appear on the other rungs. Then add a new address bit to an OTE instruction at the end of this rung. What you will call this address is up to you, but it is a form of precondition to enable the logic on the original three rungs.
On the three rungs beneath, remove the first four instructions and insert an XIC instruction instead. Assign it the same address as the new OTE instruction.
Now when the program scan reaches the new rung, it executes the four conditional instructions and then executes the OTE instruction. This is now five instructions that have been executed.
On the first of the three original rungs it will then execute the new XIC instruction and if it evaluates true, the rest of the rung will carry on as before. Likewise, the other two rungs will do the same. This means you are now "inefficiently" executing one instruction three times, rather than the original four instructions.
So that is now eight instructions being executed instead of twelve, give or take the new rungs SOR/EOR execution time, which again is negligible when compared to the original setup.
The reason I said that the new XIC instruction is still being "inefficiently" executed three times is that it is possible to further consolidate the execution of the three rungs using parallel branching on a single rung. This is where a trade off between efficient execution and clearer programming is often decided. However, because the most inefficient aspect of the logic is now streamlined, you can start to consider further reducing the number of instructions executed by placing the new XIC instruction once on a single rung before branching out to the individual logic of the three original rungs. This removes the triple execution of the new XIC instruction, reducing the overall instruction execution from twelve to six.
It will now appear somewhat clearer than if the original logic was consolidated using branching on one rung. Whether one goes that far, or not, is up to them and whether the scan time saving is more important than the loss of clarity. It should not be too difficult to decipher this piece of logic though and good rung commenting always helps.
Lessons...
Increasing rung count can, at times, help to decrease the scan time. The consolidation method is used to reduce the number of instructions being executed and not the number of rungs being used. i.e. consolidation may involve increasing or decreasing the rung count.
Now that you know more, what else can be consolidated by going to one rung?
Regards,
George
Last edited:
Bit_Bucket_07
Member
I have, in the past, improved the accuracy of critical timers in a large program by placing the timers in a separate subroutine that gets called multiple times within a single sweep. While calling the subroutine multiple times did slightly increase overall scan time, it greatly increased timer accuracy.
James Mcquade
Member
carlisn,
I think it's great that you are looking at ways of simplifying code, BUT I want to emphasize the following.
I don't know what area of the company you are in but please understand that I am expressing my opinions and past history.
1. If you simplify code by reducing rungs of logic, will maintenance be able to understand the changes and debug the program?? Just because you can simplify by making fewer rungs, doesn't mean you should.
2. Do you fully understand what the machine does and the possible consequences?
3. Don't jump in and edit the code without getting others involved first. there may be reasons the code (any code) is written the way it is. Learn as you get others involved and gain their trust.
regards,
james
I think it's great that you are looking at ways of simplifying code, BUT I want to emphasize the following.
I don't know what area of the company you are in but please understand that I am expressing my opinions and past history.
1. If you simplify code by reducing rungs of logic, will maintenance be able to understand the changes and debug the program?? Just because you can simplify by making fewer rungs, doesn't mean you should.
2. Do you fully understand what the machine does and the possible consequences?
3. Don't jump in and edit the code without getting others involved first. there may be reasons the code (any code) is written the way it is. Learn as you get others involved and gain their trust.
regards,
james
Similar Topics
I'm using productivity 1000 plc for this. The process is simple i have a wheel with yarn wrapped around it made out of aluminum with evenly spaced...
Hello everyone
I'm trying to simplify this ladder in order to make it more accesible to modifications, just trying to use indirect addressing...
Very often I have to reverse engineer something from an iFix parameter inside an array to a bit in iFix. It's a pain to do as I've yet to really...
I'm working with Studio 5000 & FactoryTalk View Studio ME. I have a UDT that contains data for a part as it passes through a system, Timestamps...
Hi all,
I have the following problem: from a long list of boolean values (about 100) I should program each possible combination with the...