110421 1 IEC61131 Lenguajes Escencial MB

8/6/2019 110421 1 IEC61131 Lenguajes Escencial MB

1/62

ControlIT

IEC 61131 Control LanguagesIntroduction


2/62


3/62

Copyright 1999 ABB Automation Products AB.

The contents of this document can be changed by ABB Automation Products AB without prior notice and

do not constitute any binding undertakings from ABB Automation Products AB. ABB Automation Products

AB is not responsible under any circumstanc- es for direct, indirect, unexpected damage or consequent

damage that is caused by this document.

All rights reserved.

Release: October 2001

Document number: 3BSE 021 358 R201 Rev B Printed inSweden.

Trademarks

Registered trademarks from other companies are:

Microsoft, Windows, Windows NT from Microsoft Corporation.

PostScript and Acrobat Reader from Adobe Systems Inc.

FIX from Intellution and 3964R from Siemens.

3BSE 021 358 R201 Rev B


4/62

Contents

1 Evolution of Control Systems 91.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3 Control Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Monitoring Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Sequencing Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Closed-loop Control Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Relay Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.5 Computers for Process Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Programming Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.6 Programmable Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

I/O Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Programming Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Computer-based Programming Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Cyclic Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Soft PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2 Why Open Systems are Needed 252.1 Programming Dialects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2 Software Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3 Software Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4 Portable Software Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5 Reusable Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6 Communication with Other Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 IEC 61131-3 Standard 313.1 Main Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Benefits Offered by the Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Well-structured Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Five Languages for Different Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Software Exchange between Different Systems . . . . . . . . . . . . . . . . . . . . . 33

3.3 PLCopen Trade Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3BSE 021 358 R201 Rev B 5


5/62

Contents

4 Programming Languages 354.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Common Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Constant Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Ladder Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Easy to Understand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Weak Software Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Limited Support for Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Difficult to Reuse Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4 Instruction List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

IL Language Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

IL Instruction Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Best System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Weak Software Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Machine-dependent Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.5 Structured Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Operators in Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Conditional Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Calling Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Suitable for Complex Calculations and Looping . . . . . . . . . . . . . . . . . . . . 53

High Threshold for Programmers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.6 Function Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Syntax for Function Block Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Standard Function Block Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Similar to Electrical Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Boolean Functions and Feedback are Easy to Implement . . . . . . . . . . . . . 60

Not Suitable for Conditional Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.7 Sequential Function Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Chart Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Steps and Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Action Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Sequence Selection and Simultaneous Sequences . . . . . . . . . . . . . . . . . . . 65

Subsequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Advice on Good Programming Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Powerful Tool for Design and Structuring . . . . . . . . . . . . . . . . . . . . . . . . . 68

Other Programming Languages are Needed . . . . . . . . . . . . . . . . . . . . . . . . 68

6 3BSE 021 358 R201 Rev B


6/62

Contents

4.8 Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Type and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

User-defined Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Differences between Functions and Function Blocks . . . . . . . . . . . . . . . . 72

How to Use Function Blocks in Control Programs . . . . . . . . . . . . . . . . . . 73

Interaction between Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5 Object-oriented Programs 75

5.1 New Life for an Old Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2 Objects in the Plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.3 Data Flow in Real-time Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.4 Program Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.5 Reuse of Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.6 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6 Control Modules 836.1 Control Module Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.2 Graphical Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.3 Automatic Code Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.4 Applications for Control Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7 Project Management 89

7.1 Stages of a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.4 Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.6 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.7 Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.8 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8 Industrial Application Example 958.1 Control Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

8.4 Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Project Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Variables and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Ramp Function Block Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

SFC Sequence Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Control Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Control Module Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

9 Glossary 109

Index 117


7/62

3BSE 021 358 R201 Rev B 7


8/62

Contents

8 3BSE 021 358 R201 Rev B


9/62

Chapter 1: Evolution of Control Systems 1.1 Introduction

Chapter 1

Evolution of Control Systems

1.1 IntroductionAlmost all industrial plants need some kind ofcontrollerto ensure safe and

economical operation. At the simplest level, the plant may consist of an elec-

tric motor driving a cooling fan to control the temperature in a room. At the

other extreme, the plant could be an entire nuclear reactor for producing elec-

trical energy for thousands of people. Apart from their size and complexity, all

control systems may be divided into three well-separated functional parts: the

transducers, the controller and the actuators.

Transducers Actuators

Plant

Inputs Controller Outputs

Parameters Status

Fig. 1 Overview of the components in an industrial control system.

The controller monitors the actual status of the plant processes through a num-

ber oftransducers. The transducers convert physical properties into electrical

signals that are connected to the controller inputs. Digital transducers measure

conditions with distinct states, such as on/off or high/low, while analog trans-

ducers measure conditions which have a continuous range, such as tempera-

ture, pressure, flow or liquid level.

3BSE 021 358 R201 Rev B 9


10/62

1.2 History Chapter 1: Evolution of Control Systems

Based on the status of the inputs the controller uses a built-in or programmed

algorithm to calculate the status of the outputs. The electrical signals from out-

puts are converted into process behavior via the actuators. Most actuators cre-

ate movements of valves, motors, pumps and other devices by using electrical or

pneumatic energy.

The operator interacts with the controller by providing control parameters.

Some controllers can display process status via a screen.

1.2 HistoryThe first control systems were developed during the industrial revolution at the

end of the 19th century. The control function was implemented by using

ingenious mechanical devices automating some of the most repetitive and crit-

ical tasks on the assembly lines. These devices had to be individually adapted to

each task and due to their mechanical nature they also suffered from a short life-

time.

In the 1920s, mechanical control devices were replaced by electrical relays and

contactors. Relay logic made it possible to develop larger and much more so-

phisticated control functions. Since then, electrical relays have been used in alarge number of control systems around the world. Relays have proven to be a

very cost-effective alternative, especially for automating small machines with a

limited number transducers and actuators. In todays industry, relay

logic is seldom chosen for new control systems but a large number of older

systems are still in use.

The silicon-based integrated circuit, IC, paved the way for a new generation of

control systems in the 1970s. Compared with relays, ICs based on TTL or

CMOS integrated circuits are much smaller, faster and also have a longer life-

time.

In most control systems based on relays and ICs, the control algorithm is per-

manently defined by the electrical wiring. Systems with wired logic are easy to

implement but unfortunately it is difficult and time-consuming to change their

behavior.

In the early 1970s, the first commercial computers debuted as controllers in

large control systems. Since computers can be programmed they offer a great

advantage compared with the wired logic function in systems based on relays

or ICs.

10 3BSE 021 358 R201 Rev B


11/62

Chapter 1: Evolution of Control Systems 1.2 History

Early computer systems were large, expensive, difficult to program and unfor-

tunately also very sensitive to the harsh environment in many industrial plants.

As a result of demands from the American car industry the Programmable

Logic Controller(PLC) was developed in the early 1970s. The PLC is a com-

puter designed to work in an industrial environment. The transducers and

actuators in the outside world are connected via robust interface cards. Com-

pared with an office computer, the PLC has a limited instruction repertoire,

often only logical conditions.

Early PLCs had no analog inputs and therefore they could only handle

