PLC Ladder logic style: Step vs State logic


Thread Starter

C. Thomas Wiesen

I would like to get some feedback on PLC Ladder logic programming style. I worked for an employer that preferred "Step" logic as a preferred programming style. By this I mean using input conditions to set bits that represented sequence steps. I find that this method can be messy depending on the
application and how the logic is implemented. State Logic as I see it means setting bits that represent machine conditions or "States". I find that this creates more structured code that is easier for me to understand and follow. I am interested in finding out what other people think are the merits and pitfalls of each style and under which circumstances each one should be

C. Thomas Wiesen
Kukulu Automation
[email protected]
Phone 608-274-2154
Pager 608-578-1297

Paul Gruhn, P.E. Moore Process Automatio

The IEC 61131-3 PLC programming language standard was specifically written to address these issues. Five languages are defined. (Ladder, Sequential
Function Charts, Structured Text, Instruction List, Function Blocks) No language is overall 'better' than another. Use the one most appropriate for the task, as each has distinct advantages.

Paul Gruhn, P.E.
Houston, TX
Hi Thomas,

This discussion took place here some time ago, but my opinion on it has somewhat evolved, so why not?

In Ladder logic, all the conditions are tested every scan, while in "Step" - which I understand as SFC or Grafcet - conditions related to that step only are tested. People here tend to say that SFC is harder to recycle, because first a known State has to be reached. And that it is less safe, since some conditions are not always tested. But on the other hand, SFC is much easier to follow than pure ladder.

To conclude, a couple of remarks

1. Even using Ladder, it is good to think in terms of SFC, and create clear states.
2. In think the best is in compromise: SFC for overall logic, while keeping Ladder for movements and Safety issues.

Hope it helps,

Pierre Kohn
ABB Body-in-White s.a.
Beauchamp, France

Phillip O'Meley

I have found that all types of PLC programming have their use. It depends upon what the goals are for the program and how difficult the process is being controlled. It would be interesting to learn why your employer prefers Step logic. Most
people base their preferences on what they hare most comfortable with. In various applications it may be more efficient, long term or short term to
use the different types of programming. I realize this doesn't give a clear or concise answer to your question, but its a bit like some people prefer Fords others GM.

[email protected]

Anthony Kerstens

The problem with using state driven logic is that you must be able to clearly and accurately define all the possible states the machine MIGHT get into, including error/fault states!!!! This is fine for a pop-machine, but as you get into complex systems, defining all possible states and their interactions can become a very cumbersome task.

I have seen people "successfully" implement custom state-driven bit-sequencers in Ladder Logic. However, bearing in mind one very specific example that I have suffered from, something as simple as an operator passing his hand in front of a photo-eye completely boggled the system. Many such little unaccounted states resulted in the unusual necessity of having a sequence reset push-button on the panel door (in lieu of rewriting the logic).

Like I said, it's great for pop-machines. You're better off using step logic that is driven by physical inputs rather than inferred logic (usually timers).

Anthony Kerstens P.Eng.

Grayg Ralphsnyder

I have successfully used 'step' logic for many years. By this I mean, when certain conditions are met, you progress to the next step in the sequence. Sometimes it is a bit tricky to allow steps to be executed in reverse order but can be done. Safety really depends on how YOU implement the required functions. The most 'safe' programming methods can be made 'unsafe' by poor

Good luck,
I don't really see the distinction.

As far as I am concerned a step in a sequence is the equivalent of a machine state.

In each case the machine remains in the step or state until a particular condition (or group of conditions occurs).

The distinction then is one of semantics, the process is at step xx or the machine is in state yy.

Pierre Desrochers

Just one example - One of our clients has a fresh-water plant. During a retrofitting job on one of the PLC we where amazed by the nervousness of the
plant operators about not touching any button when the fliters or softener where in purge cycle. So we hook up a laptop to this PLC and we found that in either cycle, if we where to switch to manual mode, the sequence ended up lock in the step it was in. Cycling power did'nt solve the situation, we had to force inputs or mechanicaly move some rotary pneumatic valves. The original programmers did not see all the possible faults... This system is still like that ! We added counters to monitor every seloctors and
pushbutton operation. This system is almost never touch by operators. Fear is among them.


Johan Bengtsson

I would say that this is entierly depending on the application
I prefer to use both, ie use the type appropriate for the problem.

For some applications a mix is the best solution, but this is may perhaps be avoided.

/Johan Bengtsson

Anthony Kerstens

Comfort with methods and technologies certainly is a factor in any decision made. I would go the extra length to say "trust". As a consultant, not only do I have to do what I think is right and correct, but I also have to consider what the customer wants.

There are many times I have coded systems in a manner prescribed by a customer that I did not like (unusual as opposed to unsafe), but I
still provided what they wanted because they were willing to sign-off on it. As for efficiency, despite my discomfort with the
customer's prescribed method, it was more efficient for them because it is what they knew!!

