SFC Programming

L

Thread Starter

Len Klochek

We teach IEC1131-3 and spend a great deal of time on SFC programming. A bit of a debate is taking place here about the adoption of SFC.

Would someone offer some opinion as to the penetration into the North American market of SFC programming.

Will it eventually become as or more prevelent than ladder logic. There seems to be a greater acceptance in Europe - possibly because of the
education levels of those writing and supporting PLC programs.

I would appreciate any comments.

Len Klochek
Seneca College
Toronto
 
B

Bob Peterson

My guess is that very little (probably less then 5%) of the PLC code in use today uses SFC. The main reason is that it does certain simple things very easily, but gives you little advantage in most real life cases, since most systems are not really sequential in nature. SFC advocates like to point out how easy it is to do a traffic light in SFC versus RLL. The fact is, that its just as easy, and far more readable for most of us (and most end users' electricians), to adjust your RLL code a bit, and create an SFC like structure but in straight RLL. By doing so, you can create the same logic structure without the SFC overhead.

A traffic light is one of the things the SFC advocates like to use as an example, but the fact is, that by starting out with all the possible
conditions, numbering them and creating a seperate number in a register, you can create an SFC like structure (more state logic then SFC though) w/o the confusing transitions and multiple intsances of the same outputs that SFC
uses.

For instance:

(Using AB register addressing)

N7:0

0 = green
1 = yellow
2 = red
3 = left arrow

All you have to do is manipulate the register value to get the proper value in it to control the light. If you tried to do this with coils, contacts, and latches, it could be done, but it would be confusing, and really difficult to follow.

Think of it as another tool, but also remember that someone has to maintain these systems after they are turned over to the end user. The "educated" guy that programmed it won't be around to fix the inevitable minor problems,
changes, and reconfigurations that inevitably have to occur over time in any system of any signifigant size. The critical issue is not the few bux saved up front but how much is wasted in lost production over the life span of the
system using a tool that may not be real obvious to those trying to maintain it.

Bob Peterson
 
D
Len,

I believe that the acceptance of SFC in the US is slowed by the inability to convert code from systems that support SFC to platforms that do not. (ie) taking PLC5 code and converting it to SLC500 platform, can't do it!
The other reason is that plant personnel are more familiar with ladder logic and this means less calls because maintenance guys understand it.
Let me say that I like SFC programming, but these are both pretty big reasons not to use it.

Dale
 
J
Don't give up! But don't expect to replace ladder logic either!

Given several conditions, I believe SFC can gain some ground. First, SFC must be made available, along with ladder diagrams (and I would
hope function block diagrams)in the major PLC programming software packages. Second, the engineers and maintenance people must be educated
in the use and benefits of SFC. Then, in time, it should become more familiar and accepted.

I would like to be able to choose the language that best fits the application in each section of a program. That would be a combination of
all the IEC languages. We have a lot of resistance to anything other than ladder, but I hope the educators and manufacturers have the
foresight to persevere!
 
J

Johan Bengtsson

Ok, this is not an answer to your question - I just want to point out that they don't solve the same problem - Ie the right tool for the job discussion.

Ok, ladder can solve everything you can do in SFC. SFC probably can solve most of what you can do in ladder - but definitely not always in a nice and elegant way, and there is a gray zone where both tools would be good for solving.

Both languages are relatively easy to understand and to work with (I am not commenting the different programming tools, but the languages themself) and if each is applied where it is best at solving the particular problem then they are easy to troubleshoot and all that.

I think it will adopt (ok, I am sitting in europe so I should probably shut my mouth and listen instead...) but if the ones trying to push it into place will overdo their work then if can easily fail. Using SFC on a problem where it don't fit is a nightmare - it is like trying to put a nail in a concrete wall and the only tool you have is a small screwdriver. You might succeed - eventually.


/Johan Bengtsson

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
B

Bruce Durdle

Hi Len,

A couple of comments that are a bit off to one side ...

I'm in a similar situation - teaching basic PLC applications to a wide mix of people from school leavers to 5+ years electricians to persons verging on geekhood.

Regardless of background (or final programming formats to be used) SFC's or something like them generally go down well as a means of helping to analyse a problem into some sort of order. It's the old question once they get past the mechanics of entering code into an AB or Modiscon or Siemens or ... how do you know what code you need to enter? SFCs provide a very simple and useful tool for converting an application into something that can be turned into ladder logic, if that is the final form to be used.

I've also recently been involved with a group of electricians on a site which has just upgraded from Modicon 884s to Quantum PLCs running Concept - just imported the 984 LL software from the old system and are now extending the software using the other IEC formats available. None of the electricians have any specific computer-type training (I'm putting them though a basic instrumentation qualification at the tradesman level). Most of the ones who have had nvolvement with the 61131-3 formats are quite enthusiastic after initial concerns about these strange looking programs.

So there are advantages about teaching SFCs even if they are not yet available for every range of PLC.

