ControlIT

IEC 61131 Control LanguagesIntroduction

IEC 61131 Control LanguagesIntroduction

3BSE 021 358 R201 Rev B

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 AutomationProducts AB. ABB Automation Products AB is not responsible under any circumstanc-es for direct, indirect, unexpected damage or consequent damage that is caused by thisdocument.

All rights reserved.

Release: October 2001Document number: 3BSE 021 358 R201 Rev BPrinted in Sweden.

TrademarksRegistered trademarks from other companies are: Microsoft, Windows, Windows NT from Microsoft Corporation.PostScript and Acrobat Reader from Adobe Systems Inc.FIX from Intellution and 3964R from Siemens.

3BSE 021 358 R201 Rev B

Contents

1 E111

11

1

2 W222222

3 I33

3 5

volution of Control Systems 9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Control Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Monitoring Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Sequencing Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Closed-loop Control Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

.4 Relay Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

.5 Computers for Process Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Programming Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

.6 Programmable Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19I/O Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Programming Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Computer-based Programming Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Cyclic Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Soft PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

hy Open Systems are Needed 25.1 Programming Dialects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2 Software Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.3 Software Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.4 Portable Software Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.5 Reusable Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.6 Communication with Other Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

EC 61131-3 Standard 31.1 Main Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Benefits Offered by the Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Well-structured Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Five Languages for Different Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Software Exchange between Different Systems . . . . . . . . . . . . . . . . . . . . . 33

.3 PLCopen Trade Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Contents

6

4 Programming Languages 354.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Common Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Constant Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4

4

4

4

4 3BSE 021 358 R201 Rev B

.3 Ladder Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Easy to Understand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Weak Software Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Limited Support for Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Difficult to Reuse Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

.4 Instruction List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46IL Language Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46IL Instruction Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Best System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Weak Software Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Machine-dependent Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

.5 Structured Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Operators in Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Conditional Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Calling Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Suitable for Complex Calculations and Looping . . . . . . . . . . . . . . . . . . . . 53High Threshold for Programmers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

.6 Function Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Syntax for Function Block Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Standard Function Block Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Similar to Electrical Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Boolean Functions and Feedback are Easy to Implement . . . . . . . . . . . . . 60Not Suitable for Conditional Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 61

.7 Sequential Function Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Chart Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Steps and Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Action Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Sequence Selection and Simultaneous Sequences . . . . . . . . . . . . . . . . . . . 65Subsequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Advice on Good Programming Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Powerful Tool for Design and Structuring . . . . . . . . . . . . . . . . . . . . . . . . . 68Other Programming Languages are Needed . . . . . . . . . . . . . . . . . . . . . . . . 68

Contents

3BSE 021 358 R201 Rev B

4.8 Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Type and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70User-defined Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Differences between Functions and Function Blocks . . . . . . . . . . . . . . . . 72How to Use Function Blocks in Control Programs . . . . . . . . . . . . . . . . . . 73Interaction between Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5 Object-oriented Programs 75555555

6 C6666

7 P77777777

8 I8888

8

9 GI 7

.1 New Life for an Old Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

.2 Objects in the Plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

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

.4 Program Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

.5 Reuse of Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

.6 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

ontrol Modules 83.1 Control Module Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Graphical Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.3 Automatic Code Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.4 Applications for Control Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

roject Management 89.1 Stages of a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90.4 Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.7 Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.8 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

ndustrial Application Example 95.1 Control Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98.4 Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Project Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Variables and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Ramp Function Block Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103SFC Sequence Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Control Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Control Module Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

lossary 109ndex 117

Contents

8 3BSE 021 358 R201 Rev B

Chapter 1: Evolution of Control Systems 1.1 Introduction

3BSE 021 358 R201 Rev B

Chapter 1Evolution of Control Systems

1.1Almoecono

tric mother trical controtransd

Fig. 1

The cber ofsignacondiducerture, p 9

Introductionst all industrial plants need some kind of controller to ensure safe and mical operation. At the simplest level, the plant may consist of an elec-otor driving a cooling fan to control the temperature in a room. At the extreme, the plant could be an entire nuclear reactor for producing elec-energy for thousands of people. Apart from their size and complexity, all l systems may be divided into three well-separated functional parts: the ucers, the controller and the actuators.

Overview of the components in an industrial control system.

ontroller monitors the actual status of the plant processes through a num- transducers. The transducers convert physical properties into electrical ls that are connected to the controller inputs. Digital transducers measure tions with distinct states, such as on/off or high/low, while analog trans-s measure conditions which have a continuous range, such as tempera-ressure, flow or liquid level.

Plant

Inputs Outputs

Transducers Actuators

Controller

Parameters Status

1.2 History Chapter 1: Evolution of Control Systems

10

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.2The fiend oingenical tato eaclife-ti

In thecontaphistilarge very ca limilogic system

The scontroCMOtime.

In momane

to imtheir

In thelarge advanor IC 3BSE 021 358 R201 Rev B

Historyrst control systems were developed during the industrial revolution at the f the 19th century. The control function was implemented by using ious mechanical devices automating some of the most repetitive and crit-sks on the assembly lines. These devices had to be individually adapted h task and due to their mechanical nature they also suffered from a short me.

1920s, mechanical control devices were replaced by electrical relays and ctors. Relay logic made it possible to develop larger and much more so-cated control functions. Since then, electrical relays have been used in a number of control systems around the world. Relays have proven to be a ost-effective alternative, especially for automating small machines with ted number transducers and actuators. In todays industry, relay is seldom chosen for new control systems but a large number of older

s are still in use.

ilicon-based integrated circuit, IC, paved the way for a new generation of l systems in the 1970s. Compared with relays, ICs based on TTL or

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

st control systems based on relays and ICs, the control algorithm is per-ntly defined by the electrical wiring. Systems with wired logic are easy plement but unfortunately it is difficult and time-consuming to change behavior.

early 1970s, the first commercial computers debuted as controllers in control systems. Since computers can be programmed they offer a great tage compared with the wired logic function in systems based on relays

s.

Chapter 1: Evolution of Control Systems 1.2 History

3BSE 021 358 R201 Rev B

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

Earlydigitahandlsystemopera

Todayof locneighlers acentraopera

Fig. 2

The oinstalAcquimonitstudy

18 11

only logical conditions.

PLCs had no analog inputs and therefore they could only handle l control applications. In todays industrial plants there is often a need to e both digital control and closed-loop analog control in the same control

. These systems are often called Programmable Controllers since their tion is not limited to only logical conditions.

, the overall control function in a plant is often distributed to a number al programmable controllers which are positioned in the immediate borhood of the objects which are to be controlled. The different control-re usually connected together into a local area network (LAN) with a l supervising process computer which administers alarms, recipes and tions reports.

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

