5.6

PLC Software Advances B. D. CAMPBELL, P. G. FRIEDMANN

(1995)

Sequence definition thru flowcharts, state diagrams, or sequential function charts

PLC Programming Languages:

Graphical—Ladder logic and function block Text based—Instruction list and structured text Flowchart like—Sequential function charts

Language Standards:

IEC 61131-3 and IEC 848

Suppliers:

PLC manufacturers are listed in Section 5.4

Programmable controllers were originally introduced to replace large panels of relays used for running automobile assembly lines. Controller flexibility allowed reprogramming for year-to-year model changes. Early controllers were restricted to discrete (ON/OFF) control. Programs were represented by the use of ladder diagrams (Section 5.2), the same way that relay logic is represented. Programmable controller capability has been extended to include mathematical functions, file manipulations, analog signal manipulations, and techniques for dealing with highspeed signals. Programmable controllers are now routinely linked together in networks, connected to general-purpose computer systems, and connected to specialized intelligent devices, as was shown in Section 5.4. These devices include displays, high-speed control cards, and interfaces to specialized sensors such as bar code readers and RF identifiers. Many programmable controller suppliers support computer software for program development, program annotation, and program storage/retrieval. These added capabilities have allowed the application of programmable controllers in many areas outside of the traditional automobile assembly-type service. They are used for continuous process control high-speed packaging, energy distribution, and automated warehousing. Many of these applications strain the capability of ladder logic for program design and implementation. The software available in many programmable controllers has extended ladder logic to serve these diverse applications. To engineer a software system correctly, the application’s requirements must be well understood. A graphic representation of these requirements is described below. Among the

© 2006 by Béla Lipták

(2005)

Program Development:

INTRODUCTION

966

C. W. WENDT

ladder logic advances are indirect addressing, program flow modification, incorporation of mathematical or scientific instructions, communication with intelligent devices, and methods for working with high-speed signals. Ladder logic segments can be organized using sequential flow chart languages to produce a sequentially oriented program. Productivity enhancements developed for computer programmers are appearing in PLC programming software. Many program editors emulate MS Visual Studio formats with multiple windows and tool bars, pull-down menus, and visible “tree” structure for the project. Wizards have appeared in programming editors to automate tasks. If fact, Siemens provides one wizard in its S7 (200) programming software that automatically programs a Master-Slave polling task. PLC logic simulation, a powerful tool for programming and debugging even before the hardware is on hand, is 1 becoming more widely available. Most major PLC manufacturers now offer PC-based PLC simulation software. Even the hardware configuration is easier. PLCs used to be configured with switches and jumpers. Now PLCs can be programmed and configured remotely over the network. GRAPHIC DESCRIPTION OF CONTROL REQUIREMENTS There have been many studies of time and money investments 2,3 in building computer systems. One key conclusion of these studies is that spending more time on the planning, design, and study of systems can have several benefits. One benefit is that the risk of project failure is reduced. Another benefit is that the resulting system is more likely to meet real needs and to provide continuing returns. One of the effective ways of representing program requirements is through the combined use of state diagrams

5.6 PLC Software Advances

Symbol

967

Explanation

Data flow

Data flow

Represents data movement.

Data transformation

Computes outputs from inputs.

Terminator

Defines items outside of the context of the system.

State

A user-identifiable system mode.

State transition

A transition causes a state change while actions occur during a transition.

Data store

Shows how data are archived.

Output Input

Terminator

State

Transition Action Data store

Control flow

Data triggering WHEN things happen.

Control flow

FIG. 5.6a Data flow diagram primitives (symbols). 4,5

and data flow diagrams. These structured documents contain symbols for terminators, data transformations, data storage, triggers for control flows, and state diagrams. Figure 5.6a includes a list of these symbols (primitives). Control flows and transformations describe when actions occur. Data flows and data transformations describe what the system does. Either data transformations are further decomposed into other data transformations, or the input/output character of the transformation is specified.