digital control applications. In todays industrial plants there is often a need to

handle both digital control and closed-loop analog control in the same control

system. These systems are often called Programmable Controllers since their

operation is not limited to only logical conditions.

Today, the overall control function in a plant is often distributedto a number of

local programmable controllers which are positioned in the immediate

neighborhood of the objects which are to be controlled. The different control-

lers are usually connected together into a local area network(LAN) with a

central supervisingprocess computerwhich administers alarms, recipes and

operations reports.

1880 1920 1970 1980 1990 2000

Mechanics

Relays

ICs

Computers

PLCs

Processcomputers

Fig. 2 The evolution of control systems since the end of the 19th century.

The operator plays a very important role in todays industry and many plant

installations therefore have a computer-based SupervisoryControl and Data

Acquisition System (SCADA). SCADA systems have high-resolution color

monitors on which the operator can select different application programs and

study the status of the manufacturing process.

3BSE 021 358 R201 Rev B 11


12/62

1.3 Control Applications Chapter 1: Evolution of Control Systems

It is characteristic of todays industry that the demand for profitability is

increasing, while at the same time there is a more frequent need to carry out

changes in the control function. Because the cost of computer equipment has

fallen dramatically in recent years, the cost of development and maintenance

of software has become the predominant factor.

In order to improve the quality and make it easier to reuse programs, there are

today many more people working with object-oriented systems. In such sys-

tems the real process components like motors, valves and PID controllers areprogrammed via standardized program objects stored in program libraries.

Such objects are well proven and have a standardized user interface.

1.3 Control Applications

It is easy to be overwhelmed by the complexity of an industrial plant process.

However, most processes can be simplified by dividing them into a number of

smallersubprocesses. Such subprocesses can normally be divided into three

different categories. Monitoring subsystems, sequencing subsystems and

closed-loop control subsystems will be further described in the following three

sections.

Monitoring SubsystemsA monitoring subsystem displays the process state to the operator and draws

attention to abnormal conditions which require some kind of action from the

operator. The measured process values for temperature, pressure, flow etc. are

displayed to the operator via indicators, meters, bar-graphs or via a computer

screen.

Signals can also be checked for alarm conditions. The system indicates alarms

via warning lamps or audible signals, often accompanied by a paper printout.

Many monitoring systems also keep records of the consumption of energy and

raw materials for accountancy purposes. The system may also create automatic

warnings when critical components need to be exchanged.

Sequencing Subsystems

The vast majority of all subprocesses can be described via a predefined

sequence of actions that must be executed in a certain order. In such a system it

is not possible to specify a momentary combination of input signals resulting in

a certain output signal. Instead, the output status is dependent on an entire

sequence of input signals having occurred. In order to monitor the sequence of

actions there is a need formemory functions.

12 3BSE 021 358 R201 Rev B


13/62

Chapter 1: Evolution of Control Systems 1.4 Relay Logic

Sequencing subsystems have many advantages over control systems based on

momentarily input status. Normally, they are easier to implement and present a

better overview of the control function. It is also easier to localize malfunc-

tions in a transducer since this will cause the sequence to freeze.

Closed-loop Control Subsystems

Many subprocesses have analog variables such as temperature, flow or pres-

sure that must be automatically maintained at some preset value or made tofollow other signals. Such a system can be represented by the block diagram

in Fig. 3. Here, a variable in the plant denoted PV(Process Value) is to be

maintained at a desired value denoted SP(Set Point).

PV is measured by a transducer and compared with SP to give an error signal.

This error signal is supplied to a control algorithm that calculates an output

signal, which is passed on to an actuator, which affects the corresponding vari-

able in the process.

The control algorithm will try to adjust the actuator until there is zero error.

Many control algorithms are available but the most commonly used is the

Proportional, Integral and Derivative (PID) controller. Since the control func-

tion is running continuously, the PV can be made to track a changing SP.

Desiredvalue

SP

Error

SP-PV

PV

Controlalgorithm

Actual value

Actuator Process

Transducer

Controlledvariable

Fig. 3 A closed-loop control system.

1.4 Relay LogicThe electromagnetic relay has been one of the most important components in

the evolution of control systems. Relay logic systems contain a number of

relays that are activated by digital transducer contacts. The control function is

defined, once and for all, by how the contacts are connected to each other and to

the corresponding relay coils.

3BSE 021 358 R201 Rev B 13


14/62

1.4 Relay Logic Chapter 1: Evolution of Control Systems

All relay coils are normally used to activate one or more built-in switches.

These switches are connected to the actuators in the process. If one of the relay

switches is used as an alternate input contact the result will be a circuit with

memory function.

Logical AND

Logical OR

Memory

Fig. 4 Three often-used logical conditions implemented with relay logic.

A relay-based control system may contain any number, from a dozen up to

thousands, of relays. The relays with corresponding wiring are contained in

one or more cabinets. The transducers and actuators are normally connected

via plinths.

The logical function of a control system based on relays is described in

ladder diagrams, presenting how transducer contacts and actuators are electri-cally connected. The ladder diagrams not only describe the logical function but

are also used as drawings when the relay cabinets are manufactured.

Since relays are relatively costly and electrical wiring is time consuming, the

total cost of a relay-based control system depends mainly on the number of re-

lays used. In large plants the limited number of contacts on both transducers

and relays sometimes leads to engineering problems.

14 3BSE 021 358 R201 Rev B


15/62

Chapter 1: Evolution of Control Systems 1.5 Computers for Process Control

Experience shows that it is easy to develop small relay systems with a limited

number of relays, but with increasing complexity the work will demand a very

experienced engineer.

A characteristic quality of relay-based control systems is the decentralization

of the logic function into a large number of discrete relays. Since relays are

electromagnetic components they have a limited life-time. Relay-based con-

trol systems therefore need continuous maintenance and service. Another dis-

advantage of relay systems is that it may be very difficult and time-consuming tochange the logical function in an existing plant.

Today, relay logic can only be justified in very small plants with less than a

dozen inputs and outputs and in plants with severe electrical interference,

where computers and programmable controllers cannot be used.

1.5 Computers for Process ControlThe first computers that were developed during the 1950s were very large,

expensive machines. Such systems were mainly used for administrative tasks

like payroll administration, accounting and banking. The operations per-

formed were most often batch processes.

Microprocessors, developed in the 1970s, started a dramatic revolution

resulting in much smaller and cheaper computer systems. During the 1970s,

many control systems were developed using microprocessors as controllers.

The most important advantage of computers, compared with wired logic, is

that the programmed control function can easily be altered. Computers are also

very suitable for performing arithmetic calculations and for storing huge

amounts of data. A standard computer, however, is not equipped for commu-

nication with industrial equipment. Another disadvantage is the high learning

threshold for developing computer programs.

Early computer-based control systems needed extra interface equipment inorder to handle real-world transducer and actuator signals. These interfaces

normally had to be individually developed for each plant. Since then, several

vendors have developed standard interface modules for both digital and analog

process signals.

3BSE 021 358 R201 Rev B 15


16/62