perator plays a very important role in todays industry and many plant lations therefore have a computer-based Supervisory Control and Data sition System (SCADA). SCADA systems have high-resolution color ors on which the operator can select different application programs and the status of the manufacturing process.

192080 1970 1980 1990 2000

Mechanics

Relays

ICs

Computers

PLCs

Processcomputers

1.3 Control Applications Chapter 1: Evolution of Control Systems

12

It is characteristic of todays industry that the demand for profitability is increasing, while at the same time there is a more frequent need to carry out changes in the control function. Because the cost of computer equipment has fallen dramatically in recent years, the cost of development and maintenance of software has become the predominant factor.

In order to improve the quality and make it easier to reuse programs, there are today many more people working with object-oriented systems. In such sys-tems progrSuch

1.3It is eHowesmalldifferclosedsectio

MonA moattentoperadisplascreen

Signavia w

Manyraw m

autom

SeqThe vsequeit is nin a csequeaction 3BSE 021 358 R201 Rev B

the real process components like motors, valves and PID controllers are ammed via standardized program objects stored in program libraries. objects are well proven and have a standardized user interface.

Control Applicationsasy to be overwhelmed by the complexity of an industrial plant process. ver, most processes can be simplified by dividing them into a number of er subprocesses. Such subprocesses can normally be divided into three ent categories. Monitoring subsystems, sequencing subsystems and -loop control subsystems will be further described in the following three ns.

itoring Subsystemsnitoring subsystem displays the process state to the operator and draws ion to abnormal conditions which require some kind of action from the tor. The measured process values for temperature, pressure, flow etc. are yed to the operator via indicators, meters, bar-graphs or via a computer .

ls can also be checked for alarm conditions. The system indicates alarms arning lamps or audible signals, often accompanied by a paper printout.

monitoring systems also keep records of the consumption of energy and aterials for accountancy purposes. The system may also create atic warnings when critical components need to be exchanged.

uencing Subsystemsast majority of all subprocesses can be described via a predefined nce of actions that must be executed in a certain order. In such a system ot possible to specify a momentary combination of input signals resulting ertain output signal. Instead, the output status is dependent on an entire nce of input signals having occurred. In order to monitor the sequence of s there is a need for memory functions.

Chapter 1: Evolution of Control Systems 1.4 Relay Logic

3BSE 021 358 R201 Rev B

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 SubsystemsMany subprocesses have analog variables such as temperature, flow or pres-sure tfollowin Figmaint

PV isThis esignaable i

The cManyPropotion i

Fig. 3

1.4The ethe evrelaysdefineto the

Desirvalue

SP 13

hat must be automatically maintained at some preset value or made to other signals. Such a system can be represented by the block diagram . 3. Here, a variable in the plant denoted PV (Process Value) is to be ained at a desired value denoted SP (Set Point). measured by a transducer and compared with SP to give an error signal. rror signal is supplied to a control algorithm that calculates an output

l, which is passed on to an actuator, which affects the corresponding vari-n the process.

ontrol algorithm will try to adjust the actuator until there is zero error. control algorithms are available but the most commonly used is the rtional, Integral and Derivative (PID) controller. Since the control func-

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

A closed-loop control system.

Relay Logiclectromagnetic relay has been one of the most important components in olution of control systems. Relay logic systems contain a number of that are activated by digital transducer contacts. The control function is d, once and for all, by how the contacts are connected to each other and corresponding relay coils.

Controlalgorithm Process

SP-PVErrored

Controlled

PV

Transducer

variableActuator

Actual value

1.4 Relay Logic Chapter 1: Evolution of Control Systems

14

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.

Fig. 4

A relathousone o

via pl

The lladdecally are al

Sincetotal clays uand re

Logical AND 3BSE 021 358 R201 Rev B

Three often-used logical conditions implemented with relay logic.

y-based control system may contain any number, from a dozen up to ands, of relays. The relays with corresponding wiring are contained in r more cabinets. The transducers and actuators are normally connected inths.

ogical function of a control system based on relays is described in r diagrams, presenting how transducer contacts and actuators are electri-connected. The ladder diagrams not only describe the logical function but so used as drawings when the relay cabinets are manufactured.

relays are relatively costly and electrical wiring is time consuming, the ost of a relay-based control system depends mainly on the number of re-sed. In large plants the limited number of contacts on both transducers lays sometimes leads to engineering problems.

Logical OR

Memory

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

3BSE 021 358 R201 Rev B

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-advanto cha

Todaydozenwhere

1.5The fexpenlike pforme

Microresultmany

The mthat thvery samou

nicatithresh

Earlyordernorm

vendoproce 15

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

, relay logic can only be justified in very small plants with less than a inputs and outputs and in plants with severe electrical interference, computers and programmable controllers cannot be used.

Computers for Process Controlirst computers that were developed during the 1950s were very large, sive machines. Such systems were mainly used for administrative tasks ayroll administration, accounting and banking. The operations per-d were most often batch processes.

processors, developed in the 1970s, started a dramatic revolution ing in much smaller and cheaper computer systems. During the 1970s, control systems were developed using microprocessors as controllers.

ost important advantage of computers, compared with wired logic, is e programmed control function can easily be altered. Computers are also uitable for performing arithmetic calculations and for storing huge nts of data. A standard computer, however, is not equipped for commu-on with industrial equipment. Another disadvantage is the high learning old for developing computer programs.

computer-based control systems needed extra interface equipment in to handle real-world transducer and actuator signals. These interfaces ally had to be individually developed for each plant. Since then, several rs have developed standard interface modules for both digital and analog ss signals.

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

16

Programming MethodsAll 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 computers instruc-tions are very different from our own verbal ways of describing the actions we want it to take. In programming, therefore, various aids are used to process and translate our verbal function description into the computers own language. Thesetively

MachMost eratioing a can ggram tions

BecaugrammEach for feknowthe cotering

Befortransldone kind clationlatingsame

assem

types

Test rallowdebugfuncti 3BSE 021 358 R201 Rev B

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

ine Code and Assemblercomputers have a limited set of instructions which carry out simple op-ns such as fetching data, storing data, adding numbers, etc. By combin-large number of such machine codes into long programs, the programmer et the computer to carry out very complex functions. In order for the pro-to work, however, it is very important to follow the rules on how instruc-should be used and combined, often called the syntax of the program.

se machine codes are binary or hexadecimal numbers, the job of pro-ing is made easier by using what are known as assembler instructions.

of these instructions has a three-letter name (memo-code), such as LDA tching data and ADD for adding two numbers. A ready-made program n as an editor is normally used when writing assembler instructions into mputer. An editor program has basic word processing functions for en- and correcting text.