The left side of Figure 5.6b shows a tank provided with a level transmitter. The sequence of tank filling and emptying are controlled by starting and stopping two pumps. If the level transmitter, pump motors, and display devices are connected to a programmable controller, the software shown on the right side of Figure 5.6b is needed to control the tank. This software must provide such actions as the automatic shutting off of the fill motor when the tank is full.

Fill Fill stop PB

Steady

PB DI

LT Level transmitter Empty motor starter DO Empty start

PB

PB DI

FIG. 5.6b Tank level control example.

© 2006 by Béla Lipták

Empty stop or level < min

DI

Empty stop

DI

Fill stop or level > max

Fill start and level < max

Fill motor starter DO Fill start

Empty start & level > min Empty

Average and store tank level Inventory records

968

PLCs and Other Logic Devices

Fill active Fill start

Fill stop

Fill active Full If level > tank max Interlock Outlet pump motor Fill active

Full

ladder logic commands read live inputs, outputs, or internal bits and perform instructions based on their state. Timers and counters are other sources of ladder logic commands. In most medium- and large-size controllers, these ladder logic-style commands are augmented by assembler-style instructions. Rather than working on bits alone, they operate on entire words. Some ladder logic extensions take on the character of high-level languages such as C or Basic. The assembly language is a primitive computer language, which Bryan defines as “a symbolic programming language that can be directly translated into machine language instruc8 tions.” While a particular assembly language is dependent on the type of machine used, each of the ladder logic extensions has its basis in some type of assembler language. For a survey of the many ways of using assembler (and advanced 9 ladder logic), see the books by Knuth. Table 5.6d lists some typical assembler-style instructions along with their comparable ladder logic instructions. Program Flow Modification

FIG. 5.6c Portion of ladder logic code.

The programmable controller’s ladder logic code for the fill motor starter controls is shown in Figure 5.6c. It shows how the start/stop station and the level interlock functions in order to guarantee that the tank does not overflow. Some programmers advocate the use of state-machine representation as a planning tool and then implementing the program directly in ladder logic. Sequential function charts (SFCs) can be used the same way. The benefits are: • • • • •

Design decision are made before programming begins. Project engineers can review and make changes before programming. Stakeholders can more easily understand and review the state-machine representation. Once the diagram is finished, it is easy to program. 6 The diagrams help document the ladder logic.

Another programming technique is based on the cycles of a machine. The cycles for the machine are numbered in sequence and are called states. The set conditions of coils or a counter is used to indicate which step the machine is in. All the actions that take place in that particular step are executed and when completed, the condition is defined to move to the next state. In addition to the cycle states, an initial state and a default safe state should also be defined. If the machine gets stuck in a state because of a malfunction, this programming technique is easy to troubleshoot, because 7 only the logic in that step needs to be examined. LADDER LOGIC ADVANCES Section 5.2 discussed ladder diagrams and their generation of commands that energize, latch, and unlatch coils. Other

© 2006 by Béla Lipták

Some of the ladder logic extensions shown in Table 5.6d modify the program flow. Conventional relay logic commands execute sequentially. In this case there are no changes in program flow, because each instruction is executed in every program scan. A GO TO command, when invoked, dictates that certain portions of the program will not be executed during the particular (current) scan. It allows the program flow to jump over the commands between the GO TO and the destination that is indicated in the GO TO. While the GO TO instruction is frequently used in general programming practice, it can make programs difficult to understand and maintain. A better device that serves the same purpose is the subroutine. The subroutine has a beginning, usually marked by a subroutine number, and an end, noted by a RETURN. The subroutine is executed by a JSR (jump to subroutine) or similar command (GOSUB, for example). When this occurs, the program flow goes to the label indicated in the command and executes the instructions that follow. Programs that consist of many subroutines are referred to as modular programs. After the RETURN is encountered at the end of the subroutine, program flow can return to the portion of the logic following the JSR. The benefits of the subroutine are as follows: 1. The same code can be run for different purposes in different places of the program without recopying the code. Fewer lines of code mean less time to make modification and maintain the code. 2. The code can be run conditionally. This means that the scan time, or time it takes to run once through the system, can be lowered if portions of the code run conditionally.

