Comparative study of various programming methods

  • Thread starter McCarthy William
  • Start date
M

Thread Starter

McCarthy William

Hello all, I am a final year Mechanical Engineering degree student in Ireland and my final year project involves rating various methods of PLC programming with each other and determining which methods are of most use
for which applications and detailing the pros and cons of each method. I am using Siemens Step 7 and using the following languages; Ladder, STL, SFC, Graph and Hi-Graph. Does anyone have any tips or advice for me on any aspect of the project.

Thanks in advance,
William
 
G

Gilles Allard

Hi William!
From my north-american understanding, STL is very popular in Europe while LAD (ladder) is more popular in America. I do not have any official statistics.

The trend is toward SFC (Graph) and SCL and CFB

Gilles
 
S

Simone Stefani

I am a 10 year PLC programmer, and since 1997 I'm using Siemens S7 family. Normally I develope my applications using STEP by STEP method. It is very useful if you need to describe a finite states AUTOMA

Simone Stefani
Automation Dep.
Romaco Zanchetta
Tel. +39-(0)583-2171
Fax +39-(0)583-217317
e mail: [email protected]
 
T

Tim O'Reardon

Hello,

I'm a maintenance support engineer for a Vehicle Manufacturer in Luton, England. At our plant we use various types of PLCs (GE Fanuc, Modicon, Omron, AB etc.) with a variety of programming languages.

In my experience most people who support PLCs have come through from being electricians to playing with PLCs. Since their background is reading electrical drawings and understanding the concept of coils, contacts, normally open and normally closed, Ladder Logic is normally the best way for them to understand the sequence.

More indepth languages like ST (Structured Text), SFC (Standard Flow Chart) SL (Statement List or boolean logic as it is sometimes called) and other non-literal forms, can cause problems to people who like to see what is happening on the screen as it happens like Ladder Logic can show.

The flip side to this, is that programmers and software writers who are happy with non Ladder Logic forms could be forced to write their software so that the maintenance personnel who have ultimately have to look after it can understand it. Also software programmers can have a job getting their head round the concept of coils and contacts also.

I've eventually managed to get my head round both types, but trying to converse with two different ways of working and trying to work with contractors and our maintenance guys can give me and my colleagues headaches.

Hope this helps

Tim O'Reardon
 
R
My 2C!

Languages that try to improve on ladder logic tend to get the worst of both worlds. Maintence people and electricians to not warm to them, yet experienced programmers do not understand them
any more than ladder logic, because they do not see things in terms of relays and coils.

I find most things can be done in ladder logic, for example, I recently implemented part of the OMRON serial comms protocol on an S7200 using ladder logic. Looking at the assembler of the resultant code I was reasonably impressed, one could have made little improvement.

Of course none of these methods are particularly good for structured programming, which is essential for complex tasks.

So my rule is

1) Use ladder

2) Use assembler where optimisation is essential

3) For complex/large tasks give the job to a real programmer and let him/her do it in C.

What would be cute in the PLC world would be a ladder logic programming environment were buildings blocks (such as a PID loop) could be user defined in terms of I/O, and the environment would generate a C wrapper, or a C++ object.

User C code, as well as having it's own namespace, would also be able to access PLC namespace as globals, and C function pointers could be assigned to interupt/event handlers.

That way specialist programmers could implement
critical elements of a system or extend standard
functionality of PLC's, and electricians could easily understand how to modify behaviour.

Does something like this exist? I mean for everyday PLC's, I know I could do things with e.g. a PC+PLC+PRODAVE+WinCC etc etc, but that is just exaggerated. So are high end PLC systems.
 
B

Bruce Durdle

And so they should!!

Programming is an activity that will take a couple of months - the operation and maintenance phases could well last for over 10 years.

Whern the programmer has long gone, the poor old site electrician is the one who has to get out of bed at 3 am and sort out why the system doesn't
work.

Bruce
 
Dear William

Most of the PLC's allow following all the standard ISO method of programming. But in my opinion each method has its own purpose.
I feel
example like,

1. Ladder : Normally in this method whole control circuit is represented in the form of Contacts. This method of programming the PLC is used for Online programming, testing/commissioning
and Diagonising the Application Programs.

2.Statement List: This is generally used at the time of engineering (in the Offline), situations like certain logics to be reused with some text editing (example: like logic MOTOR1 to be repeated for MOTOR2)

3.Flow Chart: Here the exact logics will be represented in the form of function blocks (like AND/OR miscellaneous Logic gates, ADDER, SUB and other Mathematical functions and so on). This
will be well suited for better understanding/final documentation.

BR/Girish
 
T

Tim O'Reardon

Bruce,

As I came through from being a maintenance guy at the sharp end I have every sympathy for you and the many thousands like you. When you have just got up at 3am when all hell has broken loose, you don't want to start to wade in through piles of papers trying to work out why a solenoid valve hasn't openned. I think that Ladder Logic has still got a long future.

Tim O'Reardon
 
J

Johan Bengtsson

Some of the languages are quite easy to convert to
each other: ladder, instructionlists and functionblocks are easily convertable and it should should be possible to create the program in one and view/modify it in another

some other languages, such as SFC (or grafcet) defining sequences instead of logic solves a completely other need. Some problems is best solved with a sequence programming language, other are best solved using a logic oriented
language. In the problem is best solved with a sequence language I would say it is best debugged in the same also even if it is quite often converted into logic before transferred to the PLC.

I hope this gives some additional thoughts...


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
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/
----------------------------------------
 
It looks like a very useful idea. I would be especially impressed if you put those capabilities into an "everyday" PLC, like an SLC500 or Micrologix.

Bill Sturm
 
Located in the US, working for oil and gas in Alaska, our firm has found that the various interfaces each have strengths and weaknesses depending completely on who will use the interface for what purpose.

If the use is for maintanence by a motors-&-lites electrician then ladder is most effective as it is most familiar and converts to the other work done. The circuit like logic diagram is very closely associated to relay panels or even
somewhat similar to single line diagrams of distribution and power control.

If the use is by instrument trained tech.s then the ladder interface is still commonly useful. However this group is often more familiar with statement list languages like Basic, or Pascal maybe C. Therefore this group will have more
use for the other interface methods and become more productive in these environments.

IF the programmer AND maintanence of digital controllers' applications are done by those coming from a more classic programming language background then the newer statement list interfaces are more productive.

In each case the earlier in their career a technician is trained in a particular interface the more effective they are using this to solve problems.

On the other hand, the electrician or instrument tech are more familiar with the end device and often solve problems concerning the I/O much more adroitly than the pure programmer because their knowledge base is more field oriented and less software theory based.

Therefore many control problems that could be solved very elegantly by a classically trained C++ programmer are more effectively handled in a less sophisticated software interface environment by those working in ladder.

I suggest that you use as a basis of your comparison the type of control, the chip generation of the hardware applied to the control, the network of distribution and couple this with the experience of the support group. One could almost envision a table of suggested methods of solutions based on the the variables in each facility.
 
Top