e the assembler program can be executed, the memo-codes must first be ated into hexadecimal machine code. The translation to machine code is by another program called an assembler. Assembler programs of this an be bought for most types of computers. Apart from the actual trans-, the assembler program can also help in checking syntax and in calcu- logical jumps within a program. Assembly is normally carried out on the type of computer as will be used for program execution, but there are also bler programs, known as cross-assemblers, which can be run on other

of computers.

unning of assembler programs is made easier by special programs that part of the program to be executed step by step. Using these so-called ging programs, it is also possible to simulate real-life signals so that the on can be tested without having to connect the computer to the process.

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

3BSE 021 358 R201 Rev B

Fig. 5 itor, an

Progrtages.the cotured able ito oneof comgood imporbe probecau

CompThe wten incode

Start

As LDA IN1

F60AA9

Editingusing editor

Tesusing

Fup 17

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

amming using assembler instructions has both advantages and disadvan- The work demands a thorough knowledge of the technical workings of mputer. In most cases, the problem description also has to be restruc-so that the required function can be obtained using the instructions avail-n the computers repertoire. The completed program is entirely matched particular type of computer and cannot be transported to another type puter. On the other hand, a properly written assembler program gives

performance and the optimal usage of the computers memory. This is tant in, for example, industrial robots and where very large series are to duced. Working with assembler is often called low-level language se the instructions are similar to the computers own way of working.

iling and Interpretingork of programming is made considerably easier if the program is writ-

what is known as a high-level language, which is translated into machine by a program-based compiler or interpreter.

sembling

Stop

Assembler

L1 SUB C

CMP B

BNE L1

ADD D

STO OUT1

2312E3F87606A345D3A2

No

Yes

t-running debugger

nctioningroperly?

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

18

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.

Instrutions,highlythey aactuaprocelevel called

The ptechntage iassum

The dup moassem

puter

Fig. 6indepby a c

Pro

IF P

END 3BSE 021 358 R201 Rev B

ctions in a high-level language are reminiscent of mathematical func- and are therefore relatively easy to use. All high-level languages are standardized, and the main parts of the programs can be written so that re independent of the type of computer on which they will be run. The

l matching to the computer is done by the compiler or interpreter in the ss of converting it to machine code. Programs that are written in high-languages are often known as source code, while the compiled result is object code.

rogrammer writing in a high-level language does not need to know the ical details of the design of the computer or its memory. Another advan-s that completed programs can be moved to another type of computer, ing that a suitable compiler is available.

isadvantage of programs written in high-level languages is that they take re room in the memory than corresponding programs written directly in bler (machine code). This also means that the performance of the com-is used less efficiently.

Programs written in a high-level language are totally machine-endent and are translated to computer-specific machine code ompiler program.

Compiler

fit := Income - Cost

rofit>20 THEN PRINT "Profitable"

ELSE PRINT "Loss"

020CA74337E3F88616A245A205A3127B

Source code in Pascal

Chapter 1: Evolution of Control Systems 1.6 Programmable Controllers

3BSE 021 358 R201 Rev B

1.6 Programmable ControllersIn 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 systemup to

IndepcentraThe cprogrI/O u

Aparthave Progr

Progrenginand thPLCsprese

Fig. 7

I 19

s in all kinds of industrial plants, from small machine control systems, entire manufacturing lines in large process industries.

endent of brand and type, most PLCs contain three functional parts: the l unit, the memory and the I/O unit, all communicating via a bus unit.

entral unit coordinates all activities in the PLC and executes the control am in the memory. The process status is monitored and sampled via the nit.

from logical instructions an increasing number of todays PLCs also arithmetic functionality. Many vendors are therefore using the termammable Controller instead of PLC.

amming of PLCs is normally carried out on an external computer-based eering station. The compiled program is downloaded to the central unit en into the program memory via a serial channel or via a LAN. Some have an option for using the engineering station for online process status ntation, while the control program is executing.

The components of a programmable controller system.

Central unit

Engineeringstation

Memory

Bus unit

I/O unit

nput modules Output modules

PLC

Transducers Actuators

1.6 Programmable Controllers Chapter 1: Evolution of Control Systems

20

I/O UnitsA characteristic quality of the programmable controller is that it is designed to live in and interact with an industrial environment. Most controllers have a modularized Input/Output unit (I/O) for direct connection of the transducer and actuator signals.

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

Sinceallowtomiz

The mthe siputs a

A groSuch analo4-20

ProgThe fiThe pcontabranc

The pwhichthe cocoils essary

Progrpeoplthis m 3BSE 021 358 R201 Rev B

used in the controller and also to suppress electrical transients from the equipment. This is often achieved by optical isolators containing a light-ng diode and a photoelectric transistor linked together in a package.

there are several different signal levels in a typical plant, many I/O units the use of exchangeable I/O modules. Such an I/O unit can easily be cus-ed to the specific signal levels of the plant.

ost commonly used I/O modules are digital DC inputs and outputs with gnal levels 24 V or 48 V. Many vendors also offer modules with AC in-nd outputs with signal levels of 110 V or 220V.

wing number of programmable controllers have arithmetic functionality. systems have a need for analog input and output I/O modules. Most g transducers represent a physical value as a current within the range mA, with 4 mA indicating the minimum value.

ramming Methodsrst PLCs used a programming language based on relay ladder diagrams. rogram was entered via a programming terminal with keys showing ct symbols (normally open/normally closed), relay coils and parallel hes with which a maintenance electrician would be familiar.

rogramming terminal compiled the ladder diagram into machine code was sent to the controller for execution. With the controller executing ntrol program was presented on a screen, with energized contacts and

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

amming with ladder diagrams is a very intuitive method, especially for e with previous knowledge of relay-based control systems. Therefore, ethod was initially preferred by American PLC vendors.

Chapter 1: Evolution of Control Systems 1.6 Programmable Controllers

3BSE 021 358 R201 Rev B

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.

Fig. 8

ComEarlypurpoprogr(PCs)sionasome

with cstatio

Most ware

assoc

The einstruavoidthe encontro

The cloads

Manythe coThe sSimumanu

A 001A 012 21

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

puter-based Programming Tools PLCs were programmed with dedicated terminals, only usable for that se, together with specific systems from one vendor. Today, almost all ammable controllers are programmed with standard personal computers running a dedicated development software tool. Control Builder Profes-l from ABB is an example of such a software tool intended for use with of the programmable controllers supplied by ABB. A complete system omputer and development software is often referred to as an engineering n.

development tools contain several different, but often integrated, soft-applications which simplify the work of program development for the iated control system.

ditor is used to define variables and for writing the control program ctions. Most editors have syntax checking that helps the programmer such errors. Program editing is normally done offline, which means that gineering station is running locally, not in communication with the ller.

ompiler translates the control application into machine code and down- this code for execution in the programmable controller.