1.5 Computers for Process Control Chapter 1: Evolution of Control Systems

Programming MethodsAll computer programs consist of a number ofinstructions which tell the com-

puter what to do when the program is run, orexecutedas programmers prefer to

say. Because computers process binary information, the computers instruc-

tions are very different from our own verbal ways of describing the actions we

want it to take. In programming, therefore, various aids are used to process and

translate our verbal function description into the computers own language.

These aids are ready-made computer programs which can be purchased rela-tively cheaply.

Machine Code and Assembler

Most computers have a limited set of instructions which carry out simple op-

erations such as fetching data, storing data, adding numbers, etc. By combin-

ing a large number of such machine codes into long programs, the programmer

can get the computer to carry out very complex functions. In order for the pro-

gram to work, however, it is very important to follow the rules on how instruc-

tions should be used and combined, often called thesyntax of the program.

Because machine codes are binary or hexadecimal numbers, the job of pro-

gramming is made easier by using what are known as assembler instructions.

Each of these instructions has a three-letter name (memo-code), such as LDAfor fetching data andADD for adding two numbers. A ready-made program

known as an editoris normally used when writing assembler instructions into

the computer. An editor program has basic word processing functions for en-

tering and correcting text.

Before the assembler program can be executed, the memo-codes must first be

translated into hexadecimal machine code. The translation to machine code is

done by another program called an assembler. Assembler programs of this

kind can be bought for most types of computers. Apart from the actual trans-

lation, the assembler program can also help in checking syntax and in calcu-

lating logical jumps within a program. Assembly is normally carried out on the

same type of computer as will be used for program execution, but there are alsoassembler programs, known as cross-assemblers, which can be run on other

types of computers.

Test running of assembler programs is made easier by special programs that

allow part of the program to be executed step by step. Using these so-called

debuggingprograms, it is also possible to simulate real-life signals so that the

function can be tested without having to connect the computer to the process.

16 3BSE 021 358 R201 Rev B


17/62

Chapter 1: Evolution of Control Systems 1.5 Computers for Process Control

Start

Editing usingeditor

Assembling

Test-running usingdebugger

Functioning Noproperly?

LDA IN1

L1 SUB C

CMP B

BNE L1

ADD D STO

OUT1

F6

0AA9

23

12E3

F8

Assembler 76

06

A3

45

D3

A2

Yes

Stop

Fig. 5 In low-level programming several supporting programs are used, such as an editor, an assemblerand a debugger, in order to translate the program into machine code. Programming using

assembler instructions has both advantages and disadvan- tages. The workdemands a thorough knowledge of the technical workings of the computer. In

most cases, the problem description also has to be restruc- tured so that the

required function can be obtained using the instructions available in thecomputers repertoire. The completed program is entirely matched to one

particular type of computer and cannot be transported to another type of

computer. On the other hand, a properly written assembler program gives good

performance and the optimal usage of the computers memory. This isimportant in, for example, industrial robots and where very large series are to be

produced. Working with assembler is often called low-level languagebecause

the instructions are similar to the computers own way of working.Compiling and Interpreting

The work of programming is made considerably easier if the program is writ-

ten in what is known as a high-level language, which is translated into machine

code by a program-based compilerorinterpreter.

3BSE 021 358 R201 Rev B 17


18/62

1.5 Computers for Process Control Chapter 1: Evolution of Control Systems

The difference between compilers and interpreters is that the compiler first

translates the whole program before it is executed, while the interpreter trans-

lates and executes the program instructions one by one. This means that com-

piled programs are executed considerably faster than interpreted ones.

The most common high-level languages are Pascaland the closely related

languageC. Both of these are normally compiling high-level languages. An

example of an interpreted language is Basic.

Instructions in a high-level language are reminiscent of mathematical func-

tions, and are therefore relatively easy to use. All high-level languages are

highly standardized, and the main parts of the programs can be written so that

they are independent of the type of computer on which they will be run. The

actual matching to the computer is done by the compiler or interpreter in the

process of converting it to machine code. Programs that are written in high-

level languages are often known assource code, while the compiled result is

called object code.

Source code in Pascal

Profit := Income - Cost

IF Profit>20 THEN PRINT "Profitable" ELSE

PRINT "Loss"

END

020CA7

4337E3

F8

Compiler 8616A2

45A205A3

Fig. 6 Programs written in a high-level language are totally machine- 12

independent and are translated to computer-specific machine code 7B

by a compiler program.

The programmer writing in a high-level language does not need to know thetechnical details of the design of the computer or its memory. Another advan-

tage is that completed programs can be moved to another type of computer,

assuming that a suitable compiler is available.

The disadvantage of programs written in high-level languages is that they take

up more room in the memory than corresponding programs written directly in

assembler (machine code). This also means that the performance of the com-

puter is used less efficiently.

18 3BSE 021 358 R201 Rev B


19/62

Chapter 1: Evolution of Control Systems 1.6 Programmable Controllers

1.6 Programmable Controllers

In answer to demands from the car industry, several vendors, in the early

1970s, presented the Programmable Logic Controller (PLC). The PLC is an

industry-adapted computer with a simplified programming language. Early

PLCs were originally only intended to replace relay-based control systems.

Since then, PLCs have developed into the most commonly used type of control

systems in all kinds of industrial plants, from small machine control systems,

up to entire manufacturing lines in large process industries.

Independent of brand and type, most PLCs contain three functional parts: the

central unit, the memory and the I/O unit, all communicating via a bus unit.

The central unit coordinates all activities in the PLC and executes the control

program in the memory. The process status is monitored and sampled via the

I/O unit.

Apart from logical instructions an increasing number of todays PLCs also

have arithmetic functionality. Many vendors are therefore using the term

Programmable Controllerinstead of PLC.

Programming of PLCs is normally carried out on an external computer-based

engineering station. The compiled program is downloaded to the central unit

and then into the program memory via a serial channel or via a LAN. Some

PLCs have an option for using the engineering station for online process status

presentation, while the control program is executing.

PLC Engineeringstation

Memory Central unit

Bus unit

I/O unit

Input modules Output modules

Transducers Actuators

Fig. 7 The components of a programmable controller system.

3BSE 021 358 R201 Rev B 19


20/62

1.6 Programmable Controllers Chapter 1: Evolution of Control Systems

I/O UnitsA characteristic quality of the programmable controller is that it is designed to

live in and interact with an industrial environment. Most controllers have a

modularized Input/Output unit (I/O) for direct connection of the transducer and

actuator signals.

The purpose of the I/O unit is to convert the process signals to the lower signal

level used in the controller and also to suppress electrical transients from the

plant equipment. This is often achieved by optical isolators containing a light-

emitting diode and a photoelectric transistor linked together in a package. Since

there are several different signal levels in a typical plant, many I/O units allow the

use of exchangeable I/O modules. Such an I/O unit can easily be cus- tomized to

the specific signal levels of the plant.

The most commonly used I/O modules are digital DC inputs and outputs with

the signal levels 24 V or 48 V. Many vendors also offer modules with AC in-

puts and outputs with signal levels of 110 V or 220V.