5.6 PLC Software Advances

969

TABLE 5.6d Assembly Language Comparable Assembler-Style Instructions Instruction Name

Instruction Category Arithmetic Operators

Compare

Logical Operators

Register Assignment

Shift Register

Program Control

Mnemonics in Allen-Bradley’s PLC5 and Square D’s 650

Definition

Add

ADD

Add two registers

Subtract

SUB

Subtract two registers

Multiply

MUL

Multiply two registers

Divide

DIV

Divide one register into another

Average

AVE

Average contiguous registers

Negate

NEG

Take opposite sign of source and store in destination

Equal

EQU

Set bit if source A equals source B

Greater than or equal

GEQ

Set bit if source A is greater than or equal to source B

Greater than

GRT

Set bit if source A is greater than source B

Less than or equal

LEQ

Set bit if source A is less than or equal to source B

Less than

LES

Set bit if source A is less than or equal to source B

Not equal

NEQ

Set bit if source A is not equal to source B

Clear

CLR

Set destination to zero

And

AND

Set a bit only if two bits are TRUE

Or

OR

Set a bit if either of two bits is TRUE

Excusive Or

XOR

Clear a bit if two bits are the same, otherwise set the bit

Not

NOT

Reverse state of bit

Move

MOV

Place a bit from one register into another

Masked move

MVM

Place a bit from one register into another if set in mask

BCD convert

BCD convert Indirect read

Read a word, given its address

Bit shift left

BSL

Shift bits in work left

*

Convert a register from BCD into integer

Bit shift right

BSR

Shift bits in work right

First in, first out load

FFL

Add an element to a waiting line

First in, first out unload

FFU

Remove an element from a waiting line

Jump

JMP

Skip rungs until the label is found

Jump to subroutine

JSR

Execute subroutine

Return from subroutine

RET

Exit subroutine and return to normal ladder execution

BCD = binary-coded decimal.

*

3. Details can be hidden. Breaking up the overall program into modules affords the programmer an opportunity to hide details inside of subroutines. Thus, someone other than the original author can follow the overall program better by understanding what each module of 10 code does, without examining module internals. As an example, it would be possible to code the previously described tank farm example in four separate subroutines. All of the tank logic for a single tank can be written in a single subroutine. The logic that sets up the tank logic by reading the appropriate signals can be written in another

© 2006 by Béla Lipták

subroutine. A third subroutine might communicate with other equipment after the tank logic has run. An executive routine can be used to call on each individual subroutine when they need to be called. This configuration is shown schematically in Figure 5.6e. The executive, in this case, contains only calls to the individual subroutines. Indirect Addressing One way to extend the tank-filling example across a tank farm would be to physically add sections of code for each tank. With a large number of tanks in a tank farm, a large number of rungs (lines in a ladder diagram) would be needed.

970

PLCs and Other Logic Devices

Move IO to B9: File B9 contains I/O for all tanks

Setup pointers

Top of loop

Count up Loop counter done

For each tank routine 10 loads: N3-Control offsets

JSR 10 10

20

Initialize offset tables

N6-Input offsets N7-Output offsets

Loop counter done

Run tank control

JSR 20

Routine 20 example: This rung runs for all tanks! B9:[N3]

Loop counter done

FIG. 5.6e Tank farm structure.

The larger the number of rungs, the larger the chances are that one of them could contain an error. Indirect addressing, which is new to most users of programmable controllers, is an effective way of simplifying and reducing the size of large programs. If, for instance, there are 200 tanks in a tank farm and to code one tank requires about 200 rungs, the resulting 40,000-rung program is difficult to maintain. With indirect addressing, if only one rung needs to be changed for each tank, there is only one rung to change in the total system. Without it, modifying the control would require modifications in 200 rungs. While there are variations in the capabilities of programmable controllers in regard to indirect addressing, by using assembler commands, indirect addressing is usually possible. If one desires to extend the code developed for one tank to work for an entire tank farm, the resulting requirement might look like the diagram in Figure 5.6f. The code reads the tank in progress, reads the offsets needed to run the code, reads the required information, triggers the code to operate on this information, and then writes