development tools provide a useful function that compiles and simulates ntrol function in the computer without downloading it to the controller.

imulated status of inputs and outputs is displayed on the computer screen. lation makes it possible for the programmer to test the application by ally altering the input signals.

ON 020RPA 003= 201

1.6 Programmable Controllers Chapter 1: Evolution of Control Systems

22

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.

CycIndusthe inAn exparticmay ba dela

In ordmust this thChanthe enprogr

Fig. 9

Upou

Rea

Expro 3BSE 021 358 R201 Rev B

These methods are further described in Chapter 4.

lic Executiontrial control systems are real-time systems, which means that changes in put signal require immediate action on the corresponding output signals. ample is a machine in which some movement must be stopped when a ular limit is reached. If the controller does not react in time, the result e damage to the machine or injury to the operator. The consequences of yed reaction therefore become unacceptable.

er to fulfil the demands on a real-time system, the application program have constant access to current input data from the process. To achieve e compiled program is executed cyclically at a specific frequency.

ges in the incoming signals can therefore only affect the output signals at d of each completed program cycle. The required interval time of the

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

A typical program scan in a programmable controller.

datetputs

d inputs

ecutegram

Interval time1 - 50 ms

Chapter 1: Evolution of Control Systems 1.6 Programmable Controllers

3BSE 021 358 R201 Rev B

Because different subprocesses may have different time demands, some pro-grammable controllers provide a function for dividing the total program into different tasks, each with its own interval time.

Distributed SystemsIn many large industrial plants there is a need for distribution of the entire control function to several different programmable controllers and process comprisk o

The caccou

out ovremot

DistriorderproprABB,emergvendo

SoftOne phardwtions rules comm

ent m

SeverSoft Pin a stI/O u

The mindepestabltrol aferred 23

uters. This strategy will improve total performance and also reduce the f total breakdown in the manufacturing process.

abling between transducers, actuators and the programmable controllers nts for one of the major costs in a control system. If the plant is spread er a large area, considerable cost savings may be achieved by using e I/O subsystems situated close to the actual subprocess.

buted control systems require a standardized communication protocol in to exchange information. Several PLC vendors have developed their own ietary protocols during the 1990s and some of these, like COMLI from 3964R from Siemens and the vendor-independent Profibus, have slowly ed into de facto standards supported by more than one PLC r.

PLCroblem with PLCs is that all vendors use their own proprietary controller are with an associated programming language. In spite of the basic func-

being practically identical, the instructions have different names and the governing the syntax of the programs may vary. This makes it difficult to unicate and exchange application programs between systems of differ-

anufacture.

al software vendors have presented a new type of controller called the LC. The Soft PLC is real-time software executing a control application andard PC and communicating with the plant via a standardized modular nit.

ajor advantage of a Soft PLC is that all the required hardware is vendor endent. Unfortunately, none of the software vendors has managed to ish their Soft PLC software as an industry standard. This means that con-pplications developed with one Soft PLC application cannot be trans- to Soft PLCs from other vendors.

1.6 Programmable Controllers Chapter 1: Evolution of Control Systems

24 3BSE 021 358 R201 Rev B

Chapter 2: Why Open Systems are Needed 2.1 Programming Dialects

3BSE 021 358 R201 Rev B

Chapter 2Why Open Systems are Needed

2.1The pinduscationstoodcontroproce

For alvendoprogrdecidorderdoublmanu

2.2As mmatedmana

applicof provolve

Experlong tthe wproce 25

Programming Dialectsrogrammable controller is one of the most critical components in todays try. Since control systems are being used in so many plants and in appli-s concerned with safety, it is very important that programs can be under-

by a wide range of industrial personnel. Besides the programmer, a l program should be easy to follow by technicians, plant managers and

ss engineers.

most two decades, the market has been dominated by half a dozen rs offering very similar solutions but, unfortunately, also brand-specific

amming dialects. Many customers using programmable controllers have ed to standardize their equipment to at least two different vendors, in to minimize risks. In real-world applications this often leads to costly e work and problems in communication between systems from different facturers.

Software Qualityore and more jobs in manufacturing and process industries become auto-, the software programs become larger and therefore more difficult to

ge. In most cases, more than one programmer is needed to develop the ation software for industrial automation. Experience shows that the risk gram errors grows exponentially with the number of programmers in-d and, consequently, the size of the program itself.

ience also shows that new industrial plants often encounter problems a ime after commissioning. Some failures can interrupt production or, in orst case, result in serious damage to the production equipment or the ssed material.

2.3 Software Cost Chapter 2: Why Open Systems are Needed

26

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 packahave vumen

and in

Beforwas a

2.3Duriners, limaketion vstand

In conneedshas to

Most A cusroughfinal pchangphase

The hing sphave compmanc

on thegreatefindin 3BSE 021 358 R201 Rev B

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

tation. Software quality is therefore heavily dependent on the experience tellectual capacity of the programmer.

e the IEC 61131-3 standard was established, good software engineering n open goal in the control application environment.

Software Costg the last decade, standardized software packages for personal comput-ke word processors and spreadsheets, have become very popular. This s it possible for software vendors to lower prices dramatically. Distribu-ia the Internet has pushed the limits even further, and today many useful ard applications are available as shareware, almost free of cost.

trast, most software for control applications is adapted to the specific of a single plant application. This means that the total development cost be charged to a single customer.

customers find it difficult to control the total software development cost. tomer without experience in software development can only present a functional description to the developer. In many cases, this leads to a roduct that only partly fulfills the customers requirements. Even small es and additions tend to be very costly to implement, especially in later s of program development.

ardware on which computer programs are run is developing at an amaz-eed, while prices are constantly falling. Todays personal computers

equally good, or even better, performance than yesterdays mainframe uters. With the increasingly good relationship between hardware perfor-e and price, the total cost of an installation is becoming more dependent time required for program development. In most projects, therefore, r weight is attached to standardization and reuse of programs than with g the optimal hardware.

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

3BSE 021 358 R201 Rev B

Fig. 10

An aumaterpass aapplicto be ten bycost o

2.4The pa welofficesoftwused

Morelers, tMost can o

This ihave Sinceware

dated

To maprogrstand 27

Cost of hardware versus software.

tomation plant or machinery can pose a danger to the operators or the ial if the control software has fatal errors. Therefore, the software has to particularly intense testing and validation procedure. In real-world ations, testing may be very time consuming, especially if the work has

done with the process running. If the application program has been writ- inexperienced programmers, the cost of testing even may exceed the f program coding.

Portable Software Applicationsersonal computer together with the Windows operating system is today l-established de facto standard for information handling in almost all s in the world. The main reason for the PCs enormous penetration is are compatibility. Application programs developed for Windows can be on almost all PCs around the world.

