Can automation equipment / PLC program use States


Thread Starter



I have used PLCs in the power generation industry. Due to the nature of these systems, a lot of faults happen asynchronously and it is typically unacceptable to shut the site down. For the most part, this leads to "stateless" design patterns. People just make logic in a large and/or/latch mess to handle the ideal sequences and the faults. A lot of this comes from people zeroing in on a specific failure, but it modifies the entire program, typically by accident when the modification is done. I am thinking about a career in a different area that uses PLCs. In automation machinery, is this much more controlled? Can most machines be broken down into a finite state machine for control? Or is PLC programming just sort of always this way? Does the fault handling typically drive the machine to go into an e-stop/fault state?


William Sturm

Most PLC programs use combinations of bits as state. Using bits as state is kind of subtle, but it clearly works. An auto/manual mode bit is a state. I have used integer values to hold state sometimes, mostly in the past. Integer state values work great on some PLC's, not so great on others. A C or BASIC program uses integer states. An integer state enforces "one state at a time", but is more difficult if you need multiple overlapping states.

Bill Sturm

Curt Wuollet

GE even had, (has?) a "state logic" programming language. But, state machines can be implemented in almost any language. More than once I've ended up doing a state engine without starting that way as it is ideal for some classes of problems. It is a bit inelegant and hard to recognize on some ladder systems. And it can be confusing until you see it for what it is.


My former employer and regular advertiser on this site Control Technology Corporation uses a state language to program it controllers.

Your friendly local moderator,
Peg Ferraro
I personally program PLCs like a step by step procedure for the most part. On older style PLCs I have to set the next step bit and reset the current step bit at the end of every rung. It is tedious. In modern PLCs you can have a logical equate of a step counter at the beginning of every rung and simply increment the step at the end of every rung. This makes inserting a rung far easier. Its kind of a way to force PLCs to behave in a sequential fashion like you are programming in C or BASIC. To create another "task" you just have a different named step variable, that's it (I often will start a new "program" to divide my work for readability if the PLC software allows it).

Also, having programmable function blocks allows you to put a lot of functionality on one rung. I've programmed everything from a simple pause delay to doing a servo move within function blocks (complete with error handling and fault handling logic buried inside).

As for fault handing, I build function blocks to put the fault handling at a lower level so that you don't have to wade through repetitive code. It works well.

Sure there are times where some things are just a simple logical AND and OR operation (for example: turning on a de-reeling motor or something like that). In these cases the PLC ladder logic is a natural fit.

In the end I'd rather program in a hard realtime multithreaded environment with C++, but ladder does have its place and I use it where appropriate.


As others have described, there are a number of ways of implementing state logic in PLCs. As you allude to, many times the bigger challenge is developing what the states should be and under what conditions the logic will transition between them. Many people fall into the trap of implementing a simple 1,2,3-style sequencer which works under normal conditions but causes serious complications when abnormal conditions develop. Or even worse (and all too common) are an unorganized collection of bits that are latched and unlatched in the logic as various conditions are met.

Drawing a diagram of your logic with circles for each state and arrows to represent the transitions between them should be performed before writing your logic.

One of the more challenging aspects of state logic is maintaining the correct state of the system while the machine is in manual mode and then switched back to automatic operation without unexpected consequences. Usually making the states in your logic mirror the physical state of the machine provides a good starting point.

Ron Davis
Sunapsys, Inc

I am absolutely familiar with doing state graphs. I implement them using structs in schneider electric PLCs using the state change logic and what logic to perform in a state. That is not an issue with me. The problem in the power industry is that so much can go wrong asynchronously, that the literal states of the machine is infinite. For example, most systems ship with auto manual switches for each breaker. an operator can walk up, change the breaker(s) state, and the machine is supposed to respond. This is all well and good with simple systems, but with customers that want data center protection/ tier III, the simple task of analysing where the system is at becomes incredibly large. For example, a breaker can have 4 states, if you have 8 breakers that is 4^8 or 65536. Yes, you can break it down partially. However, the way to make the program bullet proof is to know positions of all breakers before executing the action. There are a lot of developers that simply rely on the breaker protection logic to handle this. A lot of issues are solved "by accident" in stateless design. This is simply using latching for various modes. I am considering exploring other areas of PLC use. I am curious if this complexity exists in these machines, or if they traditionally can be broken down into synchronous flow. Where, depending on the fault type, the machine simply goes to an estop condition.