Internal control memory Input file

Setup pointers

Min & max thresholds

Trigger/ done

Output file

Run tank

Pointer setup

FIG. 5.6f Partial tank farm requirement.

© 2006 by Béla Lipták

B9:[N7]

Go to the top of loop

FIG. 5.6g Pointer setup and indirect addressing.

out the result and increments to the next tank on the available tank list. Figure 5.6g shows a listing of the necessary codes. Note that this code is “data driven.” By making files larger (B9 in Figure 5.6g is a file) and modifying their contents, indirect addressing provides a means for using fewer instructions than physical coding would use. Figure 5.6g shows the operation of indirect addressing. On the first pass, the value of the counter is 1. Then the code (JSR 10) runs, jumping to the subroutine 10. In this subroutine, integers are placed in registers N3, N4, N5, N6, and N7. Although the details of this subroutine are not shown, there could be a table for each of the registers, and the value of the counter would tell the program which element should be moved from the table to the register. Since the counter is at 1, the values associated with tank 1 are loaded into the registers. When subroutine 20 is run, it operates the controls for tank 1. For example, if the register that contains tank 1’s inputs is B9:45, then B9:[N3] will resolve to B9:45. Therefore, the same rung can be used for different tanks. When the counter is 2, subroutine 20 will load a different value in register N3, so that the rung will inspect a different input. Trade-Offs of Indirect Addressing Indirect addressing can help reduce the time involved in writing the ladder logic. However, it is more difficult to understand and maintain it than to maintain regular ladder logic. The benefits of indirect addressing must be weighed against some major trade-offs, including: • • •

Execution times are slower. Troubleshooting becomes more difficult. Accommodating differences in the group can be difficult.

5.6 PLC Software Advances

In time-critical applications, indirect addressing will require more processor time than would physical addressing. Thus, if, for instance, one unit’s code takes 20 ms to run, the indirect code for 100 units will take much more than the 2 seconds that would be required to run the code, if done physically. Instead of executing all the codes in a single scan, a counter can be set up to run one or more tanks per scan. In this case, it will still take more than 2 seconds to update all the tanks, but other parts of the system can run normally, and watchdog timeouts can be avoided. The second trade-off is in using a programming terminal to view the operation of the logic. When using direct I/O, either the ladder logic displays or the display of the data table can be used. With indirect addressing, the state of the logic can only be determined by studying the data table display. This makes troubleshooting difficult. A third trade-off is really an assumption that all the tanks are the same and will stay the same. It can become burdensome to write and troubleshoot the special logic to accommodate several small differences in the 100 tanks. In addition, other programming and documentation tools (like cross-referencing) may not work as expected, either. Assembly Language-Like Extensions Commands shown in Table 5.6d can perform data manipulation, including arithmetic operators, Boolean operations, and register assignment. One way that these are used is in a counting application. If, for instance, one needs to deliver a number of packages to an operator, a register can be assigned to contain the count. When operators want the programmable controller to read a thumbwheel, they can depress a button. A high state on the button causes the programmable controller to read the thumbwheel setting in binary-coded decimal and place that setting in its count register. Sensors are used to detect when individual packages are delivered to the operator. A change in state in these sensors causes the count to decrement. A ladder logic program performing these functions is shown in Figure 5.6h. The first rung moves information from the thumbwheel 10:1 to an internal word, B1:1. This word represents the required number of packages. The next decrements this number once for every FALSE to TRUE transition of the photoeye. Commands is another group shown in Table 5.6d to perform queue management. Queue management commands include LIFO (last in, first out) and FIFO (first in, first out) commands, which load and unload the queue. A queue in a programmable controller is usually a series of words that are loaded into contiguous registers to form an array. A queue management command will insert or extract a word from the array. One use for the FIFO queue is in tracking packages on a conveyor belt. Every package that enters the belt loads the FIFO and every one that exits unloads the FIFO. The word contains, for example, a package identification number.