Anthony Kerstens P.Eng.
Funny that you mention the problems with trying to program multiple "step backwards" in a sequence. Can I ask what type of machine would require stepping backwards more than one step? I've found that it's usually only necessary to have the ability to reverse the sequence only one step. Mostly used for troubleshooting, this allows the operator to cycle one portion of the sequence over and over by repeatedly selecting between "Step Forward" and "Step Reverse". Look at your step sequences and you may find that
allowing only ONE step backwards is pretty easy to implement.

Just my thoughts,

- Eric
[email protected]
Packaging Associates Automation Inc. [email protected]
Rockaway, NJ, USA

> From: "Ralphsnyder, Grayg" <[email protected]>
> I have successfully used 'step' logic for many years. By this I mean, when certain conditions are met, you progress to the next step in the
> sequence. Sometimes it is a bit tricky to allow steps to be executed in reverse order but can be done. ...<

Tommy Thompson, Georgia Pacific Corp.

In 1989 a group of Engineers that I worked with developed a form of "Grafcet" that could be used with any PLC in the world. It was used thoughout a plant that had 8000 I/O points. It is fool proof if you follow the rules. It is the only way that I write program code anymore. It is quite different from conventional programming which in my opinion is not conventional at all since 10 different people would write 10 different motor/starter circuits. Using the style of Grafcet that we did, everything was conventional. Any one of 10 people would write the identical same code as long as they had the "Grafcet". I will not bore the whole group with the details but if you are interested give me a shout at [email protected]__ I will gladly share it with you and seriously doubt there is a program scheme that exist which you can't write as long as you follow a few basic rules. I once saw a plant that thought they had such a complex control scheme that no one would be able to solve all of their poblems. A friend of mine stayed up all night, wrote the code in Grafcet and the machine started up the next day flawlessly. To my knowledge it has been running ever since. That was 14 yrs ago.

Good Luck

Johan Bengtsson

It should not be THAT hard to implement several backward steps either (not if the tool you are using is a good one), it may look strange though, but not hard to do!

/Johan Bengtsson

P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]

Eric Nelson <[email protected]> wrote:

> Funny that you mention the problems with trying to program multiple "step backwards" in a sequence. Can I ask what type of machine would require stepping backwards more than one step? I've found that it's usually only necessary to have the ability to reverse the sequence only one step. ...<

C. Thomas Wiesen

The issue that bothers me about "Step" vs "State" is that a "Step" can be very complex and described too generally making additional complex code necessary. A "State" is a specifically defined set of conditions. For example, "State" and "Step" could be considered the same if the step is "Raise Part". A "Step" labeled as "Flip Part" could contain sub steps of:

extend arm
close grippers
raise arm
rotate grippers
lower arm
open grippers
retract arm

I have seen code programmed in "Step" logic that did this very thing. The "Step" logic was so simplified that it provided little value to the program because there were many actions for each "Step" and the actual motions actions were still hacked out in hard to follow code. Only a few "Steps" were defined but many more actions were actually required. This may be a matter of semantics or discipline in coding, but I feel that referring to conditions in the program as "States" allows me to code more consistently and I can follow the program better. What do other
people think?

> From: "Ralphsnyder, Grayg" <[email protected]>

> I have successfully used 'step' logic for many years. By this I mean, when
> certain conditions are met, you progress to the next step in the sequence.
> Sometimes it is a bit tricky to allow steps to be executed in reverse order
> but can be done. Safety really depends on how YOU implement the required
> functions. The most 'safe' programming methods can be made 'unsafe' by poor
> implementation.
The "state" versus "step" thread is an interesting discussion because real world PLC programming is always so much more complex than the neat examples found in textbooks. The specification for process operation generally arrives with a "step" description of the expected
functionality. Two Problems:
i) Exception handling is given short shift. (e.g.. the timer expires after 5 minutes like its supposed to but unit #1 is in mid-cycle and
needs all the pneumatics to finish its task but the operator knows there is enough pressure anyways so he wants to put it in manual and push it through but he wants unit #2 to revert to auto after this cycle because unit #1 won't be a problem then, oops, the photocells off alignment,
ii) Ultimately, the PLC translates the program code not into a "Step", but a "State" - the various outputs being energized or de-energized and analogs being modulated. The object is to have the desired "state" of affairs for both normal and exceptional conditions. I have seen not a few programs which just get lost if sequencing cannot progress as planned.

So the question is not so much "state" versus "step", but how to methodically get from "step" to "state". For a moderately complex system, I find it useful to spreadsheet a grid, listing all the steps, their transitions, and reasonable exception cases, across the top. Down the left column are all the pertinent I/O. The grid is filled in by symbols for ON, OFF, or Doesn't Matter. Even that represents a reduction of complexity but at least I get going in the right direction.

