Usage of Flow Chart language for PLC's

R

Thread Starter

Ronald Nijssen

Hello List, I have several years in programming both PLC's and System Applications (C/C++). For the PLC's I have used all IEC 1131 languages and in the past Assembler, STL and LAD for older PLC's The last few years several PC-Based control vendors are promoting Flow Charts. I have tried some and have mixed feelings, what do you think Is Flow charting good for Interlocking?, State Machines? Step programs? What do you think of Decisions instead of Transitions in the classic language "SFC" are they good or clumsy? Can a PLC program be created with Flow Chart only or should Flow Chart only be used for specific parts of the program? Thanks, Ronald Nijssen
 
S

Scott Whitlock

> Can a PLC program be created with Flow Chart > only or should Flow Chart only be used > for specific parts of the program? > > Thanks, > Ronald Nijssen Hi, I've recently done a project with the SteepleChase VLC controller. This is primarily a flow charting program, but also has RLL (Relay Ladder Logic). Unfortunately, the customer's Spec required the use of only flow charting. I think this was to keep people from just importing their old RLL code from PLC5 into SteepleChase. My enlightened view is that flow charts are *excellent* for sequence logic. For instance, if you want to turn on a solenoid, wait for a prox, and then trigger an action, the flow charting is great. You never have to worry about the action being triggered in any other case, because it only happens when the flow chart executes. However, there were times that I sincerely missed being able to, say, turn a light on when A, B, and C conditions were true. Combinational logic is easily expressed in RLL, but it's harder to describe in flow charts. In the end, I had to have a single flowchart that branched at the beginning and ran through a series of conditions every scan, and set outputs based on those decisions. That's the only way I could guarantee that these outputs would be updated all the time, no matter where I was in the flowchart. If I were to do it again, I would certainly ask to use both flowcharts and RLL. State machines and sequence are better expressed in flowcharts, but combinational logic is much easier to understand and troubleshoot in RLL. Just my 2 cents... - Scott
 
J
Having worked for many years with SFCs I can say without a doubt you can build a reasonable control solution without SFCs but if SFCs or flowcharts are all you use then you will have an incomprehensible mess. SFC/Flowcharts are good supervisors. Control systems need to be able to respond to asyncronous events. Ladder or any other event based languages are always be needed to work hand in hand with sequential languages. You can work around the lack of an event based language but the program will become a mess to troubleshoot. Usually SFC/Flowcharts consume lots of memory as well, so the plc/pc controller better be big and fast.
 
R

Ranjan Acharya

You have opened a tin / can of worms with this question. I should warn you what we have experienced: Flow chart believers will tell you that flow charts will do everything SFCs can do and better whereas SFC believers will tell you the opposite. Sort of a North America versus everyone else approach too since flow charting is not (as far as I am aware) been added to IEC 61131.3. You will have to decide for yourself which is the best approach.
 
A

albert avidor

I use only flow chart technique for programming PLC's. It is relatively easy for sequential programming. Telekemecanique-Modicon PLC,s have a special software to do this. It is called Graphcet. Also you can prepare your program in graphcet then you can translate to ladder. You will save a lot of lines Albert Avidor
 
J

James Ingraham

Every language has its ups and downs. I personally much prefer flow charts to ladder logic, but I came from a computer science background. The people I know who came from an electrical / PLC background much prefer ladder logic. Go figure. One point that has been made by several others; flow charts are much better for sequences. I don't have the same issues others had with logic, though. To each his own. -James
 
J
I have been using Opto22 controllers for several years, which are programmed exclusively in flow charts. Flow charts definitely require a different approach to programming than ladder logic, but they can be great about documentation. A flow chart is naturally organized in logical flow, and naming the blocks is often the only comments required. Of course, a poorly-written program in any language will be difficult to understand! Any language can be used to write almost any type of program, but flow charts will be easier than most to understand later. Jeff
 
G

Gilles Allard