A growing number of programmable controllers have arithmetic functionality.

Such systems have a need for analog input and output I/O modules. Most

analog transducers represent a physical value as a current within the range4-20 mA, with 4 mA indicating the minimum value.

Programming MethodsThe first PLCs used a programming language based on relay ladder diagrams.

The program was entered via a programming terminal with keys showing

contact symbols (normally open/normally closed), relay coils and parallel

branches with which a maintenance electrician would be familiar.

The programming terminal compiled the ladder diagram into machine code

which was sent to the controller for execution. With the controller executing

the control program was presented on a screen, with energized contacts and

coils highlighted, making it possible to study the application and also, if nec-essary, to debug the program.

Programming with ladder diagrams is a very intuitive method, especially for

people with previous knowledge of relay-based control systems. Therefore,

this method was initially preferred by American PLC vendors.

20 3BSE 021 358 R201 Rev B


21/62


In large plants and when people without previous knowledge of relay logic are

to develop the control program, Boolean instruction lists are often preferred.

Most European PLC vendors have chosen this as the standard programming

method in their systems.

A 001

A 012

ON 020RP

A 003

= 201

Fig. 8 Examples of PLC programs using a ladder diagram and instruction list.

Computer-based Programming ToolsEarly PLCs were programmed with dedicated terminals, only usable for that

purpose, together with specific systems from one vendor. Today, almost all

programmable controllers are programmed with standard personal computers

(PCs) running a dedicated development software tool. ControlBuilderProfes-

sional from ABB is an example of such a software tool intended for use with

some of the programmable controllers supplied by ABB. A complete system

with computer and development software is often referred to as an engineering

station.

Most development tools contain several different, but often integrated, soft-

ware applications which simplify the work of program development for the

associated control system.

The editoris used to define variables and for writing the control program

instructions. Most editors havesyntax checkingthat helps the programmer

avoid such errors. Program editing is normally done offline, which means that

the engineering station is running locally, not in communication with thecontroller.

The compilertranslates the control application into machine code and down-

loads this code for execution in the programmable controller.

Many development tools provide a useful function that compiles andsimulates

the control function in the computer without downloading it to the controller.

The simulated status of inputs and outputs is displayed on the computer screen.

Simulation makes it possible for the programmer to test the application by

manually altering the input signals.

3BSE 021 358 R201 Rev B 21


22/62


Some development tools can be used online, for displaying the actual process

signal status on the computer screen, when the control application is executing in

the programmable controller.

With ever-increasing performance in computer-based engineering stations,

several vendors now offer developing packages, in which it is also possible to

use programming methods like Structured text, Sequential Function Charts

andFunctionBlock Diagrams, apart from ladder diagrams and instruction

lists. These methods are further described in Chapter 4.

Cyclic Execution

Industrial control systems are real-time systems, which means that changes in

the input signal require immediate action on the corresponding output signals.

An example is a machine in which some movement must be stopped when a

particular limit is reached. If the controller does not react in time, the result

may be damage to the machine or injury to the operator. The consequences of a

delayed reaction therefore become unacceptable.

In order to fulfil the demands on a real-time system, the application program

must have constant access to current input data from the process. To achieve

this the compiled program is executed cyclically at a specific frequency.Changes in the incoming signals can therefore only affect the output signals at

the end of each completed program cycle. The required interval time of the

program is determined by the maximum allowed delay time in the process.

Read inputs

Execute

program

Interval time1 - 50 ms

Updateoutputs

Fig. 9 A typical program scan in a programmable controller.

22 3BSE 021 358 R201 Rev B


23/62


Because different subprocesses may have different time demands, some pro-

grammable controllers provide a function for dividing the total program into

different tasks, each with its own interval time.

Distributed SystemsIn many large industrial plants there is a need fordistribution of the entire

control function to several different programmable controllers and process

computers. This strategy will improve total performance and also reduce therisk of total breakdown in the manufacturing process.

The cabling between transducers, actuators and the programmable controllers

accounts for one of the major costs in a control system. If the plant is spread

out over a large area, considerable cost savings may be achieved by using

remote I/Osubsystems situated close to the actual subprocess.

Distributed control systems require a standardized communication protocol in

order to exchange information. Several PLC vendors have developed their own

proprietary protocols during the 1990s and some of these, like COMLI from

ABB, 3964R from Siemens and the vendor-independent Profibus, have slowly

emerged into de facto standards supported by more than one PLC

vendor.

Soft PLCOne problem with PLCs is that all vendors use their own proprietary controller

hardware with an associated programming language. In spite of the basic func-

tions being practically identical, the instructions have different names and the

rules governing the syntax of the programs may vary. This makes it difficult to

communicate and exchange application programs between systems of differ-

ent manufacture.

Several software vendors have presented a new type of controller called the

SoftPLC. The Soft PLC is real-time software executing a control application

in a standard PC and communicating with the plant via a standardized modularI/O unit.

The major advantage of a Soft PLC is that all the required hardware is vendor

independent. Unfortunately, none of the software vendors has managed to

establish their Soft PLC software as an industry standard. This means that con-

trol applications developed with one Soft PLC application cannot be trans-

ferred to Soft PLCs from other vendors.

3BSE 021 358 R201 Rev B 23


24/62


24 3BSE 021 358 R201 Rev B


25/62

Chapter 2: Why Open Systems are Needed 2.1 Programming Dialects

Chapter 2

Why Open Systems are Needed

2.1 Programming DialectsThe programmable controller is one of the most critical components in todays

industry. Since control systems are being used in so many plants and in appli-

cations concerned with safety, it is very important that programs can be under-

stood by a wide range of industrial personnel. Besides the programmer, a

control program should be easy to follow by technicians, plant managers and

process engineers.

For almost two decades, the market has been dominated by half a dozen

vendors offering very similar solutions but, unfortunately, also brand-specific

programming dialects. Many customers using programmable controllers have

decided to standardize their equipment to at least two different vendors, in

order to minimize risks. In real-world applications this often leads to costly

double work and problems in communication between systems from different

manufacturers.

2.2 Software QualityAs more and more jobs in manufacturing and process industries become auto-

mated, the software programs become larger and therefore more difficult to

manage. In most cases, more than one programmer is needed to develop the

application software for industrial automation. Experience shows that the risk ofprogram errors grows exponentially with the number of programmers in-

volved and, consequently, the size of the program itself.

Experience also shows that new industrial plants often encounter problems a

long time after commissioning. Some failures can interrupt production or, in

the worst case, result in serious damage to the production equipment or the

processed material.

3BSE 021 358 R201 Rev B 25


26/62

2.3 Software Cost Chapter 2: Why Open Systems are Needed

It is well-known that good software quality comes at a high cost. Most control

software is developed either by a department in the customer organisation or by

small software houses working in a close privileged relationship with the

machine or plant manufacturer. In both cases, software production and thus

cost is not governed by the free market. Consequently, software suppliers are

not motivated to strive towards more efficient development methods and tools.

The vast majority of all control code is written with the proprietary software

