PLC design methods

M

Thread Starter

michael

Hi all

I have been programming PLCs for many years without using any special design strategy/method.

Does anyone have suggestions for any suitable design methods??

What about object oriented design methods, does anyone have any experience using this??
 
Presumably you have had some method behind your PLC programming, special or otherwise. You might even find that to a degree, what you do now is "object oriented"
What do you do now, and what are you hoping to find here?
 
A

allan abrera

what usually i do is i group specific logic functions into individual sub-loops, ex. Inputs, Outputs, Manual Control, Auto Control, Cooling, Heating, Mixing etc... It makes it easier to troubleshoot especially when another programmer takes over in future truobleshooting. i also take extra time in putting-in descriptions - it makes a ton of difference.
 
I normally use a top-down methode to break down the control system into smaller moduls and then design the interface between these moduls.

But I really am looking for some help on how to describe/document such designs.

When I have a machine/system with 100's of statemachines controlling each a part on a the whole machine/system, I think its difficult to describe this.

Specially when you have a control system where you have many independent statemachines running.

I try to make state diagrams for the overview and then flowcharts for detailed sequencially things. But when you have many staemachines exchanging signals its getting difficult to overview.

So what do you use??

Reading books on analyse/design methods for PCs doesn't give me the right ideas on how to do it with plc programs.

So any suggestions for further reading (books, website etc.)?

Any examples how you all do it in your company?

regards
michael
 
M

Michael Griffin

The two main methods used (when any method is used at all) are SFC (Sequential Function Charts, or grafcet), and State Diagrams. Both have their place, as each offers different advantages in different applications.

SFC and state diagrams can be nested. That is, you could have state diagrams within state diagrams, or SFC within state diagrams. A state diagram or SFC is clearest when the entire diagram can be seen on one or two pages.

For example, you may have an SFC showing a normal machine automatic sequence, but the mode transfers (e-stopped, manual, auto, stand-by, etc.) are shown on a state diagram. The auto mode SFC would represent just one of the "bubbles" in the mode transfer state diagram. Covering too much on any one particular chart or diagram makes it difficult to follow, and loses much of the point of doing it.

SFC seems to work best for normal linear "sequences", and for showing parallel sequences (where you diverge and then rendevous later). You mentioned doing "flowcharts". If you have been doing conventional "computer programming" style flow charts, rather than SFC (grafcet), then you have most likely been using the wrong tool for the job. Conventional flow charts work well in a few cases for expressing certain mathematical type algorithms, but are not as good as SFC for machine sequences. SFC tends to be much more compact, and is also designed to show parallel processes clearly.

I believe you will find that the majority of PLC programmers don't do any program design, and would in fact not really understand what you are talking about when you say that a program should be "designed" before it is written. Most just hack away at it until it looks like it works, or until they run out of time. After that they hunt down bugs after the machine is supposed to be in production.

For some very basic examples of SFC and how it can be translated to ladder, you may wish to look at the manual for the Siemens S7-200 PLC (in the section on the SCR instruction).

OMAC (the automation interest group, not the mortgage broker) has some documents which discuss machine modes, and which have some good examples on mode transitions.
 
Speaking from the small scale (a few hundred I/O) automation perspective, the environment I work in can't afford to ignore program design. My employers make automated assembly and test equipment. Historically, we've done work with platforms from microcontrollers to PCs but these days 95% is PLC.

Starting with the description from the sales team, it may be optionally flowcharted (for multi-branch decisions and parallel processes) or go straight to the sequence list. Just a computer flowcharting program (PDQ lite) and a spreadsheet are the usual tools. The original sales proposal document is clarified and expanded where necessary (usually for enclosure in the customer design approval document, a project milestone). An absolute gem of a document often ignored by PLC programmers is the test specification. This should include system behaviour under fault conditions and sequence of actions required to recover from a fault. All these documents must go into the technical construction file and most go into the manual, too.

Having broken down all processes to simple sub-processes and documented how the I/O is used in each process, coding is a doddle whether you're using statement list, ladder or something more graphical.

Most jobs are tested by simulation (although multi-axis servo controlled positioning systems can pose a headache). Simulation is done with the actual PLC, in the software engineer's office, using the test specification as a check list (and a shedload of wires, switches and lamps). De-bugging with the real kit costs your employer a lot more than simulating it while the real stuff is actually "in build".

Using this process, de-bugging with the actual plant is massively reduced. We've all got past projects which we've "de-bugged into existence" but that's all a bit 20th century these days, isn't it chaps? (and chap-esses, of course.)
 
Hello. I have written a very limited amount of programs from scratch. My experience is being on the recieving end of a new peice of equipment. If you are writing multiple programs for a particular custumer, my best advice, for ease of trouble shooting, is to standardize what you are doing. I use GX Developer on q series Mitsubishi plc's. We have many traversing hoists. I can go to anyone of them and know what the output for up, down, clamp open, clamp close, etc. is. Same for hardwire. Being able to go from job to job and being able to know it even if you haven't had to work on that particular one before, well it just makes me warm all over.


On July 11, 2005, michael wrote:
> Hi all
>
> I have been programming PLCs for many years without using any special design strategy/method.
>
> Does anyone have suggestions for any suitable design methods??
>
> What about object oriented design methods, does anyone have any experience using this?? <

( Complete thread: http://www.control.com/1026211955/index_html )
 
S

Shailesh C Patel

can any body give information or link for standard for plc programming languages?

Regards,
Shailesh C Patel
 
Get the following books, fairly expensive books and not sure where I go it. My opinion well worth it, very good for project methodology and overall programming layout and languages, the second book is much deeper into languages
etc... I have worm out the cover on the first book.

IEC 61131-3 Programming Methodology - This is available at:

http://www.automation.com/store/pid13471.php - $99

Another is: Not sure where I go it.

IEC 61131-3: Programming Industrial Automation Systems

Concepts and Programming Languages, Requirements for Programming Systems, Aids to Decision Making Tools

ISBN 3-540-67752-6

These are the defacto standard for PLC programming languages, both very good books. If you want any more info on them, contact me off list:

davco(at)grandnet(dot)com replace the at and dot

Dave
 
F

Friedrich Haase

Top