Sequential state machines

kebaldwin

Guest
K
In X years of programming I have not had one customer say that sequential function charts (or similar) PLC programming was acceptable. Everyone wanted ladder logic. In fact, we have done several jobs converting sequential function chart type code to ladder logic because their people could not understand SFC.

Anyone else have similar experiences?

How do you typically code state machines (sequential logic) in PLCs. I've found that most beginners start use a spaghetti combination of internal coils and outputs to keep track of their states. A nightmare to try to follow.

Some use drums (remember those). Although it uses a lot of overhead, they go both backwards and forwards.

We typically use counters (esentially a more flexible version of "the drum") to keep track of the state (step) number.

Any other ideas?
 
Some manufactureres (AutomationDirect.com) have stages that are handy for the type of programming you are talking about. For other platfroms we routinely use subroutines to segregate tasks that are specific to one state of a machine's operation, keeping common features such as alarming in the main portion of the program.
 
kebaldwin said:
In X years of programming I have not had one customer say that sequential function charts (or similar) PLC programming was acceptable. Everyone wanted ladder logic. In fact, we have done several jobs converting sequential function chart type code to ladder logic because their people could not understand SFC.

Anyone else have similar experiences?

All the time. SFC does make machine sequencing easier. It also allows one to orgainize the project and make code sections easier to find. I worked on a big think&do project once with over 100 axes. It isn't SFC but having a flow chart that orgainizes code into steps/states made the program much easier to follow and debug.

kebaldwin said:
How do you typically code state machines (sequential logic) in PLCs. I've found that most beginners start use a spaghetti combination of internal coils and outputs to keep track of their states. A nightmare to try to follow.

Some use drums (remember those). Although it uses a lot of overhead, they go both backwards and forwards.

We typically use counters (esentially a more flexible version of "the drum") to keep track of the state (step) number.

Any other ideas? [/B]

I wouldn't use drums or counters. I would use either state bits like Mitsubishi's STL or Automation Direct's stage program or integer in a similar way you use counters.

1. By using state bits or registers.

The problem with bits is that one must make sure the exited state has its bit cleared. It is too easy to leave state bits on. The advantage is that one state can branch into two separate sequences.

I normally use a memory location ( integer ) much as you use your counter. This is a lot cleaner, but not as flexible as the bit method. I would not use counters. Integers are more flexible.
If I want to go to the next state I can just add 1 to the state. If I want to skip a state I can add two. If I want to go to a state I can just move the new state number into the requested state.

One more thing. There is a possibility of race conditions. To avoid that I often use two registers. One is the current state and the other is the requested state. When a state change is made the requested state only is changed. At the top of the ladder the requested state is then copied into the currecnt state. This makes sure that many states don't get executed in one scan.

WHY BOTHER?

I do a lot of motion control. One very common problem is that users often give the command to move and then check for the 'in position' bit to see if the axis as reached its command position. The problem is that too often the in position is checked before the PLC even has a chance to send the command to the motion controller. The in position bit hasn't even gone off because the axis hasn't started to move yet. This causes the statemachine to jump a head to the next state too soon.

The requested state/current state method make sure only one state is executed per scan.

Finally, Siemen's S7 has the JL ( jump distributor ) instruction that allows one to implement very efficient state machines. The JL instruction is like a ON GOTO instruction in basic or a simple switch statement in 'C'. Why don't more PLCs have this feature?
 
Hmm!

Peter,

I thought your explanation on how you incorporate states into your programming was fascinating, especially the requested state / current state method.

Would it be possible for you to post a small example of how you would implement this in ladder?

Thanks!

TM
 
One of the things I've found confusing when talking about State Machines is the difference between State and Step. Some people use the two terms interchangably, while others differentiate between State (Idle, Running, Paused), and Step ("Grip the Widget", "Weld Part A to Part B").