Cheers,

Bruce.
 
D

Donald Pittendrigh

Hi All

I say long live SFC, Ladder was used to show the arrangements of contacts in old relay drawings and it was imminently suited to this purpose. If you are not able to handle the concepts of and and or gates then there is so very much code which is used in modern PLC's which you will not appreciate, that it is better you change your occupation. SFC is more readable and so much more compact a means of representation there is just no reason for the use of ladder.

Regards
Donald Pittendrigh
 
R

Ronald Nijssen

Some ideas I would like to test on the audience involved in this discussion. I have been a PLC programmer for several years of my 15 year carreer. I also am familiair with other so named high-level languages like VB, C and C++ In the past, with limitations in processor speed and memory, it was important to boil a problem down to the bare instructions needed, or to use a limited set of instructions (e.g. only IC's with NAND's available) In parallel, lots of people could read Wiring diagrams and liked to mimic code in such a way, RLL was born Both these approaches to converting an abstract problem into something that works are beside the real problem, and you need qualified engineers to make an effective conversion take place. After they do their work, you must rely on that engineers ability to document his work to be able to reproduce what he has done. In my opinion, a problem should be presented in a way that illustrates the problem, not the abstraction of the underlying things, a set of IC's or a PLC. Of course these were and are the things we solve the problem with but that doesn't have to stay that way. (who is still using Carnot to design his PLC program?) Any control problem is a combination of Functions, State Machines, Exceptions and Interlocks. They are blended together to cover all aspects of the control problem. Definitely a SFC is not fit to implement an Interlock, but there are 10 ways to use Ladder to create a State Machine, somebody who wants to understand what is implied in the code must first know what way of implementing is used to understand the implementation, this is bad because it makes the next-user rely on the previous without guarantee of availability of that previous users knowledge in any form. Therefore, i think that Ladder is not the best tool to implement a State machine. Given that tools are being developed to automatically create information that describes a problem (e.g. spec-soft) it is logical to drive towards an agreement on programming languages that are best fit to implement specific aspects of the problem, IEC 1131-3 is a good step towards this idea. The biggest hurdle is the classical issue, the advantage is not with the conception, but afterwards, no end-user can qualify the cost involved in writing code and creating good documentation vs. the use of another language, nor can they qualify how much money will be needed to modify or extend an application based on the language used. However, PLC's are very well capable of using various languages, integrated engineering suites with multiple languages are becoming available, the lifetime of an application exceeds the period the original engineering knowledge is available, the code applied for specific parts of a control problem, created with other languages than RLL, is much more self-documenting, all these aspects should drive towards the introduction of higher level languages

Regards
Ronald
 
J

James Fountas

Hi.

JUST THE FACTS

My experience is in New England, mostly Massachusetts. I have done a number of projects. I have seen SFC adopted for two projects. In both cases it was because the systems integrator decided to use SFC and not because the end user requested it. In one of those cases the end user decided to use ladder logic for their next addition.

Less then 10% of what I have encountered has been SFC. More then 50% has been ladder logic. The balance has included a variety hardware programming methods that including binary, Boolean, Basic, C, and DAPL.

I am seeing a higher penetration of PC based control then I am of SFC penetration.

OPINION 1

There is nothing wrong with either ladder logic or SFC depending on your needs. I prefer ladder logic. Ladder logic converts to Boolean easily.

OPINION 2

I disagree with your opinion that "possibly because of the education levels of those writing and supporting PLC programs." I have seen bad code independent of the point of origin and education. I have also seen very good independent
of the point of origin and education.

OPINION 3

I see the driving force for change being regulations and public relations.

 
M

Michael Griffin

I have found SFC to be a good way to analyse a problem, even if the final implementation is in ladder. It is also a good addition to the documention of the program, since it provides a clear overview to someone who is not familiar with the machine.