Each PLC language has his own strengths and weakness and two different applications may require two different languages. IEC61131 defines 6 different languages (SFC, IL, ST, LD, FBD and FCL). Siemens offer 8 (or is it 9?) for the S7-400 PLC. AB offer 2 for Controllogix (a 3rd is being prepared) etc SFC is great for sequential actions but poor for unplanned events. IL is lean and mean and offers lot of performance but no frills. ST is great for numerical works or for specialized algorithms. LD (ladder) is great to debug combinatorial logic and poor for everything else. FBD is good for continuous processes (process control). FCL (fuzzy logic) is good for ??? I would use LD for a conveyor but not for a palettizer. If both functions have to be in the same PLC, then a single-language approach can only be a compromise. If you enable mixing of two (or more) languages in the same PLC then you can benefit from the strength of each one. The important point is that all these languages must be able to interact and cooperate easily. They should all offer compatible data representation and the development tool should integrate all of them in a seamlessly fashion (I'm dreaming). For example, a cross-reference list should integrate all usages (whatever the language is). As an analogy, a journeyman always carry a pretty large set of tools in his box; he knows he will be more efficient if he (she) use the appropriate tool. What would you think about an electrician who only have a flat blade screwdriver in his box? What would you think if he (she) tell you that it would cost too much time to learn how to use other ones? Here is an example of a program we recently designed. 10% of SFC 10% of IL 80% of LD All the code related to I/Os is in LD while the mundane logic that would consumes most of CPU cycles is optimized with IL. Complex sequences are easier to debug and maintain if we look at them with the SFC debugger. I'm very aware of the problem associated to training every electrician to understand many languages; this is the main argument used by single-language proponents. PLC technology is now a specialty and requires specialists. I would not care if a PLC technician does not have any knowledge about replacing heater packs on a motor starter. If he knows, fine but his (her) main knowledge should be PLC programming, data communication and electronics. Gilles
 
>I'm very aware of the problem associated to training every electrician to >understand many languages; this is the main argument used by single-language >proponents. PLC technology is now a specialty and requires specialists. I >would not care if a PLC technician does not have any knowledge about >replacing heater packs on a motor starter. If he knows, fine but his (her) >main knowledge should be PLC programming, data communication and >electronics. > >Gilles Hello list, I do subscribe to what Gilles wrote. Today's "PLC programming" goes toward pure "programming". If yesterday the knowledge of limit-switches-ware and RS232 was enough, today we must deal with fieldbuses, industrial Ethernet, HMI applications, intelligent devices, etc. Wrestling with several O.S. (from CPM to Win2000 passing thru OS/2, DOS and Win9.x ) is another pretty difficult sport. Probably the times when machinery were wired and programmed by the same person are definitely gone: the desperate machinery manufacturers I sometime encounter are a prove of it. Ladder, IL or ST shouldn't be a matter of philosofy or religion. Like any other tool, each language is good to solve some problems or perhaps become a problem itself if used in the wrong place. Let the hammer deal with nails, not the saw... best regards Luca Gallina [email protected]
 
G
I agree with what Scott said(the first reply above). I like to use ladder logic for boolean logic combinations. I like to use flow charts for sequential operations. In addition, I like flowcharts for analog signals, math, PID, etc. I think Ladders were originally made for relay replacement and they excel in that area. I think a combination of the two would be an excellent way to go. Gerry
 
K

Kate Cornwall

>You can work around the lack of an event based language but the program >will become a mess to troubleshoot. Wrong. You can work around the lack of state with an event based language, but the program will become a mess to troubleshoot.
 
M

Michael Griffin

At 16:38 16/03/01 +0100, Luca Gallina wrote: <clip> >I do subscribe what Gilles wrote. Today's "PLC programming" goes toward >pure "programming". If yesterday the knowledge of limit-switches-ware and >RS232 was enough, today we must deal with fieldbuses, industrial Ethernet, >HMI applications, intelligent devices, etc. Perhaps we should look at this problem slightly differently. You mentioned "pure programming". I am reminded of once having read that programming languages exist for the benefit of people to read, not for the benefit of the microprocessor. A programming language should be judged on how well it enables a programmer's intent to be communicated to someone else. That someone else need not necessarily be another programmer - it could be someone who is reading the program to to try discover why a machine is not behaving itself. The best tool for communicating this intent depends upon the nature of what is being communicated. In addition to this, some tools facilitate clearer thinking about the original problem. It is very easy to write complex programs - people do it all the time. Writing a *simple* program is what takes a good deal of thought and planning. Programming languages or notations which assist in thought and in planning of a particular problem increase the likelihood you will end up with a better program. What this means is that just because a particular language or notation *could* solve a particular problem does not mean that it *should* be used to solve that problem. Having said all that, I have a question of my own. Can anyone state any clear advantages or disadvantages of "flow charts" versus "grafcet"? My impression of flow charts as used in PLC type programming is they are a tool which falls somewhere between ladder (or instruction list) and grafcet or state languages in degree of abstraction. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
V

Vladimir Zyubin

Hello List, Yes, but relay was originally made to implement algorithms. To state "Ladders excel in" we ought to show relay is the best solution to implement algorithm. On Tuesday, March 20, 2001, 2:53:08 AM, List Management Account <[email protected]> wrote: LMA> ------------Forwarded message-------- LMA> From: Gerald Moore <[email protected]> [...] LMA> I think Ladders were originally made for relay replacement and they excel in LMA> that area. [...] -- Best regards, Vladimir
 
L
To the List::: I have been predicting the death of Relay Ladder Logic for nineteen years and three careers. I'm starting to wonder if I might be wrong about that. &lt;G> The comments in this thread have been intriguing, and I'd like to kick the discussion up another notch. I have noted the complete market failure of alternative languages for automation in North America. I cheered the failure of FORTH, but I thought Sequential Function Charts and Structured Text should have done better here, and I have always hoped for success for true high level languages and some type of flow diagram. I would choose SFCs with embedded RLL for most of the machines I have ever worked on, but here is my personal experience: On the one project where I got my integrator to use that strategy, the end user insisted that the project be recoded to all RLL. The market has clearly decided that RLL is going to be used for fundamental machine control, and higher level functions are migrating to the now omnipresent PC. Yet, RLL remains clumsy for algorithms and (IMHO) motion control. And yet, it gets used clumsily. Meanwhile, increasingly smart components on device level networks are going to require a new point of view. If a pushbutton box and a motor starter are going to take care of each other, how should that set of objects be integrated into a system design by some ubersoftware? I can envision a system made up of things you can buy now, with no software that truly organizes the result from the top down. (Yes, there are soft PLCs, and I sell a lot of them. The subject is languages.) RLL sems to have won the market at the bottom end. What is working for the Listers at the network level? Larry Lawver Rexel / Central Florida
 
Larry Lawver Rexel,
You stated that you sell a lot of Soft PLC. We are looking at them and was wondering what your experiences were. What brand. What type of machines/control?
Any dependability issues?
Thanks
Mike Huff
 
For me SFC is not a language that can be compared to IL, ST, ladder... SFC is essentially a good tool allowing to structure properly and efficently sequential applications (including parallelism).
The details (tests, actions) have to be filled in the languages listed above.
Another great advantage of the SFC is the fact that the CPU scans only the code of the active steps and transitions allowing a better performance.
 
J

Jerold E. Caldwell

Like you, I also have several years in automation and control systems. A PLC is simply a CPU that makes decisions based on a simple program that is defined within its cache and of course understood by the end user (i.e the programmer).

The PLC is in essence defined by its principle program and also LIMITED by its principle program (Root Program). However, in order for a vast majority of technicians to understand programming it is easier to remain with a STANDARDIZED Procedure "i.e. Ladder Logic". It will be difficult for any other language to come to be if the institutions are basically teaching "Ladder Logic". Ladder Logic has one problem, it is limited to three to four career fields. Electrical Engineer, Electronics, Electricians, and etc. HOWEVER, FLOW CHARTS are taught over almost ALL career fields. Doctors, nurses, lawyers, even PE instructors have learned FLOW Charts. The embedded design to the Flow Chart "IE the ladder logic" becomes an invisble program running in the background. Its a beautiful marketing technique if you think about it. The future is anyone will be able to program a PLC. The brainiacs like you and I are going to go EMBEDDED. Food for thought.
 
T

Tyrone Fields

I just want to put in my small amount of experience on the subject. I have two machines in the plant that use a flow charting program called Think N Do. It is designed by Entivity. As for dependability, the program is as dependable as any RLL program I have used. However, to run this program You have to use a windows based PC. Then you bring in a whole new set of problems. Now you have all the quarks and issues that windows has, (IE. locking up etc.). I personally feel that there is less issues with the RLL programs.
 
J

Jerold Caldwell

So it appears we all agree that the primary reason for programming language is for the benefit of the operator. One could argue that the language being utilized to program the control is truly nothing more than a "Configuration Utility" more than true "embedded design programming language". In truth we simply configure the software in which the hardware engineer, the embedded design engineer, and the information technologist have devised for interface with the control. Its important to remember that the language in which they utilize may be Fortran, Pascal, C, C++, Basic, Basic A, and many others which in themselves are nothing more than another configuration utility for programs like cuple which directly interface with the microprocessor itself. The configuration utility in which the true programmer has made is in itself a combination of multiple communication protocols in order to interface with the microprocessor and at the same time make it less complicated for the end-user "the configurer" to utilize.

I agree with many of your view points however I especially appreciated one comment made "the configuration utility" should be rated on its ability to interface with multiple users. The less "specialized" the "configuration utility" or the use of design specific "protocols", the wider the range of individuals it can interface with. Thus "flow charts" which are used and taught through out all career fields would seem to be a practical "Configuration Utility" (ie programming protocol). We truly are not programmers to the device itself but we do configure the products to perform specific applications in which we are the innovators of.

Programming Languages or Protocols, which are design specific, are made for "Proprietary" reasons. They are deliberately manufactured and are intended for a select audience. The results of a non-standardized protocol are that of the manufacturer in order to secure their place within a given vertical market.

Hats off to you, great discussion gentlemen and may God Bless You…
 
Top