Thanks again,
All the discussions that I have read can likely be solved by using the Schneider Electric Unity Pro SFC (Sequential Function Chart) programming language. States and Transitions, one or multiple tokens, actions on entry/exit of states, actions while in states, complex or simple transition conditions, parallel paths etc. Diagnostics are built in. Possible to force a move to a particular state. SFC can be used in conjunction with the Function Block, Ladder or Structured Text programming languages.

If the PLC is stopped/re-started, the SFC "restarts" from the last active state, or in another designed state.

I think we are getting to my answer. I think what I am hearing, is that in other industries, state graphs are possible and are used. I am familiar with SFC. It is one of my favorites. Where the power gen industry falls apart is simply the variability of desired features and the inability to model as a state graph. This feels promising to me to explore what else is out there in automation.


Vladimir E. Zyubin

> For example, a breaker can have 4 states, if you have 8 breakers that is 4^8 or 65536. <...> I am curious if this
> complexity exists in these machines, or if they traditionally can be broken down into synchronous flow.

Hi, Tim.

You have met so called block synthesis problem. The problem has no good enough solution either with the IEC61131-3 languages nor with the native FSM model. If you have a procedural language on your PLC (ST or C) and if the number of your devices is less than ten, you possible will be lucky with the process-oriented style. The main idea is to organise logically parallel execution and communication of the FSM-like structures. I personally dealt with algorithms that were equivalent to FSMs with 10^30 states. Control algorithms with up to 1000+ "FSMs" are quite maintainable (with process-oriented languages), so a couple dozens processes can be implemented "by hands" with a measurable headache.

the best,
This is just my opinion but I feel that doing complex work in SFC or flowchart is tedious and obscure. I've used Steeplechase VLC which at first was a brilliant interface but as the machine needed to be more complex we found that the real functionality was buried in pop up dialog boxes and it was very easy to have the comments on the flowchart elements not match the buried programming under the hood (Admittedly this was partly sloppy on our part, but the program language all but encourages it). It is difficult to summarize complex logic in a flowchart element anyway. I've also used SFC in a motion controller and found it to be horrible. You end up with pages and pages of code to do things that you can do in a procedural language in one screen of understandable code.

I don't mean to cause a flame war and repeat past posts. I use PLCs with ladder when I need simple to intermediate control programming and an RTOS with C (or whatever C/Java/VB derived language exists on that device) when I need something very powerful and maintainable.

I don't like function block, but I do like SFC. You have a lot less logic active in any given machine state, and sometimes drawing it that way even helps you think about the states for the machine.

Not a lot of PLC's with a really clean implementation, though.

Vladimir E. Zyubin

> This is just my opinion but I feel that doing complex work in SFC or flowchart
> is tedious and obscure.

It is natural. SFC is based on Petri net model... and, as it can be found easily: "Petri nets were invented in August 1939 by Carl Adam Petri – at the age of 13 – for the purpose of describing chemical processes" (Carl Adam Petri and Wolfgang Reisig (2008), Scholarpedia, URL:

There are two interesting points in the statement:
1) "were invented in August 1939", i. e. "long before PLCs were invented";
2) "for the purpose of describing chemical processes", i. e. "features of technological process were ignored".

So, the human being, which believes he can easy use Petri net model to describe control algorithms intended to be executed on the digital platform, looks like a naive eccentric... in my view.

the best,

Bruce Durdle

I find that using an SFC approach to the design stage of a complex sequence can highlight all the "what if"s - so, the turbine speed has to reach 4000 rpm in 30 seconds - but what do we do if it doesn't? The usual spec from equipment designers says what is supposed to happen but often it's the times that it doesn't that cause the problems with sequence controls.

For every check that is made in the sequence, there needs to be a success path and a fail path, both of which must eventually return to the starting point with the complete system in the same state.
I agree. I joke with a colleague of mine that we tend to code 80% for the error conditions and 20% for the normal behavior. With function blocks some of this can be encapsulated, but still!


Vladimir E. Zyubin

> there needs to be a success path and a fail path,

Agreed. Could you explain, which way do you implement it on the SFC language?

-- Vladimir

Bruce Durdle

An SFC is made up of transitions and actions - a check for a particular result will trigger a series of actions based on that result. So starting an auxiliary oil pump motor prior to starting a large machine is an action - a test as to whether it is successful will be based on a pressure switch in the system.

