89,99 €
Widely used across industrial and manufacturing automation, Programmable Logic Controllers (PLCs) perform a broad range of electromechanical tasks with multiple input and output arrangements, designed specifically to cope in severe environmental conditions such as automotive and chemical plants.
Programmable Logic Controllers: A Practical Approach using CoDeSys is a hands-on guide to rapidly gain proficiency in the development and operation of PLCs based on the IEC 61131-3 standard. Using the freely-available* software tool CoDeSys, which is widely used in industrial design automation projects, the author takes a highly practical approach to PLC design using real-world examples. The design tool, CoDeSys, also features a built in simulator/soft PLC enabling the reader to undertake exercises and test the examples.
Key features:
No prior knowledge of programming PLCs is assumed making this text ideally suited to electronics engineering students pursuing a career in electronic design automation. Experienced PLC users in all fields of manufacturing will discover new possibilities and gain useful tips for more efficient and structured programming.
* Register at www.codesys.com
www.wiley.com/go/hanssen/logiccontrollers
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 579
Veröffentlichungsjahr: 2015
Cover
Title Page
Programmable Logic Controllers
Preface
Part One: Hardware
1 About PLCs
1.1 History
1.2 Structure
1.3 PLC Operation
1.4 Test Problems
2 Digital Signals and Digital Inputs and Outputs
2.1 Introduction
2.2 Terminology
2.3 Switches
2.4 Logical Sensors
2.5 Connection of Logical Sensors
2.6 Properties of Discrete Inputs
2.7 Discrete Actuators
2.8 Test Problems
3 Analog Signals and Analog I/O
3.1 Introduction
3.2 Digitalization of Analog Signals
3.3 Analog Instrumentation
3.4 Temperature Sensors
3.5 Connection
3.6 Properties of Analog Input Modules
3.7 Analog Output Modules and Standard Signal Formats
3.8 Test Problems
Part Two : Methodic
4 Structured Design
4.1 Introduction
4.2 Number Systems
4.3 Digital Logic
4.4 Boolean Design
4.5 Sequential Design
4.6 State-Based Design
4.7 Summary
4.8 Test Problems
Part Three: IEC 61131-3
5 Introduction to Programming and IEC 61131-3
5.1 Introduction
5.2 Brief Presentation of the Languages
5.3 Program Structure in IEC 61131-3
5.4 Program Processing
5.5 Test Problems
6 IEC 61131-3: Common Language Elements
6.1 Introduction
6.2 Identifiers, Keywords, and Comments
6.3 About Variables and Data Types
6.4 Pragmas and Literals
6.5 Data Types
6.6 Variables
6.7 Direct Addressing
6.8 Variable versus I/O-Addresses
6.9 Declaration of Multielement Variables
6.10 Test Problems
7 Functions
7.1 Introduction
7.2 On Functions
7.3 Standard Functions
7.4 Boolean Operations
7.5 Arithmetic Functions
7.6 Comparison
7.7 Numerical Operations
7.8 Selection
7.9 Type Conversion
7.10 Bit-String Functions
7.11 Text-String Functions
7.12 Defining New Functions
7.13 EN/ENO
7.14 Test Problems
8 Function Blocks
8.1 Introduction
8.2 Declaring and Calling FBs
8.3 FBs for Flank Detection
8.4 Bistable Elements
8.5 Timers
8.6 Counters
8.7 Defining New FBs
8.8 Programs
8.9 Test Problems
Part Four: Programming
9 Ladder Diagram (LD)
9.1 Introduction
9.2 Program Structure
9.3 Boolean Operations
9.4 Rules for Execution
9.5 Use of Standard Functions in LD
9.6 Development and Use of FBs in LD
9.7 Structured Programming in LD
9.8 Summary
9.9 Test Problems
10 Function Block Diagram (FBD)
10.1 Introduction
10.2 Program Structure
10.3 Execution Order and Loops
10.4 User-Defined Functions and FBs
10.5 Integer Division
10.6 Sequential Programming with FBD
10.7 Test Problems
11 Structured Text (ST)
11.1 Introduction
11.2 ST in General
11.3 Standard Functions and Operators
11.4 Calling FBs
11.5 IF Statements
11.6 CASE Statements
11.7 ST Code Based upon State Diagrams
11.8 Loops
11.9 Example: Defining and Calling Functions
11.10 Test Problems
12 Sequential Function Chart (SFC)
12.1 Introduction
12.2 Structure and Graphics
12.3 Steps
12.4 Transitions
12.5 Actions
12.6 Control of Diagram Execution
12.7 Good Design Technique
12.8 Test Problems
Problem 12.5 Mixing Process
13 Examples
13.1 Example 1: PID Controller Function Block: Structured Text
13.2 Example 2: Sampling: SFC
13.3 Example 3: Product Control: SFC
13.4 Example 4: Automatic Feeder: ST/SFC/FBD
Part Five: Implementation
14 CODESYS 2.3
14.1 Introduction
14.2 Starting the Program
14.3 Configuring the (WAGO) PLC
14.4 Communications with the PLC
14.5 Libraries
14.6 Defining a POU
14.7 Programming in FBD/LD
14.8 Configuring Tasks
14.9 Downloading and Testing Programs
14.10 Global Variables and Special Data Types
15 CODESYS Version 3.5
15.1 Starting a New Project
15.2 Programming and Programming Units (POUs)
15.3 Compiling and Running the Project
15.4 Test Problems
Bibliography
Index
End User License Agreement
Chapter 03
Table 3.1 Characteristics of the three types of thermocouple
Chapter 04
Table 4.1 Examples of decimal, binary, and hexadecimal numbers
Table 4.2 Binary-coded decimal numbers
Table 4.3 Overview of recommended symbols for use in flowcharts
Table 4.4 Example of state table
Chapter 06
Table 6.1 Integers and floating-point numbers
Table 6.2 Bit-string data types
Table 6.3 Time and duration
Table 6.4 Data types for text
Table 6.5 Formatting coder for printout and display
Table 6.6 Addressing and organization of memory in Omron C200H
Table 6.7 Addressing structure for direct representation of data elements
Table 6.8 Syntax for assigning new values to arrays
Chapter 07
Table 7.1 Standard functions—an overview
Table 7.2 Boolean operations
Table 7.3 Standard arithmetic functions
Table 7.4 Functions and operators for comparison
Table 7.5 Numerical functions
Table 7.6 Functions for selection
Table 7.7 Bit-string functions
Table 7.8 Standard text-string functions
Chapter 08
Table 8.1 Characteristic parameters for an up-counter
Table 8.2 Characteristic parameters for a down-counter
Chapter 09
Table 9.1 Symbols that are used in LD
Chapter 10
Table 10.1 Fan speed as a function of temperature
Chapter 12
Table 12.1 Possible graphical symbols in SFC
Table 12.2 SFC action types
Table 12.3 Implicit SFC variables defined in CODESYS
Chapter 13
Table 13.1 Shows when various tanks are fed, plus quantity, and type of food given
Chapter 01
Figure 1.1 Example of a relay and a timer (mounted on a connector board)
Figure 1.2 Omron Sysmac C20—Nonmodular PLC with digital I/O and programming terminal
Figure 1.3 PLCs from Telemecanique come in different sizes
Figure 1.4 Newer generation PLC from Wago
with Profibus coupler and I/O
Figure 1.5 Block schematic representation of a PLC
Figure 1.6 Typical memory board
Figure 1.7 Illustration of a process section that is controlled by a PLC
Figure 1.8 Principle of an optical coupler
Figure 1.9 Principle of a relay output
Figure 1.10 Principle of a transistor output
Figure 1.11 Operations that are performed in RUN mode
Chapter 02
Figure 2.1 Illustration of a discrete signal
Figure 2.2 Digital signal
Figure 2.3 Common terminology
Figure 2.4 Illustration of sensor with built-in converter (Pepperl+Fuchs.)
Figure 2.5 The terminology that will be used in this book
Figure 2.6 Various switches
Figure 2.7 Limit switches in many variants (Telemecanique)
Figure 2.8 Some safety devices
Figure 2.9 Principle of operation and an example of a reed switch
Figure 2.10 Inductive detector—principle
Figure 2.11 Inductive sensors
Figure 2.12 Examples of use of inductive sensors
Figure 2.13 Principle of capacitive sensors with built-in ground electrode
Figure 2.14 Principle of a capacitive sensor for conductive materials
Figure 2.15 Examples of capacitive proximity detectors
Figure 2.16 (a) Transmitting type, (b) reflecting type, (c) retroreflecting type
Figure 2.17 Optical fiber combined with photocells
Figure 2.18 Photocells (Pepperl + Fuchs)
Figure 2.19 Principle of an ultrasonic sensor
Figure 2.20 Ultrasonic sensors
Figure 2.21 Principle of encoder with one row of holes
Figure 2.22 Pulse train on channels A, B, and 0 for an incremental encoder
Figure 2.23 Principle of an absolute encoder
Figure 2.24 Bit pattern reading a Gray-coded disk with five hole tracks
Figure 2.25 Angular measurement based on a potentiometer
Figure 2.26 Tachometer based on induction
Figure 2.27 Contents of an electronic tag
Figure 2.28 RFID system with tag and reader connected to a PLC
Figure 2.29 Tags of various types (Telemecanique)
Figure 2.30 Switch connected to input one- and three-wire sensor connected to input 5
Figure 2.31 Connecting sensors to a discrete module
Figure 2.32 Sink-connected input module
Figure 2.33 Source-connected input module
Figure 2.34 NPN output requires source-connected PLC input
Figure 2.35 PNP output requires sink-connected PLC input
Figure 2.36 Principle of a relay and example of a small relay
Figure 2.37 Solid-state relay with electronic schematic
Figure 2.38 A solenoid in deactivated and activated position
Figure 2.39 A solenoid for industrial applications
Figure 2.40 Example of magnetic valve (GSR Ventiltechnik GmbH & Co.)
Figure 2.41 Source-connected transistor output
Figure 2.42 Sink-connected transistor output
Figure 2.43 Connection of load to relay output
Figure 2.44 Connection of load to relay output—opposite polarity
Chapter 03
Figure 3.1 Typical operations in a signal-processing system: digitizing, processing, and reconstruction
Figure 3.2 Example of measurement signal that contains noise
Figure 3.3 The frequency response to a first- and a second-order low-pass filter
Figure 3.4 Principle for A/D conversion
Figure 3.5 Illustration of sampling
Figure 3.6 Original analog signal and the discrete signal
y
(
k
)
Figure 3.7 The signal before and after the “sample and hold” circuit
Figure 3.8 Example of quantification
Figure 3.9 Principle of the thermocouple
Figure 3.10 An industrial model of the PT100
Figure 3.11 Simple sensor—PT100 (thin-film RTD)
Figure 3.12 Connecting sensors
Figure 3.13 Example of various connections to the TSX AEZ 414 module
Figure 3.14 PT100 connected in two-wire connection
Figure 3.15 PT100 connected in a four-wire connection
Figure 3.16 Three PT100 sensors connected to the same module
Figure 3.17 PT100 connected in a three-wire connection. (
Note
: Modern modules designed for three-wire measurement can compensate automatically for the conductor loss.)
Figure 3.18 Conversion from analog signal to whole-number value
Chapter 04
Figure 4.1 Integrated circuit (IC)
Figure 4.2 Pin configuration for SN7408N
Figure 4.3 One-bit adder
Figure 4.4 Implementation of circuit (possible FBD code) for level monitoring
Figure 4.5 Implementation of functional expression
Figure 4.6 Example of flowchart
Figure 4.7 Mixing process
Figure 4.8 Flowchart for the mixing process
Figure 4.9 Automated packaging line
Figure 4.10 Flowchart for automatic packaging line
Figure 4.11 Flowchart for wash operation
Figure 4.12 Illustration of the use of macro-steps
Figure 4.13 Examples of sequence diagrams
Figure 4.14 (a) System, (b) Sequence diagram
Figure 4.15 Sequence diagram for Example 4.21
Figure 4.16 Sequence diagram for the mixing process
Figure 4.17 Batch process
Figure 4.18 Sequence diagram for the batch process
Figure 4.19 Example of a generic state diagram
Figure 4.20 State diagram for a packaging facility
Figure 4.21 State diagram for the mixing process on page
Figure 4.22 State diagram at a macro level
Figure 4.23 State diagram for the batch process. Actions that are to be performed in the steps are written as (*comments*). The transitions are written in ST code
Figure 4.24 Fluid tank with pumps
Figure 4.25 State diagram for the level process
Figure 4.26 Alternative extra state
Figure 4.27 Production line—packing of apples
Figure 4.28 State diagram, apple packing, alternative 1
Figure 4.29 State diagram, apple packing, alternative 2
Figure 4.30
Figure 4.31
Figure 4.32 Sorting products
Figure 4.33 Filling station
Chapter 05
Figure 5.1 Arithmetic operations in LD (Omron C200H)
Figure 5.2 Example of code in FBD
Figure 5.3 Example of program code in LD
Figure 5.4 Example of SFC
Figure 5.5 Configuration elements and general program structure in IEC 61131-3
Figure 5.6 Example of configuration
Figure 5.7 The cycle of program development
Figure 5.8 Example of editor
Figure 5.9 Example of editor
Chapter 06
Figure 6.1 Illustration of overlapping between bit, byte, word, and double word
Figure 6.2 Illustration—address overlapping
Chapter 08
Figure 8.1 Function blocks for flank detection
Figure 8.2 Diagram for the input and output signals of the block
Figure 8.3 Bistable elements
Figure 8.4 Standard Timer
Figure 8.5 Illustration of the difference between the various modes of timer
Figure 8.6 Graphic symbol for an up-counter
Figure 8.7 Graphic symbol for a down-counter
Figure 8.8 Graphic symbol for an up/down-counter
Figure 8.9 Graphic symbol for the PID function block
Chapter 09
Figure 9.1 The structure in a LD
Figure 9.2 Example of code in LD
Figure 9.3 Standard contact symbols
Figure 9.4 Standard coil symbols
Figure 9.5 A simple program
Figure 9.6 Implementation of AND-condition
Figure 9.7 Implementation of an OR-condition
Figure 9.8 Implementation of an Exclusive OR
Figure 9.9 Possible implementation of a retention function
Figure 9.10 Implementation of a retention function with the use of Set and Reset
Figure 9.11 Use of the function block R_TRIG and the Set/Reset coils
Figure 9.12 Use of a type SR/RS function block in LD
Figure 9.13 Operation of the flank-detecting contacts
Figure 9.14 Mixing process
Figure 9.15 Sequence diagram for the mixing process
Figure 9.16 Evaluation order of a rung
Figure 9.17 Example of commenting, labels, and jumps
Figure 9.18 A function with EN input
Figure 9.19 Use of EN blocks with FBD symbol
Figure 9.20 Integration of functions by use of a text-based block
Figure 9.21 Program example with use of timer
Figure 9.22 Self-developed FB
Figure 9.23 Program-friendly flowchart for the mixing process
Figure 9.24 Controlling states
Figure 9.25 Program code based on the state flags
Figure 9.26 From flowchart to LD code
Figure 9.27 Use of memories in state-based LD code
Figure 9.28 Complete program code in LD for control of the washing process
Figure 9.29 From state diagram to LD code
Figure 9.30 LD code for the Batch process
Figure 9.31 LD code for the level process
Chapter 10
Figure 10.1 Example of code in FBD
Figure 10.2 Implementation of an XOR with AND and OR
Figure 10.3 Summary of concepts
Figure 10.4 Example of jump to a label (Fill) with return
Figure 10.5 Illustration of the function’s operation
Chapter 11
Figure 11.1 Example of ST code
Figure 11.2 Example of untidy code
Figure 11.3 A state diagram with general designations
Figure 11.4 Distribution of goods in a packaging facility
Chapter 12
Figure 12.1 Figurative description of a sequence process in SFC
Figure 12.2 Example of SFC
Figure 12.3 SFC with alternative sequences (CODESYS v3.x)
Figure 12.4 Parallel sequence (CODESYS v3.x)
Figure 12.5 Sequence for the packaging facility, with added transition conditions
Figure 12.6 Transition programmed in FBD
Figure 12.7 Example of action
Figure 12.8 All action types, except for P1 and P0, are executed one extra time
Figure 12.9 Specification of associated time for a time-dependent action
Figure 12.10 Use of different action types (in CODESYS v3.x)
Figure 12.11 SFC sequence with actions that are called up
Figure 12.12 Example of wrong design
Figure 12.13 Example of risky design
Figure 12.14 Test rig for hull resistance measurement
Figure 12.15 Mixing process—Problems 12.2 and 12.3
Figure 12.16 Mixing facilities in Problem 12.5
Chapter 13
Figure 13.1 Facility for taking samples
Figure 13.2 Product monitoring and sorting
Figure 13.3 Sketch of facility with feeding robot, transport rail, and some of the tanks
Figure 13.4 State diagram for robot control
Chapter 14
Figure 14.1 Starting a new project
Figure 14.2 Specifying the Target with settings
Figure 14.3 Defining a new POU
Figure 14.4 Main elements, menus, and windows
Figure 14.5 Alternative choices for the module 750-565 (an RTD module)
Figure 14.6 Configuration of WAGO PLCs
Figure 14.7 The configuration window
Figure 14.8 Example of a configuration
Figure 14.9 Screen capture from WAGO IO-Check
Figure 14.10 Configuring communications parameters
Figure 14.11 Configuration of the gateway server
Figure 14.12 Specification of Com port
Figure 14.13 Specification of IP address
Figure 14.14 Search for the PLC’s IP address in WAGO Ethernet Settings
Figure 14.15 Analysis of addresses and tests of (digital) I/O
Figure 14.16 Default library in a new project
Figure 14.17 Defining a new POU
Figure 14.18 Input Assistant (F2)
Figure 14.19 Our FB implemented in LD
Figure 14.20 Code for calling our FBs
Figure 14.21 Defining a new task
Figure 14.22 Test of program
Figure 14.23 Online manipulation of PT values to a timer
Chapter 15
Figure 15.1 Start-up window
Figure 15.2 Defining a new project
Figure 15.3 Units
Figure 15.4 Library management
Figure 15.5 Task configuration
Figure 15.6 Objects that can be added
Figure 15.7 Adding a new POU
Figure 15.8 The POU window
Figure 15.9 Larger extract from CODESYS that also shows a program editor
Figure 15.10 Auto-declaration window
Figure 15.11 Compiling and building menu
Figure 15.12 The message window with errors and warnings
Figure 15.13 A successful build
Figure 15.14 The communication settings window
Figure 15.15 Scanning the network and choosing target
Cover
Table of Contents
Begin Reading
iii
iv
xiv
xv
xiii
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
79
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
309
308
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
351
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
Dag H. Hanssen
Institute of Engineering and Safety, University of Tromsø, Norway
Translated byDan Lufkin
This edition first published 2015© 2015 John Wiley & Sons, Ltd
Registered OfficeJohn Wiley & Sons, Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom
For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com.
The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. It is sold on the understanding that the publisher is not engaged in rendering professional services and neither the publisher nor the author shall be liable for damages arising herefrom. If professional advice or other expert assistance is required, the services of a competent professional should be sought.
Authorised Translation from the Norwegian language edition published by Akademika forlag, Programmerbare Logiske Styringer – basert på IEC 61131-3, 4. Utgave. This translation has been published with the financial support of NORLA.
Library of Congress Cataloging-in-Publication Data
Hanssen, Dag Håkon, author. Programmable Logic Controllers: A Practical Approach to IEC 61131-3 using CODESYS / Dag Hakon Hanssen. pages cm Includes bibliographical references and index.
ISBN 978-1-118-94924-5 (pbk.)1. Sequence controllers, Programmable. 2. Programmable logic devices. I. Title. TJ223.P76H36 2015 621.39′5–dc23
2015018742
A catalogue record for this book is available from the British Library.
Dag H. Hanssen
As long as there have been competing producers of PLCs on the market, there have been different programming languages from one PLC brand to another. Even though the same languages, beginning with Instruction Lists (IL) and Ladder diagram (LD), have been used by most of the producers, all of them added their own “dialects” to the languages. When physical programming terminals replaced software-based programming tools, the differences between languages of the various producers escalated. Several programming languages also saw the light of day. This development was the natural result of the attempt by the producers to make themselves stand out among increasing competition by developing the most user-friendly languages and tools.
When the IEC1 61131-3 standard came out in 1993, the situation started to improve. This standard was the result of the work that had been ongoing for several years in which the best from the various languages and dialects from different producers was assembled into a single document. This is not a rigid standard in the sense that the producers must follow all requirements and specifications, but more a set of guidelines that the producers could choose to follow to a certain extent. Today, most of the equipment producers have come to realize the advantages of organizing themselves in accordance with the standard. All of the major producers of PLCs, such as Telemecanique, Wago, Mitsubishi, Klockner Moeller, Allen-Bradley, Omron, Siemens, and so on, have therefore, to a greater or lesser extent, adapted their programming tools to IEC 61131-3.
This book covers close to 100% of the specifications and guidelines that are given in Standard (International Electrotechnical Commission, 2013).2 The book will therefore be interested to everyone who works with, or wants to learn about programming PLCs, no matter which PLC brand they use.
The book does not assume any previous knowledge of programming.
Comments and suggestions for contents will be gratefully received.
The book is divided into five main parts:
Part 1: Hardware
Chapters 1
–
3
Part 2: Methodic
Chapter 4
Part 3: IEC 61131-3
Chapters 5
–
8
Part 4: Programming
Chapters 9
–
13
Part 5: Implementation
Chapters 14
–
15
Chapter 1 contains a brief history and a short description of the design and operation of PLCs in general. Chapters 2 and 3 give a basic introduction to digital and analog signals and equipment for detection, measurement, and manipulation of discrete and continuous quantities.
Chapter 4 focuses on methods for planning and design of structurally efficient programs. It also provides an introduction into Boolean algebra. Chapters 5 and 6 introduce the IEC standard elements such as literals, keywords, data types, variables, and addressing. Chapters 7 and 8 cover standardized functions and functional blocks.
Chapters 9 to 13 deal with programming: Chapter 9 covers programming with LD. Chapter 10 covers functional block diagrams (FBD). Chapter 11 covers the structured text (ST) language. The last language covered in the book is actually not a programming language as such, but rather a tool for structuring program code. This is called a Sequential Function Chart (SFC) and is described in Chapter 12.
Chapter 13 contains some larger practical programming examples.
The last two chapters in the book cover programming tools. Here, I have chosen to focus on CODESYS. There are several reasons for this; first, CODESYS follows the standard almost 100%. Furthermore, CODESYS is a hardware-independent programming tool that is currently used by well over 250 hardware suppliers. Finally yet importantly, the program can be downloaded free and it contains a simulator. Most of the program code in the book was written and tested with this tool.
I would like to thank the following persons and companies:
Associate Professor Tormod Drengstig, University of Stavanger, for much good feedback, suggestions for improvements, and the contribution of several examples
Assistant Professor Inge Vivås, Bergen University College, for giving his permission to reuse some problems (Section 4.6.4 and Problems 4.10 and 10.5)
Assistant Professor Veslemøy Tyssø, Oslo and Akershus University College of Applied Science, for having read an earlier edition of the book and having provided expert contributions
Colleagues and management at the University of Tromsø, Department of Engineering and Safety, for the support and patience
Schneider Electric for granting me permission to use material from their “Automation Solution Guide” when writing about sensors in
Chapter 2
Dag H. Hanssen
1
IEC—International Electrotechnical Commission. This edition of the book was updated in conformity with the 3rd edition of IEC 61131-3, issued February 2013.
2
The Standard IEC 61131-3 is introduced in
Chapter 5
.
The programmable logic controller (PLC) has its origin in relay-based control systems, also called hard-wired logic.1
Before PLCs became common in industry, all automatic control was handled by circuits composed of relays,2 switches, clocks and counters, etc (Figure 1.1). Such controls required a lot of wiring and usually filled large cabinets full of electromagnetic relays. Electricians had to assemble controls or use a prepared relay wiring diagram. The relay wiring diagrams showed how all the switches, sensors, motors, valves, relays, etc. were connected. Such relay wiring diagrams are the forerunners for the ladder diagram (LD) programming language, which is still a common programming language used in programming PLCs.
Figure 1.1 Example of a relay and a timer (mounted on a connector board)
There were many disadvantages with these mechanical controls. In addition to taking up a lot of room, they demand time and labor to implement them and to make any changes in such equipment. A relay control usually consists of hundreds of relays connected together with wires running in every direction. If the logical function needs to be changed or expanded, the entire physical unit must be rewired, something that is obviously expensive in terms of working time. Since the relays are electromechanical devices, they also had a limited service life, something that led to frequent operational interruptions with subsequent disruption.
There also was no way of testing before the control was wired up. Testing therefore had to take place by running the unit. If there was a small failure in the schematic diagram or if an electrician had connected a wire wrong, this could result in dramatic events.
The first PLC came into commercial production when General Motors was looking for a replacement for relay controls. Increased competition and expanded demands on the part of customers meant a demand for higher efficiency, and the natural step was to design a software-based system that could replace the relays. The requirement was that the new system should be able to:
Compete on price with traditional relay controls
Be flexible
Withstand a harsh environment
Be modular with respect to the number of inputs and outputs
3
Be easy to program and reprogram
Several corporations started work on providing a solution to the problem. Bedford Associates, Inc. from Bedford, Massachusetts, suggested something they called a “modular digital controller” (MODICON). MODICON 0844 was the first PLC that went into commercial production. The key to its success was probably the programming language, LD, which was based on the relay diagrams that electricians were familiar with. Today there is no question about the use of programmable controls; the question is rather what type to use.
The first PLCs were relatively simple in the sense that their function was to replace relay logic and nothing else. Gradually, the capabilities improved more and more and functions such as counters and time delays were added. The next step in development was analog input/output and arithmetic functions such as comparators and adders.
With the development of semiconductor technology and integrated circuits, programmable controls became widely used in industry. Particularly when microprocessors came on the market in the beginning of the 1970s, development proceeded at a rapid pace.
The PLCs of today come with development tools in the form of software with every imaginable ready-to-use function. Examples are program codes for managing communications as well as processing functions such as proportional integrator/derivative regulators, servo controls, axial control, etc. In other words, there is the same pace of development as with the PC (Figures 1.2, 1.3, and 1.4).
Figure 1.2 Omron Sysmac C20—Nonmodular PLC with digital I/O and programming terminal
Figure 1.3 PLCs from Telemecanique come in different sizes
Figure 1.4 Newer generation PLC from Wago with Profibus coupler and I/O
The communications side also experienced rapid development. Demand grew quickly for PLCs that could talk to one another and that could be placed away from the actual production lines. Around 1973 Modicon developed a communications protocol that they called Modbus. This made it possible to set up communications between PLCs, and the PLCs could therefore be located away from production. Modicon’s Modbus also provided for management of analog signals. As there became more and more manufacturers of PLCs and associated equipment, there also developed more proprietary5 and nonproprietary communications protocols. The lack of standardization, together with continual technological development, meant that PLC communication became a nightmare of incompatible protocols and various physical networks. Even today, there are problems, although manufacturers now offer solutions for communications over a selection of known and standardized protocols.
Several programming languages also came into use. Earlier LD, as we mentioned, was synonymous with PLC programming. Instruction List (IL) was also an early language that had many similarities with the assembly language that used for programming microprocessors. Later the graphical language Sequential Function Chart (SFC) was added. This was specially developed for implementation of sequential controls.
All of the aforementioned languages were incorporated into the international standard IEC 61131-3 (International Electrotechnical Commission, 2013). The standard also defines the function block diagram (FBD) graphic language and the structured text (ST) language. FBD has a symbol palette that is based on recognized symbols and functions from digital technology. ST is a high-level language that provides associations with Pascal and C.
Before the IEC 61131-3 standard appeared, and for many years thereafter, there were relatively large differences between PLCs from various manufacturers. This was particularly true of capabilities for selection of programming language and how the language that was implemented in the PLCs was designed. Recently, to the delight of users, manufacturers began to follow IEC 61131-3 to a greater and greater extent. This made it easier to go from one brand of PLC to another as well as making it easier, to a certain extent, for customers to know what they were getting.
There are also a number of “software-based PLCs” on the market. As the name indicates, this software is designed to control processes directly from a PC. The challenge has been to build systems that are sufficiently reliable and robust. Industry is generally critical of such solutions, mostly based on experience with many a computer crash.
Another amphibious solution is the possibility of buying a circuit board for a computer onto which the program code can be loaded. The board is made so that it is capable of carrying on with the job independently even if the computer should crash.
In recent years, manufacturers have devoted considerable resources to developing solutions for connecting instruments and actuators into a network. Such a communication bus is called a fieldbus, referring to the fact that there is communication between field instruments, in other words, instruments below the process level. Other standards and de facto6 standards are also on the market.
Work on an IEC standard for the fieldbus started as early as 1984/1985. The requirement was naturally that the standard should be an open fieldbus solution for industrial automation. It should include units such as motor controls, decentralized I/O, and PLCs, in addition to the distributed control systems (DCS) and field instruments used in the processing industry. The goal was also that the standard should cover all pertinent areas such as building automation, process automation, and general industrial automation.
It was not until the end of 1999 that those involved came to an agreement. The result was that a total of eight (partially dissimilar) systems were incorporated into a standard called IEC 61158. In other words, this was not an open solution. Even though manufacturers and suppliers argued that it was good for users to have plenty of choices, this unity did not make things much easier for engineers and others working on automation.
Several of the major manufacturers currently offer integrated solutions with I/O modules for all of the major fieldbus standards where a controller (PLC) or a gateway manages communication among the various standards simultaneously.
Another trend is that manufacturers of hardware and communication solutions offer more equipment for wireless communication (Ethernet). What is new here is that these also include individual sensors and individual instruments. In this way, it is possible to implement wireless systems right out to the sensor level.
As we said, there are a great many types of PLCs on the market. Hundreds of suppliers include PLCs of various sizes in their stock. The smallest PLCs have relatively small memory capacity and calculating capability and usually limited or no capability for expansion of the number of I/Os. The largest have processor power equivalent to powerful computers, have a large number of I/Os, and handle multitasking.7 Such PLCs usually have a supervisory function (master) in an industrial data network where smaller PLC types can be incorporated as slaves.
If we make a simplification, we can say that a PLC functions in the same way that a computer does. Schematically, we can break a PLC down into six major units as shown in Figure 1.5.
Figure 1.5 Block schematic representation of a PLC
The main parts thus consist of a central processing unit (CPU), memory, power supply, circuit modules to receive and transmit data (I/O units), and communications modules. We can perhaps also add displays/indicator lights since most of the PLCs incorporate LEDs that indicate the state of the PLC and/or the digital I/Os. Some also have displays that can furnish other information. In order for us to understand how a PLC operates and functions, it is necessary to look a little closer at the main components.
The main units are connected together with wires or copper strips called buses. All communications between the main parts of the PLC take place via these buses. A bus is a collection of a number of wires, for instance, eight, where information is transferred in binary form (one bit per wire in parallel). Typically, a PLC will have four buses: address bus, data bus, control bus, and system bus:
The data bus is used for transfer of data between the CPU, memory, and I/O.
The address bus is used to transfer the memory addresses from which data will be fetched or to which data will be sent. An address can indicate, for instance, a location down to a word in a particular register. A 16-line address bus can thus transfer 2
16
= 65 536 different addresses.
The control bus is used for synchronizing and controlling traffic circuits.
The system bus is used for I/O communication.
This is the brain of the PLC. Here are performed all of the instructions and calculations, and it controls the flow of information and how the program operates. Normally the CPU is a part of the physical block and contains the memory, communications ports, status indicator lights, and sometimes the power supply.
The size of the memory varies from one brand of PLC to another, but the memory can often be expanded by installing an extra memory card, for instance an SD card. A PLC will commonly have the following memory units:
Read-only memory (ROM) for permanent storage of operating system and system data. Since the information stored in a ROM cannot be deleted, an erasable programmable ROM (EPROM) is used for this purpose. In this way, it is possible to update a PLC operating system.
Random access memory (RAM) for storage of programs. This is because a RAM is very fast. Since the information in a RAM cannot be maintained without current, PLCs have a battery so that the program code will not be lost in the event of a power failure. Some PLCs also have the capability of program storage in an EPROM. RAMs are also used when the program code is running. This is used, for instance, for I/O values and the states of timers and counters.
Some PLCs offer the capability of inserting extra memory.
Figure 1.6 shows a typical memory board for a PLC that has an EPROM for a backup copy of the program.
Figure 1.6 Typical memory board
This unit incorporates one or more protocols for handling communications. All PLCs have a connection for a programming cable and often for an operator panel, printer, or network. Various physical standards are used, for both the programming port and for the ports for connections to other equipment. Current PLCs are usually programmed from an ordinary PC with a programming tool developed for that particular type of PLC.
It is not always necessary to have a direct connection between the PLC and the PC in order to transfer the program code to the PLC. However, it is currently the most common approach—at least for smaller systems. Sometimes, the programming can be performed via a network consisting of several PLCs and other equipment or via Ethernet. Some PLCs also have a built-in web server.
The development of instrumentation buses has enabled PLC manufacturers to supply built-in, or modular, solutions for communications via a large number of various protocols. Examples of such are the AS-i bus, PROFIBUS, Modbus, and CANbus.
Current developments are toward expanded use of Ethernet as a protocol for high-speed communications. Most manufacturers are offering solutions for this.
All PLCs must be connected to a power supply. Usually the power supply is an interchangeable module, but some smaller PLCs have the power supply as an integrated part of the processor and communications module. Even though the electronics in the PLC operate at 5 V, it is impractical to use this as an operating voltage. Most manufacturers therefore provide power supplies in several versions: 220 V AC, 120 V AC, and 24 V DC. If there is no access to power-line voltage, a variant with 24 V DC can be the solution. Usually there is access to 24 V out in the facility since this voltage level is standard for most sensors and transmitters. The advantage of being able to use a power supply that connects to the power line is that there is often a 24V output on the unit that can be used for powering sensors.
It is practical to have the power supply as a replaceable module. Then the PLC can be used in other physical locations in processing where there is not access to the same voltage level.
This is the contact between a PLC and the outside world. In a modular PLC, all inputs and outputs take place in blocks or modules that are designed to receive various types of signals and to transmit signals in various formats. There are input blocks for digital signals, analog signals, thermal elements and thermocouples, encoders, etc. There are also output blocks for digital and analog signals as well as blocks for special purposes.
Every input and output has a unique address that can be utilized in the program code. The I/O modules take care of electric isolation to protect the PLC and often have built-in functions for signal processing. This means that input and output signals can be connected directly without needing to use any extra electronic circuitry.
Chapter 2 deals with digital signals, sensors, and actuators, in Chapter 3 the theme is analog signals, and standard signal formats. On the next few pages, there follows only a general introduction to the inputs and outputs of a PLC.
Figure 1.7 on the next page shows a sketch of a process section that is controlled by a PLC. Various signal cables are drawn in the figure for the sake of illustration.
Figure 1.7 Illustration of a process section that is controlled by a PLC
The process is equipped with three pressure transmitters and one flow transmitter. These constitute the input signals to the PLC in the figure.
Based on these measurements, among others, the PLC is programmed to control two pumps. The signals to the pumps thus constitute the output signals from the PLC.
The figure also shows an example of how a PLC rack can be assembled. From left to right, we see the following:
The controller itself (CPU, memory, status lights, etc.) with built-in Ethernet (the unit in this case also has a built-in web server).
A power supply (can supply sensors and other small equipment).
I/O-modules (digital outputs, tele-modules, analog inputs and outputs).
End modules that terminate the internal communications bus.
Digital input signals generally have a potential of 24 V DC, while the internal voltage in the PLC is 5 V. In order to protect the electronics in the PLC, the input modules generally use optical couplers (optical isolators). An optical coupler consists primarily of a light-emitting diode (LED) and a phototransistor.8Figure 1.8 illustrates the principle.
Figure 1.8 Principle of an optical coupler
The diode and the transistor are electronically separated, but light can pass between them. When the signal at the input clamping circuit is logically high, the LED will emit an (infrared) light. This light then triggers the transistor and results in a logically high signal in the electronic circuits in the module, where the potential is 5 V.
The gap between the LED and the phototransistor separates the external circuit from the internal electronics in the module. The internal electronics are thereby protected so that even though the PLC operates at 5 V internally, it is possible to use voltage levels at the input from 5 up to 230 V.
How much current an individual input can handle depends upon the engineering specifications of the input module in question. However, it is seldom that this is significant because most sensors have a low operating current.
Analog signals are fed into a PLC via analog-to-digital (A/D) converters. Converters are built into the analog input modules/cards. An analog signal is thus continually sampled and converted into binary values. Although in principle this requires only 1 bit for a low state input, often 16 bits are used to store values to an analog input.
Standard digital output modules are often found in three different main types:
Relay outputs
Transistor outputs
Triac outputs
This type of output has the advantage that it can handle heavy loads and can be connected to both DC and AC loads at different voltages. When the CPU sets an output logically high, the associated output relay in the module in question closes and the external circuit to which the load is connected is completed (see Figure 1.9). The relay makes it possible for weak currents in the PLC to activate loads in which currents up to several Amperes can pass. In addition, the relay provides isolation between the PLC and external circuits.
Figure 1.9 Principle of a relay output
Compared to transistor outputs, relay outputs are relatively slow. Another advantage that makes transistor outputs popular is that they are cheaper than relay output modules. As the name indicates, such modules use transistors to complete the external circuits. It is this electronic switching that makes such modules significantly faster than relay modules, which switch with mechanical relays.9 The disadvantage of transistor outputs is that, unless one uses an additional external relay, they can only be used for switching DC. They also cannot handle wrong polarity and are particularly sensitive to overload. Fuses with built-in electronics are therefore used in order to protect these outputs. Optical couplers are also used for electrical isolation (see Figure 1.10).
Figure 1.10 Principle of a transistor output
The operation of the circuit in the figure is as follows: When the output address is set logically high by the program, the phototransistor conducts. This triggers the next transistor and this completes the external circuit. Series connection of transistors (often called Darlington circuits) is used to increase the current capacity of the output stage.
You can read more about relay and transistor outputs in Section 2.7.3.
Triac outputs are not very common. They are used in situations that require fast switching of AC. Such outputs are also extremely sensitive to overcurrent and are protected with fuses.
As discussed earlier, a PLC operates, in principle, in the same way as a PC. This means that a PLC must be programmed in order for it to perform its tasks. For a PLC, this usually means controlling and monitoring a process. This somewhat diffuse concept is used as a generalized word to describe a limited physical environment:
A process can for instance be a room in a building with heating ovens, light, and ventilation. Then it can be the task of the PLC to control physical quantities such as temperature, CO
2
content, and humidity in the space.
A process can also consist of a conveyor belt with goods, sensors, pneumatic pistons, and a labeling machine. The task of a PLC would then typically be to control labeling of goods, count goods, sort them, and group them.
The word state is often used to describe the various operating modes of a process. What states a process has depends on the nature of the process (process type). A process can have, for instance, the following states: Fill tank—agitate—heat—Drain.
The word state can also be used more specifically, for instance, for a temperature that has reached a certain value.
It is also the nature of the process that dictates what sensors and actuators are needed. Physical quantities that must be sensed can be distance, proximity, level, pressure, temperature, flow, velocity, rpm, etc. When the sensors that sense the physical quantities are connected to a PLC input module, the PLC has all of the information that is required in order to control and monitor the process. What is missing then are actuators and a user program.
The function of actuators is to operate upon and change the states of the process. The type of process therefore determines what activators are required. These can be pumps, valves, switches, or motors.
The user program employs available information from sensors, internally stored data, and the state of outputs to make decisions and calculate new output signals to the actuators.
In almost all cases, there exist dedicated data tools for development of programs. Users can sit in the office and work on program code until they are sure that it is going to function in the PLC. Many of these programming tools have built-in functions for error detection and simulation, something that makes the job significantly simpler. When the user has finished programming, the PLC can be connected to the PC via a dedicated programming cable, and the program can be transferred from the PC to the PLC. When this has been done, the PC can be disconnected and the PLC is ready to perform its control tasks.
Before a PLC can be programmed, it is necessary to have good knowledge about the process (the part of the facility) that the PLC is going to control. Good understanding of the process is important in order to obtain good results, and sometimes it is necessary in order to get the control to function at all. This can be a time-consuming part of the job and often implies access to the understanding that operating personnel are familiar with. Remember that no one knows a process better than the people do whose daily job it is to make it work. Having said this, remember that operating personnel often have strong opinions about the process and how it should function and be controlled and that this is not necessarily the optimum way of doing things. It can be difficult to think in a new direction and to see other possibilities when things have been done in the same way for a long time.
Try to obtain available documentation such as engineering data, wiring diagrams, reporting forms, troubleshooting guides, maintenance SOPs, and the like.
An I/O-list is a basic part of choosing the correct PLC and the right accessories. The I/O list must therefore contain an overview of all of the required input and output signals. It is natural to group these by type, such as digital and analog. The analog can be further grouped according to standard signal formats, such as 4–20 mA, 0–10 V, type of temperature sensor, etc. Sometimes, the special signal formats impose extra requirements on hardware.
The digital signals can also be grouped. For instance, there are counter inputs and integral counter modules that measure pulses with higher frequencies than a normal digital input can tackle. An example of such a rapidly changing signal is a signal from an encoder,10 which is a type of equipment that can be used for counting rpm and positional control.
Should the input blocks be of the sink or source11 type? The type of actuator affects the selection of the proper type of output blocks: Should you use relay outputs or transistor outputs? How should the various actuators be supplied?
In addition to the flow of the process, desired performance and requirement for sensors, actuators, and I/O modules, it is also necessary to evaluate other aspects in and around the operation:
Safety of personnel
Any danger of fire or explosion
Provision of alarms
This is a comprehensive theme that I am only going to touch on here. There are naturally laws and regulations concerning safety and I merely refer to those. At a minimum, you can try to describe what should happen in the event of a power failure, communications breakdown, activation of stops and emergency stops, etc.
Safety for humans and animals is something that must be taken extremely seriously. For instance, if a person is caught in a drive mechanism, then the actuator in question must be deactivated and an alarm sounded, at a minimum. In a power failure, you must decide whether the control should start again from where it stopped when the power failure happened, or whether it should be started anew. The same is true of a communications breakdown. There should be built-in monitoring of communications between the PLC and the HMI/SCADA12/operator panel so that the control is not cut off from manual override.
Almost all process facilities will also have one or more emergency stops, motor monitors, and the like. How to handle such events must also be described for later programming.
This also applies to switching over between automatic and manual control in a regulator, even though this is not so critical. This is often a natural portion of the process control.
Even though it is important to provide alarms in order to indicate when something has happened, it often turns out that an operator is drowning in alarms. Make a careful evaluation of which signals need to be specially monitored, what breakdowns must be handled by the PLC, and what the human–machine interface should handle, for instance.
The provision of alarms and safety will be significant considerations in how the program is organized (split up and grouped into critical and less-critical sections of programming).
In order to simplify the programming, even at this stage it can be useful to formulate something about the flow in the process. It is easy to identify the flow when processes proceed from one state to the next in a particular order (e.g., filling—heating—agitating—draining).
Sometimes, several things happen simultaneously, or in parallel, and sometimes manual activities or process-controlled events decide what should be the next step in the sequence. It is often good to describe these sequences in words and/or by the use of a flow chart, state diagram, or the like. Which signals and events affect the transition from one step to the next in sequence? How should the various steps be performed? Which actuators should be activated and when should they be activated?
Sometimes, the process to be controlled is of such a nature that the transition from one state to another does not follow a predetermined pattern, but rather proceeds in a more random pattern. Such systems are referred to as combinatoric (despite the fact that the output states may well be a function of time as well). For such systems, it may be advantageous to use a slightly different procedure to develop the algorithms for control. There are methods that can be used to determine these algorithms in a systematic way and one of these will be described in Chapter 4.
A process is in continual change. Even though the process has approached a stationary state, for instance, the fluid level in the tank has reached 80%, there will be disturbances in the form of pressure-drop in tubing, changed withdrawal of fluid and the like, that require that the PLC continually monitor the state of the input signals and correct the output signals. All PLCs in normal operation13 therefore perform the same four operations14 in a repeating cycle (Figure 1.11):
Internal processing
Read inputs
Program execution
Update outputs
Figure 1.11 Operations that are performed in RUN mode
A PLC always checks its own state before it performs user-related operations. If a response from hardware such as I/O or communications modules is lacking, the PLC gives notice of this by setting one or more flags. A flag is an internal Boolean address that can be checked by the user and/or an associated display or indicator light that gives a notification to the operator of an error state. For serious errors, normal operation is interrupted and the system goes over into an error state. Errors on individual inputs and individual outputs are also reported by setting flags. An example is when a system measures 0 current at an input configured for standard 4–20 mA signal or when an output is overloaded.
Software-related events that are performed in the internal operation are updating clocks, changing modes between run, stop, and program and setting watchdog15 times to zero, among others.
In this operation, input status is copied over to memory. How long this takes depends on the number of input modules and the number of inputs at each module that is in use. Analog inputs take significantly longer to read since this involves digitization of the analog values. In order not to reduce the update frequency of outputs, the PLC does not wait for new values to be available, but rather continues with the next operation in the cycle. This means that even though the physical values change continually, the same measured value can be used many times before an updated value is accessible in the memory.
Why copy the values to memory instead of reading the values where they are used in the program code? There are two reasons for this. First, it is quicker to read in all the values in the