than 25 years after the introduction of the first programmable control-his market still lacks an international standard similar to that for the PC. control vendors use their own proprietary programming dialect, which nly be used with their hardware.

s surprising since almost all industries using programmable controllers high demands on inter-system portability of control system software. the cost of developing well-tested software is much higher than the hard-cost, there is often a need to port existing applications from older out- hardware to newer systems.

ny, it is incomprehensible that it has taken more than 25 years for the ammable controller market to start establishing a common programming ard like the IEC 61131-3.

2.5 Reusable Software Chapter 2: Why Open Systems are Needed

28

2.5 Reusable SoftwareNot so long ago, many real programmers measured their effectiveness by the amount of program code they produced per day. Real programmers dont like to waste their time on structuring and detailed specification. Instead, they move directly from a rough specification, often made by the customer, to cod-ing in their favorite language, often ladder diagram or instruction list.

Todayovera

and c

The trthe prin ind

Anothaffectresultdifferage (rism fo

2.6The fplacecontromach

In todthe syreplac(SCAstatusABB

In larber ofsome

exam 3BSE 021 358 R201 Rev B

, even real programmers realize that the first phase in a project when the ll function is analyzed, structured and designed, is the key to a successful ost-effective application program.

aditional method of reducing software cost is to reuse common parts of ogram code in several similar applications. Unfortunately, this is difficult ustrial automation since most processes are very different in behavior.

er obstacle to software reuse is that the program code is often strongly ed by the programmers own style. When the final application is the of teamwork there are often visible seams between the parts coded by ent programmers. The only way to reduce the risk of seams is to encour-ead force) all the members of the team to follow certain rules and formal-r producing code.

Communication with Other Systemsirst programmable controllers presented in the seventies were often d in an electrical equipment cabinet close to the machine or process being lled. These controllers normally had no means of interaction with the

ine operator or communication with other controllers.

ays industrial plants, great emphasis is put on operator interaction with stem. The huge control centers in e.g. nuclear power stations are being ed by PC-based Supervisory Control and Data Acquisition Systems DA) using a large color screen to present process pictures showing plant . Two of the most commonly used SCADA systems are SattGraph from and FIX from Intellution.

ge industrial plants, the control function is normally divided into a num- different programmable controllers communicating with each other via kind of standardized communication protocol. SattLine from ABB is an ple of such a Distributed Control System (DCS).

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

3BSE 021 358 R201 Rev B

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 mana

calledtweenstand 29

gement system. General Motors in the USA has developed a standard Manufacturing Automation Protocol (MAP) for communication be- different programmable controllers and MIS. Unfortunately, the MAP

ard has so far not been particularly successful.

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

30 3BSE 021 358 R201 Rev B

Chapter 3: IEC 61131-3 Standard 3.1 Main Objectives

3BSE 021 358 R201 Rev B

Chapter 3IEC 61131-3 Standard

3.1IEC 6controautomgrammtrotecvendoducedare as

Thcatto afun

It sdiftim

Cocon

Thtraent

ThLa(FB

Thor

con 31

Main Objectives1131-3 is the first, and so far only, global standard for programmable llers. Considering that programmable controllers have been used in ation systems for more than two decades, it is remarkable that a pro-ing standard has taken so long to evolve. The IEC (International Elec-

hnical Commission) working group, with members from all the leading rs, has, after years of discussions, finally come to a consensus and pro- a working standard. The main objectives of the IEC 61131-3 standard follows.

e standard encourages well-structured program development. All appli-ion programs should be broken down into functional elements, referred s program organisation units or POUs. A POU may contain functions, ction blocks or programs. hould be possible to execute different parts of the application program at ferent rates. This means that the system must support individual interval es for different POUs.mplex sequential behavior can easily be broken down into events using a cise graphical language.

e system must support data structures so that associated data can be nsferred between different parts of a program as if they were a single ity.e system should have parallel support for the five most used languages, dder Diagram (LD), Instruction List (IL), Function Block Diagram

D), Structured Text (ST) and Sequential Function Chart (SFC).e programming syntax should be vendor independent, resulting in more less portable code that can easily be transferred between programmable trollers from different vendors.

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

32

3.2 Benefits Offered by the StandardWell-structured SoftwareThe main purpose of the IEC 61131-3 standard is to improve overall software quality in industrial automation systems. The standard encourages the devel-opment of well-structured software that can be designed either as top down or bottomtion b

A funname

anothsolutitrol fuoutpuother

By pahiddedata c

FiveThe Iming mers

SinceList pgrams

Todayital sitions diagra

The igraphscribi

An opof thetion b 3BSE 021 358 R201 Rev B

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

ction block is part of a control program that has been packaged and d so that it can be reused in other parts of the same program, or even in er program or project. Function blocks can provide any kind of software on from simple logical conditions, timers or counters, to advanced con-nctions for a machine or part of a plant. Since the definition of input and t data has to be very precise, a function block can easily be used, even by programmers than those who developed it.

ckaging software into function blocks the internal structure may be n so that well-tested parts of an application can be reused without risk of onflict or malfunction.

Languages for Different NeedsEC 61131-3 standard supports five of the most commonly used program-languages on the market. Depending on previous experience, program-often have their personal preferences for a certain language.

most older programmable controllers use Ladder Diagram or Instruction rogramming, there are often many such programs available. These pro- can relatively easily be reused in new systems supporting the standard.

s programmable controllers can handle both logical conditions for dig-gnals and arithmetic operations on analogue signals. Arithmetic opera-are much easier to program with Structured Text than with Ladder ms.

nitial structuring of a control application is normally best done with the ical language Sequential Function Chart. This method is ideal for de-ng processes that can be separated into a sequential flow of steps.

timal software application often contains parts written in more than one five programming languages. The standard allows the defintion of func-lock types using all the languages.

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

3BSE 021 358 R201 Rev B

Software Exchange between Different SystemsBefore the IEC 61131-3 standard was established it was not possible to port control programs from one vendors programmable controller to a competing system. This has been a major obstacle to a free market, where the customer selects a system based on the suitability of the hardware and price, rather than by the type of programming languages supported by the controller.

With ing sotem scompbetter

Unforachierequirfeaturthe stfore bfeatur

3.3Sinceber ofhave fuct- in

Beinging ofaboutter, paPLCoportab

The lthougLevelcomm 33

programmable controllers that are IEC compliant the potential for port-ftware is much better. Software developed for one manufacturers sys-

hould, at least theoretically, be possible to execute on any other IEC- liant system. This would open up the market dramatically resulting in standardization, lower prices and also improved software quality.