I think the problem is not with SFC itself, but with how it has been implemented in typical programming software. The systems I have seen (I haven't surveyed the entire market) have been oriented towards full time programmers, not end customers. Apparently the intention was to sell it to programmers who would then ram it down their customers' throats. Some brands (without singling out any one in particular) are quite explicit in calling SFC an "engineering tool" which is not intended to serve the end customer. I don't think this has been a very successful strategy.

In a market where the customer can dictate what they are prepared to accept,
SFC would be more successful if the implementations were directed towards the
end customers' needs. The end customer could then demand that it be used. When you ask whether SFC will be accepted, the first question should be who is doing the accepting, and what are the benefits to them.

To perhaps extend an analogy, the developers of many SFC packages have been
developing something comparable to a compiler, when the market is looking for something comparable to a spreadsheet. Both can be used to create something which will add numbers together, but if your market is accountants then the spreadsheet is what is going to sell.

In discussing the use of SFCs we should keep in mind that there are two sides to the question. The first is program design and analysis, the second is code implementation. If you use an SFC for the former (design), you have captured many of the benefits of this methodology even without using it for the latter (code implementation).
Much of what is called "programming" has nothing to do with writing the program. It is rather, deciding what the machine should do and when it should do it. It is easy to draw an SFC using boxes and lines in Word, or even with paper and pencil. Translating this into ladder is usually straightforward.

Some PLCs offer instructions which allow you to implement SFC style code (in the sense of a series of steps and transitions), even if it appears as a series of ladder rungs rather than boxes and lines. If I am using these instructions in the way they are intended, is my program written in SFC or not? This could be more a question of semantics than any practical difference.


--

************************
Michael Griffin
London, Ont. Canada
************************
 
R
And now for something completely different - in "another" arena of programming, where PLC's don't exist and things like object orientation, C++, and UML are more abundant, it struck me that UML's action diagrams resemble SFC's a lot, although action diagrams are much simpler than SFC's and thus hardly used. I have seen $10 million machines designed with action diagrams, for the simple reason that they can represent parallelism and concurrency very easily. This is also the case with SFC's, but unfortunately outside the PLC world they are hardly known. Perhaps both worlds learn will start to learn from each other in the near future...

Rob Hulsebos
 
D

David Bergeron, P.E.

SFC is not meant to replace ladder or any other language. SFC cannot stand alone. SFC is a higher level language that allows a control engineer to create a flowchart of steps and transitions. The individual steps and transitions still use the lower level languages like Ladder Logic, Instruction List, and Structured Text.

When your program must perform a specific sequence of steps (do A then B then C, etc...), SFC is the best. Sequential logic is what SFC was made for and very straigt forward to troubleshoot and understand.

If you're doing continuous control, there's no reason to use SFC.

David Bergeron, P.E.
 
M
The main benefit of Grafcet (SFC) is as a means of specifying sequences. At this it is unbeatable. As a programming language it is passable but will never replace ladder logic and is not intended to.

Although it is possible to program low level functions, for example a star-delta starter, in SFC a ladder logic or instruction list implementation is much more concise and easier to program.

Most of the available implementations of SFC as a language are fairly poor.

The best product that I have used for SFCs is CADEPA from Famic. This product uses the SFC to 'specify' the project and then generates ladder from the design once complete and verified.

I always use SFC in my projects when it is appropriate (they are always implemented in ladder mind you). SFC is merely another tool in the Engineers arsenal of tools. You wouldn't stop using a screw driver, just because you
discovered a hammer.
 
G
Dear Donald: What do you think that ladder logic is but " and & or & not & if gates? It is just the other way of representing a solution. I agree
with the gentleman that said that each has its place and area of expertise. When some other language comes out what will be your opinion of
FSC?
Gord
Edmonton Canada
 
D

Donald Pittendrigh

Hi Pierre & others

But for a hyphen that would be 2 words and I am not even sure the hyphen should be there. The point is taken however the real issue is the question of whether an inappropriate representation of the program makes the end user's life easier.

I mean is it really sensible to represent the addition of 2 numbers or a block call or a rising edge network even, in ladder? I don't think so and feel rather strongly that re-education is required.

I personally don't have any trouble dealing with any of the IEC conepts of programming, it is not for my convenience.

Regards
Donald Pittendrigh
 
L
Hi All:

My experience with teaching students C, C++, VB, and IEC61131-3 is that they find SFC a natural language for programming applications that can be represented as a series of states. The combinational / interlocking logic portion of the
application is handled using either transition FBDs,an FBD section, or ladder logic section. On a recent term test they programmed an injection molding machine application. All agreed that with SFC, the program can be designed in a fraction of the time that ladder would have taken them. It is also very easy to follow / understand / troubleshoot a state type application when implemented in SFC.

These are students that have been exposed in equal proportions to ladder, FBD, ST, IL, and SFC of IEC61131-3.

Len Klochek
 
D

Donald Pittendrigh

Hi All

Grafcet is very definitely beatable, take a look at HiGraph from Siemens or at Think and do programming in Visio.

Regards
Donald Pittendrigh
 
M
As far as I am aware HiGraph is Grafcet (which is the original name pre-1131 for SFC). I don't know about Think and Do but if it is based on flow chart (like steeplechase) or other forms of state chart, I disagree.

Grafcet/SFC is based on the Pert chart and has one of the simplest syntax's around. It is scan independant and is very good at modelling sequences.
 
P

Pierre Desrochers

Donald,

"there is just no reason for the use of ladder"

Just one word "End-User"

Pierre
Montreal, Canada
 
M
Another word (or three).

Fitness for purpose.

SFC cannot do everything that Ladder can, and was never intended to.

If you want just one and only one language, forget it.

SFC is good at what it does and so is ladder.

While the other four languages are to an extent interchangable, SFC is meant for different things.

The argument about ladder logic has been going on since the mid 80's (or longer). It'll run for a few more years yet.
 
Top