1 IEC61131 Lenguajes Escencial MB

ControlIT
IEC 61131 Control Languages

Introduction
IEC 61131
Control Languages
Introduction
Copyright 1999 ABB Automation Products AB. The contents of this document can be changed by ABB Automation Products AB without prior notice and do not constitute any binding undertakings from ABB Automation Products AB. ABB Automation Products AB is not responsible under any circumstanc- es for direct, indirect, unexpected damage or consequent damage that is caused by this document. All rights reserved. Release: October 2001 Document number: 3BSE 021 358 R201 Rev B Printed in Sweden.
Trademarks
Registered trademarks from other companies are: Microsoft, Windows, Windows NT from Microsoft Corporation. PostScript and Acrobat Reader from Adobe Systems Inc. FIX from Intellution and 3964R from Siemens.
3BSE 021 358 R201 Rev B
Contents
1 Evolution of Control Systems
1.1 1.2 1.3
1.4 1.5 1.6
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Control Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Monitoring Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Sequencing Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Closed-loop Control Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Relay Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Computers for Process Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Programming Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Programmable Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 I/O Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Programming Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Computer-based Programming Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Cyclic Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Soft PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Why Open Systems are Needed

2.1 2.2 2.3 2.4 2.5 2.6
25
Programming Dialects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Software Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Software Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Portable Software Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Reusable Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Communication with Other Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
IEC 61131-3 Standard

3.1 3.2
31
3.3
Main Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Benefits Offered by the Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Well-structured Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Five Languages for Different Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Software Exchange between Different Systems . . . . . . . . . . . . . . . . . . . . . 33 PLCopen Trade Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3BSE 021 358 R201 Rev B
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 Reuse Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instruction List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IL Language Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Block Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . Subsequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advice on Good Programming Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Powerful Tool for Design and Structuring . . . . . . . . . . . . . . . . . . . . . . . . . Other Programming Languages are Needed . . . . . . . . . . . . . . . . . . . . . . . .
35
35 37 37 38 39 40 41 42 43 44 45 46 46 47 49 49 49 50 50 51 51 53 53 53 54 54 55 60 60 61 62 62 64 64 65 67 67 68 68
4.3
4.4
4.5
4.6
4.7
3BSE 021 358 R201 Rev B
Contents
4.8
Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Type and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 User-defined Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Differences between Functions and Function Blocks . . . . . . . . . . . . . . . . 72 How to Use Function Blocks in Control Programs . . . . . . . . . . . . . . . . . . 73 Interaction between Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Object-oriented Programs
5.1 5.2 5.3 5.4 5.5 5.6
75
New Life for an Old Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Objects in the Plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Data Flow in Real-time Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Program Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Reuse of Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Control Modules
6.1 6.2 6.3 6.4
83
Control Module Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Graphical Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Automatic Code Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Applications for Control Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Project Management
7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8
89
Stages of a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Industrial Application Example

8.1 8.2 8.3 8.4
95
8.5
Control Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Project Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Variables and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Ramp Function Block Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 SFC Sequence Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Control Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Control Module Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Glossary Index
109 117
3BSE 021 358 R201 Rev B
Contents
3BSE 021 358 R201 Rev B
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 to control the temperature in a room. At the other extreme, the plant could be an entire nuclear reactor for producing electrical energy for thousands of people. Apart from their size and complexity, all control systems may be divided into three well-separated functional parts: the transducers, the controller and the actuators.
Transducers Actuators
Plant
Inputs
Controller
Outputs
Parameters
Status
Fig. 1 Overview of the components in an industrial control system.
The controller monitors the actual status of the plant processes through a number of transducers. The transducers convert physical properties into electrical signals that are connected to the controller inputs. Digital transducers measure conditions with distinct states, such as on/off or high/low, while analog transducers measure conditions which have a continuous range, such as temperature, pressure, flow or liquid level.
3BSE 021 358 R201 Rev B 9
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 into process behavior via the actuators. Most actuators create movements of valves, motors, pumps and other devices by using electrical or pneumatic energy. The operator interacts with the controller by providing control parameters. Some controllers can display process status via a screen.
1.2
History
The first control systems were developed during the industrial revolution at the end of the 19th century. The control function was implemented by using ingenious mechanical devices automating some of the most repetitive and critical tasks on the assembly lines. These devices had to be individually adapted to each task and due to their mechanical nature they also suffered from a short lifetime. In the 1920s, mechanical control devices were replaced by electrical relays and contactors. Relay logic made it possible to develop larger and much more sophisticated control functions. Since then, electrical relays have been used in a large number of control systems around the world. Relays have proven to be a very cost-effective alternative, especially for automating small machines with a limited number transducers and actuators. In todays industry, relay logic is seldom chosen for new control systems but a large number of older systems are still in use. The silicon-based integrated circuit, IC, paved the way for a new generation of control systems in the 1970s. Compared with relays, ICs based on TTL or CMOS integrated circuits are much smaller, faster and also have a longer lifetime. 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 change their behavior. In the early 1970s, the first commercial computers debuted as controllers in large control systems. Since computers can be programmed they offer a great advantage compared with the wired logic function in systems based on relays or ICs.
10
3BSE 021 358 R201 Rev B
1.2 History
Early computer systems were large, expensive, difficult to program and unfortunately also very sensitive to the harsh environment in many industrial plants. As a result of demands from the American car industry the Programmable Logic Controller (PLC) was developed in the early 1970s. The PLC is a computer designed to work in an industrial environment. The transducers and actuators in the outside world are connected via robust interface cards. Compared with an office computer, the PLC has a limited instruction repertoire, often only logical conditions. Early PLCs had no analog inputs and therefore they could only handle digital control applications. In todays industrial plants there is often a need to handle both digital control and closed-loop analog control in the same control system. These systems are often called Programmable Controllers since their operation is not limited to only logical conditions. Today, the overall control function in a plant is often 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 Fig. 2 The evolution of control systems since the end of the 19th century. 1920 1970 1980 1990 2000
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 status of the manufacturing process.
3BSE 021 358 R201 Rev B
11
1.3 Control Applications
It is characteristic of todays industry that the demand for profitability is increasing, while at the same time there is a more frequent need to carry out changes in the control function. Because the cost of computer equipment has fallen dramatically in recent years, the cost of development and maintenance of software has become the predominant factor. In order to improve the quality and make it easier to reuse programs, there are today many more people working with object-oriented systems. In such systems the real process components like motors, valves and PID controllers are programmed via standardized program objects stored in program libraries. Such objects are well proven and have a standardized user interface.
1.3
Control Applications
It is easy to be overwhelmed by the complexity of an industrial plant process. However, most processes can be simplified by dividing them into a number of smaller subprocesses. Such subprocesses can normally be divided into three different categories. Monitoring subsystems, sequencing subsystems and closed-loop control subsystems will be further described in the following three sections.
Monitoring Subsystems
A monitoring subsystem displays the process state to the operator and draws attention to abnormal conditions which require some kind of action from the operator. The measured process values for temperature, pressure, flow etc. are displayed to the operator via indicators, meters, bar-graphs or via a computer screen. Signals can also be checked for alarm conditions. The system indicates alarms via warning lamps or audible signals, often accompanied by a paper printout. Many monitoring systems also keep records of the consumption of energy and raw materials for accountancy purposes. The system may also create automatic warnings when critical components need to be exchanged.
Sequencing Subsystems
The vast majority of all subprocesses can be described via a predefined sequence of actions that must be executed in a certain order. In such a system it is not possible to specify a momentary combination of input signals resulting in a certain output signal. Instead, the output status is dependent on an entire sequence of input signals having occurred. In order to monitor the sequence of actions there is a need for memory functions.
12 3BSE 021 358 R201 Rev B
1.4 Relay Logic
Sequencing subsystems have many advantages over control systems based on momentarily input status. Normally, they are easier to implement and present a better overview of the control function. It is also easier to localize malfunctions in a transducer since this will cause the sequence to freeze.
Closed-loop Control Subsystems