packages delivered by the control system vendors. Many of these packageshave very poor facilities for working with modules, for code reuse and for doc-

umentation. Software quality is therefore heavily dependent on the experience

and intellectual capacity of the programmer.

Before the IEC 61131-3 standard was established, good software engineering

was an open goal in the control application environment.

2.3 Software CostDuring the last decade, standardized software packages for personal comput-

ers, like word processors and spreadsheets, have become very popular. This

makes it possible for software vendors to lower prices dramatically. Distribu-tion via the Internet has pushed the limits even further, and today many useful

standard applications are available asshareware, almost free of cost.

In contrast, most software for control applications is adapted to the specific

needs of a single plant application. This means that the total development cost

has to be charged to a single customer.

Most customers find it difficult to control the total software development cost. A

customer without experience in software development can only present a

rough functional description to the developer. In many cases, this leads to a

final product that only partly fulfills the customers requirements. Even small

changes and additions tend to be very costly to implement, especially in later

phases of program development.

The hardware on which computer programs are run is developing at an amaz-

ing speed, while prices are constantly falling. Todays personal computers have

equally good, or even better, performance than yesterdays mainframe

computers. With the increasingly good relationship between hardware perfor-

mance and price, the total cost of an installation is becoming more dependent

on the time required for program development. In most projects, therefore,

greater weight is attached to standardization and reuse of programs than with

finding the optimal hardware.

26 3BSE 021 358 R201 Rev B


27/62

Chapter 2: Why Open Systems are Needed 2.4 Portable Software Applications

Fig. 10 Cost of hardware versus software.

An automation plant or machinery can pose a danger to the operators or the

material if the control software has fatal errors. Therefore, the software has to

pass a particularly intense testing and validation procedure. In real-world

applications, testing may be very time consuming, especially if the work has to

be done with the process running. If the application program has been written

by inexperienced programmers, the cost of testing even may exceed the cost of

program coding.

2.4 Portable Software Applications

The personal computer together with the Windows operating system is today a

well-established de facto standard for information handling in almost all

offices in the world. The main reason for the PCs enormous penetration is

software compatibility. Application programs developed for Windows can be

used on almost all PCs around the world.

More than 25 years after the introduction of the first programmable control-

lers, this market still lacks an international standard similar to that for the PC.

Most control vendors use their own proprietary programming dialect, which

can only be used with their hardware.

This is surprising since almost all industries using programmable controllers

have high demands on inter-system portability of control system software.

Since the cost of developing well-tested software is much higher than the hard-

ware cost, there is often a need to port existing applications from older out-

dated hardware to newer systems.

To many, it is incomprehensible that it has taken more than 25 years for the

programmable controller market to start establishing a common programming

standard like the IEC 61131-3.

3BSE 021 358 R201 Rev B 27


28/62

2.5 Reusable Software Chapter 2: Why Open Systems are Needed

2.5 Reusable SoftwareNot so long ago, many real programmers measured their effectiveness by the

amount of program code they produced per day. Real programmers dont like to

waste their time on structuring and detailed specification. Instead, they move

directly from a rough specification, often made by the customer, to coding in

their favorite language, often ladder diagram or instruction list.

Today, even real programmers realize that the first phase in a project when theoverall function is analyzed, structured and designed, is the key to a successful

and cost-effective application program.

The traditional method of reducing software cost is to reuse common parts of

the program code in several similar applications. Unfortunately, this is difficult

in industrial automation since most processes are very different in behavior.

Another obstacle to software reuse is that the program code is often strongly

affected by the programmers own style. When the final application is the result

of teamwork there are often visible seams between the parts coded by different

programmers. The only way to reduce the risk of seams is to encour- age (read

force) all the members of the team to follow certain rules and formal- ism for

producing code.

2.6 Communication with Other Systems The firstprogrammable controllers presented in the seventies were often placed in an

electrical equipment cabinet close to the machine or process being controlled.

These controllers normally had no means of interaction with the machine

operator or communication with other controllers.

In todays industrial plants, great emphasis is put on operator interaction with

the system. The huge control centers in e.g. nuclear power stations are being

replaced by PC-based Supervisory Control and Data Acquisition Systems

(SCADA) using a large color screen to present process pictures showing plantstatus. Two of the most commonly used SCADA systems are SattGraph from

ABB and FIX from Intellution.

In large industrial plants, the control function is normally divided into a num-

ber of different programmable controllers communicating with each other via

some kind of standardized communication protocol. SattLine from ABB is an

example of such aDistributedControlSystem (DCS).

28 3BSE 021 358 R201 Rev B


29/62

Chapter 2: Why Open Systems are Needed 2.6 Communication with Other Systems

Most control system vendors have developed their own proprietary communi-

cation protocols for information exchange in SCADA and DCS. Some vendors

also provide software-based protocol converters enabling communication be-

tween systems from different manufacturers.

All industrial plants have computer-based ManagementInformation Systems

(MIS) for handling of statistical and economic information. There is often a

need to connect MIS with SCADA and DCS, resulting in a total control and

management system. General Motors in the USA has developed a standardcalled Manufacturing Automation Protocol(MAP) for communication be-

tween different programmable controllers and MIS. Unfortunately, the MAP

standard has so far not been particularly successful.

3BSE 021 358 R201 Rev B 29


30/62

2.6 Communication with Other Systems Chapter 2: Why Open Systems are Needed

30 3BSE 021 358 R201 Rev B


31/62

Chapter 3: IEC 61131-3 Standard 3.1 Main Objectives

Chapter 3

IEC 61131-3 Standard

3.1 Main ObjectivesIEC 61131-3 is the first, and so far only, global standard for programmable

controllers. Considering that programmable controllers have been used in

automation systems for more than two decades, it is remarkable that a pro-

gramming standard has taken so long to evolve. The IEC (International Elec-

trotechnical Commission) working group, with members from all the leading

vendors, has, after years of discussions, finally come to a consensus and pro-

duced a working standard. The main objectives of the IEC 61131-3 standard

are as follows.

The standard encourages well-structured program development. All appli-

cation programs should be broken down into functional elements, referred

to asprogram organisation units or POUs. A POU may contain functions,

function blocks or programs.

It should be possible to execute different parts of the application program at

different rates. This means that the system must support individual interval

times for different POUs.

Complex sequential behavior can easily be broken down into events using a

concise graphical language.

The system must support data structures so that associated data can be

transferred between different parts of a program as if they were a single

entity.

The system should have parallel support for the five most used languages,

Ladder Diagram (LD), Instruction List (IL), Function Block Diagram

(FBD), Structured Text (ST) and Sequential Function Chart (SFC).

The programming syntax should be vendor independent, resulting in more

or less portable code that can easily be transferred between programmable

controllers from different vendors.

3BSE 021 358 R201 Rev B 31


32/62

3.2 Benefits Offered by the Standard Chapter 3: IEC 61131-3 Standard

3.2 Benefits Offered by the Standard

Well-structured SoftwareThe main purpose of the IEC 61131-3 standard is to improve overall software

quality in industrial automation systems. The standard encourages the devel-