tunately such a high level of software portability may be difficult to ve in practice. The IEC 61131-3 standard defines many features and only es that vendors of programmable controllers specify a list of which es their system supports. This means that a system can be compliant with andard without supporting all features. In practice, portability will there-e limited, since systems from two different vendors often have different e lists.

PLCopen Trade Association the IEC standard has relatively weak compliance requirements, a num- the larger control system companies concerned with software portability ormed the PLCopen Trade Association. PLCopen is a vendor- and prod-dependent worldwide association supporting the IEC 61131-3 standard.

founded in 1992 in The Netherlands, PLCopen today also has support-fices in Canada and Japan. The organisation informs users/programmers the standard via a website (www.plcopen.org), a free quarterly newslet-rticipation at trade fairs and by arranging their own conferences. pen has defined three different compliance classes concerning the ility of control system software.

owest class is Base Level, defining a core kernel of the standard. Al-h rather restricted, it is feasible to develop applications based on it. Base provides an entrance for control system vendors, demonstrating their itment to the standard.

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

34

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. 3BSE 021 358 R201 Rev B

Chapter 4: Programming Languages 4.1 Overview

3BSE 021 358 R201 Rev B

Chapter 4Programming Languages

4.1The I

La Ins Str Fu Seq

IL anical mvantaapplic

Altholanguthe re

Fig. 11progra

M1 : 35

OverviewEC 61131-3 standard specifies five programming languages:

dder Diagrams, LDtruction List, ILuctured Text, STnction Block Diagram, FBDuential Function Charts, SFC

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

ges, it is important to have basic knowledge of the most suitable ations for each language.

ugh most control systems may be implemented with any one of the five ages the resulting program will be more or less effective, depending on quirements of the control application.

A simple Boolean condition programmed with four of the five IEC 61131-3 mming languages. SFC is normally only used for sequences.

A1

A2

A3 M1 LDN A3AND( A1OR A2)ST M1

LD IL

= ( A1 OR A2 ) AND NOT A3;

ST FBD

1& M1

A1A2A3

4.1 Overview Chapter 4: Programming Languages

36

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.

BeformableBy traEurop

The cecono

Detainenglaning

In sgooMarel

In divlati

Prolowrun

havcodsyseffcom

Whof con

tim 3BSE 021 358 R201 Rev B

e the IEC 61131-3 standard was established, most vendors of program- controllers supported only one or two of the programming languages. dition, most American vendors have preferred LD languages while ean vendors have chosen FBD or IL languages.

hoice between different programming languages is governed by several mical, technical, and cultural factors.

pending on background, programmers often have a preference for a cer- language. Programming with IL, LD or FBD is more popular among ineers with experience in automation systems using those programming guages, while ST is the natural choice for engineers with experience us- computer systems with programming languages such as Pascal.mall applications with relatively few logical conditions, the demands for d structure and reuse of code are less important than in larger systems. ny older control systems use LD as a direct analogy to systems based on

ays and switches.large plants involving many subprocesses the control function must be ided into an number of program modules with a high level of encapsu-on in order to prevent the modules from interfering with each other.gram languages are often characterized by their level of abstraction. A -level language like IL is very closely coupled to the actual binary codes ning the processor in the control systems. Low-level languages normally e a limited number of instructions producing very effective software e but, unfortunately, also totally tailored for a certain brand or model of tem. High-level languages, like ST and SFC, do not produce the most ective machine language but, on the other hand, the program may be

piled for many different programmable controllers.en programmable controllers were first introduced in the 1970s, most

the applications were for purely Boolean logical conditions. Today, a trol system must handle both digital and analog control, together with ers, counters and sequences.

Chapter 4: Programming Languages 4.2 Common Elements

3BSE 021 358 R201 Rev B

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 yeathe

Fig. 12and FB

4.2The Iof thefiers,

IdenIdentiexam

a strinunderunder

Struc

High

Low 37

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

The evolution of the five IEC 61131-3 programming languages. Today, SFC, ST D are the most commonly used techniques for developing new control systems.

Common ElementsEC standard defines a number of common elements which are used in all programming languages. This section explains the rules for using identi-data types, constants and variables.

tifiersfiers are used for naming different elements within the IEC language, for ple, variables, data types, function blocks and programs. An identifier is g of letters, digits or underscore symbols which begin with a letter or an score. Space characters are not allowed in identifiers. Two or more scores may not be used together.

1950 1960 1970 1980 1990

ture level

Year

LD

IL

FBD

ST

SFC

2000

4.2 Common Elements Chapter 4: Programming Languages

38

Keywviduafor ex

TypSomepositi

Progr(*comwhich

DataThe fused iIEC smost

In addturedhas ncontacal po

Allowed identifiers Illegal identifiersMotor_1 1MotorElapsed_Time switch 1_prog2 Conveyor__3

DataBooleIntegDoubReal DuraCalenChar 3BSE 021 358 R201 Rev B

ords are special identifiers that are used within the IEC language as indi-l syntactic elements. You are not allowed to use keywords as identifiers, ample:

e, True, False, Program, Task, Return, Step, Function, Timer, Counter compilers may be able to distinguish between keywords based on their on but others may produce confusing results.

ammers comments are delimited at the beginning and end by asterisks ment*). Comments can be placed anywhere except in IL language, has some restrictions.

Typesirst PLCs could only handle Boolean data but todays systems are being n an ever-widening range of industrial applications. For this reason, the tandard provides a comprehensive range of elementary data types. The often used data types are described below.

ition to elementary data types, programmers can define their own Struc- data types containing several components of data types. Such a data type o physical correspondence in the plant, but it can be likened to a cable ining a number of leads of different types, e.g. for the transfer of electri-wer or telephone and TV signals.

type Keyword Bitsan bool 1

er int 16le integer dint 32numbers real 32tion of time timeder time date_and_time

acter string string

Chapter 4: Programming Languages 4.2 Common Elements

3BSE 021 358 R201 Rev B

All leads are given descriptive names so that the programmer can connect to them without having a detailed knowledge of their function.

A newand E

TYPE

END_

Each and th

ConBy giafter variab

Thereare diliteralthe pr

Decimto basBooleand T

Time are prtermsare pr

Fig. 1

PumpType On (boolean)Off (boolean)Level (real) 39

structured data type is declared by delimiting the definition with TYPE ND_TYPE.

PumpTypeOn: booleanOff: booleanLevel: realName: stringTYPE

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

stant Literalsving a variable the attribute constant, you prevent it from being changed it is given its initial value. The initial value is normally specified in the le declaration.

are two classes of numerical literals: integer and real, where the latter stinguished from the former by the presence of a decimal point. Real s may end with an exponent, indicating the integer power of ten by which eceding number is to be multiplied.

