ControlIT

IEC 61131 Control Languages

Introduction
IEC 61131 Control Languages
Introduction
Copyright © 1999 ABB Automation Products AB.
The contents of this document can be changed by ABB Automation Products AB with-
out 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 2004

Document number: 3BSE021358R4001
Printed in Sweden.

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.

3BSE021358R4001
 Contents

1 Evolution of Control Systems 9

1.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Programming Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Computer-based Programming Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Cyclic Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Soft PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Why Open Systems are Needed 25
2.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 31
3.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

3BSE021358R4001 5
Contents

4 Programming Languages 35
4.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Weak 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Action 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 3BSE021358R4001
 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.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 83
6.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.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 95
8.1 Control Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.4 Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Project 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

3BSE021358R4001 7
Contents

8 3BSE021358R4001
Chapter 1: Evolution of Control Systems 1.1 Introduction

Chapter 1
Evolution of Control Systems

1.1 Introduction
Almost all industrial plants need some kind of controller to 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 of transducers. 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.

3BSE021358R4001 9
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 History
The 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 a
large 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 today’s 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 3BSE021358R4001
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 today’s 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 distributed to 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 supervising process computer which administers alarms, recipes and
operations reports.

1880 1920 1970 1980 1990 2000

Mechanics

Relays

ICs

Computers

PLCs

Process
computers

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

The operator plays a very important role in today’s industry and many plant
installations therefore have a computer-based Supervisory Control 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.

3BSE021358R4001 11
1.3 Control Applications Chapter 1: Evolution of Control Systems

It is characteristic of today’s 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 are
programmed 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
smaller subprocesses. 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 Subsystems
A 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 for memory functions.

12 3BSE021358R4001
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 to
follow 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.

Desired Error
value SP-PV Controlled
variable
SP Control Actuator Process
algorithm
PV
Actual value
Transducer

Fig. 3 A closed-loop control system.

1.4 Relay Logic

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

3BSE021358R4001 13
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 3BSE021358R4001
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
to change 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 Control

The 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 in
order 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.

3BSE021358R4001 15
1.5 Computers for Process Control Chapter 1: Evolution of Control Systems

Programming Methods
All computer programs consist of a number of instructions which tell the com-
puter what to do when the program is run, or executed as programmers prefer
to say. Because computers process binary information, the computer’s 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 computer’s 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 the syntax 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 LDA
for fetching data and ADD for adding two numbers. A ready-made program
known as an editor is 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 also
assembler 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
debugging programs, 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 3BSE021358R4001
Chapter 1: Evolution of Control Systems 1.5 Computers for Process Control

Start

Editing
using editor F6
0A
A9
LDA IN1 23
Assembling
L1 SUB C 12
E3
CMP B F8
Test-running Assembler
using debugger 76
BNE L1
06
ADD D A3
No 45
Functioning STO OUT1 D3
properly? A2

Yes

Stop

Fig. 5 In low-level programming several supporting programs are used, such as an ed-
itor, an assembler and a debugger, in order to translate the program into machine code.

Programming using assembler instructions has both advantages and disadvan-

tages. The work demands 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 avail-
able in the computer’s 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 computer’s memory. This is
important in, for example, industrial robots and where very large series are to
be produced. Working with assembler is often called low-level language
because the instructions are similar to the computer’s 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 compiler or interpreter.

3BSE021358R4001 17
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 Pascal and the closely related
language C. 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 as source code, while the compiled result is
called object code.

02
Source code in Pascal 0C
A7
43
Profit := Income - Cost 37
E3
IF Profit>20 THEN PRINT "Profitable" F8
Compiler 86
ELSE PRINT "Loss" 16
A2
END 45
A2
05
A3
Fig. 6 Programs written in a high-level language are totally machine- 12
7B
independent and are translated to computer-specific machine code
by a compiler program.
The programmer writing in a high-level language does not need to know the
technical 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 3BSE021358R4001
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 today’s PLCs also
have arithmetic functionality. Many vendors are therefore using the term
Programmable Controller instead 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 Engineering
station

Memory Central unit

Bus unit

I/O unit
Input modules Output modules

Transducers Actuators
Fig. 7 The components of a programmable controller system.

3BSE021358R4001 19
1.6 Programmable Controllers Chapter 1: Evolution of Control Systems

I/O Units
A 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 range
4-20 mA, with 4 mA indicating the minimum value.

Programming Methods
The 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 3BSE021358R4001
Chapter 1: Evolution of Control Systems 1.6 Programmable Controllers

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 020
RP
A 003
= 201

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

Computer-based Programming Tools

Early 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. Control Builder Profes-
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 editor is used to define variables and for writing the control program
instructions. Most editors have syntax checking that 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 the
controller.
The compiler translates 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 and simulates
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.

3BSE021358R4001 21
1.6 Programmable Controllers Chapter 1: Evolution of Control Systems

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
and Function Block 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 Interval time

program 1 - 50 ms

Update
outputs

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

22 3BSE021358R4001
Chapter 1: Evolution of Control Systems 1.6 Programmable Controllers

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 Systems
In many large industrial plants there is a need for distribution of the entire
control function to several different programmable controllers and process
computers. This strategy will improve total performance and also reduce the
risk 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/O subsystems 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 PLC
One 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
Soft PLC. The Soft PLC is real-time software executing a control application
in a standard PC and communicating with the plant via a standardized modular
I/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.

3BSE021358R4001 23
1.6 Programmable Controllers Chapter 1: Evolution of Control Systems

24 3BSE021358R4001
Chapter 2: Why Open Systems are Needed 2.1 Programming Dialects

Chapter 2
Why Open Systems are Needed

2.1 Programming Dialects

The programmable controller is one of the most critical components in today’s
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 Quality

As 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
of program 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.

3BSE021358R4001 25
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 packages
have 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 Cost

During 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 as shareware, 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 customer’s 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. Today’s personal computers
have equally good, or even better, performance than yesterday’s 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 3BSE021358R4001
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 writ-
ten 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 PC’s 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.

3BSE021358R4001 27
2.5 Reusable Software Chapter 2: Why Open Systems are Needed

2.5 Reusable Software

Not so long ago, many “real programmers” measured their effectiveness by the
amount of program code they produced per day. Real programmers don’t like
to “waste” their time on structuring and detailed specification. Instead, they
move directly from a rough specification, often made by the customer, to cod-
ing in their favorite language, often ladder diagram or instruction list.
Today, even real programmers realize that the first phase in a project when the
overall 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 programmer’s 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 first programmable 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 today’s 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 plant
status. 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 a Distributed Control System (DCS).

28 3BSE021358R4001
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 Management Information 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 standard
called Manufacturing Automation Protocol (MAP) for communication be-
tween different programmable controllers and MIS. Unfortunately, the MAP
standard has so far not been particularly successful.

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

30 3BSE021358R4001
Chapter 3: IEC 61131-3 Standard 3.1 Main Objectives

Chapter 3
IEC 61131-3 Standard

3.1 Main Objectives

IEC 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 as program 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.

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

3.2 Benefits Offered by the Standard

Well-structured Software
The 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.
A function block is 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 Needs

The 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.
Today’s 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 Ladder
diagrams.
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 func-
tion block types using all the languages.

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

Software Exchange between Different Systems

Before the IEC 61131-3 standard was established it was not possible to port
control programs from one vendor’s 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 manufacturer’s 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 Association

Since 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 the
portability 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.

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

Portability Level contains 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, Full Compliance, provides exchange of complete applica-
tions, including configuration information, between different control systems.

34 3BSE021358R4001
Chapter 4: Programming Languages 4.1 Overview

Chapter 4
Programming Languages

4.1 Overview
The 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 M1
LDN A3
AND( A1
OR A2
)
A2
ST M1

LD IL
A1
A2 1
M1 := ( A1 OR A2 ) AND NOT A3; & M1
A3
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.

3BSE021358R4001 35
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 software
code 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 3BSE021358R4001
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

LD
Low
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 of common elements which are used in all
of the programming languages. This section explains the rules for using identi-
fiers, data types, constants and variables.

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

3BSE021358R4001 37
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.
Programmer’s 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 today’s systems are being
used 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 3BSE021358R4001
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 name
and the component name separated by a point, for example Pump3.On.

Constant Literals
By 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 for Duration data or for Time 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#.

3BSE021358R4001 39
4.2 Common Elements Chapter 4: Programming Languages

Variables
Variables 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 3BSE021358R4001
Chapter 4: Programming Languages 4.3 Ladder Diagrams

4.3 Ladder Diagrams

Ladder 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 contacts
and 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

switch2
Normally closed Coil
contact

Normally open
contacts

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

It is possible to create LD programs that contain feedback 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

3BSE021358R4001 41
4.3 Ladder Diagrams Chapter 4: Programming Languages

using one of the relay’s physical switches as an input contact. A person with
experience in computing would probably call this a memory bit.

start stop fan

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 Understand
Programming 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 3BSE021358R4001
Chapter 4: Programming Languages 4.3 Ladder Diagrams

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 control
applications. With increasing processing power and memory size with today’s
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, or subroutines, 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
sensors provide 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 time
when 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.

3BSE021358R4001 43
4.3 Ladder Diagrams Chapter 4: Programming Languages

Limited Support for Sequences

Most control applications have a need to divide the function into a sequence of
states. Each state represents a unique condition in the plant being controlled.
Normally, only one state is active at a time.
When sequences are constructed with ladder programming the normal method
is to assign one internal memory bit to each state and to use contact conditions
from the transducers to trigger transitions between the states. Each state con-
sists of a feedback loop using the memory bit as an alternative condition for
remaining in the state. The feedback loop of a state is normally broken by the
memory bit of a succeeding state. To get real-world actions the memory bits
are used as conditions in separate rungs to control the outputs.

state_3 transducer_a state_1

state_1 state_2

state_1 transducer_b state_2

state_2 state_3

state_2 transducer_c state_3

state_3 state_1

state_1 output_a

state_2

state_3 output_b

Fig. 17 Sequence program with three states controlling two outputs.

44 3BSE021358R4001
Chapter 4: Programming Languages 4.3 Ladder Diagrams

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 used
over 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.

3BSE021358R4001 45
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 Structure
IL is a language with a series of instructions, each on a new line. An instruction
consists of an operator followed 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 if
the 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 3BSE021358R4001
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 register or accumulator. 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 must
naturally 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 the
many 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.

3BSE021358R4001 47
4.4 Instruction List Chapter 4: Programming Languages

The C modifier indicates that the corresponding instruction may only be exe-
cuted if the RR contains the Boolean value TRUE.
Parentheses are used to delay the operation of some parts in the program. This
is needed to change the execution order of the corresponding instructions,
since there is only one result register. The left-hand parenthesis indicates that
the evaluation of the following instructions must be delayed until the right-
hand parenthesis is encountered.

Operator Modifier Description

