Those who have written PLC code for controlling motors and other automation are thinking structured Ladder is an oxymoron—ladder code is inherently unstructured or worse. Even so, Ladder, as any other software language, can—and should—follow principles of structured programming.
Those who have written PLC code for controlling motors and other automation are thinking structured Ladder is an oxymoron—ladder code is inherently unstructured or worse.
Even so, Ladder, as 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 (see also “Software Toolbox Overflows for Control Programmers,” in this issue).
Certain essentials can help in developing PLC code that you and others can read and support once the project is signed off. This scheme is called Station Mapped Programming (SMP), and the four steps are described below. For elaboration and details, see the accompanying web-based tutorial at www.controleng.com.
The first step is to divide the project into its subsystems, or stations. Unless a system is so basic (fewer than, say, 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. The on-line tutorial illustrates the state-machine sequencer implementation in ladder.
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, rather than the less predictable (though definitely more exciting): “OK folks, I’m going to put it in RUN mode. Stand back!”
| Author Information |
| Dadla Ponizil is a San Diego-based electrical engineer. He has designed control software for industries ranging from semiconductor fabs to eyeglass manufacturers. [email protected] |
