Abb - Iec61131

ControlIT
ICE 61131 Control Languages

Introduction
Development version
Control IT IEC 61131 Control Languages

Introduction
Copyright 1999 ABB Automation Products AB. The contents of this document can be changed by ABB Automation Products AB without prior notice and do not constitute any binding undertakings from ABB Automation Products AB. ABB Automation Products AB is not responsible under any circumstances for direct, indirect, unexpected damage or consequent damage that is caused by this document. All rights reserved. Release: 0009 Document version: 0-2 Document 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.
Development version
3BSE021358R101 (0-2)
Development version
3BSE021358R101 (0-2)
Contents
1 Evolution of control systems
1.1 1.2 1.3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequencing subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Closed loop control subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relay logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computers for process control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programming methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programmable controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I/O units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programming methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computer based programming tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cyclic execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distributed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Soft PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programming dialects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Portable software applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Re-usable software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication with other systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benefits offered by the standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Well structured software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Five languages for different needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software exchange between different systems . . . . . . . . . . . . . . . . . . . . . . PLCopen trade association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5 6 8 8 8 9 9 11 12 15 16 16 17 18 19 19
1.4 1.5 1.6
Why open systems are needed

2.1 2.2 2.3 2.4 2.5 2.6
21
21 21 22 23 24 24
The IEC 61131-3 standard

3.1 3.2
27
27 28 28 28 29 29
3.3
3BSE021358R101 (0-2)
Development version
Contents
Programming languages
4.1 4.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constant literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ladder Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Easy to understand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weak software structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limited support for sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Difficult to re-use code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instruction List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IL language structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The IL instruction set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Best system performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weak software structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Machine dependent behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structured Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operators in expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conditional statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calling function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suitable for complex calculations and looping . . . . . . . . . . . . . . . . . . . . . High threshold for programmers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Function Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax for function block diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Similar to electrical diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boolean functions and feedback are easy to implement . . . . . . . . . . . . . . Not suitable for conditional statements . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequential Function Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chart structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steps and transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Action descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequence selection and simultaneous sequences . . . . . . . . . . . . . . . . . . . . Sub-sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advice on good programming style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Powerful tool for design and structuring . . . . . . . . . . . . . . . . . . . . . . . . . . Other programming languages are needed . . . . . . . . . . . . . . . . . . . . . . . . .
31
31 33 33 34 35 36 37 38 39 40 41 42 42 43 45 45 45 46 46 47 47 49 49 49 50 50 51 56 56 56 57 57 59 59 60 62 62 63 63
4.3
4.4
4.5
4.6
4.7
Development version
3BSE021358R101 (0-2)
Contents
4.8
Function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition and instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User defined function blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Differences between functions and function blocks . . . . . . . . . . . . . . . . . . How to use function blocks in control programs . . . . . . . . . . . . . . . . . . . . Interaction between languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . New life for an old method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objects in the plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Re-use of code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A ......................................................... B ......................................................... C ......................................................... D ......................................................... E ......................................................... F ......................................................... G ......................................................... H ......................................................... I .......................................................... L ......................................................... M ......................................................... O ......................................................... P ......................................................... R ......................................................... S ......................................................... T ......................................................... W.........................................................
64 65 66 67 68 69
Object-oriented programs
5.1 5.2 5.3 5.4
71
71 73 74 75
Control system glossary
77
77 77 78 78 79 79 79 79 80 80 81 81 82 82 83 83 83
Index
85
3BSE021358R101 (0-2)
Development version
Contents
Development version
3BSE021358R101 (0-2)
Chapter 1: Evolution of Control Systems
1.1 Introduction
Chapter 1
Evolution of Control Systems

1.1 Introduction
Almost all industrial plants need some kind of controller to ensure safe and economical operation. At the simplest level, the plant may consist of an electric motor driving a cooling fan for controlling the temperature in a room. At the other extreme, 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 controller and the actuators.
Transducers Actuators
Plant
Inputs
Controller
Outputs
Parameters
Status
Fig. 1 Overview of the components in an industrial control system.
The controller monitors the actual status of the plant processes through a 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 measure conditions which have a continuous range, such as temperature, pressure, flow or liquid level.
3BSE021358R101 (0-2)
Development version
1.2 History
Based on the status of the inputs the controller uses a built in or programmed algorithm to calculate the status of the outputs. The electrical signals from outputs are converted to process behavior via the actuators. Most actuators create movement 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
History
The 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 sophisticated 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 todays industry relay logic is seldom chosen for developing new control systems but a large number of older systems are still in use. The silicon based Integrated Circuit, IC, paved the way for a new generation of control systems in the 1970s. Compared to relays, ICs based on TTL or CMOS integrated 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 permanently defined by the electrical wiring. Systems with wired logic are easy to implement but unfortunately it is difficult and time consuming to alter their behavior. In the early 1970s the first commercial computers debuted as controllers in large control systems. Since the computer can be programmed it offers a great advantage compared to the wired logic function in systems based on relays or ICs. Early computer systems were large, expensive, difficult to program and unfortunately also very sensitive to the rough environment in many industrial plants. As a result of demands from the American car industry the Programmable Logic Controller (PLC) was developed in the early 1970s. The PLC is a computer designed to work in an industrial environment. The transducers and
Development version
3BSE021358R101 (0-2)
1.2 History
actuators from the outside world are connected via robust interface cards. Compared 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 todays industrial plants there often is a need to handle both digital control and closed loop analogue control with the same control system. These systems are often called Programmable Controllers since their operation is not limited to only logical conditions. Today the overall control function in a plant often is distributed to a number of local programmable controllers which are positioned in the immediate neighborhood of the objects which are to be controlled. The different controllers are usually connected together into a local area network (LAN) with a central supervising process computer which administers alarms, recipes and operations reports.
1880 Mechanics Relays ICs Computers PLCs Process computers 1920 1970 1980 1990 2000
Fig. 2 The evolution of control systems since the end of the 19th century.
The operator plays a very important role in todays industry and many plant installations therefore have a computer based Supervisory Control and Data Acquisition System (SCADA). SCADA systems have high-resolution color monitors on which the operator can select different application programs and study the actual status of the manufacturing process. It is characteristic of todays industry that the demand for profitability is increasing, while at the same time there is a more frequent need to carry out changes in the control function. Because the cost of computer equipment had
3BSE021358R101 (0-2)
Development version
1.3 Control applications
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 programmed via standardized program objects stored in program libraries. Such objects are well proven and have a standardized user interface.
1.3
Control applications
It is easy to be overwhelmed by the complexity of an industrial plant process. However most processes can be simplified by dividing them into a number of small sub-processes. Such sub-processes can normally be divided into three different categories. Monitoring subsystems, sequencing subsystems and closed loop control subsystems will be further described in the three following sections.
Monitoring subsystems
A 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 displayed 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 subsystems
The 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 malfunction in a transducer since this will cause the sequence to freeze.
Development version
3BSE021358R101 (0-2)
1.4 Relay logic
Closed loop control subsystems