LD N Loads operand in RR
ST N Stores current result from RR
S Sets the operand
R Resets the operand
AND N, ( Boolean AND
OR N, ( Boolean OR
XOR N, ( Exclusive OR
ADD ( Arithmetic addition
SUB ( Arithmetic subtraction
MUL ( Arithmetic multiplication
DIV ( Arithmetic division
GT ( Comparison greater than
GE ( Comparison greater than or equal to
EQ ( Comparison equal
LE ( Comparison less than
LT ( Comparison less than or equal to
NE ( Comparison not equal
) Executes delayed operation
CAL C, N Calls a function block
JMP C, N Jumps to label
RET C, N Returns from called function

Fig. 20 The IL instruction set.

48 3BSE021358R4001
Chapter 4: Programming Languages 4.4 Instruction List

Best System Performance

IL 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 are well documented since conditional jumps will otherwise be very
difficult to follow.
The behavior of the result register, with only one value available at a time,
makes it difficult to work with structured data variables. Most compilers have
no automatic function for checking whether the RR contains correct data for
the actual instruction code. Therefore, it is up to the programmer to ensure that
each instruction is given correct variable data.

Machine-dependent Behavior
Of all the five IEC languages, IL has been found to be the most controversial.
Unfortunately, the semantics, i.e. the way in which the instructions operate, are
not fully defined in the standard. For example, it is unclear how the result reg-
ister stores values of different data types. Normally, the RR is not intended for
storing structured data, which means that it is very difficult to obtain consistent
behavior when working with arrays or strings.
Another problem is that the control system behavior for error conditions is not
defined. This means that different system types may respond differently if the
programmer uses inappropriate data types. Errors can normally only be de-
tected when the system is running the application.

3BSE021358R4001 49
4.5 Structured Text Chapter 4: Programming Languages

4.5 Structured Text

Structured Text (ST) is a high-level language, similar to Pascal and C, that has
been specifically designed for use in programmable controllers. When devel-
oping large control applications there is a need for structured programming
tools. ST has proven to be such an effective programming tool, especially in
complex applications with many conditional statements and calculations.

Statements
All ST programs contain a list of statements, each ending with a semicolon
separator. Statements contain expressions which, when evaluated, result in a
value of a variable having any kind of data type. Expressions are composed of
operators and operands. The ST language supports five different types of
statements:
• assignment statement, variable := expression;
• selection statements, IF, THEN, ELSE, CASE
• iteration statements, FOR, WHILE, REPEAT
• function and function block control statements
• control statements, RETURN, EXIT
The language statements can be written in a fairly free style with spaces, tabs,
line feeds and comments inserted anywhere between operators and operands,
i.e. where a space is needed for separation.
An expression can be short, for example a literal constant, or very complex
involving many other nested operations. The assigned variable can be either
simple or structured containing any number of elementary data types.
motor := (start or motor) and not stop;
speed3 := temp1*temp2 - 5*value7;
IF speed3 < 0 THEN
tank_level := 25.8;
ELSE
tank_level := 30.6;
END_IF;
Fig. 21 Example of a simple ST program.

Statement text should be written in a structured way. The computer will accept
any number of spaces in a statement but it is good practice to place statements
at a fixed position according to their role in the hierarchy.

50 3BSE021358R4001
Chapter 4: Programming Languages 4.5 Structured Text

Operators in Expressions
The table below summarizes the arithmetic and Boolean operators in the IEC
standard. The operators are listed in execution order with the highest prece-
dence first:

Operator Symbol Precedence

Parenthesis () Highest priority
Function evaluation Function (argument list)
Negation - (before other operator)
Boolean complement NOT
Exponentiation **
Multiplication *
Division /
Modulus Mod
Addition +
Subtraction -
Comparison operators <, >, <=, >=
Equality =
Inequality <>
Boolean AND AND, &
Boolean XOR XOR
Boolean OR OR Lowest priority

Conditional Statements
Often there is a need to execute certain statements repeatedly, a specified num-
ber of times, or only when a certain condition is fulfilled. The IEC standard
provides a collection of conditional statements for this purpose.
FOR Statement
The statement FOR is used when the number of executions is known.
count := 0;
FOR i:=1 TO 10 DO
count := count + i;
END_FOR;
The variable count starts with the value 0 and increases by 1 for each time the
addition is repeated until the final value 10 is reached.

3BSE021358R4001 51
4.5 Structured Text Chapter 4: Programming Languages

WHILE Statement
The statement WHILE is used when other statements are to be repeated an
unknown number of times until the condition no longer is fulfilled.
WHILE switch1 OR switch3 DO
pump := FALSE;
alarm := TRUE;
END_WHILE;
REPEAT Statement
The REPEAT statement is very similar to WHILE but the difference is that the
statement will always be executed once since the condition is written
after the statement.
REPEAT
B := B + 1;
UNTIL B>10
END_REPEAT;
IF Statement
An IF statement is used when one or more other statements are to be executed
conditionally.
IF A>B THEN
B := A;
ELSEIF A<B THEN
A := B;
ELSE
A := 0;
B := 0;
END_IF;
If A and B have different values the highest value will be given to both, else
both of the variables will be set to zero.
When using conditional statements it is very important to avoid infinite loops.
All statements must therefore include a condition that can be fulfilled.

52 3BSE021358R4001
Chapter 4: Programming Languages 4.5 Structured Text

Calling Function Blocks

ST programs often need to access function blocks such as timers and counters.
Function blocks are invoked by a statement consisting of the instance name
followed by a list of named input and output parameter value assignments, all
of them written within parentheses.
Timer1( IN := switch3,
PT := delay1,
Q => lamp);
When switch3 is activated the lamp is turned on after the specified delay1.

Suitable for Complex Calculations and Looping

The ST language has an extensive range of constructs for assigning values to
variables, calling function blocks and creating conditional expressions. This is
very useful for evaluating complex mathematical algorithms, commonly used
in analog control applications.
No other IEC language can match the power of ST when iterations are needed,
i.e. when certain parts of the program code are to be repeated a fixed or a con-
ditional number of times.

High Threshold for Programmers

Of the five IEC languages, Structured Text is often the natural choice for
people with former experience in computer programming. Control engineers
without computer knowledge sometimes consider ST to be more complex with
a higher learning threshold than the LD or IL languages.
On the whole, ST is fairly easy to learn and a very effective tool for developing
control applications. The language is a good general purpose tool for express-
ing different types of behavior with all kind of structured variables.
Most programmable controllers supporting the SFC language use ST as the de-
fault programming language to describe the step actions in sequences.

3BSE021358R4001 53
4.6 Function Block Diagram Chapter 4: Programming Languages

4.6 Function Block Diagram

Function Block Diagram (FBD) is a graphic language in which the control
function is divided into a number of function blocks or functions connected by
flow signals. A function block may contain simple logical conditions, timers
or counters, but can also provide a complex control function to a subprocess in
a machine or even an industrial plant.

In1
In2 1 TON
& IN Q Out1
In3

Time1 PT ET Out2

Fig. 22 Example of an FBD program with two logical function blocks and a timer block.

Syntax for Function Block Diagrams

Each function block is drawn as a rectangle with inputs entering from the left
and outputs exiting on the right. All function blocks have a built-in algorithm
for calculating output values based on the status of the inputs.
The function block type name is normally shown within the block. For some
of the most common logical functions a standardized Boolean symbol may be
used instead of type names. The formal names of input and output parameters
are also shown within the block, close to the corresponding signal.
In an FBD program the normal signal flow is from the left to the right. Input
signals to function blocks may either come from transducer signals, from local
variables or from other function block outputs. Signal names are normally
shown at the corresponding connecting lines.
When working with Boolean signals, negated inputs or outputs can be shown
using a small circle placed at the corresponding line, close to the block symbol.
Some systems use a NOT function block instead of the circle.

54 3BSE021358R4001
Chapter 4: Programming Languages 4.6 Function Block Diagram

Function block type

TON
AND IN Q

Negation symbol PT ET

Input parameters Output parameters

Fig. 23 Some fundamental rules for drawing function block diagrams.

Standard Function Block Types

The IEC 61131-3 standard defines a small repertoire of rudimentary standard
function block types. These are predefined in most of today’s programmable
controllers. Standard function blocks are often used to construct user-defined
function blocks. The most commonly used blocks are:
• Boolean conditions like AND, OR, XOR and NOT
• Bistables
• Edge detectors
• Timers
• Counters
Bistables
Two types of bistables are available, SR and RS. Both of them have two Bool-
ean inputs and one output. The output is set (SR) or reset (RS) as a memory
when the triggering input (S1 or R1) momentarily becomes true. When the
other input becomes true the output returns to its initial state. If both inputs are
true the SR will be set while the RS will be reset.

3BSE021358R4001 55
4.6 Function Block Diagram Chapter 4: Programming Languages

SR bistable RS bistable

SR RS

S1 Q1 S Q1

R R1

S1 R1

Q1 Q1
R S

Fig. 24 SR and RS bistable symbols with their corresponding functions below.

Edge Detectors
There are two edge-detecting function blocks, Rising edge trigger (R_TRIG)
and Falling edge trigger (F_TRIG), which are used to detect the changing state
of a Boolean input. The output of the blocks produces a single pulse when a
transition edge is detected.
When the input changes state, according to the type of edge detector, the out-
put is true during one function block execution. After that the output remains
false until a new edge is detected.

Rising edge detector Falling edge detector

R_TRIG F_TRIG
CLK Q1 CLK Q1

CLK CLK

Q Q

Fig. 25 Edge detectors create a single pulse with the same duration as the execution
time of the function block.

56 3BSE021358R4001
Chapter 4: Programming Languages 4.6 Function Block Diagram

Timers
Timers are among the most used function blocks in a control application.
Whenever there is a need for a time delay between a change of state and the
corresponding action a timer can be used. In most programmable control sys-
tems the timing is based on the CPU system clock, which means that the speci-
fied time intervals are very precise.
There are three different types of timer function blocks, pulse timers (TP),
on-delay timers (TON) and off-delay timers (TOF). All of them have a Bool-
ean input called IN, a Boolean output called Q, an input of type time called PT
and an output of type time called ET.
The required delay (or pulse width) is specified on input PT (Preset Time)
while the actual elapsed time is shown on output ET (Elapsed Time).
A pulse timer is normally used to generate output pulses of a specified dura-
tion. When input IN changes to the true state the output Q follows and
remains true for a duration specified by input PT. The elapsed time ET is in-
creased linearly as long as the pulse output is true. When the pulse terminates,
the elapsed time is held until the input changes to false. Note that the output Q
will remain true until the pulse time has elapsed, even if the input changes to
false.
Both delay timers are used to delay an output action by the specified time PT
when a certain condition becomes true.
The on-delay timer delays the activation of an output. When the input IN be-
comes true the elapsed time at output ET starts to increase. If the elapsed time
reaches the value specified in PT, the output Q becomes true and the elapsed
time is held. The output Q remains true until input IN becomes false. If input
IN is not true longer than the specified delay in PT, the output remains false.
The off-delay timer delays the deactivation of an output. When the input IN
becomes false, the elapsed time starts to increase and continues until it reaches
the specified delay given by PT. The output Q is then set to false and the
elapsed time is frozen. When input IN becomes true the output Q follows and
the elapsed time is reset to zero.

3BSE021358R4001 57
4.6 Function Block Diagram Chapter 4: Programming Languages

Pulse timer On-delay timer Off-delay timer

TP TON TOF
IN Q IN Q IN Q
PT ET PT ET PT ET

IN IN IN
PT PT PT PT PT PT
Q Q Q

ET ET ET

Fig. 26 Timing diagrams for the three different types of timer function blocks.

Counters
Counters are another commonly used type of function block. These are de-
signed to be used in a wide range of applications, for example counting pulses,
revolutions, completed production batches, etc.
There are three types of counter blocks, up-counters (CTUs), down-counters
(CTDs) and up-down counters (CTUDs). CTUs are used to indicate when the
counter has reached a specified maximum value. CTDs indicate when the
counter reaches zero, on counting down from a specified value. CTUDs can be
used to both count up and count down and have two outputs indicating both
maximum value and zero.
A CTU has three inputs and two outputs. A CTU block counts the number of
pulses (rising edges) detected at the Boolean input CU. The input PV (Preset
Value) of data type integer defines the maximum value of the counter. Each
time a new rising edge occurs on CU the output CV (Counter Value) of type
integer is incremented by one. When the counter reaches the value specified in
PV, the Boolean output Q becomes true and counting stops.
If necessary, the Boolean input R (reset) can be used to set the output Q to false
and to clear CV to zero.

58 3BSE021358R4001
Chapter 4: Programming Languages 4.6 Function Block Diagram

Up counter
CU
CTU
bool CU Q bool Q
bool R R
int PV CV int CV=PV
CV=0
CV
Fig. 27 Example of a CTU counter block with preset value PV=5.

The CTD is very similar to CTU with three inputs and two outputs. A CTD
counts down the number of pulses detected at the Boolean input CD. The input
PV is used to specify the starting (integer) value of the counter. Each time a
new rising edge occurs on CD the output CV is incremented by one. When the
counter reaches zero, the output Q becomes true and counting stops.
If necessary, the Boolean input LD (load) can be used to clear the output Q to
false and to load the output CV with the value specified in PV.

Down counter
CD
CTD
bool CD Q bool Q
bool LD LD
PV CV=PV
int CV int
CV CV=0

Fig. 28 Example of a CTD counter block with preset value PV=5.

The CTUD is a combination of the other two counter blocks. It has two Bool-
ean inputs, CU and CD, used for counting up and counting down the value in
output CV. Similarly to the two other counters, the integer input PV defines the
counter’s maximum value. When the counter reaches the value specified in PV
the output QU is set to true and counting stops. In a similar way, the output QD
is set to true and counting stops when the counter reaches zero.
If necessary, the input LD can be used to load the value from PV to the output
CV while the input R can be used to clear the output CV to zero.

3BSE021358R4001 59
4.6 Function Block Diagram Chapter 4: Programming Languages

Up-down counter
CU
CTUD
bool CU QU bool CD
bool CD QD bool QU
bool R
QD
bool LD CV int
int PV LD

R
CV=PV CV=PV

CV CV=0

Fig. 29 Example of a CTUD counter block with preset value PV=3.

The CTUD is often used in applications where there is a need to monitor the
actual number of items in a process. It could, for example, be used to count the
number of products placed on and taken off a store shelf.

Similar to Electrical Diagrams

In many ways, a function block can be compared to an integrated circuit (IC),
the building block of today’s computers and other electronic devices. Like ICs,
function blocks can provide standard solutions to common control functions.
The connection lines between blocks symbolize signal flow in the system.
Electrical engineers who have experience in designing and analyzing circuit
diagrams often have a preference for programming with FBD.

Boolean Functions and Feedback are Easy to Implement

FBD is very suitable for describing Boolean logic with associated timers,
counters and bistables. Most programmable controllers have such function
blocks predefined in standard libraries for direct use by the programmer.
There is no other programming language where timers and counters are so
easy to implement as in FBD.
Many analog control systems, for example PID controllers, use closed-loop
control where some output signals are fed back and used as inputs in the con-
trol algorithm. The FBD program gives a good overview of signal flow in sys-
tems with feedback.

60 3BSE021358R4001
Chapter 4: Programming Languages 4.6 Function Block Diagram

Not Suitable for Conditional Statements

FBD programs have very weak support for conditional statements when one
or more actions are to be repeated for a specified number of times, or only as
long as a certain condition is fulfilled.
This kind of construct is much easier to accomplish in the ST language with
one of the statements FOR, WHILE, REPEAT or IF.

3BSE021358R4001 61
4.7 Sequential Function Chart Chapter 4: Programming Languages

4.7 Sequential Function Chart

Sequential Function Chart (SFC) is a very powerful language for describing
the structure of a control system. Since SFC is not a full programming lan-
guage it requires instructions taken from the other languages to construct a
complete application program. Many experienced programmers consider SFC
combined with ST statements to be the ultimate method for developing struc-
tured control applications.
The SFC standard has evolved from Grafcet, a graphical method of describing
sequential behavior. Most European vendors have offered support for Grafcet
in their most advanced programmable controllers since the beginning of the
1990s.
One of the most important aspects of SFC is that it gives an overview of all the
main states of a control application, all the possible changes of states and also
the reasons why these changes may occur.
The SFC language can be used to divide the entire control application into
parts that are executed only when needed, providing a method of optimizing
the performance of the programmable controller.
Sequences can also be hierarchical with a main sequence containing several
subsequences. The result is an application program with a good overview pro-
viding detailed information about the controlled process objects.

Chart Structure
SFC is a method of dividing the control function into a series of steps repre-
sented by rectangular boxes and connected by vertical lines. Each step repre-
sents a physical state of the system being controlled. On each connecting line
there is a horizontal bar representing a transition. The transition is associated
with a transition condition which, when true, deactivates the step before the
transition and activates the step after the transition. The execution flow is nor-
mally down the page, but SFC can also branch backwards in the chart.
Each step is normally associated with one or more actions. These actions
describe the actual physical behavior in the plant, e.g. open valve, start motor,
and so on. An action can, in some editors, be described directly in the associ-
ated step rectangle. However, in most editors the actions are described as sepa-
rate program statements (normally in ST language) in other code blocks or in
an separate editor window associated with the step. An important consider-
ation in SFC programs is that only the code in active steps is executed.

62 3BSE021358R4001
Chapter 4: Programming Languages 4.7 Sequential Function Chart

All SFC sequences must have an initial step identifying where program
execution starts after system initialization. This step is drawn as a rectangular
box with double border lines. The initial step remains active until the following
transition enables flow to the next step.
Some editors allow the programmer to describe short transition conditions
directly on the SFC, close to the corresponding bar. However with more com-
plex conditions it is better to put the code in a separate window. The program
is often written in ST language but many editors also allow the use of LD, IL,
or FBD languages.
When the sequence has finished, the flow can be terminated by a step with no
associated action. If necessary, the sequence can also repeat the same behavior
cyclically. Cyclic execution is enabled by a conditional branch backwards to
the first step in the flow. To avoid cluttering the SFC with crossing lines,
branches are drawn with a starting arrow where the branch begins and a con-
cluding arrow at the step where the branch ends up. In order to clarify the flow
the transition name is written at both places.

Initial step
Start Transition
Tr1 Transition conditions with code
in other windows
Pusch

Tr2 Steps with code in other windows

Drill

Tr3

Wait

Tr4
Label

Tr5

Stop

Tr6

Fig. 30 Example of an SFC program for an automatic drilling machine. Note the cyclic
execution being enabled by the Tr6 transition condition.

3BSE021358R4001 63
4.7 Sequential Function Chart Chapter 4: Programming Languages

Steps and Transitions

All steps within an SFC must have unique names and may only appear once in
each flow. Every step has an automatically defined Boolean Step active flag
variable that is true while the corresponding step is active. The Step active flag
is given the same name as the step plus the suffix X, e.g. Drill.X. It can be used
within the current SFC to control the logical flow.
Two adjacent steps must always be separated by a transition condition which
produces a Boolean result. A transition that always occurs can be expressed by
the Boolean literal TRUE. The transition conditions may contain any kind or
complexity of statements, variables and parameters, as long as the result can
be expressed as a Boolean variable.

Action Descriptions
Steps in an SFC are used to describe the states of a controlled plant or machine.
When the programmable controller executes an SFC program the state model
only works as an internal memory representation of the control function. In
order to get real-world actions each state has one or more action descriptions
containing program code controlling the physical objects. Any of the four IEC
languages can be used to describe the behavior of an action.
Action descriptions are normally placed in rectangular boxes that are attached
to the step with a connection line. To avoid overloading the SFC with too much
detailed information the boxes can be folded in or out. Most editors use a sep-
arate window or another code block for specifying the actions.

P1 Drill_P1 Drill_Motor := Drill.T;

Drill N Drill_N
P0 Drill_P0

Fig. 31 Example of a step with the associated actions folded out and one of them
described in a separate editor window.

Each action can have one or more action qualifiers that determine when and
how the action is executed. Most editors support the following three action
qualifiers.
• The N action qualifier (Non-stored) causes the action code to be executed
continuously as long as the step is active.

64 3BSE021358R4001
Chapter 4: Programming Languages 4.7 Sequential Function Chart

• The P1 (Pulse rising edge) action qualifier causes the action code to be
executed once when the step becomes active.
• The P0 (Pulse falling edge) action qualifier causes the action code to be
executed once when the step becomes inactive.
To use one or more of the action qualifiers the programmer writes the code
statements in the associated editor window. It is not necessary to use all three
action qualifiers. Most sequences use the N action qualifier, but it is possible
to leave all three qualifiers empty resulting in a step without any actions.

Sequence Selection and Simultaneous Sequences

In its simplest form, an SFC program consists of a series of steps in a closed-
loop executed continuously. This type of system (e.g. Fig. 30 on page 63) has
only one main flow path.
In many systems there is a need for two or more branches in the sequence flow,
often referred to as sequence selection. This is required in many batch process
applications. In the example below with divergent paths, each branch starts
and ends with a transition. When either of the transition conditions Tr2 or Tr3
becomes true, the corresponding branch is selected and execution continues
along that path. Note that only one branch can be executed at a time. If more
than one transition condition is true the leftmost branch has the highest execu-
tion priority. When the last transition in the selected branch becomes true the
flow converges back to the main flow.

S1

Tr1

S2

Tr2 Tr3

S3 S4

Tr4 Tr5

S5

Tr6

Fig. 32 Example of a sequence selection with two branches.

3BSE021358R4001 65
4.7 Sequential Function Chart Chapter 4: Programming Languages

We have earlier seen how divergent paths can be used to execute alternative
paths in sequences. An important characteristic of such parallel branches is
however, that only one step in one of the branches may be active at any time.
However, in many batch process applications there is a need for simultaneous
sequence structure with several branches. The main sequence is used for pri-
mary process control, while secondary parallel sequences are used to monitor
that the process is running normally. Such parallel sequences can e.g. check
that plant temperatures and pressures are within required limits, otherwise the
control system may shut down the process.
In the example below, all three divergent branches start with a common tran-
sition condition. Execution then continues in parallel and independently along
all three paths until convergence is reached. Both the divergent and the conver-
gent flow in simultaneous sequences are drawn with a pair of lines to distin-
guish the construct from a sequence selection.
The transition condition that succeeds the simultaneous sequence structure
will not be tested until all the branches have finished execution, i.e. when the
last step of each branch is active.

Start

Tr1

Acid

Tr2

Water Press Monitor

Tr3 Tr4

Heat Temp

Tr5

Wait

Tr6

Fig. 33 Example of a simultaneous sequence with three continuous branches.

66 3BSE021358R4001
Chapter 4: Programming Languages 4.7 Sequential Function Chart

Subsequences
One of the main uses of SFC is as a tool for developing the top down design of
the control function in a complex plant. Most processes can be described by a
relatively small number of main states, each representing a subprocess with a
number of minor states.
Some editors provide a method for dividing large SFC programs into a number
of subsequences, each represented by a general symbol. A subsequence may
in turn contain other subsequences which provides a powerful tool for struc-
turing the overall control function into any number of hierarchical levels. This
allows attention to be focused on either the overall behavior of the entire plant
or on the detailed operation of the controlled process objects.
A subsequence usually contains sequence parts that perform a set of logically
related actions. Steps and actions from different hierarchical levels are never
visible at the same time. To study the inside of a subsequence the programmer
has to step into the subsequence which changes the SFC view, so that only the
contents of the selected subsequence are displayed.

Advice on Good Programming Style

Names of steps, transitions and actions should be unique within each program
organisation unit (e.g. function block). It as also wise to use meaningful names
whenever possible.
Try to keep all SFCs as small as possible and focused on the overall behavior.
It is better to put detailed behavior in the action blocks or in other SFCs at a
lower hierarchical level.
It is good practice to reduce the interaction between simultaneous sequences
to a minimum.
Never allow step actions from different simultaneous sequences to change the
same variables.
Avoid using constructs in which a divergent path branches out of a simulta-
neous sequence since this may lead to a sequence that never completes or
behaves unpredictably.

3BSE021358R4001 67
4.7 Sequential Function Chart Chapter 4: Programming Languages

Powerful Tool for Design and Structuring

SFC is a very suitable top-level design tool in the early phase of a project, but
can also be used to describe the more detailed behavior of the plant objects
being controlled.
The SFC’s graphical metaphor can be used from the beginning, to give an ini-
tial representation of the overall behavior of the system. Since the description
is very easy to follow SFC is a very suitable means of communication between
the customer and the programmer.
In the early phases of a project, there are normally many aspects of the system
behavior that have not been defined. By using an easy-to-follow tool for the
preliminary specification the number of misunderstandings between customer,
system designer and programmer can be reduced to a minimum.
The SFC schemes produced in the first phase of a project can be further speci-
fied and refined as new information becomes available. Actions associated
with overall steps can then be described via other nested SFC schemes.
The good continuity of SFC from the initial phase to the refining design phases
makes it very popular among system designers and programmers.

Other Programming Languages are Needed

Even though SFC has many advantages as a design and structuring tool it is
not a complete programming language. Therefore, the transition conditions
and action descriptions have to be programmed with one or more of the other
four IEC programming languages.
Most experienced programmers prefer the ST language as a complement to
SFC. Therefore, the vast majority of programmable controllers use ST as the
default language for detailed descriptions in SFC schemes. Some controllers
also allow programming with FBD or IL.
Although it is possible to implement simple Boolean conditions with the help
of transitions in SFC schemes, this is not recommended since the resulting
code will be much longer and therefore slower in executing than code in other
programming languages.

68 3BSE021358R4001
Chapter 4: Programming Languages 4.8 Function Blocks

4.8 Function Blocks

All IEC 61131-3 software applications can be broken down into functional
elements called program organisation units (POUs). A POU may contain
functions, function blocks or entire programs.

Application

Program Program

Function block Function block

Function Function block

Function
Function block

Function Function block

Fig. 34 The abbreviation POU is a common name for all these program parts.

Function blocks may be regarded as basic building blocks for control systems.
The IEC standard ensures that function blocks can be realized using any of the
five programming languages. Each function block is a well-packaged software
module that can easily be reused in other parts of the control application.
A function block can be compared to an integrated circuit (IC) which is used
in almost all electronic equipment. The use of ICs has simplified the design of
electronic hardware enormously. Function blocks can provide a similar off-
the-shelf solution to common control problems.

IC with counter Up counter

CTU
CU Q
R
PV CV

Fig. 35 Comparison between an IC and a counter function block.

3BSE021358R4001 69
4.8 Function Blocks Chapter 4: Programming Languages

The ability of a function block to store both data and algorithms means that it
is possible to develop truly encapsulated control functions. A function block
describes both the behavior of data and the data structure.
The use of function blocks encourages well-structured design which in
return will speed up program development considerably. This is especially true
in large plants containing a lot of similar control functions which means that
function blocks can be reused many times.
It may also be interesting to compare function blocks with objects used in
object-oriented programming. Function blocks contain truly encapsulated data
and also have methods (the algorithm of the control function) for processing
the data. However, other features from object-oriented languages, like
inheritance, are not fully supported by function blocks.
Do not mix up function blocks with the programming language FBD, which
uses a number of predefined function blocks. A function block may be defined
using any one of the five programming languages. Function blocks may also
be called from all the five programming languages.

Type and Instances

One of the main reasons for programming with function blocks is the ability
to reuse parts of the application software several times. This is accomplished
by first establishing a function block type and then creating one or many func-
tion block instances of that type.
The function block type contains two parts:
• a specification of the data structure for input parameters, internal variables
and output parameters, and
• an algorithm that calculates output parameters using the input parameters
and, if necessary, local variables for intermediate storage. The algorithm
may be expressed in any one of the five IEC 61131-3 programming lan-
guages.
A function block instance, also only called function block, is a unique set of
data values considered together as a structure based on the common rules in
the type algorithm. These data are required since the function block has to re-
member its values between each call in the application program.
The function block instance only contains data that are unique to the particular
set of function block type. This means that although a function block type may
use a very complicated algorithm the memory required to store the data for

70 3BSE021358R4001
Chapter 4: Programming Languages 4.8 Function Blocks

each function block instance may be very modest. An application program

based on several function blocks therefore requires less memory than pro-
grams containing duplicates of code.
Each function block instance is given a unique function block name for identi-
fication purposes. The name is shown above the function block symbol.
Function block type
Variable declarations
Converter
Converter1

Converter2
Function blocks

Converter3

Algorithm
Fig. 36 Function block type and function blocks. The same algorithm is used several
times to calculate the unique sets of data in each function block.

User-defined Function Blocks

In order to fully utilize the potential of function blocks, programmers should
develop their own function block types for all program parts that can be reused.
Most of today’s programmable controller editors allow the user to define the
function block algorithm using any of the five programming languages. In
many cases, the ST programming language is the most suitable for writing the
algorithm. Many user-defined function blocks are also constructed by combin-
ing standard function blocks into more complex structures.
A user-defined function block has a close resemblance to an entire application
program. The function block is given a unique type name, has its own
variables and parameters and a characteristic algorithm describing the tasks it
performs. Local variables are only available inside the function block and are
used for intermediate storage by the algorithm. Parameters are used to transfer
data in to or out of the function block.
When designing a new function block type, it is always worth considering as
many current and future uses of the block as possible. There are many advan-
tages of constructing well-proven function blocks that can be used to solve a
wide range of control problems.

3BSE021358R4001 71
4.8 Function Blocks Chapter 4: Programming Languages

On the other hand, care should be taken not to include so many features and
variations into the function block that it becomes cumbersome to use.

Fig. 37 Example of a user-defined function block with two

statistical calculations.

Differences between Functions and Function Blocks

Most programmable controllers have a number of predefined functions that
can be used in expressions like variables or constants. Functions may be used
in all the five programming languages. Among the most commonly used func-
tions are mathematical ones such as cos, sin, tan, exp or log, and conversions
like real_to_int or time_to_string.
The IEC 61131-3 standard states that when a function is used it should result
in one and only one value. This value is calculated from the function’s input
parameters. Any number of parameters of any type may be used in a function.
A function always results in the same value for the same input values.
When using a predefined or custom function block the type must always be
created and given a unique function block name. Function blocks communicate
via input and output parameters. Each function block results in a unique set of
parameters.

72 3BSE021358R4001
Chapter 4: Programming Languages 4.8 Function Blocks

A function block cannot be used in expressions, it has to be called. When

called, the programmer has to connect both input and output parameters to
local variables in the POU. Contrary to functions, a function block can create
different output parameters although the input parameters have the same val-
ues. For example, this is the case for a counter which counts up every time it
is called and remembers its values until the next count up.
Control Builder Professional from ABB has an increased functionality con-
cerning functions as regards the standard IEC 61131-3. Here, a function can
have both input and output parameters. If a function has output parameters it
must be used like a function block.

How to Use Function Blocks in Control Programs

Before a function block type can be used, the programmer has to create a fuc-
tion block of it and give this a unique name. In the programming editor this is
normally done via the window used to declare variables.
To create a function block means almost the same as making a copy of the
function block type data. The programmable controller then reserves individ-
ual memory space for the variables and parameters in the function block type.
To call a function block with the ST language, you first write the name of the
function block followed by a parenthesis. Within this parenthesis you have to
fill in the local variables that connect to the parameters in the function block.

Fig. 38 A function block from Fig. 37 on page 72

connected to local variables in an ST program.

3BSE021358R4001 73
4.8 Function Blocks Chapter 4: Programming Languages

With the IL programming language you have to call a function block by using
the instruction CAL followed by the function block unique name. The local
variables are specified in a similar way as with ST, as described above.
When a function block type is used with the FBD language the editor presents
the function block instance as a graphical symbol. The programmer only has
to connect the input and output parameters to local variables.

Interaction between Languages

All the five IEC programming languages have their advantages and disadvan-
tages and no single one of them is suitable for all control tasks. Programmable
controllers that are IEC compliant allow the programmer to choose the most
suitable language for each task.
One of the main objectives of the IEC standard is to encourage well-structured
program development by breaking down the total function into a number of
program organisation units (POUs). Such POUs may be programmed in any
of the five languages and it is strongly advisable to combine the benefits of
more than one language in a total plant application.
SFC is by far the most suitable language for the early design and structuring
of a control application. It works both as a communication tool between the
customer and the programmer and as a structuring tool for the overall design
of the control application.
Since SFC is not a complete language, all logical conditions and calculations
have to be written in the other languages. Experienced programmers often
prefer the ST programming language since it gives a compact description and
has several tools for conditional execution and powerful mathematical func-
tions. FBD is another alternative giving a very good overview of logical con-
ditions, but this language unfortunately only has limited power for conditional
execution.
Programmers with previous experience of LD or IL languages may, of course,
use their favorite language, although they do not provide the same power as ST
or FBD. Application programs from older control systems may be transformed
relatively easily to IEC compliant programmable controllers by using these
two languages.

74 3BSE021358R4001
Chapter 5: Object-oriented Programs 5.1 New Life for an Old Method

Chapter 5
Object-oriented Programs

The IEC 61131-3 standard for programmable controllers is not the only effort
towards better program quality, standardization and the reuse of existing pro-
grams in new projects. During the past decade, many program projects have
been realized with a technique called object-oriented programming. In this
chapter, that technique will be compared with the IEC standard for program-
mable controllers.
Examples of object-oriented programming languages include Simula, Small-
talk and C++, the latter being a development of the language C. Other success-
ful examples using object-oriented techniques are the operating systems for
the Macintosh and Windows, both of which have an extensive degree of stan-
dardization of man/machine communication.
Compared with programs that have been produced using more conventional
tools, object-oriented programs require both more memory and better perfor-
mance from the computer. The increased demands on the hardware, however,
can be balanced by great savings in time and improvements in the quality of
the software.

5.1 New Life for an Old Method

Thinking in an object-oriented manner is perhaps new to many system analysts
and programmers, but the method is really just a return to an old and more nat-
ural way of describing problems. One thought-provoking consequence of this
is that beginners often learn to program using object-orientation more quickly
that experienced programmers, who are hindered by their own traditional way
of thinking.
In order to explain the principles of object orientation and some of the basic
concepts, we shall look briefly at a cell, which is the basic building block for
all life. Every cell has a very specialized task, which may be anything from
converting energy to producing movement. The information on how the cell is
to carry out its task is stored in the cell nucleus. The behavior of the cell may

3BSE021358R4001 75
5.1 New Life for an Old Method Chapter 5: Object-oriented Programs

vary according to the particular chemical substances which it may contain at

any instant.
All cells are contained within a membrane which has two important tasks; the
first is to protect the cell so that foreign material cannot enter it, and the second
is to screen and separate the internal activity of the cell from surrounding cells.
All communication between cells occurs by means of chemical substances
which pass through the cell membranes.

Object

Methods

Variables

Message

Fig. 39 A living cell is object-oriented in the way it works and interacts with other cells.

The living cell is an object with a function which is determined by methods in

the cell nucleus and by the particular chemical substances which are available,
i.e. the variables. Cells coordinate with other cells via chemical messages
which pass through the membrane, thereby affecting the variables. A message
consists of one or more parameters with data which affects specific variables
in the cell.
Note that the internal activity of the cell is completely separate from that of
surrounding cells. In order to coordinate with other cells it is sufficient to send
chemical messages. The receiving cells then react by carrying out the required
action. In other words, it is sufficient to send orders as to what should be done
but not how it should be done.
There are many different types of cell, but all have the same class or definition
of their internal structure and function. The class of cell, however, allows sev-
eral subclasses with different variations. Examples of these are plant cells with
hard membranes, blood cells which are mobile and specialized for the trans-
port of gases, and muscle cells which can alter their shape and carry out work.
Every subclass occurs in a large number of individual instances which have al-
most identical characteristics.

76 3BSE021358R4001
Chapter 5: Object-oriented Programs 5.2 Objects in the Plant

5.2 Objects in the Plant

A necessity for being able to work in an object-oriented manner is of course
that the total function in the industrial plant can be divided up into subfunc-
tions comprising a number of objects. Every object is then programmed with
its own program object, which in the IEC 61131-3 standard, is called a
program organisation unit (POU).
The simplest implementation is when actual physical objects each have their
own corresponding program object. Examples of such objects might be valves,
PID controllers, robots, etc. In industries where raw materials are processed, it
is by no means clear where the boundaries should be drawn between objects.
The aim of drawing boundaries is partly to achieve a simple functional de-
scription, and partly to minimize the total requirement for communication be-
tween objects. The programs for the different objects can then be tested
individually before the total function is commissioned, which reduces the risk
of program errors.

Fig. 40 Object distribution on the right is more efficient as it needs less communication.

The vast majority of computer programs produced by traditional methods are

designed to solve a specific problem. The program designer then has to take
all the details into account, and to write unique programs for every application.
Such programs are difficult to use in other, similar installations. In most cases,
it is quicker to write completely new procedures than to adapt already existing
programs to new tasks.

3BSE021358R4001 77
5.3 Data Flow in Real-time Systems Chapter 5: Object-oriented Programs

If program objects (function blocks) which correspond to actual physical

objects are used instead, then there is a greater likelihood that the programs can
be reused. The main part of the programming time would then be taken up in
combining and connecting together well-proven program objects to produce
finished systems. The system designer then does not need to know in
detail how the final objects work internally, but only how they interact with the
environment. Programming a system then becomes a matter of selecting suit-
able objects which can be connected together and thereby simulate the real-life
functioning of the installation. In order for it to be possible to use program
objects efficiently, they must be well documented, particularly regarding their
interface with the outside world.
The situation can be compared with the industrial manufacturing of products
where functional units are assembled (e.g. cars) with the help of a large num-
ber of well-proven standard components. Some of these components may have
relatively complex functions, such as the electronic fuel injection system.
Given that their interface with the outside world is carefully specified, com-
plex components of this type can be used without having to have a knowledge
of their internal functioning.

5.3 Data Flow in Real-time Systems

Industrial control systems are real-time systems, which means that changes in
the input signal require immediate action on the corresponding output signal.
An example may be a machine where some movement has to be stopped when
a particular limit is reached. If the controller does not react in time, the ma-
chine may be damaged or the operator injured. The consequences of a delayed
reaction therefore become unacceptable.
For certain functions, on the other hand, such as printing out and reporting, a
certain delay between cause and effect can be accepted. A delay in the opera-
tor’s work can naturally have an adverse effect on production, but as long as
the delay is kept at a reasonable level the effect will be minimal.
In summary, we can say that a real-time system is predictable. Regardless of
the status of the input signals and the internal condition of the system, we have
to be able to guarantee correct answers to all conceivable occurrences within
a predetermined time.
Another notable characteristic of process control is that the internal state of a
POU can be altered without any external influence from the input signals from
the process. This, for example, is the situation in a PID controller, where the

78 3BSE021358R4001
Chapter 5: Object-oriented Programs 5.4 Program Sorting

output signal is calculated as the sum of the control error, its integral and its
derivative. The integral part is changed automatically with time, which means
that the output signal has to be updated at regular intervals. Similarly, the out-
put signal from a timer has to be updated when the set time delay expires.

Fig. 41 Example of data flow between program POUs in a real-time system.

In an object-oriented system the objects send messages to one another when

changes occur. When the receiving object gets the message, the information is
stored in the object’s local variables. Under normal circumstances, several
messages are required from other objects before the particular object sends
new messages. This type of event-controlled activation of objects results in a
complex system in which it is difficult to predict the behavior in all conceiv-
able situations, and where one often finds a delay between cause and effect.

5.4 Program Sorting

In order to fulfil the demands made on a real-time system, the POU must have
constant access to current input data from the process and from other objects.
In many real-time systems the object-oriented model is complemented with a
mechanism which determines the ordering of messages on the basis of the data
flow between the objects.
In a data flow-controlled model of this type, the object is active all the time.
The object’s program code is executed when all the input data are available. As

3BSE021358R4001 79
5.4 Program Sorting Chapter 5: Object-oriented Programs

soon as the output data have been calculated they immediately become avail-
able to other POUs. This leads to a new execution, etc., in cyclical succession.
During compilation, an analysis is first carried out of the data flow between
objects. The total function of the network of objects is then translated into a
program list divided into blocks, which are then sorted into a suitable order.
Sorting of the object’s program blocks is a complex operation, the aim of
which is to achieve the best ordering for their messages.

Fig. 42 During compilation the pro-

gram code of the objects is sorted in
order to give a suitable order for
their data flows (compare previous
diagram). The total program is exe-
cuted cyclically with a predeter-
mined interval time.

The compiled program is executed cyclically at a specific frequency. Changes

in the incoming signals and local variables therefore affect the output signals
at the end of each completed program cycle. The interval time (cycle time) of
the program is determined by the demands on the maximal delay time in the
process. Because different POUs may have very variable time demands, the to-
tal program can be divided up into a number of program parts, each with its
own interval time.

80 3BSE021358R4001
Chapter 5: Object-oriented Programs 5.5 Reuse of Code

5.5 Reuse of Code

Many programmers strive to design program objects which exactly imitate
real-life process objects and which contain the same control functions. Most
installations contain a large number of more or less similar variations of
process objects. Examples of these are valves with on/off, continuous or three-
position functions. It is therefore important to look for patterns and to design
general function blocks which can be reused with minimal adaptation.
In general object-oriented systems, program objects often are reused by a
method known as inheritance. This means that we create abstract classes of
objects which describe characteristics common to several different objects.
Abstract classes in many cases lack a physical counterpart in reality. New,
more specialized classes can be created from this type of father class, and these
will automatically inherit all the father’s characteristics.
In real-time systems there is less need to create or change program objects
while the system is in operation. Concrete classes called POUs (functions,
function blocks or programs) are therefore used instead of the method of
inheritance. The programmer starts by defining the function block and then
creates the required number of instances (copies of data sets).

5.6 Libraries
Nowadays, hardly any companies manufacture their own screws, nuts or sim-
ilar components. The production of standard components is carried out by a
few large companies who have long experience of the business and who can
produce goods of high quality at a low price. When it comes to program devel-
opment using traditional methods, on the other hand, there are still many who
are rediscovering the wheel over and over again.
One of the greatest advantages of object-oriented programming is that it is
easy to reuse objects with standard functions. The software for commonly
occurring objects is then produced by people with long experience which re-
sults in high quality. Examples of objects of this type are PID controllers,
alarm functions, communication units, etc. It is important to document the in-
teraction of the objects with their surroundings accurately, so that it is possible
to use them without knowing anything about their internal function.
Most IEC compliant programmable controllers today are delivered with a
large number of ready-made functions and function blocks stored in standard
libraries, for example, common functions such as timers, counters, pulse gen-
erators, PID controllers, limiters, etc.

3BSE021358R4001 81
5.6 Libraries Chapter 5: Object-oriented Programs

The standard modules are produced by people with many years’ experience of
applications in the process industry. This guarantees high quality in terms of
the modules’ function
.

Fig. 43 The standard function block library

supplied with Control Builder Professional.

In the design of application programs it is important for the programmer to use

the standard functions and function blocks as often as possible. Several stan-
dard function blocks can also be combined into user-defined function blocks.
It should, however, be noted that there is a considerable knowledge threshold
for the programmer to surmount before it becomes possible to make full use
of the advantages of program libraries. In order to be able to use the standard
function blocks to the full, one must have a general view of their capabilities
and limitations, which can take a considerable time for complex systems.

82 3BSE021358R4001
Chapter 6: Control Modules 6.1 Control Module Concept

Chapter 6
Control Modules

The IEC 61131-3 standard does not fully support all requirements for object-
oriented programs. Some vendors of programmable controllers have therefore
extended their systems with extra functionality. The engineering tool Control
Builder Professional from ABB provides an extension called control modules.

6.1 Control Module Concept

A control module is a container for both application programs and graphical
objects. Control modules may represent simple process objects, like valves
and motors, or more complex subprocesses, like tanks and mixers. Control
modules are created with a graphical editor providing basic shapes, interaction
objects and composite objects.
Control modules facilitate structuring of large controller applications. The use
of control modules promotes object-oriented data flow programming and
yields flexible and efficient automation solutions.

Application
Material A
Material A Conveyor 1
Submodules

Conveyor 2

Material B Code for

internal
behavior
Submodule
Mixed product handling the
interface to
neighbors

Fig. 44 Mixer process controlled via object-oriented control modules.

3BSE021358R4001 83
6.2 Graphical Programming Chapter 6: Control Modules

A control module may have an application program inside the module. Appli-
cation programs can be written in any one of the five IEC programming lan-
guages described in Chapter 4.
Control modules also provide basic supervision capabilities. Current process
status may be presented graphically and the user can feed in parameters
through command buttons and input fields.
Control modules have a great deal in common with IEC function blocks, but
they also expand the functionality with new features such as graphical pro-
gramming and automatic code sorting.

6.2 Graphical Programming

Control modules are normally created in the Control Module Diagram Editor
which is accessed from the Project Explorer window. This window is made up
of two toolbars, a status bar and the drawing area. The graphics toolbar on the
left contains basic autoshapes such as text, lines, squares, ellipses, segments
and polygons. All graphical objects may be freely positioned and scaled and it
is possible to change the object color. The drawing area normally has a visible
grid which simplifies exact positioning of objects. Text objects may be either
static or used for displaying actual parameter values in the application.

Fig. 45 The project explorer shows the hierarchy of all control modules which are
edited in the Control Module Diagram Editor. Compare this program with Fig. 44.

84 3BSE021358R4001
Chapter 6: Control Modules 6.3 Automatic Code Sorting

The graphical toolbar also has ready-to-use interaction objects, such as com-
mand buttons, option buttons, check boxes, input fields, windows buttons and
non-graphical interaction objects. Such objects make it possible for the user to
change process variables and open or close windows while the programmable
controller is executing the control application. The non-graphical interaction
button is invisible in online mode and is therefore normally placed on top of
another graphical object.
Finally, there are four composite objects: image selectors, string selectors, bar-
graphs and trend-graphs, which may be used for more advanced functions. The
image selector is used for displaying one of several pictures or control modules
in a specified position. The string selector is used in a similar way to display
one of several text strings. The bar-graph tool is used to produce a graphical
presentation of one or more real variables in bar form. The trend-graph is used
for presenting trend curves, that is, several values of variables over a given
time period.
The visibility of objects may be controlled by Boolean variables which offer a
powerful way of showing only the main functionality and temporarily hiding
unnecessary details.

6.3 Automatic Code Sorting

As was explained earlier, in Chapter 5.3, real-time systems are sensitive to the
order of execution in different parts of the control program. In application pro-
grams based on function blocks the programmer has to deal with the sorting
manually which may be very difficult and time-consuming in large plants.
A very important difference between function blocks and control modules is
that the control module code blocks are executed in an order based on optimal
data flow, as determined by the compiler. Control modules are only executed
once per scan (cycle), whereas function blocks may be executed several times
per scan (or not at all). The automatic program sorting of control modules
eliminates program errors due to incorrect execution order.
For control modules, the compiler analyzes each code block separately with
respect to which variables are read and written by each block. Based on the re-
sult of that analysis, the compiler then determines the optimal execution
order. A code block that assigns a value to a variable has to be executed before
other blocks that need to read this value.

3BSE021358R4001 85
6.4 Applications for Control Modules Chapter 6: Control Modules

The technique is called code sorting and means that the optimal execution
order will be based on data flow instead of program flow (as is the case for
function blocks).
V1

Control module 1 Control module 2 Control module 3

V1 := 10 + P1; P1 := 2; P1 R1 := V1 - 10;
V2 := 20 * P2; P2 := 3 * P1; P2 R2 := P1 + P2;

P1
P2

Fig. 46 Automatic code sorting detects that the control module 2 must be executed first,
followed by module 1 and finally module 3.

Since the execution order of the code blocks in the control modules is deter-
mined automatically, it is possible for one module to make a request to another
module and to react to the answer within the same scan (cycle).
However, when more than one control module uses the same variable for both
reading and writing, the compiler gives a warning message that a program loop
exists, meaning that the execution order cannot be resolved automatically.
Such a problem can be solved by introducing a new intermediate code block
with an extra variable storing the result from the previous scan.

6.4 Applications for Control Modules

Before you start to design a control application you should decide whether to
use traditional sequence programs with function blocks, or an object-oriented
solution based on control modules. The choice depends on both application
size and the need for reusable program objects.
As a general guideline, traditional programming is often suitable for small
control applications, while control modules are recommended for large pro-
cess applications. In large applications the performance of the programmable
controller often has to be optimized. Control modules often generate a more
effective code than function blocks.
Control modules make it much easier to develop object-oriented programs
than the standard IEC function blocks. Object-oriented programs are very suit-
able for controlling batch processes which are often used in the medical

86 3BSE021358R4001
Chapter 6: Control Modules 6.4 Applications for Control Modules

industry and in the food industry. Such program objects can easily be reused
in similar subprocesses. If all the code for process objects is concentrated into
modules, it will also be much easier to manage the maintenance of the plant.
Compared with function blocks, the control module strategy entails a system-
atic and time-consuming design process. Many engineers find this frustrating
since they are eager to produce code. However, the time spent on design is
repaid during the later phases of implementation, i.e. reuse and testing of the
control application.

Design Implement Reuse Test

Control Module

Function Block

Fig. 47 Time spent in the different phases of a control program project.

Most application programs with control modules also contain function blocks.
The reason for this is that object orientation is not normally cost-effective at
the lowest complexity level in a plant. For simple Boolean logic, traditional
programming with function blocks is a more cost-effective strategy.

3BSE021358R4001 87
6.4 Applications for Control Modules Chapter 6: Control Modules

88 3BSE021358R4001
Chapter 7: Project Management 7.1 Stages of a Project

Chapter 7
Project Management

Developing large industrial control systems is a demanding task. The control

system often has to deal with hundreds or even thousands of different inputs
and outputs. An unstructured program for such a system will be very difficult
to write, and even more difficult to follow for maintenance and fault finding.
This chapter presents a number of methods resulting in a more structured con-
trol program with improved software quality.

7.1 Stages of a Project

Inexperienced engineers are often very eager to produce control code as fast
as possible without “wasting” time on problem analysis, specification and
design. However, experience shows that such a strategy, or perhaps lack of
strategy, will result in a control application that takes a very long time to
develop, and is very difficult to debug.
More experienced programmers use a strategy in which the control application
is developed in seven stages, as shown in Fig. 48. Sometimes, the first two
stages are combined into one, which is then considered to be the design stage.

Analysis

Design

Coding

Testing

Documentation

Commissioning

Maintenance

Fig. 48 The recommended stages of a control system project.

3BSE021358R4001 89
7.2 Analysis Chapter 7: Project Management

7.2 Analysis
The initial stage of analyzing the control problem is, without doubt, the most
difficult stage in a project. This work has to be done by people with a good
knowledge of both the plant that is to be controlled and of the actual control
system being used. Often, the supplier/programmer of the control system
meets with the other contractors and the operators in the plant to determine
what controls are needed and how the control actions are to be carried out. At
this stage, it is also important to establish what operator controls are needed.
Another important consideration is to provide some form of manual mainte-
nance control that can be used for testing or rescuing an automated plant which
has failed to function as expected.
Experience shows that inadequate analysis will be very difficult and costly to
correct in the later stages of a project. Although programmable controllers are
easy to reprogram such work will be very time consuming if it has to be carried
out during the commissioning stage.
The result of the analysis stage is a description of how the plant will work,
what operator stations and control are needed and how these will be imple-
mented, what maintenance aids are to be included and a complete list of the
I/O signals, together with electrical specifications and physical location in the
plant. At this stage, the final testing requirements should also be defined.

7.3 Design
In large control applications, the programmer should not write a single, long
application program, but instead break it down into many small program parts,
if possible in an object-oriented structure. Ideally, each program part should
contain no more than about ten logical conditions, since this is the maximum
most human minds can hold at any time.
Over the years many methods have been developed which make the work sim-
pler and also result in better software quality. By working from the top down,
and breaking down the function of the installation into a hierarchical structure
of programs, the whole problem can be divided up into manageable parts.
In the IEC 61131-3 standard these parts are called POUs. A hierarchical struc-
ture is used with POUs at different levels, where every POU represents its own
particular part of the plant. The highest level in the hierarchy gives an over-
view, while the subordinate levels contain more and more detailed informa-
tion, the lower down one goes. In large industrial plants this method results in
considerable improvements in software quality.

90 3BSE021358R4001
Chapter 7: Project Management 7.3 Design

POUs at the higher levels in the hierarchy are constructed of a number of other
POUs which, in turn, can contain further POUs, and so on. The hierarchy can
therefore also be written as a block diagram, in which every POU contains sub-
ordinate POUs.

Fig. 49 Comparison between block diagram and POU hierarchy for an installation.

Assuming that the collaboration between POUs has been accurately specified,
it will be easy for several people to work together on building up the applica-
tion program. It is normally not necessary to know exactly how a complete
POU is constructed or how it works inside in order to be able to use it; we only
need to know how it interacts with other POUs.
One limitation of the top down method is that it can be difficult to draw bound-
aries between program POUs at the beginning of a project. Such problems are
often not discovered until much later, and it can then take a very long time to
correct finished program modules. The need for restructuring grows with the
total size of the program project.
An alternate method is to work from the bottom up, where complete POUs are
produced at a lower level without having to take account of the structure above
them. Each such POU can be tested and optimized individually, and can then
be used in different plant application programs. The disadvantage of this meth-
od is that the POUs have to be very generalized, which produces less effective
program code than with the top down method.
The object-oriented approach is the newest method for structuring large con-
trol applications. Physical plant objects are programmed as self-contained
modules communicating with other modules in a data flow-driven model.
When working with object-oriented programming, the top down method is
often used at the beginning of a project, while the bottom up method is best for
handling the internal object behavior. Object-oriented programming is
described in Chapter 5.

3BSE021358R4001 91
7.4 Coding Chapter 7: Project Management

7.4 Coding
Based on the structure laid down at the design stage, the coding can now be
done with any of the five IEC programming languages. If the initial two stages
of analysis and design have been carried out carefully the coding need not
involve more than 10% of the total time spent on a project.
An effective design with well-defined behavior and carefully defined interac-
tions between different subprocesses makes it possible to divide the work of
coding between several programmers. However, it should be noted that such
project groups must be managed by an experienced project leader with a good
overview of the entire control function.
During the work on coding it will sometimes be necessary to further specify
the control function in some of the plant subprocesses. There may also be a
need to divide some subprocesses into further subprocesses.

7.5 Testing
All control systems must be tested carefully before they are allowed to interact
with the real-world plant process. A very important advantage of software-
based control systems is that testing can be carried out with the system running
offline, without communicating with the process. Most computer-based engi-
neering stations have a useful simulation feature providing graphical display
of selected control functions. The programmer manually provides input sig-
nals via the engineering station, thereby simulating the real transducers. The
resulting actions of actuators are calculated by software in the engineering
station and presented graphically on the screen.

Fig. 50 Simulation of
SFCs is a very powerful
method for testing the
control function in a
subprocess.

92 3BSE021358R4001
Chapter 7: Project Management 7.5 Testing

Since most programmable controllers use standardized I/O modules a control

program can be developed using variable names for all the real-world inputs
and outputs but without knowledge of the address configuration where the
physical signals are connected to the controller.
Before the simulated control program can be tested online it is necessary to
configure the I/O unit with all the variables that are used in the application.
At this stage, it is also advisable to test the electrical connections between
transducers, actuators and the programmable controller. Most programmable
controllers have LED indicators displaying the status of the I/O unit signals.

Fig. 51 Example of an I/O configuration for a programmable controller.

With all but the simplest systems, it can be very time consuming to check all
the controls and actions that have been specified in the analysis. In many
projects there is spoken or unspoken pressure to hand over the plant control as
soon as all the basic operations have been tested, but with more rarely used
options untried. Too often, such tests are omitted and faults are not discovered
until years after the plant has commissioned. It is therefore very important to
establish what testing must be carried out before the plant can be started and
what can be tested later, online when the plant is in operation.
However, safety-related testing must never be omitted. Finding out that an
emergency stop sequence does not work when it is used for the first time in a
real emergency will definitely create a disaster.

3BSE021358R4001 93
7.6 Documentation Chapter 7: Project Management

7.6 Documentation
At every stage in a project new documents are added describing the plant from
several different aspects. After successful testing, all these documents have to
be gathered together to provide total documentation of the plant control sys-
tem. It is therefore very important that all documents are updated with changes
made to the control function during the project. Since it is very easy to alter
the control function in programmable controllers there always is a risk of
losing grip on the plant after program changes.
The purpose of the documentation is both to help the operators during normal
use and to serve the maintenance personnel when something goes wrong. It is
therefore very important that the documents are well structured and adapted to
the needs of both these categories.
When a new control system is introduced in a plant all personnel involved must
be informed about the system. Well structured documentation is one of the best
tools for this purpose.

7.7 Commissioning
If the application has been tested thoroughly offline, the online test together
with the process should not result in any unpleasant surprises. In many plants,
commissioning is an undramatic experience. However, if there are some pro-
cess conditions that could not be simulated effectively offline, the online test-
ing may be very difficult, time consuming and therefore also very expensive.
The cost of online testing together with the process may sometimes be more
than ten times higher than testing offline.

7.8 Maintenance
The final maintenance stage seems to be very far away during the earlier stages
of a project. However, once a plant control system is handed over it must be
maintained, which includes fault finding and minor changes in the specified
control function. Such changes are often a response to market needs or to new
technologies being developed.
Experience shows that the maintenance stage accounts for almost 50% of the
total time spent on a project during its life-time. Therefore, it is of vital impor-
tance that control programs be developed and documented so they can be
easily changed, also by people who were not involved in the previous stages.

94 3BSE021358R4001
Chapter 8: Industrial Application Example 8.1 Control Problem

Chapter 8
Industrial Application Example

In this final chapter we are going to apply the earlier described structuring
methods and programming techniques to a real-world plant. To keep complex-
ity at a reasonable level we will concentrate our efforts on one of many sub-
processes in the manufacturing line of an automobile factory.

8.1 Control Problem

The subprocess in question is an industrial robot moving car parts from a con-
veyor to a manufacturing machine. The car plant contains a number of such ro-
bots with similar behavior. The system is to be controlled by a programmable
controller of the type AC800M/C.

Conveyor

ES

LSL

Forward/Back
Open/Close

Left/Right LSB LSF

Machine
LSR

Fig. 52 The industrial robot moves car parts between a conveyor and a machine.

3BSE021358R4001 95
8.2 Analysis Chapter 8: Industrial Application Example

8.2 Analysis
The robot has three different electrical engines which move the manipulator.
The entire arm can rotate left or right, the foremost part of the arm can also
move forwards or backwards and the gripper, finally, can open or close. The
reason for moving the arm forwards and backwards is that there is limited
space when the arm rotates between the conveyor and the machine.
All the movements are to be controlled by six digital output signals from the
programmable controller. The robot system uses four limit switches to collect
information about the current position of the arm. The gripper has a mechani-
cal device that stops it from pressing too hard on closing and opening. This
makes it possible to hold the output signal from the control system for a short
while after the gripper has reached its final position, thereby eliminating the
need for two limit switches. All the inputs and outputs are summarized in the
table below.

I/O signal I/O In/Out Description

Arm_Forward AF Out Robot arm moves forwards
Arm_Backward AB Out Robot arm moves backwards
Arm_Right AR Out Robot arm turns right
Arm_Left AL Out Robot arm turns left
Gripper_Closes GC Out Gripper closes
Gripper_Opens GO Out Gripper opens
Limit_Switch_Left LSL In Robot arm at the conveyor
Limit_Switch_Right LSR In Robot arm at the machine
Limit_Switch_Back LSB In Robot arm in its backward position
Limit_Switch_Forward LSF In Robot arm in its forward position
Emergency_Switch ES In Emergency signal from operator

In its initial state the robot is placed at the conveyor with the arm in its back-
ward position and with the gripper fully open. If the machine has completed
the previous operation a command from the conveyor control program starts
the robot arm moving forward. When the arm reaches its forward position
(indicated by LSF) the gripper begins to close around the car part. The total
time needed for the gripper to close completely is 2 s. With the gripper closed
around the car part the arm is now moved backwards and when LSB is active
the arm begins to rotate right towards the machine. When LSR at the machine

96 3BSE021358R4001
Chapter 8: Industrial Application Example 8.2 Analysis

indicates that the arm is in the correct position it begins to move forwards
again, which continues until LSF is active. The gripper now opens and releases
the car part to the machine. The total time needed for the gripper to open com-
pletely is 1 s. After this, the arm is moved backwards until LSB is active fol-
lowed by a turn to the left until LSL indicates that the arm is back in its initial
state.
In order to minimize energy consumption and reduce the risk of damaging the
equipment and the car parts, all robot movements should start and stop
smoothly. This is accomplished through a ramp signal with a duration adapted
to the needs of the different movements and for start and stop.
The conveyor and the machine are both controlled by other control programs.
The robot control program has to communicate with these via the following
four Boolean parameters:

Parameter name Short In/Out Information

Conveyor_Request CR In Conveyor needs transportation
Machine_Ready MR In Machine has finished operation
Robot_Home RH Out Robot is back in initial position
Robot_Ready RR Out Robot has finished transportation

If something goes wrong in the plant the operator stops the control system via
an emergency switch. All motors must then stop immediately. After an emer-
gency situation the operator puts the system into its initial state by controlling
the motors manually in a normal sequence.
All the transducer signals from the limit switches and the emergency switch
are of digital type. Since the robot motors should be started and stopped
smoothly, all the actuator signals have to be of analog type. This means that
our programmable controller must have an I/O unit with five free digital inputs
and six free analog outputs.

3BSE021358R4001 97
8.3 Design Chapter 8: Industrial Application Example

8.3 Design
The analysis has shown that our robot is a self-contained system with relatively
limited communication with the surrounding subprocesses in the plant. Since
the plant contains several similar robots the control problem should preferably
be solved via an object-oriented robot control module. Such a module may be
reused several times in the plant, thereby standardizing the operator interface
and reducing the programming work.

Conveyor_Request Machine_Ready
Conveyor Robot Machine

Robot_Home Robot_Ready

Fig. 53 Communication between the robot and its neighboring subprocesses.

The robot control module should have a graphical symbol with color shifts
indicating its state. Gray may be used to signify inactive, green for active
(moving car parts) and red for emergency state.
According to the top down strategy the robot control module should contain
an SFC sequence program, which together with a control program (interlock-
ing with emergency switch), handles the movement of the robot arm. The con-
trol program uses the internal states of the SFC sequence interlocked with the
emergency signal to control the motors. All motor controls will pass through
a ramp function block generating a smoothly increasing or decreasing output
signal.

Robot control module

SFC Control Ramp

sequence program
Fig. 54 The structure of our
program robot control module with SFC
program, control program and
ramp function block.

98 3BSE021358R4001
Chapter 8: Industrial Application Example 8.3 Design

Technicians who are not familiar with SFC often use flow charts to describe
sequential behavior. Such flow charts are easy to follow, even for those with
no engineering background. But unfortunately they often become very large
and therefore will be difficult to manage in large plants. The sequential control
function for our robot arm is shown in such a flow chart below. The sequence
uses eight different working states plus the initial waiting state
.

Init 1

CR N AF
and
MR
Y N
LSF
AF

Y
N GO
LSF

Y
Delay N
GC 1s

Y
Delay N
AB
2s

Y
N
AB LSB

Y
N
LSB AL

Y
N
AR LSL

Y
N
LSR

Y
1
Fig. 55 Flow chart describing the control function for our robot sequence.

3BSE021358R4001 99
8.4 Coding Chapter 8: Industrial Application Example

The ramp function block type should generate a smooth increase or decrease
in the analog output as soon as the digital input is turned on or off. It must be
possible to change the ramp up and ramp down times depending on which
movements are to be controlled. An example of such a ramp timing diagram is
shown below.

Input
100%

Output

0% 1s 0.5 s

Fig. 56 Timing diagram for a ramp function block.

The ramp function block should be programmed via cyclical addition and sub-
traction. In order to produce a smooth output, the function block must have a
shorter interval time than the rest of the application, e.g. 100 ms compared
with the normal 250 ms.

8.4 Coding
Our robot control project will now be implemented with the engineering tool
Control Builder Professional from ABB. The control project will be developed
for downloading to an AC 800M programmable controller, equipped with a
digital input I/O module and an analog output I/O module.

Project Libraries
All project-specific control modules types, function blocks types, functions
and data types that are to be used several times are normally placed in one or
several project-specific libraries. Such control functions can easily be reused
in a similar manner as the objects in SystemLib. In large projects with several
programmers involved, it is advisable to appoint one programmer to be respon-
sible for the project-specific libraries and to allow the others to use them as
read-only files. In our example, we will create a library called MyLib for that
purpose.
Since the robot control module and the ramp function block will both be used
several times in our application, they should both be placed in MyLib. All the

100 3BSE021358R4001
Chapter 8: Industrial Application Example 8.4 Coding

underlying control modules used in the robot control module will automatical-
ly be available as control module types in MyLib.
Following the rules of object-orientation we will use a structured variable for
communication between the robot module and its surrounding modules. The
data type of this variable, called Robot_Communication, should also be placed
in MyLib.

Fig. 57 The Project Explorer

window showing our robot
project’s configuration of MyLib
and the AC 800M controller.

Variables and Parameters

Before the actual coding starts it is recommended that all the variables and
parameters needed in the project are defined. However, it is often difficult to
predict what local variables are needed inside control modules and function
blocks. In most cases the work therefore starts with the real-world I/O signals.
These can either be defined as global variables in the application or as local
variables in the module where they are needed. The system accepts both kinds
of variables when connection to the I/O modules is established.

3BSE021358R4001 101
8.4 Coding Chapter 8: Industrial Application Example

Global variables are available at all module levels in an application which sim-
plifies the programming. Unfortunately, this also increases the risk of data cor-
ruption, since all modules may write to such variables.
Using local variables gives better encapsulation of data but also has a small
disadvantage in that modules cannot be moved in the hierarchy once the con-
nection to the I/O unit is established. In our project we will choose this last
method.

Fig. 58 Local variables used in our robot control module. RealIO and BoolIO are both
composite data types containing the current value plus a number of components used
for manual signal forcing.

The only parameter needed in the robot control module is the project declared
Robot_Communication used for signal exchange with other modules.

102 3BSE021358R4001
Chapter 8: Industrial Application Example 8.4 Coding

Ramp Function Block Type

The ramp function block type will be used as a buffer between the digital states
in the SFC sequence program and the analog output signals to the motors cre-
ating robot arm movements. The purpose of this buffering is to achieve smooth
acceleration and retardation when the motors start and stop. Since the different
robot movements may have their own demands on the delay time, for both
increasing and decreasing, the function block must have two parameters estab-
lishing these two values.

Fig. 59 The ramp function block type uses conditional cyclic addition or subtraction of
a step value that is calculated from the time demands on the ramp signal.

The ramp will be used six times for the different robot motor outputs and the
ramp function block type must therefore be created six times. In order to create
almost linear output signal these function blocks should be executed with a
shorter interval time than the SFC sequence and the control program.
A shorter interval time is accomplished by connecting the six function blocks
to the Task Fast and setting its interval time to 100 ms in the Tasks window.

3BSE021358R4001 103
8.4 Coding Chapter 8: Industrial Application Example

SFC Sequence Program

The flow chart functional description of the sequence is easy to program as an
SFC program block. Each state is represented by a named SFC step with code
in separate windows and transition conditions in other windows.

Fig. 60 The robot sequence as an SFC code block with the selected transition condition
Tr4 in a separate window.

Our sequence uses two timer function blocks to create delays in the states
Close and Open. The required timer statements are placed in the code windows
for continuous action at the two corresponding steps.

104 3BSE021358R4001
Chapter 8: Industrial Application Example 8.4 Coding

Control Program
Normally, the binary status from an SFC step (Stepname.X) is not used direct-
ly for controlling the outputs in a process. The reason for this is that there is
often a need to interlock the step status with other variables such as emergency
signals. Additionally, many systems do not have a one to one relation between
the steps and corresponding process actions. In our robot sequence either the
step Forward1 or the step Forward2 should result in the same action. This is
also the case for the steps Backward1 and Backward2.
From the above mentioned it is evident that there is a need for an extra control
program block containing the interlocking logic and the “summing up” of the
different conditions for activation.
This program block is also a suitable place in which to call the ramp function
block that are to create smooth robot arm movements.
Finally we must not forget to create the two Boolean signals that are used to
tell other control modules that the robot has moved a car part to the machine
and that it is back in it’s initial position at the conveyor.

Fig. 61 The robot control program is used to connect the Boolean step states with the
analog motor outputs via six function blocks of the ramp function block type.

3BSE021358R4001 105
8.4 Coding Chapter 8: Industrial Application Example

Control Module Graphics

An important advantage of using control modules is that, apart from its control
programs, the module may also contain interactive graphical objects. Such
objects can be used for presenting actual process status to the operator.
In our robot process we want to indicate the status of the robot arm with colors.
This can be accomplished in several ways, but one of the simplest is to use
three similar robot modules with different colors and to only show one at a
time. The visibility of modules can easily be controlled by Boolean variables.

Fig. 62 The variables Any_Action and Emergency_Switch.Value can

be used to control the visibility of three differently colored robot modules.
Normally, the modules are placed exactly on top of each other,
but in the screen above they have been moved to illustrate the method

106 3BSE021358R4001
Chapter 8: Industrial Application Example 8.5 Testing

8.5 Testing
When large applications are to be tested it is of vital importance to reduce the
complexity by first testing smaller program parts, like function blocks, and
control modules, separately. Once the smaller parts have been debugged the
entire application can be tested more effectively. All testing normally follows
such a bottom-up procedure.
Most engineering stations have a simulation feature where an entire program
project can be tested without compiling and downloading it to the programma-
ble controller. Real-world input signals are then fed in manually either by typ-
ing on the keyboard or by the pointing device.
In our robot project the testing starts with the ramp function block. If a func-
tion block is connected to surrounding local variables it is possible to simulate
and observe the function. The sequence function is very easy to test via simu-
lation since the status is displayed directly on the screen.

Fig. 63 By providing simulated variable values, the programmer can test

run the function without being in contact via the programmable controller.

3BSE021358R4001 107
8.5 Testing Chapter 8: Industrial Application Example

When function block types and control module types are to be tested it is nor-
mally best to work with a funbction block and control module and connect it
to other modules providing the necessary parameter communication. It may
sometimes be necessary to create variables or control modules that are used for
testing only and deleted afterwards.

Fig. 64 When the robot control module type is to be tested it is best

to create another temporary control module using a control module
of the robot module. Parameter communication is accomplished
through a temporary structured variable.

After successful simulation the control project should always be downloaded

to the programmable controller and tested online. Most simulations are carried
out with much less processing power than during real execution in the control-
ler. The exact timing behavior of critical control functions may therefore be
very different when simulated, compared with online execution.

108 3BSE021358R4001
Chapter 9: Glossary 8.5 Testing

Chapter 9
Glossary

A
adaptive control
Control system where the controller parameters are automatically adjusted
to the properties of the process.
algorithm
A collection of rules which describe, step by step, how a problem is to be
solved.
analog signal
A continuously variable signal which represents a physical quantity, e.g.
temperature, flow or pressure.
application
The application contains a number of instructions that are compiled and
downloaded for execution in the controller.
ASCII
An abbreviation for American Standard Code for Information Interchange.
ASCII is the most commonly used code for character representation in data
processing systems.
assembler instructions
A low-level programming language using letter codes to represent the
machine code instructions.

3BSE021358R4001 109
8.5 Testing Chapter 9: Glossary

B
baud
A unit used to specify the data transmission rate between two devices.
One baud is equal to one bit per second.
Boolean
A variable that can only hold logical values such as True and False or
1 and 0.
bottom up
A method for structuring application programs where the individual
program objects are developed without consideration of the program
structure above them.
bus
A system of parallel circuit wires for connecting the different units in a
computer system or a programmable controller.

C
compiler
An application program that translates the control application to low-level
machine language that can be executed in a computer or programmable con-
troller.
CPU
The Central Processing Unit in a computer or programmable controller is
the “brain” that coordinates all activities and carries out all operations speci-
fied in the application program. In PLCs the name Central Unit is
often used instead of CPU.
cycle time
All application programs in programmable controllers are executed
repeatedly at a specified time interval.

110 3BSE021358R4001
Chapter 9: Glossary 8.5 Testing

D
digital signal
A signal with only two possible states, called high and low, on and off
or 1 and 0.
distributed systems
A control system with several computers or programmable controllers
communicating with each other via a local network.
download
A common name for the transfer of a compiled application program from
the engineering tool to the programmable controller.

E
editor
Application program that is used for writing and editing text or instructions.
execution
When a computer is running the instructions are executed one at a time.

F
falling edge
The change from 1 to 0 of a Boolean variable.
feedback
A signal from the controlled process may be fed back to the controller
where it is used in the control algorithm.
fieldbus
A communication bus used for digital information interchange between
sensors, actuators and programmable controllers.
full duplex
A transmission method where data can be both transmitted and received
simultaneously.

3BSE021358R4001 111
8.5 Testing Chapter 9: Glossary

G
gateway
A communication unit for connecting different types of networks.
It translates between different communication protocols.
global variable
A variable that can be accessed by all programs.

H
half duplex
A transmission method where data can only be transmitted in one direction
at a time.
hardware
A common name for all the equipment in a computer system.
hexadecimal
A system of numbers to the base 16. The numbers 0 – 9 are not changed
while 10 – 15 are represented by the letters A – F.
high-level language
A programming language similar to ordinary written text where each
instruction or statement results in several machine code instructions.
Pascal, C and Java are common high-level languages.

112 3BSE021358R4001
Chapter 9: Glossary 8.5 Testing

I
I/O module
Many programmable controllers use expandable I/O units making it
possible to add more input or output signals via extra modules.
I/O signal
The physical inputs or outputs of the I/O module.
identifier
A combination of letters, numbers and other characters used to give names
to variables, parameters, modules and other language objects.
initialization
Establishing basic conditions when a system starts up.
instruction
A programming language element that specifies an operation and the values
or location of its operands.
integrated circuit
Electronic functional unit containing a large number of semiconductors
which have been compressed to a small silicon chip.

L
LAN
Abbreviation for Local Area Network. A LAN is used to enable high-speed
communication between several computers and programmable controllers
in a plant.
local variable
A variable that can only be accessed in the program where it is defined.
low-level language
A programming language with letter codes where each instruction results in
one machine code instruction. Assembler is a typical low-level language.
LSB
An abbreviation for Least Significant Bit, i.e. the bit in a binary number with
the lowest value.

3BSE021358R4001 113
8.5 Testing Chapter 9: Glossary

M
machine code
When a computer executes a program it must be available in machine code
language which is a low-level language with binary or hexadecimal codes.
MMS
An abbreviation for Manufacturing Message Specification, which specifies
the messages used for industrial communication (manufacturing, process
robotics etc.). This is the application layer used within MAP (Manufactur-
ing Automation Protocol), a specification for open communication based on
the OSI model.
MSB
An abbreviation for Most Significant Bit, i.e. the bit in a binary number with
the highest value.

O
object code
Common name for the resulting code produced when the compiler has
translated an application program to executable machine language.
octal
A system of numbers to the base 8. The decimal digits 8 and 9 are not used
in this system.
offline
A computer (with editor and compiler) that is not connected to the controller
is considered to be offline. This is the normal situation for editing the source
code.
online
A computer (with editor and compiler) is considered to be online when it is
connected to the controller where the program is being executed. This is the
normal situation with the plant application executing and the process status
being displayed in the editor.

114 3BSE021358R4001
Chapter 9: Glossary 8.5 Testing

P
PLC
An abbreviation for Programmable Logic Controller which is the most
common type of control system in today’s industry.
POU
An abbreviation for Program Organisation Unit. The IEC standard
describes programs, function blocks and functions as POUs.
protocol
A set of rules which determines the procedure for communication between
different I/O units, computers or controllers.

R
RAS
Abbreviation for Remote Access Service. With RAS a remote client can dial
up a gateway machine resident on a LAN and establish a connection over
the telephone network.
real-time system
A system where changes in the input signals will result in immediate actions
on the corresponding output signals. Almost all control systems are of this
type.
rising edge
The change from 0 to 1 of a Boolean variable.
RS-232C
International standard for serial data transmission with the signal levels
-12V and +12V. Mainly used over relatively short distances.

3BSE021358R4001 115
8.5 Testing Chapter 9: Glossary

S
sampling
Computer-based control systems cannot communicate continuously with
the surrounding transducers and actuators. Instead, the control system
samples the environment (collects and transmits values) periodically with
a specified sample time.
SattBus
A fairly fast (62.5 kbit/s) fieldbus with token bus protocol. It is intended to
be used for short messages to field devices such as transducers, actuators,
etc.
simulation
Many computer-based engineering tools provide a function for simulating
the control function in the computer without downloading it to the program-
mable controller.
source code
Programs written in high-level languages are often called source code
before they are compiled to object code.

T
TCP/IP
An abbreviation for Transmission Control Protocol/Internet Protocol.
TCP/IP is used both on the Internet and on many Local Area Networks.
top down
A method of breaking down the entire control function into a hierarchical
structure of subprocesses.

W
workstation
A common name for a computer with associated software used for editing
and compiling control programs.

116 3BSE021358R4001
 Index
Numerics control modules 83 I
controller 9
3964R 23 I/O unit 19, 20
cross-assembler 16
IC 10, 69
identifier 37
A
D IL register 47
abstract classes 81
data flow 79 inheritance 70, 81
access variable 40 initial step 63
accumulator 47 data structure 31
DCS 28 initial value 40
action 62
debugging program 16 instance 53, 70, 76, 81
action description 64 instruction 16, 46
action qualifier 64 definition/type 76
distributed system 23 instruction list 21
actuator 10
divergent path 65 integrated circuit 60
analyze 90 interaction object 85
assembler 16 download 21
Duration 39 internal state 78
assembly language 46
interpreter 17
interval time 22, 31, 80, 103
B E
edge 56
Basic 18
editor 16, 21
L
batch process 65, 86 label 46
Boolean data 39 elementary data type 38
encapsulated data 43, 70 ladder diagram 20
bottom up 32, 91
engineering station 19, 21 LED indicator 93
event 31 libraries 12
C execute 16, 22 local area network 11
C 18, 50 expression 50 local variable 40, 101
C++ 75 loop 86
central unit 19 low-level language 17
F
class 76
feedback loop 41
closed loop control 13
flow chart 99
M
code sorting 86
function 54, 72 machine code 16, 21
COMLI 23
function block 32, 54, 69, 72 Macintosh 75
comment 38, 46 main state 67
common elements 37 function block name 72
MAP 29
communication protocol 23
memory 12, 19
compatibility 27 G memory bit 42
compiler 17, 21 global variable 40, 101 message 76
compliance class 33 Grafcet 62 methods 70, 76
composite object 85 minor state 67
conditional statement 51
constant 39
H MIS 29
high-level language 17 mnemonic 47
contact 41 monitoring subsystem 12
Control Builder Professional 21,
83

3BSE021358R4001 117
Index

O state 44
statement 50
object 76
step 62
object code 18
object-oriented programming 75 Step active flag 64
structured data type 38
object-oriented systems 12
subclass 76
offline 21, 92
online 22, 93 subprocess 12
subroutine 43
operand 46, 50
subsequence 67
operator 46, 50
operator modifier 47 syntax 16
syntax checking 21
optical isolator 20
SystemLib 100

P
T
parameter 54, 70, 72, 76
task 23, 103
Pascal 18, 50
PID controller 13, 78 Time of day 39
timer 79
PLCopen 33
top down 32, 67, 90
plinth 14
POU 31, 40, 69, 77, 90 transducer 9
transition 62
power rails 41
transition condition 62
process computer 11
Process Value 13 type 70
Profibus 23
Programmable Controller 11, 19 V
Programmable Logic Controller variable 40, 76
11, 19
protocol 28
W
Windows 75
R
real-time system 22, 78
relay coil 13, 41
relay logic 13
remote I/O 23
result register 47
retain 40

S
SCADA 11, 28
semantics 49
sensor 43
sequence 12, 44
sequence selection 65
Set Point 13
shareware 26
Simula 75
simulation 21, 92
simultaneous sequence 66
Smalltalk 75
Soft PLC 23
source code 18
standard libraries 60, 81

118 3BSE021358R4001
3BSE021358R4001
October 2004