opment of well-structured software that can be designed either as top down or

bottom up software. One of the most important tools in achieving this is func-

tion blocks.

Afunction blockis part of a control program that has been packaged and

named so that it can be reused in other parts of the same program, or even in

another program or project. Function blocks can provide any kind of software

solution from simple logical conditions, timers or counters, to advanced con-

trol functions for a machine or part of a plant. Since the definition of input and

output data has to be very precise, a function block can easily be used, even by

other programmers than those who developed it.

By packaging software into function blocks the internal structure may be

hidden so that well-tested parts of an application can be reused without risk of

data conflict or malfunction.

Five Languages for Different NeedsThe IEC 61131-3 standard supports five of the most commonly used program-

ming languages on the market. Depending on previous experience, program-

mers often have their personal preferences for a certain language.

Since most older programmable controllers use Ladder Diagram or Instruction

List programming, there are often many such programs available. These pro-

grams can relatively easily be reused in new systems supporting the standard.

Todays programmable controllers can handle both logical conditions for dig-

ital signals and arithmetic operations on analogue signals. Arithmetic opera-

tions are much easier to program with Structured Text than with Ladderdiagrams.

The initial structuring of a control application is normally best done with the

graphical language Sequential Function Chart. This method is ideal for de-

scribing processes that can be separated into a sequential flow of steps.

An optimal software application often contains parts written in more than one of

the five programming languages. The standard allows the defintion of function

block types using all the languages.

32 3BSE 021 358 R201 Rev B


33/62

Chapter 3: IEC 61131-3 Standard 3.3 PLCopen Trade Association

Software Exchange between Different SystemsBefore the IEC 61131-3 standard was established it was not possible to port

control programs from one vendors programmable controller to a competing

system. This has been a major obstacle to a free market, where the customer

selects a system based on the suitability of the hardware and price, rather than

by the type of programming languages supported by the controller.

With programmable controllers that are IEC compliant the potential for port-

ing software is much better. Software developed for one manufacturers sys-

tem should, at least theoretically, be possible to execute on any other IEC-

compliant system. This would open up the market dramatically resulting in

better standardization, lower prices and also improved software quality.

Unfortunately such a high level of software portability may be difficult to

achieve in practice. The IEC 61131-3 standard defines many features and only

requires that vendors of programmable controllers specify a list of which

features their system supports. This means that a system can be compliant with

the standard without supporting all features. In practice, portability will there-

fore be limited, since systems from two different vendors often have different

feature lists.

3.3 PLCopen Trade AssociationSince the IEC standard has relatively weak compliance requirements, a num-

ber of the larger control system companies concerned with software portability

have formed the PLCopen Trade Association. PLCopen is a vendor- and prod-

uct- independent worldwide association supporting the IEC 61131-3 standard.

Being founded in 1992 in The Netherlands, PLCopen today also has support-

ing offices in Canada and Japan. The organisation informs users/programmers

about the standard via a website (www.plcopen.org), a free quarterly newslet-

ter, participation at trade fairs and by arranging their own conferences.

PLCopen has defined three different compliance classes concerning theportability of control system software.

The lowest class is Base Level, defining a core kernel of the standard. Al-

though rather restricted, it is feasible to develop applications based on it. Base

Level provides an entrance for control system vendors, demonstrating their

commitment to the standard.

3BSE 021 358 R201 Rev B 33


34/62

3.3 PLCopen Trade Association Chapter 3: IEC 61131-3 Standard

Portability Levelcontains a large set of features including user-defined func-

tions and function blocks. This level also demands that the system has an

export/import tool for easy exchange of program code between systems from

different manufacturers.

The highest level,FullCompliance, provides exchange of complete applica-

tions, including configuration information, between different control systems.

34 3BSE 021 358 R201 Rev B


35/62

Chapter 4: Programming Languages 4.1 Overview

Chapter 4

Programming Languages

4.1 OverviewThe IEC 61131-3 standard specifies five programming languages:

Ladder Diagrams, LD

Instruction List, IL

Structured Text, ST

Function Block Diagram, FBD

Sequential Function Charts, SFC

IL and ST are textual languages while LD, FBD and SFC are based on graph-ical metaphors. Since all of these languages have both advantages and disad-

vantages, it is important to have basic knowledge of the most suitable

applications for each language.

Although most control systems may be implemented with any one of the five

languages the resulting program will be more or less effective, depending on

the requirements of the control application.

A1 A3 M1LDN A3

AND( A1

OR A2

A2)

ST M1

LD IL

A1

M1 := ( A1 OR A2 ) AND NOT A3;A2 1

A3& M1

ST FBD

Fig. 11 A simple Boolean condition programmed with four of the five IEC 61131-3

programming languages. SFC is normally only used for sequences.

3BSE 021 358 R201 Rev B 35


36/62

4.1 Overview Chapter 4: Programming Languages

Historically, the five languages have evolved in parallel with the evolution of

automation systems. Relay systems documented via LD were dominant in the

1950s. Logical circuits described by FBD were used mostly in the 1960s.

PLCs debuted in the 1970s with programming in IL. Computers for process

automation were introduced in the 1980s with ST programming in languages

like Pascal and C. Improved CPU power in the 1990s finally made it possible

to work with graphical languages like SFC.

Before the IEC 61131-3 standard was established, most vendors of program-mable controllers supported only one or two of the programming languages.

By tradition, most American vendors have preferred LD languages while

European vendors have chosen FBD or IL languages.

The choice between different programming languages is governed by several

economical, technical, and cultural factors.

Depending on background, programmers often have a preference for a cer-

tain language. Programming with IL, LD or FBD is more popular among

engineers with experience in automation systems using those programming

languages, while ST is the natural choice for engineers with experience us-

ing computer systems with programming languages such as Pascal. In small applications with relatively few logical conditions, the demands for

good structure and reuse of code are less important than in larger systems.

Many older control systems use LD as a direct analogy to systems based on

relays and switches.

In large plants involving many subprocesses the control function must be

divided into an number of program modules with a high level of encapsu-

lation in order to prevent the modules from interfering with each other.

Program languages are often characterized by their level of abstraction. A

low-level language like IL is very closely coupled to the actual binary codes

running the processor in the control systems. Low-level languages normally

have a limited number of instructions producing very effective softwarecode but, unfortunately, also totally tailored for a certain brand or model of

system. High-level languages, like ST and SFC, do not produce the most

effective machine language but, on the other hand, the program may be

compiled for many different programmable controllers.

When programmable controllers were first introduced in the 1970s, most

of the applications were for purely Boolean logical conditions. Today, a

control system must handle both digital and analog control, together with

timers, counters and sequences.

36 3BSE 021 358 R201 Rev B


37/62

Chapter 4: Programming Languages 4.2 Common Elements

The cost of software development has a tendency to increase exponentially

with the size of the application. Since many control functions are used in the

same way over and over again it is possible to simplify the application pro-

gram by using generalized standard modules. Reuse of standard modules is

by far the most effective method to reduce costs.

When industrial plants are redesigned with new control systems, large parts