© 2006 by Béla Lipták

Pushbutton Mov 10:1 to B1:1

Package photoeye

Package photoeye

Oneshot

B1:1 = B1:1 − 1

971

Move from live thumbwheel to internal word

Decrement count

Oneshot Allows one decrement per package

FIG. 5.6h Ladder logic for package counting.

Package sensing can be accomplished with photoelectric devices. Communication with Intelligent Devices Often, there are microprocessor devices that communicate with the programmable controller. Some newer devices do this by mimicking racks and by being scanned as a rack would be scanned. While this scheme affords a simple interface to these devices, it decreases the number of racks with which the programmable controller may connect. Often these devices physically plug in like an I/O card and communicate using some type of serial communication. In fact, one common type of card is the ASCII card, a card that is able to communicate using RS-422 or RS-232. As long as the supplier is specific about the format of the serial communication, the user can program these cards with ladder logic and jumpers on the card to communicate with any device using this form of serial communication. One common feature of these applications is that they require a ladder logic program that reads and writes a block of words, often performed continuously. One device that uses this type of programming and is common to many programmable controller vendors is the counter card. Counter cards count pulses that might occur too quickly for a programmable controller to handle. The words communicated to and from the counter cards might include a setpoint, an accumulated count, and a word containing information about the state of the communication itself. The way that this block of words is read from the external card and written to the external card is illustrated in Figure 5.6i. In Figure 5.6i, “BTR” refers to the statement in AllenBradley’s PLC-5 called a block transfer read. The rest of the items on this instruction indicate how the read will be done, including the PLC memory to be used, the location of the physical hardware, and the amount of data in the transmission. A similar statement is available in other programmable controllers that provide serial communication with intelligent devices.

972

PLCs and Other Logic Devices

There are both reads and writes; this one is a read

BTR Rack Group Module Control block Data file Length Continuous

Where the communication module resides Control words for storing communication state. Provides communication diagnostics.

Amount of data (words)

FIG. 5.6i The block transfer statement.

Fast I/O Updating Methods In many medium- to large-size programmable controllers there are numerous ways to read signals that occur faster than the scan time of the programmable controller. Conversely, outputs must sometimes be updated quickly, without the error associated with a variable scan time. The four most common methods for fast I/O updating are time-scheduled interrupts, programmable interrupts, latching hardware, and independent (dedicated) programmable controllers. If, for instance, one desires to capture a pulse of 20 ms duration in a controller with a program scan time of 100 ms, there is a good chance that the program that serves to count the pulses is going to miss some. One solution is the use of a concurrent time-scheduled routine. The routine contains a counter that reads the pulse input in question. By scheduling this counter to run once every 15 ms, the program would be guaranteed to read the 20 ms pulse, yet it would count each pulse only once, on the leading edge of the pulse. Several suppliers provide this type of routine. Code for such a routine is loaded in some special area of the memory, and the user must provide a time interval for running the concurrent routine. In many programmable controllers, there is an immediate update input instruction, or a “programmable interrupt.” When the instruction is encountered, the controller stops scanning the program, determines the current state of the particular (interrupting) input, and then continues on with the program. Several suppliers provide this type of interrupt on their inputs or outputs. As another option for reading quick, discrete signals, suppliers provide a special-purpose card for reading pulses, usually called a latching card. It is a useful approach for counting pulses only if the time between pulses is longer than the maximum program scan time. After using the “latched” input, the program needs to rest the card, making it ready for the next pulse. A final updating method is the use of another programmable controller. A small controller that is fast enough to detect quick pulses can be programmed to act like a counter or a latching card. Some manufacturers supply small controllers to act as cards for the programmable controller rack or

© 2006 by Béla Lipták

with convenient serial communication for communication to other controllers.

