General Precautions: The biggest danger in using iterative loops is creating a scenario where the indexing variable never achieves the end value. If a loop never terminates, the watchdog timer of the PLC will timeout and stop the PLC from processing logic. The other two iterative loops can use an EXIT instruction inside the loop to handle special cases where it becomes necessary to prematurely terminate loop execution. This feature is not supported in the FOR…NEXT instruction. Special care must be taken, so that the programmer does not create a never-ending loop. This can occur if logic inside the loop modifies the index variable. This can also occur if the end value is likewise modified. Any manipulation of the index variable, the start value (which can also be a variable), or the end value (which can also be a variable), inside the loop would be considered a poor programming practice.
The second danger in using the iterative loops, is overloading the loop. This can take several forms. In one form, the program performs elaborate manipulations on multi-element arrays of structured data-types. While this is the real power the instruction offers, it can be easily overused. Multi-dimensional arrays (more than four dimensions), large data-structures (more than four layers of abstraction), and indices greater than 100 elements, require special attention as these typically indicate a potential overload. The processing power of the PLC will determine the risk of exposure to this type of issue.
The least obvious type of danger in using iterative loops, is the potential to saturate the processing power of the PLC or its communication networks by initiating (or re-initiating) an advanced function call inside the loop. Any type of communication function block or mechanism that initiates such a function, will queue as many communication requests as there are iterations of the loop. As this happens in one PLC program scan, it is easily possible to saturate and lock up the communication port on the PLC. Using advanced functions, or communication functions, inside of an iterative loop is considered a poor programming practice. It is one of those programming traps that leads to intermittent operation of the system. As a side note, this danger is not always obvious. If a FOR…NEXT loop is used in an HMI or SCADA system, and the loop is reading a different variable from the PLC for each change in the index variable, the HMI or SCADA will actually be queueing successive communication requests. In most cases, these requests will likely be for only one element. This will, again, saturate the communications and lock up the system. The programmer should only use variables with a local scope, inside of an iterative loop. A local variable is a variable that can be accessed without going outside the confines of the memory structure where the code resides.
For any questions on these best practices, contact RF Jordan at [email protected] or 414-231-2539.