Some of it is just semantics (for instance, the above Steps can be considered to be part of the "Running" State, or rather, the Running State can be divided into other States such as "Running - Grip the Widget"; you would never have a "Idle - Grip the Widget"), but the differences can be important (For example, when coming out of the Paused State, it's nice to know what Step you are/were on so you can enter the Running State on the right Step. If you don't seperate the two concepts, then you may have to create lots more states: "Paused while Gripping", "Paused whil Welding", etc.)

I've only had a few clients who would allow SFCs (although there were many who wouldn't have cared - they didn't intend for their maintenence folk to go into the PLC). Even so, I almost never use them.

SFCs are fine if everything goes according to plan. But if you add a PAUSE button, or an E-STOP, and they can get real ugly, real fast. That's the beauty of Ladder Logic - it is more adept at exception handling than SFCs and some of the other highter level hanguages.

But the philosophy of SFCs, that's something that every novice PLC programmer should learn, to prevent the spagetti code that you've mentioned. The concept isn't hard - you have States (or Steps if you perfer), and the Transitions from one State to another State. That's all there is to it. The only thing to watch for is to make sure that the Actions that are being executed in a particular Step will generate the condition necessary to acheive the desired Transition.

I've seen two types of code that handle the Step/Transition logic well. The first type is of the "poke-a-number" variety. This includes the drum (e.g., the AB SQO instruction) or the equivalent Indirect Pointer to a bit matrix (which sounds like your counter)

The biggest problem with the counter types is getting the sequencer to recognize when there is a "Null" Step (or a step whose Transition conditions are met before the Step is active). Counters (and the SQO) need a Low-to-High transition, and so the rung conditions have to go back to Low (false) for at least one scan for the counter to recognise that it's OK to count again. I've seen some pretty fancy logic to accomplish this (successfully and consistantly), but it can be a problem.

The variant I use is the following code:


STEP 1 ON_STEP_1 TRANSIT_2 +-- MOV -+
-----| = |----+----| |---------| |------| 2 |
| | STEP |
| +--------+
|
| ON_STEP_1
+----------------------------( )


STEP 2 ON_STEP_2 TRANSIT_3 +-- MOV -+
-----| = |----+----| |----+----| |------| 3 |
| | | STEP |
| | +--------+
| |
| | TRANSIT_7 +-- MOV -+
| +----| |------| 7 |
| | STEP |
| +--------+
|
| ON_STEP_2
+----------------------------( )



`
Of course, this doesn't drive any outputs; this only controls the sequence. I have the ON_STEP_x coil on the above rung to do two things. First, it ensures that a sequence will be on a step for at least one scan. This helps prevent the opposite of the counter problem I mentioned above - blowing through a sequence too fast.

The other thing that the bit does is drive the outputs. A typical set of outputs might look like this:

 

ON_STEP_1 VALVE
---+----| |----+-----------( )
| |
| ON_STEP_2 |
+----| |----+
| |
| ON_STEP_3 |
+----| |----+


ON_STEP_2 PUMP
--------| |----------------( )



`
The exception logic can be put whereever its needed. I can put it as a condition to a Transition, a Step (IF E-STOP, MOVE to STEP Zero), as part of the output rung (stop the pump, but not closing the valve on a PAUSE condition).

The biggest limitation of the Poke-a-Number type of sequencers is that they don't handle diverging logic. If a sequence needs to spawn two simultaneous threads, and then later join back together, the Number sequncer fails, although an SFC can do this without much ado.

For these, I use the Latched-bit sequence. I know that the PLC world is divided very strongly into two camps regarding Latches and Unlatches. And there is much to be said in favor of both camps. The code that follows looks a lot like the badly-written code of a PLC programming newbie. BUT, if you truly understand the concepts of State and Transition, it works just like the above code:

 

ON_STEP_1 TRANSIT_2 ON_STEP_2
-----| |---------| |-------------+------(L}
|
| ON_STEP_1
+------(U)


ON_STEP_2 TRANSIT_3 ON_STEP_3
-------| |--------| |-------+----+-----(L)
| |
ON_STEP_5 TRANSIT_8 | | ON_STEP_2
-------| |--------| |-------+ +-----(U)
|
| ON_STEP_5
+-----(U)