GRAPHIC, FLOWCHART-LIKE LANGUAGES Graphic languages are natural in today’s computer environments (e.g., Windows). Since the early 1980s, there have been several versions of graphic, flowchart-like languages, including sequential function charts. Their goal is to provide a maintenance-related programming language for sequences of operations. Because of this, they are often not very adaptable to continuous process control. As the origin of ladder logic is in relays, it is a language well adapted to describing a large number of relays. By their nature, these devices operate in a nonsequential, highly concurrent manner. Only with great difficulty is a sequence of control possible. These sequences are usually tracked by a counter or by latching relays. The order of the sequence is usually difficult, if not impossible, to quickly determine from the program. Several attempts have been made to build a language in which sequential control is easily coded. There is an interna11 tional standard for a graphic programming language. In this language, there are several basic symbol blocks (primitives). They are: • • • • •

Steps Transitions Directed links Branching sequences Simultaneous sequences

Steps are small programs. The programs might be written in any language, but many are ladder logic–driven. The transitions initiate a move from one step to another. When a step is connected to a transition, steps can be made to occur sequentially, as shown in Figure 5.6j. The direct sequential connection of steps with a transition is known as a directed link.

The first program step Condition indicating when the step is done

The second program step

Note: The detailed description of each step and transfer condition is a separate program listing.

FIG. 5.6j The use of directed links.

5.6 PLC Software Advances

during each program scan. If an exit condition becomes true, its associated step will no longer be executed. An example of using concurrent steps is shown in Figure 5.6m. In this example, each assembled product needs to have a cover placed on it and four screws fastened on the cover. One solution is to design a program for each screw, to be run concurrently. Each program turns a screwdriver driving a screw. When a screw has been inserted completely, as indicated by screwdriver position, that screwdriver is retracted and its program is no longer executed. The flowchart for this example, Figure 5.6m, illustrates the application power of this type of controller programming.

The process will branch from step 10 to either step 13 or step 14. If condition 11 comes true, step 13 will start. If condition 12 comes true, step 14 will start. Condition 11 and 12 cannot be true simultaneously.

10

11

12

13

14

FIG. 5.6k Branching steps.

Steps can also branch, depending on some other condition, allowing alternate sequences to occur. In the example shown in Figure 5.6k, conditions 11 and 12 control the program flow, allowing execution of step 13 or 14. It is possible to program concurrent or simultaneous steps. This means that during a program scan, the code associated with both of the concurrent steps is executed. In the example shown in Figure 5.6l, so long as exit condition 24 is not true, steps 22 and 23 will be executed

IEC 61131-3 PLC LANGUAGE STANDARD Programming a PLC is one of the most labor-intensive tasks in assembling a control system. It therefore makes good sense to try to reuse as much of the program as possible, once it 12 is debugged. A uniform programming environment for all manufacturers aids reusability, limits errors, and increases programmer efficiency. Developing the code only once and reusing it in many recurring control process scenarios is highly desirable, and attempts to standardize PLC language are in progress (see Table 5.6n). The International Electrotechnical Commission (IEC) 13 introduced IEC 1131-3 in 1992 and shortly thereafter renamed it IEC 61131-3. Since then, it has become widely accepted by the international user and vendor community. There are eight parts to the IEC 61131-3 standard for programmable controllers:

23

22

24

In this instance, both steps 22 and 23 run until condition 24 indicates completion.

1. General information 2. Equipment requirements and tests 3. Programming languages

FIG. 5.6l Concurrent steps.

Position cover 31 Cover positioned

Run screwdriver 32 #1

Run screwdriver 33 #2

Run screwdriver 34 #3

36 Screwdrivers done

FIG. 5.6m An example of using concurrent steps in a PLC program.

© 2006 by Béla Lipták

973

Run screwdriver 35 #4

974

PLCs and Other Logic Devices

TABLE 5.6n Work on a PLC International Language Standard Has 13 Been Ongoing Since 1979

4. 5. 6. 7. 8.

1970

NEMA Programmable Controllers Committee formed

1977

Grafcet (France) DIN 40 719, function charts (Germany)

1978

NEMA ICS-3-304, programmable controllers (U.S.)

1979

IEC SC65A/WG6 formed

1980

DIN 19 239, programmable controller (Germany)

1983

