*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.