Recently I had to troubleshoot a kluge of PLC-5/40 ladder logic consisting of latches, interlocks, summations, redundancies, and confusing documentation, not to mention the occasional far-flung rung.

The action is a straightforward SEQUENCE: a mechanism pushes a pallet onto a waiting cart and then retracts. After my latest go round with this mess I decided enough is enough and started seriously investigating SFCs (spare 5/40 on the bench with an 8x8 simulator module) with a view to retrofitting to make this thing intelligible. There are currently no SFCs used in any of the A-B processors in the building and I’ve never dealt with a live one so I’m in uncharted waters here.

I searched the WWW and found lots of articles on the subject. Not surprisingly, this led to more questions:

· One thing I couldn’t pin down was: “At what level of complexity do SFCs come into their own?” That is, is a mere eight steps, with no branches, too trivial a task for an SFC? Does it even matter if the machine becomes more understandable and maintainable as a result of SFCs being included?

· Also, are there things an SFC should not be asked to do? My reading so far hints that they are intended to control machinery yet there are times when a process is sequential but is more oriented toward data manipulation.

· The only way I’ve found to get an SFC active is by adding its program number to the MCP list. There’s a lot of information in the A-B help files but invoking SFCs is not mentioned. Is the MCP list the only way?


Any nuggets of SFC wisdom you’d care to pass along would be appreciated.

Thanks

Don't you just love those ad-hoc "designs"? Latches that don't get un-latched, interlocks from several different program files, complex but redundant or even non-functional branches and rungs....

I've scrubbed a few of these in favour of SFC's and would definitely recommend that you get stuck in and go for it!

SFC's got a bit of a bad rep due to the implementation in the 'classic' PLC5's. The 5/250 was no real improvement. However, the 'new platform' PLC5 implementation is excellent and very powerful.


While an SFC can simplify something that is complex when solely in ladder, the criteria should simply be 'how well does it fit'.I've programmed SFC's with as little as two steps. I've used them for plant control, machine control, sequencing a RSSQL interface, and 'pseudo-MCP' (see below).

I like to think of it this way: all those latches and interlocks disappear to be replaced by the structure of the chart. It is, after all, only ever in one step at a time and there are definite conditions for advancing from one step to another. The actions for each step very often reduce to one or two unconditional OTE's.

There are times when a sequence appears ideally suited at first glance, only to discover that it gets horribly complex when all the "what-if's" are factored in. Breaking the system down to smaller parts may help, but sometimes it's just simpler in ladder. A hybrid approach is often required - e.g. for auto / manual control.


Action files can be ladder or another SFC. Each SFC step can have eight actions - each of which can be another SFC. An SFC with a single simultaneous diverge, a single step in each branch with actions calling other SFC's, and transitions that are always false makes a very useful "pseudo-MCP".

Please keep posting your SFC pros and cons as you "play" there are others of us out there approaching the same bridge. We'd love to hear what you encounter.

YES!

I program lots of sequential systems and do it in ladder. Would love to start trying SFC -- just don't have the time to learn, so I keep doing it the way I've been doing it for years...

This, to me, is the great appeal of SFC programming - you can actually see what the blue blazes is going on!

My experiments so far confirm this. I like!

The 'what-ifs' are a big part of what has made this logic the mess it is. It's almost unavoidable though; pallets get stuck, parts break and fail to operate their sensors, the system is shut down mid-transfer, PE's go out of alignment, etc.

The rev. of the processor available does not support SFCs in the action list.



That tells me I'm not too far off the path. One of my first experiments was a two way transfer (diverter). Once I got it working, with three selective branches, it looked too simple. Add in the fact that over a dozen programs were needed to implement this and I started to wonder if the triviality factor was appearing. 12+ programs notwithstanding, the SFC is a lot easier on the eye.

It looks like I've got a ways to go.

An SFC with a single simultaneous diverge - What is the difference between this and an unadorned step?

and transitions that are always false - Huh? Wouldn't the program just get stuck there?

I can see that this technique could overcome the sixteen program limitation of the native MCPs but I hope I don't have to go there yet. What I'm looking to do at this point is pick some of the more simple but mysteriously programmed sequences and convert only them. To convert all of the sequential parts of some of the programs would definitely bring the 'pseudo MCP' scheme into play.

Thank you very much for your reply!

That's news to me - what rev. do you have? They sometimes refer to them as sub-charts.
I thought all the features were in the NP 5's from day 1.


One step can have a max. of 8 actions. Parallel steps expand the number of parallel actions possible.


Yes - and that's the general idea. All the actions are continuously executed.


You will find that you use a LOT of program files - often with only one or two rungs. But there is no restriction on using any particular action or transition file multiple times throughout your SFC(s).

The newer rev's of the PLC5 that support 2000 files were developed for this reason.

P.S. Don't create unnecessary gaps in your program file numbering, or you may find that all your memory has disappeared into "overhead".

I did create gaps of unused programs because I entered blank steps in the chart, verified the SFC, which dutifully created a program file for each and every step and transition, and then went back and re-referenced to take advantage of the program reuse feature. I guess my technique needs some work.