Many subprocesses have analog variables such as temperature, flow or pressure that must be automatically maintained at some preset value or made to follow other signals. Such a system can be represented by the block diagram in Fig. 3. Here, a variable in the plant denoted PV (Process Value) is to be maintained at a desired value denoted SP (Set Point). PV is measured by a transducer and compared with SP to give an error signal. This error signal is supplied to a control algorithm that calculates an output signal, which is passed on to an actuator, which affects the corresponding variable in the process. The control algorithm will try to adjust the actuator until there is zero error. Many control algorithms are available but the most commonly used is the Proportional, Integral and Derivative (PID) controller. Since the control 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 digital transducer contacts. The control function is defined, once and for all, by how the contacts are connected to each other and to the corresponding relay coils.
3BSE 021 358 R201 Rev B
13
1.4 Relay Logic
All relay coils are normally used to activate one or more built-in switches. These switches are connected to the actuators in the process. If one of the relay switches is used as an alternate input contact the result will be a circuit with memory function.
Logical AND
Logical OR
Memory
Fig. 4 Three often-used logical conditions implemented with relay logic.
A relay-based control system may contain any number, from a dozen up to thousands, of relays. The relays with corresponding wiring are contained in one or more cabinets. The transducers and actuators are normally connected via plinths. The logical function of a control system based on relays is described in ladder diagrams, presenting how transducer contacts and actuators are 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 electrical wiring is time consuming, 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 leads to engineering problems.
14
3BSE 021 358 R201 Rev B
1.5 Computers for Process Control
Experience shows that it is easy to develop small relay systems with a limited number of relays, but with increasing complexity the work will demand a very experienced engineer. A characteristic quality of relay-based control systems is the decentralization of the logic function into a large number of discrete relays. Since relays are electromagnetic components they have a limited life-time. Relay-based control systems therefore need continuous maintenance and service. Another disadvantage of relay systems is that it may be very difficult and time-consuming to change the logical function in an existing plant. Today, relay logic can only be justified in very small plants with less than a dozen inputs and outputs and in plants with severe electrical interference, where computers and programmable controllers cannot be used.
1.5
Computers for Process Control
The first computers that were developed during the 1950s were very large, expensive machines. Such systems were mainly used for administrative tasks like payroll administration, accounting and banking. The operations 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 of computers, compared with wired logic, is that the programmed control function can easily be altered. Computers are also very suitable for performing arithmetic calculations and for storing huge amounts of data. A standard computer, however, is not equipped for communication with industrial equipment. Another disadvantage is the high learning threshold for developing computer programs. Early computer-based control systems needed extra interface equipment in order to handle real-world transducer and actuator signals. These interfaces normally had to be individually developed for each plant. Since then, several vendors have developed standard interface modules for both digital and analog process signals.
3BSE 021 358 R201 Rev B
15
Programming Methods
All computer programs consist of a number of instructions which tell the computer what to do when the program is run, or executed as programmers prefer to say. Because computers process binary information, the computers instructions are very different from our own verbal ways of describing the actions we want it to take. In programming, therefore, various aids are used to process and translate our verbal function description into the computers own language. These aids are ready-made computer programs which can be purchased 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 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 checking syntax and in calculating logical jumps within a program. Assembly is normally carried out on the same type of computer as will be used for program execution, but there are also assembler programs, known as cross-assemblers, which can be run on other types of computers. Test running of assembler programs is made easier by special programs that allow part of the program to be executed step by step. Using these so-called debugging programs, it is also possible to simulate real-life signals so that the function can be tested without having to connect the computer to the process.
16
3BSE 021 358 R201 Rev B
Start
Editing using editor LDA IN1 L1 Test-running using debugger SUB CMP BNE L1 ADD D STO Functioning properly? Yes Stop No OUT1 C B 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 an editor, an assembler and a 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 restruc- tured so that the required function can be obtained using the instructions available in the computers repertoire. The completed program is entirely matched to one particular type of computer and cannot be transported to another type of computer. On the other hand, a properly written assembler program gives good performance and the optimal usage of the computers memory. This is important in, for example, industrial robots and where very large series are to be produced. Working with assembler is often called low-level language because the instructions are similar to the 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.
3BSE 021 358 R201 Rev B
17
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 highlevel 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 completed programs can be moved to another type of computer, assuming that a suitable compiler is available. The disadvantage of programs written in high-level languages is that they take up more room in the memory than corresponding programs written directly in assembler (machine code). This also means that the performance of the computer is used less efficiently.
18
3BSE 021 358 R201 Rev B
1.6 Programmable Controllers
1.6
Programmable Controllers
In answer to demands from the car industry, several vendors, in the early 1970s, presented the Programmable Logic Controller (PLC). The PLC is an industry-adapted computer with a simplified programming language. Early PLCs were originally only intended to replace relay-based control systems. Since then, PLCs have developed into the most commonly used type of control systems in all kinds of industrial plants, from small machine control systems, up to entire manufacturing lines in large process industries. Independent of brand and type, most PLCs contain three functional parts: the central unit, the memory and the I/O unit, all communicating via a bus unit. The central unit coordinates all activities in the PLC and executes the control program in the memory. The process status is monitored and sampled via the I/O unit. Apart from logical instructions an increasing number of todays PLCs also have arithmetic functionality. Many vendors are therefore using the term Programmable Controller instead of PLC. Programming of PLCs is normally carried out on an external computer-based engineering station. The compiled program is downloaded to the central unit and then into the program memory via a serial channel or via a LAN. Some PLCs have an option for using the engineering station for online process status presentation, while the control program is executing.
PLC Engineering station
Memory
Central unit
Bus unit
I/O unit Input modules Output modules
Transducers Actuators Fig. 7 The components of a programmable controller system.
3BSE 021 358 R201 Rev B
19
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 lightemitting diode and a photoelectric transistor linked together in a package. Since there are several different signal levels in a typical plant, many I/O units allow the use of exchangeable I/O modules. Such an I/O unit can easily be cus- tomized to the specific signal levels of the plant. The most commonly used I/O modules are digital DC inputs and outputs with the signal levels 24 V or 48 V. Many vendors also offer modules with AC inputs and outputs with signal levels of 110 V or 220V. A growing number of programmable controllers have arithmetic functionality. Such systems have a need for analog input and output I/O modules. Most analog transducers represent a physical value as a current within the range 4-20 mA, with 4 mA indicating the minimum value.
Programming Methods
The first PLCs used a programming language based on relay ladder diagrams. The program was entered via a programming terminal with keys showing contact symbols (normally open/normally closed), relay coils and parallel branches with which a maintenance electrician would be familiar. The programming terminal compiled the ladder diagram into machine code which was sent to the controller for execution. With the controller executing the control program was presented on a screen, with energized contacts and coils highlighted, making it possible to study the application and also, if necessary, to debug the program. Programming with ladder diagrams is a very intuitive method, especially for people with previous knowledge of relay-based control systems. Therefore, this method was initially preferred by American PLC vendors.
20
3BSE 021 358 R201 Rev B
In large plants and when people without previous knowledge of relay logic are to develop the control program, Boolean instruction lists are often preferred. Most European PLC vendors have chosen this as the standard programming method in their systems.
A 001 A 012 ON 020 RP A 003 = 201 Fig. 8 Examples of PLC programs using a ladder diagram and instruction list.
Computer-based Programming Tools