IEC 65A (Sec) 38, programmable controllers MIL-STD-1815 Ada (U.S.)

1985

IEC SC65A (Sec) 49, PC languages

1987

IEC SC65A (Sec) 67 IEC 848, function charts

1988

IEC 65A (Sec) 90

1992

IEC 1131-3

User guidelines Messaging service specification Reserved for future use Fuzzy control programming Guidelines for the application and implementation of programming languages

Programming languages (part 3) define, as a minimum set, the basic programming elements, syntactic and semantic rules for the most commonly used programming languages. It also defines major fields of application, applicable tests, and means by which manufacturers may expand or adapt those basic sets to their own programmable controller imple14 mentations. The IEC 61131-3 standard defines the following languages: • • • • •

Sequential function chart Ladder logic diagram Function block diagram Instruction list Structured text

Sequential function chart is a flowchart-like organizational construct based on the French Graphcet (IEC 848). Actual programming for steps and transitions is programmed in the other four languages. The two graphical languages are ladder logic and function block. Ladder logic was invented in the United States and is still the most widely used there. Function block is popular in Europe and is widely used in DCS systems. It is also well suited to controlling batch operations. The two text languages are the instruction list and structured text languages. Instruction list is an assembler-type language that was widely used in Germany. Structured text is the only language that was invented for the standard. It has a high-level syntax that resembles Basic. It is unique in that

© 2006 by Béla Lipták

it can combine the SFC in text form and incorporate the control in the same language. In actual application, rifts exist between standardized versus proprietary versions. Each vendor’s implementation of the standard is a little different. This inevitably causes some rewriting of code when moving programs between manufacturers. The degree that reuse is possible depends on how well each vendor complies with the standard. Also, high-level functions like PIDs are not addressed within the standard, so each manufacturer puts together its 15 own version. To address this, PLC Open was formed in 1992 to promote the adaptation of IEC 61131-3 and to minimize the number of variant adaptations of the standard. It 16 also provides independent certification of conformance. End users and system integrators want to be able to move easily between different brands and types of PLCs. Software that can configure all of the PLCs of at least one manufacturer and be similar to other manufacturers’ programming software 17 would be a step in the right direction. In the past, sequential and continuous processes were often addressed separately, with PLC used for the sequential and DCS for the continuous process and using their respective languages of ladder diagrams for PLCs and function blocks for DCS. One of the benefits of IEC 61131-3 is that PLC users can use ladders and DCS veterans can use function blocks in the same PLC. CONCLUSION Modern PLC software advances are increasing the productivity of PLC programmers. PLCs have matured from simple relay replacement to sophisticated controls involving interfacing to PCs and intelligent controllers. International standards like IEC 61131-3 have produced a unified, manufacturerindependent programming environment. Graphical languages (ladder logic and function block), text languages (instruction list and structured text), and organizational constructs (sequential function charts) support a wide variety of applications. The ability to mix these languages within a single PLC has also fueled software development. Modern software productivity tools (including wizards) and simulation software have made PLC programming and testing considerably easier than it was just ten years ago.

References 1. 2. 3. 4. 5.

Mintchell, G. A., “Toolbox Overflows for Control Programmers,” Control Engineering, September 2001. Boehm, B., Software Engineering Economics, New York: McGrawHill, 1981. DeMarco, T., Controlling Software Projects: Management, Measurement and Estimates, Englewood Cliffs, NJ: Yourdon Press, 1986. Ward, P. T. and Mellor, S. J., Structured Development for Real-Time Systems, Englewood Cliffs, NJ: Yourdon Press, 1991. DeMarco, T., Structured Analysis and System Specification, Englewood Cliffs, NJ: Yourdon Press, 1979.

5.6 PLC Software Advances

6. 7. 8. 9.

10. 11. 12. 13. 14. 15. 16. 17.

