Flow Charts vs. RLL vs. State, yada-yada-yada

D

Thread Starter

David Hermann

I have used "RLL-Plus" (I believe now marketed by Koyo/Automation Direct) ...it seems to combine some of the best of both worlds....flow chart like control of the sequence combined with ladder rungs for the nitty-gritty logical functions--- an area it handles particularly well is "interlocks", which, by virtue of only one section of RLL or code cycling at a time, are easier to implement. Of course a purist might argue that RLL plus is nothing more than a cleverly disguised set of MCR blocks in ladder, with a more "graphical appearance" I wonder why it always has to be an "all-or-nothing at all approach"... why not use the best of everything..... RLL and Charts.... suprised that RLL plus does not gain a wider "look-see" -- David J. Hermann [email protected]
 
R
This may not be an Answer, since there appears to be no single answer out there. However there are several packages out there that are attempting to move to a total IEC 1131 specification that allows for integration of multiple types of program methods within the same processor. Modicon's Concept is one (I think it is the most complete at this time) and Siemens S7 is another. IEC 1131 specification may be misleading since there are several levels of compliance. From only meeting one section to meeting all sections of the specification. These sections include LADDER LOGIC type of programming, State programming, Function block, Sequencing, and other methods (some which look a little like assembler, and some that look more like Pascal). The functionality is coming, and a full implementation of IEC 1131 on a hardware and software level would be great since it would then mean that a single software package could program in multiple languages across multiple hardware platforms. That too is probably not likely since it seems each Mfg. wants us to buy their particular software.
 
B
At 11:47 AM 3/23/2001 -0500, you wrote: >I wonder why it always has to be an "all-or-nothing at all approach"... >why not use the best of everything..... RLL and Charts.... suprised >that RLL plus does not gain a wider "look-see" I also wish that more structured PLC languages would become widely accepted. I just spent many extra hours at a job site yesterday because of using ladder diagrams to implement a sequential program. Frankly, it can be a real pain. I started off with a general plan and structure for my ladder. It worked pretty well. But as features were added on the fly, the structure become more complex. In the end, any small changes ends up potentially affecting other parts of the program. Each change requires hours of re-testing. With this huge mess of combinatorial logic, it is extremely difficult to anticipate the effects of a minor change. I believe that a sequential function chart or some similar type of tool would help tremendously in a situation like this. But the requested SLC500 does not offer much help here. I would like to use a sequential language for machine sequencing and ladder for safety interlocks which must scan continuously. This would save countless hours of work for the manufacturing community. As members of this list, we have the power to influence some real innovations. Any suggestions are welcome. Bill Sturm
 
B

Bruce Durdle

This of course was the objective of the original IEC61131-3 exercise. You can program a sequence using SFC to identify the basic flow of activities, and trigger events or drive outputs using loadder logic or Function Block notation (which are virtually interchangeable anyway). You can also tie in IL (Insruction List) or Structured Text for the tricky stuff. Unfortunately, we are still stuck in the days when, to become an "expert" in PLCs, we attended a Modicon or A-B or Siemens or ... programming course and learnt how to do it their way. They are still doing it "their" way, with one or two exceptions. But Modicon Concept does allow mixing of languages to some extent. The other problem is that the advantages of Function Block, SFCs, etc, as design tools in the process of developing a program are still not appreciated. Once this becomes better accepted, perhaps through end-users insisting on some user-friendly information on their equipment, and it is also appreciated how easy it is to eliminate a fairly complex and error-prone design step (writing ladders) the "higher-level" forms may get better support. So hang on in there - its happening. Bruce.
 
C

Curt Wuollet

It would be great if you could mix languages, each for the kind of problem it's most applicable to. And you should have unfettered access to the internals so you can write those occasional bits and pieces that no one seemed to anticipate. A state language for process control and communications, RLL where it's strongest, graphical stuff where it's strong. And the ability to extend and modify routines when it makes sense. Of course to be able to use these efficiently, you need to know how they really work, it's the things the book doesn't say that you burn time on. And yes, you can make this happen. www.linuxplc.org Regards cww
 
B

Bruce Durdle

The problem is not necessarily the lack of a structured language, but "features added on the fly". One justification for having a formally-approved Functional Spec and logic/sequential diagrams is it makes it easier to insist that any changes are properly approved. Even small changes eventually lead to spaghetti - even with a structured language. Bruce
 
B

Bouchard, James [CPCCA]

Remember the IEC 61131-3 does not require a PLC manufacturer to support all 5 languages in the same PLC. The choice is left to the manufacturer so until they provide all 5 languages then you have to make do with those they do supply. Also one has to consider that manufacturers have product lines for all budgets and one of the ways they do it is by eliminating features. The SLC 5 0x family does not support some of the features found in the PLC 5 x0 series because it costs considerably less. In many cases these discussions boil down to what do you want to pay for and when. At first people will buy a minimal system to get things going or approved and then want to expand it later, Of course when later come around it may be replace the hardware to get the capabilities you need or spend more engineering time to do them in a less capable PLC. James Bouchard
 