Many sub-processes have analogue variables such as temperature, flow or pressure 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.
Desired value SP PV Actual value Transducer Error SP-PV Control algorithm Actuator Process Controlled variable
Fig. 3 A closed loop control system.
1.4
Relay logic
The electromagnetic relay has been one of the most important components in the evolution of control systems. Relay logic systems contain a number of relays that are activated by 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.
3BSE021358R101 (0-2)
Development version
1.4 Relay logic
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.
Logical AND
Logical OR
Memory
Fig. 4 Three often used logical conditions implemented with relay logic.
A relay based control system may contain any number, from a dozen 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 its time consuming to do the electrical wiring, the total cost of a relay based control system depends mainly on the number of relays used. In large plants the limited number of contacts on both transducers and relays sometimes will cause engineering problems. Experience shows that it is easy to develop small relay systems with a limited number of relays but with increasing complexity the work will demand a very experienced engineer.
10
Development version
3BSE021358R101 (0-2)
1.5 Computers for process control
A characteristic quality of relay based control systems is the decentralization of the logic function into a large number of discrete relays. Since relays are electromagnetic components they have a limited life 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 computers and programmable controllers cant be used.
1.5
Computers for process control
The first computers, that were developed during the 1950s, were very large and expensive machines. Such systems were mainly used for administrative tasks like payroll, 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 many control systems were developed using microprocessors as controllers. The most important advantage with computers, compared to wired logic, is that the programmed control function easily can be altered. Computers are also very suitable for performing arithmetic calculations and for storing huge amounts of data. A standard computer however is not equipped for communicating with industrial equipment. Another disadvantage is the high learning threshold for developing computer programs. Early computer based control systems needed extra interface equipment in order to handle the real world transducer and actuator signals. These interfaces normally had to be individually developed for each plant. Since then several vendors have developed standard interface modules for both digital and analogue process signals.
3BSE021358R101 (0-2)
Development version
11
Programming methods
All computer programs consist of a number of instructions which tell the computer what it is to do when the program is run, or executed as programmers prefer to call it. Because computers process binary information, the computers instructions are very different from our own verbal ways of describing those actions we want it to take. In programming, therefore, various aids are used to process and translate our verbal function description into the computers own language. These aids are ready-made computer programs which can be purchased relatively cheaply.
Machine code and assembler
Most computers have a limited set of instructions which carry out simple operations such as fetching data, storing data, adding numbers, etc. By combining a large number of such machine codes into long programs, the programmer can get the computer to carry out very complex functions. In order for the program to work, however, it is very important to follow the rules on how instructions should be used and combined, often called the syntax of the program. Because machine codes are binary or hexadecimal numbers, the job of programming is made easier by using what are known as assembler instructions. Each of these instructions has a three-letter name (memo-code), such as LDA for fetching data and ADD for adding two numbers. A ready-made program known as an editor is normally used when writing assembler instructions into the computer. An editor program has basic word processing functions for entering and correcting of text. Before the assembler program can be executed, the memo-codes must first be translated into hexadecimal machine code. The translation to machine code is done by another program called an assembler. Assembler programs of this kind can be bought for most types of computers. Apart from the actual translation, the assembler program can also help in syntax checking and in calculating logical jumps within a program. The assembly is normally carried out on the same type of computer as will then be used in its execution, but there are also assembler programs, known as cross-assemblers, which can be run on other types of computers. Test running of assembler programs is made easier by special programs that allow part of the program to be executed step by step. Using these so-called debugging programs, it is also possible to simulate real-life signals so that their function can be tested without having to connect it up to the actual process.
12
Development version
3BSE021358R101 (0-2)
Start
Editing using editor LDA IN1 L1 Test-running using debugger SUB C CMP B BNE L1 ADD D Functioning properly? Yes Stop No STO OUT1 Assembler
Assembling
F6 0A A9 23 12 E3 F8 76 06 A3 45 D3 A2
Fig. 5 In low-level programming several supporting programs are used, such as editor, assembler and debugger, in order to translate the program into machine code.
Programming using assembler instructions has both advantages and disadvantages. 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 computers repertoire. The finished program is entirely matched to one particular type of computer and cannot be transported to another computer type. On the other hand, a properly written assembler program gives good performance and the optimal usage of the computers memory. This is important in, for example, industrial robots and where systems are to be produced in very large series. Work using assembler is often called low level language because the instructions are similar to the computers own way of working.
Compiling and interpreting
The work of programming is made considerably easier if the program is written in what is known as a high-level language, which is translated into machine code by a program-based compiler or interpreter.
3BSE021358R101 (0-2)
Development version
13
The difference between compilers and interpreters is that the compiler first translates 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 standardized, and the main parts of the programs can be written so that they are independent of the type of computer on which they will be run. The actual matching to the computer is done by the compiler or interpreter in the process of converting it to machine code. Programs that are written in a high-level languages are often known as source code, while the compiled result is called object code.
Source code in Pascal
02 0C A7 43 37 E3 F8 86 16 A2 45 A2 05 A3 12 7B
Profit := Income - Cost IF Profit>20 THEN PRINT "Profitable" ELSE PRINT "Loss" END Compiler
Fig. 6 Programs written in a high-level language are totally machineindependent and are translated to computer-specific machine code by a compiler program.
The programmer writing in a high-level language does not need to know the technical details of the design of the computer or its memory. Another 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 directly in assembler (machine code). This also means that the performance of the computer is used less efficiently.
14
Development version
3BSE021358R101 (0-2)
1.6 Programmable controllers
1.6
Programmable controllers
Answering 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 to entire manufacturing lines in large process industries. Independent of brand and type most PLCs contain three functional parts; the central unit, the memory and the I/O unit, all communicating via a bus unit. The central unit coordinates all activities in the PLC and executes the control program in the memory. The actual process status is monitored and sampled via the I/O unit. Apart from logical instructions an increasing number of todays PLCs also have arithmetic functionality. Many vendors therefore are using the term Programmable Controller instead of PLC. Programming of PLCs is normally carried out on an external computer based engineering station. The compiled program is downloaded to the central unit and further into the program memory via serial channel or via a LAN. Some PLCs have an option for using the engineering station for online process status presentation, while the control program is executing.
PLC Engineering station
Memory
Central unit
Bus unit
I/O unit Input modules Output modules
Transducers
Actuators
Fig. 7 The components of a programmable controller system.
3BSE021358R101 (0-2)
Development version
15
I/O units
A characteristic quality of the programmable controller is that it is designed to live in and interact with an industrial environment. Most controllers have a modularized Input/Output unit (I/O) for direct connection of the transducer and actuator signals. The purpose of the I/O unit is to convert the process signals to the lower signal level used in the controller and also to suppress electrical transients from the plant equipment. This is often achieved by optical isolators containing a light-emitting diode and photoelectric transistor linked together in a package. Since there are several different signal levels in a typical plant many I/O units allow the use of exchangeable I/O modules. Such an I/O unit can easily be customized to the specific signal levels of the actual plant. The most used I/O modules are digital DC inputs and outputs with the signal levels 24 V or 48 V. Many vendors also offer modules with AC 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 analogue transducers represent their physical value as a current within the range 4-20 mA, with 4 mA indicating the minimal value.
Programming methods
The first PLCs used a programming language based on relay ladder diagrams. The program was entered via a programming terminal with keys showing contact symbols (normally open/normally closed), relay coils and parallel branches with which a maintenance electrician would be familiar. The programming terminal compiled the ladder diagram into machine 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 persons with previous knowledge of relay based control systems. Therefore this method from the start was preferred by the American PLC vendors.
16
Development version
3BSE021358R101 (0-2)
In large plants and when people without previous knowledge of relay logic are to develop the control program, Boolean instruction lists are often preferred. Most European PLC vendors have chosen this as the standard programming method in their systems.
001 012 003 201
020
A 001 A 012 ON 020 RP A 003 = 201
Fig. 8 Examples of PLC programs using ladder diagram and instruction list.
Computer based programming tools

Early PLCs were programmed with dedicated terminals only usable for that purpose and together with specific systems from one vendor. Today almost all programmable controllers are programmed with standard personal computers (PCs) running a dedicated development software tool. Advant Control Builder from ABB is an example of such a software tool intended for use with some of the programmable controllers from ABB. A complete system with computer and development software is often referred to as an engineering station. Most development tools contain several different, but often integrated, 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 program 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. Simulation makes it possible for the programmer to test the application by manually altering the actual input signals.
3BSE021358R101 (0-2)
Development version
17
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 execution
Industrial control systems are real-time systems, which means that changes in the input signal require immediate action on the corresponding output signals. An example may be a machine where some movement has to be stopped when a particular 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 consequences of a delayed reaction therefore become unacceptable. In order to fulfil the demands on a real-time system, the application program must have constant access to current input data from the process. To achieve this the compiled program is executed cyclically at a specific frequency. Changes in the incoming signals 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.
Read inputs
Execute program
Cycle time 1 - 50 ms
Update outputs
Fig. 9 A typical program scan in a programmable controller.
18
Development version
3BSE021358R101 (0-2)
Because different sub-processes may have variable time demands, some programmable controllers provides a function for dividing the total program into different tasks, each with its own cycle time.
Distributed systems
In 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 accounts 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 proprietary protocols during the 1990s and some of these like COMLI from ABB, 3964R from Siemens, Data Highway Plus from Allen Bradley and the vendor independent Profibus have slowly emerged into de facto standards supported by more than one PLC vendor.
Soft PLC
One problem with PLCs is that all vendors use their own proprietary controller hardware with an associated programming language. In spite of the basic functions 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 establish their Soft PLC software as an industry standard. This means that control applications developed with one Soft PLC application cant be transferred to another vendors Soft PLC.
3BSE021358R101 (0-2)
Development version
19
20
Development version
3BSE021358R101 (0-2)
Chapter 2: Why open systems are needed
2.1 Programming dialects
Chapter 2
Why open systems are needed

