When Programmable Logic Controllers were first introduced, their programs were geared toward the replacement of simple relay circuits. Logic statement 0 was processed first, then logic statement 1, and so on until an END instruction was reached. Then the PLC's supervisory software, or "Operating System", would do some housekeeping - update timers and counters, send outputs to the physical devices, read inputs from the physical devices, and run the user's stored program again. Logic statement five was never skipped, statement ten was never executed twice in a row.
The addition of branch control instructions changed all that. Now all but the least expensive "Smart Relay" controllers have the ability for the program to decide that rather than go forward to the next instruction, the system should instead branch backward - to make a loop. Obviously, if that loop were to go on forever, the controller would never get to execute its housekeeping after the program's "END" instruction - so we have to be careful to limit how many loops we make. This power to make a loop, combined with the ability for the controller to do something slightly different each time through the loop, gives us the power to replace hundreds, even thousands of PLC instructions with a very small amount of PLC code - and to improve the program's reliability while we're at it.
Let's take as an example the password scanning logic I wrote about last week. In that example program, I had eight nearly-identical rungs of logic - one to check the password for level one, one to check the password for level two, and so on. I could have, instead, written a small loop of program which counted from one to eight, checking the password that corresponded to that loop counter, and after the eighth time through, stopped looping and continued on to the rest of the program.
The benefits to writing loops include using less program memory space, taking less of your time to enter than copying, pasting, and changing all those rungs, and decreasing the number of typos - if you process fifteen things in a loop, either they all work or they all don't. If you write them out longhand, then you may make a typo on number 12 and not notice it for years.
The downside to writing loops is that the code is never obvious - PLCs tend not to have very clear methods of handling the kind of indirect addressing that loops use, and no two controller brands have the same indexing method. Also, it takes some setup and thought to get a loop working right - it is often easier to just cut and paste repeated rungs if there are only going to be two or three of them. (In this case, eight was right about at my limit - had it been twelve, I would have made it a loop right away.)
So now that we know some of the rewards and pitfalls, let's recode those password checking rungs into a loop structure:
First, we'll need to initialize a count variable for the loop. We'll start with MI 280 at zero, counting up and stopping when we reach eight. We then place a LABEL instruction, which is where the loop will jump back up to (PassLoop).
Next, we take the value of MI 280 and use it as an _index_ into the list of passwords, pulling out the password for the current level and storing it in MI 281.
We'll then have a single rung which checks passwords, just like the eight rungs we had before - the difference is that our new single rung will be processed eight times in a single scan.
Finally, we increment the loop counter and go back to the top of the
loop if the counter is less than 8.
And that's it! We've cut the number of rungs in half, and once it's running, we're sure that if one password level works, they all do. So, next time you find yourself starting to copy and paste rungs, decide if you're feeling loopy instead!
This is a downloadable link to a V570 application file containing the framework code with looped password checking - it has been released into the public domain, feel free to use it as a starting-point for making your own V570 projects.
To learn more about Howman Controls, visit our web page at www.howman.com