ABB - IEC61131

Development version

ControlIT

ICE 61131 Control LanguagesIntroduction

Control IT

IEC 61131 Control LanguagesIntroduction

Development version 3BSE021358R101 (0-2)

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: 0009Document version: 0-2Document number: 3BSE021358R101

Printed in Sweden.

7UDGHPDUNV

Registered trademarks from other companies are: Microsoft™, Windows™, Windows NT™ from Microsoft Corporation.PostScript™ and Acrobat Reader™ from Adobe Systems Inc.


3BSE021358R101

Contents

1 Evolution of control systems 51.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Control applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Monitoring subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Sequencing subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Closed loop control subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Relay logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Computers for process control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Programming methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.6 Programmable controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

I/O units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Programming methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Computer based programming tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Cyclic execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Distributed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Soft PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Why open systems are needed 212.1 Programming dialects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2 Software quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Software cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4 Portable software applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5 Re-usable software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.6 Communication with other systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 The IEC 61131-3 standard 273.1 Main objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Benefits offered by the standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Well structured software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Five languages for different needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Software exchange between different systems . . . . . . . . . . . . . . . . . . . . . . 29

3.3 PLCopen trade association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

(0-2) Development version 1

Contents

2

4 Programming languages 314.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Common elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Constant literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Ladder Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Easy to understand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Weak software structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Limited support for sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Difficult to re-use code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 Instruction List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42IL language structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42The IL instruction set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Best system performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Weak software structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Machine dependent behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5 Structured Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Operators in expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Conditional statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Calling function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Suitable for complex calculations and looping . . . . . . . . . . . . . . . . . . . . . 49High threshold for programmers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.6 Function Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Syntax for function block diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Standard function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Similar to electrical diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Boolean functions and feedback are easy to implement . . . . . . . . . . . . . . 56Not suitable for conditional statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.7 Sequential Function Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Chart structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Steps and transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Action descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Sequence selection and simultaneous sequences . . . . . . . . . . . . . . . . . . . . 60Sub-sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Advice on good programming style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Powerful tool for design and structuring . . . . . . . . . . . . . . . . . . . . . . . . . . 63Other programming languages are needed . . . . . . . . . . . . . . . . . . . . . . . . . 63


Contents

3BSE021358R101

4.8 Function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Definition and instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65User defined function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Differences between functions and function blocks . . . . . . . . . . . . . . . . . . 67How to use function blocks in control programs . . . . . . . . . . . . . . . . . . . . 68Interaction between languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 Object-oriented programs 715.1 New life for an old method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2 Objects in the plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.3 Re-use of code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.4 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6 Control system glossary 77A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Index 85

(0-2) Development version 3

Contents

4

Chapter 1: Evolution of Control Systems 1.1 Introduction

3BSE021358R101 (0-

Chapter 1

Evolution of Control Systems

1.1 IntroductionAlmost all industrial plants need some kind of controller to ensure safe and eco-nomical operation. At the simplest level, the plant may consist of an electric motor driving a cooling fan for controlling the temperature in a room. At the other ex-treme, the plant could be an entire nuclear reactor for producing electrical energy to thousands of people. Apart from their size and complexity all control systems may be divided into three well separated functional parts; the transducers, the con-troller and the actuators.

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

The controller monitors the actual status of the plant processes through a number of transducers. The transducers converts 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 analogue transducers mea-sure conditions which have a continuous range, such as temperature, pressure, flow or liquid level.

Plant

Inputs Outputs

Transducers Actuators

Controller

Parameters Status

2) Development version 5

1.2 History Chapter 1: Evolution of Control Systems

6

cho-s are

f OS .

erma-im-ior.

large

r ICs.

rtu-. As

de-

Based on the status of the inputs the controller uses a built in or programmed al-gorithm to calculate the status of the outputs. The electrical signals from outputs are converted to process behavior via the actuators. Most actuators create move-ment for 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 connected screen.

1.2 HistoryThe first control systems were developed during the industrial revolution in the end of the 19th century. The control function was implemented by using ingenious mechanical devices automating some of the most repetitive and critical tasks in the assembly lines. These devices had to be individually adopted to each task and due to their mechanical nature they also suffered from a short life cycle.

In the 1920s the mechanical control devices were replaced by electrical relays and contactors. Relay logic made it possible to develop larger and much more sophis-ticated control functions. Electrical relays has since then 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 seldomsen for developing new control systems but a large number of older systemstill in use.

The silicon based Integrated Circuit, IC, paved the way for a new generation ocontrol systems in the 1970s. Compared to relays, ICs based on TTL or CMintegrated circuits are much smaller, faster and also have a longer life cycle

In most control systems, based on relays and ICs, the control algorithm is pnently defined by the electrical wiring. Systems with wired logic are easy to plement but unfortunately it is difficult and time consuming to alter their behav

In the early 1970s the first commercial computers debuted as controllers in control systems. Since the computer can be programmed it offers a great advantage compared to the wired logic function in systems based on relays o

Early computer systems were large, expensive, difficult to program and unfonately also very sensitive to the rough environment in many industrial plantsa result of demands from the American car industry the Programmable Logic Controller (PLC) was developed in the early 1970s. The PLC is a computer signed to work in an industrial environment. The transducers and


Chapter 1: Evolution of Control Systems 1.2 History