2.1 Programming dialects
The programmable controller is one of 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 programming dialects. Many customers using programmable controllers have, in order 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 quality
As more and more jobs in manufacturing and process industries become automated, 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 processed 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.
3BSE021358R101 (0-2) Development version 21
2.3 Software cost
The vast majority of all control code is written with the proprietary software packages delivered by the control system vendors. Many of these packages have very poor facilities for working with modules, for code 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 cost
In 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 dramatically. 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. Todays personal computers have equally good, or even better, performance than yesterdays mainframe computers. With the increasingly good relationship between hardware performance and price, the total cost of an installation is more and more determined by the time for program development. In most projects, therefore, greater weight is attached to standardization and reuse of programs than with finding the optimal hardware.
22
Development version
3BSE021358R101 (0-2)
2.4 Portable software applications
100 90 80 70 60 50 40 30 20 10 0 1960s 1970s 1980s 1990s 2000s Cost of program development Cost of hardware
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 applications
The personal computer together with the Windows operating system is today a well established de facto standard for information handling in almost all offices in the world. The main reason for the PCs enormous penetration is software compatibility. Application programs developed for Windows can be used on almost all PCs around the world. More than 25 years after the introduction of the first programmable 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 developing 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.
2.5 Re-usable software
2.5
Re-usable software
Not so long ago many real programmers measured their effectiveness by the amount of program code produced per day. Real programmers dont like to waste their time on structuring and detailed specification. Instead they move directly from a rough specification, often made by the customer, to coding in their favorite language, often Ladder Diagram or Instruction List. Today even real programmers realize that the first face in a project when the overall function is analyzed, structured and designed is the key to a successful and cost effective application program. The traditional method of reducing software cost is to re-use common parts of the program code in several similar applications. Unfortunately this is difficult to achieve in industrial automation since most processes are very different in behavior. Another obstacle to software re-use is that the program code most often is strongly affected by the personal programmer style. When the final application is the result of a team work there often are visible seams between the different parts coded by different programmers. The only way to reduce the risk of seams is to encourage (read force) all the members in the team to follow certain rules and formalism for producing code.
2.6
Communication with other systems
The first programmable controllers presented in the seventies were often placed in an electrical equipment cabinet close to the machine or process being controlled. These controllers normally had no means for interaction with the machine operator or for communication with other controllers. In todays industrial plants great emphasis is put on operator interaction with the system. The huge control centers in e.g. nuclear power stations are being replaced by PC-based Supervisory Control and Data Acquisition Systems (SCADA) using a large color screen for presenting process pictures with actual status. Two of the most used SCADA-systems are SattGraph from ABB and FIX from Intellution. In large industrial plants the total control function is normally divided into a number of different programmable controllers communicating with each other via some kind of standardized communication protocol. SattLine from ABB is an example of such a Distributed Control Systems (DCS).
24
Development version
3BSE021358R101 (0-2)
2.6 Communication with other systems
Most of the control system vendors have developed their own proprietary communication protocols for information exchange in SCADA and DCS. Some vendors also provide software based protocol converters enabling communication between 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 management system. General Motors in the USA have developed a standard named Manufacturing Automation Protocol (MAP) for communication between different programmable controllers and MIS. Unfortunately the MAP-standard so far have not been particularly successful.
3BSE021358R101 (0-2)
Development version
25
2.6 Communication with other systems
26
Development version
3BSE021358R101 (0-2)
Chapter 3: The IEC 61131-3 standard
3.1 Main objectives
Chapter 3
The IEC 61131-3 standard

3.1 Main objectives
IEC 61131-3 is the first, and so far only, global standard for programmable controllers. Considering that programmable controllers have been used in automation systems for more than two decades it is remarkable that a programming 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 application programs should be broken down into functional elements, referred to as program 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 rate. This 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 transferred between different parts of a program as if they were a single entity. The system should have parallel support for the five most used languages, Ladder Diagram (LD), Instruction List (IL), Function Block Diagram (FDB), Structured Text (ST) and Sequential Function Chart (SFC). The programming syntax should be vendor independent, resulting in more or less portable code that can easily be transferred between programmable controllers from different vendors.
3BSE021358R101 (0-2)
Development version
27
3.2 Benefits offered by the standard
3.2
Benefits offered by the standard
Well structured software

The main purpose of the IEC 61131-3 standard is to improve overall software quality in industrial automation systems. The standard encourages development of well structured software that can be designed either from top-down or from bottom-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 program 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 needs

The 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 programs 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.
28
Development version
3BSE021358R101 (0-2)
3.3 PLCopen trade association
Software exchange between different systems

