Ladder Logic Programming

Those who have written PLC code for controlling motors and other automation may think “structured Ladder” is an oxymoron, believing Ladder code is inherently unstructured or worse. Even so, Ladder, like any other software language, can and should follow principles of structured programming. These principles include modularity, top-down design, single entry/exit points, and bottom up testing.

Certain essentials can help in developing PLC code that users can read and support once the project is signed off. This scheme is called Station Mapped Programming (SMP), and its four steps are described below.

The first step is to divide the project into its subsystems, or stations. Unless a system is so basic (fewer than 16 I/O points), it can be segregated into modules or subtasks. For example, consider a conveyor-fed process involving a pallet fixture, a pick-and-place station, and a process step, once the part is secured. The process step (or one of many) can be a vision system. Once the part is inspected, the pick-and-place puts it back on the pallet. The conveyor takes it downstream and brings in a new part.

This system may be divided into task areas or stations. Number these sequentially (0 to? 9), beginning with the input stage (conveyor) and continue to the output stage (the vision process). Using 10 stations will take care of most PLC-embedded systems, and the digits 0,9 readily map to each station's memory designation.

Next, design each process using state-machine representation. Taking one station at a time, bring together all available information, such as system specifications, truth tables, servo control protocols, SCADA requirements, customer specifications, etc. Develop a state-machine representation of each station's function(s). Use multiple sequencers when station processing is complex.

Reasons for using state-machine modeling are:

- Design decisions are made up front, before labor has been spent on coding;

- Project principals may review the design and make changes before coding;

- The representation holds a one to one correspondence with the ladder;

- The project is self-documenting since state diagrams represent the control specification; and

- With state diagrams, it's easier to explain to those not intimate with the project what will take place.

The actual ladder coding is almost an afterthought since the state diagram is the ladder. Once one sequencer is built in ladder, it's only a matter of changing the state word/bit descriptions to reflect new actions, and coding the state transitions/actions. Having a sequencer template and station mapped memory; the programmer just does an indexed cut and paste for the next process. Time is spent designing the process, not laboring over complex rung structures.

An important advantage to sequencer control is the ease of bottom-up test and debug. First, isolate the utility files, driver files, and common files and test them separately. Then, having confidence in these, enable the larger more complex process files one at a time. Sequencers allow single steps through the code so race conditions and logic errors can be identified methodically.