Ponizil, D., “Back to Basics: The Essentials of Structured PLC,” Control Engineering, September 2001. Fairey, W., “A Standard PLC Programming Method for Small Manufacturers,” Programmable Controls, March/April 1991. Bryan, L. A. and Bryan, E. A., Programmable Controllers: Selected Applications, Chicago: Industrial Text Co., 1987. Knuth, D., The Art of Computer Programming: Vol. 1, Fundamental Algorithms, 1981; Vol. 2, Seminumerical Algorithms, 1982; Vol. 3, Sorting and Searching, 1983; Reading, MA: Addison-Wesley. Kernigham, B. E. and Plaugher, P. J., Elements of Programming Style, New York: McGraw-Hill, 1978. International Electrotechnical Commission, Standard #848. Laduzinsky, A. J., “An Open Look for PLC Programs,” Control Engineering, May 1993. Christensen, J. H., “Programmable Controller Users and Makers to Go Global with IEC 1131-3,” I&CS, 1993. “General Introduction into IEC 61131: All Parts,” PLC Open Web site, June 2003, www.PLCopen.org. Greenfield, D., “Once Written, Often Used,” Control Engineering, August 2003. Babb, M., “IEC 1131-3: A Standard Programming Resource for PLCs,” Control Engineering, February 1996. Hebert, D., “PLCs in Harmony,” Control Magazine, January 2001.

Bibliography Berger, H., Automating with STEP 7 in STL and SCL: SIMATIC S7-300/400 Programmable Controllers, 2nd Book and CD-ROM edition, Hoboken, NJ: John Wiley & Sons, 2005. Bergwall Productions Inc., Statement List Programming PLCs, Albany, NY: Delmar Publishers, 1992. Boehm, B. W., Software Risk Management, Los Alamitos, CA: IEEE (Computer Science), 1990. Bryan, L. A. and Bryan, E. A., Programmable Controllers: Selected Applications, Chicago: Industrial Text Co., 1987.

© 2006 by Béla Lipták

975

Bryan, L. A. and Bryan, E. A., Programmable Controllers: Theory and Implementation, Chicago: Industrial Text Co., 1988. DeMarco, T., Controlling Software Projects: Management, Measurement and Estimates, Englewoods Cliffs, NJ: Yourdon Press, 1986. DeMarco, T., Structured Analysis and System Specification, Yourdon Press, 1979. Fleming, D. W. and Pillai, V. A., S88 Implementation Guide, New York: McGraw-Hill Professional, 1998. Girard, B., Programmable Logic Controllers: Architecture and Application, New York: John Wiley & Sons, 1990. Kernigham, B. E. and Plaugher, P. J., Elements of Programming Style, New York: McGraw-Hill, 1978. Knuth, D., The Art of Computer Programming, Vol. 1: Fundamental Algorithms, Reading, MA: Addison-Wesley, 1981. Knuth, D., The Art of Computer Programming, Vol. 2: Seminumerical Algorithms, Reading, MA: Addison-Wesley, 1982. Knuth, D., The Art of Computer Programming, Vol. 3: Sorting and Searching Algorithms, Reading, MA: Addison-Wesley, 1973. Larson, K., “The Great DCS versus PLC Debate,” Control, January 1993. Lewis, R., Programming Industrial Control Systems Using IEC 1131-3 (IEE Control Engineering Series , Vol. 50), Revised edition, Stevenage, UK: IEE Publishing, 1998. Parr, E. A., Programmable Controllers, 2nd edition, Boston: Newnes, 1998. Pereira, F., Application Note: Sequential Function Chart Programming Concepts, Allen-Bradley, 1985. Perron, S., “New Generation Language for Control Design,” Control Engineering, February 1992. Petruzella, F. D., Programmable Logic Controllers, New York: McGrawHill, 1989. PLC-5 Programming Software, Allen-Bradley, 1991. Ready, L. A., “Programming PLCs with Sequential Logic,” Control Engineering, November, 1991. SYMAX 650 Programming Manual, Square D, 1991. Ward, P. T. and Mellor, S. J., Structured Development for Real-Time Systems, Englewood Cliffs, NJ: Yourdon Press, 1991. Warnock, I. G., Programmable Controllers: Operation & Application, Englewood Cliffs, NJ: Prentice Hall, 1989.