`
Note that there is one and only one rung to latch the bit which describes a Step. And that any Step which can lead to a particular Step gets unlatched on the same rung that that Step gets latched on. This violates the "rule" that some PLC programmers hold dear, that you must have only one unlatch and one latch for a bit.

TOUGH. It's a good little sequencer - easy to follow and troubleshoot. It drives outputs in the same manner that the first one does (I've seen one variation on this where the relevant outputs are Latched/Unlatch on each Step along with the Step bit - I don't recommend this, even if it does more closely resemble the philosophy of the SFC)

If the sequence needs to have two parallel sequences, then there would be two latches on the same rung. If the parallel sequences must join back together, both ON_STEP_x bits would be in series on the rung to latch the next next step (and unlatch both of those bits).
 
Last edited:
Allen,

>>For these, I use the Latched-bit sequence. I know that the PLC world is divided very strongly into two camps regarding Latches and Unlatches. And there is much to be said in favor of both camps. The code that follows looks a lot like the badly-written code of a PLC programming newbie. BUT, if you truly understand the concepts of State and Transition, it works just like the above code: <<


You've just presented the only justifiable case I've ever seen for this sort of programming.

I've seen latch-bit sequencing several times, and admired it's compactness, but never liked the end result. I realize now that I was looking at bad examples. In one, the programmer did not use states, he just ran from input to output. The other was the self-unlatching rungs you describe in the last paragraph, which threw me completely.

I can see that this sort of code could be very useful. Programming-wise, I have enough tools in my arsenal these days (FLL command, MOV command, etc.) to overcome the usual latching-output problems, like startup issues. I'm going to look into it further.

Lastly, I'd like to point out a form of program pause logic I've not seen mentioned thus far - conditional subroutine calls. In AB at least, if you stop calling a subroutine, it stops executing exactly where it is at the end of that program scan, and will remain so until called again. Do this with a single input, on all your subroutines, and boom - instant pause / resume logic.

Thanks!

TM
 
I've have yet to run into a customer who wouldn't allow SFC programming, but it doesn't surprise me that they are out there. I guess my take would be that an SFC would be easier to visualise than as equivalent state machine. But that is probably personal preference.

As Allen shows, a VERY important thing is to keep your state machine separate from your machine actions. If you don't do this things get very confusing very quick.

I personally like using integer based state machines using decimal values as opposed to base-2 powers. IMHO this makes interpretation of the current step a little more straight-forward. I've used these quite a bit and if you are careful about state machine construction they are pretty easy to understand and very easy to modify.

Peter, good call on the JL in Siemens. Like you, I wish everyone provided this instruction. It makes a very clean state machine.

Keith
 
Heads in the sand

It's sad but true that there are people out there in customer-land that want you to perform magic with one or both hands tied behind your back. When they say "SFC's are unacceptable", or "don't use FOR-NEXT loops", or "never use TOF timers", what they're really saying is that they are too lazy to attempt to understand anything new or beyond absolute basics.

My SFC experience is with PLC5's. I like them and use them. They greatly simplify the logic of a sequential operation. The interlocking and sequencing of actions/steps is embodied in the chart and allows the majority of the action ladder files to be a single-rung unconditional output. And since only active steps are scanned, over-all program scan time is optimised. For troubleshooting, the chart highlights the step it's on and you can then examine the appropriate transition file to see what's holding things up. Much simpler and faster than going through a lot of ladder logic with 3 or 4 branches on every rung.

The only legitimate argument I've heard for using a ladder emulation over the real thing is that you can edit the ladder on-line in run mode, whereas the SFC has to be edited in program mode. I don't accord much weight to this, since it exposes the arguer's lack of understanding of the sequence requirements before programming it.

Having said all that, I must say that I have yet to see an application where it would be practical or advisable to use SFC's for everything. For example, SFC's are great for sequencing an injection moulding machine, but offer nothing for barrel heating control or for start/stop of the hydraulic pump.
 
It's sad but true that there are people out there in customer-land that want you to perform magic with one or both hands tied behind your back. When they say "SFC's are unacceptable", or "don't use FOR-NEXT loops", or "never use TOF timers", what they're really saying is that they are too lazy to attempt to understand anything new or beyond absolute basics.

I have been here and done this before. It has nothing to do with lazy, it has to do with understanding, for a college graduate engineer or manangement to expect an electrician to understand "all" forms of programming is ridiculous and not at all realistic.

Simple fact, electricians have to go thru an extensive training process to learn their jobs, in an industrial environment they must learn even more. Many are very good at their job and have performed it efficiently for many years, to expect them to "know" or "understand" a toy of an engineer/programmer is as I stated not realistic.

Why cant any of y'all educated professionals create a ladder style programming environment that uses some of these features that make things so great for y'all but still maintains the ease of understanding that ladder logic provides.

Another simple fact, us "lazy" electricians must troubleshoot using your programming or troubleshoot your program in many cases. If we have to goto college to do this then why would we BE "lazy" electricians, it takes the roughly the same amount of time to complete an apprecticeship and/or journeyman process. We could just skip that process and be "lazy" engineers" instead.

I apologize for the sarcasm but as you can tell this is a sore point. I personally feel I can deal with any programming language you desire to use BUT in reality dont think most offer anything but a way to make a programmer's life easy...using the term that was stated earlier..."lazy". If only you or a handful of others can comprehend what you have done then you havent accomplished anything.

I stayed out of this until that statement was made because I am not that versed in SFC, stage, or step methods even though I have had to troubleshoot systems using them. I read (pronounced red) and learned alot from the posts on this subject..Thank you.
 
Last edited:
Did I mention electricians?

Happy New Year, Ron

In my experience, the nonsense "rules" come from 'freshman' programmers with little or no electrical background - typically draughtsmen (pronounced 'draftsmen').

Site electricians at plants where I have installed programs using SFC's have had little difficulty in understanding them after a few minutes' explanation. And they have later commented that they aid in troubleshooting. Perhaps I'm just lucky...

beerchug
 
Re: Hmm!

TimothyMoulder said:
Peter,

I thought your explanation on how you incorporate states into your programming was fascinating, especially the requested state / current state method.

Would it be possible for you to post a small example of how you would implement this in ladder?

Thanks!

TM

I am going from memory here, but I believe these programs have an example state machine.
SLC state machine example
S7 state machine example. Not using JL instruction.

The S7 example has 8 state machines. One for each axis.
 
Happy New Year Gerry

I apologize for being/sounding sarcastic. I love to read and learn about all forms of programming, never know when I may need it. I am not really an electrician though, I just play one on TV.

Actually I am an electronics technician playing an electrician not on TV. On a day to day basis I have to explain to electricians and engineers what is happening in that "little black box" thing. I do ok with alot of this stuff but geez its gets harder every day keeping up with the technology. I have with most brands (except ABB) obtained a good understanding of the Instructions and methods used. I probably could with ABB if I could figure out how to go online with it, even offline would be good.

I think alot of things will be standard one day but not just because its easier to program with but because its easier to understand. Thats one reason I think Siemens is on the right track with the 300/400 series...simple example, they have a block(box) that is designated "toggle" and performs exactly that function, toggles between outputs with one input. This works in a ladder and to me seems really simple to understand (the name says it all). Its the best of both worlds, an instruction that can be used in ladder but understood by electricians/technicians/non-programmers. They seem to have alot of those and I still havent learned how they all work.

I understand that you also have a job to do and that to make money you have to find ways to do the programming in as short a period of time as possible to be able to move on to the next job. I beseech you to consider the people that must come behind you that must work with/on the system, do not "dumb" down the code but find ways to make the code the best and understandable to the poor guys in the trenches. Those guys dont want to look dumb even if they are in ways.

I meant no disrespect on your abilities and apologize for the sarcasm.

BTW Peter thanks for the examples.
 
Actually, Ron, I'm inclined to substantially agree with your first comment. I have observed that it is common for programmers (especially rookies) to forget that the customer isn't paying for programming. They are really paying for a machine or process control function, and the programming is one of the tools involved in producing the desired result. Troubleshooting and maintenance are just as critical as writing the original code, and in many cases are more difficult.

The more "sophisticated" languages are fine and should be used if appropriate. However, if a customer feels plain old ladder logic is going to enhance his maintenance and troubleshooting efforts, it is a valid choice and doesn't constitute "dumbing down" the system. It is a selection of appropriate technology for the production environment that the system must perform in, and in many cases results in total life cycle cost lower than might result from more elegant programming that causes difficulty during ongoing operations.

After all, the original PLC was developed for the very purpose of producing robust hardware with flexible functions and troubleshooting techniques familiar to electricians commfortable with JIC ladder diagrams. That ain't bad!
 
I use ‘state’ programming quite regularly and I have never had a problem with the customer not understanding what is happening.
In fact I think if done properly it simplifies the troubleshooting.

I mainly use Mitsubishi state programming which is known as STL (Step Ladder)
This can be confused with statement list but that is what mitsi call it.

I have a few rules to make it easy to understand.
One is make each stage small and the other is to branch each condition from the ‘stage’ contact.
This makes each stage easy to differentiate from the last and next.

Each stage is clearly labeled and I make sure in the event of an unforeseen problem there cannot be a domino run-through.

I have shown none electrical personnel the programs running and they had no problem following what was going on.
 
From kebaldwin's original post:

How do you typically code state machines (sequential logic) in PLCs. I've found that most beginners start use a spaghetti combination of internal coils and outputs to keep track of their states. A nightmare to try to follow.

I think this is the best reason to use SFC. Granted, I am referring to platforms that provide SFC or an SFC equivalent as part of the base programming package (AB PLC5 or Koyo come to mind immediately). If I needed to purchase a separate option to program/view SFC I would probably feel differently. Because of their visual nature I find SFCs are very helpful in understanding program flow as well as aiding in troubleshooting. While there are a few new rules you need to learn the end result is easier to understand.

It all comes down to design. If you write an SFC that ANYONE is not able to understand you will very likely write a ladder state machine that cannot be understood either.
Where you get into trouble is when the baseline SFC structure is circumvented using jumps and other types of misdirection. If you need to do this either your process does not lend itself very well to SFC programming or the process needs to be broken up further to pull out the sequencial portion of it.

In theory I tend to agree with Tom's comments, although I'm not quite as committed to it. In kebaldwin's case it sounds like the customer base is at a relatively common level and no one wants to get into SFC. In that case it doesn't seem to make sense to fight the tide. However, if I can write software using SFC (or any other language for that matter) that is less likely to contain hidden issues and takes half the time to develop and commision, maybe I (and the customer for that matter) am better off providing the customer with detailed training and extended support. Ultimately it saves me time in development and commisioning. It also may save the end user time in that the state machine doesn't break when an operator hits some button combination with his toe on the 4th Tueday of an odd month under a full moon (we've all had those). There is less support time required because the software is more stable.

Just some thoughts.
Keith
 

Similar Topics

Hi there, We have a system at a water treatment plant where large raw water tanks feed into the plant that's all on the same level. At high tank...
Replies
18
Views
3,646
Hi, I started off my career in PLC programming doing water/wastewater on AB around 20 years ago, but then moved overseas a few years later and...
Replies
57
Views
11,866
It appears to me that Logix is improperly executing sheets of an AOI in sequential scans instead of the same scan as the main program. To test...
Replies
4
Views
1,657
Hi, is it possible to read the name of the steps in an S7 Graph sequencer? In the parameterinterface there is, for example the parameter #S_NO...
Replies
21
Views
7,093
Hi All, is there a way to incorporate SFC with HMI in some way, in order to represent missing conditions for next step. Something similiar...
Replies
0
Views
961
Back
Top Bottom