Ladder Logic 102: Organization

*Note: This post was written in October of 2012. Since that time I have written a number of other posts on ladder logic you may find useful. These are listed below for your convenience:
Ladder Logic 201: Inputs (March 2013)
Ladder Logic 202: Outputs (April 2013)
Ladder Logic 203: Faults (April 2013)
Ladder Logic 204: Auto Sequences (April 2013)
Ladder Logic 205: System Routine 1 (May 2013)
Ladder Logic 206: Scanning (May 2013)
There are also a number of other PLC related posts if you look around on the site.


Last week I received a couple of comments on an old post I made back when I started this blog, “Ladder Logic 101: Where Do I Start?”. First off, I really appreciate the comments because they are actually pretty rare and it’s nice to know people visit this site. Tony comments pretty regularly and always has some great information to add.

Anyway, this comment was from Doug, who is a mechanical guy that found the site and has a project he is just getting started on. He asked a question about project planning and design. I posted a quick response about some of the tools that I have used as follows:

“In general, here is a procedure I generally follow for my projects:
1. Kick-off meeting and discussion with design team. If a machine layout is available I usually use that and mark it up by hand, taking notes. If not, I use a piece of graph paper and draw a layout myself; I have a shorthand I use. Solid dots for valves, open circles for motors, X for a prox or limit switch, E and a dotted line for a photoeye and arrows for direction of movement. I use this drawing to generate an I/O list.
2. Timing diagram. I use Excel for this, usually this was generated by the mechanical team. This has a list of actions with a column for actuation time and bars for “on-time” for the actuators. It sort of looks like a Gantt chart with actions starting where others end. This is used as a basis for sequences.
3. I/O List. Again, I used Excel here. This came from the previous two steps, its important that the names of actuators and devices are firmed up by this time. You can use concatenation to generate tagnames off of your original device names here, i.e. Device_pb, Device_ind, Device_extpx, Device_retpx, Device_fault, etc. If your controller doesn’t use tags, you can do the same thing assigning bit addresses and comments or descriptions. I use the same spreadsheet for fault lists, messages and data collection tags.
4. Flow chart. I use the IEC 61131 Sequential Function Chart as a basis and create the chart in either Visio or AutoCAD. The components are Steps with their associated actions, transitions with their logic conditions and directional links between steps and transitions.
5. Program template. This is simply a base program with some simple mode logic (Auto/Manual/Step), a single sample input rung, output rung and fault. These can be duplicated with your IO List. Your sequences are generated with the flow chart which was in turn generated with the timing diagram.

Depending on the programming software, tags can be copied directly from your I/O list. Some software even allows XML imports which means you can use macros in Excel to actually generate Instruction List code which can be converted to ladder. This can be handy with things that are duplicated like I/O and faults.”

The picture at the top of this post is a flow chart of the machine level layout process we used at my old employer, Wright Industries. It shows a Machine-Zone-Cell hierarchy that was our standard for line and machine layout.

This is one of several layout templates I have used in the past for programming. I often have to use other companies’ templates when writing programs, in fact this year I did some programming for Borg-Warner, Automation Tool and Denso and had to use three very different organizational layouts. In my opinion, there is really no wrong way to lay out your programming, but some ways are better and easier to understand than others.

In the above example, the Zone designation is almost entirely safety related. Everything starts and stops at the same time and a fault within the zone issues a cycle stop for the whole zone. Cells within the zone are convenient methods of organizing mechanisms and devices that act as units. They also tend to have one main sequence that operates the cell actuators, but some have more. Cells also generally each have their own homing routines, fault structures and I/O.

The names that are used for these organized elements vary, cells may be called stations or processes, zones may be called workcells, etc. As I mentioned previously, there are many different ways to organize programs and machinery, people tend to like one method more than another but it is better in my opinion to have some method rather than none at all. Machine builders usually standardize on a template so that other employees within the organization can easily work on each other’s machinery.