Early PLCs were programmed with dedicated terminals, only usable for that purpose, together with specific systems from one vendor. Today, almost all programmable controllers are programmed with standard personal computers (PCs) running a dedicated development software tool. Control Builder Professional from ABB is an example of such a software tool intended for use with some of the programmable controllers supplied by ABB. A complete system with computer and development software is often referred to as an engineering station. Most development tools contain several different, but often integrated, software applications which simplify the work of program development for the associated control system. The editor is used to define variables and for writing the control program instructions. Most editors have syntax checking that helps the programmer avoid such errors. Program editing is normally done offline, which means that the engineering station is running locally, not in communication with the controller. The compiler translates the control application into machine code and 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 input signals.
3BSE 021 358 R201 Rev B
21
Some development tools can be used online, for displaying the actual process signal status on the computer screen, when the control application is executing in the programmable controller. With ever-increasing performance in computer-based engineering stations, several vendors now offer developing packages, in which it is also possible to use programming methods like Structured text, Sequential Function Charts and Function Block Diagrams, apart from ladder diagrams and instruction lists. These methods are further described in Chapter 4.
Cyclic Execution
Industrial control systems are real-time systems, which means that changes in the input signal require immediate action on the corresponding output signals. An example is a machine in which some movement must be stopped when a particular limit is reached. If the controller does not react in time, the result may be damage to the machine or injury to the operator. The consequences of a delayed reaction therefore become unacceptable. In order to fulfil the demands on a real-time system, the application program must have constant access to current input data from the process. To achieve this the compiled program is executed cyclically at a specific frequency. Changes in the incoming signals can therefore only affect the output signals at the end of each completed program cycle. The required interval time of the program is determined by the maximum allowed delay time in the process.
Read inputs
Execute program
Interval time 1 - 50 ms
Update outputs
Fig. 9 A typical program scan in a programmable controller.
22
3BSE 021 358 R201 Rev B
Because different subprocesses may have different time demands, some programmable controllers provide a function for dividing the total program into different tasks, each with its own interval time.
Distributed Systems
In many large industrial plants there is a need for distribution of the entire control function to several different programmable controllers and process computers. This strategy will improve total performance and also reduce the risk of total breakdown in the manufacturing process. The cabling between transducers, actuators and the programmable controllers accounts for one of the major costs in a control system. If the plant is spread out over a large area, considerable cost savings may be achieved by using remote I/O subsystems situated close to the actual subprocess. Distributed control systems require a standardized communication protocol in order to exchange information. Several PLC vendors have developed their own proprietary protocols during the 1990s and some of these, like COMLI from ABB, 3964R from Siemens and the vendor-independent Profibus, have slowly emerged into de facto standards supported by more than one PLC vendor.
Soft PLC
One problem with PLCs is that all vendors use their own proprietary controller hardware with an associated programming language. In spite of the basic functions being practically identical, the instructions have different names and the rules governing the syntax of the programs may vary. This makes it difficult to communicate and exchange application programs between systems of different manufacture. Several software vendors have presented a new type of controller called the Soft PLC. The Soft PLC is real-time software executing a control application in a standard PC and communicating with the plant via a standardized modular I/O unit. The major advantage of a Soft PLC is that all the required hardware is vendor independent. Unfortunately, none of the software vendors has managed to establish their Soft PLC software as an industry standard. This means that control applications developed with one Soft PLC application cannot be transferred to Soft PLCs from other vendors.
3BSE 021 358 R201 Rev B
23
24
3BSE 021 358 R201 Rev B
Chapter 2: Why Open Systems are Needed
2.1 Programming Dialects
Chapter 2
Why Open Systems are Needed