R
> I also wish that more structured PLC languages would become widely > accepted. Can't Agree more. Just compare it with modern high level languages. Who tries to program complex programs in Basic using jumps and labels. The result is spagetti code. Using modern object orientated technics to write modular code requires SFC and FBD. By the way I just got my FBD extension from Rockwell for RSLOGIX 5000 and cant wait to get the SFC extension. Having the same for the PLC/SLC range would make my job a hell easier. Best Regards Rolf RG Electrical Engineering & Consulting PO Box 37601, Winnellie NT 0821 Australia Tel: ++61 (0)8 8984 4385 Fax: ++61 (0)8 8984 4001 Mobile: 0417 837 933 Allen Bradley System Integrator Rockwell Strategic Software Provider
 
M

Michael Griffin

At 13:30 26/03/01 -0500, you wrote: <clip> >However there are several packages out there that are attempting >to move to a total IEC 1131 specification that allows for integration of >multiple types of program methods within the same processor. Modicon's >Concept is one (I think it is the most complete at this time) and Siemens >S7 is another. <clip> Unfortunately, Siemens supports some of the languages (such as SFC) by "compiling" the source code in a non-reversible way. That is, unless you have the latest source code version, you may not be able to read the SFC chart on line in the PLC. This makes life very difficult for maintenance and other purposes. The problem is that the S7 system does not support these advanced forms of programming in a native format. They are just "add-ons" to the Step-7 programming software. I think if they supported SFC (or state logic) better, more people would use it. Both families of PLCs in the S7 series are really intended as statement list plus ladder plus function block diagram systems, with rather weak support for anything more advanced. What I did find interesting though, is that although the S7-200 series doesn't offer any means of SFC programming, some of the advanced features are explained in the manual by means of SFC charts. They show what the example will do by means of the SFC, and then illustrate how to implement it in ladder. Using SFC format allowed them to clearly show what the intent of the example was without getting lost in the details. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
I don't know what RLL-PLUS language is, but I believe there is significant difference between Flow Chart (Visio like) and SFC (IEC 1131). I would like to know how popular it is now for the FlowChart language, in USA and EU. To have the advantages of all the languages, B&R (www.br-automation.com) has a programming environment called Automation Studio which includes LAD, IL, ST, SFC and Ansi-C, it is also possible to build your own IEC standard function block. Another language they have called AutomationBasic, which is a super set of ST, has State Machine command, very easy to program sequence flow in structured text form. Regards, Mark
 
I get a little dissapointed reading some of the prior posts in this thread. It is not due to the individuals who post but to the lack of marketing by TI and later Siemens. Almost everyone thinks the 1131 and 1131-like programming packages are a recent thing. In the late 80's Texas Instruments put out a package for their 505 line of PLC's called APT. It has a pre-1131 (in some ways better) form of SFC, ST, and even a form of SL (not officially supported). TI had a hard time selling it due to the dominance of ladder in the marketplace. The SFC portion could include ST inside the steps (not just assignments like current packages) ST programs have a limited function block-like feel with ability for generic inputs and outputs so the code could be re-used. Devices in the field were represented by devices in the program with verbs (methods) like auto, start, open etc. Program structure could be generic at a massive level allowing mass copying of whole a whole process (like a boiler) with only having to change the I/O to the unit. All in all a very powerful and easy to use package. When Siemens bought out the TI line of PLC's all serious development on the package stopped. New PLC's were supported etc. , but the program was never ported to windows. This was, in my opinion, done to drive the current user base to the newer S7 line. Marketing of APT was virtually nil, to everyone's disadvantage. If you can find someone who has a copy, take a look at it. Siemens had a package that was 13+ years ahead of its time and failed to see the importance of it.
 
P

Paul Gobeille

Bill,
All of the Process Control Engineers who must use PLC's will yell "HELL YA" when they read your reply.
Good Job
Paul Gobeille
 
B
Yes, APT was a very good programming tool. It is hard to understand why a compiler was not written for the new PLCs. Siemens does have a new flowchart programming tool, S7 Charts, that works with their S7 PLCs. But, be warned, there is at least one huge bug in the software. The debug feature that allows the chart to be viewed does not work for sub charts below the 3rd or 4th level of nesting. Siemens is aware of the problem and has no plans for fixing it at this time. How's that for support? We have used TI and Siemens for many years and are now very disappointed in the ways products have been discontinued or supported. Products seem to be constantly changing with little regard for upgrades or compatiblity with their other equipment.
 
Top