of the old program code, which have been tested and debugged over several

years of intensive use, are often reused. Even the most up-to-date systems,therefore, have to support older and generally less effective languages.

Structure level

High SFC

FBD

ST

IL

LDLow

Year

1950 1960 1970 1980 1990 2000

Fig. 12 The evolution of the five IEC 61131-3 programming languages. Today, SFC, ST

and FBD are the most commonly used techniques for developing new control systems.

4.2 Common Elements

The IEC standard defines a number ofcommon elements which are used in all of

the programming languages. This section explains the rules for using identi-

fiers, data types, constants and variables.

IdentifiersIdentifiers are used for naming different elements within the IEC language, for

example, variables, data types, function blocks and programs. An identifier is a

string of letters, digits or underscore symbols which begin with a letter or an

underscore. Space characters are not allowed in identifiers. Two or more

underscores may not be used together.

3BSE 021 358 R201 Rev B 37


38/62

4.2 Common Elements Chapter 4: Programming Languages

Allowed identifiers Illegal identifiers

Motor_1 1Motor

Elapsed_Time switch 1

_prog2 Conveyor__3

Keywords are special identifiers that are used within the IEC language as indi-

vidual syntactic elements. You are not allowed to use keywords as identifiers,

for example:

Type, True, False, Program, Task, Return, Step, Function, Timer, Counter

Some compilers may be able to distinguish between keywords based on their

position but others may produce confusing results.

Programmers comments are delimited at the beginning and end by asterisks

(*comment*). Comments can be placed anywhere except in IL language,

which has some restrictions.

Data Types

The first PLCs could only handle Boolean data but todays systems are beingused in an ever-widening range of industrial applications. For this reason, the

IEC standard provides a comprehensive range of elementary data types. The

most often used data types are described below.

Data type Keyword Bits

Boolean bool 1

Integer int 16

Double integer dint 32

Real numbers real 32

Duration of time time

Calender time date_and_time

Character string string

In addition to elementary data types, programmers can define their own Struc-

tured data types containing several components of data types. Such a data type

has no physical correspondence in the plant, but it can be likened to a cable

containing a number of leads of different types, e.g. for the transfer of electri-

cal power or telephone and TV signals.

38 3BSE 021 358 R201 Rev B


39/62

Chapter 4: Programming Languages 4.2 Common Elements

All leads are given descriptive names so that the programmer can connect to

them without having a detailed knowledge of their function.

PumpType On (boolean)

Off (boolean)

Level (real)

Name (string)

Fig. 13 Example of a structured data type containing several elementary data types.

A new structured data type is declared by delimiting the definition with TYPE

and END_TYPE.

TYPE PumpType

On: boolean

Off: boolean

Level: real

Name: string

END_TYPE

Each component in a structured data type is identified via the variable nameand the component name separated by a point, for example Pump3.On.

Constant LiteralsBy giving a variable the attribute constant, you prevent it from being changed

after it is given its initial value. The initial value is normally specified in the

variable declaration.

There are two classes of numerical literals: integer and real, where the latter

are distinguished from the former by the presence of a decimal point. Real

literals may end with an exponent, indicating the integer power of ten by which

the preceding number is to be multiplied.

Decimal numbers are represented in conventional decimal notation. Numbers