3BSE021358R101 (0-

to ntrol

bor-usu-

s

rs e ac-

t ad

actuators from the outside world are connected via robust interface cards. Com-pared to an office computer the PLC has a limited instruction repertoire, often only logical conditions.

Early PLCs had no analogue inputs and therefore they could only handle digital control applications. In today’s industrial plants there often is a need handle both digital control and closed loop analogue control with the same cosystem. These systems are often called Programmable Controllers since their op-eration is not limited to only logical conditions.

Today the overall control function in a plant often is distributed to a number of local programmable controllers which are positioned in the immediate neighhood of the objects which are to be controlled. The different controllers are ally connected together into a local area network (LAN) with a central supervising process computer which administers alarms, recipes and operationreports.

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 plantinstallations therefore have a computer based Supervisory Control and Data Ac-quisition System (SCADA). SCADA systems have high-resolution color monitoon which the operator can select different application programs and study thtual status of the manufacturing process.

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 ouchanges in the control function. Because the cost of computer equipment h

19201880 1970 1980 1990 2000

Mechanics

Relays

ICs

Computers

PLCs

Processcomputers


1.3 Control applications Chapter 1: Evolution of Control Systems

8

dropped dramatically in recent years, the cost of development and maintenance of software has become the entirely predominant factor.

In order to improve the quality and make it easier to re-use programs, there are today many more people working with object-oriented systems. In such systems the real process components like motors, valves and PID controller are pro-grammed via standardized program objects stored in program libraries. Such ob-jects are well proven and have a standardized user interface.

1.3 Control applicationsIt 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 small sub-processes. Such sub-processes can normally be divided into three dif-ferent categories. Monitoring subsystems, sequencing subsystems and closed loop control subsystems will be further described in the three following sections.

Monitoring subsystemsA monitoring subsystem displays the process state to the operator and draw attention to abnormal conditions which need some kind of action from the operator. The measured process values for temperature, pressure, flow etc. are dis-played to the operator via indicators, meters, bargraphs or via a computer screen.

Signals can also be checked for alarm conditions. The system indicates alarms via warning lamps or audible sounds, often accompanied by a paper printout.

Many monitoring systems also keeps 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 subsystemsThe vast majority of all sub-processes can be described via a predefined sequence of actions that have to 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 of an entire sequence of input signals having occurred. In order to monitor the sequence of actions there is a need for memory functions.

Sequencing subsystems have a lot of advantages compared to 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 mal-function in a transducer since this will cause the sequence to freeze.


Chapter 1: Evolution of Control Systems 1.4 Relay logic

3BSE021358R101 (0-

Closed loop control subsystemsMany sub-processes have analogue variables such as temperature, flow or pres-sure that need to be kept automatically at some preset value or made to follow other signals. Such a system can be represented by the block diagram of Fig. 3. Here a variable in the plant denoted PV (Process Value) is to be kept at a desired value denoted SP (Setpoint).

PV is measured by a transducer and compared with SP go give an error signal. This error signal is supplied to a control algorithm that calculates an output signal that is passed to an actuator which affect the actual variable in the process.

The control algorithm will try to adjust the actuator until there is zero error. There are many possible control algorithms available but the most commonly used is the Proportional, Integral and Derivative (PID). Since the control function is running continuously, the PV can be made to track a changing SP.

Fig. 3 A closed loop control system.

1.4 Relay logicThe electromagnetic relay has been one of the most important components in the evolution of control systems. Relay logic systems contain a number of relays that are activated by the digital transducer contacts. The control function is defined, once and for all, by how the contacts are connected together with each other and with the corresponding relay coils.

Controlalgorithm Process

SP-PVErrorDesired

value Controlled

SP

PV

Transducer

variableActuator

Actual value


1.4 Relay logic Chapter 1: Evolution of Control Systems

10

wir-mber cers

ed ex-

All relay coils are 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 are used as an alternate input contact the result will be a circuit with memory function.

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

A relay based control system may contain any number, from a dozen and 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 electrically 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 it’s time consuming to do the electricaling, the total cost of a relay based control system depends mainly on the nuof relays used. In large plants the limited number of contacts on both transduand relays sometimes will cause engineering problems.

Experience shows that it is easy to develop small relay systems with a limitnumber of relays but with increasing complexity the work will demand a veryperienced engineer.

Logical AND

Logical OR

Memory


Chapter 1: Evolution of Control Systems 1.5 Computers for process control

3BSE021358R101 (0-

and s like

many

that very of in-evel-

aces ven-e pro-

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 electro-magnetic components they have a limited life cycle. Relay based control systems therefore need continuous maintenance and service. Another disadvantage with 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 interferences, where com-puters and programmable controllers can’t be used.

1.5 Computers for process controlThe first computers, that were developed during the 1950s, were very largeexpensive machines. Such systems were mainly used for administrative taskpayroll, accounting and banking. The operations performed 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 control systems were developed using microprocessors as controllers.

The most important advantage with computers, compared to wired logic, is the programmed control function easily can be altered. Computers are alsosuitable for performing arithmetic calculations and for storing huge amountsdata. A standard computer however is not equipped for communicating withdustrial equipment. Another disadvantage is the high learning threshold for doping computer programs.

Early computer based control systems needed extra interface equipment inorder to handle the real world transducer and actuator signals. These interfnormally had to be individually developed for each plant. Since then severaldors have developed standard interface modules for both digital and analogucess signals.


1.5 Computers for process control Chapter 1: Evolution of Control Systems

12

c- we and hese heap-

era-g a et o uld

gram-

An ng of

t be is

, the cal type r pro-

rs.

allow

can

Programming methodsAll computer programs consist of a number of instructions which tell the comput-er what it is to do when the program is run, or executed as programmers prefer to call it. Because computers process binary information, the computer’s instrutions are very different from our own verbal ways of describing those actionswant it to take. In programming, therefore, various aids are used to processtranslate our verbal function description into the computer’s own language. Taids are ready-made computer programs which can be purchased relatively cly.

Machine code and assemblerMost computers have a limited set of instructions which carry out simple options such as fetching data, storing data, adding numbers, etc. By combininlarge number of such machine codes into long programs, the programmer can gthe computer to carry out very complex functions. In order for the program twork, however, it is very important to follow the rules on how instructions shobe used and combined, often called the syntax of the program.

Because machine codes are binary or hexadecimal numbers, the job of proming 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 edi-tor is normally used when writing assembler instructions into the computer. editor program has basic word processing functions for entering and correctitext.

Before the assembler program can be executed, the memo-codes must firstranslated into hexadecimal machine code. The translation to machine codedone by another program called an assembler. Assembler programs of this kind can be bought for most types of computers. Apart from the actual translationassembler program can also help in syntax checking and in calculating logijumps within a program. The assembly is normally carried out on the same of computer as will then be used in its execution, but there are also assemblegrams, known as cross-assemblers, which can be run on other types of compute

Test running of assembler programs is made easier by special programs thatpart 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 their functionbe tested without having to connect it up to the actual process.


Chapter 1: Evolution of Control Systems 1.5 Computers for process control

3BSE021358R101 (0-

type her e op-us-using r

tten e

Programming using assembler instructions has both advantages and disadvantag-es. The work demands a thorough knowledge of the technical workings of the computer. In most cases the problem description also has to be restructured so that the required function can be obtained using the instructions available in the com-puter’s repertoire. The finished program is entirely matched to one particular of computer and cannot be transported to another computer type. On the othand, a properly written assembler program gives good performance and thtimal usage of the computer’s memory. This is important in, for example, indtrial robots and where systems are to be produced in very large series. Work assembler is often called low level language because the instructions are similato the computer’s own way of working.

Compiling and interpretingThe work of programming is made considerably easier if the program is wriin what is known as a high-level language, which is translated into machine codby a program-based compiler or interpreter.

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

Start

Assembling

Stop

Assembler

LDA IN1

L1 SUB C

CMP B

BNE L1

ADD D

STO OUT1

F60AA92312E3F87606A345D3A2

No

Yes

Editingusing editor

Test-runningusing debugger

Functioningproperly?


1.5 Computers for process control Chapter 1: Evolution of Control Systems

14

The difference between compilers and interpreters is that the compiler first trans-lates the whole program before it is executed, while the interpreter translates and executes the program instructions one by one. This means that compiled 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 functions, and are therefore relatively easy to use. All high-level languages are highly stan-dardized, and the main parts of the programs can be written so that they are inde-pendent 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 a high-level languages are often known as source code, while the compiled result is called object code.

The programmer writing in a high-level language does not need to know the tech-nical details of the design of the computer or its memory. Another advantage is that finished 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 which are written direct-ly in assembler (machine code). This also means that the performance of the com-puter is used less efficiently.

Fig. 6 Programs written in a high-level language are totally machine-independent and are translated to computer-specific machine code by a compiler program.

Compiler

Profit := Income - Cost

IF Profit>20 THEN PRINT "Profitable"

ELSE PRINT "Loss"

END

020CA74337E3F88616A245A205A3127B

Source code in Pascal


Chapter 1: Evolution of Control Systems 1.6 Programmable controllers

3BSE021358R101 (0-

ave

d d s esen-

1.6 Programmable controllersAnswering 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 as a replacement for relay based control systems. Since then PLCs have developed into the most used type of control systems in all kind of industry plants, from small machine control systems and up toentire manufacturing lines in large process industries.

Independent of brand and type most PLCs contain three functional parts; the cen-tral unit, the memory and the I/O unit, all communicating via a bus unit. The cen-tral unit coordinates all activities in the PLC and executes the control program in the memory. The actual process status is monitored and sampled via the I/O unit.

Apart from logical instructions an increasing number of today’s PLCs also harithmetic functionality. Many vendors therefore are using the termProgrammable Controller instead of PLC.

Programming of PLCs is normally carried out on an external computer baseen-gineering station. The compiled program is downloaded to the central unit anfurther into the program memory via serial channel or via a LAN. Some PLChave an option for using the engineering station for online process status prtation, while the control program is executing.

Fig. 7 The components of a programmable controller system.

Central unit

Engineeringstation

Memory

Bus unit

I/O unit

Input modules Output modules

PLC

Transducers Actuators


1.6 Programmable controllers Chapter 1: Evolution of Control Systems

16

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 modular-ized 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 photoelectric transistor linked together in a package.

Since there are several different signal levels in a typical plant many I/O units al-low the use of exchangeable I/O modules. Such an I/O unit can easily be custom-ized to the specific signal levels of the actual plant.

The most used I/O modules are digital DC inputs and outputs with the signal lev-els 24 V or 48 V. Many vendors also offer modules with AC inputs and outputs using signal levels 110 V or 220V.

A growing number of programmable controllers have arithmetic functionality. Such systems have a need for analogue input and output I/O modules. Most ana-logue transducers represent their physical value as a current within the range 4-20 mA, with 4 mA indicating the minimal value.

Programming methodsThe first PLCs used a programming language based on relay ladder diagrams. The program was entered via a programming terminal with keys showing contact symbols (normally open/normally closed), relay coils and parallel branches with which a maintenance electrician would be familiar.

The programming terminal compiled the ladder diagram into machine codes which were 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 necessary, to debug program errors.

Programming with ladder diagrams is a very intuitive method, especially for per-sons with previous knowledge of relay based control systems. Therefore this method from the start was preferred by the American PLC vendors.



3BSE021358R101 (0-

In large plants and when people without previous knowledge of relay logic are todevelop the control program, Boolean instruction lists are often preferred. MostEuropean PLC vendors have chosen this as the standard programming method intheir systems.

Computer based programming toolsEarly PLCs were programmed with dedicated terminals only usable for that pur-pose and together with specific systems from one vendor. Today almost all pro-grammable controllers are programmed with standard personal computers (PCs) running a dedicated development software tool. Advant Control Builder from ABB is an example of such a software tool intended for use with some of the pro-grammable controllers from ABB. A complete system with computer and devel-opment software is often referred to as an engineering station.

Most development tools contain several different, but often integrated, software applications which simplify the work with program development for the associated control system.

The editor is used for defining variables and for writing the actual control pro-gram instructions. Most editors have syntax checking that helps the programmer avoid such errors. Program editing is normally done off-line, which means that the engineering station is running locally without communication with the controller.

The compiler translates the control application into machine code and downloads 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. Sim-ulation makes it possible for the programmer to test the application by manually altering the actual input signals.

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

A 001A 012ON 020RPA 003= 201

0 0 1 0 1 2 0 0 3

0 2 0

2 0 1



18

Some development tools can be used on-line, 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 the computer based engineering stations, several vendors now offer developing packages where it, apart from ladder diagrams and instruction lists, also is possible to use programming methods like Structured text, Sequential Function Charts and Function Block Diagrams. These methods are further described in Chapter 4.

Cyclic executionIndustrial control systems are real-time systems, which means that changes in the input signal require immediate action on the corresponding output signals. An ex-ample may be a machine where some movement has to be stopped when a partic-ular limit position is reached. If the controller does not react in time, the result may be that the machine is destroyed or that the operator gets injured. The conse-quences 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 therefore only can affect the output signals at the end of each completed program cycle. The required cycle time of the program is determined by the maximal allowed delay time in the process.

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

Updateoutputs

Read inputs

Executeprogram

Cycle time1 - 50 ms



3BSE021358R101 (0-

an-

Because different sub-processes may have variable time demands, some program-mable controllers provides a function for dividing the total program into different tasks, each with its own cycle time.

Distributed systemsIn many large industrial plants there is a need for distributing the entire control function to several different programmable controllers and process computers. This strategy will improve total performance and additionally also reduce the risk for a total breakdown in the manufacturing process.

The cabling between transducers, actuators and the programmable controllers ac-counts for one of the major costs in a control system. If the plant is spread out on a large area great cost savings may be achieved by using remote I/O sub-systems situated close to the actual sub-process.

Distributed control systems need a standardized communication protocol in order to exchange information. Several PLC vendors have developed their own propri-etary protocols during the 1990s and some of these like COMLI from ABB, 3964R from Siemens, Data Highway Plus from Allen Bradley and the vendor in-dependent Profibus have slowly emerged into de facto standards supported by more than one PLC vendor.

Soft PLCOne problem with PLCs is that all vendors use their own proprietary controller hardware with an associated programming language. In spite of the basic func-tions being practically identical, the instructions are named differently and there are also to a certain extent different rules for the syntax of the programs. This makes it difficult to communicate and exchange application programs between systems of different manufacture.

Several software vendors have presented a new type of controller named the Soft PLC. The Soft PLC is a 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 with a Soft PLC is that all the needed hardware is vendor independent. Unfortunately no one of the software vendors have managed to es-tablish their Soft PLC software as an industry standard. This means that control applications developed with one Soft PLC application can’t be transferred toother vendors Soft PLC.



20

Chapter 2: Why open systems are needed 2.1 Programming dialects

3BSE021358R101 (0-

Chapter 2

Why open systems are needed

2.1 Programming dialectsThe programmable controller is one of most critical components in todays industry. With control systems being used in so many plants and with applications concerned with safety, it is very important that programs can be understood 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 pro-gramming dialects. Many customers using programmable controllers have, in or-der to minimize risks, decided to standardize their equipment to at least two different vendors. In real world applications this often leads to costly double work and problems with communication between different brands of systems.

2.2 Software qualityAs more and more jobs in manufacturing and process industries become automat-ed, the software programs become larger and thereby 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 involved programmers and consequently the size of the program itself.

Experience also shows that new industrial plants often face problems for a long period after the installation. Some failures can interrupt the production or in the worst case also result in serious damages to the production equipment or the pro-cessed material.

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 thereby cost is out of the free market. Consequently the software suppliers are not motivated to search for more efficient development methods and tools.


2.3 Software cost Chapter 2: Why open systems are needed

22

qual- With , the ram dard-

The vast majority of all control code is written with the proprietary software pack-ages delivered by the control system vendors. Many of these packages have very poor facilities for working with modules, for code re-use and for documentation. Software quality therefore is heavily dependent of 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 costIn the last decade standardized software packages for personal computers, like word processors and spreadsheets, have become very popular selling in millions of copies. This makes it possible for the software vendors to lower prices dramat-ically. Distribution via Internet has pushed the limits even further and today a lot of useful standard applications are available as shareware, almost free of cost.

On the contrary most software for control applications are adapted to the specific needs of a single plant application. This means that the total development cost has to be charged on a single customer.

Most customers find it difficult to get control of 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 covers the customers requirements. Even small changes and additions tends to be very costly to implement, especially in a late phase of the program development.

The hardware on which computer programs are run is developing at an amazing speed, while prices are constantly falling. Today’s personal computers have ely good, or even better, performance than yesterday’s mainframe computers.the increasingly good relationship between hardware performance and pricetotal cost of an installation is more and more determined by the time for progdevelopment. In most projects, therefore, greater weight is attached to stanization and reuse of programs than with finding the optimal hardware.


Chapter 2: Why open systems are needed 2.4 Portable software applications

3BSE021358R101 (0-

Fig. 10 Cost of hardware versus software.

An automation plant or machinery can become dangerous 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 the testing may be very time consuming, especially if the work has to be done with the process running. If the application program has been written by non experienced programmers the cost of testing even may exceed the cost of program coding.

2.4 Portable software applicationsThe personal computer together with the Windows operating system is today a well established de facto standard for information handling in almost all offices in the world. The main reason for the PCs enormous penetration is soft-ware 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 controllers this market still lacks an international standard similar to the PC. Most control vendors use their own proprietary programming dialect that only can be used with their hardware.

On the contrary almost all industries using programmable controllers have high demands for inter-system portability of control system software. Since develop-ing costs of well tested software is much higher than the hardware cost there often is a need for porting existing applications from older outdated hardware to never systems.

Many observers find it to be a mystery 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.

1960s 1970s 1980s 1990s 2000s0

10

20

30

40

50

60

70

80

90

100

Cost of hardware

Cost of program development


2.5 Re-usable software Chapter 2: Why open systems are needed

24

the

e di-heir

over-d cost

f the ehav-

trong-e re-oded

cour-

aced n-hine

the laced

of the n.

m-a ex-

2.5 Re-usable softwareNot so long ago many “real programmers” measured their effectiveness by amount of program code produced per day. Real programmers don’t like to “waste” their time on structuring and detailed specification. Instead they movrectly from a rough specification, often made by the customer, to coding in tfavorite language, often Ladder Diagram or Instruction List.

Today even real programmers realize that the first face in a project when theall function is analyzed, structured and designed is the key to a successful aneffective application program.

The traditional method of reducing software cost is to re-use common parts oprogram code in several similar applications. Unfortunately this is difficult toachieve in industrial automation since most processes are very different in bior.

Another obstacle to software re-use is that the program code most often is sly affected by the personal programmer style. When the final application is thsult of a team work there often are visible seams between the different parts cby different programmers. The only way to reduce the risk of seams is to enage (read force) all the members in the team to follow certain rules and formalism for producing code.

2.6 Communication with other systemsThe first programmable controllers presented in the seventies were often plin an electrical equipment cabinet close to the machine or process being cotrolled. These controllers normally had no means for interaction with the macoperator or for communication with other controllers.

In todays industrial plants great emphasis is put on operator interaction withsystem. The huge control centers in e.g. nuclear power stations are being repby PC-based Supervisory Control and Data Acquisition Systems (SCADA) using a large color screen for presenting process pictures with actual status. Two most used SCADA-systems are SattGraph from ABB and FIX from Intellutio

In large industrial plants the total control function is normally divided into a nuber of different programmable controllers communicating with each other visome kind of standardized communication protocol. SattLine from ABB is anample of such a Distributed Control Systems (DCS).


Chapter 2: Why open systems are needed 2.6 Communication with other systems

3BSE021358R101 (0-

Most of the control system vendors have developed their own proprietary commu-nication protocols for information exchange in SCADA and DCS. Some vendors also provide software based protocol converters enabling communication be-tween different brands of systems.

All industrial plants have computer based Management Information Systems (MIS) for handling of statistical and economical information. Often there is a need to connect MIS with SCADA and DCS resulting in a total control and man-agement system. General Motors in the USA have developed a standard named Manufacturing Automation Protocol (MAP) for communication between differ-ent programmable controllers and MIS. Unfortunately the MAP-standard so far have not been particularly successful.


2.6 Communication with other systems Chapter 2: Why open systems are needed

26

Chapter 3: The IEC 61131-3 standard 3.1 Main objectives

3BSE021358R101 (0-

ation

te.

s-

, Lad-

e or con-

Chapter 3

The IEC 61131-3 standard

3.1 Main objectivesIEC 61131-3 is the first, and so far only, global standard for programmable con-trollers. Considering that programmable controllers have been used in automation systems for more than two decades it is remarkable that a program-ming standard has taken so long time to evolve. The IEC working group, with members from all the leading vendors, have after years of discussions finally come to a consensus and produced a working standard. The main objectives of the IEC 61131-3 standard are as follows:

• The standard encourages well structured program development. All applicprograms should be broken down into functional elements, referred to aspro-gram organisation units or POUs. A POU may contain functions, function blocks and programs.

• Different parts of the application program can be executed at their own raThis means that the system must support individual cycle time 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 tranferred between different parts of a program as if they were a single entity.

• The system should have parallel support for the five most used languagesder Diagram (LD), Instruction List (IL), Function Block Diagram (FDB), Structured Text (ST) and Sequential Function Chart (SFC).

• The programming syntax should be vendor independent, resulting in morless portable code that can easily be transferred between programmabletrollers from different vendors.


3.2 Benefits offered by the standard Chapter 3: The IEC 61131-3 standard

28

3.2 Benefits offered by the standard

Well structured softwareThe main purpose of the IEC 61131-3 standard is to improve overall software quality in industrial automation systems. The standard encourages development of well structured software that can be designed either from top-down or from bot-tom-up. One of the most important tools for obtaining this is the use of function blocks.

A function block is a part of a control program that has been packaged and named so that it can be re-used in other parts of the same program or even in another pro-gram or project. Function blocks can provide any kind of software solution from simple logical conditions, timers or counters to advanced control functions for a machine or a 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 re-used without risk for data conflicts and malfunction.

Five languages for different needsThe IEC 61131-3 standard have support for five of the most used programming languages on the market. Depending on previous experience programmers often have their personal preferences for a certain language.

Since most older programmable controllers use Ladder Diagram or Instruction List programming there often are a lot of such programs available. These pro-grams can relatively easy be re-used in newer systems supporting the standard.

Todays programmable controllers can handle both logical conditions for digital signals and arithmetic operations on analogue signals. Arithmetic operations 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 describing 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 definition of function blocks using all the languages.


Chapter 3: The IEC 61131-3 standard 3.3 PLCopen trade association

3BSE021358R101 (0-

t sys-diza-

ch uires

to the be list.

er of s -

rting about artic-as de-

l pro-t to

ons

Software exchange between different systemsBefore the IEC 61131-3 standard was established it was not possible to port con-trol 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 sys-tem 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 porting software is much better. Software developed for one manufacturer’s systemshould, at least theoretically, be able to execute on any other IEC compliantem. This would open up the market dramatically resulting in better standartion, lower prices and also improved software quality.

Unfortunately such a high level of software portability may be difficult to reain practise. The IEC 61131-3 standard defines a lot of features and only reqthat vendors of programmable controllers specify a list of which features their system supports. This means that a system can be compliantstandard without supporting all features. In practice portability therefore willlimited, since systems from two different vendors often have different feature

3.3 PLCopen trade associationSince the IEC standard has relatively week compliance requirements a numbthe largest control system companies concerned with software portability haformed the PLCopen Trade association. PLCopen is a vendor and product independent world wide association supporting the IEC 61131-3 standard.

Being founded in 1992 in The Netherlands, PLCopen today also has suppooffices in Canada and Japan. The organisation informs users/programmers the standard via a website (www.plcopen.org), a free quarterly newsletter, pipation at trade shows and by arranging their own conferences. PLCopen hfined three different compliance classes concerning the portability of control system software.

The lowest class is Base Level defining a core kernel of the standard. Althoughrather restricted it is feasible to develop applications based on it. Base Levevides an entrance for the control system vendors, showing their commitmenthe standard.

Portability Level contains a large set of features including user defined functiand function blocks. This level also demands that the system has an


3.3 PLCopen trade association Chapter 3: The IEC 61131-3 standard

30

export/import tool for easy exchange of program code between systems from dif-ferent manufacturers.

The highest level, Full-Compliance, provides exchange of complete applications, including configuration information, between different control systems.


Chapter 4: Programming languages 4.1 Overview

3BSE021358R101 (0-

hical ortant ge.

lan-e re-

Chapter 4

Programming languages

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

• Ladder Diagrams, LD

• Instruction List, IL

• Structured Text, ST

• Function Block Diagram, FBD

• Sequential Function Charts, SFC

IL and ST are textual languages while LD, FBD and SFC are based on grapmetaphores. Since all of these languages have both pros and cons, it is impto have a brief knowledge of the most suitable applications for each langua

Although most control systems may be implemented with any one of the fiveguages the resulting program will be more or less effective depending on thquirements of the control application.

Fig. 11 A simple boolean condition programmed with four of the five IEC 61131-3 programming languages. SFC is normally only used for sequences.

A1

A2

A3 M1 LDN A3AND( A1OR A2)ST M1

LD IL

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

ST FBD

1& M1

A1

A2

A3


4.1 Overview Chapter 4: Programming languages

32

pref-ular natu-

r Many lays

e di-n in

. A run-ave

un-h chine dif-

f the m ers

Historically the five languages have evolved in parallel with the evolution of au-tomation systems. Relay systems documented via LD were the dominant technol-ogy in the 1950s. Logical circuits described by FBD were used mostly in the 1960s. PLC:s debuted in the 1970s with programming i 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 a graphical languages like SFC.

Before the IEC 61131-3 standard was established most vendors of programmable controllers supported only one or two of the programming languages. By tradition most american vendors have preferred LD languages while european vendors have standardized on FBD or IL languages.

The choice between different programming languages is governed by several eco-nomical, technical, and cultural factors:

• Depending on age and educational background programmers often have aerence for certain languages. Programming with LD or FBD are more popamong older technicians without academic background while ST are the ral choice for younger people with a good computer knowledge.

• In small applications with relatively few logical conditions the demands fogood structure and re-use of code are less important than in larger plants. older control systems use LD as a direct analogy for systems based on reand switches.

• In large plants with a lot of sub-processes the total control function must bvided into an number of program modules with a high level of encapsulatioorder to prevent the modules from interfering with each other.

• Program languages are often characterized after their level of abstractionlow level language like IL is very close coupled to the actual binary codesning the processor in the control systems. Low level languages normally ha limited number of instructions producing very effective software code butfortunately also totally tailored for a certain brand or model of system. Higlevel languages like ST and SFC does not produces the most effective malanguage but on the other hand the program may be compiled for a lot offerent programmable controllers.

• When programmable controllers were first introduced in the 1970s most oapplications very purely boolean logical conditions. Today a control systemust handle both digital and analogue control together with timers, countand sequences.


Chapter 4: Programming languages 4.2 Common elements

3BSE021358R101 (0-

lly me by ar the

ts of rs of have

con-

or s a n un-re un-

• The cost of software development has a tendency to increase exponentiawith the size of the plant. Since many control functions are used in the saway over and over again it is possible to simplify the application programusing generalized standard modules. Re-use of standard modules is by fmost effective method to reduce costs.

• When industrial plants are redesigned with new control systems large parold program code, that has been tested and debugged during several yeaintensive use, is often re-used. Even the most up to date systems thereforeto support older and generally less effective languages.

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

4.2 Common elementsThe IEC standard defines a lot of common elements which are used in all of the programming languages. This section explains the rules for using identifiers,stants, data types and variables.

IdentifiersIdentifiers are used for naming different elements within the IEC language. Fexample variables, data types, function blocks and programs. An identifier istring of letters, digits and underline characters which begin with a letter or aderline character. Space characters are not allowed in identifiers. Two or moderline characters may not be used together.

1950 1960 1970 1980 1990

Structure level

High

Low

Year

LD

IL

FBD

ST

SFC

2000


4.2 Common elements Chapter 4: Programming languages

34

l in the

used stan-

pe e con-

Keywords are special identifiers that are used within the IEC language as individ-ual syntactic elements. You are not allowed to use keywords as identifiers, for ex-ample:

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

Some compilers may be able to distinguish between them based on their position but others may produce confusing results.

Programmer’s comments are delimited at the beginning and end by the speciacharacters (* and *) respectively. Comments can be placed anywhere exceptIL language, which have some restrictions.

Data typesThe first PLC:s could only handle boolean data but todays systems are beingin an ever widening range of industrial applications. For this reason the IEC dard provides a comprehensive range of elementary data types. The most often used data types are described below:

In addition to the elementary data types programmers can define their own Struc-tured data types containing several components of data types. Such a data tyhave no physical correspondence in the plant, but it can be likened to a cabl

Allowed identifiers Illegal identifiers

Motor_1 1Motor

Elapsed_Time switch 1

_prog2 Conveyor__3

Data type Keyword BitsBoolean BOOL 1

Short Integer SINT 8

Integer INT 16

Double integer DINT 32

Long integer LINT 64

Real numbers REAL 32

Long real number LREAL 64

Duration TIME

Date DATE

Character string STRING


Chapter 4: Programming languages 4.2 Common elements

3BSE021358R101 (0-

taining a number of leads of different types, e.g. for the transfer of electrical pow-er, telephone and TV signals. All leads are given descriptive names so that the programmer can connect to them without having a detailed knowledge of their function.

A new structured data type is declared by framing the definition with TYPE and END_TYPE.

TYPE AlarmOn: BOOLEANOff: BOOLEANLevel: REALName: STRING

END_TYPE

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

Constant literalsBy giving a variable the attribute constant, you prevent it from being changed af-ter 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. Based num-bers are represented in base 2, 8 or 16 (prefix 2#, 8# or 16#). Boolean data are rep-resented by value 0 and 1 or the keywords FALSE and TRUE.

Time literals are used either for Duration data or for Time of day and date. Duration data are prefixed by the keyword T# or TIME# followed by the actual duration in terms of days, hours, minutes, seconds and milliseconds.

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

Pumptype On (BOOLEAN)

Off (BOOLEAN)

Level (REAL)

Name (STRING)


4.2 Common elements Chapter 4: Programming languages

36

ated

a

in

en gram

Time of day literals and dates are prefixed by the keywords TIME_OF_DAY#, TOD#, DATE#, D#, DATE_AND_TIME# or DT#.

VariablesVariables is a common name for 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 it’s value when the system restarts. A constant variable will not bechanged by the system. Variables with a blank attribute will always be calculat system restart.

If a variable has to start at a special value, that value has to be specified asInitial value, otherwise it will start at a predefined value depending on its dattype (normally 0).

The table below shows examples of names and attributes for variables of frequently used data types:

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 programwhich they are declared.

Global variables are accessible from any program or function block in the opproject. A global variable must be declared as an external variable in the proorganisation unit (POU) accessing it.

Access variables can be used by other controllers.

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

NumberOfRev dint constant 10

Temperature_5 real retain


Chapter 4: Programming languages 4.3 Ladder Diagrams

3BSE021358R101 (0-

4.3 Ladder DiagramsLadder Diagrams (LD) has evolved from the electrical wiring diagrams that ear-lier were used for example in the car industry for describing relay based control systems. 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, named 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 contacts in 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 represents physical ob-jects like a motor, a lamp or others but may also be an internal variable in the con-trol 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 the con-tacts are closed. Normally closed contacts present a false state (Boolean variable is 0) when they are opened.

In analogy with electrical circuits, contacts connected horizontally in serial rung represent logical AND operations. Alternate parallel paths from the main rung represent logical OR operations.

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

It is possible to create LD programs which contain feedback loops where the vari-able 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

switch1

switch2

alarm motor

Coil

Normally open

Normally closed

contacts

contact

Power rails


4.3 Ladder Diagrams Chapter 4: Programming languages

38

en-ople

using one of the relay’s physical switches as an input contact. A computer experienced person would probably call this a memory bit.

Fig. 15 Feedback loop in a LD program. The fan starts with an impulse on contactstart and continues to run until the contact stop is opened.

Easy to understandProgramming with LD can be learnt relatively quickly and the graphical prestation is easy to follow. The method is particularly easy to understand by pewho are familiar with simple electrical or electronic circuits.

Fig. 16 Status indication of an executing LD-program.

start

fan

stop fan



3BSE021358R101 (0-

o-

cks.

s or

ficult with d set t im-

e writ-l data ro-gram

ata ca-

Apart need r is ac-re-

truc-s such re the the

LD programs are very popular among maintenance engineers since faults can eas-ily be traced. Most programming stations generally provide an animated display showing the live state of transducers while the Programmable controller is run-ning. This provides a very powerful on-line diagnostics facility for locating incorrect logic paths or faulty equipment.

Weak software structureLadder programming is a very effective method for designing small control appli-cations. With increasing processing power and memory size with today’s prgrammable controllers, the method can also be used to build large control systems. Unfortunately large ladder programs have several serious drawba

Since most programmable controllers have limited support for program blocksubroutines it is difficult to break down a complex program hierarchically. Thelack of features for passing parameters between program blocks makes it difto break down a large program into smaller parts that have a clear interfaceeach other. Usually it is possible for one part of a Ladder Diagram to read ancontacts and outputs in any other part of the program, which makes it almospossible to have truly encapsulated data.

The lack of data encapsulation is a serious problem when large programs arten by several different programmers. There is always a danger that internain one block can be modified by faulty code in other program blocks. Each pgrammer therefore has to be very careful when accessing data from other problocks.

There are also problems using structured data with ladder programs since dnormally is stored and addressed in single memory bits. Many control applitions often has a need to group data together as a structure. A lot of sensors pro-vide more than one variable that has to be recorded by the control systems. from the physical value measured by the sensor the application sometimesto disable the sensor, place it in test mode, record the time when the sensotive and also raise an alarm if the sensor is activated longer than a certain pscribed period.

All of this information from the sensor should ideally be handled as a single sture that can be addressed using a common name. In most ladder programdata is often spread out among different ladder rungs. Without a data structuprogrammable controller has no provision for warning the programmer whenincorrect data is accessed.


4.3 Ladder Diagrams Chapter 4: Programming languages

40

Limited support for sequences Most control applications have a need for dividing the total 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 built with ladder programming the normal method is to as-sign one internal memory bit to each state and to use contact conditions from the transducers to trigger transitions between the states. Each state consists of a feed-back loop using the memory bit as an alternate condition for remaining in the state. The feedback loop of a state is normally broken by the memory bit of a suc-ceeding state. To get real world actions the memory bits are used as conditions in separate rungs for controlling the outputs.

Fig. 17 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



3BSE021358R101 (0-

From the above example it is obvious that ladder programs with sequences can be-come very large and difficult to maintain. The most obvious problem is that con-trol of the memory based sequence model is mixed with the application logic so that the total program behavior is difficult to understand and follow.

Difficult to re-use codeIn 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 and unstructured programs.

Unfortunately very few programmable controllers have an option for defining standardized ladder blocks that can easily be called upon many times with differ-ent inputs and outputs.


4.4 Instruction List Chapter 4: Programming languages

42

4.4 Instruction ListInstruction List (IL) is a low level language with a structure very similar to assembly language, often used for programming micro processors.

IL has been chosen as preferred language by a number of PLC manufacturers for their small to medium size systems. In larger systems the lack of structured vari-ables and weak debugging tools make the language less suitable.

IL language structureIL 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 will be processed. A few operators can process more than one operand, in which case, they should be sep-arated by commas.

IL programs are often written on a spreadsheet-like form with one column for op-erators 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 oper-and. Comments are enclosed by the starting characters (* and ending characters *). It is strongly advisable to add comments to all instructions during the program-ming. Large IL-programs without comments are very difficult to follow.

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

To improve readability, IL instructions normally are structured so that labels, op-erators, operands and comments are put in fixed tabulated positions.

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*)

End: ST motor (*Store speed to motor*)


Chapter 4: Programming languages 4.4 Instruction List

3BSE021358R101 (0-

A characteristic behavior of IL programs is that instructions always relate to an internal register, named result register, RR, IL register or accumulator. Most op-erations are a calculation between the result register and the operand. The result of an instruction is always stored in the result register. Most programs start with the instruction LD that 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 of course have be taken into consideration by the programmer when writing code. The pro-gram example in Fig. 18 first loads the RR with a real variable. The second in-struction 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 named motor controlling the speed of the motor.

The IL instruction setIEC 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 of current programmable controllers. Each instruction is written as an abbreviation 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 com-plete 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

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

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)*)


4.4 Instruction List Chapter 4: Programming languages

44

The C modifier indicates that the corresponding instruction may only be executed 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 opening parenthesis indicates that the evalu-ation of the following instructions must be delayed until the closing parenthesis is encountered.

Fig. 20 The IL instruction set.

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 or equal than

EQ ( Comparison equal

LE ( Comparison less than

LT ( Comparison less or equal than

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


Chapter 4: Programming languages 4.4 Instruction List

3BSE021358R101 (0-

Best system performanceIL is ideal for solving small straight-forward problems. In the hands of an experi-enced 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 performance. During several years a huge amount of software has been written and thoroughly tested. Such software can be modularized into libraries and reused even by pro-grammers without a deeper knowledge of the internal behavior.

Weak software structureSince IL is a low level language, great care should be taken in structuring the code making it easy to understand and maintain. It is very important that IL programs are well documented since conditional jumps otherwise will be very difficult to follow.

The behavior of the result register with only one available value at a time makes it difficult to work with structured data variables. Most compilers have no auto-matic 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 instruc-tion is given correct variable data.

Machine dependent behaviorOf all the five IEC languages IL has been found to be the most controversial. Un-fortunately the semantics, i.e. the way the instructions operate, are not fully de-fined in the standard. For example it is unclear how the result register stores values of different data types. Normally the RR is not intended for storing structured data which means that it is very difficult to get consistent behavior when working with arrays or strings.

Another problem is that the control system behavior for error conditions is not de-fined. This means that different system types may respond with totally different behavior if the programmer uses inappropriate data types. Errors can normally only be detected when the system is running the application.


4.5 Structured Text Chapter 4: Programming languages

46

s, line i.e.

any ctured

ept ts con-

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 developing large control applications there is a need for structured programming tools. ST has proven to be such an effective programming tool, especially in complex applica-tions with a lot of conditional statements and calculations.

StatementsAll ST programs contain a list of statements, each ending with a semicolon sepa-rator. Statements contain expressions which, when evaluated, results in a value to 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 statement, 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, tabfeeds and comments inserted anywhere between operators and operands, where a space is needed for separation.

An expression can be short like a literal constant or very complex involving mother nested operations. The assigned variable can be either simple or strucontaining 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 accany number of spaces in a statement but a good practice is to place statemensequently at a fixed position according to their role in the hierarchy.


Chapter 4: Programming languages 4.5 Structured Text

3BSE021358R101 (0-

Operators in expressionsThe table below summarizes the arithmetic and boolean operators in the IEC stan-dard. The operators are listed in execution order with the highest precedences first:

Conditional statementsOften there is a need to execute some statements repeatedly for a specified num-ber of times or only when a certain condition is fulfilled. The IEC standard pro-vides a collection of conditional statements for this purpose:

FOR statementThe statement FOR is used when the number of execution times 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 ad-dition is repeated until the final value 10 is reached.

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


4.5 Structured Text Chapter 4: Programming languages

48

WHILE statementThe 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 DOpump := FALSE;alarm := TRUE;

END_WHILE;

REPEAT statementThe REPEAT statement is very similar to WHILE but the difference is that the ac-tual statement will always be executed once since the condition is written after the statement.

REPEATB := B + 1;

UNTIL B>10END_REPEAT;

IF statementAn IF statement is used when one or more other statements are to be executed conditionally.

IF A>B THENB := A;

ELSEIF A<B THENA := B;

ELSEA := 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 therefore must include a condition that can be fulfilled.


Chapter 4: Programming languages 4.5 Structured Text

3BSE021358R101 (0-

Calling function blocksST programs often need to access function blocks like timers and counters. Func-tion 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 writ-ten 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 loopingThe ST language has an extensive range of constructs for assigning values to vari-ables, calling function blocks and creating conditional expressions. This is very useful for evaluating complex mathematical algorithms, commonly used in ana-logue 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 should be repeated either a fixed or a conditional number of times.

High threshold for programmersOf 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 and having a higher 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 expressing 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 for describing the step actions in sequences.


4.6 Function Block Diagram Chapter 4: Programming languages

50

4.6 Function Block DiagramFunction Block Diagram (FBD) is a graphic language where the total control function is divided into a number of function blocks or functions connected with 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 ma-chine or even an industrial plant.

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

Syntax for function block diagramsEach 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 cal-culating 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 a 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. Actual 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.

1&

In1

In2

In3

TONIN Q

PT ETTime1

Out1

Out2


Chapter 4: Programming languages 4.6 Function Block Diagram

3BSE021358R101 (0-

lean en the t be- will

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

Standard function blocksThe IEC 61131-3 standard defines a small repertoire of rudimentary standard function block types. These are predefined in most of todays programmable con-trollers. Standard function blocks are often used to construct other more user de-fined function blocks. The most common used blocks are:

• Boolean conditions like AND, OR, XOR and NOT

• Bistables

• Edge detectors

• Timers

• Counters

• PID Controllers

BistablesTwo types of bistables are available, SR and RS. Both of them have two booinputs and one output. The output is set (SR) or reset (RS) as a memory whtriggering input (S1 or R1) momentarily becomes true. When the other inpucomes true the output returns to its initial state. If both inputs are true the SRbe set while the RS will be reset.

AND TONIN Q

PT ET

Function block type

Negation symbol

Input parameters Output parameters



52

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

Edge detectorsThere are two edge detecting function blocks, Rising edge trigger (R_TRIG) and Falling edge trigger (F_TRIG), that are used to detect the changing state of a bool-ean input. The output of the blocks produce a single pulse when a transition edge is detected.

When the input changes state according to the type of edge detector the output is true during one function block execution. After that the output remains false until a new edge is detected.

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

SR

S1 Q1

R

SR bistable

RS

S Q1

R1

RS bistable

S1

R

Q1

R1

S

Q1

R_TRIG

CLK Q1

Rising edge detector

F_TRIG

CLK Q1

CLK

Q

CLK

Q

Falling edge detector



3BSE021358R101 (0-

TimersTimers are among the most used function blocks in a control application. When-ever there is a need for a time delay between a change of state and the correspond-ing action the timer can be used. In most programmable control systems the timing is based upon the CPU system clock, which means that the specified 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 boolean input named IN, a boolean output named Q, an input of type time named PT and an output of type time named ET.

The wanted 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 time 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 linear as long as the pulse output is true. When the pulse terminates, the elapsed time is held until the input changes to false state. Note that the output Q will remain true until the pulse time has elapsed, even if the input changes to false state.

Both delay timers are used for delaying an output action with the specified time PT when a certain condition becomes true.

The on-delay timer delays the activation of an output. When the input IN goes true the elapsed time at output ET starts to increase. If the elapsed time reaches the val-ue specified in PT, the output Q goes true and the elapsed time is held. The output Q remains true until input IN goes false. If input IN is not true longer than the specified delay in PT, the output remains false.

The off-delay timers delays the de-activation of an output. When the input IN goes 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 held. When input IN goes true the output Q follows and the Elapsed time is reset to ze-ro.



54

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

CountersCounters are another commonly used type of function blocks. These are designed to be used in a wide range of applications, for example counting pulses, rotations, completed production batches, etc.

There are three types of counter blocks, up-counters (CTU), down-counters (CTD) and up-down counters (CTUD). The CTU is used to indicate when the counter has reached a specified maximum value. The CTD indicates when the counter reaches zero, on counting down from a specified value. The CTUD can be used to both count up and count down and has two outputs indicating both maximum value and zero.

The CTU has three inputs an two outputs. A CTU-block counts the number of pulses (rising edges) detected at the boolean input CU. The input PV (Preset val-ue) of data type integer defines the maximum value for the counter. Each time a new rising edge occurs on CU the output CV (counter value) of type integer is in-cremented by one. When the counter reaches the specified value in PV, the bool-ean output Q goes true and the counting stops.

If necessary the boolean input R (reset) kan be used to set the output Q to false and to clear CV to zero.

Fig. 27 Example of a CTU-counter block with preset value PV=5.

TPIN Q

Pulse timer

IN

Q

On-delay timer Off-delay timer

PT ET

TONIN Q

PT ET

TOFIN Q

PT ET

ET

IN

Q

ET

IN

Q

ET

PT PT PT PT PTPT

CTUCU Q

Up-counterCU

Q

PV CV

R

bool

bool

int

bool

int

R

CV

CV=PV

CV=0



3BSE021358R101 (0-

The CTD is very similar to CTU with three inputs and two outputs. CTD counts down the number of pulses detected at the boolean input CD. The input PV is used to specify the starting (integer) value for the counter. Each time a new rising edge occurs on CD the output CV is incremented by one. When the counter reaches ze-ro, the output Q goes true and the 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.

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 boolean inputs CU and CD used for counting up and counting down the value in output CV. Similar to the two other counters the integer input PV defines the counters 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 output CV to zero.

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

CTDCD Q

Down-counterCD

Q

PV CV

LD

bool

bool

int

bool

int

LD

CV=0CV

CV=PV

CTUDCU QU

Up-down counterCU

QU

PVCVLD

bool

boolint

bool

intLD

CV

QD boolCDbool

Rbool

CD

QD

RCV=PV CV=PV

CV=0



56

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 diagramsIn many ways a function block can be compared to an integrated circuit (IC), the building block of todays computers and other electronic devices. Like ICs, func-tion blocks can provide standard solutions to common control functions. The con-nection 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 implementFBD is very suitable for describing boolean logic with associated timers, counters and bistables. Most programmable controllers have such function blocks pre-defined 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 analogue control systems, for example PID-controllers, use closed loop control where some output signals are fed back and used also as inputs in the con-trol algorithm. The FBD program gives a good overview over signal flow in sys-tems with feedback.

Not suitable for conditional statementsFBD programs have very week 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 any of the statements FOR, WHILE, REPEAT or IF.


Chapter 4: Programming languages 4.7 Sequential Function Chart

3BSE021358R101 (0-

4.7 Sequential Function ChartSequential Function Chart (SFC) is a very powerful language for describing the structure of a control system. Since SFC is not a full programming language it re-quires instructions taken from the other languages to build a complete application program. Many experienced programmers consider SFC combined with ST-state-ments to be the ultimate method for building structured control applications.

The SFC standard has evolved from Grafcet, a graphical method of describing se-quential behavior. Most European vendors have offered support for Grafcet in their most advanced programmable controllers since the beginning of the 90:es.

One of the most important aspects of SFC is that it gives an overview over all the main states of a control application, all the possible changes of states and also the reasons why those 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 perfor-mance of the programmable controller.

Sequences can also be hierarchical with a main sequence containing several sub-sequences. The result is an application program with a good overview and also more detailed information about the controlled process objects.

Chart structureSFC is a method of dividing the control function into a series of steps drawn with rectangular boxes and connected by vertical lines. Each step represents 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 condi-tion which, when true, deactivates the step before the transition and activates the step after the transition. The execution flow is normally down the page, but SFC also have an option to 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 associated step rect-angle. However in most editors the actions are described as separate program statements (normally i ST language) in other code blocks or an separate editor window associated to the actual step. An important consideration of SFC pro-grams are that only the code in active steps are executed.

All SFC sequences must have an initial step identifying where the program execution starts after system initialization. This step is drawn as a rectangular box


4.7 Sequential Function Chart Chapter 4: Programming languages

58

with double border lines. The initial step remains active until the following tran-sition enables the flow to next step.

Some editors allows the programmer to describe short transition conditions directly on the SFC, close to the corresponding bar. However with more complex 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 lan-guages.

When the sequence has finished all the steps the flow can be terminated by a step with no associated action. If necessary the sequence can also repeat the same be-havior cyclically. The cyclic execution is enabled by a conditional branch back-wards to one of the first steps in the flow. To avoid cluttering the SFC with crossing lines branches are drawn with a starting arrow where the branch begins and a concluding arrow at the step where the branch ends up. In order to clarify the flow the transition name is written on both places.

Fig. 30 Example of a SFC program for an automatic drilling machine. Note the cyclic exe-cution being enabled by the Tr5 transition condition.

Steps and transitionsAll 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 vari-able that is set true while the corresponding step is active. The Step active flag is

Pusch

Drill

Wait

Label

Start

Steps with code i other windows

Transition conditions with code

Tr4

Tr1

Tr2

Tr6

Tr3

Transition

Initial step

Stop

Tr5

in other windows



3BSE021358R101 (0-

con-

when

given the same name as the step plus the suffix X, e. g. Drill.X. It can be used within the actual SFC for controlling the logical flow.

Two adjacent steps must always be separated by a transition condition which pro-duces a boolean result. A transition that always occurs can be expressed by the boolean literal TRUE. The transition conditions may contain any kind or com-plexity of statements, variables and parameters as long as the result is put into a boolean variable.

Action descriptionsSteps 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 pro-gram code for controlling the physical objects. Any of the five 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 actual step with a connection line. To avoid overloading the SFC with to much detailed information the boxes can be folded in or out. Most editors use a separate window or another code block for specifying the actions.

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 qualifier that determines 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 executedtinuously as long as the step is active.

• The P1 (Pulse rising edge) causes the action code to be executed once when the step becomes active.

• The P0 (Pulse falling edge) causes the action code to be executed once the step becomes inactive.

Drill Drill_NN

Drill_Motor := Drill.T;

Drill_P0

Drill_P1

P0

P1



60

loop flow

s Tr2 con-

more ution con-

paths ever

To use one or more of the action qualifiers the programmer writes the code state-ments 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 sequencesIn it’s simplest form an SFC program consist of a series of steps in a closedexecuted continuously. This type of systems (e.g. Fig. 30) only has one mainpath.

In many systems there is a need for two or more alternative branches in thesequence 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 any of the transition conditionor Tr3 become true, the corresponding branch is selected and the executiontinues in that path. Note that only one branch can be executed at any time. Ifthan one transition condition is true the leftmost branch has the highest execpriority. When the last transition in the selected branch becomes true the flowverges back to the main flow.

Fig. 32 Example of a sequence selection with to alternative branches.

We have earlier seen how divergent paths can be used to execute alternatein sequences. An important characteristic of such parallel branches are howthat only one step in one of the branches may be active at any time.

S2

S3 S4

S5

S1

Tr4

Tr1

Tr2

Tr6

Tr3

Tr5



3BSE021358R101 (0-

However in many batch process applications there is also a need for simultaneous sequence structure with several branches. The main sequence is used for describ-ing the primary process control while secondary parallel sequences are used for monitoring that the process is running normally. Such a parallel sequences can e. g. check that plant temperatures and pressures are within required limits. Other-wise the control system may shut down the process.

In the example below all three divergent branches starts with a common transition condition. The execution then continues in parallel and independently on all three paths until a convergence is reached. Both the divergent and the convergent flow in simultaneous sequences are drawn with a pair of lines to distinguish the con-struct from a sequence selection.

The transition condition that succeeds the simultaneous sequence structure will not be tested until all the branches have finished their execution, i. e. when the last step of each branch is active.

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

Sub-sequencesOne 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 rel-

Acid

Water Press

Wait

Start

Tr3

Tr1

Tr2

Tr6

Tr4

Heat

Tr5

Monitor

Temp



62

to a

the

us se-

t can eing

a first sy to

ative small number of main states, each representing a sub-process with a number of minor states.

Some editors provide a method for dividing large SFC programs into a number of sub-sequences, each represented by a general symbol. A sub-sequence may in turn contain other sub-sequences which provides a powerful tool for structuring the overall control function into any number of hierarchical levels. This provides a powerful method for focusing the attention on either the overall behavior of the entire plant or on the detailed operation of the controlled process objects.

A sub-sequence usually contain sequence parts that perform a set of logically re-lated actions. Steps and actions from different hierarchical levels are never visible at the same time. To study the inside of a sub-sequence the programmer has to step into the sub-sequence which changes the SFC view, so that only the contents of the selected sub-sequence is displayed.

Advice on good programming styleAll names for steps, transitions and actions should be unique within the actual 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. De-tailed behavior is better to put within the action blocks or in other SFCs at a lower hierarchical level.

It’s a good practice to reduce interaction between simultaneous sequences minimum.

Never allow step actions from different simultaneous sequences to change same variables.

Avoid using constructs where a divergent path branches out of a simultaneoquence since this may lead to a sequence that never complete or behave unpredictably.

Powerful tool for design and structuringSFC is a very suitable top level design tool in the early phase of a project bualso be used for describing the more detailed behavior of the plant objects bcontrolled.

The SFCs graphical metaphore can be used right from the beginning, to give representation of a systems overall behavior. Since the description is very ea



3BSE021358R101 (0-

follow SFC is a very suitable communications tool between the customer and the programmer.

In the early phases of a project there normally are many aspects of the system be-havior that has not been defined. By using an easy to follow tool for the prelimi-nary 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 specified and refined as new information becomes available. Actions associated to overall steps can then be described via other nested SFC schemes.

SFCs good continuity from the initial phase to the refining design phases makes it very popular among system designers and programmers.

Other programming languages are neededEven though SFC has a lot of 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 some of the other four IEC program-ming 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 lan-guage for detailed description in SFC schemes. Some controllers also allow pro-gramming with FBD or IL.

Even though 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 execution than with the other pro-gramming languages.


4.8 Function blocks Chapter 4: Programming languages

64

4.8 Function blocksAll IEC 61131-3 software applications can be broken down into functional elements named program organisation units (POUs). A POU may contain func-tions, function blocks or entire programs.

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 easy be re-used 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 elec-tronic hardware enormously. Function blocks can provide a similar off-the-shelf solution to common control problems.

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

Application

Program Program

Function block

Function

Function block

Function

Function block

Function

Function block

Function block

CTUCU Q

Up-counter

PV CV

R

74LS163

IC with counter


Chapter 4: Programming languages 4.8 Function blocks

3BSE021358R101 (0-

ses ing alled

re- first

and

d if ex-

a a is en ev-

tion d al-

block func-

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 de-scribes both the behavior of data and the data structure.

The use of function blocks encourages well structured design which in return will speed up the program development considerably. This is especially true in large plants containing a lot of similar control functions which means that function blocks can be re-used 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. But other features from object oriented languages like inheritance is not ful-ly supported with function blocks.

Don’t mess up function blocks with the programming language FBD which ua number of predefined function blocks. A function block may be defined usany one of the five programming languages. Function blocks may also be cupon from all the five programming languages.

Definition and instancesOne of the main reasons for programming with function blocks is the ability touse parts of the application software several times. This is accomplished byestablishing a function block definition and then creating one or many instances of that definition.

The definition for a function block contains two parts:

• A specification of the data structure for input parameters, internal variablesoutput parameters.

• An algorithm calculating output parameters using the input parameters annecessary local variables for intermediate storage. The algorithm may bepressed in any one of the five IEC 61131-3 programming languages.

A function block instance is a unique set of data values handled together asstructure based upon the common rules in the definition algorithm. This datneeded since the function block instance has to remember it’s values betweery call in the application program.

The instance only contains data that are unique to the particular set of funcblock. This means that although a function block may use a very complicategorithm the memory requirements to store the data for each instances of a may be very modest. An application program based on several instances of



66

tion blocks therefore require less memory than programs containing duplicates of code.

Each instance of a function block is given a unique instance name for identifica-tion purpose. The instance name is shown above the function block symbol.

Fig. 36 Function block definition and instances. The same algorithm is used several times to calculate the unique sets of data in each instance.

User defined function blocksIn order to fully utilize the potential of function blocks the programmers should develop their own function block types for all program parts that can be re-used. Most of todays programmable controller editors allows 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 tool for writing the algo-rithm. Many user defined function blocks are also built by combining the 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 definition name, has its own variables and parameters and a characteristic algorithm describing the tasks it per-forms. 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 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 advantages to construct well proven function blocks that can be used for solving a wide range of control problems.

Type definitionVariable declarations

Algorithm

Converter

Converter1

Converter2

Converter3

Instances



3BSE021358R101 (0-

am-unc-

e to

On the other hand, care should be taken not to build so many features and varia-tions 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 blocksMost 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 used functions are mathemat-ical like 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 pareters. Any number of parameters of any type may be used in a function. A ftion always results in the same value for the same input values.

When using a predefined or custom function block the definition always havbe instantiated and given a unique instance name. Function blocks communicatevia input and output parameters. Each instance of a function block results in a unique set of parameters.



68

d the les in

e val-it’s

s re-tput ion

ce of ally

tion l

in-e ac-

A function block can’t be used in expressions, it has to be called. When calleprogrammer has to connect both input and output parameters to local variabthe actual POU. Contrary to functions a function block can create different output parameters even though the input parameters have the samues. For example this is the case for a counter which counts up every time called and remembers it’s values until next count up.

Advant Control Builder has an increased functionality concerning functions agards to standard IEC 61131-3. Here a function can have both input and ouparameters. If a function has output parameters it must be used like a functblock.

How to use function blocks in control programsBefore a function block can be used the programmer has to create an instanit and give this instance a unique name. In the programming editor this is normdone via the window being used for declaring variables.

To create an instance means almost the same as making a copy of the funcblock definitions data. The programmable controller then reserves individuamemory space for the variables and parameters in the function block.

To call a function block with the ST language you first write the name of thestance followed by a parenthesis. Within this parenthesis you have to fill in thtual local variables that connects to the parameters in the function block.

Fig. 38 An instance of the function block from Fig. 37connected to local variables in a ST-program.



3BSE021358R101 (0-

T or e

an-

With the IL programming language you have to call a function block by using the instruction CAL followed by the instance name. The actual local variables are specified in a similar way as with ST described above.

When an instance of a function block is used with the FBD language the editor presents the instance as a graphical symbol. The programmer only has to connect the input and output parameters to actual local variables.

Interaction between languagesAll the five IEC programming languages have there pros and cons and no one of them is suitable for all control tasks. Programmable controllers that are IEC com-pliant allows the programmer to choose the most suitable language for each task.

One of the main objectives with the IEC standard is to encourage well structured program development by breaking down the total function into a number of pro-gram 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 any of the other languages. Experienced programmers often prefer the ST programming language since it gives a compact description and has several tools for conditional execution an powerful mathematical func-tions. FBD is another alternative giving a very good overview over logical condi-tions but this language unfortunately also have limited power for conditional execution.

Programmers with previous experience of LD or IL languages may of course use their favorite language even though they don’t provide the same power as SFBD. Application programs from older control systems may relatively easy btransferred to IEC compliant programmable controllers by using these two lguages.



70


71 Development version 3BSE021358R101 (0-2)


72


73 Development version 3BSE021358R101 (0-2)


74

Chapter 5: Object-oriented programs 5.1 New life for an old method

3BSE021358R101 (0-

Chapter 5

Object-oriented programs

The IEC 61131-3 standard for programmable controllers is not the only effort to-wards better program quality, standardization and the re-use of old programs in new projects. In the last decade a lot of program projects have been realized with a technique named object-oriented programming. In his section that technique will be compared to the IEC standard for programmable controllers.

Examples of object oriented programming languages include Simula, Smalltalk and C++, which is a development of the language C. Other successful examples using object oriented techniques are the operating systems for the Macintosh and Windows, both of which have an extensive standardization of man/machine com-munication.

Compared with programs which 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 quality of the software.

5.1 New life for an old methodThinking 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 natural way of describing problems. One thought-provoking consequence of this is that beginners often learn to program using object-orientation more quickly that expe-rienced programmers, who are hindered by their own habitual way of thinking.

In order to explain the principles of object orientation and some of the basic con-cepts, 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 en-ergy 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 vary somewhat ac-cording 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 materials cannot enter it, and the second is to


5.2 Objects in the plant Chapter 5: Object-oriented programs

76

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.

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 and thereby affect 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 separated from surrounding cells. In order to coordinate with other cells it is sufficient to send chemical mes-sages. 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 for their internal structure and function. The class of cell, however, allows several sub-classes with different variations. Examples of these are plant cells with hard membranes, blood cells which are mobile and specialized for the transport of gas-es, and muscle cells which can alter their shape and carry out work. Every sub-class occurs in a large number of individual instances which have almost identical characteristics.

5.2 Objects in the plantA necessary condition 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 sub-

Object

Message

Methods

Variables


Chapter 5: Object-oriented programs 5.2 Objects in the plant

3BSE021358R101 (0-

functions comprising a number of objects. Every object is then programmed with its own program object which in the IEE 61131-3 standard is named 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 process industries where raw materials are processed, it is by no means quite clear where the boundaries should be drawn between objects.

The aim of drawing boundaries is partly to achieve a simple functional descrip-tion, and partly to minimize the total requirement for communication between ob-jects. 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 de-signed 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 pro-grams to new tasks.

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 re-used. The main part of the programming time would then be taken up in combining and connecting together well-proven program objects to produce fin-

Object A Object B

Object C

Object 1 Object 2

Object 3 Object 4

Object 5


5.3 Re-use of code Chapter 5: Object-oriented programs

78

while

cre-

ws, d out

ished 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 suitable objects which can be connected together and thereby simulate the real-life func-tioning of the installation. In order for it to be possible to use program objects efficiently, they must be well documented particularly regarding their in-terface 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 number of well-proven standard components. Some of these components may have rela-tively complex functions, such as the electronic fuel injection system. Given that their interface with the outside world is carefully specified, complex components of this type can be used without having to have a knowledge of their internal func-tioning.

5.3 Re-use of codeMany programmers strives to design program objects which exactly imitate the real-life process objects and which contain the same control functions. Most in-stallations contain a large number of more or less similar variants of process ob-jects. 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 func-tion blocks which can be reused with minimal adaptation work.

In general object-oriented systems program objects can be 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 objectsthe 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 with defining the function block and thenates the required number of instances (copies of data sets).

5.4 LibrariesNowadays there are hardly any companies that manufacture their own screnuts or similar components. The production of standard components is carrie


Chapter 5: Object-oriented programs 5.4 Libraries

3BSE021358R101 (0-

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 develop-ment 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 ob-jects is then produced by people with long experience which results in high qual-ity. Examples of objects of this type are PID controllers, alarm functions, communication units, etc. It is important to document accurately the interaction of the objects with their surroundings, so that it becomes 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 generators, PID controllers, limiters, etc. The standard modules are produced by people with many years of experience of applications in the process industry. This guarantees high quality in terms of their function.

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 standard function blocks can also be combined into user defined function blocks.

Fig. 41 The standard function block library supplied with Advant Control Builder.


5.4 Libraries Chapter 5: Object-oriented programs

80

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 limita-tions, which can take a considerable time for complex systems.


Chapter 6: Control system glossary

3BSE021358R101 (0-

own-

. ing

ma-

Chapter 6

Control system glossary

A

adaptive controlControl system where the controller parameters are automatically adjusted to the process’ properties.

algorithmA collection of rules which describe, step by step, how a problem is to besolved.

analogue signalA continuously variable signal which represents a physical quantity, e.g. temperature, flow or pressure.

applicationThe application contains a number of instructions that are compiled and dloaded for execution in the controller.

ASCIIAn abbreviation for American Standard Code for Information InterchangeASCII is the most used code for character representation in data processsystems.

assembler instructionsA low level programming language using letter codes for representing thechine code instructions.

B

BaudA unit used to specify the data transmission rate between two devices. One baud is equal to one bit per second.

BooleanA variable that can only hold logical values such as True and False or 1 and 0.



82

d in ad of

the

bottom-upA method for structuring application programs where the individual program objects are developed without consideration about the program struc-ture above them.

busA system of parallel circuit lines for connecting the different units in a computer system or a programmable controller.

C

compilerAn application program that translates the control application to low level ma-chine language that can be executed in a computer or programmable controller.

CPUThe Central Processing Unit in a computer or programmable controller is the “brain” that coordinates all activities and carries out all operations specifiethe application program. In PLCs the name Central unit is often used insteCPU.

cycle timeAll application programs in programmable controllers are executed repeatedly with a specified time interval.

D

digital signalA signal with only two possible states, named high and low, on and off or 1 and 0.

distributed systemsA control system with several computers or programmable controllers communicating with each other via a local network.

downloadA common name for the transfer of a compiled application program from engineering tool to the programmable controller.



3BSE021358R101 (0-

E

editorApplication program that is used for writing and editing text or instructions

executionWhen a computer is running the instructions are executed one at a time.

F

falling edgeThe change from 1 to 0 of a Boolean variable.

feedbackA signal from the controlled process may be fed back to the controller where it is used in the control algorithm.

fieldbusA communication bus used for digital information interchange between sen-sors, actuators and programmable controllers.

full duplexA transmission method where data can be both transmitted and received simultaneously.

G

gatewayA communication unit for connecting different types of networks. It translates between different communication protocols.

global variableA variable that can be accessed in all programs.

H

half duplexA transmission method where data can only be transmitted in one direction at a time.

hardwareA common name for all the equipment in a computer system.



84

hexadecimalA system of numbers with a base of 16. The numbers 0 - 9 are not changed while 10 - 15 are represented by the letters A - F.

high-level languageA programming language similar to ordinary written text where each instruc-tion or statement results in several machine code instructions. Pascal, C and Java are some of the most used languages today.

I

I/O moduleMany programmable controllers use expandable I/O units making it possible to add more input or output signals via extra modules.

I/O signalThe physical inputs or outputs in the I/O module.

identifierA combination of letters, numbers and other characters which are used to give names to variables, parameters, modules and other language objects.

initializationEstablishing basic conditions when a system starts up.

instructionA programming language element that specifies an operation and the values or location of its operands.

integrated circuitElectronic functional unit containing a large number of semiconductors which have been compressed to a small silicon chip.

L

LANAbbreviation for Local Area Network. A LAN is used to enable high speed communication between several computers and programmable controllers in a plant.

local variableA variable that can only be accessed in the program where it is defined.



3BSE021358R101 (0-

low level languageA programming language with letter codes where each instruction results in one machine code instruction. Assembler is a typical low level language.

LSBAn abbreviation for Least Significant Bit, i.e. the bit in a binary number with the lowest value.

M

machine codeWhen a computer executes a program it must be available in machine code lan-guage which is a low level language with binary or hexadecimal codes.

MMSAn 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 (Manufacturing Automa-tion Protocol), a specification for open communication based on the OSI mod-el.

MSBAn abbreviation for Most Significant Bit, i.e. the bit in a binary number with the highest value.

O

object codeCommon name for the resulting code produced when the compiler has translat-ed an application program to executable machine language.

octalA system of numbers with a base of 8. The decimal digits 8 and 9 are not used in this system.

off-lineA computer (with editor and compiler) that is not connected to the controller is considered to be off-line. This is the normal situation for editing the source code.



86

dif-

ial r the

ns type.

on-lineA computer (with editor and compiler) is considered to be on-line when it is connected to the controller where the program is executed. This is the normal situation with the plant application executing and the process status being displayed in the editor.

P

PLCAn abbreviation for Programmable Logic Controller which is the most common used type of control system in today’s industry.

POUAn abbreviation for program Organisation Unit. The IEC-standard describes programs, function blocks and functions as POUs.

protocolA set of rules which determines the procedure for communication betweenferent I/O units, computers or controllers.

R

RASAbbreviation for Remote Access Service. With RAS a remote client can dup a gateway machine resident on a LAN and establish a connection ovetelephone line.

real-time systemA system where changes in the input signals will result in immediate actioon the corresponding output signals. Almost all control systems are of this

rising edgeThe change from 0 to 1 of a Boolean variable.

RS232CInternational standard for serial data transmission with the signal levels -12V and +12V. Is mainly used over relatively short distances.

S

sampling



3BSE021358R101 (0-

sur-the en-ple

be etc.

the ble

ruc-

and

Computer based control systems can’t communicate continuously with therounding transducers and actuators. Instead the control system samples vironment (collects and transmits values) periodically with a specified samtime.

SattBusA fairly fast (62,5 kbit/s) fieldbus with token bus protocol. It is intended to used for short messages to field devices such as transducers, actuators,

simulationMany computer based engineering tools provide a function for simulatingcontrol function in the computer without downloading it to the programmacontroller.

source codePrograms written in high level languages are often called source code before they are compiled to object code.

TTCP/IP

An abbreviation for Transmission Control Protocol/Internet Protocol. TCP/IP is used both on the Internet and on many Local Area Networks.

top-downA method of breaking down the entire control function into a hierarchical stture of sub-processes.

W

workstationA common name for a computer with associated software used for editingcompiling control programs.



88

3BSE021358R101 (0-

Index

Numerics3964R 19

Aabstract classes 74access variable 36accumulator 43action 57action description 59action qualifier 59actuator 6Advant Control Builder 17assembler 12assembly language 42

BBasic 14batch process 60Boolean data 35bottom-up 28

CC 14, 46C++ 71central unit 15class 72COMLI 19comment 34, 42common elements 33communication protocol 19compatibility 23compiler 13, 17compliance class 29conditional statement 47constant 35contact 37controller 5cross-assembler 12cycle time 18, 27

DData Highway Plus 19data structure 27date 35DCS 24debugging program 12definition 65, 72distributed system 19

divergent path 60download 17Duration 35

Eedge 52editor 12, 17elementary data type 34encapsulated data 39, 65engineering station 15, 17event 27execute 12, 18expression 46

Ffeedback loop 37function 67function block 28, 50, 64, 67

Gglobal variable 36Grafcet 57

Hhigh-level language 13

II/O unit 15, 16IC 6, 64identifier 33IL register 43inheritance 65, 74initial step 58initial value 36instance 49, 65, 72, 74instance name 67instruction 12, 42instruction list 17integrated circuit 56interpreter 13

Llabel 42ladder diagram 16libraries 8local area network 7

local variable 36low level language 13

Mmachine code 12, 17Macintosh 71main state 62MAP 25memory 8, 15memory bit 38message 72methods 65, 72minor state 62MIS 25mnemonic 43

Oobject 72object code 14object-oriented programming

71object-oriented systems 8off-line 17on-line 18operand 42, 46operator 42, 46operator modifier 43optical isolator 16

Pparameter 50, 65, 67, 72Pascal 14, 46PID 9PLCopen 29POU 27, 36, 64, 73power rails 37process computer 7Process Value 9Profibus 19Programmable Controller 7,

15Programmable Logic Control-

ler 7, 15protocol 24

Rreal-time system 18relay coil 9, 37remote I/O 19


Index

90

result register 43retain 36

SSCADA 7, 24semantics 45sensor 39sequence 8, 40sequence selection 60Setpoint 9shareware 22Simula 71simulate 17simultaneous sequence 61Smalltalk 71Soft PLC 19source code 14standard libraries 56, 75state 40statement 46step 57structured data type 34sub-class 72sub-process 8subroutine 39sub-sequence 62syntax 12syntax checking 17

Ttask 19Time of day 35top-down 28, 62transducer 5transition 57transition condition 57

Vvariable 72

WWindows 71


3BSE021358R1010009

Specifications subject to change without notice.Printed in Sweden. © 1999 ABB Automation Products AB.

ABB - IEC61131

Documents

advant control

local area

plcopen trade

calling function

rising edge

weak software

sequential

entire control