2.1 Programming Dialects
The programmable controller is one of the most critical components in todays industry. Since control systems are being used in so many plants and in 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 decided to standardize their equipment to at least two different vendors, in order to minimize risks. In real-world applications this often leads to costly double work and problems in communication between systems from different manufacturers.
2.2
Software Quality
As more and more jobs in manufacturing and process industries become automated, the software programs become larger and therefore more difficult to manage. In most cases, more than one programmer is needed to develop the application software for industrial automation. Experience shows that the risk of program errors grows exponentially with the number of programmers involved and, consequently, the size of the program itself. Experience also shows that new industrial plants often encounter problems a long time after commissioning. Some failures can interrupt production or, in the worst case, result in serious damage to the production equipment or the processed material.
3BSE 021 358 R201 Rev B
25
2.3 Software Cost
It is well-known that good software quality comes at a high cost. Most control software is developed either by a department in the customer organisation or by small software houses working in a close privileged relationship with the machine or plant manufacturer. In both cases, software production and thus cost is not governed by the free market. Consequently, software suppliers are not motivated to strive towards more efficient development methods and tools. The vast majority of all control code is written with the proprietary software packages delivered by the control system vendors. Many of these packages have very poor facilities for working with modules, for code reuse and for documentation. Software quality is therefore heavily dependent on the experience and intellectual capacity of the programmer. Before the IEC 61131-3 standard was established, good software engineering was an open goal in the control application environment.
2.3
Software Cost
During the last decade, standardized software packages for personal computers, like word processors and spreadsheets, have become very popular. This makes it possible for software vendors to lower prices dramatically. Distribution via the Internet has pushed the limits even further, and today many useful standard applications are available as shareware, almost free of cost. In contrast, most software for control applications is adapted to the specific needs of a single plant application. This means that the total development cost has to be charged to a single customer. Most customers find it difficult to control the total software development cost. A customer without experience in software development can only present a rough functional description to the developer. In many cases, this leads to a final product that only partly fulfills the customers requirements. Even small changes and additions tend to be very costly to implement, especially in later phases of program development. The hardware on which computer programs are run is developing at an 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 becoming more dependent on the time required for program development. In most projects, therefore, greater weight is attached to standardization and reuse of programs than with finding the optimal hardware.
26 3BSE 021 358 R201 Rev B
2.4 Portable Software Applications
Fig. 10 Cost of hardware versus software.
An automation plant or machinery can pose a danger to the operators or the material if the control software has fatal errors. Therefore, the software has to pass a particularly intense testing and validation procedure. In real-world applications, testing may be very time consuming, especially if the work has to be done with the process running. If the application program has been written by inexperienced programmers, the cost of testing even may exceed the cost of program coding.
2.4
Portable Software Applications
The personal computer together with the Windows operating system is today a well-established de facto standard for information handling in almost all offices in the world. The main reason for the PCs enormous penetration is software compatibility. Application programs developed for Windows can be used on almost all PCs around the world. More than 25 years after the introduction of the first programmable controllers, this market still lacks an international standard similar to that for the PC. Most control vendors use their own proprietary programming dialect, which can only be used with their hardware. This is surprising since almost all industries using programmable controllers have high demands on inter-system portability of control system software. Since the cost of developing well-tested software is much higher than the hardware cost, there is often a need to port existing applications from older outdated hardware to newer systems. To many, it is incomprehensible that it has taken more than 25 years for the programmable controller market to start establishing a common programming standard like the IEC 61131-3.
3BSE 021 358 R201 Rev B
27
2.5 Reusable Software
2.5
Reusable Software
Not so long ago, many real programmers measured their effectiveness by the amount of program code they produced per day. Real programmers dont like to waste their time on structuring and detailed specification. Instead, they move directly from a rough specification, often made by the customer, to coding in their favorite language, often ladder diagram or instruction list. Today, even real programmers realize that the first phase in a project when the overall function is analyzed, structured and designed, is the key to a successful and cost-effective application program. The traditional method of reducing software cost is to reuse common parts of the program code in several similar applications. Unfortunately, this is difficult in industrial automation since most processes are very different in behavior. Another obstacle to software reuse is that the program code is often strongly affected by the programmers own style. When the final application is the result of teamwork there are often visible seams between the parts coded by different programmers. The only way to reduce the risk of seams is to encour- age (read force) all the members of the team to follow certain rules and formal- ism for producing code.
2.6 Communication with Other Systems The first programmable controllers presented in the seventies were often placed in an electrical equipment cabinet close to the machine or process being controlled. These controllers normally had no means of interaction with the machine operator or communication with other controllers.
In todays industrial plants, great emphasis is put on operator interaction with the system. The huge control centers in e.g. nuclear power stations are being replaced by PC-based Supervisory Control and Data Acquisition Systems (SCADA) using a large color screen to present process pictures showing plant status. Two of the most commonly used SCADA systems are SattGraph from ABB and FIX from Intellution. In large industrial plants, the control function is normally divided into a 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 System (DCS).
28
3BSE 021 358 R201 Rev B
2.6 Communication with Other Systems
Most 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 systems from different manufacturers. All industrial plants have computer-based Management Information Systems (MIS) for handling of statistical and economic information. There is often a need to connect MIS with SCADA and DCS, resulting in a total control and management system. General Motors in the USA has developed a standard called Manufacturing Automation Protocol (MAP) for communication between different programmable controllers and MIS. Unfortunately, the MAP standard has so far not been particularly successful.
3BSE 021 358 R201 Rev B
29
2.6 Communication with Other Systems
30
3BSE 021 358 R201 Rev B
Chapter 3: IEC 61131-3 Standard
3.1 Main Objectives
Chapter 3
IEC 61131-3 Standard

3.1 Main Objectives
IEC 61131-3 is the first, and so far only, global standard for programmable controllers. Considering that programmable controllers have been used in automation systems for more than two decades, it is remarkable that a programming standard has taken so long to evolve. The IEC (International Electrotechnical Commission) working group, with members from all the leading vendors, has, 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 or programs. It should be possible to execute different parts of the application program at different rates. This means that the system must support individual interval times for different POUs. Complex sequential behavior can easily be broken down into events using a concise graphical language. The system must support data structures so that associated data can be transferred between different parts of a program as if they were a single entity.
The system should have parallel support for the five most used languages, Ladder Diagram (LD), Instruction List (IL), Function Block Diagram (FBD), Structured Text (ST) and Sequential Function Chart (SFC). The programming syntax should be vendor independent, resulting in more or less portable code that can easily be transferred between programmable controllers from different vendors.
3BSE 021 358 R201 Rev B
31
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 the development of well-structured software that can be designed either as top down or bottom up software. One of the most important tools in achieving this is function blocks. A function block is part of a control program that has been packaged and named so that it can be reused in other parts of the same program, or even in another program or project. Function blocks can provide any kind of software solution from simple logical conditions, timers or counters, to advanced control functions for a machine or part of a plant. Since the definition of input and output data has to be very precise, a function block can easily be used, even by other programmers than those who developed it. By packaging software into function blocks the internal structure may be hidden so that well-tested parts of an application can be reused without risk of data conflict or malfunction.
Five Languages for Different Needs

