Sequential Function Charts: WHEN INDICATED?

Recently I had to troubleshoot a PLC-5/40 ladder logic kluge 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. One thing I couldn’t pin down though 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?

On a side note: 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 directly mentioned (or, it might have been and I just missed it). Is the MCP list the only way?

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

Thanks

Sorry, I have never used SFCs. I am sure they are useful in many situations.

OK, thanks. Got bump out of it tho'.

SFCs are graphical state machines

SFCs provide a graphical way of organizing a state machine. State machines are used all the time when controlling machinery because most machine control can be divided in to steps where the machine must do something ( the step ) and wait for some condition to be met before going on to the next step ( the transition ) . If you can break down your machine control application into a series of steps and transitions then SFCs are for you.

Our motion controller uses steps and links which is about the same as SFC steps and transitions. The main reason we chose this method of programming is that motion control has a lot of 'do this and wait for that' type of programming. Another reason why we like state machine programming is that it is relatively efficient compared to ladder programming where all the ladder gets scanned all the time. A good state machine or SFC implementation should only need to check the conditions that would cause the state machine to change state or step.

SFCs are also easy to debug. When the program hangs up it is easy to see exactly where the problem is because it is easy to see which state is active and what conditions ( transitions ) are not met to allow the state machine to go to the next step.

It is also possible to have multiple SFCs running at the same time. This is effectively multi-tasking. This muli-tasking is handy when multiple SFCs need to run asynchronously.

I think that the ideal way to motion control/machine programming is SFCs with ST to define operations in the steps and transitions.

Note, SFCs and state machines are good for the machine sequencing. Operator inputs should still be polled using ladder or ST.

I thought this looked familiar

We discussed this here

So, have you made any progress in your exploration of SFC's?

Peter Nachtwey said:

SFCs are also easy to debug. When the program hangs up it is easy to see exactly where the problem is because it is easy to see which state is active and what conditions ( transitions ) are not met to allow the state machine to go to the next step.

Click to expand...

This is my main reason for looking into SFCs - the despair became too great last time I confronted the logic mentioned in the initial post.

Peter Nachtwey said:

I think that the ideal way to motion control/machine programming is SFCs with ST to define operations in the steps and transitions.

Click to expand...

That's a ways off, this is a ladder logic organization. Shoot, just the appearance of the first SFC is sure to cause a bit of a stir.

Thank you for your reply.

Gerry said:

We discussed this here?

Click to expand...

Yes, I posted to both forums at the same time. The post here must have hit at a bad time because it just faded away. I'd be interested to know how Lancie1 found it.

Gerry said:

So, have you made any progress in your exploration of SFC's?

Click to expand...

Some. I have yet to put one into a live machine (conveyor system) but I've been converting likely candidates and running them on the bench to learn my way around. Found a bunch of things that don't work and I've discovered a few tricks with step actions to reduce the number of steps/transitions needed.

One of the conversions runs a turntable which accepts loads from two positions. After I got it working a comparison showed that while the job was done with about fourteen (not terribly complex) ladder rungs the SFC version needed nearly thirty programs to accomplish the same thing. Of course, that logic was written by a more capable programmer. I think in that case the original logic is more efficient and just as clear as an SFC would be.

Maybe I put too much hope in the WWW but, I Googled SFCs and checked over one hundred links looking for something like "SFCs for dummies". There's a ton of information out there but precious little in the way of tutorials. Also, nothing like 'hints and tips' exists that I could find.

The other thing I've found out is that bringing this online is going to be tricky. I've got to have the SFC tie into the existing logic and yet be able to switch over to with the original logic at will. This is important because it's a 3-shift operation and others who haven't seen SFCs would be left hanging. And then I'd be hanged when I did show up!