to bases other than 10 are represented in base 2, 8 or 16 (prefix 2#, 8# or 16#).

Boolean data are represented by the values 0 and 1 or the keywords FALSE and

TRUE.

Time literals are used either forDuration data or forTime of day. Duration data

are prefixed by the keywords TIME# or T# followed by the actual duration in

terms of days, hours, minutes, seconds and milliseconds. Time of day literals

are prefixed by the keywords TIME_OF_DAY# or TOD#.

3BSE 021 358 R201 Rev B 39


40/62

4.2 Common Elements Chapter 4: Programming Languages

VariablesVariables is the name given to data elements whose content may change during

execution of the application program. A variable may be associated with a real-

world input and output, but can also be an internal memory storage. All variables

are declared with a unique name and a corresponding data type. This is

normally done before the program code is written. A variable must also have an

attribute, either retain, constant or a blank field. Retain means that the variable

will retain its value when the system restarts. A constant variable will not be

changed by the system. Variables with a blank attribute will always be

calculated at system restart.

If a variable has to start at a specific value, that value has to be specified as

Initial value, otherwise it will start at a predefined value depending on its data

type (normally 0).

The table below shows examples of names and attributes of variables of

frequently used data types.

Name Data type Attributes Initial value

Pump_1 bool retain False

PhotoCell_4 bool False

Duration_Open time constant T#3m10s

Event_Notation date_and_time constant DT#1999-02-01-

12:30:00.000

NumberOfRev dint constant 10

Temperature_5 real retain

The IEC standard defines three types of variables:

local, global and access variables.

Local variables can only be accessed in the same function block or program in

which they are declared.

Global variables are accessible from any program or function block in the

open project. A global variable must be declared as an external variable in the

program organisation unit (POU) accessing it.

Access variables can be used by other controllers.

40 3BSE 021 358 R201 Rev B


41/62

Chapter 4: Programming Languages 4.3 Ladder Diagrams

4.3 Ladder DiagramsLadder Diagrams (LD) have evolved from the electrical wiring diagrams that

were used, for example, in the car industry, to describe relay-based control sys-

tems. LD is a graphic representation of Boolean equations, using contacts as a

representation for inputs from the process and coils for outputs.

An LD diagram is limited on both sides by vertical lines, called power rails.

The power rails serve as a symbolic electrical power supply for all the contactsand coils that are spread out along horizontal rungs.

Each contact represents the state of a Boolean variable, normally a transducer,

but sometimes also an internal variable in the control system. When all con-

tacts in a horizontal rung are made, i.e. in the true state, power can flow along

the rail and operate the coil on the right of the rung. The coil normally repre-

sents physical objects like a motor or a lamp, but may also be an internal vari-

able in the control system.

There are two types of contacts, normally open and normally closed. Contacts

which are normally open present a true state (Boolean variable is 1) when they

are closed. Normally closed contacts present a false state (Boolean variable is

0) when they are open.

In analogy with electrical circuits, contacts connected horizontally in series

represent logical AND operations. Parallel contacts represent logical OR

operations.

switch1 alarm motor

switch2Normally closedcontact

Coil

Normally opencontacts

P o w e rrails

Fig. 14 Example of a simple ladder diagram with three contacts and a coil.

It is possible to create LD programs that containfeedback loops, where the

variable from an output coil is used as an input contact, either in the same or

in other logical conditions. In a real-world relay circuit this is equivalent to

3BSE 021 358 R201 Rev B 41


42/62

4.3 Ladder Diagrams Chapter 4: Programming Languages

using one of the relays physical switches as an input contact. A person with

experience in computing would probably call this a memory bit.

start

fan

stop fan

Fig. 15 Feedback loop in an LD program. The fan starts with an impulse on contact start and continues

to run until the contact stop is opened.

Easy to UnderstandProgramming with LD can be learnt relatively quickly and the graphical pre-

sentation is easy to follow. The method is particularly easy to understand by

people who are familiar with simple electrical or electronic circuits.

Fig. 16 Status indication of an executing LD program.

42 3BSE 021 358 R201 Rev B


43/62


LD programs are very popular among maintenance engineers since faults can

easily be traced. Most programming stations generally provide an animated

display showing the live state of transducers while the programmable control-

ler is running. This provides a very powerful online diagnostics facility for

locating incorrect logic paths or faulty equipment.

Weak Software Structure

Ladder programming is a very effective method for designing small controlapplications. With increasing processing power and memory size with todays

programmable controllers, the method can also be used to construct large con-

trol systems. Unfortunately, large ladder programs have several serious draw-

backs.

Since most programmable controllers have limited support for program blocks,

orsubroutines, it is difficult to break down a complex program hierar- chically.

The lack of features for passing parameters between program blocks makes it

difficult to break down a large program into smaller parts that have a clear

interface with each other. Usually, it is possible for one part of a Ladder

Diagram to read and set contacts and outputs in any other part of the program,

which makes it almost impossible to have truly encapsulated data.This lack of data encapsulation is a serious problem when large programs are

written by several different programmers. There is always a danger that inter-

nal data in one block can be modified by faulty code in other program blocks.

Each programmer, therefore, has to be very careful when accessing data from

other program blocks.

There are also problems in using structured data with ladder programs since

data are normally stored and addressed in single memory bits. Many control

applications often have a need to group data together as a structure. Some

sensorsprovide more than one variable that has to be recorded by the control

system. Apart from the physical value measured by the sensor, the application

sometimes needs to disable the sensor, place it in test mode, record the timewhen the sensor is active and also raise an alarm if the sensor is activated long-

er than a certain prescribed period.

All of this information from the sensor should ideally be handled as a single

structure that can be addressed using a common name. In most ladder pro-

grams such data is often spread out among different ladder rungs. Without a

data structure the programmable controller has no provision for warning the

programmer when incorrect data are accessed.

3BSE 021 358 R201 Rev B 43


44/62


45/62


From the above example it is obvious that ladder programs with sequences can

become very large and difficult to maintain. The most obvious problem is that

control of the memory-based sequence model is mixed with the application

logic so the behavior of the complete program is difficult to understand and

follow.

Difficult to Reuse Code

In many large control systems similar logic strategies and algorithms are usedover and over again. A common application is to detect fire by using two or

more transducers with a comparison algorithm to eliminate false alarms. Such

systems consist of a large number of similar ladder rungs with only minor

modifications to read different contacts and to set different outputs. This can

result in very large, unstructured programs.

Unfortunately, very few programmable controllers have an option for defining

standardized ladder blocks that can easily be called upon many times with dif-

ferent inputs and outputs.

3BSE 021 358 R201 Rev B 45


46/62

4.4 Instruction List Chapter 4: Programming Languages

4.4 Instruction List

Instruction List (IL) is a low-level language with a structure very similar to

assembly language, often used for programming microprocessors.

IL has been chosen as the preferred language by a number of PLC manufac-

turers for their small to medium-sized systems. The lack of structured vari-

ables and weak debugging tools make the language less suitable for larger

systems.

IL Language StructureIL is a language with a series ofinstructions, each on a new line. An instruction

consists of an operatorfollowed by an operand. The operator tells the system

what to do, while the operand identifies which variable is to be processed.

Some operators can process more than one operand, in which case, the opera-

tors should be separated by commas.

IL programs are often written on a spreadsheet-like form with one column for

operators and another for operands.Labels, used to identifying entry points for

jump instructions, are placed in their own column to the left of the instruction.

All labels should end with a colon. The instructions only need to have labels ifthe program contain jumps. Comments are placed in a fourth column to the

right of the operand. Comments are enclosed by asterisks (*comment*). It is

strongly advisable to add comments to all instructions during programming.

Large IL programs without comments are very difficult to follow.

Label Operator Operand Comment

LD temp1 (*Load temp1 and*)

GT temp2 (*Test if temp1 > temp2*)

JMPCN Greater (*Jump if not true to Greater*)LD speed1 (*Load speed1*)

ADD 200 (*Add constant 200*)

JMP End (*Jump unconditional to End*)

Greater: LD speed2 (*Load speed2*)

Fig. 18 Example of an IL program for controlling the speed of a motor.

To improve readability, IL instructions are normally structured so that labels,

operators, operands and comments are put in fixed tabulated positions.

46 3BSE 021 358 R201 Rev B


47/62

Chapter 4: Programming Languages 4.4 Instruction List

A characteristic of IL programs is that instructions always relate to an internal

register, called the result register, RR, IL registeroraccumulator. Most opera-

tions consist of calculation between the result register and the operand. The re-

sult of an instruction is always stored in the result register. Most programs start

with the instruction LD, which loads the accumulator with a variable. The

result register changes its data type automatically during program execution in

order to fit the value that needs to be stored.

Programmable controllers normally only have one result register. This mustnaturally be taken into consideration by the programmer when writing code.

The program example in Fig. 18 on page 46 first loads the RR with a real vari-

able. The second instruction compares RR with another variable which results

in a Boolean TRUE or FALSE result in RR. The conditional jump instruction

JMPCN uses the Boolean value in RR as a condition for either continuing with

the next instruction (RR false) or jumping to the label Greater. In both cases,

the next instruction loads RR with a new real value. The final instruction stores

the RR in a real variable called motor controlling the speed of the motor.

IL Instruction Set

The IEC has developed a standardized instruction repertoire by examining themany low-level languages offered by different vendors. The IL language, as

defined in IEC 61131-3, is a selection of the most commonly used instructions in

current programmable controllers. Each instruction is written as an abbrevi-

ation of the corresponding operation, sometimes referred to as a mnemonic.

Some IL operations can take operator modifiers after the mnemonic that

change the behavior of the corresponding operation. The modifier character

must complete the operator name with no blank characters in between. The

following three modifiers can be used:

N, Boolean negation of the operand

C, Conditional operation

(, delayed operation

Operator Operand Comment

LDN switch1 (*Load inverse of switch1*)

AND( switch2 (*Boolean AND with the following two operations*) OR

switch3

) (*RR := NOT switch1 AND (switch2 OR switch3)*)

Fig. 19 Example of operator modifiers in an IL program.

3BSE 021 358 R201 Rev B 47


48/62


49/62

Chapter 4: Programming Languages 4.4 Instruction List

Best System PerformanceIL is ideal for solving small straightforward problems. In the hands of an ex-

perienced programmer it produces very effective code resulting in applications

that are optimized for fast execution.

There is also another reason for using IL in order to optimize system perfor-

mance. During a period of several years a huge amount of software has been

written and thoroughly tested. Such software can be modularized into libraries

and reused even by programmers with no detailed knowledge of the internal

behavior.

Weak Software Structure

Since IL is a low-level language, great care should be taken in structuring the

code so that it is easy to understand and maintain. It is very important that IL

programs ar

Documents

110421 1 IEC61131 Lenguajes Escencial MB