Jump to content
  • entries
    7
  • comments
    18
  • views
    23,363

Feelin' a little Loopy!


Phil Salkie

2,130 views

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).

loop1.png

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.

loop2.png

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.

loop3.png

Finally, we increment the loop counter and go back to the top of the

loop if the counter is less than 8.

loop4.png

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

6 Comments


Recommended Comments

  • MVP 2014

Hi Phil,

Thanks for the post. This is of interest to me as I have come from a background of PC-based programming and it's always a brain-stretch to cross between that and PLC ladder logic.

Whilst I generally agree with the usefulness of loops, my understanding of jumps in the Unitronics world is that they only jump forwards, not backwards. So the "jump back" actually causes the PLC to end the scan at the jump instruction and start the next scan at the jump label. So in the example of a loop, n interations would take n scans, and the other code in the program would not be executed during this time. If the code in the loop is short and the PLC is fast (like the V570) then this wil still execute reasonably well.

This isn't confirmed knowledge, and the help file is not definitive on this point. A simple program could be used to test it, or if a Unitroics engineer is reading, it could be confirmed by revelation. Or maybe I am wrong all together...

Link to comment
  • External Moderators

Simon,

I think Phil is the only one who can delete the duplicate comment :D

As far as the Loop side of things goes. In my experience of using them, I found they would simple "Add the Scan" if you were "Jumping Back" to a Label.

If you make a Loop take too long to complete, you can trigger a "Software Watchdog" error, which means the PLC Scan never actually finished within a reasonable time.

I just made a quick test program and added an INC Utility in Net 1, made a Label with another INC Utility in Net 2, then in Net 3 a "Jump to Label" so it would jump "Back to Net 2". I also added a INC Utility in Net 4.

When I started the PLC Program, the INC in Net 1 counted up just once, then the MI on the INC Utility in Net 2 was counting up very fast - then I hit a Watchdog Timeout because my loop "Never Ended".

So based on this one thing to remember would be Inputs and Outputs won't be updated whilst in a "Loop" of Label Jumping.

Very handy, but dangerous feature at the same time! :D

Link to comment
  • MVP 2014

Thanks Ash (and Phil), that's good to know, I will make more use of it. In this case I am glad my initial assumptions were wrong!

Nothing like an endless loop to really foul things up...

Link to comment
Hi Phil,Thanks for the post. This is of interest to me as I have come from a background of PC-based programming and it's always a brain-stretch to cross between that and PLC ladder logic.Whilst I generally agree with the usefulness of loops, my understanding of jumps in the Unitronics world is that they only jump forwards, not backwards. So the "jump back" actually causes the PLC to end the scan at the jump instruction and start the next scan at the jump label. So in the example of a loop, n interations would take n scans, and the other code in the program would not be executed during this time. If the code in the loop is short and the PLC is fast (like the V570) then this wil still execute reasonably well.This isn't confirmed knowledge, and the help file is not definitive on this point. A simple program could be used to test it, or if a Unitroics engineer is reading, it could be confirmed by revelation. Or maybe I am wrong all together...
Hi Simon, I have used this structure myself several times when it was necessary to complete a series of iterations within one scan. I can say with a large degree of certainty that it in fact does prolong the scan it is on and not simply start back at the jump label. In the old Forum you will see a topic call "Implementation of FOR loop" (or something like that) where I reference having actually made a test program that allowed me to determine the effect on scan time as iterations increased (or complexity of the loop). Although Unitronics does not explicitly state that "jumping back" is allowed it does not seem to prevent you from it. I suspect they may not advertise it because it opens the door to a lot of tech support headaches as it could easily be misused if the person implementing it does not take care writing the code or does not understand how the PLC processes the overhead and scan.
Link to comment

Phil,

Great article. I think this feature is often overlooked because it is assumed that it isn't allowed.

Some also look at it unfavorably because if you are not careful with your coding you could create a lot of havoc. From my perspective, that is true no matter what your doing.

Hopefully some day Unitronics will address it in the documentation so that users can gain a better level of comfort with it.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.