>From there, I program backwards from the outputs, and split off manual and sequence logic. i.e.. Valve B is open if the sequencing calls for open OR is manually called for open OR if the system is in relief....(add prior rungs...) sequence open coil ON if in step 3 or
step 5 AND system NOT is manual OR relief.

Ron Sewell
Sigmatic Controls
Kelowna, B.C.
I use the same method to map valve positions for Turbine driven compressor applications written in ladder.
Using the spreadsheet map, I can identify how many distinct states are needed. I can build logic to set a coil for each state. Each state can be selected in order or random, so a backwards step or a jump of several steps are as simple to implement as a single step forward. Next I use a contact off each state to set the valves open or closed. This makes it very easy to modify as well.
In the case where someone else might modify the code, I add a test for more than one active state at a time, and if found, force the system to a safe shutdown state.
If using Allen Bradley SFC programming method - simply consider each vertical SFC connection path as:
A subroutine that calls a subroutine upon a condition (but logic solving never goes back to the calling subroutine), Etc.
The only real danger is that when you stop executing a subroutine all values stay in their last solved state.

Account for that & you can do anything you like.(I've programmed PLCs for 25 yrs & will avoid SFC programming if possible)
Interesting question, especially for types like me whose first introduction to programming was with sequential programming languages like BASIC.

It took a while to get used to the 'logic network' architecture of a PLC. But once I did, I saw the elegance and appropriateness of the language.

For safety's sake, the simplistic (and therefore robust) architecture of a PLC is ideal. Never sacrifice this feature of PLC's. Common programming practice in the U.S. automotive industry features a rung of "safety" logic for each discrete machine motion. Each motion is inhibited unless this rung solves 'true'. Since the PLC scans this rung of ladder logic each program scan (you had better be sure you structure your program such that it does), the safety of the machine and personnel is almost assured.

Next, it's important in any programming language to break up a large problem into small ones. There's something to learn from object-oriented programming, as well. Treating a portion of a machine as a discrete 'object' with properties and methods, is a very effective approach. This is where the transition to approaching your problem with 'state' logic comes in.

Think of your body. Each part seems to have a measure of built-in intelligence. It doesn't take much conscious thought to pull your hand back from a hot surface, or react quickly to a pinprick. It's almost as if your arm has some intelligence of its own.

Program each component of your machine as an intelligent 'object'. The portion of your ladder that controls that component should be programed to carry out an action on command of the higher-level function of your control program. As in another poster's illustration, imagine the steps involved in telling a robot to flip over a part. There's several discrete actions involved, but for the supervisory level of your program, it's just one action: flip that part.

Whether or not the part is ready to be flipped is properly the concern of the supervisory portion of the control program. The command to flip the part could be raised during the exectution of the pre-defined steps of the automatic cycle, or it could be raised as a semi-automatic sequence initiated by an operator. In either case, the logic that determines whether each discrete sub-step involved in fipping the part is conditioned by the ever important 'safety logic' embedded in the low-level code.

Freeing the supervisory portion of the code from the details of each program step, produces an ideal 'hybrid' code pattern. State logic keeps the individual components of your machine from doing anything stupid, while the supervisory-level code can churn along sequencing the entire unit through its automatic cycle.

Programmable devices that are controlled by your PLC often provide signals like 'ready' or respond to single-bit commands like 'go'. When programming in this method, these peripheral devices can be treated pretty much the same as the rest of your system. Sometimes, it's necessary to write some 'wrapper code' to coddle and condition the device, as I've had to do so in programming interfaces to robots and servo controllers. Your 'wrapper' then generates signals for the supervisory level of your control program - signals like 'ready', 'complete', or 'faulted'.

On an Allen/Bradley PLC, I usually put the code for each sub-system (robot, servo, lift table, conveyor), in its own file. The supervisory program usually resides in file two (or three, if you just use file two for subroutine calls). Fault diagnosis is usually approached as a question of 'state', and that code goes in its own file.

Now, applying this to the question of 'backtracking' the operation, imagine how much easier it would be to write a this code in the application described wherein a robot has to flip over a part. The supervisory portion of the code will give the command to flip the part in one of two circumstances - stepping the cycle forward, or stepping the cycle backwards. I can't imagine the logic for this existing in more than one rung, and being very clear when trying to decipher the code. However, if the logic required to control the robot through all 7 or 8 discrete sub-steps for flipping the part was all cluttered up with having to deal with moving forwards or backwards, well, that's why they call it 'spaghetti code'!

So, to answer the question of whether it's better to program in a 'state' or step paradigm; I'd say 'neither'. You should not abandon 'state' thinking, especially since the state logic approach does so well in assuring safety. But designing a program such that you define steps to be executed serves well in writing easy-to-follow (and easy to debug!) code. Tell your boss that you'll write 'step' logic, and deliver 'hybrid' code. He'll thank you for it later.