But it's no use simply saying "If the pressure switch makes, carry on and start the motor" - you have to have some sort of time limit on the pressure switch being made and then decide what subsequent actions are needed if the pressure input isn't made in that time. The SFC provides a useful graphical tool to review the situation and explore the "What Ifs".

A useful concept in most machines is the "operational cycle" - the state of a system will initially be "Power Off and Shut Down". With power applies, it will go into a reset or standby state, and after any running sequence (successful or unsuccessful) will generally have to return to the reset state. The "state" doesn't just refer to the control box, but to the total system - including equipment powered up or down as part of the operation. In the example of the auxiliary oil pump, don't forget to shut off the pump motor as part of the fault routine, just in case the problem is not with the pump (Had this happen to me once on a gas compressor when the oil pressure switch failed - the motor started, the sequence aborted on oil pressure failure, and the motor continued merrily to pump oil into the casing until someone noticed it coming out the seals. Seems the programmer had decided that the only possible cause of failure to meet the pressure requirement was that the motor wouldn't start, so he didn't bother to explicitly stop it.)

Once you've decided on the necessary system states and transitions using an SFC approach, converting the requirements into an operational program is much easier and less prone to error if the target system can be programmed directly from the SFC rather than the chart having to be translated into C or some other implementation. However, it is quite easy to build up the structure to implement an SFC-based control, even with ladder (or, for that matter, in TTL).

The problem with developing a complex control system, especially for sequential controls, is not in getting the final control platform to do what is required - it is in deciding what in fact the system is required to do. This usually needs input from people who are not necessarily familiar with the trivia of programming languages, and need some sort of diagrammatic aid to understand what is happening. SFCs, FBDs, and other approaches are all useful tools in different circumstances to help with this process.

Vladimir E. Zyubin

Bruce: Thank you very much for your detailed explanation on PLC basics, but my question was about the code on SFC that implement the declared strategy -- "a success path and a fail path".

This is right control strategy I use it in every control project, but I personally see big problem with the coding in terms of SFC... even in the case of a simple sequential algorithm (without parallelism and hierarchical structurization).

My doubts based on the fact that there is no conceptual support for the strategy in the SFC. SFC (Petri net) was invented for chemical processes (to describe they). And there is no need for "fail path" case in description of a chemical process, and there is no core need for the if-else constructions, etc. (though I know it can be implemented by means of the SFC language in the unsafe manner).

So, I think any attempt to implement the strategy on the SFC language leads to extremely tedious/laborious coding, an un-maintainable code, and run-time problems with the safety.

But I realize the above is just my speculative conclusion, and I would like to check its correspondence with reality (your practice). Do you invent any trick for a seamless implementation of the "success/fail" control strategy on the SFC language?

Again, many thanks for your detailed answer.


Bruce Durdle


One of the basic elements in SFC is the transition, which will have a logic condition associated with it.

Another is the divergence, where a single step has a number of possible subsequent steps, each with their own initiating condition.
So to implement my example test I would use a transition with condition "Pressure switch made" as the "pass" test with another transition which is taken if the pressurize step has been running for more than 10 s as the "fail" test. I can use a number of transitions to implement a "case" element.


Vladimir E. Zyubin

> Another is the divergence <...>
> So to implement my example test I would use a transition with condition
> "Pressure switch made" as the "pass" test with another transition which is
> taken if the pressurize step has been running for more than 10 s as the "fail"
> test. I can use a number of transitions to implement a "case" element.

Bruce, as far as I know the divergence does not equal to the case structure, it can lead to duplication of the markings, i. e. the both paths can be activated.

Have a look at the user's manual ( , page A-38). They write, "Divergences and convergences are used to represent multiple links between steps and transitions. Simple divergences or convergences represent different inclusive possibilities between different sub parts of the process" (the word "inclusive" is bolded). And then, in the comment under example, they emphasize that nuance again -- "Warning: following transitions are not implicitly exclusive"...

So, more or less safe approach is: 1. to insert a single divergence with hand-made two exclusive conditions/transitions (for success and NOT success path), and then, 2. for the "NOT success path" to insert an empty step, and then, 3. to insert a transition (for the false path, in your case -- the tricks with timer to catch timeout).

As far as I understand the above is a safe implementation of case structure only, otherwise you will have unsafe implementation with an unforeseen behaviour.

...but the safe implementation has a lot of undesirable side effects I have spoken about in the previous messages.