As Tony mentioned in his book review of Cascading Logic by Gary Kirckof (Published by ISA), There really are no truly advanced PLC programming books. Tony’s definition of an advanced book is:
“Advanced book: how to write the best PLC program, tips and tricks, covers advanced applications such as motion control, interfacing to advanced sensors (such as machine vision), analog I/O, and using advanced PLC instructions.”
The problem is, each PLC platform is different. I use Rockwell/Allen-Bradley, Siemens, and Koyo/Automation Direct quite a bit, and all three are very different. AB is very easy to use, has a Controller/Task/Program hierarchy and UDTs (User-Defined Data Types) along with AOIs (Add-On Instructions) that make it easy to interface with other devices such as Vision, Servos, Robots and Torque Drivers. Siemens is less user friendly, uses Function Calls and Function Blocks and is closely aligned with IEC 61131, which is becoming a de-facto world standard. It also allows fairly seamless use of STL (Statement List) and SFC (Sequential Function Charts) within the ladder program. Koyo, which Doug is using, uses accumulators/logical stack for mathematical operations and data control. This can be confusing for people who mostly work with ladder, but is fairly straightforward for those familiar with low level computer languages. Because of differences like these, it would be difficult to write a single advanced book that covers all platforms.

After my current book is done I may take a shot at covering programming techiniques in more depth. Maybe even another book, but after discovering how difficult the book process is, I may wait a while.


Electrical Engineer and business owner from the Nashville, Tennessee area. I also play music, Chess and Go.

7 Comments on “Ladder Logic 102: Organization

  1. An advanced PLC programming book is probably best done as an e-book (e.g. Kindle, ePub), and oriented towards a specific group, e.g. A-B, IEC61131 users, etc.

    I’d call all ladder logic very low level, compared to modern mainstream (desktop, server, web, mobile) programming languages.

    One big plus of mainstream programming languages is the large number of truly excellent books available, both for writing code and overall development. I touched on this in a recent post.

    I do think market size and fragmentation is an issue (note that Kirchof’s book is published by a niche publisher), but not the only issue. Consolidation around IEC61131 will help, but I don’t see current market leaders (such as A-B and Automation Direct) fully adopting it anytime soon.

    I think part of the problem is cultural. For example, I suspect that “hobby appeal” is important. Many people really love programming and learn it on their own (heck, I did), but I don’t think this is common for PLC programmers. And when you love doing something, you’re more likely to do things for love (like writing books), not because you’re paid.

    An illustration of this: there’s a book coming out on the BeagleBone embedded controller board, which is popular with the hobbyist and hacker crowd, but I’m sure there more A-B PLC programmers than BeagleBone programmers. Maybe publishers think BeagleBone owners, as hobbyists, are more likely to buy books; I wouldn’t be surprised if this was true. But I think it’s significant that the author is a BeagleBone user who has already created a cool application for it (the Descriptive Camera).

  2. Thanks for the reply and post Phranc. It helped very much to clear things up for me as far as a good procedure to follow and possible program structures. However it also made me realize I have a lot more to learn then I thought! I can follow everything that you say about the procedure and the machine level layout process. But when putting it into practice there are a few spots where I feel like I have writers block when it comes to designing the program from the beginning. It’s more likely a lack of knowledge and confidence, but it’s much different then being able to follow an existing program.
    I was wondering if it would be possible to provide an example of the design procedure (machine layout, timing diagram, I/O list, and flow chart) for a simple machine, zone, or even just a cell. As well as the corresponding ladder program that relates to all of that and the flow charts you provided. As I’m writing I realize that’s probably asking a lot. So maybe you could help direct me towards some example programs that may show some of these things?
    I realize there are many different platforms and details to keep in mind, but I think any type of example will really help me a lot.

    I think I will buy the book Tony suggested. What’s the expected date for yours Phranc? Any early release specials?

    Well thanks for all the help. It’s really great learning all this stuff and I think you do a great job of explaining it.

    • Hi Doug, I am sending you some material today as a sample, hopefully it will be helpful. As far as the expected publication date it should be out early next year. I am sending out manuscripts for technical review next week and McGraw -Hill will have all materials by 12/1.

  3. Hi, can you so kind to share some templates or examples as you mentioned above. Im very interested in learn SFC.


  4. Excellent post, organization can be one of the most confusing aspects of starting a project. Pick the peripheral devices and let them drive your I/O list. It surprises me how many engineers actually reverse the order of those two items on the list.

  5. Hi Phranc,

    I am a programming enthusiast. After long search of materials, I stumbled over you site. I find your materials very useful.

    Thanks for the great work.


  6. Not sure How I lucked on to this site, but your enthusiasm and ability to explain things to us common folk trying to learn on our own is good.
    once I have read everything and tried a few things on my own, I may be able to ask intelligent questions.