al numbers are represented in conventional decimal notation. Numbers es other than 10 are represented in base 2, 8 or 16 (prefix 2#, 8# or 16#). an data are represented by the values 0 and 1 or the keywords FALSE RUE.

literals are used either for Duration data or for Time of day. Duration data efixed by the keywords TIME# or T# followed by the actual duration in of days, hours, minutes, seconds and milliseconds. Time of day literals efixed by the keywords TIME_OF_DAY# or TOD#.

3 Example of a structured data type containing several elementary data types.

Name (string)

4.2 Common Elements Chapter 4: Programming Languages

40

VariablesVariables is the name given to data elements whose content may change during execution of the application program. A variable may be associated with a real-world input and output, but can also be an internal memory storage.

All variables are declared with a unique name and a corresponding data type. This is normally done before the program code is written. A variable must also have avariabnot becalcu

If a vInitiatype (The tfrequ

The I

loc

Localwhich

Globaopen progr

Acces

NamPumPhotDuraEven

NumTem 3BSE 021 358 R201 Rev B

n attribute, either retain, constant or a blank field. Retain means that the le will retain its value when the system restarts. A constant variable will changed by the system. Variables with a blank attribute will always be

lated at system restart.

ariable has to start at a specific value, that value has to be specified as l value, otherwise it will start at a predefined value depending on its data normally 0).able below shows examples of names and attributes of variables of ently used data types.

EC standard defines three types of variables:

al, global and access variables.

variables can only be accessed in the same function block or program in they are declared.

l variables are accessible from any program or function block in the project. A global variable must be declared as an external variable in the am organisation unit (POU) accessing it.s variables can be used by other controllers.

e Data type Attributes Initial valuep_1 bool retain FalseoCell_4 bool Falsetion_Open time constant T#3m10st_Notation date_and_time constant DT#1999-02-01-

12:30:00.000berOfRev dint constant 10perature_5 real retain

Chapter 4: Programming Languages 4.3 Ladder Diagrams

3BSE 021 358 R201 Rev B

4.3 Ladder DiagramsLadder Diagrams (LD) have evolved from the electrical wiring diagrams that were used, for example, in the car industry, to describe relay-based control sys-tems. LD is a graphic representation of Boolean equations, using contacts as a representation for inputs from the process and coils for outputs.

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

Each but sotacts ithe rasents able i

Therewhichare cl0) whIn anarepresopera

Fig. 14

It is pvariabin oth 41

ower rails serve as a symbolic electrical power supply for all the contacts oils that are spread out along horizontal rungs.

contact represents the state of a Boolean variable, normally a transducer, metimes also an internal variable in the control system. When all con-n a horizontal rung are made, i.e. in the true state, power can flow along il and operate the coil on the right of the rung. The coil normally repre-physical objects like a motor or a lamp, but may also be an internal vari-n the control system.

are two types of contacts, normally open and normally closed. Contacts are normally open present a true state (Boolean variable is 1) when they

osed. Normally closed contacts present a false state (Boolean variable is en they are open.

logy with electrical circuits, contacts connected horizontally in series ent logical AND operations. Parallel contacts represent logical OR tions.

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

ossible to create LD programs that contain feedback loops, where the le from an output coil is used as an input contact, either in the same or er logical conditions. In a real-world relay circuit this is equivalent to

switch1

switch2

alarm motor

Coil

Normally open

Normally closed

contacts

contact

Power rails

4.3 Ladder Diagrams Chapter 4: Programming Languages

42

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

Fig. 15start a

EasProgrsentatpeopl

Fig. 16

start

fan

stop fan 3BSE 021 358 R201 Rev B

Feedback loop in an LD program. The fan starts with an impulse on contactnd continues to run until the contact stop is opened.

y to Understandamming with LD can be learnt relatively quickly and the graphical pre-ion is easy to follow. The method is particularly easy to understand by e who are familiar with simple electrical or electronic circuits.

Status indication of an executing LD program.

Chapter 4: Programming Languages 4.3 Ladder Diagrams

3BSE 021 358 R201 Rev B

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 StructureLaddeapplicprogrtrol sybacks

Sinceblockchicamakeclear Diagrwhich

This lwrittenal daEach other

Theredata aapplicsenso

systemsome

whener tha

All ofstructgramsdata sprogr 43

r programming is a very effective method for designing small control ations. With increasing processing power and memory size with todays

ammable controllers, the method can also be used to construct large con-stems. Unfortunately, large ladder programs have several serious draw-

.

most programmable controllers have limited support for program s, or subroutines, it is difficult to break down a complex program hierar-lly. The lack of features for passing parameters between program blocks s it difficult to break down a large program into smaller parts that have a interface with each other. Usually, it is possible for one part of a Ladder am to read and set contacts and outputs in any other part of the program, makes it almost impossible to have truly encapsulated data.

ack of data encapsulation is a serious problem when large programs are n by several different programmers. There is always a danger that inter-ta in one block can be modified by faulty code in other program blocks. programmer, therefore, has to be very careful when accessing data from program blocks.

are also problems in using structured data with ladder programs since re normally stored and addressed in single memory bits. Many control ations often have a need to group data together as a structure. Some rs provide more than one variable that has to be recorded by the control

. Apart from the physical value measured by the sensor, the application times needs to disable the sensor, place it in test mode, record the time the sensor is active and also raise an alarm if the sensor is activated long-n a certain prescribed period.

this information from the sensor should ideally be handled as a single ure that can be addressed using a common name. In most ladder pro- such data is often spread out among different ladder rungs. Without a tructure the programmable controller has no provision for warning the ammer when incorrect data are accessed.

4.3 Ladder Diagrams Chapter 4: Programming Languages

44

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 sists oremaimemo

are us

Fig. 17 3BSE 021 358 R201 Rev B

the transducers to trigger transitions between the states. Each state con-f a feedback loop using the memory bit as an alternative condition for ning in the state. The feedback loop of a state is normally broken by the ry bit of a succeeding state. To get real-world actions the memory bits ed as conditions in separate rungs to control the outputs.

Sequence program with three states controlling two outputs.

state_1

state_2

transducer_a

state_1

state_3

state_2

state_3

transducer_b

state_2

state_1

state_3

state_1

transducer_c

state_3

state_2

output_a

output_b

state_1

state_2

state_3

Chapter 4: Programming Languages 4.3 Ladder Diagrams

3BSE 021 358 R201 Rev B

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 CodeIn maover a

more

systemmodifresult

Unforstandferent 45

ny large control systems similar logic strategies and algorithms are used nd over again. A common application is to detect fire by using two or transducers with a comparison algorithm to eliminate false alarms. Such

s consist of a large number of similar ladder rungs with only minor ications to read different contacts and to set different outputs. This can in very large, unstructured programs.

tunately, very few programmable controllers have an option for defining ardized ladder blocks that can easily be called upon many times with dif- inputs and outputs.

4.4 Instruction List Chapter 4: Programming Languages

46

4.4 Instruction ListInstruction 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 system

IL LIL is aconsiwhat Sometors s

IL prooperajump All lathe prright strongLarge

Fig. 18

To imopera

Lab

Grea 3BSE 021 358 R201 Rev B

s.

anguage Structure language with a series of instructions, each on a new line. An instruction

sts of an operator followed by an operand. The operator tells the system to do, while the operand identifies which variable is to be processed. operators can process more than one operand, in which case, the opera-hould be separated by commas.

grams are often written on a spreadsheet-like form with one column for tors and another for operands. Labels, used to identifying entry points for instructions, are placed in their own column to the left of the instruction. bels should end with a colon. The instructions only need to have labels if ogram contain jumps. Comments are placed in a fourth column to the of the operand. Comments are enclosed by asterisks (*comment*). It is ly advisable to add comments to all instructions during programming. IL programs without comments are very difficult to follow.

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

prove readability, IL instructions are normally structured so that labels, tors, operands and comments are put in fixed tabulated positions.

el Operator Operand CommentLD 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*)