Before the IEC 61131-3 standard was established it was not possible to port control programs from one vendors programmable controller to a competing system. This has been a major obstacle to a free market, where the customer selects a system based on the suitability of the hardware and price, rather than by the type of programming languages supported by the controller. With programmable controllers that are IEC compliant the potential for porting software is much better. Software developed for one manufacturers system should, at least theoretically, be able to execute on any other IEC compliant system. This would open up the market dramatically resulting in better standardization, lower prices and also improved software quality. Unfortunately such a high level of software portability may be difficult to reach in practise. The IEC 61131-3 standard defines a lot of features and only requires that vendors of programmable controllers specify a list of which features their system supports. This means that a system can be compliant to the standard without supporting all features. In practice portability therefore will be limited, since systems from two different vendors often have different feature list.
3.3
PLCopen trade association
Since the IEC standard has relatively week compliance requirements a number of the largest control system companies concerned with software portability has formed 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 supporting offices in Canada and Japan. The organisation informs users/programmers about the standard via a website (www.plcopen.org), a free quarterly newsletter, participation at trade shows and by arranging their own conferences. PLCopen has defined three different compliance classes concerning the portability of control system software. The lowest class is Base Level defining a core kernel of the standard. Although rather restricted it is feasible to develop applications based on it. Base Level provides an entrance for the control system vendors, showing their commitment to the standard.
Portability Level contains a large set of features including user defined functions and function blocks. This level also demands that the system has an
3BSE021358R101 (0-2)
Development version
29
3.3 PLCopen trade association
export/import tool for easy exchange of program code between systems from different manufacturers. The highest level, Full-Compliance, provides exchange of complete applications, including configuration information, between different control systems.
30
Development version
3BSE021358R101 (0-2)
Chapter 4: Programming languages
4.1 Overview
Chapter 4
Programming languages
4.1 Overview
The IEC 61131-3 standard specifies five programming languages: Ladder Diagrams, LD Instruction List, IL Structured Text, ST Function Block Diagram, FBD Sequential Function Charts, SFC IL and ST are textual languages while LD, FBD and SFC are based on graphical metaphores. Since all of these languages have both pros and cons, it is important to have a brief knowledge of the most suitable applications for each language. Although most control systems may be implemented with any one of the five languages the resulting program will be more or less effective depending on the requirements of the control application.
A1 A3 M1
A2
LDN AND( OR ) ST
A3 A1 A2 M1
LD
A1 A2 M1 := ( A1 OR A2 ) AND NOT A3; A3
IL
&
FBD
M1
ST
Fig. 11 A simple boolean condition programmed with four of the five IEC 61131-3 programming languages. SFC is normally only used for sequences.
3BSE021358R101 (0-2)
Development version
31
4.1 Overview
Historically the five languages have evolved in parallel with the evolution of automation systems. Relay systems documented via LD were the dominant technology 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 economical, technical, and cultural factors: Depending on age and educational background programmers often have a preference for certain languages. Programming with LD or FBD are more popular among older technicians without academic background while ST are the natural choice for younger people with a good computer knowledge. In small applications with relatively few logical conditions the demands for good structure and re-use of code are less important than in larger plants. Many older control systems use LD as a direct analogy for systems based on relays and switches. In large plants with a lot of sub-processes the total control function must be divided into an number of program modules with a high level of encapsulation in order to prevent the modules from interfering with each other. Program languages are often characterized after their level of abstraction. A low level language like IL is very close coupled to the actual binary codes running the processor in the control systems. Low level languages normally have a limited number of instructions producing very effective software code but unfortunately also totally tailored for a certain brand or model of system. High level languages like ST and SFC does not produces the most effective machine language but on the other hand the program may be compiled for a lot of different programmable controllers. When programmable controllers were first introduced in the 1970s most of the applications very purely boolean logical conditions. Today a control system must handle both digital and analogue control together with timers, counters and sequences.
32
Development version
3BSE021358R101 (0-2)
4.2 Common elements
The cost of software development has a tendency to increase exponentially with the size of the plant. Since many control functions are used in the same way over and over again it is possible to simplify the application program by using generalized standard modules. Re-use of standard modules is by far the most effective method to reduce costs. When industrial plants are redesigned with new control systems large parts of old program code, that has been tested and debugged during several years of intensive use, is often re-used. Even the most up to date systems therefore have to support older and generally less effective languages.
Structure level High
SFC FBD ST IL
Low 1950
LD
Year 1960 1970 1980 1990 2000
Fig. 12 The evolution of the five IEC 61131-3 programming languages. Today SFC, ST and FBD are the most used techniques for developing new control systems.
4.2
Common elements
The 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, constants, data types and variables.
Identifiers
Identifiers are used for naming different elements within the IEC language. For example variables, data types, function blocks and programs. An identifier is a string of letters, digits and underline characters which begin with a letter or an underline character. Space characters are not allowed in identifiers. Two or more underline characters may not be used together.
3BSE021358R101 (0-2)
Development version
33
4.2 Common elements
Allowed identifiers Motor_1 Elapsed_Time _prog2
Illegal identifiers 1Motor switch 1 Conveyor__3
Keywords are special identifiers that are used within the IEC language as individual syntactic elements. You are not allowed to use keywords as identifiers, for example: Type, True, False, Program, Task, Return, Step, Function, Timer, Counter Some compilers may be able to distinguish between them based on their position but others may produce confusing results. Programmers comments are delimited at the beginning and end by the special characters (* and *) respectively. Comments can be placed anywhere except in the IL language, which have some restrictions.
Data types
The first PLC:s could only handle boolean data but todays systems are being used in an ever widening range of industrial applications. For this reason the IEC standard provides a comprehensive range of elementary data types. The most often used data types are described below:
Data type Boolean Short Integer Integer Double integer Long integer Real numbers Long real number Duration Date Character string Keyword BOOL SINT INT DINT LINT REAL LREAL TIME DATE STRING
Bits 1 8 16 32 64 32 64
In addition to the elementary data types programmers can define their own Structured data types containing several components of data types. Such a data type have no physical correspondence in the plant, but it can be likened to a cable con34 Development version 3BSE021358R101 (0-2)
4.2 Common elements
taining a number of leads of different types, e.g. for the transfer of electrical power, 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.
Pumptype On (BOOLEAN) Off (BOOLEAN) Level (REAL) Name (STRING)
Fig. 13 Example of a structured data type containing several elementary data types.
A new structured data type is declared by framing the definition with TYPE and END_TYPE. TYPE Alarm On: BOOLEAN Off: BOOLEAN Level: REAL Name: 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 literals
By giving a variable the attribute constant, you prevent it from being changed after it is given its initial value. The initial value is normally specified in the variable declaration. There are two classes of numerical literals: integer and real, where the latter are distinguished from the former by the presence of a decimal point. Real literals may end with an exponent, indicating the integer power of ten by which the preceding number is to be multiplied. Decimal numbers are represented in conventional decimal notation. Based numbers are represented in base 2, 8 or 16 (prefix 2#, 8# or 16#). Boolean data are represented 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.
3BSE021358R101 (0-2)
Development version
35
4.2 Common elements
Time of day literals and dates are prefixed by the keywords TIME_OF_DAY#, TOD#, DATE#, D#, DATE_AND_TIME# or DT#.
Variables
Variables 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 its value when the system restarts. A constant variable will not be changed by the system. Variables with a blank attribute will always be calculated at system restart. If a variable has to start at a special value, that value has to be specified as Initial value, otherwise it will start at a predefined value depending on its data type (normally 0). The table below shows examples of names and attributes for variables of frequently used data types:
Name Pump_1 PhotoCell_4 Duration_Open Event_Notation NumberOfRev Temperature_5 Data type bool bool time date_and_time dint real constant constant constant retain Attributes retain Initial value False False T#3m10s DT#1999-02-01-12:30:00 10
The IEC standard defines three types of variables: local, global and access variables Local variables can only be accessed in the same function block or program in which they are declared. Global variables are accessible from any program or function block in the open project. A global variable must be declared as an external variable in the program organisation unit (POU) accessing it. Access variables can be used by other controllers.
36
Development version
3BSE021358R101 (0-2)
4.3 Ladder Diagrams
4.3
Ladder Diagrams
Ladder Diagrams (LD) has evolved from the electrical wiring diagrams that earlier 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 objects like a motor, a lamp or others but may also be an internal variable in the control system. There are two types of contacts, normally open and normally closed. Contacts which are normally open present a true state (Boolean variable is 1) when the contacts 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.
switch1 alarm motor
switch2
Normally closed contact Normally open contacts Power rails Fig. 14 Example of a simple ladder diagram with three contacts an a coil. Coil
It is possible to create LD programs which contain feedback loops where the variable from an output coil is used as an input contact, either in the same or in other logical conditions. In a real world relay circuit this is equivalent to
4.3 Ladder Diagrams
using one of the relays physical switches as an input contact. A computer experienced person would probably call this a memory bit.
start stop fan
fan
Fig. 15 Feedback loop in a LD program. The fan starts with an impulse on contact start and continues to run until the contact stop is opened.
Easy to understand
Programming with LD can be learnt relatively quickly and the graphical presentation is easy to follow. The method is particularly easy to understand by people who are familiar with simple electrical or electronic circuits.
Fig. 16 Status indication of an executing LD-program.
38
Development version
3BSE021358R101 (0-2)
4.3 Ladder Diagrams
LD programs are very popular among maintenance engineers since faults can easily be traced. Most programming stations generally provide an animated display showing the live state of transducers while the Programmable controller is running. This provides a very powerful on-line diagnostics facility for locating incorrect logic paths or faulty equipment.
Weak software structure

Ladder programming is a very effective method for designing small control applications. With increasing processing power and memory size with todays programmable controllers, the method can also be used to build large control systems. Unfortunately large ladder programs have several serious drawbacks. Since most programmable controllers have limited support for program blocks or subroutines it is difficult to break down a complex program hierarchically. The lack of features for passing parameters between program blocks makes it difficult to break down a large program into smaller parts that have a clear interface with each other. Usually it is possible for one part of a Ladder Diagram to read and set contacts and outputs in any other part of the program, which makes it almost impossible to have truly encapsulated data. The lack of data encapsulation is a serious problem when large programs are written by several different programmers. There is always a danger that internal data in one block can be modified by faulty code in other program blocks. Each programmer therefore has to be very careful when accessing data from other program blocks. There are also problems using structured data with ladder programs since data normally is stored and addressed in single memory bits. Many control applications often has a need to group data together as a structure. A lot of sensors provide more than one variable that has to be recorded by the control systems. Apart from the physical value measured by the sensor the application sometimes need to disable the sensor, place it in test mode, record the time when the sensor is active and also raise an alarm if the sensor is activated longer than a certain prescribed period. All of this information from the sensor should ideally be handled as a single structure that can be addressed using a common name. In most ladder programs such data is often spread out among different ladder rungs. Without a data structure the programmable controller has no provision for warning the programmer when the incorrect data is accessed.
3BSE021358R101 (0-2)
Development version
39
4.3 Ladder Diagrams
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 assign 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 feedback 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 succeeding state. To get real world actions the memory bits are used as conditions in separate rungs for controlling the outputs.
state_3 transducer_a state_1
state_1
state_2
state_1
transducer_b
state_2
state_2
state_3
state_2
transducer_c
state_3
state_3 state_1 state_2 state_3
state_1 output_a
output_b
Fig. 17 Sequence program with three states controlling two outputs.
40
Development version
3BSE021358R101 (0-2)
4.3 Ladder Diagrams
From the above example it is obvious that ladder programs with sequences can become very large and difficult to maintain. The most obvious problem is that control of the memory based sequence model is mixed with the application logic so that the total program behavior is difficult to understand and follow.
Difficult to re-use code

In many large control systems similar logic strategies and algorithms are used over and over again. A common application is to detect fire by using two or more transducers with a comparison algorithm to eliminate false alarms. Such systems consist of a large number of similar ladder rungs with only minor modifications to read different contacts and to set different outputs. This can result in very large 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 different inputs and outputs.
3BSE021358R101 (0-2)
Development version
41
4.4 Instruction List
4.4
Instruction List
Instruction 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 variables and weak debugging tools make the language less suitable.
IL language structure
IL is a language with a series of instructions, each on a new line. An instruction consists of an operator followed by an operand. The operator tells the system what to do while the operand identifies which variable will be processed. A few operators can process more than one operand, in which case, they should be separated by commas. IL programs are often written on a spreadsheet-like form with one column for operators and another for operands. Labels, used to identifying entry points for jump instructions, are placed in their own column to the left of the instruction. All labels should end with a colon. The instructions only need to have labels if the program contain jumps. Comments are placed in a fourth column to the right of the operand. Comments are enclosed by the starting characters (* and ending characters *). It is strongly advisable to add comments to all instructions during the programming. Large IL-programs without comments are very difficult to follow.
Label Operator LD GT JMPCN LD ADD JMP Greater: End: LD ST Operand temp1 temp2 Greater speed1 200 End speed2 motor Comment (*Load temp1 and*) (*Test if temp1 > temp2*) (*Jump if not true to Greater*) (*Load speed1*) (*Add constant 200*) (*Jump unconditional to End*) (*Load speed2*) (*Store speed to motor*)
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, operators, operands and comments are put in fixed tabulated positions.
42
Development version
3BSE021358R101 (0-2)
A characteristic behavior of IL programs is that instructions always relate to an internal register, named result register, RR, IL register or accumulator. Most operations 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 program example in Fig. 18 first loads the RR with a real variable. The second instruction compares RR with another variable which results in a boolean TRUE or FALSE result in RR. The conditional jump instruction JMPCN uses the boolean value in RR as a condition for either continuing with the next instruction (RR false) or jumping to the label Greater. In both cases the next instruction loads RR with a new real value. The final instruction stores the RR in a real variable named motor controlling the speed of the motor.
The IL instruction set

IEC has developed a standardized instruction repertoire by examining the many low level languages offered by different vendors. The IL language, as defined in IEC 61131-3, is a selection of the most commonly used instructions 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 complete the operator name with no blank characters in between. The following three modifiers can be used: N, Boolean negation of the operand C, Conditional operation (, delayed operation
Operator LDN AND( OR ) Operand switch1 switch2 switch3 (*RR := NOT switch1 AND (switch2 OR switch3)*) Comment (*Load inverse of switch1*) (*Boolean AND with the following two operations*)
Fig. 19 Example of operator modifiers in an IL program.
3BSE021358R101 (0-2)
Development version
43
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 evaluation of the following instructions must be delayed until the closing parenthesis is encountered.
Operator LD ST S R AND OR XOR ADD SUB MUL DIV GT GE EQ LE LT NE ) CAL JMP RET C, N C, N C, N N, ( N, ( N, ( ( ( ( ( ( ( ( ( ( ( Modifier N N Description Loads operand in RR Stores current result from RR Sets the operand Resets the operand Boolean AND Boolean OR Exclusive OR Arithmetic addition Arithmetic subtraction Arithmetic multiplication Arithmetic division Comparison greater than Comparison greater or equal than Comparison equal Comparison less than Comparison less or equal than Comparison not equal Executes delayed operation Calls a function block Jumps to label Returns from called function
Fig. 20 The IL instruction set.
44
Development version
3BSE021358R101 (0-2)
Best system performance

IL is ideal for solving small straight-forward problems. In the hands of an experienced 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 programmers without a deeper knowledge of the internal behavior.
Weak software structure

Since 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 automatic function for checking whether the RR contains correct data for the actual instruction code. Therefore it is up to the programmer to ensure that each instruction is given correct variable data.
Machine dependent behavior

Of all the five IEC languages IL has been found to be the most controversial. Unfortunately the semantics, i.e. the way the instructions operate, are not fully defined 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 defined. 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.
3BSE021358R101 (0-2)
Development version
45
4.5 Structured Text
4.5
Structured Text
Structured Text (ST) is a high level language, similar to Pascal and C, that has been specifically designed for use in programmable controllers. When 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 applications with a lot of conditional statements and calculations.
Statements
All ST programs contain a list of statements, each ending with a semicolon separator. Statements contain expressions which, when evaluated, 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, tabs, line feeds and comments inserted anywhere between operators and operands, i.e. where a space is needed for separation. An expression can be short like a literal constant or very complex involving many other nested operations. The assigned variable can be either simple or structured containing any number of elementary data types. motor := (start or motor) and not stop; speed3 := temp1*temp2 - 5*value7; IF speed3 < 0 THEN tank_level := 25.8; ELSE tank_level := 30.6; END_IF;
Fig. 21 Example of a simple ST program.
Statement text should be written in a structured way. The computer will accept any number of spaces in a statement but a good practice is to place statements consequently at a fixed position according to their role in the hierarchy.
46
Development version
3BSE021358R101 (0-2)
4.5 Structured Text
Operators in expressions
The table below summarizes the arithmetic and boolean operators in the IEC standard. The operators are listed in execution order with the highest precedences first:
Operator Parenthesis Function evaluation Negation Boolean complement Exponentiation Multiplication Division Modulus Addition Subtraction Comparison operators Equality Inequality Boolean AND Boolean XOR Boolean OR Symbol () Function (argument list) - (before other operator) NOT ** * / Mod + <, >, <=, >= = <> AND, & XOR OR Lowest priority Precedence Highest priority
Conditional statements
Often there is a need to execute some statements repeatedly for a specified number of times or only when a certain condition is fulfilled. The IEC standard provides a collection of conditional statements for this purpose:
FOR statement
The statement FOR is used when the number of 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 addition is repeated until the final value 10 is reached.
3BSE021358R101 (0-2)
Development version
47
4.5 Structured Text
WHILE statement
The statement WHILE is used when other statements are to be repeated an unknown number of times until the condition no longer is fulfilled. WHILE switch1 OR switch3 DO pump := FALSE; alarm := TRUE; END_WHILE;
REPEAT statement
The REPEAT statement is very similar to WHILE but the difference is that the actual statement will always be executed once since the condition is written after the statement. REPEAT B := B + 1; UNTIL B>10 END_REPEAT;
IF statement
An IF statement is used when one or more other statements are to be executed conditionally. IF A>B THEN B := A; ELSEIF A<B THEN A := B; ELSE A := 0; B := 0; END_IF; If A and B have different values the highest value will be given to both. Else both of the variables will be set to zero. When using conditional statements it is very important to avoid infinite loops. All statements therefore must include a condition that can be fulfilled.
48
Development version
3BSE021358R101 (0-2)
4.5 Structured Text
Calling function blocks

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

The ST language has an extensive range of constructs for assigning values to variables, calling function blocks and creating conditional expressions. This is very useful for evaluating complex mathematical algorithms, commonly used in analogue 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 programmers

Of the five IEC languages Structured Text is often the natural choice for people with former experience in computer programming. Control engineers without computer knowledge sometimes consider ST to be more complex 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 default programming language for describing the step actions in sequences.
3BSE021358R101 (0-2)
Development version
49
4.6 Function Block Diagram
4.6
Function Block Diagram
Function 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 machine or even an industrial plant.
In1 In2 In3 Time1 PT ET Out2
&
IN
TON
Out1
Fig. 22 Example of a FBD program with two logical function blocks and a timer block.
Syntax for function block diagrams

Each function block is drawn as a rectangle with inputs entering from the left and outputs exiting on the right. All function blocks have a built in algorithm for calculating output values based on the status of the inputs. The function block type name is normally shown within the block. For some of the most common logical functions a standardized boolean symbol may be used instead of type names. The formal names of input and output parameters are also shown within the block, close to the corresponding signal. In 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.
50
Development version
3BSE021358R101 (0-2)
Function block type
AND
IN
TON
Negation symbol
PT
ET
Input parameters
Output parameters
Fig. 23 Some fundamental rules for drawing function block diagrams.
Standard function blocks

The IEC 61131-3 standard defines a small repertoire of rudimentary standard function block types. These are predefined in most of todays programmable controllers. Standard function blocks are often used to construct other more user defined function blocks. The most common used blocks are: Boolean conditions like AND, OR, XOR and NOT Bistables Edge detectors Timers Counters PID Controllers
Bistables
Two types of bistables are available, SR and RS. Both of them have two boolean inputs and one output. The output is set (SR) or reset (RS) as a memory when the triggering input (S1 or R1) momentarily becomes true. When the other input becomes true the output returns to its initial state. If both inputs are true the SR will be set while the RS will be reset.
3BSE021358R101 (0-2)
Development version
51
SR bistable SR S1 R Q1
RS bistable RS S R1 Q1
S1 Q1 R
R1 Q1 S
Fig. 24 SR and RS bistable symbols with their corresponding function below.
Edge detectors
There 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 boolean 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.
Rising edge detector R_TRIG CLK Q1 Falling edge detector F_TRIG CLK Q1
CLK Q
CLK Q
Fig. 25 Edge detectors create a single pulse with the same duration as the execution time of the function block.
52
Development version
3BSE021358R101 (0-2)
Timers
Timers are among the most used function blocks in a control application. Whenever there is a need for a time delay between a change of state and the corresponding action 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 duration. 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 increased 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 value 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 zero.
3BSE021358R101 (0-2)
Development version
53
Pulse timer IN PT TP Q ET
On-delay timer IN PT TON Q ET
Off-delay timer IN PT TOF Q ET
IN
PT PT
IN
PT PT
IN
PT PT
Q ET
Q ET
Q ET
Fig. 26 Timing diagram for the three different types of timer function blocks.
Counters
Counters 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 value) 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 incremented by one. When the counter reaches the specified value in PV, the boolean 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.
Up-counter CTU bool bool int CU R PV CV int CV
CV=0
CU Q bool Q R
CV=PV
Fig. 27 Example of a CTU-counter block with preset value PV=5.
54
Development version
3BSE021358R101 (0-2)
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 zero, 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.
Down-counter CTD bool bool int CD LD PV CV int CV Fig. 28 Example of a CTD-counter block with preset value PV=5. Q bool CD Q LD
CV=PV CV=0
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.
Up-down counter bool bool bool bool int CTUD CU QU CD QD R LD CV PV CU bool bool int LD R
CV=PV CV=PV CV=0
CD QU QD
CV
Fig. 29 Example of a CTUD-counter block with preset value PV=3.
3BSE021358R101 (0-2)
Development version
55
The CTUD is often used in applications where there is a need to monitor the actual number of items in a process. It could, for example, be used to count the number of products placed on and taken off a store shelf.
Similar to electrical diagrams

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

FBD is very suitable for describing boolean logic with associated timers, counters and bistables. Most programmable controllers have such function blocks predefined in standard libraries for direct use by the programmer. There is no other programming language where timers and counters are so easy to implement as in FBD. Many 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 control algorithm. The FBD program gives a good overview over signal flow in systems with feedback.
Not suitable for conditional statements

FBD 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.
56
Development version
3BSE021358R101 (0-2)
4.7 Sequential Function Chart
4.7
Sequential Function Chart
Sequential Function Chart (SFC) is a very powerful language for describing the structure of a control system. Since SFC is not a full programming language it requires instructions taken from the other languages to build a complete application program. Many experienced programmers consider SFC combined with ST-statements to be the ultimate method for building structured control applications. The SFC standard has evolved from Grafcet, a graphical method of describing sequential behavior. Most European vendors have offered support for Grafcet in their most advanced programmable controllers since the beginning of the 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 performance of the programmable controller. Sequences can also be hierarchical with a main sequence containing several subsequences. The result is an application program with a good overview and also more detailed information about the controlled process objects.
Chart structure
SFC 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 condition 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 rectangle. 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 programs 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
3BSE021358R101 (0-2)
Development version
57
with double border lines. The initial step remains active until the following transition 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 languages. 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 behavior cyclically. The cyclic execution is enabled by a conditional branch backwards 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.
Initial step Start Tr1 Pusch Tr2 Drill Tr3 Wait Tr4 Label Tr5 Stop Tr6 Steps with code i other windows Transition Transition conditions with code in other windows
Fig. 30 Example of a SFC program for an automatic drilling machine. Note the cyclic execution being enabled by the Tr5 transition condition.
Steps and transitions

All steps within an SFC must have unique names and may only appear once in each flow. Every step has an automatically defined boolean step active flag variable that is set true while the corresponding step is active. The Step active flag is
58
Development version
3BSE021358R101 (0-2)
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 produces a boolean result. A transition that always occurs can be expressed by the boolean literal TRUE. The transition conditions may contain any kind or complexity of statements, variables and parameters as long as the result is put into a boolean variable.
Action descriptions
Steps in an SFC are used to describe the states of a controlled plant or machine. When the programmable controller executes an SFC program the state model only works as an internal memory representation of the control function. In order to get real world actions each state has one or more action descriptions containing program code 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.
Drill
P1 N P0
Drill_P1 Drill_N Drill_P0
Drill_Motor := Drill.T;
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 executed continuously 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 when the step becomes inactive.
3BSE021358R101 (0-2)
Development version
59
To use one or more of the action qualifiers the programmer writes the code statements in the associated editor window. It is not necessary to use all three action qualifiers. Most sequences use the N action qualifier but it is possible to leave all three qualifiers empty resulting in a step without any actions.
Sequence selection and simultaneous sequences

In its simplest form an SFC program consist of a series of steps in a closed loop executed continuously. This type of systems (e.g. Fig. 30) only has one main flow path. In many systems there is a need for two or more alternative branches in the sequence flow, often referred to as sequence selection. This is required in many batch process applications. In the example below with divergent paths each branch starts and ends with a transition. When any of the transition conditions Tr2 or Tr3 become true, the corresponding branch is selected and the execution continues in that path. Note that only one branch can be executed at any time. If more than one transition condition is true the leftmost branch has the highest execution priority. When the last transition in the selected branch becomes true the flow converges back to the main flow.
S1 Tr1 S2 Tr2 S3 Tr4 S5 Tr6 S4 Tr5 Tr3
Fig. 32 Example of a sequence selection with to alternative branches.
We have earlier seen how divergent paths can be used to execute alternate paths in sequences. An important characteristic of such parallel branches are however that only one step in one of the branches may be active at any time.
60
Development version
3BSE021358R101 (0-2)
However in many batch process applications there is also a need for simultaneous sequence structure with several branches. The main sequence is used for describing 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. Otherwise 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 construct 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.
Start Tr1 Acid Tr2 Water Tr3 Heat Tr5 Wait Tr6 Fig. 33 Example of a simultaneous sequence with three continuous branches. Temp Press Tr4 Monitor
Sub-sequences
One of the main uses of SFC is as a tool for developing the top-down design of the control function in a complex plant. Most processes can be described by a rel3BSE021358R101 (0-2) Development version 61
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 related 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 style

All 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. Detailed behavior is better to put within the action blocks or in other SFCs at a lower hierarchical level. Its a good practice to reduce interaction between simultaneous sequences to a minimum. Never allow step actions from different simultaneous sequences to change the same variables. Avoid using constructs where a divergent path branches out of a simultaneous sequence since this may lead to a sequence that never complete or behave unpredictably.
Powerful tool for design and structuring

SFC is a very suitable top level design tool in the early phase of a project but can also be used for describing the more detailed behavior of the plant objects being controlled. The SFCs graphical metaphore can be used right from the beginning, to give a first representation of a systems overall behavior. Since the description is very easy to
62
Development version
3BSE021358R101 (0-2)
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 behavior that has not been defined. By using an easy to follow tool for the preliminary specification the number of misunderstandings between customer, system designer and programmer can be reduced to a minimum. The SFC schemes produced in the first phase of a project can be further 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 needed

Even 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 programming languages. Most experienced programmers prefer the ST language as a complement to SFC. Therefore the vast majority of programmable controllers use ST as the default language for detailed description in SFC schemes. Some controllers also allow programming 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 programming languages.
3BSE021358R101 (0-2)
Development version
63
4.8 Function blocks
4.8
Function blocks
All IEC 61131-3 software applications can be broken down into functional elements named program organisation units (POUs). A POU may contain functions, function blocks or entire programs.
Application Program Function block Function Program Function block Function block Function Function block Function Function block
Fig. 34 The abbreviation POU is a common name for all these program parts.
Function blocks may be regarded as basic building blocks for control systems. The IEC standard ensures that function blocks can be realized using any of the five programming languages. Each function block is a well packaged software module that can 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 electronic hardware enormously. Function blocks can provide a similar off-the-shelf solution to common control problems.
IC with counter Up-counter CTU CU
74LS1 63
Q CV
R PV
Fig. 35 Comparison between an IC and a counter function block.
64
Development version
3BSE021358R101 (0-2)
4.8 Function blocks
The ability of a function block to store both data and algorithms means that it is possible to develop truly encapsulated control functions. A function block describes both the behavior of data and the data structure. The use of function blocks encourages well structured design which in return will speed up 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 fully supported with function blocks. Dont mess up function blocks with the programming language FBD which uses a number of predefined function blocks. A function block may be defined using any one of the five programming languages. Function blocks may also be called upon from all the five programming languages.
Definition and instances

One of the main reasons for programming with function blocks is the ability to reuse parts of the application software several times. This is accomplished by first establishing a function block 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 variables and output parameters. An algorithm calculating output parameters using the input parameters and if necessary local variables for intermediate storage. The algorithm may be expressed in any one of the five IEC 61131-3 programming languages. A function block instance is a unique set of data values handled together as a structure based upon the common rules in the definition algorithm. This data is needed since the function block instance has to remember its values between every call in the application program. The instance only contains data that are unique to the particular set of function block. This means that although a function block may use a very complicated algorithm the memory requirements to store the data for each instances of a block may be very modest. An application program based on several instances of func-
3BSE021358R101 (0-2)
Development version
65
4.8 Function blocks
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 identification purpose. The instance name is shown above the function block symbol.
Type definition Converter
Variable declarations Converter1
Converter2
Instances
Converter3 Algorithm 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 blocks

In 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 algorithm. 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 performs. Local variables are only available inside the function block and are used for intermediate storage by the algorithm. Parameters are used to transfer data in 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.
66
Development version
3BSE021358R101 (0-2)
4.8 Function blocks
On the other hand, care should be taken not to build so many features and variations into the function block that it becomes cumbersome to use.
Fig. 37 Example of a user defined function block with two statistical calculations.
Differences between functions and function blocks

Most programmable controllers have a number of predefined functions that can be used in expressions like variables or constants. Functions may be used in all the five programming languages. Among the most used functions are mathematical 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 functions input parameters. Any number of parameters of any type may be used in a function. A function always results in the same value for the same input values. When using a predefined or custom function block the definition always have to be instantiated and given a unique instance name. Function blocks communicate via input and output parameters. Each instance of a function block results in a unique set of parameters.
4.8 Function blocks
A function block cant be used in expressions, it has to be called. When called the programmer has to connect both input and output parameters to local variables in the actual POU. Contrary to functions a function block can create different output parameters even though the input parameters have the same values. For example this is the case for a counter which counts up every time its called and remembers its values until next count up. Advant Control Builder has an increased functionality concerning functions as regards to standard IEC 61131-3. Here a function can have both input and output parameters. If a function has output parameters it must be used like a function block.
How to use function blocks in control programs

Before a function block can be used the programmer has to create an instance of it and give this instance a unique name. In the programming editor this is normally done via the window being used for declaring variables. To create an instance means almost the same as making a copy of the function block definitions data. The programmable controller then reserves individual memory 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 the instance followed by a parenthesis. Within this parenthesis you have to fill in the actual local variables that connects to the parameters in the function block.
Fig. 38 An instance of the function block from Fig. 37 connected to local variables in a ST-program.
68
Development version
3BSE021358R101 (0-2)
4.8 Function blocks
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 languages

All 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 compliant 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 program organisation units (POUs). Such POUs may be programmed in any of the five languages and it is strongly advisable to combine the benefits of more than one language in a total plant application. SFC is by far the most suitable language for the early design and structuring of a control application. It works both as a communication tool between the customer and the programmer and as a structuring tool for the overall design of the control application. Since SFC is not a complete language all logical conditions and calculations have to be written in 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 functions. FBD is another alternative giving a very good overview over logical conditions 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 dont provide the same power as ST or FBD. Application programs from older control systems may relatively easy be transferred to IEC compliant programmable controllers by using these two languages.
3BSE021358R101 (0-2)
Development version
69
4.8 Function blocks
70
Development version
3BSE021358R101 (0-2)
4.8 Function blocks
71
Development version
3BSE021358R101 (0-2)
4.8 Function blocks
72
Development version
3BSE021358R101 (0-2)
4.8 Function blocks
73
Development version
3BSE021358R101 (0-2)
4.8 Function blocks
74
Development version
3BSE021358R101 (0-2)
Chapter 5: Object-oriented programs
5.1 New life for an old method
Chapter 5
Object-oriented programs
The IEC 61131-3 standard for programmable controllers is not the only effort towards better program quality, standardization and the 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 communication. Compared with programs which have been produced using more conventional tools, object oriented programs require both more memory and better performance 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 method
Thinking in an object-oriented manner is perhaps new to many system analysts and programmers, but the method is really just a return to an old and more natural way of describing problems. One thought-provoking consequence of this is that beginners often learn to program using object-orientation more quickly that experienced programmers, who are hindered by their own habitual way of thinking. In order to explain the principles of object orientation and some of the basic concepts, we shall look briefly at a cell, which is the basic building block for all life. Every cell has a very specialized task, which may be anything from converting energy to producing movement. The information on how the cell is to carry out its task is stored in the cell nucleus. The behavior of the cell may vary somewhat according to the particular chemical substances which it may contain at any instant.
All cells are contained within a membrane which has two important tasks; the first is to protect the cell so that foreign materials cannot enter it, and the second is to
3BSE021358R101 (0-2)
Development version
75
5.2 Objects in the plant
screen and separate the internal activity of the cell from surrounding cells. All communication between cells occurs by means of chemical substances which pass through the cell membranes.
Object Methods Variables Message
Fig. 39 A living cell is object-oriented in the way it works and interacts with other cells.
The living cell is an object with a function which is determined by methods in the cell nucleus and by the particular chemical substances which are available, i.e. the variables. Cells coordinate with other cells via chemical messages which pass through the membrane 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 messages. The receiving cells then react by carrying out the required action. In other words it is sufficient to send orders as to what should be done but not how it should be done. There are many different types of cell, but all have the same class or definition 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 gases, and muscle cells which can alter their shape and carry out work. Every subclass occurs in a large number of individual instances which have almost identical characteristics.
5.2
Objects in the plant
A 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-
76
Development version
3BSE021358R101 (0-2)
5.2 Objects in the plant
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 description, and partly to minimize the total requirement for communication between objects. The programs for the different objects can then be tested individually before the total function is commissioned, which reduces the risk of program errors.
Object A
Object B
Object 1
Object 2
Object 3
Object 4
Object C
Object 5
Fig. 40 Object distribution on the right is more efficient as it needs less communication.
The vast majority of computer programs produced by traditional methods are designed to solve a specific problem. The program designer then has to take all the details into account, and to write unique programs for every application. Such programs are difficult to use in other similar installations. In most cases it is quicker to write completely new procedures than to adapt already existing programs to new tasks. 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-
3BSE021358R101 (0-2)
Development version
77
5.3 Re-use of code
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 functioning of the installation. In order for it to be possible to use program objects efficiently, they must be well documented particularly regarding their interface with the outside world. The situation can be compared with the industrial manufacturing of products where functional units are assembled (e.g. cars) with the help of a large number of well-proven standard components. Some of these components may have relatively complex functions, such as the electronic fuel injection system. Given that their interface with the outside world is carefully specified, complex components of this type can be used without having to have a knowledge of their internal functioning.
5.3
Re-use of code
Many programmers strives to design program objects which exactly imitate the real-life process objects and which contain the same control functions. Most installations contain a large number of more or less similar variants of process objects. Examples of these are valves with on/off, continuous or three-position functions. It is therefore important to look for patterns and to design general function blocks which can be reused with minimal adaptation 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 fathers characteristics. In real-time systems there is less need to create or change program objects while the system is in operation. Concrete classes called POUs (functions, function blocks or programs) are therefore used instead of the method of inheritance. The programmer starts with defining the function block and then creates the required number of instances (copies of data sets).
5.4
Libraries
Nowadays there are hardly any companies that manufacture their own screws, nuts or similar components. The production of standard components is carried out
78
Development version
3BSE021358R101 (0-2)
5.4 Libraries
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 development using traditional methods, on the other hand, there are still many who are rediscovering the wheel over and over again. One of the greatest advantages of object oriented programming is that it is easy to reuse objects with standard functions. The software for commonly occurring objects is then produced by people with long experience which results in high quality. 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.
Fig. 41 The standard function block library supplied with Advant Control Builder.
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.
3BSE021358R101 (0-2)
Development version
79
5.4 Libraries
It should however be noted that there is a considerable knowledge threshold for the programmer to surmount before it becomes possible to make full use of the advantages of program libraries. In order to be able to use the standard function blocks to the full one must have a general view of their capabilities and limitations, which can take a considerable time for complex systems.
80
Development version
3BSE021358R101 (0-2)
Chapter 6: Control system glossary
Chapter 6
Control system glossary

A
adaptive control Control system where the controller parameters are automatically adjusted to the process properties. algorithm A collection of rules which describe, step by step, how a problem is to be solved. analogue signal A continuously variable signal which represents a physical quantity, e.g. temperature, flow or pressure. application The application contains a number of instructions that are compiled and downloaded for execution in the controller. ASCII An abbreviation for American Standard Code for Information Interchange. ASCII is the most used code for character representation in data processing systems. assembler instructions A low level programming language using letter codes for representing the machine code instructions.
B
Baud A unit used to specify the data transmission rate between two devices. One baud is equal to one bit per second. Boolean A variable that can only hold logical values such as True and False or 1 and 0.
3BSE021358R101 (0-2)
Development version
81
bottom-up A method for structuring application programs where the individual program objects are developed without consideration about the program structure above them. bus A system of parallel circuit lines for connecting the different units in a computer system or a programmable controller.
C
compiler An application program that translates the control application to low level machine language that can be executed in a computer or programmable controller. CPU The Central Processing Unit in a computer or programmable controller is the brain that coordinates all activities and carries out all operations specified in the application program. In PLCs the name Central unit is often used instead of CPU. cycle time All application programs in programmable controllers are executed repeatedly with a specified time interval.
D
digital signal A signal with only two possible states, named high and low, on and off or 1 and 0. distributed systems A control system with several computers or programmable controllers communicating with each other via a local network. download A common name for the transfer of a compiled application program from the engineering tool to the programmable controller.
82
Development version
3BSE021358R101 (0-2)
E
editor Application program that is used for writing and editing text or instructions execution When a computer is running the instructions are executed one at a time.
F
falling edge The change from 1 to 0 of a Boolean variable. feedback A signal from the controlled process may be fed back to the controller where it is used in the control algorithm. fieldbus A communication bus used for digital information interchange between sensors, actuators and programmable controllers. full duplex A transmission method where data can be both transmitted and received simultaneously.
G
gateway A communication unit for connecting different types of networks. It translates between different communication protocols. global variable A variable that can be accessed in all programs.
H
half duplex A transmission method where data can only be transmitted in one direction at a time. hardware A common name for all the equipment in a computer system.
3BSE021358R101 (0-2)
Development version
83
hexadecimal A 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 language A programming language similar to ordinary written text where each instruction or statement results in several machine code instructions. Pascal, C and Java are some of the most used languages today.
I
I/O module Many programmable controllers use expandable I/O units making it possible to add more input or output signals via extra modules. I/O signal The physical inputs or outputs in the I/O module. identifier A combination of letters, numbers and other characters which are used to give names to variables, parameters, modules and other language objects. initialization Establishing basic conditions when a system starts up. instruction A programming language element that specifies an operation and the values or location of its operands. integrated circuit Electronic functional unit containing a large number of semiconductors which have been compressed to a small silicon chip.
L
LAN Abbreviation for Local Area Network. A LAN is used to enable high speed communication between several computers and programmable controllers in a plant. local variable A variable that can only be accessed in the program where it is defined.
84
Development version
3BSE021358R101 (0-2)
low level language A programming language with letter codes where each instruction results in one machine code instruction. Assembler is a typical low level language. LSB An abbreviation for Least Significant Bit, i.e. the bit in a binary number with the lowest value.
M
machine code When a computer executes a program it must be available in machine code language which is a low level language with binary or hexadecimal codes. MMS An abbreviation for Manufacturing Message Specification, which specifies the messages used for industrial communication (manufacturing, process robotics etc.). This is the application layer used within MAP (Manufacturing Automation Protocol), a specification for open communication based on the OSI model. MSB An abbreviation for Most Significant Bit, i.e. the bit in a binary number with the highest value.
O
object code Common name for the resulting code produced when the compiler has translated an application program to executable machine language. octal A system of numbers with a base of 8. The decimal digits 8 and 9 are not used in this system. off-line A 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.
3BSE021358R101 (0-2)
Development version
85
on-line A 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
PLC An abbreviation for Programmable Logic Controller which is the most common used type of control system in todays industry. POU An abbreviation for program Organisation Unit. The IEC-standard describes programs, function blocks and functions as POUs. protocol A set of rules which determines the procedure for communication between different I/O units, computers or controllers.
R
RAS Abbreviation for Remote Access Service. With RAS a remote client can dial up a gateway machine resident on a LAN and establish a connection over the telephone line. real-time system A system where changes in the input signals will result in immediate actions on the corresponding output signals. Almost all control systems are of this type. rising edge The change from 0 to 1 of a Boolean variable. RS232C International standard for serial data transmission with the signal levels -12V and +12V. Is mainly used over relatively short distances.
S
sampling
86
Development version
3BSE021358R101 (0-2)
Computer based control systems cant communicate continuously with the surrounding transducers and actuators. Instead the control system samples the environment (collects and transmits values) periodically with a specified sample time. SattBus A fairly fast (62,5 kbit/s) fieldbus with token bus protocol. It is intended to be used for short messages to field devices such as transducers, actuators, etc. simulation Many computer based engineering tools provide a function for simulating the control function in the computer without downloading it to the programmable controller. source code Programs written in high level languages are often called source code before they are compiled to object code.
T
TCP/IP An abbreviation for Transmission Control Protocol/Internet Protocol. TCP/IP is used both on the Internet and on many Local Area Networks.
top-down A method of breaking down the entire control function into a hierarchical structure of sub-processes.
W
workstation A common name for a computer with associated software used for editing and compiling control programs.
3BSE021358R101 (0-2)
Development version
87
88
Development version
3BSE021358R101 (0-2)
Index
Numerics
3964R 19 divergent path 60 download 17 Duration 35 local variable 36 low level language 13
A
abstract classes 74 access variable 36 accumulator 43 action 57 action description 59 action qualifier 59 actuator 6 Advant Control Builder 17 assembler 12 assembly language 42
E
edge 52 editor 12, 17 elementary data type 34 encapsulated data 39, 65 engineering station 15, 17 event 27 execute 12, 18 expression 46
M
machine code 12, 17 Macintosh 71 main state 62 MAP 25 memory 8, 15 memory bit 38 message 72 methods 65, 72 minor state 62 MIS 25 mnemonic 43
F
feedback loop 37 function 67 function block 28, 50, 64, 67
B
Basic 14 batch process 60 Boolean data 35 bottom-up 28
O
object 72 object code 14 object-oriented programming
71
G
global variable 36 Grafcet 57
C
C 14, 46 C++ 71 central unit 15 class 72 COMLI 19 comment 34, 42 common elements 33 communication protocol 19 compatibility 23 compiler 13, 17 compliance class 29 conditional statement 47 constant 35 contact 37 controller 5 cross-assembler 12 cycle time 18, 27
H
high-level language 13
object-oriented systems 8 off-line 17 on-line 18 operand 42, 46 operator 42, 46 operator modifier 43 optical isolator 16
I
I/O unit 15, 16 IC 6, 64 identifier 33 IL register 43 inheritance 65, 74 initial step 58 initial value 36 instance 49, 65, 72, 74 instance name 67 instruction 12, 42 instruction list 17 integrated circuit 56 interpreter 13
P
parameter 50, 65, 67, 72 Pascal 14, 46 PID 9 PLCopen 29 POU 27, 36, 64, 73 power rails 37 process computer 7 Process Value 9 Profibus 19 Programmable Controller 7,
15
D
Data Highway Plus 19 data structure 27 date 35 DCS 24 debugging program 12 definition 65, 72 distributed system 19
L
label 42 ladder diagram 16 libraries 8 local area network 7
Programmable Logic Controller 7, 15 protocol 24
R
real-time system 18 relay coil 9, 37 remote I/O 19
3BSE021358R101 (0-2)
Development version
89
Index result register 43 retain 36
S
SCADA 7, 24 semantics 45 sensor 39 sequence 8, 40 sequence selection 60 Setpoint 9 shareware 22 Simula 71 simulate 17 simultaneous sequence 61 Smalltalk 71 Soft PLC 19 source code 14 standard libraries 56, 75 state 40 statement 46 step 57 structured data type 34 sub-class 72 sub-process 8 subroutine 39 sub-sequence 62 syntax 12 syntax checking 17
T
task 19 Time of day 35 top-down 28, 62 transducer 5 transition 57 transition condition 57
V
variable 72
W
Windows 71
90
Development version
3BSE021358R101 (0-2)
Specifications subject to change without notice. Printed in Sweden. 1999 ABB Automation Products AB.
3BSE021358R101 0009

Abb - Iec61131

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Abb - Iec61131

Hochgeladen von

Copyright:

Verfügbare Formate

ControlIT

ICE 61131 Control Languages

Control IT IEC 61131 Control Languages

1.4 1.5 1.6

Why open systems are needed

The IEC 61131-3 standard

Control system glossary

Chapter 1: Evolution of Control Systems

Evolution of Control Systems

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

Chapter 1: Evolution of Control Systems

Chapter 1: Evolution of Control Systems

1.3 Control applications

Chapter 1: Evolution of Control Systems

Chapter 1: Evolution of Control Systems

1.4 Relay logic

Closed loop control subsystems

Fig. 3 A closed loop control system.

1.4 Relay logic

Chapter 1: Evolution of Control Systems

Chapter 1: Evolution of Control Systems

1.5 Computers for process control

Computers for process control

1.5 Computers for process control

Chapter 1: Evolution of Control Systems

Chapter 1: Evolution of Control Systems

1.5 Computers for process control

1.5 Computers for process control

Chapter 1: Evolution of Control Systems

Chapter 1: Evolution of Control Systems

1.6 Programmable controllers

I/O unit Input modules Output modules

Fig. 7 The components of a programmable controller system.

1.6 Programmable controllers

Chapter 1: Evolution of Control Systems

Chapter 1: Evolution of Control Systems

1.6 Programmable controllers

A 001 A 012 ON 020 RP A 003 = 201

Computer based programming tools

1.6 Programmable controllers

Chapter 1: Evolution of Control Systems

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

Chapter 1: Evolution of Control Systems

1.6 Programmable controllers

1.6 Programmable controllers

Chapter 1: Evolution of Control Systems

Chapter 2: Why open systems are needed

2.1 Programming dialects

Why open systems are needed

2.3 Software cost

Chapter 2: Why open systems are needed

Chapter 2: Why open systems are needed

2.4 Portable software applications

Fig. 10 Cost of hardware versus software.

Portable software applications

2.5 Re-usable software

Chapter 2: Why open systems are needed

Communication with other systems

Chapter 2: Why open systems are needed

2.6 Communication with other systems

2.6 Communication with other systems

Chapter 2: Why open systems are needed