It would be a useful enhancement to RSLogix5 to cross reference programs used in SFCs the way that memory is cross referenced to ladder rungs.

I found it helpful too to just designate two files for dummies, ie. S(tep) DUMMY and T(ransition) DUMMY because I found that so many of these are used.

I'm pretty sure the processor is series A, rev. A. I'll post tomorrow when I verify this. Do you know if a rev. A can be flashed to rev. B (or even higher)? Flashing a processor is also something that's never been done here. The little I know about it is that if certain precautions aren't taken one can end up with a very expensive doorstop!

Thanks again!

Gee...that sounds familiar. I've got a discrete manufacturing plant, too.

I've looked at SFC's over time. I have 3 problems with the PLC-5 implementation. First, the editor is a pain in the rear. I have a lot of problems getting the diagram just the way I want it. Second, the electricians are utterly confused by them so we run into the old reason that we still use relay logic anyways...clarity.

Third, the question is whether you are trying to implement a state machine or if you have steps operating in parallel. In almost all of my processes, they are sequential. Or at worst, I end up with 2-5 interacting processes, each of which is a separate sequence.

The "traditional" way of doing this aside from some really ugly ladder code is using a sequencer instruction...SQI/SQO. From my experience, these are an even bigger bitch to debug. You essentially have a bunch of state bits toggling on and off almost as phantoms that you can't really trivially debug. Usually the guy before you burned the state diagram too so you have to map it out by hand.

Here is the way I actually do it currently. It is relatively clean and my electricians have no problems troubleshooting it. It is technically a bit "slower" because it uses integers instead of bits, but it is very clear to someone troubleshooting it.

Break your program down into a set of steps. Actually draw it out as a real state diagram. The way I do it is in Visio but you can do it anywhere. Draw one box for each "step" in your sequence. Inside the box, write down what that step is doing. Each box is a state. Draw arrows between the boxes showing how the program moves from one state to the next. On your arrow itself, write down the condition required to cause it to transition to the next state. Usually this is just a bit (limit switch set), a timer output (the timer goes INSIDE the box), or a condition check (tank level>95%). I usually write down both the text and the PLC addresses for reference, with a squiggle (~) representing "NOT" (such as normally closed contacts).

Now number your boxes. I don't care what numbers they use.

Now begin with picking an integer (N7:x) as your sequencer. The integer value equals the numbering you wrote on the boxes.

Your first rung should be something like if this is the first program scan after a power up, then reset the integer to a known safe state (the power up state).

Now start the first rung of your first state. Create a rung TITLE with "State x: Name". In the comment block, list everything inside the box and everything on the outgoing arcs. This basically moves your documentation inside the ladder diagram so that if you ever lose your state diagram, it is still clearly documented. Also, when you look at the "tree" on the left hand pane in RS-Logix 5, your entire state machine will show up there as individual items under the ladder. And you will get one page per state when you print the ladder to a printer.

Inside each rung, you will get code like:
if EQU N7:x y (the state), then do Y (the things inside the box)
...followed by:
if EQU N7:x y (the state) and <conditions> then MOV z N7:x
These correspond to each of the arrows you drew earlier.

When I do these, I also tend to isolate what I call "utility" or low level code from the state machine. I put all that stuff down below under separate rung titles with names like "Pump A", "Rotater B", etc., etc. This separates the state machine from the low level hardware logic.

Debugging gets really simple. You can just check the state variable to go straight to the appropriate piece of code, or the appropriate low level routine. Usually there are a half dozen extra transitions I didn't think of or some screwy error state that I didn't think of that has to be added. I just create another box and add it into what's already there. Adding additional states is relatively easy to do and preserves the "clean" nature of the system.

I've used this successfully on many projects and it has converted the spaghetti crap you described earlier into rock solid systems that are very predictable. At this point the electricians are used to checking 2 things whenever they troubleshoot PLC problems: What state was it in, and what was it doing or not doing? Since they only have to look at what is going on in a single state, the troubleshooting speed is usually dramatically improved.

It is a bit intimidating at first. Having done a few, I'm getting comfortable with it. Granted, my efforts are on the elementary side.


It's unknown how SFCs would go over here so the ladder logic approach you describe below definitely has an appeal.


Ninety nine percent of the PLC code here is about getting a box from point A to point B, I can't think of anything that involves parallel processes.


I looked at those too. A-B's implementation does leave something to be desired.


Doing this in online programming would be an advantage over having to go to program mode to change the SFC layout. They don't like that around here!

Thanks for the outline, I will try this out.

My processor is series A, rev. B. SFCs (subcharts) are not available in the action list until series B.

The biggest hurdle to any paradigm shift is the R:C factor (resistance to change).


If they understand this, I fail to see why they should be utterly confused by a chart with the current step highlighted.

The method Paul describes is quite common and has the advantage of being applicable to just about any model or brand of PLC and can be edited on-line.

The PLC5 SFC chart can't be edited on-line, but the action and transition ladder files can. There is an argument that the chart structure shouldn't need to be edited on-line.


Speaking of state machines - have you ever used (or considered) the PLC5 SDS instruction (Smart Directed Sequencer)? It has some pretty neat (and powerful) features.
...yet another paradigm...