ter: LD speed2 (*Load speed2*)

Chapter 4: Programming Languages 4.4 Instruction List

3BSE 021 358 R201 Rev B

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.

ProgrnaturaThe pable. in a BJMPCthe nethe nethe R

IL InThe Imanydefinein curation

Somechangmust follow

N, C, (, d

Fig. 19

OpeLDNANDOR) 47

ammable controllers normally only have one result register. This must lly be taken into consideration by the programmer when writing code. rogram example in Fig. 18 on page 46 first loads the RR with a real vari-The second instruction compares RR with another variable which results oolean TRUE or FALSE result in RR. The conditional jump instruction N uses the Boolean value in RR as a condition for either continuing with xt instruction (RR false) or jumping to the label Greater. In both cases, xt instruction loads RR with a new real value. The final instruction stores R in a real variable called motor controlling the speed of the motor.

struction SetEC has developed a standardized instruction repertoire by examining the low-level languages offered by different vendors. The IL language, as d in IEC 61131-3, is a selection of the most commonly used instructions rent programmable controllers. Each instruction is written as an abbrevi-of the corresponding operation, sometimes referred to as a mnemonic.

IL operations can take operator modifiers after the mnemonic that e the behavior of the corresponding operation. The modifier character complete the operator name with no blank characters in between. The ing three modifiers can be used:

Boolean negation of the operandConditional operationelayed operation

Example of operator modifiers in an IL program.

rator Operand Commentswitch1 (*Load inverse of switch1*)

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

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

4.4 Instruction List Chapter 4: Programming Languages

48

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.

Fig. 20

OpeLDSTSRANDORXORADDSUBMULDIVGTGEEQLELTNE)CALJMPRET 3BSE 021 358 R201 Rev B

The IL instruction set.

rator Modifier DescriptionN Loads operand in RRN Stores current result from RR

Sets the operandResets the operand

N, ( Boolean ANDN, ( Boolean ORN, ( Exclusive OR( Arithmetic addition( Arithmetic subtraction( Arithmetic multiplication( Arithmetic division( Comparison greater than( Comparison greater than or equal to( Comparison equal( Comparison less than( Comparison less than or equal to( Comparison not equal

Executes delayed operationC, N Calls a function blockC, N Jumps to labelC, N Returns from called function

Chapter 4: Programming Languages 4.4 Instruction List

3BSE 021 358 R201 Rev B

Best System PerformanceIL is ideal for solving small straightforward problems. In the hands of an ex-perienced programmer it produces very effective code resulting in applications that are optimized for fast execution.

There is also another reason for using IL in order to optimize system perfor-mance. During a period of several years a huge amount of software has been writteand rebehav

WeaSincecode progrdiffic

The bmakeno au

the aceach

MacOf allUnfornot fuister sstorinbehav

Anothdefineprogrtected 49

n and thoroughly tested. Such software can be modularized into libraries used even by programmers with no detailed knowledge of the internal ior.

k Software Structure IL is a low-level language, great care should be taken in structuring the so that it is easy to understand and maintain. It is very important that IL ams are well documented since conditional jumps will otherwise be very ult to follow.

ehavior of the result register, with only one value available at a time, s it difficult to work with structured data variables. Most compilers have tomatic function for checking whether the RR contains correct data for tual instruction code. Therefore, it is up to the programmer to ensure that instruction is given correct variable data.

hine-dependent Behavior the five IEC languages, IL has been found to be the most controversial. tunately, the semantics, i.e. the way in which the instructions operate, are lly defined in the standard. For example, it is unclear how the result reg-tores values of different data types. Normally, the RR is not intended for g structured data, which means that it is very difficult to obtain consistent ior when working with arrays or strings.

er problem is that the control system behavior for error conditions is not d. This means that different system types may respond differently if the

ammer uses inappropriate data types. Errors can normally only be de- when the system is running the application.

4.5 Structured Text Chapter 4: Programming Languages

50

4.5 Structured TextStructured 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.

StatAll Sseparvalueoperastatem

ass

sel iter fun con

The laline fei.e. w

An exinvolvsimpl

mo

spIF

EL

EN

Fig. 21

Statemany nat a fi 3BSE 021 358 R201 Rev B

ementsT programs contain a list of statements, each ending with a semicolon ator. Statements contain expressions which, when evaluated, result in a of a variable having any kind of data type. Expressions are composed of tors and operands. The ST language supports five different types of ents:

ignment statement, variable := expression;ection statements, IF, THEN, ELSE, CASEation statements, FOR, WHILE, REPEATction and function block control statementstrol statements, RETURN, EXITnguage statements can be written in a fairly free style with spaces, tabs, eds and comments inserted anywhere between operators and operands,

here a space is needed for separation.

pression can be short, for example a literal constant, or very complex ing many other nested operations. The assigned variable can be either

e or structured containing any number of elementary data types.

tor := (start or motor) and not stop;eed3 := temp1*temp2 - 5*value7; speed3 < 0 THENtank_level := 25.8;SEtank_level := 30.6;D_IF;

Example of a simple ST program.

ent text should be written in a structured way. The computer will accept umber of spaces in a statement but it is good practice to place statements xed position according to their role in the hierarchy.

Chapter 4: Programming Languages 4.5 Structured Text

3BSE 021 358 R201 Rev B

Operators in ExpressionsThe table below summarizes the arithmetic and Boolean operators in the IEC standard. The operators are listed in executi