The IEC 61131-3 standard supports five of the most commonly used 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 are often many such programs available. These programs can relatively easily be reused in new 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 the defintion of function block types using all the languages.
32
3BSE 021 358 R201 Rev B
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 possible to execute on any other IECcompliant system. This would open up the market dramatically resulting in better standardization, lower prices and also improved software quality. Unfortunately such a high level of software portability may be difficult to achieve in practice. The IEC 61131-3 standard defines many features and only requires that vendors of programmable controllers specify a list of which features their system supports. This means that a system can be compliant with the standard without supporting all features. In practice, portability will therefore be limited, since systems from two different vendors often have different feature lists.
3.3
PLCopen Trade Association
Since the IEC standard has relatively weak compliance requirements, a number of the larger control system companies concerned with software portability have formed the PLCopen Trade Association. PLCopen is a vendor- and product- independent worldwide 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 fairs and by arranging their own conferences. PLCopen has defined three different compliance classes concerning the portability of control system software. The lowest class is Base Level, defining a core kernel of the standard. Although rather restricted, it is feasible to develop applications based on it. Base Level provides an entrance for control system vendors, demonstrating their commitment to the standard.
3BSE 021 358 R201 Rev B
33
3.3 PLCopen Trade Association
Portability Level contains a large set of features including user-defined functions and function blocks. This level also demands that the system has an export/import tool for easy exchange of program code between systems from different manufacturers. The highest level, Full Compliance, provides exchange of complete applications, including configuration information, between different control systems.
34
3BSE 021 358 R201 Rev B
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 metaphors. Since all of these languages have both advantages and disadvantages, it is important to have basic knowledge of the most suitable applications for each language. Although most control systems may be implemented with any one of the five languages the resulting program will be more or less effective, depending on the requirements of the control application.
A1 A3 M1
A2
LDN AND( OR ) ST
A3 A1 A2 M1
LD
A1 M1 := ( A1 OR A2 ) AND NOT A3; A2 A3
IL
1 &
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.
3BSE 021 358 R201 Rev B
35
4.1 Overview
Historically, the five languages have evolved in parallel with the evolution of automation systems. Relay systems documented via LD were dominant in the 1950s. Logical circuits described by FBD were used mostly in the 1960s. PLCs debuted in the 1970s with programming in IL. Computers for process automation were introduced in the 1980s with ST programming in languages like Pascal and C. Improved CPU power in the 1990s finally made it possible to work with graphical languages like SFC. Before the IEC 61131-3 standard was established, most vendors of programmable controllers supported only one or two of the programming languages. By tradition, most American vendors have preferred LD languages while European vendors have chosen FBD or IL languages. The choice between different programming languages is governed by several economical, technical, and cultural factors. Depending on background, programmers often have a preference for a certain language. Programming with IL, LD or FBD is more popular among engineers with experience in automation systems using those programming languages, while ST is the natural choice for engineers with experience using computer systems with programming languages such as Pascal. In small applications with relatively few logical conditions, the demands for good structure and reuse of code are less important than in larger systems. Many older control systems use LD as a direct analogy to systems based on relays and switches. In large plants involving many subprocesses the control function must be divided into an number of program modules with a high level of encapsulation in order to prevent the modules from interfering with each other. Program languages are often characterized by their level of abstraction. A low-level language like IL is very closely coupled to the actual binary codes running the processor in the control systems. Low-level languages normally have a limited number of instructions producing very effective software code but, unfortunately, also totally tailored for a certain brand or model of system. High-level languages, like ST and SFC, do not produce the most effective machine language but, on the other hand, the program may be compiled for many different programmable controllers. When programmable controllers were first introduced in the 1970s, most of the applications were for purely Boolean logical conditions. Today, a control system must handle both digital and analog control, together with timers, counters and sequences.
36
3BSE 021 358 R201 Rev B
4.2 Common Elements
The cost of software development has a tendency to increase exponentially with the size of the application. Since many control functions are used in the same way over and over again it is possible to simplify the application program by using generalized standard modules. Reuse of standard modules is by far the most effective method to reduce costs. When industrial plants are redesigned with new control systems, large parts of the old program code, which have been tested and debugged over several years of intensive use, are often reused. Even the most up-to-date systems, therefore, have to support older and generally less effective languages.
Structure level High
SFC FBD ST IL
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 commonly used techniques for developing new control systems.
4.2
Common Elements
The IEC standard defines a number of common elements which are used in all of the programming languages. This section explains the rules for using identifiers, data types, constants and variables.
Identifiers
Identifiers are used for naming different elements within the IEC language, for example, variables, data types, function blocks and programs. An identifier is a string of letters, digits or underscore symbols which begin with a letter or an underscore. Space characters are not allowed in identifiers. Two or more underscores may not be used together.
3BSE 021 358 R201 Rev B
37
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 keywords based on their position but others may produce confusing results. Programmers comments are delimited at the beginning and end by asterisks (*comment*). Comments can be placed anywhere except in IL language, which has some restrictions.
Data Types
The first PLCs could only handle Boolean data but todays systems are 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 Integer Double integer Real numbers Duration of time Calender time Character string
Keyword
bool int dint real time date_and_time string
Bits
1 16 32 32
In addition to elementary data types, programmers can define their own Structured data types containing several components of data types. Such a data type has no physical correspondence in the plant, but it can be likened to a cable containing a number of leads of different types, e.g. for the transfer of electrical power or telephone and TV signals.
38
3BSE 021 358 R201 Rev B
4.2 Common Elements
All leads are given descriptive names so that the programmer can connect to them without having a detailed knowledge of their function.
PumpType On (boolean) Off (boolean) Level (real) Name (string)
Fig. 13 Example of a structured data type containing several elementary data types.
A new structured data type is declared by delimiting the definition with TYPE and END_TYPE. TYPE PumpType On: boolean Off: boolean Level: real Name: string END_TYPE Each component in a structured data type is identified via the variable name and the component name separated by a point, for example Pump3.On.
Constant Literals
By giving a variable the attribute constant, you prevent it from being changed after it is given its initial value. The initial value is normally specified in the variable declaration. There are two classes of numerical literals: integer and real, where the latter are distinguished from the former by the presence of a decimal point. Real literals may end with an exponent, indicating the integer power of ten by which the preceding number is to be multiplied. Decimal numbers are represented in conventional decimal notation. Numbers to bases other than 10 are represented in base 2, 8 or 16 (prefix 2#, 8# or 16#). Boolean data are represented by the values 0 and 1 or the keywords FALSE and TRUE. Time literals are used either for Duration data or for Time of day. Duration data are prefixed by the keywords TIME# or T# followed by the actual duration in terms of days, hours, minutes, seconds and milliseconds. Time of day literals are prefixed by the keywords TIME_OF_DAY# or TOD#.
3BSE 021 358 R201 Rev B
39
4.2 Common Elements
Variables
Variables is the name given to data elements whose content may change during execution of the application program. A variable may be associated with a realworld input and output, but can also be an internal memory storage. All variables are declared with a unique name and a corresponding data type. This is normally done before the program code is written. A variable must also have an attribute, either retain, constant or a blank field. Retain means that the variable will retain its value when the system restarts. A constant variable will not be changed by the system. Variables with a blank attribute will always be calculated at system restart. If a variable has to start at a specific value, that value has to be specified as Initial value, otherwise it will start at a predefined value depending on its data type (normally 0). The table below shows examples of names and attributes of variables of frequently used data types. Name Pump_1 PhotoCell_4 Duration_Open Event_Notation NumberOfRev Temperature_5 Data type bool bool time constant date_and_time constant dint real constant retain Attributes retain Initial value False False T#3m10s DT#1999-02-0112:30:00.000 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.
40
3BSE 021 358 R201 Rev B
4.3 Ladder Diagrams
4.3
Ladder Diagrams
Ladder Diagrams (LD) have evolved from the electrical wiring diagrams that were used, for example, in the car industry, to describe relay-based control 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, called power rails. The power rails serve as a symbolic electrical power supply for all the contacts and coils that are spread out along horizontal rungs. Each contact represents the state of a Boolean variable, normally a transducer, but sometimes also an internal variable in the control system. When all contacts in a horizontal rung are made, i.e. in the true state, power can flow along the rail and operate the coil on the right of the rung. The coil normally represents physical objects like a motor or a lamp, 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 they are closed. Normally closed contacts present a false state (Boolean variable is 0) when they are open. In analogy with electrical circuits, contacts connected horizontally in series represent logical AND operations. Parallel contacts represent logical OR operations.
switch1 alarm motor
switch2
Normally closed contact Normally open contacts P owe rails r Coil
Fig. 14 Example of a simple ladder diagram with three contacts and a coil.
It is possible to create LD programs that contain feedback loops, where the variable from an output coil is used as an input contact, either in the same or in other logical conditions. In a real-world relay circuit this is equivalent to
3BSE 021 358 R201 Rev B
41
4.3 Ladder Diagrams
using one of the relays physical switches as an input contact. A person with experience in computing would probably call this a memory bit.
start stop fan
fan
Fig. 15 Feedback loop in an LD program. The fan starts with an impulse on contact start and continues to run until the contact stop is opened.
Easy to Understand
Programming with LD can be learnt relatively quickly and the graphical 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.
42
3BSE 021 358 R201 Rev B
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 online diagnostics facility for locating incorrect logic paths or faulty equipment.
Weak Software Structure

Ladder programming is a very effective method for designing small control applications. With increasing processing power and memory size with todays programmable controllers, the method can also be used to construct 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 hierar- chically. The lack of features for passing parameters between program blocks makes it difficult to break down a large program into smaller parts that have a clear interface with each other. Usually, it is possible for one part of a Ladder Diagram to read and set contacts and outputs in any other part of the program, which makes it almost impossible to have truly encapsulated data. This lack of data encapsulation is a serious problem when large programs are written by several different programmers. There is always a danger that 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 in using structured data with ladder programs since data are normally stored and addressed in single memory bits. Many control applications often have a need to group data together as a structure. Some sensors provide more than one variable that has to be recorded by the control system. Apart from the physical value measured by the sensor, the application sometimes needs to disable the sensor, place it in test mode, record the time when the sensor is active and also raise an alarm if the sensor is activated 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 incorrect data are accessed.
3BSE 021 358 R201 Rev B
43
4.3 Ladder Diagrams
Limited Support for Sequences

Most control applications have a need to divide the function into a sequence of states. Each state represents a unique condition in the plant being controlled. Normally, only one state is active at a time. When sequences are constructed with ladder programming the normal method is to assign one internal memory bit to each state and to use contact conditions from the transducers to trigger transitions between the states. Each state consists of a feedback loop using the memory bit as an alternative condition for remaining in the state. The feedback loop of a state is normally broken by the memory bit of a succeeding state. To get real-world actions the memory bits are used as conditions in separate rungs to control the outputs.
state_3 transducer_a state_1
state_1
state_2
state_1
transducer_b
state_2
state_2
state_3
state_2
transducer_c
state_3
state_3 state_1 state_2 state_3
state_1 output_a
output_b
Fig. 17 Sequence program with three states controlling two outputs.
44
3BSE 021 358 R201 Rev B
4.3 Ladder Diagrams
From the above example it is obvious that ladder programs with sequences can become very large and difficult to maintain. The most obvious problem is that control of the memory-based sequence model is mixed with the application logic so the behavior of the complete program is difficult to understand and follow.
Difficult to Reuse Code

In many large control systems similar logic strategies and algorithms are used over and over again. A common application is to detect fire by using two or more transducers with a comparison algorithm to eliminate false alarms. Such systems consist of a large number of similar ladder rungs with only minor modifications to read different contacts and to set different outputs. This can result in very large, unstructured programs. Unfortunately, very few programmable controllers have an option for defining standardized ladder blocks that can easily be called upon many times with different inputs and outputs.
3BSE 021 358 R201 Rev B
45
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 microprocessors. IL has been chosen as the preferred language by a number of PLC manufacturers for their small to medium-sized systems. The lack of structured variables and weak debugging tools make the language less suitable for larger systems.
IL Language Structure
IL is a language with a series of instructions, each on a new line. An instruction consists of an operator followed by an operand. The operator tells the system what to do, while the operand identifies which variable is to be processed. Some operators can process more than one operand, in which case, the operators should be separated by commas. IL programs are often written on a spreadsheet-like form with one column for operators and another for operands. Labels, used to identifying entry points for jump instructions, are placed in their own column to the left of the instruction. All labels should end with a colon. The instructions only need to have labels if the program contain jumps. Comments are placed in a fourth column to the right of the operand. Comments are enclosed by asterisks (*comment*). It is strongly advisable to add comments to all instructions during programming. Large IL programs without comments are very difficult to follow.
Label
Operator LD GT JMPCN LD ADD JMP
Operand temp1 temp2 Greater speed1 200 End speed2
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*)
Greater:
LD
Fig. 18 Example of an IL program for controlling the speed of a motor.
To improve readability, IL instructions are normally structured so that labels, operators, operands and comments are put in fixed tabulated positions.
46
3BSE 021 358 R201 Rev B
A characteristic of IL programs is that instructions always relate to an internal register, called the result register, RR, IL register or accumulator. Most operations consist of 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, which loads the accumulator with a variable. The result register changes its data type automatically during program execution in order to fit the value that needs to be stored. Programmable controllers normally only have one result register. This must naturally be taken into consideration by the programmer when writing code. The program example in Fig. 18 on page 46 first loads the RR with a real 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 called motor controlling the speed of the motor.
IL Instruction Set
The IEC has developed a standardized instruction repertoire by examining the many low-level languages offered by different vendors. The IL language, as defined in IEC 61131-3, is a selection of the most commonly used instructions in current programmable controllers. Each instruction is written as an 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 Operand
LDN AND( ) switch1 switch2 switch3 (*RR := NOT switch1 AND (switch2 OR switch3)*)
Comment
(*Load inverse of switch1*) (*Boolean AND with the following two operations*) OR
Fig. 19 Example of operator modifiers in an IL program.
3BSE 021 358 R201 Rev B
47
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 left-hand parenthesis indicates that the evaluation of the following instructions must be delayed until the righthand parenthesis is encountered. Operator LD ST S R AND OR XOR ADD SUB MUL DIV GT GE EQ LE LT NE ) CAL JMP RET
Fig. 20 The IL instruction set.
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 than or equal to Comparison equal Comparison less than Comparison less than or equal to Comparison not equal Executes delayed operation Calls a function block Jumps to label Returns from called function
N, ( N, ( N, ( ( ( ( ( ( ( ( ( ( ( C, N C, N C, N
48
3BSE 021 358 R201 Rev B
Best System Performance

IL is ideal for solving small straightforward 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 a period of several years a huge amount of software has been written and thoroughly tested. Such software can be modularized into libraries and reused even by programmers with no detailed knowledge of the internal behavior.
Weak Software Structure

Since IL is a low-level language, great care should be taken in structuring the code so that it is easy to understand and maintain. It is very important that IL programs are well documented since conditional jumps will otherwise be very difficult to follow. The behavior of the result register, with only one value available at a time, makes it difficult to work with structured data variables. Most compilers have no automatic function for checking whether the RR contains correct data for the actual instruction code. Therefore, it is up to the programmer to ensure that each instruction is given correct variable data.
Machine-dependent Behavior
Of all the five IEC languages, IL has been found to be the most controversial. Unfortunately, the semantics, i.e. the way in which the instructions operate, are not fully defined in the standard. For example, it is unclear how the result 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 obtain consistent behavior when working with arrays or strings. Another problem is that the control system behavior for error conditions is not defined. This means that different system types may respond differently if the programmer uses inappropriate data types. Errors can normally only be detected when the system is running the application.
3BSE 021 358 R201 Rev B
49
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 many conditional statements and calculations.
Statements
All ST programs contain a list of statements, each ending with a semicolon separator. Statements contain expressions which, when evaluated, result in a value of a variable having any kind of data type. Expressions are composed of operators and operands. The ST language supports five different types of statements: assignment statement, variable := expression; selection statements, IF, THEN, ELSE, CASE iteration statements, FOR, WHILE, REPEAT function and function block control statements control statements, RETURN, EXIT
The language statements can be written in a fairly free style with spaces, tabs, line feeds and comments inserted anywhere between operators and operands, i.e. where a space is needed for separation. An expression can be short, for example a literal constant, or very complex involving many other nested operations. The assigned variable can be either simple or structured containing any number of elementary data types. motor := (start or motor) and not stop; speed3 := temp1*temp2 - 5*value7; IF speed3 < 0 THEN tank_level := 25.8; ELSE tank_level := 30.6; END_IF;
Fig. 21 Example of a simple ST program.
Statement text should be written in a structured way. The computer will accept any number of spaces in a statement but it is good practice to place statements at a fixed position according to their role in the hierarchy.
50
3BSE 021 358 R201 Rev B
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 precedence 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
Precedence
Highest priority
Lowest priority
Conditional Statements
Often there is a need to execute certain statements repeatedly, 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 executions is known. count := 0; FOR i:=1 TO 10 DO count := count + i; END_FOR; The variable count starts with the value 0 and increases by 1 for each time the addition is repeated until the final value 10 is reached.
3BSE 021 358 R201 Rev B
51
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 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_I F; If A and B have different values the highest value will be given to both, else both of the variables will be set to zero. When using conditional statements it is very important to avoid infinite loops. All statements must therefore include a condition that can be fulfilled.
52
3BSE 021 358 R201 Rev B
4.5 Structured Text
Calling Function Blocks

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

The ST language has an extensive range of constructs for assigning values to variables, calling function blocks and creating conditional expressions. This is very useful for evaluating complex mathematical algorithms, commonly used in analog control applications. No other IEC language can match the power of ST when iterations are needed, i.e. when certain parts of the program code are to be repeated a fixed or a 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 with a higher learning threshold than the LD or IL languages. On the whole, ST is fairly easy to learn and a very effective tool for developing control applications. The language is a good general purpose tool for 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 to describe the step actions in sequences.
3BSE 021 358 R201 Rev B
53
4.6 Function Block Diagram
4.6
Function Block Diagram
Function Block Diagram (FBD) is a graphic language in which the control function is divided into a number of function blocks or functions connected by flow signals. A function block may contain simple logical conditions, timers or counters, but can also provide a complex control function to a subprocess in a machine or even an industrial plant.
In1 In2 In3 Time1 PT
&
IN
TON
Out1
ET
Out2
Fig. 22 Example of an FBD program with two logical function blocks and a timer block.
Syntax for Function Block Diagrams

Each function block is drawn as a rectangle with inputs entering from the left and outputs exiting on the right. All function blocks have a built-in algorithm for calculating output values based on the status of the inputs. The function block type name is normally shown within the block. For some of the most common logical functions a standardized Boolean symbol may be used instead of type names. The formal names of input and output parameters are also shown within the block, close to the corresponding signal. In an FBD program the normal signal flow is from the left to the right. Input signals to function blocks may either come from transducer signals, from local variables or from other function block outputs. Signal names are normally shown at the corresponding connecting lines. When working with Boolean signals, negated inputs or outputs can be shown using a small circle placed at the corresponding line, close to the block symbol. Some systems use a NOT function block instead of the circle.
54
3BSE 021 358 R201 Rev B
Function block type
AND
IN
TON
Q ET
Negation symbol
PT
Input parameters
Output parameters
Fig. 23 Some fundamental rules for drawing function block diagrams.
Standard Function Block Types

The IEC 61131-3 standard defines a small repertoire of rudimentary standard function block types. These are predefined in most of todays programmable controllers. Standard function blocks are often used to construct user-defined function blocks. The most commonly used blocks are: Boolean conditions like AND, OR, XOR and NOT Bistables Edge detectors Counters
Timers
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.
3BSE 021 358 R201 Rev B
55
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 functions below.
Edge Detectors
There are two edge-detecting function blocks, Rising edge trigger (R_TRIG) and Falling edge trigger (F_TRIG), which are used to detect the changing state of a Boolean input. The output of the blocks produces a single pulse when a transition edge is detected. When the input changes state, according to the type of edge detector, the 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.
56
3BSE 021 358 R201 Rev B
Timers
Timers are among the most used function blocks in a control application. Whenever there is a need for a time delay between a change of state and the corresponding action a timer can be used. In most programmable control systems the timing is based on 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 called IN, a Boolean output called Q, an input of type time called PT and an output of type time called ET. The required delay (or pulse width) is specified on input PT (Preset Time) while the actual elapsed time is shown on output ET (Elapsed Time). A pulse timer is normally used to generate output pulses of a specified 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 linearly as long as the pulse output is true. When the pulse terminates, the elapsed time is held until the input changes to false. Note that the output Q will remain true until the pulse time has elapsed, even if the input changes to false. Both delay timers are used to delay an output action by the specified time PT when a certain condition becomes true. The on-delay timer delays the activation of an output. When the input IN becomes true the elapsed time at output ET starts to increase. If the elapsed time reaches the value specified in PT, the output Q becomes true and the elapsed time is held. The output Q remains true until input IN becomes false. If input IN is not true longer than the specified delay in PT, the output remains false. The off-delay timer delays the deactivation of an output. When the input IN becomes false, the elapsed time starts to increase and continues until it reaches the specified delay given by PT. The output Q is then set to false and the elapsed time is frozen. When input IN becomes true the output Q follows and the elapsed time is reset to zero.
3BSE 021 358 R201 Rev B
57
Pulse timer IN PT IN
PT PT
On-delay timer Q ET TON IN Q PT ET
Off-delay timer TOF IN PT Q ET
TP
IN
PT PT
IN
PT PT
Q T E
Q ET
Q ET
Fig. 26 Timing diagrams for the three different types of timer function blocks.
Counters
Counters are another commonly used type of function block. These are designed to be used in a wide range of applications, for example counting pulses, revolutions, completed production batches, etc. There are three types of counter blocks, up-counters (CTUs), down-counters (CTDs) and up-down counters (CTUDs). CTUs are used to indicate when the counter has reached a specified maximum value. CTDs indicate when the counter reaches zero, on counting down from a specified value. CTUDs can be used to both count up and count down and have two outputs indicating both maximum value and zero. A CTU has three inputs and two outputs. A CTU block counts the number of pulses (rising edges) detected at the Boolean input CU. The input PV (Preset Value) of data type integer defines the maximum value of the counter. Each time a new rising edge occurs on CU the output CV (Counter Value) of type integer is incremented by one. When the counter reaches the value specified in PV, the Boolean output Q becomes true and counting stops. If necessary, the Boolean input R (reset) can be used to set the output Q to false and to clear CV to zero.
58
3BSE 021 358 R201 Rev B
Up counter bool bool int R PV CV int

CV=0
CTU CU Q
CU bool Q R
CV=PV
CV Fig. 27 Example of a CTU counter block with preset value PV=5.
The CTD is very similar to CTU with three inputs and two outputs. A CTD counts down the number of pulses detected at the Boolean input CD. The input PV is used to specify the starting (integer) value of the counter. Each time a new rising edge occurs on CD the output CV is incremented by one. When the counter reaches zero, the output Q becomes true and counting stops. If necessary, the Boolean input LD (load) can be used to clear the output Q to false and to load the output CV with the value specified in PV.
Down counter bool bool int LD PV CV int CV Fig. 28 Example of a CTD counter block with preset value PV=5. CTD CD Q CD bool 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. Similarly 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 the output CV to zero.
3BSE 021 358 R201 Rev B
59
Up-down counter bool bool bool bool int CD R LD PV CTUD CU QU QD CV CU bool bool int CD QU QD LD R
CV=PV CV=PV CV=0
CV Fig. 29 Example of a CTUD counter block with preset value PV=3.
The CTUD is often used in applications where there is a need to monitor the actual number of items in a process. It could, for example, be used to count the number of products placed on and taken off a store shelf.
Similar to Electrical Diagrams

In many ways, a function block can be compared to an integrated circuit (IC), the building block of 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 analog control systems, for example PID controllers, use closed-loop control where some output signals are fed back and used as inputs in the control algorithm. The FBD program gives a good overview of signal flow in systems with feedback.
60
3BSE 021 358 R201 Rev B
Not Suitable for Conditional Statements

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

1 IEC61131 Lenguajes Escencial MB

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

1 IEC61131 Lenguajes Escencial MB

Caricato da

Copyright:

Formati disponibili

ControlIT

IEC 61131 Control Languages

3BSE 021 358 R201 Rev B

1.4 1.5 1.6

Why Open Systems are Needed

IEC 61131-3 Standard

3BSE 021 358 R201 Rev B

3BSE 021 358 R201 Rev B

Industrial Application Example

3BSE 021 358 R201 Rev B

3BSE 021 358 R201 Rev B

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

3BSE 021 358 R201 Rev B

Chapter 1: Evolution of Control Systems

3BSE 021 358 R201 Rev B

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.

3BSE 021 358 R201 Rev B

1.4 Relay Logic

Chapter 1: Evolution of Control Systems

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

3BSE 021 358 R201 Rev B

Chapter 1: Evolution of Control Systems

1.5 Computers for Process Control

Computers for Process Control

3BSE 021 358 R201 Rev B

1.5 Computers for Process Control

Chapter 1: Evolution of Control Systems

3BSE 021 358 R201 Rev B

Chapter 1: Evolution of Control Systems

1.5 Computers for Process Control

3BSE 021 358 R201 Rev B

1.5 Computers for Process Control

Chapter 1: Evolution of Control Systems

3BSE 021 358 R201 Rev B

Chapter 1: Evolution of Control Systems

1.6 Programmable Controllers

I/O unit Input modules Output modules

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

3BSE 021 358 R201 Rev B

1.6 Programmable Controllers

Chapter 1: Evolution of Control Systems

3BSE 021 358 R201 Rev B

Chapter 1: Evolution of Control Systems

1.6 Programmable Controllers

Computer-based Programming Tools

3BSE 021 358 R201 Rev B

1.6 Programmable Controllers

Chapter 1: Evolution of Control Systems

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

3BSE 021 358 R201 Rev B

Chapter 1: Evolution of Control Systems

1.6 Programmable Controllers

3BSE 021 358 R201 Rev B

1.6 Programmable Controllers