Controlling Your World One Contact At A Time  

AB to AD - Stage Programming

The DL06 manual has an excellent section (Chapter 7) devoted to the 'how' of stage programming. I'd like to cover the 'why'

Stage Programming is not appropriate to all control applications. It is not for a continuous process type setup. Stage programming is most useful when different discrete steps are performed. Of course an incredibly simple set of steps may be performed by a drum instruction (which the AD PLCs have by the way.) But any more complex series, with error checking and different type of triggers of succeeding steps may benefit greatly from Stage programming.

Paradigm Shift

A paradigm shift is a radical change in a method of thinking about a subject. Such a paradigm shift may be necessary when considering Stage Programming.

Many programmers look at the controlled outputs and think 'what conditions turn on these outputs?' They then proceed to produce incredibly complex rungs with an output as the final point.

A Stage programmer must step back from the process and ask 'what is the machine (or some identifiable subsection of the machine) trying to accomplish right now?' 'What condition(s) will cause it to start doing something different?' Enter the Stage.

When a Stage (a box in the left rail) is active, the rungs between it and the next stage box are scanned. If the Stage is not active, the rungs aren't scanned at all! In the stage you may have a rung to activate a certain output. Certainly you will have a rung to evaluate the condition(s) needed to transfer to another Stage. When that rung becomes true you will execute a jump (JMP) instruction. This will have two effects. It will deactivate the stage of which it is a part. It will also activate the stage which is its operand.

As a person who habitually uses Stage programming, the output conditions are the LAST thing I program. I analyze the machine action in the 'what is happening now' and 'what makes it start doing something different' These decisions become the Stages and the conditions for the jump instructions. Only after writing all the stages do I finally concentrate on 'by the way, during which of these stages is output Y on?' And it's perfectly fine if output Y must be on in more than one stage. Since no logic in a stage which isn't activated is scanned, neither are output instructions. As long as only one stage which controls a given output is active then other occurrences of the output in the ladder do not matter. If more than one were in simultaneously active stages then the old 'last one wins' rule applies.

One of the things I write in each Stage is error checking. If the Stage is active for more than the amount of time in an error checking timer then a problem has occurred. This timeout becomes a condition for jumping to an error handling stage. Invalid states of other inputs may also be a cause for jumping to error checking stages.

Our machines consist of multiple sections each executing a series of stages to work on the product in its section. When all have completed to a final stage for its section then a supervisory stage uses this fact as a condition to move the product to the next section and begin each section's stages again from their beginning.

Back To Introduction

Please email comments to me at the address below.

Copyright © 2005, 2006, 2007 Bernard Carlton