CANopen Implementation:

applications to industrial networks

Mohammad Farsi and

Manuel Bernardo Martins Barbosa

RESEARCH STUDIES PRESS LTD.

Baldock, Hertfordshire, England
RESEARCH STUDIES PRESS LTD.
15/16 Coach House Cloisters, 10 Hitchin Street, Baldock, Hertfordshire, England, SG7 6AE

and

325 Chestnut Street, Philadelphia, PA 19106

Copyright © 2000, by Research Studies Press Ltd.

All rights reserved.
Any part of this book may be reproduced by any means, or transmitted, or translated into
a machine language without the written permission of the publisher.

Marketing:
Research Studies Press Ltd.
15/16 Coach House Cloisters, 10 Hitchin Street, Baidock, Hertfordshire, England, SG7
6AE

Distribution:
NORTH AMERICA
Taylor & Francis Inc.
47 Runway Road, Suite G, Levittown, PA 19057 - 4700, USA
ASIA-PACIFIC
Hemisphere Publication Services
Golden Wheel Building, 41 Kallang Pudding Road #04-03, Singapore
EUROPE & REST OF THE WORLD
John Wiley & Sons Ltd.
Shripney Road, Bognor Regis, West Sussex, England, PO22 9SA

Library of Congress Cataloging-in-Publication Data

Farsi, Mohammad, 1940-
CANopen implementation : applications to industrial networks /
Mohammad Farsi and Manuel Bernardo Martins Barbosa.
p. cm. - - (Industrial control, computers, and Communications
series ; 18)
Includes bibliographical references.
ISBN 0-86380-247-8 (hc.)
1. Process control - - Automation. 2. Controller AreaNetwork
(Computer network) 3. Computer network protocols. I. Barbosa,
Manuel Bernardo Martins, 1973 - II. Title. III. Series.
TS156.8.F38 1999
670.42'75--dc21
99-31145
CIP

British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library.

ISBN 0 86380 247 8

Printed in Great Britain by SRP Ltd., Exeter

Editorial Preface
We entered the 20th Century with an Industrial Economy and we leave it with a
Knowledge Based Economy (KBE).

The sustaining technology that has enabled our KBE economy to develop and
expand is based on the ubiquitous silicon chip and the consequent “digitalisation” of
data, which has provided a mechanism that allows Computation, Communication and
Control to be integrated into a seamless process.

We began the last decade of the 20th Century with an emerging conceptual model of
a PC (personal computer) on every desk. Th etechnology was driven by 16 bit
microprocessors operating around 25MHz, with a Disk Operating System (DOS). The
World Wide Web had not been invented, telephones were largely analogue and
restricted to “physical” connections.

The last ten years have seen the rapid growth in chip manufacturing capacity that
now enables manufacturers to offer everyone the computing capacity of what was once
called a “Super Computer”, only 15 years ago, for the price of a family holiday on the
“Algarve”, for example.

But the key to the infrastructure that will sustain the Knowledge Based Economy of
the 21st Century is the digital communication or NETWORKING facility that now,
increasingly, underpins our modern lifestyle. The Network now transforms “Islands of
Computation” into a seamless computing tool that provides both a central platform for
Industrial and Commercial applications, and a service for the general public to use. A
measure of the rapid integration of networking in our daily lives can be found, for
example, on the “Bill Boards”, that consistently provide WWW addresses, that invite
the general public to visit their “virtual” shopping of “facilities” site. Major retail chains
now provide customers with “free” NET access, for good commercial reasons, let me
quickly add.

The speed of this change is truly overwhelming. We are all having to "run fast" to
"stand still" and the "need to know" is of paramount importance. This book presents
detailed and specialist knowledge of a particular network instantiation that has gained
rapid acceptance in the Industrial domain as a technology that can sustain the needs of
the Manufacturing Industry and a range of consumer products, of which a car is an
example.

For Engineers who are working in the Automation and Control Industries a
knowledge and understanding of CAN Network is not only desirable it is ESSENTIAL,
because it is part and parcel of the modern industrial infrastructure.

In welcoming this book to the series it epitomizes the conceptual model that
stimulated the series: the recognition that the Integration of Computing, Contfol and
Communication would provide the infrastructure for the world economy in the 21st
Century, and that the Books in this series would address the component parts of that 21st
Century Infrastructure.

This Book presents a very important component of that 21st Century Infrastructure.
My congratulations and thanks to the Authors for the clarity and detail of their
presentation.

Derek Wilson
University of Southern Queensland, Australia
March 2000
CANopen is a success story...
What started as a public funded project, was adopted, enhanced and matured by
mainly small and medium sized companies under the roof of the international user and
manufacturer association "CAN in Automation" (CiA). Not being dominated by any of
the major global players, CANopen had the chance to gain flexibility and the features
needed for applications beyond standard industrial automation. CANopen caters for
both centralized and distributed control architectures, for fast real time communication
as well as for parameter up- and download. It is scalable, preserves all CAN features
and runs on almost any type of micro-controller. Thus CANopen meanwhile is not only
the world de-facto standard for interoperable CAN based automation solutions, but for
all sorts of embedded communication tasks as well. Consequently CANopen was
accepted for international standardisation.

Today we find CANopen networks not only in various industrial applications

ranging from printing machines and robots to process controls, but also in ships,
building automation, trains, trucks and even in coffee machines. CANopen is used for
high accuracy drive synchronisation and for flight data recording. It was chosen as
standard communication protocol for medical applications and for passenger
information systems in public transport.

The CANopen success was always driven by technology, not by marketing. This
book explains CANopen technology, its implementation and its application. In doing so,
it will contribute in the typical CANopen way to the CANopen success story.

Martin Rostan Nuremberg, February 2000

Chairman Interest Group CANopen
CAN in Automation e.V.
Acknowledgements
The authors would like to thank the Department of Electrical Engineering of the
University of Newcastle where they had the opportunity to carry out the work that made
the writing of this book possible.

In particular the authors wish to acknowledge the valuable contribution of Mr Karl

Ratcliff who has assisted Dr M Farsi, as a Research Associate, in preparation of the
material presented in this book.

The authors are also grateful to Mr Richard McLaughlin, from the Open Device
Vendor Association (ODVA), for reviewing the book and for his valuable suggestions
and contributions.

While participating in the writing of this book Manuel Barbosa was the recipiënt of
the BD/13641/97 scholarship from the Fundacao para a Ciência e Tecnologia, Programa
PRAXIS XXI ( Portugal).
Preface
CANopen Implementation: Applications to Industfial Networks is intended to be a
reference book both for field engineers who are interested in implementing CAN and
CANopen in their devices and for students specialising in Automation and Control
Engineering. Modern networking applies to all branches of engineering courses and
sustains new industrial infrastructures.
In recent times the introduction of computers into the manufacturing workplace, in
the form of Information Technology (IT) in general and automation in particular, has
revolutionised the way in which the manufacturing industry operates. This applies to the
general organisation and procedures adopted by the manufacturing industry as well as to
specific methods and techniques of manufacture. The advantages of these changes come
in different forms.
One of the most important improvements made possible through the use of
Information Technology is the replacement of workers in dangerous environments with
lower cost machines. Other advantages may involve immediate savings, decreasing
production costs by reducing waste, reducing processing time, reducing the number of
defective products, lower failure rates and better quality products. Therefore, the reader
should never lose sight of why the technology is used. It is not for love of technology,
or the desire to use the latest ideas, but because the application of technology brings
commercial advantages.
This book will describe the application of computer technology and communication
technology as it relates to the shop floor in the automation arena. In particular, this book
will describe this relationship at the 'work cell' level and below, and how the use of
decentralised or distributed control application can affect and improve the design and
performance of manufacturing systems.
The field of automation and control is constantly expanding with the introduction of
innovative techniques, particularly with the advent of lower cost and higher power
information technology tools. Therefore, training in the fields of communication
systems, intelligent manufacturing, production units and distributed control systems
environments is essential to maintain a successful and competitive manufacturing
industry. A steering group created by the Department of Trade and Industry for the
technology foresight programme in the UK (white paper 1993) has acknowledged this
fact. This group has identified 'the harnessing of technologies in sensors and
automation', to improve the production services, as one of the top priority strategie
themes. This is also emphasised as a key area by the sector panel on manufacturing,
production and business processes. The work of the panel provides strong indication
that sensor and control technology will become even more important in the future.
Therefore, the market for expertise in these areas is very wide at the regional, national
and even international levels.
Communication in a factory environment consists of different networking levels
ranging from the network inside a machine to the network running around the shop
floor, the design room and subsequently management and finance at the corporate level
where worldwide communication may be involved. Moreover, it is certain that the
Internet will be widely used by companies to exchange information at the highest level.
In fact the 21st century may see the advance of a factory completely remotely controlled
over the Internet from one central site elsewhere in the world. However, this may only
be made possible if an efficiënt and reliable communication system is employed.
The advent of new manufacturing philosophies is placing new strains on
manufacturers, forcing them to modernise their enterprises and apply novel
technologies. For example, if a manufacturer operates a Just-In-Time system (JIT), it
will require smaller order sizes but a very reliable supply of components and raw
materials from its various suppliers. The impact of this is that if a large manufacturer
decides to implement JIT technology there is a knock-on effect to its suppliers. They,
too, may need to adopt JIT practices, as may their suppliers in turn. So once a major
manufacturer has decided to change its working methods its suppliers must also adapt if
they wish to keep their customers. The implementation of such manufacturing strategies
requires a degree of flexibility and adaptability that can only be achieved by applying
innovative techniques.
Within the manufacturing process itself the emphasis is on the speed of response of
the system. This enables the manufacturing system to cope with changes in customer
orders and requirements, scheduling of work to make full use of the system, etc. If
several different products are manufactured, this may require different processing times
at different sites within the factory to ensure a balanced flow of work through the
system, avoiding bottle-necks and large queues of work waiting to be processed, or
alternatively machines lying idle with no work to process. The manufacturing system
must be able to cope with all the various demands and priorities that are required of it;
in a word it must be flexible.
The use of distributed systems is one of the new techniques that is gaining
increasing popularity in the manufacturing arena, at the shop-floor level. Fieldbuses are
at the heart of these distributed systems as they are used to interconnect the different
intelligent devices that comprise the systems. As one of these fieldbuses, the Controller
Area Network (CAN) has gained extensive popularity, leading to the appearance of a
wide range of CAN hardware products on the market.
CANopen is a fieldbus protocol based on CAN, designed to be 'future-proof, and
provides a flexible and powerful open industrial communication solution with many
attractive features. CANopen is one of the fieldbus protocols currently available on the
market and is already being used widely in the manufacturing industry. It has been
developed by the European Community and is supported by large manufacturers such as
Bosch, Siemens and Philips. It is hoped that CANopen will gain further momentum,
becoming one of the most important fieldbus protocols in the world.
The reasons for the authors writing this book are threefold. Firstly it is to provide the
readers with the basic knowledge and understanding of fieldbus technology without
covering in detail the theoretical aspects, which are not necessary for field engineers to
implement fieldbuses in their products. Secondly, CAN and CANopen have been
chosen because they are one of the most prominent fieldbus systems on the market. The
market evaluation made by the CAN in Autornation group (CiA) shows that the use of
CAN in most of European passenger cars and the decision by truck and off-road vehicle
manufacturers to adopt CAN technology guarantee the availability of CAN chips for
more than ten years. Other high-volume markets such as domestic appliances and
industrial control also increase the CAN sales figures. In fact, the CiA World Wide Web
site indicates that up to March 1999 more than 150 million CAN nodes had been
installed worldwide (CiA web site, October 1999). Thirdly, to the best of the authors'
knowledge there is no textbook available on the market that describes CAN and
CANopen simply, enabling readers to enjoy reading and understanding the technology.
More specifïcally, as a guide for those wishing to implement CAN and CANopen in
their products, the book is an excellent support. The authors have also been encouraged
by many field engineers to write the book because without thorough explanation of
CANopen Device and Communication Profiles, implementations are time consuming
and expensive.
Contents
CHAPTER 1 INTRODUCTION.................................................................................... 1
1.1 BACKGROUND ................................................................................................... 1
1.1.1 The Factory as a Control System ................................................................... 2
1.1.2 Just In Time.................................................................................................... 3
1.1.3 Communication in a Factory Environment .................................................... 3
1.1.4 Typical Production Control Components ...................................................... 4
1.1.5 Flexible Manufacturing Systems ................................................................... 5
1.2 THE ISO/OSI REFERENCE MODEL.................................................................. 7
1.2.1 The General Framework Of The OSI Reference Model................................ 7
1.2.2 Application Layer ........................................................................................ 10
1.2.3 Presentation Layer........................................................................................ 10
1.2.4 Session Layer ............................................................................................... 10
1.2.5 Transport Layer............................................................................................ 11
1.2.6 Network Layer ............................................................................................. 11
1.2.7 Data Link Layer ........................................................................................... 11
1.2.8 The Physical Layer....................................................................................... 12
1.2.9 Layer Management & Control ..................................................................... 13
1.3 NETWORKING AND ITS BENEFITS .............................................................. 13
1.4 BASIC NETWORKING CONCEPTS ................................................................ 14
1.4.1 Data Transmission........................................................................................ 14
1.4.2 Data Synchronisation ................................................................................... 17
1.4.2.1 Asynchronous Sampling....................................................................... 18
1.4.2.2 Synchronous Sampling......................................................................... 18
1.4.3 Networking Topologies................................................................................ 20
1.4.4 Frame Concept ............................................................................................. 21
1.4.5 Medium Access Control............................................................................... 22
1.4.5.1 Poll/Select............................................................................................. 22
1.4.5.2 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) 24
1.4.5.3 Token Ring and Token Bus MAC........................................................ 24
1.4.5.4 Slotted Ring.......................................................................................... 25
1.4.6 Error Checking Mechanisms........................................................................ 26
1.4.6.1 Checksum ............................................................................................. 26
1.4.6.2 Parity Check ......................................................................................... 26
1.4.6.3 Cyclic Redundancy Check ................................................................... 28
1.4.7 Network Operational Models....................................................................... 29
1.4.7.1 Master/Slave Networks ........................................................................ 30
1.4.7.2 Peer-to-Peer .......................................................................................... 30
1.4.7.3 Producer/Consumer Model................................................................... 31
1.4.8 Network Performance .................................................................................. 32
1.5 NETWORK SELECTION CRITERIA ............................................................... 34
1.6 CONCLUSIONS ................................................................................................. 36
CHAPTER 2 CAN: CONTROLLER AREA NETWORK........................................ 38
2.1 INTRODUCTION ............................................................................................... 38
2.2 CAN PHYSICAL LAYER .................................................................................. 40
2.2.1 Bit Timing Configuration............................................................................. 41
 2.2.2 Physical Connection..................................................................................... 43
2.2.3 CAN Bus Basic Operation ........................................................................... 45
2.3 CAN DATA LINK LAYER ................................................................................ 46
2.3.1 Frame Formats ............................................................................................. 46
2.3.2 Message Filtering ......................................................................................... 47
2.3.3 Bus Arbitration............................................................................................. 48
2.3.4 Error Handling ............................................................................................. 49
2.4 CAN HARDWARE IMPLEMENTATIONS ...................................................... 51
2.4.1 CAN Controller Organisation ...................................................................... 51
2.4.2 Basic CAN vs Full CAN Implementations .................................................. 52
2.4.3 Stand-alone vs Embedded CAN Controllers ............................................... 54
2.4.4 Overview of the CAN Hardware Market ..................................................... 55
CHAPTER 3 INTRODUCTION TO CANOPEN ...................................................... 56
3.1 BACKGROUND ................................................................................................. 56
3.2 ORIGIN AND STRUCTURE OF THE CANopen SPECIFICATIONS...................... 58
3.3 CANopen APPLICATION LAYER FUNCTIONALITY .................................. 61
3.3.1 Introduction .................................................................................................. 61
3.3.2 Master/Slave Communication Relationships ............................................... 63
3.3.3 Client/Server Communicatio n Relationships.............................................. 63
3.3.4 Producer/Consumer Relationships - Push/Pull Model................................. 64
3.4 CANopen OBJECTS AND THE OBJECT DICTIONARY ............................... 65
3.4.1 Device Modelling in CANopen ................................................................... 65
3.4.2 CANopen Data Types and Encoding Rules ................................................. 66
3.4.3 Object Dictionary Structure ......................................................................... 67
3.4.4 Object Dictionary Representation ................................................................ 69
3.4.5 Object Dictionary Implementation............................................................... 70
3.4.6 CANopen Communication Objects for Application Data Transfer............. 70
3.5 SERVICE DATA OBJECTS............................................................................... 71
3.5.1 General Description ..................................................................................... 71
3.5.2 Segmented SDO Transfer ............................................................................ 72
3.5.2.1 Segmented SDO Download.................................................................. 73
3.5.2.2 Segmented SDO Upload ...................................................................... 75
3.5.3 Expedited SDO Transfers ............................................................................ 76
3.5.3.1 Expedited SDO Download ................................................................... 76
3.5.3.2 Expedited SDO Upload ........................................................................ 77
3.5.4 Block SDO Transfers ................................................................................... 78
3.5.4.1 Block SDO Download.......................................................................... 78
3.5.4.2 Block SDO Upload............................................................................... 83
3.5.5 Abort SDO Transfer Protocol ...................................................................... 87
3.5.6 SDO Configuration Through the Object Dictionary.................................... 88
3.6 PROCESS DATA OBJECTS .............................................................................. 89
3.6.1 General Description ..................................................................................... 89
3.6.1.1 Write PDO............................................................................................ 89
3.6.1.2 Read PDO............................................................................................. 90
3.6.2 PDO Triggering Modes................................................................................ 91
3.6.3 PDO Transmission Types ............................................................................ 91
3.6.4 Configuration of Process Data Objects Through the Object Dictionary...... 93
3.6.4.1 PDO Communication Parameters ........................................................ 94
 3.6.4.2 PDO Mapping Parameters.................................................................... 96
3.7 OTHER PRE-DEFINED CANopen COMMUNICATION OBJECTS....................... 99
3.7.1 Synchronisation Object (SYNC).................................................................. 99
3.7.2 Emergency Object...................................................................................... 100
3.8 COMMUNICATION OBJECTS FOR NETWORK MANAGEMENT................... 102
3.8.1 Introduction ................................................................................................ 102
3.8.2 State Diagram of a CANopen Device and NMT Module Control Services
................................................................................................................................. 103
3.8.3 CANopen Network Management Error Control Services ......................... 106
3.8.3.1 Node Guarding and Life-guarding Services....................................... 106
3.8.3.2 Heartbeat Service ............................................................................... 108
3.8.4 Pre-defined Connection Set ....................................................................... 110
3.8.5 Allocation of Identifiers by a Configuration Tool ..................................... 111
3.8.6 CANopen Network Boot-up Procedure ..................................................... 111
3.8.7 Minimum Capability Device...................................................................... 112
3.9 ELECTRONIC DATA SHEETS (EDS) AND DEVICE CONFIGURATION
FILES (DCF).............................................................................................................. 113
3.9.1 Structure of an Electronic Data Sheet ........................................................ 113
3.9.1.1 File Information Section..................................................................... 114
3.9.1.2 General Device Information Section .................................................. 114
3.9.1.3 Object Dictionary Sections................................................................. 115
3.9.1.4 Additional EDS Sections.................................................................... 116
3.9.2 DCF-specific Sections and Keywords ....................................................... 117
3.10 OTHER CANopen FEATURES...................................................................... 117
3.10.1 Definition of a CANopen Manager device .............................................. 118
3.10.2 SDO Manager and Dynamic Establishment of SDO Connections .......... 119
3.10.3 Programmable Device I/O ....................................................................... 120
3.10.4 Configuration Manager ............................................................................ 120
3.10.5 Multiplexor PDO and Node Group Addressing....................................... 120
CHAPTER 4 CANOPEN IMPLEMENTATION ISSUES ...................................... 122
4.1 INTRODUCTION ............................................................................................. 122
4.2 USING CAN HARDWARE IN A CANopen CONTEXT................................ 122
4.2.1 Revision of CAN Hardware Platforms ...................................................... 122
4.2.2 Message Reception: CANopen Filtering Requirements ............................ 124
4.2.3 Transmission of CANopen Data ................................................................ 125
4.2.4 CAN Messages and Message Bursts.......................................................... 127
4.2.5 Minimising Message Bursts o n a CANopen Network.............................. 128
4.3 IMPLEMENTATION OF MULTIPLE DEVICE MODULES......................... 129
4.4 OTHER SOFTWARE AND HARDWARE CONSIDERATIONS .................. 131
4.4.1 The Processor/CAN Controller Interface................................................... 131
4.4.2 Hardware Access to I/O Devices ............................................................... 132
4.4.3 Software Overheads ................................................................................... 132
4.4.4 Implementation Remarks ........................................................................... 132
4.5 CONSTRUCTING A CANopen NETWORK .................................................. 134
4.6 INFORMATION FOR CANopen DEVICE DEVELOPERS AND
MANUFACTURERS ................................................................................................ 135
4.7 AN EXAMPLE OF CANopen-B ASED SYSTEM INTEGRATION .............. 136
4.7.1 Constructing a CANopen Network (An Example) .................................... 136
 4.7.1.1 Step One - Collecting Information ..................................................... 137
4.7.1.2 Step Two - Distributing the Application ............................................ 138
4.7.1.3 Steps Three and Four - Selecting Appropriate CANopen Devices .... 141
4.7.2 Usage of CANopen Communication Objects (An Example) .................... 142
4.7.2.1 NMT Communication Objects ........................................................... 143
4.7.2.2 Service Data Objects .......................................................................... 143
4.7.2.3 Process Data Objects .......................................................................... 144
4.7.3 Message Exchange in CANopen Networks (An Example) ....................... 144
CHAPTER 5 CANOPEN CONFORMANCE TESTING........................................ 148
5.1 INTRODUCTION ............................................................................................. 148
5.2 EDS TESTS ....................................................................................................... 149
5.2.1 Completeness Tests.................................................................................... 150
5.2.1.1 Mandatory Sections Test .................................................................... 150
5.2.1.2 Standard Sections Test ....................................................................... 150
5.2.2 Value Ranges Test ..................................................................................... 153
5.2.3 Consistency Tests....................................................................................... 154
5.2.3.1 Dummy Usage Test ............................................................................ 154
5.2.3.2 Supported Objects Test ...................................................................... 155
5.2.3.3 Object Links Test ............................................................................... 155
5.2.3.4 PDO Mappings Test ........................................................................... 155
5.3 DEVICE TESTS ................................................................................................ 156
5.3.1 Protocol Verification Tests ........................................................................ 157
5.3.1.1 Service Data Objects Test .................................................................. 157
5.3.1.2 PDO Communication Parameter Test ................................................ 158
5.3.1.3 PDO Mapping Parameter Test ........................................................... 159
5.3.2 Object Dictionary Tests ............................................................................. 160
5.3.2.1 Communication Specific Area Test ................................................... 160
5.3.2.2 Device and Manufacturer Specific Area Test .................................... 161
5.3.2.3 Remaining Area Test.......................................................................... 162
5.3.3 Parameter Storage/Restorage Test ............................................................. 162
5.3.4 Emergency Test.......................................................................................... 163
5.3.5 Error Control Tests..................................................................................... 163
5.3.5.1 Node Guarding and Life-guarding Test ............................................. 163
5.3.5.2 Heartbeat Test..................................................................................... 164
5.3.5.3 Heartbeat / Node Guarding Precedence Test ..................................... 164
5.3.6 Synchronisation Test.................................................................................. 165
5.3.7 Verification of Network States .................................................................. 166
5.3.8 Verification of State Transitions ................................................................ 168
5.4 THE CANopen TEST INTERFACE (C.O.T.I.)................................................ 169
CHAPTER 6 EXAMPLE OF A CANOPEN IMPLEMENTATION ..................... 172
6.1 INTRODUCTION ............................................................................................. 172
6.2 OVERVIEW OF THE SAB-C167CR-LM MICROCONTROLLER ............... 173
6.3 HARDWARE IMPLEMENTATION................................................................ 175
6.3.1 Introduction ................................................................................................ 175
6.3.2 Circuit Schematics and Explanation .......................................................... 176
6.3.2.1 The C167 Microcontroller and Supporting Hardware ....................... 176
6.3.2.2 The CAN Physical Layer ................................................................... 177
6.3.2.3 The I/O Lines...................................................................................... 177
 6.3.2.4 Additional Remarks............................................................................ 178
6.4 SOFTWARE IMPLEMENTATION ................................................................. 178
6.4.1 Introduction ................................................................................................ 178
6.4.2 The Module Control Block ........................................................................ 180
6.4.2.1 Initialisation........................................................................................ 180
6.4.2.2 Implementation of NMT Services ...................................................... 181
6.4.3 The Service Data Object and Object Dictionary Block ............................. 182
6.4.3.1 The Object Dictionary ........................................................................ 183
6.4.3.2 Object Dictionary Read and Write Operations................................... 185
6.4.4 The Process Data Object Block ................................................................. 185
6.4.4.1 Event PDOs ........................................................................................ 185
6.4.4.2 Synchronous PDOs............................................................................. 186
6.4.5 The Emergency Object Block .................................................................... 186
CIRCUIT SCHEMATICS ......................................................................................... 188
GLOSSARY ................................................................................................................ 190
REFERENCES ........................................................................................................... 191
Flow chart: a guide to readers
 1

CHAPTER 1
Introduction
Chapter Objectives
When you have completed this chapter you should:
• Be able to identify the manufacturing structure and its utilisation by man to create a
better environment to live in and better working conditions.
• Be able to identify the needs for system integration.
• Understand the concept of distributed control systems technology in an automation
environment.
• Be familiar with typical cell components such as sensors and actuators.
• Understand the concept of distributed control and decentralised intelligence in the
context of fïeldbuses.
• Be familiar with protocols normally used in production cells in an automation
environment.
• Be able to identify the requirement for a fieldbus selection.
• Know the benefits of fieldbus systems in the automation arena.

1.1 BACKGROUND
In recent times the introduction of computers into the manufacturing workplace, in
the form of Information Technology (IT) in general and automation in particular, has
revolutionised the way in which the manufacturing industry operates. This applies to the
general organisation and procedures adopted by manufacturing industry as well as
specific methods and techniques of manufacture.
The advantages of these changes come in different forms. They may replace
workers in dangerous environments with lower cost machines; also they may involve
immediate savings, decreasing production costs by reducing waste, reducing processing
time, reducing the number of defective products, lower failure rates and better quality
products.
Concurrently, there are many other advantages, which may be less direct but often
have greater impact in the longer term:
• Greater knowledge of IT and its utilisation by humans to create a better living
environment and working conditions.
• Greater understanding of the manufacturing process, allowing easier
identification of bottle-necks.
• Better production scheduling, making maximum use of the production facilities.
• Greater flexibility in response to changes in design, customer requirements and
competition.
• Shorter 'lead times' in designing new products.
• Faster identification of faults in both product and processing machinery.
• Ability to identify deterioration in equipment before actual failure, reducing
production 'down time'.

In a system that must be flexible, its individual components and processing systems
must also be flexible. They must be capable of changing their operational parameters,
 2

tooling or processing operations at short notice, perhaps on a job to job basis. This is
where computer based automation comes into effect.
Computer systems imply programmability and decision making capability, i.e.
intelligence; intelligent production systems, cells & work stations and even individual
cell components are at the heart of the flexible capability of advanced manufacturing
systems.
It is for these reasons that this new technology is considered an asset. Although as
engineers it is the technology that interests us, for business it will be the advantages that
the application of this technology can bring to production. This will be the driving force
in bringing the technology to the work place.

1.1.1 The Factory as a Control System

Figure 1.1 shows a block diagram depicting the multiple communication links that
in general are in operation within a factory environment.

Figure 1.1 Example of a manufacturing system

As can be seen from Figure 1.1, the factory and its manufacturing system may be
thought of as a control system consisting of several feedback loops. In these loops man
and machine are integrated with one another.
Product design is based on externally obtained information and drives the
manufacturing effort. Manufacturing capabilities constrain and shape the product
design. Manufacturing requires an input of materials and its output is delivered to the
market via distribution and sales.
Marketing gathers internal and external information and feeds back information to
improve product design, manufacturing and sales. Sales are also fed through finance to
the corporate management and the corporate management will influence the product
design decisions.
All this interaction obviously requires adequate communication at all levels.
 3

1.1.2 Just In Time

The application of IT as a whole has allowed companies to make far better use of
information relating to all aspects of manufacturing goods. Computers can store far
greater quantities of data, whilst allowing faster access to requested items. The
processing power allows in depth analysis of data collected to produce meaningful
information that can be studied for future planning, and greater processing speed allows
faster decision making about the current state of production on the shop floor.
A consequence of these changes has been the appearance of the 'Just In Time' (JIT)
principle. The basic idea of JIT is that all necessary materials, components and
instructions for processing arrive at the processing site just as it has completed its last
operation. The impact on a company that adopts this principle can be very dramatic.
The first major impact is that as work arrives at the processing site 'Just in Time',
there are no long queues of raw materials, half-finished or completed components at
work sites throughout the factory. With the 'Work in Progress' cut to a minimum,
capital, i.e. money, is not tied-up in large stocks of goods materials. This may not have
come about without effective and adequate communication resources.

1.1.3 Communication in a Factory Environment

Communication in a factory environment consists of different networking levels.
These range from the simplest network inside a machine, to the network running around
the shop floor, the design room, the management and finance departments and
ultimately to the corporate level, where worldwide communication may be involved.
An automated manufacturing system may be described as a three-level hierarchical
model, according to the International Standards Organisation. This model is shown in
Figure 1.2.

Figure 1.2 Factory automation hierarchy, courtesy of Mr. R. McLaughlin (ODVA)

As can be seen in Figure 1.2, a hierarchy of communication systems is required to

meet the needs of all the elements within a manufacturing environment. Higher level
 4

networks such as TOP and MAP are not suitable to implement the communication
mechanisms required in the shop floor. Accordingly, lower level networks such as CAN
protocols could not possibly be used to perform tasks that require a lot more than the
simple interconnection of sensors and actuators on an automation cell.
A typical production line consists of a transportation system and several flexible
manufacturing cells. The transportation system itself will have various sensors and
actuators mounted on it to control and monitor pallet positions and to log product
information and process controllers. A typical flexible manufacturing cell consists of
sensors, actuators, process controllers, manual stations, mechanical linkages and
pneumatic components.
All these elements need to communicate with each other e.g. sensors and actuators
need to be connected to the process controller and even between process controllers
linkage may be required to allow co-ordination of the whole manufacturing line.
Consider the diagram in the Figure 1.3.

Figure 1.3 A typical production cell

In this simple system products are routed through different parts of the line
depending on the product that is being made. The progress of the product through the
system is monitored by sensors such as bar code readers that monitor its position in the
production system at any moment in time thereby providing a quality control check.

1.1.4 Typical Production Control Components

Most equipment found on the factory floor may be divided into four main groups:
• Process control equipment - programmable devices which control the manufacturing
process and include Programmable Logic Controllers (PLCs), embedded controllers
(industrial PCs, VME racks) and specialist controllers (motion, robot, CNC machine
etc).
• Mechanical components - transportation systems (conveyors), linear and rotary axes
(controlled by motors) and automatic guided vehicles (AGVs).
• Actuators - electric motors (AC/DC/Stepper), pneumatic valves and pistons, maglev
guides, and other similar devices.
• Sensors - used for obtaining data from the environment, positions of mechanical
components, testing and monitoring quality of output and machine control.
 5

1.1.5 Flexible Manufacturing Systems

The advent of programmable electronics and the use of programmable controllers
has given the industrial user (systems integrator) the ability to modify a production cell
simply by reprogramming it without having to change the wiring of the control system.
This ability reduces costs of the system as less time is spent re-configuring a cell to
produce new products.
A flexible manufacturing system will consist of several different types of devices,
which traditionally have been connected to a central controller via different electrical
interfaces, as illustrated in Figure 1.4.
The illustration in Figure 1.4 portrays a system that is commonly known as a
centralised control system. In this type of system all control devices are connected to a
central controller. The central controller is responsible for co-ordinating the operation of
the cell or machine. Different control components will be mounted in different
geographical locations, for example, in a production cell environment. Each type of
device will have a different electrical interface to the controller. Therefore, numerous
wires must be run around the production cell or machine from each device to the central
controller.
This is disadvantageous because as the cell complexity increases so does the wiring
complexity. In a complex wiring system faults can be very diffïcult to find and the more
wires used the greater the cost of the overall system. A large number of wires can also
be diffïcult to connect to a control unit simply because of the physical sizes of
connectors.

Figure 1.4 A conventional production cell control system, courtesy of Mr. R. McLaughlin
(ODVA)

This solution has other disadvantages in a situation where the addition of new
components is required. For example, a component that uses a special type of interface
can be very difficult and costly to integrate in an existing system. Also, if each cell is
self-contained, each cell controller must individually be re-programmed at the location
in the production line.
 6

Figure 1.5 A typical networked production cell, courtesy of Mr. R. McLaughlin (ODVA)

To overcome the above disadvantages, i.e. to reduce the cost of implementation and
to provide ease of integration, the use of fieldbuses is a solution that is being
increasingly adopted in the automation industry. A typical fieldbus-based system is
represented in Figure 1.5.
The network depicted in Figure 1.5 is a fieldbus. It can been seen that rather than
connecting each constituent element to the controller, all these elements are locally
connected to the same fieldbus, a shared communication medium. A fieldbus is an
innovative solution to a permanent need of systems integrators: ensuring efficient
communication between the constituent elements of a production cell. Information
Technology and the development of low cost microcontrollers with integrated
networking capabilities has meant that control components from simple on/off sensors
upwards now have their own intelligence and ability to communicate with one another.
This gave way to a new concept in the manufacturing arena: the Distributed Control
System, also called a Decentralised Control System.
Using a network offers advantages over a conventional system. For starters, in a
Distributed Control System, only a single set of wires needs to be routed around the
cell, often including the power cables, hence less physical connectors are required. This
leads to another improvement: cost reduction. Additionally, new devices are easily
connected to the system and better diagnostics and fault finding mechanisms can be
implemented. A Distributed Control System also introduces a greater flexibility and the
ability for controllers to operate over larger geographical areas. Finally, only one basic
standard interface may be required and, if the network is sufficiently standardised, there
will be no tie to a single vendor.
 7

Figure 1.6 Automation cell structure

The example in Figure 1.6 illustrates the basic layout of a production cell with a
conveyor transportation mechanism and a PLC acting as the cell controller. In this
example, the conveyor system in the production cell carries two pallets moving in a
closed track. Pneumatic actuators and two inductive proximity sensors at two pallet
station positions allow the system to monitor and control the position of each pallet.
One of the pallets has an extra metal tag, which is detected by the sensors and used for
pallet identification. All of this information is channelled through a remote digital I/O
module. This module communicates with the cell controller via CAN bus using the
CANopen protocol.

1.2 THE ISO/OSI REFERENCE MODEL

The ISO/OSI Reference Model is a framework that was devised by the International
Standards Organisation (ISO) to support the development and implementation of open
communication protocols. This model is used as a reference by most present-day
protocol specifications. The ISO/OSI Reference Model is briefly discussed in the
following sections.

1.2.1 The General Framework Of The OSI Reference Model

The model is based on the assumption that there are two co-operating systems
wishing to communicate. Each system is servicing a particular application process. The
model is also known as the 7-layer ISO/OSI Reference Model, the hierarchy of which is
shown in Figure 1.7.
 8

Figure 1.7 ISO/OSI 7-layer model

The essence of the model is that data are passed between two application processes,
A and B, by methods which are unknown and largely transparent to the application
itself. As the two applications operate on different machines, they are known as 'remote
application processes'. These applications link to the communications system by using
the services of the uppermost layer of the Reference Model, the Application Layer. In
turn the Application Layer uses the services of the layer below it, the Presentation Layer
without the need for knowledge of any lower layers. There are 7 layers in the model,
each layer being used by the layer immediately above it, and using the services of the
layer immediately below. The functionality of all lower layers is hidden and completely
transparent in their operation.
The seven layers, from the highest (layer 7) to lowest (layer 1), are called
Application, Presentation, Session, Transport, Network, Data Link and Physical Layers.
Each layer within the system, as well as calling the layer immediately below it, is in
effect in communication with the equivalent layer in the other process. The concept of
the OSI model envisages associations, or agreements to co-operate, being set up
between each of the seven layers of the co-operating end systems. These so-called
'corresponding elements' are then responsible for negotiating levels of reliability of
service and data flow control. The rules governing the interactions between the
equivalent layers are known as 'layer protocols'.
In any given layer, the two co-operating systems' active elements, or 'peer entities' as
they are called, communicate with each other by following a set of agreed rules, known
as 'layer protocols for peer entities'. These protocols determine the way in which the
peer entities co-operate to provide the layer functionality.
Data are transferred between the two application processes (A and B), by being
passed down through the layers of one system before being passed over the transmission
medium. Data are transferred between layers in the form of 'data units' (DU). Each layer
 9

may add control information to each data unit, and this control information is used to
organise communication between the peer entities in the two remote systems.
Each layer passes its data to the level below in the form of a 'protocol data unit'
(PDU). The next layer adds 'protocol control information' (PCI) to that data unit, now
known as the 'service data unit' (SDU), to produce its own protocol data unit. This new
PDU is then passed down to the next lower layer, and so on down to the Physical Layer.
The Physical Layer then possesses a complete transmittable 'data frame', which can be
transferred through the transmission medium. This process is shown in Figure 1.8.
The complete transmitted frame is then received by the second system. As the frame
is passed up through the layered structure of the receiving system B, each PCI header is
stripped off at its respective layer. When a data unit is passed on by the Application
Layer in system B only the user data remains.
The information contained in the various PCI headers, added by the entities in the
layers of system A, is removed by peer entities within system B. The information held
in the PCI headers influences the way an individual layer responds to the SDUs which
they receive from or pass to the next highest level.
With this concept, the services of each layer of functionality of the Reference Model
can be isolated from each other, avoiding the problems of interaction between functions
that often occur in less well-defined architectures. Each layer is only aware of its
immediately adjacent layers, above and below, and generally passes on user data units
without modification or understanding. Each layer communicates with the underlying
layer by invoking the services that this layer offers, or particular functions within these
services, known as 'service elements'.

Figure 1.8 ISO/OSI message construction

The reader should note that as the ISO/OSI Reference Model is designed to
encompass the most complex communication links, some communication systems may
not use all seven layers of the model (unused layers are often called Null Layers). This
 10

may be due to the fact that a particular communications network operates within very
strict and limited parameters, so the functionality of some of the layers is not required.
Or it may be that certain commercial systems are only defined up to a certain level
(counting from the Physical Layer upwards), leaving it to the users to make their own
decisions about the higher level functionality that they need to implement. In the
following, the functionality of each layer is discussed in more detail.

1.2.2 Application Layer

The Application Layer is the layer that user programs and processes access to
communicate over the network. It is usually the only access point available to users.
The Application Layer is responsible for:
• Providing complete addresses for 'named' remote application processes.
• Control of security.
• Checking the authenticity and authority of the communications link end systems.
• Error control and recovery.
• In general, providing all services required for the support of the application process
e.g. file transfer management. The Application Layer makes use of services
provided by all the lower layers.

1.2.3 Presentation Layer

The Presentation Layer provides much of the device independence that is required of
open systems interconnection. Its main concern is with the syntax of the data, not its
interpretation, which is the responsibility of the Application Layer. This may include
providing conversions from the remote application data representation to the local
application data representation, i.e. encoding and decoding from the agreed common
transmitted data representation into the local application's format requirements.
In order to provide this service, a number of Presentation Layer functions have been
defined:
• Session establishment and termination requests.
• Data transfer.
• Negotiation and re-negotiation of syntax.
• Syntax transformation; this includes data transformation, formatting and special
transformations such as data compression to reduce message size.

1.2.4 Session Layer

The Session Layer has an unusual functionality within the layer structure. It provides a
translation of communication concepts. The Session Layer is the point where links
between two different machines and different processes in those machines are brought
together.
Consider two multi-user systems linked together, and a user on one system
communicating with a user on the other system. Layers 1 to 4 are concerned with how
the two machines communicate, and layers 6 and 7 deal with translating and organising
the data sent and received by each user or process. The Session Layer is concerned with
the transaction changes that occur between two communicating processes and deals
with two communicating machines.
Therefore, the Session Layer is responsible for setting up associations between users or
application processes, and for the termination of information exchanges. This is done by
 11

using tokens to enable synchronisation on start-up and re-establishment of connections

after link failures. The Session Layer also coordinates the provision of data flow
between the communicating systems. Session Layer functionality includes:
• Normal data exchange.
• Expedited data exchange, when data are required immediately and are given a
higher priority. Expedited data exchanges may overtake data being transferred using
normal data exchange.
• Token management used in systems that pass tokens between each other, where
each system is only allowed access to the network when in possession of the token.
• Dialogue control of either two way alternate (half-duplex) or two-way simultaneous
(full-duplex) data exchange.
• Exception reporting, notifying errors and other unexpected events.
The exact range of functions that the Session Layer may be called on to provide is
application specific. The requirements of the Presentation Layer wili influence exactly
which subset(s) of the Session Layer services are required.

1.2.5 Transport Layer

A fundamental difference exists between the three upper layers and the three lower
levels of the ISO/OSI Reference Model, The upper three layers, Session, Presentation
and Application Layers, are responsible for providing high-level data communication
functions between network users. On the other hand the lower layers, Physical, Data
Link and Network, are concerned with basic data transmission functions, either through
a direct link to another machine, or via a cascaded system of links.
The Transport Layer is responsible for bridging the gap between the functions that
provide data transmission functions and the layers that provide communication
functions. The Transport Layer is also responsible for overall end-to-end reliable data
flow, providing a service that is independent of the physical media or networks used.
This will include the ability to segment large data structures (or files) into smaller
transmittable sections. Likewise the Transport Layer would be involved in the
reconstruction of received data structures.

1.2.6 Network Layer

This Layer performs the addressing and routing functions needed to transport
messages between the end systems involved. This can be a complex task if the messages
have to pass through a series of sub-networks to reach their final destination, where
each has its own form of naming and addressing functions.
Where several different sub-networks, using different media-access methods and
data-handling capabilities, are connected, the connections are formed by a device
known as a 'router'. A router operates using the conventions of the lower three levels of
the ISO/OSI Reference Model. It acts as a kind of sorting office to redirect messages
that pass through sets of heterogeneous sub-networks. It identifies the destination of a
message, and can recognise which of the subnetworks to relay the message to so that the
message can reach its final destination.

1.2.7 Data Link Layer

No matter what physical data transmission medium is used, random errors will
appear during the process of data transmission though present-day local area networks
and digital circuits are less likely to introduce errors than older systems.
 12

The main purpose of the Data Link Layer is to deal with this fact and minimise the
number of errors passed on to the higher layers. This is achieved by constructing the
data into a recognisable structure known as 'data frame'. This method is used to detect,
and where possible rectify, errors introduced by the physical medium during the
transmission process. Such systems usually analyse the content of a data frame before
transmission and add control information to the data so that errors can be detected and
eventually corrected on the receiver end. A very common error detection mechanism is
the Cyclic Redundancy Check, whereby the transmitter includes in the frame a code,
which is calculated based on the contents of the data. The receiver then performs its
own calculation to obtain an equivalent code based on the data it received. If the two
codes do not match then an error has occurred in the transmission.
Additionally, the Data Link Layer deals with three other main areas of
communication. These are:
• Flow Control - this is used to cope with the problems inherent with a fast sender
sending messages to a slow receiver. Some method must be employed to slow down
a fast sender while the slow receiver handles previously transferred messages.
• Link Management - this deals with the rules that a sender and receiver must follow
in order to exchange information. For example, a sender and receiver may need to
identify themselves to each other and be willing and ready to communicate before
exchanging any data.
• Medium Access Control - this controls access to the transmission medium itself. Its
purpose is to cope with the problem of two or more stations sending data at the same
time: either by preventing the problem from happening, or by recognising a 'data
collision' (two stations trying to send messages on the transmission medium at the
same time), and resolving the problem so that data and messages are not lost.

1.2.8 The Physical Layer

The Physical Layer is concerned with transforming or encoding the data passed to it
into some form of signal that can be passed over the transmission medium. The form the
encoded data will take will depend on the form of transmission medium used. This may
be cable or fibre optics, and may be a baseband system (one message transmission at a
time) or a broadband system (messages can be sent simultaneously, by having different
sets of frequency bands available for transmission). Functions of the Physical Layer
include:
• Performing data encoding and decoding operations - translating the data into some
form of transmittable signal, and translating incoming messages back into usable
data.
• Generating control signals for proper operation of the Data Link Layer - e.g.
collision and bad signal detection. Note that the Physical Layer detects and signals
these events, but it is the Data Link Layer that makes decisions, and takes actions on
the signals.
• Defining physical connections to the medium - e.g. plug types and pin connections.

If a broadband system is in use, the Physical Layer will also have to:
• Perform modulation and demodulation functions - to extract signals on a set
frequency band from other signals, using filter systems to reject 'noise' generated
from other frequency channels.
• Providing a channel with a desired bandwidth and low error rate performance.
 13

Although the Physical Layer describes the connection to the transmission medium, it
does not dictate the actual form of the transmission medium, nor its specific
performance characteristics. Over long distance connections, signals may deteriorate to
a state that they can no longer be accurately read by the receiving station. Devices
known as 'repeaters' can be installed to cope with this problem. Repeaters are effectively
signal boosters; all incoming signals are simply passed on, but with signal strength
restored to acceptable levels. The most obvious application is in very long distance
systems, such as the Trans-Atlantic phone system.

1.2.9 Layer Management & Control

In the ISO/OSI Reference Model, data are passed up and down the layers of the
model, with each layer only being aware of adjacent layers. Therefore, there may be a
need for the application itself to set performance parameters or to receive performance
information about lower layers of the model. To accomplish this some form of layer
management system can be implemented that allows the application a limited access to
the functionality of layers of the model.
This type of functionality is most likely to be used at the start of an application, to
change or to check the specific configuration of the communications system. The
application may also need to access the management system when significant errors are
detected, in which case the application may need to obtain more detailed information on
the exact causes of errors for analysis and correction.

1.3 NETWORKING AND ITS BENEFITS

The basic concept of a network system is that all devices are connected to, and
communicate, using a single standard system. The degree to which this affects each
device is dependent on the simplicity of the system in terms of the system's
implementation and use. To allow simple devices to communicate via a network may
cause a significant increase in the complexity and sophistication of the device, meaning
extra cost, while the extra benefit to the device itself may be minimal. However, the
capability of integration with other devices will expand the functionality of the system
as a whole. This is the great advantage of using a network system.
This discussion implies that makers of simple devices may at first be reluctant to
add large amounts of sophistication to originally simple devices, as this greatly
increases the price of the device, endangering its acceptance on the market. However if
a systems integrator wishes to use such simple devices, e.g. a simple on/off switch, then
the device has to have the potential for integration with the whole system.
This means that the network system selected must be widely accepted on the market,
with good indicators of future reliability of supply.
This in turn means that potential users of a network system have to be convinced of
the system's viability and that there are sufficient advantages to counter-balance what
may be a large-scale investment.
The main areas in which the concept of networks brings benefits are:
• Standardised minimum wiring between devices and low cost of implementation.
• Ability for control systems to expand over large geographical areas.
• Future expandability i.e. capability to add further devices to the system without the
need of system redesign.
• A sole basic communications standard for engineers to learn and to maintain.
 14

• Vendor independence, in case the standard is widely accepted in industry e.g. open
protocols.

Networks allow transferring data via a standard system of wiring that is shared by
multiple devices. Any standard system of wiring, e.g. a twisted pair of wires between
devices, will have the immediate benefit cost cutting in terms of quantity required,
installation and implementation. The other benefit is that of less maintenance and fault
diagnostics costs. These advantages have been felt in the use of CAN in the automotive
industry, where the reduction in wiring costs was significant and widely recognised.
The use of networking reduces the number of controllers otherwise required. Not
only can the physical size of the system be greater but also tasks can be delegated on
other devices connected to the network thereby decreasing the processor load. This
yields obvious cost benefits and may also allow greater coordination of a system as all
actions can be controlled and supervised by one central controller.
Network systems can, in general, be easily expanded. Moreover, when standard
devices are employed, the task of expansion can come down to simply adding a few
metres of network cable and connectors.

1.4 BASIC NETWORKING CONCEPTS

1.4.1 Data Transmission
This section discusses the basic properties of transmission lines and media with
relevance to today's industrial wired networks. Most networks work on the basis of
serial transmission where parallel data are converted into serial form for transmission
over the network. The data are then converted back from their serial form to their
parallel representation by the receiving end. The receiving end does this simply by
sampling the media at specific time intervals and converting these data into a logical
sequence of Ts and 'O's. This concept is shown in Figure 1.9.
Transceivers are used to drive the interconnecting cable between networked
components at the correct voltage and current levels. In optical and radio systems the
transceiver takes the form of optical and radio transmission/reception components.
However, due to the cost and technical limitations of today's electronic components,
most networks are linked using cables. A simple end-to-end network is shown in Figure
1.10.

Figure 1.9 Data transmission

 15

Figure 1.10 A simple end-to-end network structure

The diagram in Figure 1.10 shows two devices connected and communicating over
the physical media. It is perfectly acceptable to have more than two devices sharing the
same media although this depends on the line drivers or transceivers and the type of
network used. Several common standards exist for data transmission over a network or
point-to-point communications link. All that differs between them is the current and
voltage signal levels, which determine the level for logic '0' and a logic '1'. The signal
properties differ with respect to noise and maximum data rates.

Figure 1.11 A typical TTL driven arrangement

Figure 1.11 shows a typical end-to-end TTL line driver. Typical signal levels are
+V=+12 to +15 Volts and -V=-12 to -15 Volts. With this type of end-to-end connection,
data rates are restricted to less than 115 Kbit/s. Maximum line length is normally about
15 metres.
The standard 20mA current loop uses current rather than voltage levels for the
representation of logic levels. This substantially increases distances and is extremely
popular in industry (particularly in process control arenas). A simple arrangement for
current driven signals is illustrated in Figure 1.12.
 16

Figure 1.12 A typical current driven arrangement

To transmit logic '0' the transmitter opens its current switch. At the receiving end no
current is detected or flowing and therefore it interprets the signal as a zero. When the
transmitter transmits logic T it closes its current switch, current flows around the loop,
the receiver detects this and indicates a one has been transmitted. The noise immunity of
the system is much higher than for voltage driven systems. However, the rejection of
common mode noise in the current loop arrangement is less than that of the voltage
driven arrangement. Typically, current loops are used to transmit over distances of up to
lkm but transmission rates are relatively low due to limitations in the switching circuits.
In RS422 (Figure 1.13) logic 1 and logic 0 are represented by the polarity of a
differential voltage. Rt is a terminating resistor used to terminate the lines so as to
reduce unwanted reflected signals, decreasing signal distortion. This system has good
common-mode rejection properties.

Figure 1.13 RS422 line driver arrangement.

 17

Figure 1.14 shows the RS485 arrangement. This system is a variant on the RS422
standard with the essential difference being that several transmitters and receivers can
share the same pair of wires. This requires special techniques to ensure that no two
transmitters try to send information at the same time, causing data corruption. For this
reason, the RS485 arrangement has been used as the basic concept for many networking
systems such as Profibus and CAN.

Figure 1.14 RS485 line driver arrangement

1.4.2 Data Synchronisation

In order for data to be transmitted over a serial bus system, parallel-to-serial and
serial-to-parallel conversions of signal levels take place at the transmitting and receiving
ends, respectively. This requires the receiver to sample the bus at the correct point in
time in order for the correct signal values to be converted back into their parallel
representations. Incorrect sampling results in corrupted messages. Figure 1.15 illustrates
this concept.

Figure 1.15 Sampling: (a) sampling correctly, (b) sample time too long, (c) sample time too
short

From Figure 1.15 it is possible to evaluate how important it is that the sampling
clock at the receiver end is synchronised with the clock of the transmitter (the
 18

transmitter clock is responsible for the parallel-to-serial conversion process). Two types
of bit sampling exist: asynchronous sampling and synchronous sampling.

1.4.2.1 Asynchronous Sampling

In an asynchronous sampling scheme both transmitter and receiver have their own
clocks running at the same frequency. An asynchronous sampling scheme is shown in
Figure 1.16.

Figure 1.16 Asynchronous sampling and synchronisation

Generally, the start of the transmission synchronises the clock at the receiver end
with that of the transmitter and from this point on both clocks run asynchronously from
cne another. RS232 works on this principle. Here transmission rates are governed more
by the accuracy of the timing components than by the quality and propagation
properties of the interconnections. Nowadays this is less of a problem, as components
are manufactured with precision and therefore timing accuracy has improved.

1.4.2.2 Synchronous Sampling

Synchronisation can be done in a number of ways. Perhaps the most obvious is to
transmit the clock signal using a separate signal conductor. There are disadvantages to
this method. The first is that the cabling will require at least one extra conductor and
therefore cabling cost is increased. The second is that the propagation effects of the
cable may mean that the clock signal on reaching the receiving end has drifted
sufficiently to cause incorrect sample times at the receiver. Also there is increased cost
as additional driving electronics are required to power the cable carrying the clock
signal. An alternative to this is to superimpose both data and clock signals. An example
of this is given in Figure 1.17.

Figure 1.17 Synchronisation by encoding the clock and data signals

 19

Superimposing clock and data signals however, can create difficulties in decoding
the incoming pulse train. This is particularly true in the example of Figure 1.17 where
the receiving electronics must decode three different bus signal levels. An alternative
method is to use the transitions that will inevitably occur within the pulse train itself.
This requires the use of a resynchronisation method whereby the sampling process at
the receiving end is synchronised at periodic intervals during reception of the pulse
train. For this purpose, a digital phase locked loop (DPLL) may be used, as shown in
Figure 1.18.

Figure 1.18 Synchronous transmission using DPLL

The bit encoding scheme must ensure that the DPLL has enough bit transitions in
order to resynchronise sampling. The most common process is to insert extra stuff bits
as part of the bit stream where there may be a continual series of ones or zeroes. For
example, CAN networks insert a bit of the opposite polarity every 5 bits of the same
value. Another alternative is to use the Manchester encoding scheme.
The Manchester encoding scheme encodes logical Ts and 'O's as signal transitions,
as shown in Figure 1.19.

Figure 1.19 Manchester encoding scheme

 20

Using the Manchester encoding scheme a transition in signal level is guaranteed

even if the transmitter is transmitting a constant stream of Ts or 'O's.

1.4.3 Networking Topologies

There are several networking topologies and the most common ones are illustrated
in Figure 1.20.
The simplest layout, low-cost and the most common form of topology is the Bus or
Linear network. With this network it is easy to add new nodes and extend the bus. The
disadvantage of this network is that if the cable breaks in one location communication
may be lost with several nodes.
Ring topology is common in industrial networks. This type of topology may have
increased cabling and connector costs, but if a cable breaks, this may not necessarily
cause loss of communication.
Star topologies are used primarily for telephone systems and wide area networks.
Data are routed through different network paths by packet switching devices. Switching
components can add to overall costs and may also slow data rates.

Figure 1.20 Network topologies

The Hub/Tree network is similar in geographical layout to a Star network except a

Hub performs no data or packet switching (Figure 1.21). A Hub simply relays frames or
electrical signals between different parts of the network. This type of network has an
increased cost and decreased data rates due to the use of Hubs. This type of network is
used for longer distance communication.
 21

Figure 1.21 Hub/Tree network

To extend the length of a bus, repeaters are sometimes used. An example of a Bus
network with a repeater is shown in Figure 1.22.

Figure 1.22 Bus network using repeaters

1.4.4 Frame Concept

When transmitting information on a network as a serial bit stream, data are
encapsulated into a frame. A frame contains several pieces of information that the
receiver can use to decode and check the validity of the contents of the frame and the
enclosed data. A typical frame consists of a Start of Frame (SOF) field, a Control Field
(CF), a Data Field (DF), an Error Checking Field (ECF) and an End of Frame (EOF)
field. This general frame format is shown in Figure 1.23.

Figure 1.23 General frame format

• SOF - contains information, in the form of a bit pattern, denoting to receivers that it
is the start of the transmission. This may include bit patterns for synchronisation of
the receiver clock or for governing access to the bus.
• CF - contains information regarding the length of the data and the type of data
included in the frame.
 22

• DF - contains any information included in the frame. Different networks will have
different maximum data lengths in each frame.
• ECF - contains information that allows the receiver to check the validity of the data
and/or control fields.
• EOF - contains, in general, a fixed format bit pattern denoting to receivers and
prospective transmitters of information that the frame is at an end.

Note that a frame may not have all of these fields present. One of the simplest
frames is that used by RS232. The format of an RS232 frame is shown in Figure 1.24.
The start bit represents the SOF and is used by a receiver to resynchronise its clock
so that sampling of subsequent bits is achieved successfully. There is no control field as
the format of the frame is agreed in advance i.e. both transmitter and receiver will
always use the same frame format. The data field consists of seven or eight bits of data.
The parity bit (which may not necessarily be present) represents the error check field
and the stop bits are at the end of the frame.

Figure 1.24 RS232 frame format

1.4.5 Medium Access Control

Medium Access Control (MAC) is used to arbitrate which transmitter in a network
gains access to the transmission media. It is used to prevent two or more nodes from
trying to transmit information at the same time and thus prevents electrical signals from
interfering with one another and causing data loss or corruption.
In large networks there are many different paths for communication and if two or
more nodes wish to transmit at the same time they can use different network paths, thus
avoiding collisions. In a Bus or Ring topology all nodes share the same transmission
media and therefore they use MAC methods to prevent data collision.
There are many different methods for MAC, some of which are described in
standards e.g.
• CSMA/CD = IEEE 802.3.
• Token Ring = IEEE 802.5.
• Token Bus = IEEE 802.4.

1.4.5.1 Poll/Select
In a Poll/Select mechanism only one station on the network (the master) is allowed
to initiate transmissions. The master polls devices for information and will only request
information from a device once its previous request has been successfully completed.
An error detection mechanism is inherent within this method of communication: a node
 23

failing to reply to a request after a certain predefined time-out period may have failed.
The Poll/Select method is shown in Figure 1.25.

Figure 1.25 Poll/Select communication

This type of communication can be made quite fast for small networks, although the
loading on the master and the response times and data update rates increase as the
number of nodes on the bus grows.

Figure 1.26 CSMA/CD illustration

 24

1.4.5.2 Carrier Sense Multiple Access with Collision Detection (CSMA/CD)

In a Carrier Sense Multiple Access network with Collision Detection, transmitting
nodes first check the network to see if the bus is clear i.e. if there are no electrical
signals on the bus (Carrier Sense). If the bus is idle, a node begins transmission of its
frame or message. Other nodes will see this transmission and will not transmit
themselves.
The transmitting node also listens to the bus at the same time. Therefore, if two
nodes try to transmit data simultaneously (or close to it, remember propagation delays
may have an effect) the actual signal on the bus and the transmitted one (intended
signal) will differ. Both transmitting nodes will detect this variation (Collision
Detection) and stop their transmission. After a certain period, the nodes will try to re-
transmit again provided the bus is free. This period is sometimes randomly defined, as
in the case of Ethernet. The CSMA/CD MAC method is illustrated in Figure 1.26.
In Ethernet when a collision occurs nodes wait for a random time period before
attempting re-transmission. During this time another node may have started to transmit
data. Therefore, the original nodes detecting this situation will have to wait until the bus
is free again. If there are a large number of nodes transmitting data the node may face
unacceptable delays before being able to transmit its message. In this type of system
problems may occur when message length is long and there are a large number of nodes
trying to transmit information.

1.4.5.3 Token Ring and Token Bus MAC

A control token is a special kind of frame used to arbitrate bus access. In this
scheme the control token is passed from one node to the next and only when a node has
possession of the token may it transmit data. The system is shown in Figure 1.27.

Node A transmitting

Node B transmitting

Node C passing the token as it has no data to transmit

Figure 1.27 Token Ring MAC transmission

 25

On network initialisation node A has the token and may transmit data. When node A
has finished transmitting data it passes the token to node B which can then start
transmitting. When node B has finished it passes the token to node C. If node C has no
data to send it immediately passes the token to node A.
The two variants of this token passing arrangement, i.e. Token Bus and Token Ring,
work in exactly the same way, if we forget about the network topology: in a Token Bus
network the token passing is in a logical ring, where one node logically follows another.
In a real time control environment small amounts of data need to be transmitted at
regular intervals. To prevent a node from continually transmitting data and
monopolising the token each node is configured to hold the token for a limited period of
time, known as the Token Hold Time (THT). Care must be taken to make the THT
small enough to give the network fast response times but large enough to allow the node
to transmit its data within its allotted THT: otherwise a data build up can occur on the
node.

1.4.5.4 Slotted Ring

Slotted Ring MAC is primarily used in Ring networks. The network is initialised
with a fixed number of bits for transmission by a special node known as the monitor.
The bit stream is continually shifted around the ring from one node to another. The ring
contains a fixed number of transmission slots each made up of a single fixed frame of
information, as shown on Figure 1.28.

Figure 1.28 Slotted Ring MAC topology

Initially all slots are maiked as empty. When a node detects an empty slot it fills in
the frame with data and the destination address for the data. It then marks the slot as
full. The slot is then circulated through each node until the destination address matches
the address of the node. If the addresses do not match, the node simply ignores the slot.
If the addresses match, the node reads the data and sets the acknowledgement field. The
slot re-circulates until it reaches the source (original transmitting node) which detects
the acknowledgement and marks the slot as empty. If there is no acknowledgement an
error has occurred.
 26

Disadvantages are that this type of bus requires a monitor node and the frame length
is fixed, requiring multiple slots for large amounts of data. The time taken to transmit
data increases with the number of nodes in the ring.

1.4.6 Error Checking Mechanisms

Several error-checking mechanisms are commonly used to allow a receiver to detect
whether the information has been received correctly. These include: FORM or FRAME
errors where the received frame does not follow the correct format, BIT errors, for
example with the violation of bit encoding rules, and others.
However, these do not check the validity of the data content of the frame. Therefore
certain error checking mechanisms are used whereby both transmitter and receiver
perform calculations based on the frame contents. The result of the calculation by the
transmitter is compared to an independent calculation done by the receiver. If a
mismatch exists then an error has occurred. Once a receiver detects an error, it will be
signalled to the transmitter in several different ways, for example:
• By means of a negative acknowledgement - the receiver replies to a transmitted
message indicating the error has occurred. This mechanism is mostly used in Peer-
to-Peer and Poll/Select networks.
• Transmitting an error frame - when a receiver detects an error it transmits an error
frame e.g. in Controller Area Network (CAN) the error frame consists of 6
Dominant bits.
Some of the most common error-checking mechanisms will be briefly explained in
the following.

1.4.6.1 Checksum
The simplest form of error check is the checksum. In a checksum consecutive bytes
in the frame are added together to form the checksum value. Note that the checksum
may be done on the whole frame or just the data section of the frame. An example of a
checksum calculation is shown below.

DATA FRAME CHECKSUM

34 ; 66 100

However, this method does not detect all errors (or even a large enough portion of
them):

DATA FRAME CHECKSUM

TRANSMITTED 54 ; 56 110
RECEIVED 55 ; 55 110

It is seen that in the cases given above both checksums are correct while the data is
erroneous.

1.4.6.2 Parity Check

Parity checking is commonly used, for example in RS232, and works by
transmitting an extra parity bit with each byte of data. The frame format of an RS232 is
shown in Figure 1.29.
 27

Figure 1.29 RS232 frame format

Figure 1.30 Illustration of parity check mechanism

The parity bit is calculated by performing successive XOR operations of the serially
received bits. The mechanism is illustrated in Figure 1.30.

Table 1.1 Example of a parity bit calculation

B0 B1 B2 B3 B4 B5 B6 B7 Operation
1 0 1 1 1 0 0 1
P0 = 1 B0 ⊕ B1 = P0 = 1 = 1 ⊕ 0
P1 = 0 P0 ⊕ B2 = P1 = 0 = 1 ⊕ 1
P2 = 1 P1 ⊕ B3 = P2 = 1 = 0 ⊕ 1
P3 = 0 P2 ⊕ B4 = P3 = 0 = 1 ⊕ 1
P4 = 0 P3 ⊕ B5 = P4 = 0 = 0 ⊕ 0
P5 = 0 P4 ⊕ B6 = P5 = 0 = 0 ⊕ 0
P6 = 1 P5 ⊕ B7 = P6 = 1 = 0 ⊕ 1
Parity (Even) = P6 = 1, Parity (Odd) = NOT P6 = 0

Table 1.1 shows an example of a parity bit calculation. This scheme is useful in
detecting single bit errors that may occur between the transmitter and receiver i.e. if one
bit is in error it will be detected. However, if two bits or more are in error the same
parity bit may result, in which case the error will go undetected. Therefore, the parity bit
scheme used in RS232 is said to have a Hamming Distance of 2 i.e. two binary words
 28

may share the same parity value as long as they differ in more than 1 bit value, as
shown in the Table 1.2.

Table 1.2 Examples of binary words with Hamming Distance of 2

Data Parity (even) Parity (odd)
0000 0000 0 1
0000 0001 1 0
0000 0010 1 0
0000 0011 0 1

A variant of the parity bit check is the block parity bit check. In this case successive
data bytes are not only parity checked across each row but corresponding bits in
successive data bytes are also checked. This principle is shown in Table 1.3.

Table 1.3 Block parity check

Direction of transmission Data Parity (even) Parity (odd)
0000010 1 0
0101000 0 1
1000110 1 0
0100000 1 0
0101101 0 1
1000000 1 0
1100011 0 1
0000011 0 1
Column parity check 1000001 0 1

Note that this parity bit error check scheme permits detecting two or, in some cases,
more bit errors in the transmission. Additionally, if no more than one bit error occurs
during the transmission, it is possible to locate the erroneous bit and therefore correct it.

1.4.6.3 Cyclic Redundancy Check

Also called the frame check sequence (FCS), this method is based on polynomial
codes generated through the division of the frame contents by a generator polynomial.
The result of the division is transmitted with the frame. The same operation is carried
out at the receiver end and the results are compared. If the result of comparison is zero,
then no error has occurred; otherwise the frame is erroneous. The mechanism is
illustrated in the following:

Let:
• N(x) be a frame of length k bits.
• G(x) be an (n+1) bit number. This is known as the generator polynomial.
• R(x) be an n bit number such than k>n. This is called the remainder of the division.
• Q(x) the quotient of the division

If:
N ( x) × 2 n R( x)
= Q( x) + ,
G ( x) G ( x)
 29

Then:
N ( x) × 2 n + R( x)
= Q( x)
G ( x)

Calculation at the transmitter end, first stage:

• Let N(x) be a 8 bit long frame (k=8).
• Let the generator polynomial be a 5 bit number (n=4).
• Then FCS = R(x) will be a 4 bit number.
• Let the data frame = 11001001.
• The transmitter shifts the data frame to the left by 4 places. This is equivalent to
Frame x 24 = 11001001 0000 or simply to adding n zero bits at the end of the frame.
• Select a generator polynomial of 10001.
• The generator polynomial must always remain the same for the network. There is no
hard and fast rule for the selection of this polynomial. Some polynomials work
better than others but, in general, CRC checking detects 99.8% of all errors.
• The transmitter divides the shifted data frame by the generator polynomial using
Modula 2 division:

111000101 = Q( x)
10001 110010010000

• The remainder = 0101 = FCS. Therefore, the transmitted result is:

DATA FCS
11001001 0101

Calculation at the receiver end, second stage:

• The receiver divides the transmitted frame (including FCS) by the generator
polynomial:

10110110 = Q( x)
10001 110010010101

• In this case, the remainder equals zero, R(x) = 0000, indicating a correct reception.
• If there is an error in the received data e.g.

1100010 = Q( x)
10001 110010010111

this will result in R(x) = 0010 * 0.

1.4.7 Network Operational Models

In all networks where the transmission media is shared between nodes in the
network, each node is normally assigned a network address. This address is what
determines the destination for the data i.e. the node intended to receive the information.
 30

In most networks the frame format of the message will have both the source and
destination addresses encoded in it. The general format of a frame is shown below.

Destination address Source address Data Error Check

The SOURCE information allows the DESTINATION to determine where to send a

response (if required). There are several operational models of network/fieldbuses used
in industry and some of the more important ones are discussed in the following.

1.4.7.1 Master/Slave Networks

In a Master/Slave network the source address is often omitted as the response from
any node is always directed at the master. This type of system is inherently a one-to-one
data exchange process i.e. there is no possibility of transmitting to several nodes at the
same time. The model is shown in Figure 1.31.

Figure 1.31 Master/Slave model

Transferring information from slave A to slave C requires four telegrams in this type
of network. The master requests to read inputs from slave A. Slave A sends a response
with the input information encoded in it. The master then requests to write this data to
slave C (data in request). Finally slave C confirms the write request has been successful.
The example of this type of network/fieldbus is AS-I (Actuator Sensor Interface).
In the Master / Slave model, data update rates may be slow with an increase in the
number of nodes and more computational effort is required by the master for each new
node added to the network, as the master must poll each node in turn to retrieve data.

1.4.7.2 Peer-to-Peer
Figure 1.32 shows the Peer-to-Peer configuration. In a Peer-to-Peer network, nodes
may communicate directly with one another and the source/destination address scheme
allows the destination node to reply to the source node.
 31

SOURCE DESTINATION Message Contents

REQUEST A C “I want to read your inputs”
RESPONSE C A “My data is …………….”

Figure 1.32 Peer-to-Peer fieldbus topology

This type of network uses MAC methods such as token passing techniques to
control which node can gain access to the bus and therefore initiate a request. Data
transfer is still done on a one-to-one basis but the network loading is less than that of a
Master/Slave network. MODBus-Plus and LONWorks networks work using this type of
topology.

1.4.7.3 Producer/Consumer Model

In a Producer/Consumer network messages are identified by their content. If a node
needs a particular piece of data, it consumes it (accepts it). The frame format contains
an identifier field that uniquely determines the data content, a data field and an error
check field. An example of this type of topology is illustrated in Figure 1.33.
In this example node D is configured to receive or consume data with the same
identifier as that of the frame produced by node A.

Figure 1.33 Producer/Consumer model

 32

It is also possible to perform multicast operations whereby several nodes are

configured to consume information with the same identifier. This is shown in Figure
1.34.

Figure 1.34 Multicast Producer/Consumer model

It is also possible to configure nodes to consume more than one item of data i.e.
several different frames with different identifiers. In the Producer/Consumer model,
network loading is considerably reduced as only one telegram is required per data
transaction. Multicasting is not possible with Master/Slave and Peer-to-Peer networks.
On the other hand it is possible to emulate both of these systems on a
Producer/Consumer network. Multicast operations allow all or a subset of nodes on the
network to receive data at the same time. Therefore, multicasting is ideal for application
control and network management where all nodes need to be coordinated together. Note
that Producer/Consumer networks still need MAC methods to prevent two or more
different producers from transmitting at the same time. Producer/Consumer networks
also eliminate the need to poll for data i.e. data may be produced when an event occurs
i.e. change of state of inputs on a device, timer events, etc. Examples of networks using
this model are ControlNet, Foundation Fieldbus and the Controller Area Network.

1.4.8 Network Performance

The performance of a network is a result of the combined effects of several factors
such as:
• Number of Nodes - generally, the more nodes on the network the higher the network
load, as larger amounts of data need to be transmitted between various points on the
network. Distance can also effect overall speed due to propagation effects.
• Baudrate - the sheer speed at which bits are transmitted on the bus. The faster the
network the less time is required to transmit a frame and as a result more time is
available for other nodes to transmit their data. Therefore the baudrate is often used
as a measure of performance but it is not necessarily an accurate measure due to the
way in which MAC is implemented and the way the messaging works.
• Frame Size - generally, the larger the frame size the more time elapses before
another node can transmit its data. This results in slower response times. Note that
latency in a network is the time taken between a node wishing to transmit its data
and actually transmitting it. Therefore, longer frame lengths generally mean higher
latency.
• MAC Method — time absorbed or taken in media access control that could be used
for transmission of data e.g. time taken to pass a token.
 33

• Network Model - the more frames required to transfer data between two nodes the
slower the data update times due to higher network loading.
• Protocol Efficiency - measured as the total number of bits in the frame compared to
the number of data bits in the frame i.e.

N Data
Protocol Efficiency =
N Frame

Unfortunately, if the number of data bits is large compared to the total number of
frame bits the protocol efficiency is high but the reaction time of the network may be
reduced. This is due to the fact that a node transmitting a large amount of data will take
up network bandwidth and other nodes cannot transmit their data.
Network performance for two types of MAC systems is illustrated in Figure 1.35.

Figure 1.35 Comparison of CSMA/CD and Token Ring performance

The graphs show the mean time a frame takes to be transferred across the network
as a function of the offered load. The load is expressed as the fraction of the available
bit rate and is referred to as normalised throughput. The transfer time is defined as the
time from generation of the frame to the time it is successfully received. The graphs
were calculated from simulations where each network had 100 stations randomly
wishing to transmit data on the network.
From graph (a), it can be concluded that token bus systems behave less effectively
than CSMA/CD networks when the frame size is small. This is because, in this instance,
the time taken to pass the token round to the node wishing to transmit is significantly
longer than for a CSMA/CD network which can transmit as soon as the carrier is free.
In the second graph, token bus networks perform much better than CSMA/CD
networks as the longer frame size means that a CSMA/CD network must wait longer
(carrier sense) before trying to transmit a frame. In either case, the probability of a
collision occurring in a CSMA/CD network increases as the network load or throughput
increases. This reaches a critical state when the throughput or network loading
 34

approaches 70%. At this point a node may be continually trying to gain access to a
network and continually colliding with other nodes or backing off due to sensing of a
carrier.

1.5 NETWORK SELECTION CRITERIA

Several criteria must be considered when choosing a network/bus for a particular
Distributed Control Application. Issues such as physical characteristics, network layout,
maximum distances, simplicity and flexibility in network configuration, product
availability and proprietary rights (i.e. whether or not a network is 'open') must be
considered.

Figure 1.36 General procedure for selecting a network or bus system

Figure 1.36 shows a general procedure for selection of a fieldbus or network. The
procedure was developed by Professor Gerhard Gruhler with contribution from other
members of the ASPIC Consortium (ASPIC Project, 1992 - 1995). This procedure
begins on one hand with the specification of the application requirements and on the
other hand with the gathering and evaluation of data of the bus systems. It is vital that
the requirements of the application are classified as to their relative importance so that
the results of a comparison of how well the characteristics of the evaluated bus systems
match these requirements can be correctly evaluated and, ultimately, a choice can be
made.
In this process, the basic network architecture and network characteristics must be
evaluated with regard to reaction times, maximum transmission rates, transmission
modes, fault detection and error control, types of devices supported, etc. Cabling costs,
cost of nodes and interfaces to the network, installation and configuration costs must
also be recognised. Most importantly it must be assessed whether a licensing fee is
required or if the bus system is open and free to use. Additionally, the future
 35

requirements of the application, future support, component availability, number of

vendors, existing applications (proven technologies should be preferred) and suitable
standards must be strategically evaluated.
Young K, McLaughlin R T and Piggin R S H [1998] also published a
comprehensive treatment of the fieldbus selection problem. The referred authors
emphasise selection criteria such as vendor popularity, needs of distributed control
environment, openness of the fieldbus, interoperability testing of products, conformance
testing of products, availability of products, data bus length requirement,
communication specifications e.g. speed, model, Medium Access Control capability and
system configuration possibilities.
Let us divide the bus system selection criteria into two general categories, which
encompass the required principles: 'Technical Data' and 'Strategic Criteria'. These
categories are further specified below:

1. Technical Data:
• Geographical Criteria e.g. data bus length and expandability.
• Time Criteria e.g. speed, reaction time and propagation delay.
• Further Technical Criteria e.g. vendor/ user group representation,
communication model and simplicity and flexibility in network
configuration.
2. Strategic Criteria:
• Standards e.g. open or subject to proprietary rights and conformance
testing procedures.
• Availability of components, Software and Services
• Cost

The best possible route to compare several systems may be to select a hypothetical
application and analyse how each system can be used to fulfil the requirements of the
application. Each system can then be evaluated according to the criteria depicted in
Table 1.4.

Table 1.4 A general bus evaluation chart

Weight Factor Bus System 1 Bus System 2 Bus System n
Criteria …..
% % % %
1. Technical Criteria
1.1 Geographical Criteria
Evaluation No. 1.1
1.2 Time Criteria
Evaluation No. 1.2
1.3 Further Technical Criteria
Evaluation No. 1.3
2. Strategic Criteria
2.1 Standards
Evaluation No. 2.1
Availability of Components,
2.2
Software and Services
Evaluation No. 2.2
2.3 Costs
Evaluation No. 2.3
2.4 Further Strategic Criteria
Evaluation No. 2.4
Sum of Evaluation Points
 36

Table 1.5 An example of bus evaluation and selection

Weight Factor Bus System 1 Bus System 2 Bus System n
Criteria …..
% % % %
1. Technical Criteria 50
1.1 Geographical Criteria 10 100 95 78
Evaluation No. 1.1 10 9.50 7.80
1.2 Time Criteria 20 96 85 91
Evaluation No. 1.2 19.20 17.00 18.20
1.3 Further Technical Criteria 20 85 78 62
Evaluation No. 1.3 17.00 15.60 12.40
2. Strategic Criteria 50
2.1 Standards 5 51 54 74
Evaluation No. 2.1 2.55 2.70 3.70
Availability of Components,
2.2 15 71 50 75
Software and Services
Evaluation No. 2.2 10.65 7.50 11.25
2.3 Costs 20 74 48 63
Evaluation No. 2.3 14.80 9.60 12.60
2.4 Further Strategic Criteria 10 66 34 69
Evaluation No. 2.4 6.60 3.40 6.90
Sum of Evaluation Points 100% 80.80 65.30 72.85

Most information will be available from the data sheets of the bus systems. The
important issue is to give weighting to various criteria based on their importance
according to the application's requirements. A hypothetical example of the procedure
for selecting a bus is illustrated in Table 1.5.
A weighting factor is assigned to each criterion based on the classification of
application requirements. Each bus system is then evaluated according to each criterion
and a percentage score is given to each one according to how well they perform. Let us
say that the overall maximum points that a bus may gain is a figure of 200. If the bus
system scores 135 out of 200, then the equivalent percentage will be 135/200 or 67.5%.
The formula for calculating the final evaluation result is that of multiplying the group
weighting factor by equivalent percentage, e.g. in this example for the particular case of
bus number 1 and criterion 2.1 the final evaluation result is 15 * 71% = 10.65%.
In the example above, bus number 1 would be selected because it scored better than
the others did. However, in a different application a different bus could have been
selected based on a different weighting allocated to each requirement.
This hypothetical example is based on the extensive evaluation criteria developed
during the EEC project ASPIC. The weighting factors are based on the experience of
several manufacturers forming the ASPIC consortium.

1.6 CONCLUSIONS
Having explored the benefit of the fieldbus systems, it is worth noting that one of
the most prominent higher layer systems on the market is CANopen. It was developed
by the European Community to increase the competitiveness of the market with the
view that SME's should not be tied to major manufacturers. Also it was meant to relieve
the EEC manufacturers' dependency on automation products from the fieldbus
technologies emerging from countries outside the EEC.
CANopen is an ideal networking system for all types of automated machinery. One
of the distinguishing features of the CANopen protocol is its support for data exchange
at various levels of complexity, e.g. at the control level as well as with simple sensors
and actuators. This particularly avoids the use of gateways and bridges, which will add
 37

to the cost of implementations. CANopen is a networking system based on the CAN

serial bus. It assumes that the device's hardware has a CAN transceiver and CAN
controller as specified in ISO 11898. In the following chapters CAN and CANopen
technologies will be thoroughly investigated.
 38

CHAPTER 2
CAN: Controller Area Network
Chapter Objectives
When you have completed this chapter you should:
• Know some of the history of the development of CAN.
• Understand CAN technology.
• Understand how CAN is related to the ISO/OSI Reference Model.
• Identify and understand the Frame format used in CAN.
• Understand the MAC system used in CAN.
• Know the general organisation of a CAN controller.
• Differentiate Basic and Full CAN technology.
• Understand CAN message filtering.
• Understand CAN error handling.
• Identify stand alone and embedded CAN technology.

2.1 INTRODUCTION
CAN is a serial bus system especially suited for networking several intelligent
devices, including sensors and actuators, within a machine or an automation cell. It is a
serial bus system with multi-master capabilities i.e. where several CAN nodes can try to
transmit data at any point in time. Consequently, in CAN, simultaneous transmission
attempts by several nodes may occur. Each message carries an identifier that establishes
a priority system: the node with the highest priority will gain access to the bus and the
remaining nodes (with lower priority) will back off. The identifier is a number carried in
a particular field of the CAN message and it determines the priority of that message: the
higher the priority the faster the bus access. The CAN bus does not need addressing of
subscribers or nodes in the conventional or peer-to-peer manner. Instead messages are
sent to all CAN nodes. Each node then decides, on the basis of the identifier received,
whether the message is intended for that node and if it should process the message. The
relative simplicity of the CAN protocol means that very little cost and effort is required
for training the engineers working in the field.
The Controller Area Network (CAN) was originally developed in the 1980s by
Robert Bosch GmbH in an attempt to solve communication problems between different
control systems in cars. In fact, one of CAN's first uses was the interconnection of
control components such as Anti-Block Systems (ABS) and Acceleration Skid Controls
(ASC). The complexity of the control functions implemented by these systems requires
data transfer mechanisms, which would normally be implemented using dedicated
control lines. However, as the complexity of such devices increased, the number of
control lines and connections required also increased, leading to a situation where in
many of today's car control components the sheer number of control lines has reached
its maximum physical limit. Furthermore, there are now a number of systems in cars,
which require data exchange between several devices. For example in ASC, engine
timing and carburettor control are required when wheel slippage occurs. Additionally,
the information consumed and produced by the ASC will be used by other systems in
the car to accomplish their own tasks. What better than to link such devices via a single
 39

set of wires, minimising the number of connections, where data can be quite freely
exchanged, not just between two devices but between several, all at the same time? This
is the basic idea behind CAN.
Needless to say it was not long before this idea migrated from vehicles into the
machinery markets. Nowadays CAN has found its way into diverse areas such as
agricultural machinery, medical instrumentation, elevator controls, fairground rides and
industrial automation control components. It is because of its widespread use (especially
in cars) that a large number of semiconductor manufacturers now produce CAN
devices, making CAN semiconductors relatively inexpensive. The fact that companies
such as Philips, Motorola, National Semiconductors, Siemens and Intel (to name but a
few) are involved in developing CAN technology is a trustworthy indicator that this
technology is guaranteed well into the future.
The original CAN specification, released by Robert Bosch GmbH, is now called
CAN Specification 2.0 - Part A. The reason for this is that an upgraded CAN
specification was released subsequently by the same company, containing both Part A
and a new version of CAN called Part B. CAN Specification 2.0 - Part B, is upward
compatible with CAN Specification 2.0 - PART A. The main difference between the two
versions lies in the fact that the former defines a CAN message format with 11-bit
identifier field, while the latter allows the use of an extended 29-bit identifier. The CAN
Specification 2.0 is in the public domain.
In this chapter the most important aspects of the CAN specification relating to
CANopen protocol will be introduced. CAN Specification 2.0 - Part B will be adopted
not only because it encompasses Part A but also because nowadays most CAN
hardware implementations comply with this newer version of the specification, even if
only passively.
In 1993, CAN became an ISO standard. The ISO Draft International Standard with
reference ISO 11898 is based on the CAN Specification 2.0 but it adopts the classic
CAN message format with 11-bit identifiers. The ISO 11898 standard relates CAN to
the ISO/OSI Reference Model, specifying the CAN Physical Layer, and the CAN Data
Link Layer.
CAN Specification 2.0 did not define a complete Physical Layer for CAN, although
some of the requirements that need to be met by the Physical Layer are specified. These
requirements are, in short, bit encoding/decoding, bit timing and synchronisation. In
fact, in this specification most of the Physical Layer was left for the user to define as
application specific. Therefore, it was necessary, for the purpose of ISO 11898, to set
down a proper Physical Layer definition. Today the ISO 11898 CAN Physical Layer
definition is used throughout the CAN world and has also been adopted in CANopen
and hence will be discussed in this Chapter in more detail.
The functionality specified in the CAN Specification 2.0 can be interpreted, in terms
of the ISO/OSI Reference Model, as being a two layer protocol, as shown in Figure 2.1.
 40

Figure 2.1 The CAN protocol and the ISO/OSI Reference Model

In parallel with the specification laid in ISOl 1898 standard, another standard based
on the CAN Specification 2.0 was specified: ISOl 1252. The difference between the two
standards lies in the Physical Layer definitions. ISOl 1252 covers the usage of the CAN
protocol at lower communication speeds than that specified in the ISOl 1898. As such,
the requirements for the implementation of the Physical Layer in ISOl 1252 are less
demanding, making it a cheaper solution. However, the number of applications using
ISOl 1252 is very small when compared with applications based on ISOl 1898.

2.2 CAN PHYSICAL LAYER

The physical medium typically used to implement CAN networks is a differentially
driven two-wire bus line with common return. The two wires are called CAN_H and
CAN_L, according to the polarity of the differential voltage between them. The CAN
bus must also be terminated at both ends by resistors with a recommended value of
124Q (Figure 2.2).

Figure 2.2 Block diagram of a CAN network

 41

The maximum length of the CAN bus depends on the baudrate at which it will be
used. CANopen specifies a set of recommended baudrates that should be implemented
by CANopen devices. (For each of these baudrates the recommended bus lengths are
also specified in CANopen, as shown in Table 2.1.) CANopen additionally specifies
that the implementation of the 20Kbit/s baudrate is mandatory for all CANopen devices.

Table 2.1 Baudrates and bus lengths recommended by CANopen

Baudrate Bus Length
1 Mbit/s 25 m
800 kbit/s 50 m
500 kbit/s 100 m
250 kbit/s 250 m
125 kbit/s 500 m
50 kbit/s 1000 m
20 kbit/s 2500 m
10 kbit/s 5000 m

The bit representation used for transmitting messages in the CAN bus is NRZ (non-
return-to-zero) coding that guarantees maximum efficiency in bit coding. However, the
need for frequent transitions on the bus (in order to maintain synchronisation) demands
the implementation of a bit-stuffing mechanism. This bit-stuffing mechanism consists in
the sender inserting a stuff-bit after five consecutive bits of the same polarity (i.e. five Is
or five 0s). The stuff-bit is of reversed polarity in order to force the occurrence of
transitions on the CAN bus (e.g. five Is will be followed by a 0). The receiver removes
the stuff-bits before processing the message. This mechanism is also used for error
control as will be seen in the following sections.

2.2.1 Bit Timing Configuration

In order to explain the typical process of configuring a CAN controller for
communication at a particular baudrate, it is necessary to introduce concepts defined in
the CAN specification concerning bit timing. The CAN specification defines three
timing parameters:
• The Nominal Bit Rate is basically the number of bits per second that corresponds to
the desired communication baudrate.
• The Nominal Bit Time is defined as 1 / Nominal Bit Rate. The bit timing
configuration of a CAN implementation is defined in terms of the Nominal Bit Time
parameter.
• The Time Quantum is a fixed unit of time derived from the oscillator period. In
CAN implementations there will be a programmable pre-scalar ranging from 1 to 32
through which the Time Quantum parameter will be programmable from a value of
one Minimum Time Quantum to a value of 32 times the Minimum Time Quantum.

The process of programming a particular baudrate consists of establishing the

duration of the Time Quantum and, subsequently, the duration of the Nominal Bit Time
with basis on the Time Quantum. The structure of the Nominal Bit Time parameter is
defined in the CAN specification as a set of time segments (Figure 2.3).
 42

Figure 2.3 Structure of the Nominal Bit Time parameter

The SYNC_SEG is the part of the bit time used to synchronise the different clocks
on the nodes connected to the bus and where the transition from the previous bit to the
current bit is expected to lie. The PROP_SEG accounts for propagation delays on the
bus. Finally, the segments PHASE_SEG1 and PHASE_SEG2 can be automatically
adjusted by the CAN controller to compensate for synchronisation errors, within certain
limits specified by the programmer. In CANopen it is recommended that, by default
configuration, the bit timing in a node should be prepared to support maximum
propagation delay in the bus i.e. the synchronisation and timing features within the
module/node must be programmed for maximum delay tolerance.
Programming the length of the time segments, shown in Figure 2.3, the total length
of the Nominal Bit Time can be established at the desired value (i.e. at the value that
corresponds to the desired Nominal Bit Rate). Furthermore, the sample point can be
placed at different, locations within the bit time. The CAN specification places the
following limitations on the lengths of the segments:
• The SYNC_SEG must be always 1 Time Quantum long.
• The PROP_SEG is programmable to be 1 to 8 Time Quanta long.
• The PHASE_SEG1 is programmable to be 1 to 8 Time Quanta long.
• The PHASE_SEG2 must be equal to the maximum of PHASE_SEG1 and the
information processing time of the CAN implementation. It is also specified that this
information processing time must be kept smaller than two Time Quanta.

The way in which the configuration of these parameters is performed will depend on
the CAN controller's implementation. As an example, let us take the embedded CAN
controller in the C167 microcontroller from Siemens. The bit timing configuration of
this CAN controller is performed by programming the following bit fields in the bit
timing registers:
• Baudrate Prescaler (BRP) - this parameter permits setting the Time Quantum at
2(BRP+1)·CPU Clock.
 43

• Time Segment before Sample Point (TSEG1) - this parameter comprises the
PROP_SEG and the PHASE_SEG1. It can be set to a value ranging from 2 to 15,
indicating TSEG1+1 Time Quanta before the sample point (not including the
SYNC_SEG).
• Time Segment after Sample Point (TSEG2) - this parameter comprises the
PHASE_SEG2. It can be set at a value ranging from 1 to 7, indicating TSEG2+1
Time Quanta after the sample point.
• Synchronisation Jump Width (SJW) - this parameter sets the maximum number of
Time Quanta that can be inserted or removed by the CAN controller from the
PHASE_SEG segments to maintain synchronisation at SJW+1. The SJW parameter
can take values from 0 to 3.

The CAN controller in question provides access to these parameters through a 16-bit
register shown in Figure 2.4.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
r TSEG2 TSEG1 SJW BRP
Figure 2.4 Bit Timing Register in the C167's embedded CAN controller

To program the CAN controller to operate at a baudrate of W00Kbit/s with the CPU
clock running at 20MHz, the timing parameters could be configured as:
• BRP = 0, setting the Time Quantum at 0.lµs.
• TSEG2 = 7, setting the PHASE_SEG2 and the PHASE_SEG1 at 2 Time Quanta.
• TSEG1 = 6, setting the PROP_SEG at 5 Time Quanta.
• SJW = 3, because in CANopen one must always set the controller to the maximum
propagation delay tolerance.

With this configuration the sample point would be set at 8 Time Quanta within the
bit time i.e. at 80% of the bit time. For most applications the sample point will be set at
around 75% to 88%. This allows for any distortion effects on bit levels that may be
caused by signal propagation and the transmission media, particularly in systems
operating at higher bit rates.

2.2.2 Physical Connection

The connection of a CAN controller to the CAN bus must be done using a CAN
transceiver that complies with ISO11898. An example of such a transceiver is the
82C250 chip from Philips, which is widely used in CAN implementations. The
connection between the CAN controller and the transceiver may be direct or it may be
performed using optical isolation. The use of optical isolation is important for protection
of the device from electrical overloads originating elsewhere on the bus. Additionally, if
all devices in a CAN network use optical isolation, the common return will be
expendable and only two wires are required for communication: CAN_H and CANJL.
A direct connection between the CAN controller and the CAN transceiver will look
somewhat like the circuit in Figure 2.5. The TxD and RxD signals are straightforward
serial signals that the microcontroller uses to send and receive information. The
transceiver converts these signals to and from the differential format used in the CAN
bus.
 44

Figure 2.5 Direct connection between the CAN controller and the CAN transceiver

Some CAN controllers interpret the serial signals TxD and RxD differentially rather
than comparing them to ground. When this is the case there will be four wires
connecting the controller to the transceiver: TxO, Txl, RxO and Rxl. Two of these
wires, namely RxO and TxO, will usually be connected to the reference voltages: TxO
on the controller side and RxO on the transceiver side.
An optically isolated connection between the CAN controller and the CAN
transceiver is illustrated in Figure 2.6.
The optocouplers used for this purpose must be high-speed optocouplers specially
designed for this type of application. An example of this type of component is the
HCPL-7710 from Hewlett Packard. The recommended electronic topology for this type
of application can be found in the corresponding datasheets and application notes
published by the manufacturers.
It is common for CAN transceivers to allow the designer to control, up to a certain
point, the R.F.I, generated by the CAN network. This is usually done by changing the
value of a resistor connected to the transceiver that controls the slope of the transitions
on the bus. The steeper the slopes, the higher the R.F.I, generated by the network.

Figure 2.6 Optically isolated connection between CAN controller and transceiver

Regarding the physical connection to the CAN bus, CANopen recommends a

standard 9-pin D-Sub connector (DIN41652), according to DS102 (Figure 2.7). DS102
is the CAN in Automation (CiA) defmition for a CAN Physical Layer in industrial
applications. However, other types of connectors are allowed, ranging from 5-pin Mini
Style connectors to multi-pole connectors.
 45

Figure 2.7 Standard 9-pin D-Sub connector

The pin assignments for the type of connector in Figure 2.7 are shown in Table 2.2.

Table 2.2 CAN connector pin assignments

Pin Signal Description
1 Reserved
2 CAN L CAN_L bus line (dominant low)
3 CAN_GND CAN Ground
4 Reserved
5 (CAN_SHLD) Optional CAN Shield
6 (GND) Optional CAN Ground
7 CAN_H CAN_H bus line (dominant high)
8 Reserved (error line)
Optional CAN external positive supply (dedicated
9 (CAN_V+) for supply of transceiver and optocouplers, if
galvanic isolation of the bus nodes applies)

A detailed description of the electronic connection to the CAN bus is not necessary
for the purpose of this book but it is important to explain how this connection works in
general terms, as it is the basis for the Data Link Layer's operation. This will be done in
the following section.

2.2.3 CAN Bus Basic Operation

A CAN bus and the nodes connected to it behave, in theory, as the wired-AND
circuit illustrated in Figure 2.8.

Figure 2.8 Wired-AND configuration

 46

Each of the transistors shown in the diagram in Figure 2.8 represents the connection
of a CAN node to the CAN bus. Each node can transmit a logic 1 by switching the
transistor off (VCC appears between the bus lines) or a logic 0 by switching the
transistor on (0V appear across the bus lines). This circuit implements what is called a
wired-AND configuration because all modules must be transmitting a logic 1 in order to
have a logic 1 on the bus. In other words, to have a logic 0 on the bus, it is sufficient
that a single node transmits a logic 0. This is the reason why a bit of value 0 is called a
Dominant bit in the CAN bus system, and a bit of value 1 is called Recessive.
As was mentioned earlier, this mechanism is the basis for the operation of the CAN
Data Link Layer, which is discussed in the following section.

2.3 CAN DATA LINK LAYER

The Data Link Layer can be divided into two sub-layers: the Medium Access
Control and the Logical Link Control. The Medium Access Control is responsible for
determining which node in the network is assigned the control of the bus for message
transmission. The Logical Link Control ensures that the higher layers in the network are
provided with an interface that is independent from the underlying layers. In other
words, this sub-layer must ensure that the Physical Layer and the Medium Access
Control are transparent to the upper layers. In practice, this means that the Logical Link
Control is responsible for the detection and correction of errors when data are
exchanged through the bus i.e. it must implement an error-safe transmission
mechanism.

2.3.1 Frame Formats

In order to be able to carry out its tasks, the CAN Data Link Layer assembles the
data to be transmitted into Data Frames such as the one shown in Figure 2.9. The Data
Frame format shown is defined in the CAN 2.0-Part B specification for 11-bit identifier
messages.

Figure 2.9 The CAN 2.0-Part B data frame

As shown in Figure 2.9, the CAN Data Frame is composed of a number of fields:
• Start Of Frame (SOF) Field - This field is composed of a single synchronisation
Dominant bit.
• Arbitration Field - This field has two components. The first one is an 11-bit
identifier, which establishes the message's priority and its identity. The second
component is the Remote Transmission Request bit (RTR) which, if set Dominant,
indicates the Frame contains Data and, if set to Recessive, indicates a Remote
Frame. Remote Frames are exactly the same as Data Frames except that they carry
 47

no data and they are used to request the transmission of a data frame with the same
identifier by another node on the bus.
• Control Field - this field has three components. The first is the Identifier Extension
(IDE) bit which, if set Recessive, indicates the transmission of messages with 29-bit
identifiers, as defined in the CAN 2.0-Part B specification. If the IDE bit is set
Dominant it indicates a standard 11-bit identifier. The second component is a
reserved bit (rO), which may be used in future versions of CAN. The last
component is a 4-bit long Data Length Code (DLC), which holds the data byte count
for the message. The DLC field can have values ranging from 0 to 8, indicating the
number of data bytes in the frame.
• Data Field - this is the field where data bytes are sent and can hold between 0 and 8
bytes of data.
• Cyclic Redundancy Check (CRC) Field - this field is used for error checking and
contains a 15-bit CRC code followed by a Recessive delimiter bit.
• Ack. Field - this field is used to ensure that a message has been successfully
received by other node(s). Message reception is acknowledged by inserting a
Dominant bit in the first bit position inside this field, which is always transmitted as
Recessive but is expected to be detected by the transmitter as Dominant. If the Ack
Slot, as it is called, is not filled by a receiver node with a Dominant bit, the
transmitter then knows that the message has not been received correctly and the
transmission is aborted. The second bit position in this field is a Recessive bit
delimiter.
• End of Frame Field - this field is composed of seven recessive bits.

In addition to Data Frames and Remote Frames, the CAN protocol also uses Error
Frames and Overload Frames.
Error Frames are composed of six consecutive bits of the same polarity. These
frames intend to violate the bit-stuffing rule that was mentioned when discussing the
CAN Physical Layer. This is the usual way for aborting transmission of the frames in
which errors were detected. Error Frames are called Active if they are composed of six
Dominant bits and Passive if they are composed of six Recessive bits. The usage of
these frames will be discussed in a forthcoming section.
The details of Overload Frames are not relevant for the purpose of this book.
However, it is important to note that a receiver may use these to delay the transmission
of Data Frames or Remote Frames when it is not ready to receive them.
All CAN frames must be followed by at least three Recessive bits. This is called an
Intermission period. After Intermission the bus goes Idle, meaning that a new
transmission can be initiated.

2.3.2 Message Filtering

When a data frame is transmitted on the bus, no station is addressed. Instead each
message is designated by a unique identifier, shown in Figure 2.9 as the 11-bit identifier
in the Arbitration Field. If a node wishes to transmit information it simply passes the
data and the identifier to its CAN controller and sets the relevant transmit request. It is
then up to the CAN controller to format the message contents and transmit the data in
the form of a CAN frame. Once the node has gained access to the bus and transmitted
its message, all other nodes become receivers. Having received the message correctly,
the nodes then perform an acceptance test to determine if the data is relevant to that
 48

particular node. This process is called message filtering. The way the filtering is
handled by the designer will depend on the CAN controller being used. This issue will
be further discussed later in this chapter.
It is logical to conclude Chat it is not only possible to perform communication on a
peer-to-peer basis, where a single node accepts the message, but also to perform
broadcast and synchronised communication, whereby multiple nodes can accept the
same message using only a single transmission. The ability to send data on an event
basis means that bus loading is reduced i.e. messages are sent on the basis of necessity
rather than having a fixed schedule for message transmission. This concept is known in
the networking world as the Producer/Consumer mechanism. One difference between
CAN and other fieldbus solutions is that this mechanism requires no interaction from a
bus master or arbiter: it follows the multi-master concept.

2.3.3 Bus Arbitration

The identifier in a CAN message also defines the priority of the message and is the
basis for the Medium Access Control mechanism. The operation of the Medium Access
Control can be described as follows:
• When a device detects that the bus is free for transmission, it starts to transmit a
message.
• During the transmission, the device keeps monitoring the bus, checking if the bus is
responding to its transmission.
• If, during the transmission of the Arbitration Field, the node attempts to transmit a
Recessive bit but it detects a Dominant bit on the bus, it stops the transmission and
waits for the bus to be free again so that the process can restart. Note that, if a bit
error is detected outside the Arbitration Field, or if inside the Arbitration Field when
transmitting a dominant bit, then the bit will be considered erroneous and the node
will use the CAN error signalling mechanisms to abort the transmission. An
exception to this rule is of course the Ack. Slot in the Ack. Field where the
transmitter sends a Recessive bit and expects to detect a Dominant one as
acknowledgement.

It was mentioned in a previous section that a Dominant bit placed by a node on the
bus always prevails over any number of Recessive bits placed on the bus by other
nodes. Hence, a node attempting transmission will only keep control of the bus if the
message it is transmitting has the numerically lowest identifier. This mechanism is the
essence of the Medium Access Control in CAN and an example of its operation is
shown in Figure 2.10.
 49

Figure 2.10 Example of the operation of the CAN MAC mechanism, courtesy of Mr. R.
McLaughlin (ODVA)

The Medium Access Control mechanism in CAN is called 'non-destructive bitwise

arbitration', for the obvious reasons, and it can be classified as a CSMA/CD mechanism.
It ensures a non-centralised, non-destructive bus allocation method, based on priority
and need, which is ideal for real-time distributed control applications.
Note that this scheme means that no bandwidth is wasted during the arbitration
process. Ethernet (for example) also uses CSMA/CD but if there is a collision between
two nodes, one node will transmit a jamming signal, causing both nodes to back off the
bus. Both nodes will then wait a random period before trying to retransmit. The bus
arbitration process used by CAN means that the node with the highest priority
(transmitting the message with lowest identifier) will continue to transmit without
having to back off the bus. This gives the CAN bus a deterministic and predictable
behaviour (no random waiting) and very efficient bandwidth use of the bus. In fact, it is
possible to have CAN networks operating at near 100% bus bandwidth, although this is
not recommended.

2.3.4 Error Handling

In addition to the Medium Access Control, the Data Link Layer is also responsible
for the Logical Link Control, whereby a reliable transmission mechanism is provided by
the CAN Data Link Layer, through the implementation of a series of error detection
mechanisms. The mechanisms are:
• Bit Error - a node that after transmitting the Arbitration Field is still in control of the
medium keeps monitoring the bus, checking if it is responding correctly to the
transmission. This permits the detection of both global bus errors and local
transmission errors by the transmitter. There are of course exceptions to this rule,
such as the transmission of a Recessive bit and detection of a Dominant bit both in
the Arbitration and in the Ack. Fields.
• Bit Stuffing Error - it was mentioned previously that bit stuffing is used to ensure a
minimum number of transitions occur on the bus, for synchronisation purposes. This
 50

feature is also used for transmission error control: when a receiver detects six
consecutive equal bits, it knows that a bit stuffing error must have occurred.
• Cyclic Redundancy Check Error - the cyclic redundancy check is performed using
the CRC Field in the CAN frame. The transmitter calculates a CRC code based on
the contents of the message it is sending and inserts the code on the CRC Field. At
the receiver end, the CRC code is recalculated and compared to the one received. If
the codes are different, a CRC error has occurred.
• Form Error - there is a mechanism built into CAN that verifies the structure of the
transmitted frame by checking bit-fields within it against the fixed frame format and
the fixed frame size.
• Acknowledgement Error - it has been mentioned before that all recipients
acknowledge messages by introducing a Dominant bit in the Ack. Slot in the Ack.
Field of the message. If this doesn't happen, it is clear that a transmission error has
occurred and no node has received the message accurately.

A CAN node detecting a transmission error is able to abort the transmission by

sending an Error Flag to the other nodes on the bus. The type of Error Flag (Active or
Passive) depends on the error status of the device. In fact, with respect to the error
status, a device can be in one of three states:
• Error Active - the device is completely sure that an error has occurred and that this
error was not its own fault. In this state, errors are signalled using Active Error
Flags. As mentioned previously, an Active Error Flag is composed of six Dominant
bits so that any transmission on the bus is disrupted: it violates the bit stuffing rule,
preventing other nodes from accepting the erroneous message and triggering a
retransmission attempt by the sender.
• Error Passive - when the device detects an error, it suspects that the source of that
error might be local. For this reason errors are now signalled using Passive Error
Flags. Since Passive Error Flags are composed of six Recessive bits, the
transmission is generally only aborted if the device is the transmitter of the message
or if it is the only receiver.
• Bus-off - the device believes that it is the cause for the error i.e. it is not capable of
communicating correctly. Therefore, the erroneous node ceases to participate in the
communication so as not to disturb the other nodes in the bus. This state particularly
prevents erroneous nodes from flooding the bus and as a result it allows normal
functioning of the other nodes.

To determine in which error state the node is, CAN specifies that each unit must
implement two error counters: one for transmit-errors and the other for receive-errors.
These counters work under a rather complex algorithm, in short, their counts increase
when errors are detected and decrease on successful message transfers. When the CAN
devices are reset they begin to operate in Error Active mode. As errors begin to occur,
the error count increases and eventually they reach a threshold beyond which the node
enters the Error Passive state. If the errors persist, the error counts will keep increasing
until the node shuts itself off, entering the Bus-off state.
If it were not for this mechanism, e.g. if CAN units remained in the Error Active
state regardless of the number of errors detected, this could lead to the loss of all
messages e.g. if a faulty node wrongly assumed that all the messages in the bus were
erroneous. For this reason, this mechanism is called a Fault Confinement feature. The
 51

Fault Confinement system was included in CAN with the aim of making a station
capable of recognising its own defects and possibly entering an operating mode where
the network is not affected by them.

2.4 CAN HARDWARE IMPLEMENTATIONS

When implementing any kind of device that communicates using CAN, the designer
does not have to be concerned with the CAN communication itself, since all of the
functionality required to handle it is implemented in the hardware. These CAN
hardware implementations are commonly called CAN Controllers. All that is required
from the designer is:
• Basic knowledge of how the CAN protocol works.
• Implementation of the hardware interface between the CAN controller and the CAN
bus (possibly also between the CAN controller and the microprocessor).
• Ability to program the CAN controller according to the needs of the application.

In this section these issues will be discussed in more detail.

2.4.1 CAN Controller Organisation

There are different ways in which the CAN protocol is implemented in the various
CAN controllers available on the market. Although the type of communication that can
be achieved is identical for all implementations of the CAN protocol, there are
differences regarding the extent to which the controller takes over message handling.
However, all CAN controllers share a common structure such as the one shown in
Figure 2.11.

Figure 2.11 Typical structure of a CAN controller

The functional blocks in Figure 2.11 perform the following tasks:

• The CPU Interface Logic (CBL) executes commands from the processor running the
software and controls data transfers on the CAN serial bus. Global status and control
 52

registers as well as the control bits in the communication objects are used primarily
by the CPU interface logic.
• The Bit Stream Processor (BSP) controls the data stream between the message
buffer memory (parallel data) and the bus line (serial data). It controls the entire
protocol, differentiates between the frame types and detects frame errors.
• The Error Management Logic receives error messages from the bit stream processor
and, in turn, sends back information about the Error State to the bit stream processor
and the CPU Interface Logic.
• The Bit Timing Logic (BTL) determines the timing of the bits and maintains the
CAN controller synchronised with the edges of the bit stream on the CAN bus. It
monitors the bus through a differential input comparator and determinesthe bit
timings related to the serial bus. The BTL synchronises on a transition at the start of
the frame and re-synchronises on further transitions during reception of the frame.
The BTL also provides programmable time segments to compensate for the
propagation delay times and phase shifts discussed above.
• The Transceiver Control Logic (TCL) consists of bit stuffing logic, programmable
output driver logic, CRC logic and data shift registers. The BSP co-ordinates these
individual elements. Reception, arbitration, transmission and error signalling are
performed by the TCL.
• The Message Buffer Memory stores individual CAN objects for transmission or
reception. The CPU communicates only with this area in order to transmit and
receive messages.The CPU Interface Logic manages the data exchanges.
• The Clock Generator is simply used to derive a suitable clock frequency for the
CAN controller based on the frequency of an external clock oscillator.

2.4.2 Basic CAN vs Full CAN Implementations

With respect to message filtering, two broad categories of CAN implementations
can be identified. These categories were formerly known as Basic CAN and Full CAN
implementations. The distinction between the two is becoming less and less important,
considering most of the newer Full CAN controllers also provide the functionality of
Basic CAN.
In Full CAN controllers, individual sections or objects of the message buffer
memory (see Figure 2.12) are reserved for the reception or transmission of CAN frames,
with pre-set programmable identifiers. When receiving a message, if the identifier
matches the one programmed into the header of the object, the data are stored in that
object or memory area. If the identifier does not match any of the programmed object
identifiers, the message is rejected by the hardware. This type of arrangement can save
the designer a great deal of trouble when writing the CAN software, in comparison to
what is required in Basic CAN controllers.
 53

Figure 2.12 Principles of Full CAN operation

In Basic CAN controllers the controller receives all messages irrespective of their
identifier and puts them into a single or dual receive message buffer. It is then up to the
processor collecting the incoming messages to accept or reject these messages.
Therefore, a software receive routine is invoked every time a CAN message is received,
regardless of whether the CAN message is intended for the application or not. This can
add a large amount of software and processing overhead for an application. Overheads
may be reduced in some instances as a Basic CAN controller will normally have an
acceptance filtering scheme allowing the controller to accept all or a subset of the CAN
identifier range. In a Philips 8x592 microcontroller and the Motorola 68HC05X family
of microcontrollers, for example, the filter consists of an Acceptance Mask (AM)
register and an Acceptance Code (AC) register, as shown in Figure 2.13.
Both the Acceptance Code and Mask registers are normally eight bits in length and
the filtering is based on the top 8 bits of the CAN identifier. The Acceptance Mask
register defines whether the corresponding bits in the Acceptance Code register and the
CAN identifier must match to pass the acceptance test (this is done by setting the must-
match bits in the Acceptance Mask to zero).
In Figure 2.13, ID1 fails the acceptance test whilst ID2 passes. It should be noted
that the identifier bits for which the Acceptance Mask has a value of 1 are not taken into
consideration. The same applies to the last three bits of the identifier over which there is
no filtering control. Therefore, if the Acceptance Code in the example is set to
01110111 in binary (119 in decimal), and all bits in the Acceptance Mask are set to
must-match, (the top 8 bits of the identifier must equal the 8 bits of the Acceptance
Code), then a range of identifiers from 952 to 959 decimal will pass the filtering test of
the CAN controller. Obviously, the software must perform further filtering if only some
of these messages are to be accepted.
 54

Figure 2.13 Basic CAN acceptance filtering registers

2.4.3 Stand-alone vs Embedded CAN Controllers

Regarding the way in which a CAN controller may be integrated into a product, a
distinction needs to be made between stand-alone CAN controllers and embedded CAN
controllers. Depending on the hardware requirements of each application, particularly in
what concerns the microcontroller that is used, one of these solutions will be more
suitable than the other.
Stand-alone CAN controllers are CAN hardware implementations encapsulated in
one physical integrated circuit. Because of this, these chips need also to implement all
the functionality required to share a data bus and to function as a typical peripheral in
microprocessor-based circuits. An example of a standalone CAN controller is the
SJA1000 chip from Philips.
Embedded CAN controllers are CAN hardware implementations that are provided
as an additional embedded peripheral within a microcontroller. This type of CAN
controller is implemented in the same chip as the microprocessor and therefore all the
physical connections that are needed between the two devices are already there. An
example of a microcontroller that provides an embedded CAN controller is the C167
chip from Siemens.
The two approaches are shown in Figure 2.14. Note that the connections with the
transceivers (drivers) are different in each case, meaning that, depending on the
hardware, different solutions may apply.
 55

Figure 2.14 Variants of CAN hardware

2.4.4 Overview of the CAN Hardware Market

Finally, it is important to transmit to the reader the idea that the range of CAN
hardware products available on the market is broad. This is true for both transceivers
and CAN controllers, but more so for the latter, as can be seen in Table 2.3 and Table
2.4.
A number of different manufacturers produce bus driver or transceiver chips and a
few of them are shown in Table 2.3.

Table 2.3 A selection of transceiver chips

Part Number Max Speed Manufacturer
SN75LBC031D 500 kbit/sec Texas Instruments
UC5350 1 Mbit/sec Unitrode
82C250, 82C251 1 Mbit/sec Philips Semiconductors

Table 2.4 Standalone and integrated CAN controllers

Part Number Extended ID Microcontroller Manufacturer
FM2C Yes 16-bit Fujitsu
H8/300H Yes 16-bit Hitachi
AN 82527 Yes None Intel
AN87C196CA Yes 16-bit Intel
68HC05X4 No 8-bit Motorola
M37630 E4/M4 Yes 8-bit Mitsubishi
COP684BC Passive 8-bit National Semiconductors
µPD70F3xxx Yes 32-bit NEC
P8X592/8 No 8-bit Philips
ST10F167 Yes 16-bit SGS Thompson
SAE81C90/91 Passive None Siemens
C167CR Yes 16-bit Siemens
TMP88PP87 Yes 8-bit Toshiba
TCG54AF Yes None Toshiba

Table 2.4 shows a list of some of the integrated and standalone CAN controllers
available. This is by no means an exhaustive list and many other variants exist (the
same should be noted for Table 2.3). Most of the manufacturers listed here produce
more than one CAN product. Note that most of these CAN controllers support the
extended 29-bit identifier range although some only support 29-bit identifiers passively
i.e. they can be used on the same network as CAN controllers using the extended 29-bit
ID but they use standard 11-bit identifiers only.
 56

CHAPTER 3
Introduction to CANopen
Chapter Objectives
When you have completed this chapter you should:
• Know the history of the development of CANopen.
• Understand the CANopen Communication Model.
• Know the structure of a CANopen Object Dictionary.
• Understand the basic CANopen communication mechanisms: PDO and SDO.
• Understand the principle of PDO mapping.
• Know other pre-defined CANopen objects such as the Synchronisation and
Emergency Objects.
• Understand the CANopen boot-up procedure.
• Know the CANopen pre-defined connection set of identifiers.
• Understand the usefulness of Electronic Data Sheets and Device Configuration
Files.
• Know what DS301 and DS302 stand for.
• Be able to construct a CANopen network.

3.1 BACKGROUND
The CAN specification can be mapped onto the two lower layers of the ISO/OSI
Reference Model: the Physical Layer and the Data Link Layer. The CAN Data Link
Layer offers services for transferring and requesting data units no longer than 8 bytes.
These services were sufficient for the original universe of applications in which CAN
was to be used. However, in more complex distributed applications, additional
functionality is required, such as the co-ordinated initialisation of nodes or the
transmission of blocks of data longer than 8 bytes.
In ISO/OSI terms, this means that higher layer services are needed. This was the
reason why the CAN in Automation (CiA) organisation specified the CAN Reference
Model and, within it, the CAN Application Layer (CAL), which is a standard for the top
protocol layer in CAN based systems. The application horizon of CAN was greatly
broadened when the CAL was released and, nowadays, CAL is used in a wide spread of
application fields ranging from medical applications to traffic control.
The CAN Reference Model and the way in which it relates to the ISO/OSI
Reference Model are shown in Figure 3.1.
As can be seen in Figure 3.1 the CAN Reference Model is a three layer model
containing only the Physical Layer, the Data Link Layer and the Application Layer,
which is common in fieldbus protocols.
 57

Figure 3.1 CAN Reference Model

The Physical Layer and the Data Link Layer of this model have already been
discussed in Chapter 2. The Application Layer is, in general terms, the interface
between the data communication environment and the application that uses this
environment to co-operate with other applications. This interfacing is also the task for
which the CAN Application Layer was designed. The reasons for not implementing the
remaining layers in the ISO/OSI Reference Model are as follows:
• Network Layer - the Network Layer is supposed to handle the interconnection of
several networks. As inter-networking never happens in CAN, the services of this
layer were not needed.
• Transport Layer - the purpose of this layer is to guarantee the reliable transfer of
messages of arbitrary length over unreliable networks. In real-time systems,
however, if a transfer fails, it is very likely that the data being transferred are no
longer valid when a new attempt to transfer is made: every transfer attempt stands
on its own and the reliability offered by CAN is sufficient for this type of
application. Furthermore, if an application does need to transfer messages of
arbitrary length, the CAN Application Layer incorporates services for this transfer.
Hence, the services of a Transport Layer are not required in the CAN Reference
Model.
• Session Layer - in real-time control applications the concept of a session is
meaningless and the services offered by the Session Layer are not applicable.
• Presentation Layer - the Presentation Layer basically deals with the encoding of the
data and keeping track of its meaning across the network. In the CAN Reference
Model, a set of basic data types are defined that must be used by all applications to
describe their data. There are also encoding rules that specify how these data types
should be transferred. Additionally, it is assumed that the meaning of the data is
known by all applications beforehand so that the functionality of the Presentation
Layer is no longer required.
 58

In the CAN Reference Model, communication between applications can be achieved

by employing the services provided by the CAN Application Layer. These services
permit the exchange of information through the CAN bus, using the services of the Data
Link and Physical Layers according to the protocol specified inCAL.
The CAN Application Layer provides a large number of services, which are divided
by four application layer entities, according to their nature. These entities are:
• CAN-based Message Specification (CMS) - offers an open, object-oriented
environment in which to design user applications. It is a language used to specify
what COBs (Communication Objects, CAN messages with particular message
identifiers) a module uses and how they are formatted, and it can describe all CAN
Data Link Layer features. The CMS uses variable, event and domain objects to
specify how the functionality of a module can be accessed through its CAN
interface. It also includes data encoding rules that define how to encode and decode
application data into the transfer syntax and vice-versa.
• Network Management (NMT) - offers an open, object-oriented environment in
which one module (the NMT Master) is able to deal with the initialisation and
possible failures of the other nodes (the NMT Slaves). The NMT entity provides the
basic tools for the construction and maintenance of distributed applications.
• Distributor (DBT) - handles an essential problem in building a CAN application, i.e.
the allocation of message identifiers (COBs). An identifier determines a message's
priority and therefore the identifier values used by a particular CAN module cannot
be fixed by its manufacturer. Instead, the systems integrator must have total control
over them. The DBT offers a mechanism for dynamic distribution of the identifiers
by one module (the DBT Master) to the other nodes (the DBT Slaves).
• Layer Management (LMT) - offers the possibility to let a LMT Master node control
the settings of certain layer parameters in other modules, called the LMT Slaves.

Usually the master functionality of NMT, DBT and LMT will be centred on one
device that controls the operation of the network. This, however, is not mandatory and
the functions can be performed by different devices.
As will be seen in the next section, CANopen was defined based on the CAN
Application Layer. In fact, in CANopen networks, only a subset of the services
specified in CAL is used; although it must be stressed that for more than 95% of
applications using CAN, this subset is more than adequate. For this reason, the details of
all the services defined in the CAL will not be described here. For more details about
the CAN Application Layer refer to the CAL documentation available from CiA.

3.2 ORIGIN AND STRUCTURE OF THE CANopen SPECIFICATIONS

A very important concept when discussing CANopen is the concept of a profile. In
network protocol terminology. a profile is a protocol specification that is based on other
existing protocol specifications. Usually, a profile defines a subset of the services
provided by the existing protocols that can be used for communication, and restricts the
way in which these services can be applied.
But how does this concept of a profile relate to CANopen? Very simply, the
CANopen specification is composed of a set of profiles that are based on the CAN
Reference Model discussed in the previous section. In fact, the profiles that are part of
CANopen are divided into two categories:
 59

• CANopen Device Profiles - a Device Profile defines the way the functionality of a
particular type of device is made accessible through the CAN bus, and what
CANopen Communication Profile tools are needed to access this functionality.
Conceptually there should be a Device Profile for each type of device that can be
used in an industrial environment, connected to a CAN bus. However, at present,
there are only a few standardised Device Profiles: I/O modules (DS401), Drives and
Motion Control (DS402), Human Machine Interfaces (DS403), IEC1131
Programmable Devices (DS405) and Encoders (DS406). Special groups within the
CiA are currently working on the development of new Device Profiles for various
categories of devices that are not yet covered by the existing specifications.
• CANopen Communication Profile, DS301 - the CANopen Communication Profile
is applicable to all devices. It defines how a subset of CAL services can be used to
communicate with a CANopen device and how this device is expected to behave.
All devices are required to implement DS301: the Communication Profile is the
standard interface between CAN and the CANopen Device Profiles. The CANopen
Communication Profile encompasses the real-time object-oriented communication
model as well as the protocols used by all devices in the network.

The CANopen specification relates these concepts to the ISO/OSI Reference Model
by defining the CANopen Reference Model, shown in Figure 3.2.
The CANopen Reference Model, shown in Figure 3.2, is an extended version of the
CAN Reference Model discussed in the previous section. In fact, the CANopen profiles
provide a framework for the development of applications that use CAL services to
communicate. Furthermore, CANopen devices are forced to use CAL in a compatible
way, so that a systems integrator has only to choose the right devices and to perform
minor configuration tasks when building a distributed system. This is an important
advantage of CANopen (and one of the main reasons for its development) when
compared to CAL, where a systems integrator would have to spend a considerable
amount of time devising a way of modelling its application in terms of CAL concepts.
In short, CAL provides a set of communication tools but leaves it to the systems
integrator to figure out how to use them to implement each distributed application.
CANopen complements CAL, defining a standardised way of using CAL services to
implement distributed applications and freeing the systems integrator from this task.
This concept is illustrated in Figure 3.2 where it can be seen that CANopen expands
above the limits set by the ISO/OSI Reference Model and into the domain of the user
application. In fact, the CANopen Device Profiles can be seen as an additional layer
(some authors call it a User Layer or Layer 8) on top of the ISO/OSI seven-layer model,
effectively constraining the way in which distributed applications can be implemented.
 60

Figure 3.2 CANopen Reference Model

Since their first release, the CANopen profiles have been revised a number of times
with the objective of making CANopen a self-contained protocol specification that can
be internationally accepted as a standard. In fact, the latest CANopen Communication
Profile release (version 4.0) contains significant changes regarding its predecessors that
make it virtually independent from the CAN Application Layer specifications. This
approach brings great improvement to the readability of the specification as one is no
longer referred to other documents for a detailed description of the communication
protocol rules. Another factor that contributed to make DS301 more accessible to the
reader was that it was possible to discard some of the CAN Application Layer
terminology that did not quite fit in the CANopen context and adopt a more coherent
terminology.
The CANopen profiles define mandatory and optional requirements for devices.
Mandatory requirements are essential for CANopen compatibility and interoperability
and, as such, they must be implemented in all devices, from the most simple to the most
complex. On the other hand, optional requirements may or may not be implemented in a
device. These are often called 'nice to have' features; they are not critical for the
operation of the system and can therefore be left out in the case of simple devices.
However, when these optional features are implemented, this must be done according to
the specification. Additionally, and for the sake of generality, a device may implement
manufacturer specific features which are not covered in either the optional or the
mandatory parts of the CANopen profiles. Hence, the profiles do not constrain future
developments: they cater for new functionality.
 61

3.3 CANopen APPLICATION LAYER FUNCTIONALITY

3.3.1 Introduction
The CANopen Communication Profile divides the Application Layer functionality
into several Service Objects, each offering a specific functionality and all services
related with this functionality. When an application invokes a CANopen service to
communicate with a remote CANopen device, the Service Object offering the referred
service will interact with a peer Service Object on the remote CANopen node to carry
out the data exchange operation (Figure 3.3).

Figure 3.3 CANopen Service Objects

According to the ISO/OSI Reference Model, an application interacts with the

underlying Application Layer, for every service invocation, using four general types of
service primitives:
• Request - issued by the application to the Application Layer to request a service.
• Indication - issued by the Application Layer to the application to report that a
network event has occurred or that a service has been required from the application
by another node.
• Response - issued by the application to the Application Layer as a reply to an
indication.
• Confirmation - issued by the Application Layer to the application to report on the
result of a previously issued request.

According to the service primitives that are used in their invocation, Application
Layer services can be classified as:
• Local service - only a Request is used, in which the application triggers a local
network event.
• Provider-initiated service - only an Indication is used, signalling to the application
the occurrence of a local network event.
• Unconfirmed service - an application produces a Request, which requires that an
Indication must be given to an application running in another node.
• Confirmed service - following the same procedure as for an Unconfirmed service,
the remote application then issues a Response. This Response is the11 signalled to
the local application in the form of a Confirmation primitive.
 62

These concepts, also used in CANopen for Application Layer service

specification, are summarised in Figure 3.4.

Figure 3.4 Types of Application Layer services

In Chapter 2 it was emphasised that in CAN, the network on which CANope11 is

based, the Data Link Layer offers a broadcast service of identified messages, s°
messages are not sent to a particular application in a remote node. In fact, each
application has to decide whether or not it will receive the data carried by a
Communication Object (COB). The decision on whether or not to accept a message is
based on the identifier of the message, which also identifies the dat:a being transferred.
This feature makes the CAN network a 'message-oriented protocol'. Therefore, in a
CAN network, the receiving applications are not know11 by the transmitter. This
message-oriented nature of CAN is preserved in the services provided by CANopen.
In short, CAN is highly flexible in the types of communication mechanisrris that it
can be used to implement. In CANopen this flexibility is noticeable in the diversity of
communication relationships that can coexist in the network, involving two or more
devices.
In fact, a CANopen device will be involved, at any moment in time, in multiple
communication relationships with multiple nodes in the network. These communication
relationships can belong to one of three basic communication models:
• Master/Slave.
 63

• Client/Server.
• Producer/Consumer.

The different types of communication relationships will be described in more detail

in the following sections.

3.3.2 Master/Slave Communication Relationships

In Master/Slave interactions one device, the Master, is responsible for coordinating
one particular aspect of the operation of the network, communicating with all the other
devices in the network, the Slaves.
The services that CANopen offers, at the Application Layer level, based on
Master/Slave communication are related to network management mechanisms. These
services can be confirmed or unconfirmed as shown in Figure 3.5.

Figure 3.5 Master/Slave communication

3.3.3 Client/Server Communicatio n Relationships

Client/Server relationships involve only two devices. It is a peer to peer interaction
in which one device, the Client accesses (i.e. reads or writes) data in another device, the
Server.
The services that CANopen offers, at the Application Layer level, based on
Client/Server communication are used typically for off-line device configuration. These
services are always confirmed whereby the Client issues a request to download or
upload data and expects a response from the Server indicating the result of the operation
(Figure 3.6).
 64

Figure 3.6 Client Server communication

3.3.4 Producer/Consumer Relationships - Push/Pull Model

In Producer/Consumer relationships the functionality of CAN is used,
unconstrained, at the Application Layer level. One device is said to be the Producer of a
particular piece of data that it can transmit on the bus. There may be any number of
devices on the network (even no devices at all) that pick up this data whenever it is
transmitted on the bus. These devices receiving the data are called Consumers.
The services that CANopen offers, at the Application Layer level, based on
Producer/Consumer communication are typically used for on-line real-time exchange of
process data. These services can be confirmed or unconfirmed. Confirmed services in
Producer/Consumer interactions are said to follow the Push model. Similarly,
unconfirmed services are said to follow the Pull model. Figure 3.7 illustrates these
concepts.

Figure 3.7 Producer/Consumer communication

It is important to note that any one of the Consumers may invoke a confirmed
service at any moment in time.
 65

3.4 CANopen OBJECTS AND THE OBJECT DICTIONARY

3.4.1 Device Modelling in CANopen
CANopen uses an object-oriented approach to the definition of standard devices:
each device is represented as a set of objects that can be accessed through the network.
Every aspect of the operation of a device is mapped onto one or more of these objects. It
is therefore possible to change the configuration or the status of a device simply by
using the network to alter the attributes of a particular object within it.
The CANopen model of a device is depicted in Figure 3.8.

Figure 3.8 CANopen model of a device

From Figure 3.8 it follows that there are two basic types of objects:
Communication Objects - these objects are instances of the Service Object classes
defined in the CANopen Application Layer. Each represents a specific communication
functionality within the device. Communication Objects are specified in the CANopen
Communication profile.
Application Objects - these objects represent device-specific functionality such as
the state of an input digital signal and they are defined in the Device Profile that applies
to the device.
All the objects in a device can be accessed through an Object Dictionary where they
are represented. This principle is shown in Figure 3.8 that shows the Object Dictionary
interacting with all the objects within the device. The Object Dictionary is the most
important part of the device model since it is a map to the internal structure of the
device: if the structure of the Object Dictionary of a particular device is known, then
everything that is needed to build a distributed application using this device is also
known. In other words, knowing a device's Object Dictionary makes it possible to
predict the device's behaviour on the network.
Based on the functionality they offer, Communication Objects can be divided into
two general categories:
 66

• Communication Objects for Network Management - this type of Communication

Object permits establishing Master/Slave communication relationships in the
network and can be used for global device control and status checking i.e. network
management. One object of this type is shown in Figure 3.8 interacting with the
device's state machine which determines, according to the state of the device at a
particular moment in time, which parts of the device's functionality are enabled. The
state machine of a CANopen device will be discussed in Section 3.8.
• Communication Objects for Application Data Transfer - this type of
Communication Object may be further divided into two categories:
• Some objects provide indexed access to all the objects within the device, via the
Object Dictionary, by means of a Client/Server communication relationship with
another device. The device whose Object Dictionary is being accessed is the
Server in this relationship. Using these Communication Objects it is possible to
access all the features within the device, typically for configuration purposes.
However, since this type of object requires data channelling through the Object
Dictionary, their operation is not suitable for real-time access to Application
Objects due to excessive protocol overhead. An example of this type of
Communication Object is the Service Data Object.
• Other objects (shown on the bottom left of Figure 3.8) provide direct access to
Application Objects making it possible to implement real-time synchronous and
asynchronous data exchange mechanisms. This type of Communication Object
follows the Producer/Consumer philosophy involving minimal protocol
overhead for maximum efficiency. Process Data Objects are an example of this
type of mechanism.

As a consequence of the previous classification of Communication Objects,

Application Objects can also be divided in two general groups also shown in Figure 3.8:
those that can be accessed in real-time using dedicated Communication Objects and
those that can only be accessed via the Object Dictionary.

3.4.2 CANopen Data Types and Encoding Rules

Depending on the property that a particular object represents, this object may be
composed of just one simple attribute or it may be more complex with several attributes.
Objects with just one attribute are treated in CANopen as simple variables, and they are
of simple (static) types such as FLOAT, B00LEAN, STRING or INTEGER. More
complex objects, with more than one attribute, are treated as ARRAYs or RECORDS.
An ARRAY is used to represent a collection of attributes of the same data type and a
RECORD represents a collection of attributes of different data types.
An example of a simple object that may be represented by a simple variable is the
Device Type object, which is stored as a single 32-bit unsigned word. On the other
hand, an ARRAY may be used to represent the digital outputs of an I/O module. If a
device of this type has 2 sets of 8 digital outputs, these may be assigned to a single
object represented by an ARRAY with two elements of the 8-bit unsigned type. Finally,
RECORDs can be used, for example, to represent different parameters associated with a
CAN message that a device transmits: the identifier (e.g. unsigned 16 bit word), the type
of data exchange that is used (e.g. unsigned 8 bit word), the minimum time between
transmissions (e.g. unsigned 16 bit word), etc.
 67

The pre-defined static and complex data types specified in DS301 are shown in
Table 3.1.

Table 3.1 DS301 Data Types

Static Complex
B00LEAN UNSIGNED8 REAL64 PDO COMMUNICATION
INTEGER8 UNSIGNED16 VISIBLE STRING PARAMETER
INTEGER16 UNSIGNED32 OCTET STRING PDO MAPPING
INTEGER24 UNSIGNED24 DATE PARAMETER
INTEGER32 UNSIGNED40 TIME OF DAY SDO COMMUNICATION
INTEGER40 UNSIGNED48 TIME DIFFERENCE PARAMETER
INTEGER48 UNSIGNED56 BIT STRING IDENTITY
INTEGER56 UNSIGNED 64 DOMAIN
INTEGER64 FLOAT

The data type of a particular attribute of an object within a CANopen device

determines the way in which the value this attribute is stored in a CAN message when it
is transferred. In fact, CANopen defines a set of data encoding rules that must be
applied to all application data that is transferred.
CANopen specifies the data encoding rules in two basic steps. Firstly CANopen
states how a generic stream of bits containing application data should be organised in
the CAN messages used to transfer it. Secondly, CANopen specifies how each
particular data type can be converted in a bit stream to which the former rule can be
applied.
The details about the CANopen data types and data encoding rules can be found in
DS301.

3.4.3 Object Dictionary Structure

The entries in an Object Dictionary i.e. the objects, are referenced by a simple
addressing scheme consisting of an unsigned 16-bit Index and an unsigned 8-bit Sub-
index.
The Sub-index is used in different ways according to the object type. For a simple
object consisting of a single attribute the Sub-index for the object is always 00H. For an
ARRAY or RECORD, the Sub-index references individual elements of the ARRAY or
RECORD, and Sub-index 00H is used to store the number of elements. For STRING
objects, Sub-index 00H indicates the length of the STRING (STRINGS are treated as
ARRAYS of characters or UNSIGNED8 values). Each array or record can only have up
to 254 elements since Sub-index FFH is reserved. In fact, the contents of Sub-index
FFH are pre-defined in CANopen: if it is implemented, it must contain information
about the type of the object at that index using special coding defined in DS301.
Objects are stored in the Object Dictionary according to their function. Furthermore,
certain Index ranges are reserved for specific object function groups as shown in Table
3.2.
 68

Table 3.2 Object Dictionary organisation

Index Object
0000 Not used
0001-001F Static Data Types
0020-003F Complex Data Types
0040-005F Manufacturer Specific Data Types
0060-007F Device Profile Static Data Types
0080-009F Device Profile Complex Data Types
00A0-0FFF Reserved
1000-1FFF Communication Profile Area
2000-5FFF Manufacturer Specific Profile Area
6000-9FFF Standardised Profile Area
A000-FFFF Reserved

The Index range below 1000H is used to indicate data type definitions, which are
represented in the Object Dictionary only for reference purposes and that are described
in the device's documentation. These entries can, however, be implemented as read-only
objects that hold the bit-length (in the case of simple types) or structure (in the case of
complex types) of an object of that particular type. Table 3.3 shows the CANopen pre-
defined data types and the corresponding object Index. These definitions are mainly
used for compatibility across different computing platforms e.g. the Index for a
particular type definition can be used as an unambiguous code that indicates the type of
a given attribute.

Table 3.3 Representation of DS301 Data Types in the Object Dictionary

Index Data Type Index Data Type
0001 B00LEAN 0011 REAL64
0002 INTEGER8 0012 . INTEGER40
0003 INTEGER16 0013 INTEGER48
0004 INTEGER32 0014 INTEGER56
0005 UNSIGNED8 0015 INTEGER64
0006 UNSIGNED16 0016 UNSIGNED24
0007 UNSIGNED32 0017 (reserved)
0008 FLOAT 0018 UNSIGNED40
0009 VISIBLE STRING 0019 UNSIGNED48
000A OCTET STRING 001A UNSIGNED56
000B DATE 001B UNSIGNED 64
000C TIME OF DAY 001C-001F (reserved)
000D TIME DIFFERENCE 0020 PDO COMM. PARAMETER
000E BIT STRING 0021 PDO MAPPING PARAMETER
000F DOMAIN 0022 SDO COMM. PARAMETER
0010 INTEGER24 0023 IDENTITY

The Index range from 1000H to 1FFFH is reserved for objects that represent
CANopen Communication Profile parameters. They are used in a CANopen network by
all devices. Every device will implement these entries in the same way and, therefore,
the configuration of communication parameters can be performed in the same way for
every device.
The Index range from 2000H to 5FFFH is reserved for objects that represent
manufacturer specific features of a device.
 69

The Index range from 6000H to 9FFFH is reserved for objects that represent
features of a device that are standardised in the corresponding Device Profile. In fact, a
Device Profile is essentially the definition of the meaning of these entries for a
particular type of device.

3.4.4 Object Dictionary Representation

An overview of the Object Dictionary of a device is normally shown in a tabular
form, similar to the one in Table 3.4.

Table 3.4 Example of an Object Dictionary

Index Object Access
Name Type M/O
(hex) (Symbolic Name) Attribute
0001 DEFTYPE Boolean
0005 DEFTYPE Unsigned8
0006 DEFTYPE Unsignedl6
0007 DEFTYPE Unsigned32
0009 DEFTYPE Visible string
0020 DEFSTRUCT PDO Communication Parameter
0021 DEFSTRUCT PDO Mapping
0022 DEFSTRUCT SDO Communication Parameter
1000 VAR Device type UNSIGNED32 ro M
1001 VAR Error register UNSIGNED8 ro M
1002 VAR Manufacturer status register UNSIGNED32 ro O
1003 ARRAY Pre-defined error field UNSIGNED8 ro O
1008 VAR Manufacturer device name VISIBLE STRING ro O
1009 VAR Manufacturer hardware version VISIBLE STRING ro O
100A VAR Manufacturer software version VISIBLE STRING ro O
1200 RECORD Server SDO Comm. Parameter SDO COMM. PAR. ro M
1400 RECORD 1st receive PDO Comm. Parameter PDO COMM. PAR. rw O
1600 ARRAY 1st receive PDO Mapping Parameter PDO MAPPING PAR. rw O
6000 ARRAY Read 8 input lines UNSIGNED8 ro O
6200 ARRAY Write 8 output lines UNSIGNED8 rw O

The six columns in the table indicate the following object characteristics:
• The Index for the object, in hexadecimal format. This is used as a 16-bit address to a
given object within the Object Dictionary. The Sub-index is not specified here, since
it is only relevant inside each object. The structure of individual objects is shown
separately.
• The Object's Symbolic Name, which specifies an object code, used for reference
purposes and for standardisation across different computing platforms. These codes
are listed in Table 3.5.
• The Name of the object, which contains a simple textual description of the function
of the object.
• The Type of the entry, which may be simple or complex. The types may also be pre-
defined or manufacturer (device) specific.
• The Access Attribute of the object, which defines the access rights to the object:
read only (ro), write only (wo), read/write (rw) or read only access of a constant
value (const). There are two additional possible values for this parameter, which are
read/write from process input (rww) and read/write from process output (rwr). These
additional values allow automatic tools to check if an entry is suitable for mapping
on a receive PDO (rww) or a transmit PDO (rwr).
 70

• The M/O attribute of an object, which indicates if the implementation of this object
is mandatory or optional.

Table 3.5 Object Codes

Object Name Comments Code
NULL Empty dictionary entry 0
DOMAIN Large variable amount e.g. executable program code 2
DEFTYPE Simple type definitions such as UNSIGNED8, FLOAT, etc. 5
DEFSTRUCT Record type definition. 6
VAR Simple variable of types such as a B00LEAN, UNSIGNED32 7
ARRAY Multiple attribute object consisting of a collection of VARS of the same type 8
RECORD Multiple attribute object consisting of a collection of VARS with differing types 9

When a detailed description of the Object Dictionary is needed, each object entry is
then described separately and, for each complex object, the meaning of each Sub-index
entry is also shown. Such a detailed description is given in both DS301 and in the
defined Device Profiles. This book does not provide a complete description of all
Object Dictionary entries and only the most relevant ones will be discussed.

3.4.5 Object Dictionary Implementation

The implementation of an Object Dictionary is straightforward. A CANopen device
merely has to be able to map its internal status in terms of the correct Object Dictionary
entries. In practice this means that when a remote node reads an Object Dictionary
entry, the device must be able to recognise which piece of internal information this
entry is representing, encode this information according to the CANopen rules, and
issue an appropriate response. Likewise, when an Object Dictionary entry is written by
a remote node, the device simply must be able to recognise which piece of local
information will be influenced by this operation, and alter its status accordingly.
In reality, depending on the device, the number of object dictionary entries that
actually need to be implemented is very small. As mentioned previously, all objects
below 1000H need not be implemented at all and are only listed in the Object
Dictionary for reasons of completeness. Additionally, special care was taken to keep the
number of mandatory Object Dictionary entries to a minimum in the CANopen
specification.
Objects not specified in the standard CANopen profiles are normally implemented
in the Index range 2000H to 5FFFH (the manufacturer specific area). No significant
restrictions are made, although it is required that these entries are thoroughly described
in the device's documentation. By allowing this flexibility, every device is catered for
and CANopen is said to be 'future-proof.

3.4.6 CANopen Communication Objects for Application Data Transfer

Application data are transferred using basically two types Communication Objects:
Service Data Objects (SDOs) and Process Data Objects (PDOs). Although both of them
can be used to transfer data between the devices that support them, SDOs and PDOs
offer different types of functionality, as shown in Table 3.6.
 71

Table 3.6 Comparison of SDO and PDO communication

Service Data Object (SDO) Process Data Object (PDO)
• High volume data transfers. • Low volume data transfers.
• Low priority data transfers. • High priority data transfers.
• Uses 16-bit Index and 8-bit Sub-index for
• Objects mapped into individual bytes of the
object addressing. CAN telegram data field. This information
can be configured using SDOs.
• Asynchronous transfers. • Synchronous or asynchronous transfers.
The former can also be cyclic or acyclic.
• Data transfers of more than 8 bytes are • Only data transfers of up to 8 bytes of data
possible using multiple CAN telegrams. using a single CAN telegram.

From Table 3.6 it is clear that SDO and PDO communication are used for different
purposes in a CANopen network.
In addition to SDOs and PDOs, CANopen defines Communication Objects that are
useful for the implementation of specific data exchange techniques. These objects are:
• Synchronisation Object — this object can be used to synchronise the operation of
CANopen devices.
• Time Stamp Object - this object can be used to establish a global time frame across
a CANopen network.
• Emergency Object - this object can be used for signalling of emergency situations in
CANopen networks which is essential for the implementation of error recovery
mechanisms.

The operation of Service Data Objects and Process Data Objects, as well as the
other Communication Objects defined in CANopen will be described in the following
sections.

3.5 SERVICE DATA OBJECTS

3.5.1 General Description
Service Data Objects are used to establish Client/Server relationships between two
CANopen devices whereby the Client device has read and write access to the Object
Dictionary of the Server device.
A Service Data Object implemented in a CANopen device is called Server SDO or
Client SDO depending on the part played by the device in the SDO relationship
established through that particular SDO. A CANopen device must implement at least
one Server Service Data Object through which it provides access to its Object
Dictionary. In addition, it is possible to implement more Server SDOs and any number
of Client SDOs, in both cases up to a maximum of 128 SDOs.
SDOs carry Index and Sub-index information, to allow object addressing in the
Object Dictionary. The combination of Index and Sub-index information is called a
Multiplexor since it makes it possible for a complex data structure such as the Object
Dictionary, composed of multiple sets of data, to be read and written unambiguously
through a single SDO communication link.
Two CAN message identifiers must be allocated to an SDO. One of them is used for
messages sent by the Client to the Server and the other one for messages sent in the
opposite direction. CANopen reserves a range of CAN message identifiers to be used by
devices for default SDO communication, as will be discussed in Section 3.8.4.
 72

The two CANopen services used for SDO transfers are called SDO Download and
SDO Upload and they can be used for writing and reading from the Object Dictionary
respectively. However, given that the data transferred to/from an Object Dictionary
entry is of arbitrary length i.e. it can vary from only a few bytes up to tens of thousands
of bytes depending on the object that is accessed. SDO transfers can follow one of three
procedures that are more suitable for particular circumstances:
• Segmented Transfer - general procedure that can be used in every transfer.
• Expedited Transfer - procedure optimised for very small pieces of data.
• Block Transfer - procedure optimised for large pieces of data.

The particular procedure to be used in each transfer will depend on the

implementation. However, the CANopen specification states that expedited transfers are
of mandatory implementation and that they must be used for data not greater than 4
bytes in lengths. Segmented transfers must be implemented if a device supports objects
that require the transfer of data greater than 4 bytes in length. Block transfers are
optional.
The protocols used by these mechanisms will be described in the following sections.
It is important to note that in these protocols it is always the Client who initiates a SDO
transfer but both Client and Server can take the initiative to abort the transfer. Also note
that in the SDO transfer protocols, the 8 bytes in the CAN data field are always
transmitted, even if they contain meaningless data.

3.5.2 Segmented SDO Transfer

A segmented SDO transfer is the basic type of SDO transfer from which all other
SDO transfer procedures are derived. The data is transferred as a sequence of segments,
carried in successive confirmed exchanges of CAN messages. Prior to transferring the
segments there is an initialisation phase where the devices agree on what and how data
should be transferred.
The general procedure for segmented SDO transfers is shown in Figure 3.9.

Figure 3.9 General format for segmented SDO read and write operations
 73

When the Client wishes to access the Server's Object Dictionary, it begins by using
either an Initiate SDO Download or an Initiate SDO Upload message. This message will
inform the Server that a transfer has been requested and triggers a response indicating
whether or not the transfer can be carried out.
Following this initialisation stage, a succession of Upload or Download Domain
Segment messages will be used to transfer a series of data segments to/from the Server,
until all the data have been transferred. In Figure 3.9 it is clear that in Upload operations
the data is transferred from the Server to the Client and in Download operations it is
transferred in the opposite direction.

3.5.2.1 Segmented SDO Download

The SDO Download service can be used by the Client to write to the Server's Object
Dictionary. Although the protocol for the SDO Download service must be implemented
as a whole, the procedure for segmented downloads is specified as two sub-services for
easier understanding:
• Initiate SDO Download - through this service, the Client asks the Server to prepare
for receiving data i.e. for a data download. This service is confirmed and the
response will indicate either the success or the failure of the operation. If the
operation is successful, then the Download SDO Segment service can be used to
transfer the data.
• Download SDO Segment - this service is used by the Client to supply a new
segment of the data to the Server. It also indicates whether or not it is the last
segment in the transfer. Again the service is confirmed and the response will
indicate success or failure of the operation.
Figure 3.10 shows the protocol for the Initiate SDO Download service.

Figure 3.10 Initiate SDO Download

Figure 3.10 shows the data field of the CAN messages to be used in the protocol for
an Initiate SDO Download service. The data fields of the exchanged messages are
structured as a sequence of bit-fields, with the following functions:
• The CCS (Client Command Specifier) bit-field, stored in bits 5 to 7 of byte 0, is
equal to 1 indicating the Initiate SDO Download command.
• The X bits are unused bits and should always be set to zero.
• The E bit (bit 1 in data byte 0) indicates whether the transfer is Expedited (E = 1) or
Segmented (E = 0). Expedited SDO transfers will be discussed in the following
section.
• The S bit indicates whether or not the size of the data is indicated in bytes 4 to 7 of
the CAN message. If S is set to 0, then the size is not indicated.
 74

• The Multiplexor is stored in bytes 1 to 3 of the data field. The way in which this
attribute is coded in the telegram is determined by the CANopen data encoding
rules, applied to the data type of the Multiplexor. The Multiplexor is a composite
variable made of an UNSIGNED16 Index and an UNSIGNED8 Sub-index. The
Index is stored in byte positions 1 and 2 with the Least Significant Byte first. The
Sub-index is stored in byte position 3.
• The SCS (Server Command Specifier) contains the value 3, indicating a response to
an Initiate SDO Download command (bits 5 to 7 of byte 0 in the response telegram).

Error or failure indications are given using the Abort SDO Transfer service and
protocol described in Section 3.5.4.2.
The protocol for the Download SDO Segment service is shown in Figure 3.11.
For each segment downloaded, two messages are exchanged between Client and
Server, as shown in Figure 3.11. The request sent by the Client carries the segment of
data, as well as segmentation control information. The Server's response acknowledges
the reception of each segment.
The meaning of the CCS and SCS bit-fields is exactly the same as for the Initiate
SDO Download protocol. However, here, these fields hold the values of 0 and 1,
identifying the Download SDO Segment request and response messages, respectively.

Figure 3.11 Download SDO Segment

Additional bit-fields are used in the Download SDO Segment protocol for
segmentation control. These bit-fields are:
• The N field determines the size of the data held in bytes 1 to 7 of the CAN data
field. In fact, this field indicates the number of bytes in the telegram that do not
contain data. Its value can range from 0 to 7, and it will indicate that bytes 8-N to 7
will be empty. Note that a null value N means that all bytes contain data.
Additionally, since the maximum value of N is 7, at least one data byte will always
have to be transferred.
• Bit t is a toggle bit and its value alternates between 0 and 1 on successive Download
SDO Segment exchanges. For the first segment, bit t has an initial value of zero.
• The C bit is used to determine whether there are more segments to download. It is
set to 0 if there are more segments to download and to 1 if this is the last segment to
be downloaded.

On reception of the Domain SDO Segment request from the Client, the Server
responds with a message where the toggle bit t must match the toggle bit t in the Client
 75

request. This bit is used to synchronise requests and responses and an error should be
signalled if the toggle bits do not match.

3.5.2.2 Segmented SDO Upload

The SDO Upload service can be used by the Client to read from the Server's Object
Dictionary. Although the protocol for the SDO Upload service must be implemented as
a whole, the procedure for segmented uploads specified as two sub-services for easier
understanding:
• Initiate SDO Upload - through this service, the Client asks the Server to prepare for
transmitting data i.e. for uploading data to the Client. This service is confirmed and
the response will indicate either the success or the failure of the operation. If the
operation is successful, then the Upload SDO Segment service can be used to
transfer data.
• Upload SDO Segment - this service is used by the Client to request a new segment
of the data from the Server. Again the service is confirmed and the response carries
the requested segment of data or an error indication. The reply also indicates
whether or not it is the last segment in the transfer.

Error or failure indications are given using the Abort SDO Transfer service and
protocol described in Section 3.5.4.2.
The protocol for the Initiate SDO Upload service is shown in Figure 3.12.

Figure 3.12 Initiate SDO Upload

From Figure 3.12 it is clear that the Initiate SDO Upload protocol is very similar to
the Initiate SDO Download protocol. However, in the Upload case, the data to be
transferred flows from the Server to the Client in the response messages.
The Client initiates the transfer by issuing a request with a CCS of 2 that indicates
an Initiate SDO Upload request. Again, bytes 1, 2 and 3 contain the Multiplexor of the
data block being read. The Server response also has a SCS of 2, indicating an Initiate
SDO Upload response.
In segmented transfers the E bit is set to zero and bytes 4 to 7 indicate the size of the
total data to be uploaded (the observations that were made in the previous section
regarding the S bit apply equally in this protocol). Subsequent Upload SDO Segment
service invocations are then required for uploading the data.
The protocol of the Upload SDO Segment service is shown in Figure 3.13.
 76

Figure 3.13 Upload SDO Segment

For the Upload SDO Segment request, the value of the CCS is 3. Once again the
toggle bit t is used to denote alternate requests: it is set to zero for the first request and
toggled on subsequent requests.
On reception of the Upload Domain Segment request, from the Client, the Server
responds using an SCS of 0. The toggle t bit must match that of the request. The N bits
(bits 0 to 3 in byte 0) denote the number of bytes in the telegram that do not contain data
(bytes 8-N to 7). The C bit denotes whether more upload segments are to follow (C with
a value of 0) or that this is the last segment (C with a value of 1).

3.5.3 Expedited SDO Transfers

Expedited SDO transfers are a modified version of segmented SDO transfers where
the protocol is optimised for very small pieces of data, more precisely for data not
greater than 4 bytes in length.
In expedited transfers the data is carried in the initialisation messages themselves,
simplifying the transfer protocol greatly. The general procedure for expedited SDO
transfers is shown in Figure 3.14.

Figure 3.14 General format for expedited SDO read and write operations

Again, when the Client wishes to access the Server's Object Dictionary, it uses
either an Initiate SDO Download or an Initiate SDO Upload message. This message will
inform the Server that a transfer has been requested and, in the case of a download
operation it also carries the data to be written. The request triggers a response from the
Server indicating whether or not the transfer can be carried out. In the case of an upload
operation this response also carries the data to be read.

3.5.3.1 Expedited SDO Download

The protocol for expedited downloads is very similar to the protocol for segmented
SDO downloads. In the case of expedited SDO downloads, only the Initiate Domain
 77

Download service presented for segmented downloads is used. Figure 3.15 shows the
protocol for the Initiate SDO Download service in expedited transfers.
The distinction between segmented and expedited transfers is made by bit E. If it is
0 then the transfer is segmented. On the other hand, if bit E is 1 then it is an expedited
transfer.
In expedited SDO downloads the data is carried in byte positions 4 to 7 in the
message sent by the Client to the Server. Bit S (bit 0 in byte position 0) indicates if the
size of the data is carried in bit field N (S equals 1) or if the data size is not indicated at
all (S equals 0).
In fact, if the size of the message is carried in the message, bit field N actually
indicates the number of bytes in the telegram that do not contain data. Its value can
range from 0 to 3, and it will indicate that bytes 8-N to 7 will be empty. Note that a null
value of N means that all bytes contain data. Additionally, since the maximum value of
N is 3, at least one data byte will always have to be transferred.

Figure 3.15 Initiate SDO Download

All the other bit fields in the messages shown in Figure 3.15 are exactly the same as
the ones described for segmented SDO downloads.

3.5.3.2 Expedited SDO Upload

The protocol for expedited uploads is derived from the protocol for segmented SDO
uploads. In the case of expedited SDO uploads, only the Initiate Domain Upload
Service presented for segmented uploads is used. Figure 3.16 shows the protocol for the
Initiate SDO Upload service in expedited transfers.

Figure 3.16 Initiate SDO Upload

The protocol for expedited uploads transfers is very similar to the protocol for
expedited downloads discussed in the previous section. However, in this case, the data
and associated control bit fields (N, E and S) are carried in the response message, from
 78

the Server to the Client. The meaning of the information in these fields is the same as
for the expedited SDO download protocol.
All the other bit fields in the messages shown in Figure 3.16 are exactly the same as
the ones described for segmented SDO uploads.

3.5.4 Block SDO Transfers

Block SDO transfers are a modified version of segmented SDO transfers where the
protocol is optimised for very large blocks of data. In this type of transfer the data is
transferred as a sequence of blocks, each composed of a series of segments.
The basic difference relative to segmented transfers is that within a block, each
segment is not acknowledged; instead, all segments that constitute a block are
simultaneously acknowledged when the entire block has been transferred.
The elimination of acknowledgements within a block greatly reduces the protocol
overhead. However, this may lead to situations where the retransmission of a large
amount of data is necessary since an error may only be indicated to the sender some
time after it has occurred and during this time subsequent data segments will have been
transferred.
The block SDO transfer protocols include an optional Cyclic Redundancy Check
(CRC) feature that may be used to detect errors during the transfer. The operation of this
mechanism is based on a CRC calculation performed by the sender of the data
transferred. The receiver then must perform the same calculation on the data received
and compare the two CRC values. If the values differ then an error must have occurred
during the transfer and it must be terminated accordingly. The CRC calculation is
performed only on the transferred data.

3.5.4.1 Block SDO Download

The general procedure for block SDO Downloads is shown in Figure 3.17.
 79

Figure 3.17 General format for block SDO download operations

Similarly to segmented transfers, a block download begins with an initialisation

phase during which the parameters of the block transfer are negotiated between Client
and Server. However, in block transfers, this negotiation is somewhat more complex as
more parameters are involved.
This initialisation phase is then followed by the successive transfer of blocks of data
from the Client to the Server until all the data is transmitted. The protocol terminates
with a final negotiation between Client and Server in which the remaining segmentation
control parameters are transferred from the Client to the Server and a final error check is
performed.
The details of how each block is transferred are shown in Figure 3.18.
 80

Figure 3.18 Download SDO block procedure

For each block downloaded, several messages are exchanged between Client and
Server, as shown in Figure 3.18. The Client sends all the segments that constitute the
block, one at a time, to the Server and then waits for a confirmation. This confirmation
will indicate which was the last segment successfully received. The Client will then
proceed to download the next block starting from the first data not yet successfully
transferred. Each segment carries 7 bytes of data unless it is the last segment in the
procedure, in which case it will contain the remaining data bytes.
Although the protocol for the SDO Download service must be implemented as a
whole, the procedure for block downloads is specified as three sub-services for easier
understanding:
• Initiate SDO Block Download - through this service, the Client asks the Server to
prepare for receiving data i.e. for a data download. This service is confirmed and the
response will indicate either the success or the failure of the operation. If the
operation is successful, then the Download SDO Block Segment service can be used
to transfer the data.
• Download SDO Block Segment - this service is used by the Client to supply a new
block of data to the Server. Again the service is confirmed and the response will
indicate success or failure of the operation.
• End SDO Block Download - this service is used by the Client to terminate the SDO
transfer upon receiving from the Server the confirmation that all the data have been
successfully received. An optional CRC feature can be included in this service.

Error or failure indications are given using the Abort SDO Transfer service, the
protocol of which will be described in Section 3.5.5.
Figure 3.19 shows the protocol for the Initiate SDO Block Download service.
 81

Figure 3.19 Initiate SDO Block Download

Figure 3.19 shows the data fields of the CAN messages to be used in the protocol of
an Initiate SDO Block Download service. The data fields of the exchanged messages are
structured as a sequence of bit-fields, with the following functions:
• The CCS (Client Command Specifier) bit-field, stored in bits 5 to 7 of byte 0, is
equal to 6 indicating the Initiate SDO Block Download command.
• The X bits are unused bits and should always be set to zero.
• The Client CRC Support (CC) bit indicates to the Server if the Client supports the
CRC feature (CC equal to 1). In the response, the Server will indicate in a similar
way if it supports this functionality in the SC field. If both devices support the CRC
feature this mechanism will be used in the End SDO Block Download service.
• The S bit indicates whether or not the size of the data is indicated in bytes 4 to 7 of
the Client-to-Server CAN message. If S is set to 0, then the size is not indicated.
• The Multiplexor is again stored in bytes 1 to 3 of the data field in the same format as
was described for segmented transfers.
• The SCS (Server Command Specifier) contains the value 5, indicating a response to
an Initiate SDO Block Download command (bits 5 to 7 of byte 0 in the response
telegram).
• The Client Sub-command and Server Sub-command bit fields (CS and SS
respectively) are used to differentiate between the different stages of the block
transfer. In this initialisation stage, these fields hold the value 0.
• Finally, the Block Size field is used by the Server to indicate to the Client how many
segments of data should be in the first block to be transferred. The block size must
be a value in the range 0 < Block Size < 128.

The protocol for the Download SDO Block Segment service is shown in Figure
3.20.
The meaning of the SCS bit-field is exactly the same as for the Initiate SDO Block
Download protocol and it holds the same value. On the other hand, the Server Sub-
command Specifier (SS) holds a value of 2 indicating a block confirmation message.
 82

Figure 3.20 Download SDO Block Segment

Additional bit-fields are used in the Download SDO Block Segment protocol for
segmentation control. These bit-fields are the following:
• The Sequence Number holds an identification code for each segment transferred.
The first segment will carry a value of 1 and subsequent segments will carry
incremented values until a maximum of 127.
• The C bit is used to determine whether there are more segments to download. It is
set to 0 if there are more segments to download and to 1 if this is the last segment to
be downloaded.
• The Sequence Acknowledge field holds the Sequence Number of the last segment
that the Server received correctly.
• The Block Size field holds the number of segments that should compose the next
block to be transferred. Again, this value must be in the range 0 < Block Size < 128.

Note that all the segments transferred in the Download SDO Block Segment
protocol will contain seven bytes of data. However, this may not be the case in the last
segment of the last block of data. The number of data bytes contained in this final
segment is indicated to the Server during the execution of the End SDO Block
Download service.
Finally, the protocol for the End SDO Block Download protocol is depicted in
Figure 3.21.

Figure 3.21 End SDO Block Download

When the Server has acknowledged the reception of the last segment of data, the
Client uses the End SDO Block Download protocol to terminate the block transfer
procedure. The bit fields used in this protocol are the following:
 83

• The Client Command Specifier still holds a value of 6. However, the Client Sub-
command Specifier holds the value 1, distinguishing this message from the Initiate
SDO Block Download protocol.
• The Server Command Specifier still holds a value of 5. However, the Server Sub-
command Specifier holds the value 1, making a distinction from the previous
protocols.
• If the CRC feature is used, the CRC field holds the result of the CRC calculation
performed by the Client.
• Finally, the N field carries the number of data bytes transferred in the last data
segment in the last data block. N holds a value between 0 and 7 indicating that bytes
8-N to 7 in the last segment do not contain valid data. If the N field carries 0 this
means that all 7 bytes in the last segment are valid.

3.5.4.2 Block SDO Upload

The general procedure for block SDO Uploads is shown in Figure 3.22.

Figure 3.22 General format for block SDO upload operations

 84

Similarly to block downloads, a block upload begins with an initialisation phase

during which the parameters of the block transfer are negotiated between Client and
Server. However, in this case, the initialisation phase requires three messages
exchanged between Client and Server. This is because when the Client's initial request
to read from the Server's Object Dictionary is accepted, the Server must be given an
indication that it can start uploading the data. This indication is given in the second
initialisation message sent by the Client to the Server.
The initialisation phase is followed by the successive transfer of blocks of data from
the Server to the Client, until all the data are transmitted. The protocol terminates with a
final negotiation between Client and Server in which the remaining segmentation
control parameters are transferred from the Server to the Client and a final error check is
performed.
The details of how each block is transferred are shown in Figure 3.23.

Figure 3.23 Upload SDO block procedure

For each block downloaded, several messages are exchanged between Client and
Server, as shown in Figure 3.23. The Server sends all the segments that constitute the
block, one at a time, to the Client and then waits for a confirmation. This confirmation
will indicate the last segment that was successfully received. The Server will then
proceed to upload the next block starting from the first data not yet successfully
transferred. Each segment carries 7 bytes of data unless it is the last segment in the
procedure, in which case it will contain the remaining data bytes.
An interesting feature was added to the protocol for SDO Block Upload operations.
Since the Client is not aware of the size of the data it will be reading from the Server, it
is possible that the data might not be large enough to justify the use of the block transfer
procedure. For this reason, in the initialisation stage, the Client informs the Server of a
data size threshold below which the Server should switch to the other transfer
procedures. In this situation, the Server can use the segmented procedure, for data that is
more than 4 bytes in length, or the expedited procedure, for data that is up to 4 bytes in
length.
 85

Although the protocol for the SDO Upload service must be implemented as a whole,
the procedure for block uploads is specified as three sub-services for easier
understanding:
• Initiate SDO Block Upload - through this service, the Client asks the Server to
prepare for sending data i.e. for a data upload, indicating the data size threshold
below which the block transfer procedure should be abandoned. This service is
confirmed and the response will indicate either the success or the failure of the
operation. If the operation is successful, then the Client sends an indication to the
Server that it can use the Upload SDO Block Segment service to transfer the data.
• Upload SDO Block Segment - this service is used by the Server to supply a new
block of the data to the Client. Again the service is confirmed and the response will
indicate success or failure of the operation.
• End SDO Block Upload - this service is used by the Server to terminate the SDO
transfer, receiving from the Client the confirmation that all the data have been
successfully received. An optional CRC feature can be included in this service.

Error or failure indications are given using the Abort SDO Transfer service and
protocol described in Section 3.5.4.2.
Figure 3.24 shows the protocol for the Initiate SDO Block Upload service. It shows
the data fields of the CAN messages to be used in an Initiate SDO Block Upload
service. The data fields of the exchanged messages are structured as a sequence of bit-
fields, with the following functions:
• The CCS (Client Command Specifier) bit-field, stored in bits 5 to 7 of byte 0, is
equal to 5 indicating the Initiate SDO Block Upload command.
• The X bits are unused bits and should always be set to zero.
• The Client CRC Support (CC) bit indicates to the Server if the Client supports the
CRC feature (CC equal to 1). In the response, the Server will indicate in a similar
way if it supports this functionality in the SC field. If both devices support the CRC
feature this mechanism will be used in the End SDO Block Upload service.
• The Multiplexor is again stored in bytes 1 to 3 of the data field in the same format as
was described for segmented transfers.
• The SCS (Server Command Specifier) contains the value 6, indicating a response to
an Initiate SDO Block Upload command (bits 5 to 7 of byte 0 in the response
telegram).
• The Client Sub-command and Server Sub-command bit fields (CS and SS
respectively) are used to differentiate between the different stages of the block
transfer. In the first two messages, these fields hold the value 0. In the second
message sent by the Client, the CS field carries the value 3.
• The Block Size field is used by the Client to indicate to the Server how many
segments of data should be in the first block to be transferred. The block size must
be a value in the range 0 < Block Size < 128.
• The Protocol Switch Threshold (PST) bit field carries a value that indicates to the
Server a threshold below which it should switch to the normal segmented or
expedited transfer procedures. If the PST is 0 then the protocol switch is not
allowed. If the PST is greater than 0, the Server can optionally switch to another
transfer procedure if the data size is smaller than the PST. Note that if the Server
switches to another protocol, the response to the Client's first message will follow
 86

the expedited SDO upload procedure (if the data is up to 4 bytes in length) or the
segmented SDO upload procedure (if the data is over 4 bytes in length). In other
words, if a protocol switch occurs, only the first message shown in Figure 3.24 is
actually used.
• Finally, the S bit indicates whether or not the size of the data is indicated in bytes 4
to 7 of the Server-to-Client CAN message. If S is set to 0, then the size is not
indicated.

Figure 3.24 Initiate SDO Block Upload

The protocol for the Upload SDO Block Segment service is shown in Figure 3.25.
The meaning of the CCS bit-field is exactly the same as for the Initiate SDO Block
Upload protocol and it holds the same value. On the other hand, the Client Sub-
command specifier (CS) holds a value of 2 indicating a block confirmation message.

Figure 3.25 Upload SDO Block Segment

The remaining bit fields shown in Figure 3.25 serve the same purpose as the ones
described for the Download SDO Block Segment protocol discussed in the previous
section.
Note that all the segments transferred in the Upload SDO Block Segment protocol
will contain seven bytes of data. However, this may not be the case in the last segment
of the last block of data. The number of data bytes contained in this final segment is
indicated to the Client during the execution of the End SDO Block Upload service.
 87

Finally, the protocol for the End SDO Block Upload protocol is depicted in Figure
3.26.

Figure 3.26 End SDO Block Upload

When the Client has acknowledged the reception of the last segment of data, the
Server uses the End SDO Block Upload protocol to terminate the procedure. The bit
fields used in this protocol are the following:
• The Client Command Specifier still holds a value of 5. However, the Client Sub-
command Specifier now holds the value 1, distinguishing this message from the
previous protocols.
• The Server Command Specifier still holds a value of 6. However, the Server Sub-
command Specifier holds the value 0, making a distinction from the Initiate SDO
Block Upload protocol.
• If the CRC feature is used the CRC field holds the result of the Cyclic Redundancy
Check calculation performed by the Server.
• Finally, the N field carries the number of data bytes transferred in the final data
segment. N holds a value between 0 and 7 indicating that bytes 8-N to 7 in the last
segment do not contain valid data. If the N field carries 0 this means that all 7 bytes
in the last segment are valid.

3.5.5 Abort SDO Transfer Protocol

The indication of a failure in a SDO transfer, whatever the transfer procedure
adopted, is done using the Abort SDO Transfer service. Both Client and Server can
invoke this service at any time during the data transfer, in order to terminate it.
The protocol for this service is shown in Figure 3.27.

Figure 3.27 Abort SDO Transfer

The protocol for the Abort SDO Transfer service is very simple. A single
unconfirmed message is sent by the device indicating the failure of the operation, to the
peer device. The Command Specifier (CS) for this message has a value of 4.
 88

The reason for the invocation of this service is indicated in the bytes holding an
Abort Code. The Abort Codes that can be used in CANopen are specified in DS301.
Some errors that can be signalled using this service are:
• Protocol errors e.g. toggle bits do not match.
• Index / Sub-index combination does not exist in the Object Dictionary of the Server.
• The range of the uploaded/downloaded data is invalid.
• Incompatibility between the parameter being transferred and other associated
parameters.
• Size mismatch between the Object Dictionary entry, the number of bytes actually
transferred or the size indicated in the Initiate SDO Up- or Download service
(possibly a type error).
• Time-out occurrence (time-outs are usually implemented to prevent the occurrence
of deadlocks caused by the absence of a response).

Note that the Abort SDO Transfer service can only be used in the context of a SDO
transfer. The Abort SDO Transfer service must not be used for other purposes such as
the indication of errors due to communication faults or device application errors.

3.5.6 SDO Configuration Through the Object Dictionary

Every Service Data Object that a device implements is represented in its Object
Dictionary by an entry of type 'SDO Communication Parameter' (CANopen Data Type
22H). By accessing these entries in a device's Object Dictionary, the Service Data
Objects implemented in the device can be configured. The actual Indexes of the SDO
Communication Parameter entries are defined in the CANopen Communication Profile:
• For SDOs where the device is a Server, the valid Index range is 1200H to 127FH.
The implementation of one Server SDO is mandatory, together with its
representation in the Object Dictionary at Index 1200H. The parameters of this SDO
must not be changeable as it is the default link for communication with a CANopen
device.
• For SDOs where the device is a Client, the valid Index range is 1280H to 13FFH.

The structure of each SDO Communication Parameter entry is shown in Table 3.7.
By accessing Sub-indexes 1H and 2H the message identifiers used in the SDO
communication can be modified. Additionally, the most significant bit of these fields
permits enabling or disabling the transmission/reception of these messages. Obviously,
a Service Data Object is only enabled if both of these messages are enabled. The actual
structure of these sub-entries is shown in Table 3.8. Sub-index 3 of the SDO
Communication Parameter structure may hold the Node ID of the peer device in the
Client/Server relationship but this is not of mandatory implementation. An exception to
this rule is the mandatory Server SDO Communication Parameter at Index 1200H in
which Sub-index 3 must not be present. The Node ID parameter will be introduced in
Section 3.8.
 89

Table 3.7 Structure of an entry of type 'SDO Communication Parameter'

Sub-index Field in record Data type
0H Number of supported sub-entries UNSIGNED8
1H CAN identifier for the Client-to-Server message UNSIGNED32
2H CAN identifier for the Server-to-Client message UNSIGNED32
3H Node ID of peer device UNSIGNED8

Table 3.8 Description of the SDO message identifier entry

bit Number Value Meaning
0 SDO valid
31
1 SDO not valid
30 0 reserved, always 0
0 11-bit message identifier
29
1 29-bit extended identifier
0 if bit 29 is 0: 0
28 to 11
X if bit 29 is 1: bits 28 to 11 of the 29-bit identifier
10 to 0 X bits 10 to 0 of the message identifier

3.6 PROCESS DATA OBJECTS

3.6.1 General Description
Process Data Objects provide direct access to Application Objects within a device.
They are used to perform real-time transfers of short blocks of high priority data. The
data transferred must be less than or equal to 8 bytes in length. All data bytes in the
CAN message are used for data transfer. Hence, no transfer-control information is used
at the Application Layer level.
This is possible because both the transmitter and the receiver know the meaning of
the information carried by the PDO. The meaning of each byte of the telegram is pre-
defined by means of PDO mapping information, which is stored in the Object
Dictionary of the devices that produce and consume the PDO. This mapping, which in
some devices may be dynamically changed using SDOs, also determines the data type
of the information and, therefore, the way it is encoded in the CAN telegram according
to the CANopen encoding rules. PDO mapping will be described in Section 3.6.4.2.
The operation of Process Data Objects is based on Producer/Consumer relationships
where both the Push and Pull models can be used. A PDO for which a device is the
Producer is called a transmit PDO of that device. A PDO for which a device is a
Consumer is called a receive PDO of that device.
Each PDO requires the allocation of one CAN message identifier for its operation.
CANopen defines default CAN message identifiers that may be used by CANopen
devices to implement eight PDOs: in four of these PDOs, the device will be the
Producer; in the other four PDOs the device will be a Consumer. The default message
identifiers allocated to each CANopen device will be discussed in Section 3.8.4.
Two services are specified for Process Data Object communication: Write PDO and
Read PDO.

3.6.1.1 Write PDO

The Write PDO service follows the Push Model. There is one Producer and any
number of Consumers for the PDO. Using the Write PDO service the Producer may
send, based on its own initiative, the application data associated with the PDO to the
Consumers.
 90

The protocol for the Write PDO service is shown in Figure 3.28.

Figure 3.28 Write PDO

As can be seen in Figure 3.28 the service is unconfirmed and the CAN message used
in the transfer carries process data only. The number of data bytes carried by a PDO is
determined by the application of the CANopen data encoding rules to the Application
Objects mapped on the PDO.

3.6.1.2 Read PDO

The Read PDO service follows the Pull Model. There is one Producer and at least
one Consumer for the PDO. Using the Read PDO service one of the Consumers may
request from the Producer the application data associated with the PDO.
The protocol for the Read PDO service is shown in Figure 3.29.

Figure 3.29 Read PDO

As can be seen in Figure 3.29 the service is confirmed. The discussion regarding the
CAN data message used in the protocol for the Write PDO service also applies to the
CAN data message shown in Figure 3.29. In fact, the protocol for the Read PDO service
is an extended version of the one for the Write PDO service, where the PDO
transmission triggering is left to one of the Consumers. To trigger the transmission of
the PDO, the Consumer requesting the PDO simply places on the bus a CAN remote
frame with the identifier assigned to the PDO.
 91

3.6.2 PDO Triggering Modes

The transmission of a PDO may be triggered in three different ways:
• Event driven - the PDO's transmission is triggered by the occurrence of an event in
the device. This event may be related to a Communication Object or to an
Application Object within the device as will be seen in the next section. In this
triggering mode, the Write PDO service is used.
• Timer driven - a PDO can also be configured so that its transmission is triggered
when a specified time has elapsed without the occurrence of the event associated
with that PDO. In this triggering mode, the Write PDO service is used.
• Remotely requested - the transmission of the PDO is requested by another device
using a remote frame, according to the Read PDO service. PDOs whose
transmission is triggered using remote frames are ideal for the implementation of
polling mechanisms.

Usually, a PDO is configured to operate in Event driven transmission triggering

mode, although it is possible to configure a PDO to operate in the Remotely requested
mode only. Both the Timer driven and the Remotely requested modes can be used
simultaneously with the Event driven mode.

3.6.3 PDO Transmission Types

The transmission type of a PDO is determined by the nature of the event that
triggers its transmission. PDOs are divided in the following categories, according to
their transmission type:
• Synchronous transmission - the transmission of synchronous PDOs is dependent on
the reception of a periodic synchronisation message, the Synchronisation Object,
transmitted by another device. This makes it possible to implement co-ordinated
data acquisition mechanisms across CANopen networks. Furthermore, the data
carried by the synchronous PDOs are only used by their Consumers on reception of
the next Synchronisation Object. This makes it possible to implement co-ordinated
actuation mechanisms across CANopen networks. The Synchronisation Object will
be described in more detail in Section 3.7.1. This type of PDO obviously operates in
the event driven triggering mode, as discussed in the previous section.
• Asynchronous transmission - the transmission of the PDO is triggered by an event
unrelated to the Synchronisation Object. For some PDOs this event may have its
origin in an Application Object within the Device; for others it may have its origin
in a Communication Object within the device. The former type of PDO operates in
event driven triggering mode and the event associated with it can be, for example, a
change of state in one of the input signals to the device. The latter type of PDO may
operate in timer driven or remotely requested modes.

Synchronous PDOs can be further divided into cyclic or acyclic. Cyclic PDOs will
be transmitted after a certain number of Synchronisation Objects are received. An
acyclic PDO is transmitted after the reception of a Synchronisation Object, but only
when a particular event, internal to the device, has occurred.
Usually, in automation applications, the nature of the process data travelling on the
bus will belong to one of two very broad categories: Commands and Feedback
messages:
 92

• Command messages will typically be issued by a controller device to remote

actuation devices. Through these messages, the controller exhorts its control over
the actuation devices so that they perform a determinate action. Using synchronous
PDO communication, the execution of these Commands can be performed
simultaneously by multiple devices.
• Feedback messages will be usually issued by remote data acquisition devices to a
controller, carrying process data that they have collected. Using synchronous PDO
communication, process data can be collected at very well defined instants in time,
which can be very useful in applications where the time consistency of the data is
important.

The diagram shown in Figure 3.30 illustrates the typical scenario in a CANopen
network using synchronous PDO communication.
At predefined time intervals the Synchronisation Object (SYNC) is transmitted by
one of the devices on the network, called the Synchronisation Object Producer. The
time interval separating the transmission of two Synchronisation Objects is called the
Communication Cycle Period. The Synchronisation Object Producer may or may not be
the same device acting as application or network Master.
When a Synchronisation Object is received, all devices producing synchronous
PDOs place their messages (some of these will be Command messages and the
remaining will be Feedback messages) on the bus. The example in Figure 3.30 assumes
that Feedback messages are assigned higher priority CAN identifiers, which would be a
logical solution in applications where the collection of process data has time-critical
requirements. In any case, all synchronous PDOs will be transmitted during a time
interval that starts with the reception of the SYNC Object, usually called the
Synchronous Window. The actions that are triggered using the synchronous Command
messages are only carried out upon reception of the next Synchronisation Object. This
permits co-ordinated action by several devices in the network.

Figure 3.30 Synchronous PDO typical traffic pattern

It is important to note that in Figure 3.30 only synchronous PDO messages are
shown. In a real network, other types of messages such as SDOs or asynchronous PDOs
 93

may be transmitted at any time. A careful CAN identifier distribution should be able to
ensure that all communication requirements are met.
As previously mentioned, the transmission of an asynchronous PDO may be
associated with the occurrence of an application event detected in the device. In this
case, it may be transmitted at any time during the operation of the application, based on
the occurrence of this event. The type of application event that triggers the transmission
is either device specific, in which case it is thoroughly described in the applicable
Device Profile, or it is manufacturer specific and it will be explained in the device's
documentation. Typical application events associated with asynchronous PDOs include
the change of state of a set of inputs or an analogue input exceeding a pre-defined
threshold value.

Figure 3.31 Example of an asynchronous PDO transmission

Figure 3.31 shows a typical situation where this type of asynchronous PDO is
useful. A proximity sensor, such as the one shown in Figure 3.31, is a good example of
a control element that may change its state unexpectedly. The fast detection of this type
of event may be very important in some applications. By associating this event with an
asynchronous PDO, the information can be broadcasted on the network as soon as the
event occurs. In this example, the CANopen device asynchronously transmits a PDO
when the analogue voltage exceeds 4V.

3.6.4 Configuration of Process Data Objects Through the Object Dictionary

The configuration of a PDO consists of two different steps:
• Setting the mapping of the data inside the PDO message i.e. determining which data
will be transferred at which position of the CAN message data field. This permits
both the Producer and the Consumers to know which pieces of information are
being transferred without introducing additional protocol control information in the
CAN messages, and thus maximising transmission efficiency.
• Setting the communication parameters of the PDO itself e.g. the CAN message
identifier it uses, the transmission type, etc.

Global network aspects, such as between which devices should the PDO transfer
take place, relative priorities to be given to the different PDOs travelling on the bus and
bus loading, should also be kept in mind when performing PDO configuration.
 94

3.6.4.1 PDO Communication Parameters

Every Process Data Object that a device implements must be represented in its
Object Dictionary by an entry of type 'PDO Communication Parameter'. The actual
Indexes of these entries are defined in the CANopen Communication Profile:
• The valid Index range for receive PDOs is from 1400H to 15FFH. Only the first
four PDOs in this range can be active by default since they are the only ones for
which default communication parameters are available, as will be seen in Section
3.8.4.
• The valid Index range for transmit PDOs is from 1800H to 19FFH. Again, only the
first four PDOs in this range can be active by default since they are the only ones for
which default communication parameters are available as will be seen in Section
3.8.4.

By accessing these entries, the communication parameters of the Process Data

Objects can be configured. The structure of each PDO Communication Parameter entry
is shown in Table 3.9.
As in the case of the SDO entries, the CAN message identifier parameter, at Sub-
index 1H, permits also the configuration of other aspects of PDO operation, as shown in
Table 3.10. Hence, to enable or disable a PDO, it is sufficient to use a SDO to access
this sub-entry and set the most significant bit to 0 or 1 as desired.
The transmission type parameter at Sub-index 2H defines the transmission character
of the PDO. The usage of this sub-entry is shown in Table 3.11.

Table 3.9 Structure of an entry of type PDO Communication Parameter

Sub-index Field in record Data type
0H Number of supported sub-entries UNSIGNED8
1H CAN message identifier that the PDO uses UNSIGNED32
2H Transmission type UNSIGNED8
3H Inhibit time UNSIGNED16
4H Reserved UNSIGNED8
5H Event Timer UNSIGNED16

Table 3.10 Description of the PDO message identifier entry

Bit number Value Meaning
0 PDO valid
31
1 PDO not valid
0 Remote requests allowed on this PDO
30
1 Remote requests not allowed on this PDO
0 11 -bit message identifier
29
1 29-bit extended identifier
0 if bit 29 is 0: 0
28 to 11
X if bit 29 is 1: bits 28 to 11 of the 29-bit identifier
l0 to 0 X bits 10 to 0 of the message identifier
 95

Table 3.11 PDO Transmission Types

Transmission
PDO transmission character
Type
Cyclic Acyclic Synchronous Asynchronous Remote request
0


1 to 240


241 to 251 reserved
252


253


254

255

Relative to Table 3.11, an acyclic synchronous PDO is an event-triggered PDO sent

on reception of the first SYNC telegram after the occurrence of an internal application
event to which the PDO is associated. Writing a value of zero to Sub-index 02H of a
PDO Communication parameter entry will configure the PDO to be of this type. The
application event associated with the PDO will either be defined in the applicable
Device Profile or in the device's documentation. Writing a value of 1 to 240 to the same
Sub-index will configure the PDO as being not only synchronous, but also cyclic. This
means that it will be transmitted on reception of every N SYNC telegrams, where N is
the number stored at this Sub-index.
A transmission type value of 252 means that PDO transmission will occur once a
CAN remote frame has been received, but the data in it will correspond to the time
instant at which the last SYNC telegram has been received. A value of 253 indicates
that the PDO will be transmitted on reception of a CAN remote frame and the data will
be updated on reception of the remote frame itself.
A transmission type value of 254 indicates that the PDO is purely asynchronous, and
the application event that triggers the transmission is manufacturer specific. A value of
255 indicates that the PDO is purely asynchronous, and the application event that
triggers the transmission is defined in the Device Profile.
Sub-indexes 3 and 5 in the PDO Communication Parameter entry contain two
additional parameters that can be very useful for transmit PDOs of types 254 and 255:
the Inhibit Time and the Event Timer parameters (these Sub-indexes are meaningless
for receive PDOs). Sub-index 4 is reserved for compatibility with previous versions of
the CANopen protocol and it doesn't have to be implemented.
The Inhibit Time parameter is used to limit the maximum transmission rate of a
PDO and it can be very useful to prevent high priority PDOs from flooding the CAN
bus, preventing the transmission of lower priority messages. In other words, the PDO
cannot be transmitted before the time set in this parameter elapses.
The Timer Event parameter is used to ensure a minimum rate of PDO transmissions,
independently of the occurrence of the application event associated with the PDO. In
other words, if the time set in this parameter elapses and the occurrence of the event
associated with the PDO is not detected, the PDO is transmitted.
The values for the Inhibit Time and Event Timer parameters are set in multiples of
100 microseconds and 1 millisecond respectively. In both cases a null value indicates
that the mechanisms are disabled.
Finally, it is important to note that the implementation of the Inhibit Time and Event
Timer sub-entries is optional; the implementation is unnecessary if the mechanisms they
relate to are not supported.
 96

3.6.4.2 PDO Mapping Parameters

The mapping of process data onto each PDO must be represented in the Object
Dictionary by an entry of type PDO Mapping Parameter. The Index for this entry is
found by adding 200H to the Index of the corresponding PDO Communication
Parameter entry. In fact, the Index ranges for the mapping entries are defined in the
CANopen Communication Profile as:
• The valid Index range for receive PDOs mappings is from 1600H to 17FFH.
• The valid Index range for transmit PDOs mappings is from 1A00H to 1BFFH.

Table 3.12 Structure of an entry of type 'PDO Mapping Parameter'

Sub-index Field in record Data type
0H Number of mapped objects in PDO UNSIGNED8
1H Is' object to be mapped UNSIGNED32
2H 2nd object to be mapped UNSIGNED32
::::::: ::::::::::: ::::::::::
40H 64th object to be mapped UNSIGNED32

The PDO mappings describe the PDO content by listing the sequence and the length
of the mapped Object Dictionary entries that are carried by the PDO. The structure of
each PDO Mapping Parameter entry is shown in Table 3.12.
To describe the contents of a PDO, it is sufficient to indicate how many Object
Dictionary entry values will be carried by the PDO, which are the mapped entries
(Index and Sub-index), in what order are they mapped, and what are their individual
sizes. This description is stored in the values of the Sub-index entries shown in Table
3.12. The structure of the entries from Sub-indexes 1H to 40H is shown in Figure 3.32.

Figure 3.32 Structure of object mapping entry

The object length can be a value in the range from 1 to 64, indicating the number of
bits occupied by a particular object.
Object Dictionary entries corresponding to CANopen data types can also be
referenced in the mapping. The parts of the PDO data mapped using this feature will not
be considered by the device receiving the PDO. These parts of the PDO content are
called dummy mappings. Dummy mappings can be very useful e.g. to use a single PDO
to send different pieces of information to different devices whereby each device can be
configured to ignore the data that is not intended for it (this is called a piggy-back
scheme).
The procedure for altering a PDO mapping using SDOs is the following:
• Write the value 0 to Sub-index 0H in the mapping record. If the mapping is not
changeable this write operation will be aborted.
• Write the mapped entries at successive Sub-indexes starting at Sub-index 1H and
using the data format shown in Figure 3.32.
• Write the total number of mapped entries to Sub-index 0H.
 97

An example of a PDO mapping is shown in Figure 3.33.

The mapping for a PDO telegram may be fixed. For this type of mapping, the
meaning and content of the data contained in the PDO cannot be altered by writing a
new mapping structure to the device's Object Dictionary. This lack of flexibility has
also some advantages, as it adds a smaller processing overhead than using dynamic
mapping. Furthermore, the lack of flexibility can be minimised by implementing several
PDOs with different fixed mappings. When this is the case, a suitable mapping can be
selected by activating the PDO that supports it using the communication parameters
accessible in the Object Dictionary.
It is important to note that the Device Profiles define standard default mappings that
all devices of a particular type must use. If these default mappings are suitable for a
particular application, the amount of configuration needed in order to commission a
device for normal operation is reduced to setting the PDO's communication parameters.

Figure 3.33 Example of a PDO mapping

In conclusion, a PDO mapping is simply a way of informing a device of what it is

receiving or transmitting in a PDO. By looking at the mapping information, the device
is able to get the correct data from the Object Dictionary and put it into the PDO or to
get the data from the PDO and use it to update the correct Object Dictionary entries.
Figure 3.34 shows an example where three 8-bit Digital Output Modules have to be
configured to produce at their outputs the values of the signals being read by an 8-bit
 98

Digital Input Module also present on the network. Using a single PDO this can be done
in a very simple way:
• The first transmit PDO in the Digital Input Module is configured with the
appropriate identifier, in this case identifier 0x189, and with a transmission type of
5, meaning that the PDO will be transmitted at every fifth occurrence of the SYNC
Object. The mapping of this PDO is set to contain only the object at Index=0x6000
and Sub-index=0x01 which, for Digital Input Modules, maps 8 digital input lines.
• The first receive PDOs in all the Digital Output Modules are configured in exactly
the same way: the appropriate identifier is set to 0x189 and the transmission type to
OxFF, meaning that the contents of the PDO should be immediately passed on to the
digital outputs. The mapping of these PDOs is set to contain only the object at
Index=0x6200 and Sub-index=0x01 which, for Digital Output Modules, maps 8
digital outputs lines.

Figure 3.34 Example of a configuration of PDO connections

It is important to keep in mind that many of the configuration operations referred to

in this example would be unnecessary since they match the default configuration of the
devices. This is the case, for example, for the identifier of the first transmit PDO in the
Digital Input module. However, assuming that all these parameters were to be set using
SDOs, configuring the network in Figure 3.34 would require sixteen SDO data
transfers.
 99

3.7 OTHER PRE-DEFINED CANopen COMMUNICATION OBJECTS

3.7.1 Synchronisation Object (SYNC)
The Synchronisation Object is broadcasted periodically on the network by a
synchronisation device. This object is used to implement a global clock-tick type event
in the network. Each device may or may not use this event to synchronise itself with
other devices in the network.
The time interval that separates the transmission of two Synchronisation messages is
called the Communication Cycle Period (Figure 3.30).
It is important to keep in mind that the transmission of the Synchronisation Object,
even if it's given the highest priority CAN message in the network, is subject to a small
time jitter. This is due to the fact that if a message is already being transmitted on the
bus when the Communication Cycle terminates, the transmission of the Synchronisation
Object will have to wait until transmission of the previous message is over.
The operation of the Synchronisation Object is based on the Producer/Consumer
Model. However, only one service is defined for the Synchronisation Object. This is the
Write SYNC service, through which the device transmitting the Synchronisation Object,
the Synchronisation Object producer, notifies the Consumers that a new
Communication Cycle has started. The protocol for the Write SYNC service is shown in
Figure 3.35.

Figure 3.35 Write SYNC

The Synchronisation Object and the CANopen device functionality associated with
this object are represented in the Object Dictionary by three different entries:
• COB-ID SYNC Message (Index 1005H) - This entry holds the message identifier
used by the Synchronisation Object as an UNSIGNED32 number divided into
several bit fields (Table 3.13). This entry must be implemented by both the Producer
and the Consumers of the Synchronisation Object. Bit 30 in this Object Dictionary
entry is used to trigger the Producer to start transmitting the Synchronisation Object.
The first transmission happens after one Communication Cycle Period has elapsed.
• Communication Cycle Period (Index 1006H) - This entry holds the Communication
Cycle Period in microseconds. It is mandatory for devices that are able to operate as
Producers, for obvious reasons. Devices that only operate as Consumers of the
Synchronisation Object may also implement this entry and use the information in it
internally. A value of zero in this entry deactivates the Communication Cycle
functionality.
• Synchronous Window Length (Index 1007H) - This entry holds the time interval
reserved in a network for transmission of synchronous messages after the SYNC.
 100

This parameter allows a device to determine the time instant from which it is
guaranteed that a new command has arrived and prepare itself for co-ordinated
actuation at the beginning of the next Communication Cycle. The value of the
Synchronous Window Length parameter is stored in microseconds. Again, a value
of zero in this entry deactivates the Synchronous Window Length functionality.

Table 3.13 Description of the COB-ID SYNC Message entry

Bit number Value Meaning
31 0 Reserved
0 Device does not produce SYNC
30
1 Device Produces SYNC
0 11-bit message identifier
29
1 29-bit extended identifier
0 if bit 29 is 0: 0
28 to 11
X if bit 29 is 1: bits 28 to 11 of the 29-bit identifier
10 to 0 X bits 10 to 0 of the message identifier

CANopen reserves message identifier 80H for the Synchronisation Object as will be
seen in Section 3.8.4.
The Synchronisation Object can be used for synchronisation of data collection and
actuation. However, if time consistence is of prime importance, a global time frame can
be implemented in a CANopen network using another pre-defined Communication
Object: the Time Stamp Object. Time Stamp Objects will not be discussed here. More
information on this type of object can be found in DS301.

3.7.2 Emergency Object

Emergency messages are used by CANopen devices to signal the occurrence of
internal errors. When an internal error occurs, the device transmits an Emergency
message, so that appropriate action can be taken by the network manager. This message
carries error codes, defined in DS301 and in the CANopen Device Profiles, specifying
the type of error that has occurred. Emergency messages can be sent one time only per
detected error, to prevent faulty nodes from flooding the network. The implementation
of the Emergency Objects is optional.
Emergency Objects are used for global fault control and, as such, they can be very
important in some applications. For this reason it is usual to assign high priority CAN
identifiers to this type of message.
The error status of a device may also be checked using a Service Data Object to
access the Object Dictionary entries related to the Emergency Object. The error status of
a device is represented in a device's Object Dictionary by two entries:
• Error Register (Index 1001H) - this entry contains an error status byte for the device.
In this status byte, the device can map its internal errors, by setting and resetting
each bit. The meaning of the bits in this register is pre-defined in DS301. Only one
of these bits (bit 0) must be implemented, and it indicates the presence or absence of
a Generic Error.
• Pre-defined Error Field (Index 1003H) - this entry holds a history of the errors that
have occurred on the device and that have been signalled using the Emergency
Object. The implementation of this Object Dictionary entry is mandatory (at least it
must hold the last error that was signalled) if the Emergency Object is implemented.
This object is implemented as an ARRAY of UNSIGNED32 values. As always,
 101

Sub-index 0H indicates the number of sub-entries which, in this case, corresponds to

the number of errors reported. Every new error should be stored at Sub-index 1H
and older errors shifted to higher Sub-indexes. Writing a zero to Sub-index 0H
resets the register. If the error condition that corresponds to a given entry disappears,
the entry should be removed from the ARRAY. Each entry in the register is divided
into two 16-bit fields:
• The 2 least significant bytes hold a 16-bit Emergency Error Code. CANopen
defines the meaning of these Emergency Error Codes in two steps. The most
significant byte of the Emergency Error Code gives the general meaning of
the error and is defined in DS301. The least significant byte of the
Emergency Error Code gives a more precise meaning of the nature of the
error and is defined in the Device Profiles.
• The 2 most significant bytes hold additional information about the error. The
codes in these bytes are manufacturer specific and should be explained in the
device's documentation.

The Emergency Object carries eight data bytes and it is structured as shown in
Figure 3.36.

Byte 0 1 2 3 4 5 6 7
Emergency Error Code Error Register Manufacturer Specific Error
Content
(CANopen defined) (Object 1001H) Field
Figure 3.36 Structure of an Emergency Object

The values used in the Manufacturer Specific Error Field should also be explained
in the device's documentation.
Regarding its error status, a device may be in either one of two states: 'Error Free'
and 'Error Occurred'. 'Error Free' means that the device is operating normally, and no
error condition has been detected. 'Error Occurred' means that at least one uncorrected
error condition has been detected on the device. The operation of the device is as
follows:
• After initialisation, the device enters the 'Error Free' state. If no error is detected the
device remains in this state and no Emergency message is sent.
• When an error is detected, an Emergency Object signalling the error is transmitted,
the device enters the 'Error Condition' state (if it is not already there), and the
associated Object Dictionary entries are updated accordingly.
• If some of the errors that have been detected disappear, the device remains in an
'Error Condition' state and must update its Object Dictionary entries accordingly. An
Emergency Object with an Emergency Error Code indicating Error Reset (0000H)
may be transmitted to indicate that the error status has changed but, in this case, the
remaining fields of the message must indicate that some error conditions still remain
uncorrected.
• If all errors are repaired the device returns to the 'Error Free' state and it transmits an
Emergency Object containing an Emergency Error code indicating Error Reset
(0000H). All the other fields in this Emergency Object will also indicate the absence
of errors so that no ambiguity will exist relative to the previous case.
 102

The extent to which the detection of an error should affect the functionality of a
device very much depends on the type of functionality implemented in the device. For
this reason the CANopen Communication Profile does not define this aspect of a
device's behaviour, placing it in the scope of the CANopen Device Profiles.
The operation of the Emergency Object is based on the Producer/Consumer Model.
However, only one service is defined for the Emergency Object. This is the Write
EMCY service, through which the Producer notifies the Consumers that its error status
has changed. The protocol for the Write EMCY service is shown in Figure 3.37.

Figure 3.37 Write EMCY

CANopen reserves a range of CAN message identifiers to be used by default for

Emergency Objects in CANopen devices, as will be discussed in Section 3.8.4.
Finally, it is important to mention that the communication parameters associated
with the Emergency Object are represented in the Object Dictionary by two entries:
The CAN message identifier used by a device for the Emergency Object can be
written or read from a dedicated Object Dictionary entry at Index 1014H. This entry is
composed of a single Sub-index holding an UNSIGNED32 value. The least significant
bits of this number hold the identifier of the Emergency Object. If the identifier is an
extended one, then bit 29 is set to 1. The remaining bits of the entry are reserved.
The Inhibit Time associated with the Emergency Object is stored at Index 1015H as
an UNSIGNED16 number. The Emergency Object cannot be transmitted twice within
the time interval defined by the Inhibit Time. The Inhibit Time is stored in multiples of
100 microseconds.

3.8 COMMUNICATION OBJECTS FOR NETWORK MANAGEMENT

3.8.1 Introduction
The network management functionality offered by CANopen is very important in
building a distributed application. Distributed applications have problems that would
not exist if the application was not distributed. These problems arise because the
introduction of a communication network in a system adds significantly to the number
of things that can go wrong. Using the CANopen Network Management (NMT)
Communication Objects, it is possible to handle
these problems. The NMT Communication Objects are not directly related with the
goal of the application; they are used to ensure that all devices in the network are able to
give their contribution to the end result i.e. that they are able to communicate in the
correct way.
The NMT Communication Objects operate according to the Master/Slave principle
(model). In fact, one of the devices in a CANopen network must operate as the NMT
 103

Master, while all the other nodes operate as NMT Slaves. The Master node must
maintain an internal global image of the network in terms of which devices are
connected to it and their individual status. Its task is to use the functionality of the NMT
Communication Objects residing in each Slave node to control the operation of the
entire network.
Each CANopen device is uniquely identified on the network by its Node ID. The
Node ID is a value between 1 and 127, configured on each device using some type of
local mechanism e.g. DIP-switches. The Node ID parameter is used for Slave node
addressing in the services provided by the CANopen NMT Communication Objects.
For this reason, all the devices in a CANopen network must have different Node IDs.
For this reason, the maximum number of nodes in a CANopen network is 127.
However, this number of nodes is sufficient for most industrial automation distributed
control applications.
Each CANopen node implements one NMT Communication Object that offers
services through which the node can be controlled and monitored. The services offered
by NMT Communication Objects are divided into the following functional groups:
• Module Control - these services can be used for the initialisation of the NMT Slaves
that want to take part in the distributed application and for global control of the
application data exchange mechanisms i.e. enabling and disabling this type of
communication in one particular node or in all nodes simultaneously. In fact, before
enabling the application data exchange mechanisms it is required that the Slave
nodes are correctly configured. One of the most important configuration tasks that
must be carried out at this stage is the assignment to devices of all the CAN message
identifiers they need to communicate i.e. for all their Communication Objects. This
assignment of identifiers is normally done statically whereby the systems integrator
defines a priori what identifiers each node uses and for what purpose.
• Error Control - these services are used for supervision of the communication status
of the NMT Slaves. There are three services defined for this purpose: the Node
Guarding Event, the Heartbeat Event and the Life-guarding Event. The two former
services can be used by the NMT Master to monitor the status of NMT slaves. The
Life-guarding service allows the detection of failures in the NMT Master by NMT
Slaves.

3.8.2 State Diagram of a CANopen Device and NMT Module Control Services
A CANopen NMT Slave operates according to a state diagram in which the state
transitions are caused by invocations, by the NMT Master, of the Module Control
services offered by the NMT Communication Objects described in the previous section.
This state diagram is shown in Figure 3.38.
 104

Figure 3.38 State diagram of a CANopen device

On Power-on' a CANopen node enters an Initialisation phase (transition 1 in Figure

3.38). This Initialisation phase is conceptually divided into two states: Reset
Application and Reset Communication. Passing through these states automatically, the
node brings itself to its default status i.e. all the internal parameters of the device, such
as communication parameters and all other Object Dictionary entries will be given their
default values.
When the Initialisation phase is over, the node enters the Pre-operational state
automatically (this is represented by transition 2 in the state diagram). In Pre-
operational state, communication via SDOs is allowed and can be used since at this
stage each device in the network has its own set of default CAN message identifiers to
communicate. These identifiers are derived from the Node ID parameter and they will
be discussed in Section 3.8.3. PDOs are not allowed in Pre-operational state.
When the device is in the Pre-operational state it can be configured by a
Configuration Application that uses SDOs to access the device's Object Dictionary. For
example, the mapping of PDOs in the device can be set-up at this stage. SDOs can also
be used at this stage by the Configuration Application to assign all necessary message
identifiers to the nodes.
Once the device has been configured to handle all communication tasks required by
the distributed application, its normal operation can be started. The normal operation of
a node is represented in the state diagram by the Operational state. In this state all the
communication functionality of the node can be used e.g. PDOs, synchronisation using
the Synchronisation Object, etc. The transition to the Operational state is represented in
the state diagram by transition 3. It is triggered using the Start Remote Node service.
From Operational state, a device may be brought back to Pre-operational state, e.g.
for additional configuration, by using the Enter Pre-operational State service. This
transition is labelled 4 in the state diagram.
The Stopped state is included in the state diagram of a CANopen device to
accommodate situations in which it is necessary to switch off all the communication
functionality in a device. Other device specific functionality can also be incorporated
 105

into Stopped state, if so stated in the applicable Device Profile. The transitions to
Stopped state, labelled 7 and 8 in the state diagram, are triggered through the Stop
Remote Node service.
At any time, from any state, a node can be forced to reset itself. This reset procedure
can be global i.e. the device will go through the same Initialisation process as on 'Power
on', or it can apply only to the communication parameters of the node. The first type of
reset is represented in the state diagram by the transition labelled 9. It can be triggered
using the Reset Node service. The second type of reset is represented on the state
diagram by the transition labelled 10 and can be triggered using the Reset
Communication service.
The relationships between the transitions in Figure 3.38 and the NMT services
defined in CANopen are summarised in Table 3.14.

Table 3.14 Relationship between NMT services and transitions in Figure 3.38
Transition Service
1 Automatic
2 Automatic
3 Start Remote Node
4 Enter Pre-operational State
5 Enter Pre-operational State
6 Start Remote Node
7 Stop Remote Node
8 Stop Remote Node
9 Reset Node
10 Reset Communication

It is important to note that Emergency Objects can be transmitted by a node, as long

as it is not in Stopped state, any time an internal device error is detected.

Figure 3.39 Protocol for NMT Module Control services

The protocol for the Module Control NMT services is shown in Figure 3.39. The CS
field indicates a NMT Command Specifier that is used to differentiate between the
 106

different services. The Node ID field carries the Node ID of the node to which the
message is intended. If all nodes are being simultaneously addressed then this field will
contain zero. This is the reason why a device can never have a Node ID of 0.
CANopen reserves CAN message identifier 0 to be used in the protocols for the
NMT Module Control services.

3.8.3 CANopen Network Management Error Control Services

In a CANopen network, it is very important that the device managing the
communications, the NMT Master, keeps track of the state that each device is in within
the network. This is the only way in which there can be a good level of certainty that
each device will be able to respond correctly to whatever is requested from it.
The problem of keeping track of the states of the devices in a CANopen network is
especially relevant to devices that do not transmit PDOs regularly, as these could be
used to assess the device's state.
If no mechanism is implemented on the network allowing node state monitoring, an
internal event in one of the devices could cause an undetected change of the device's
state e.g. to Stopped, and, when some request was issued to this device, an unexpected
error would occur. This type of situation can be very costly in certain types of
applications, where the communications reliability issue is critical. To solve this
problem, CANopen defines the Node Guarding, the Life-guarding and the Heartbeat
services.

3.8.3.1 Node Guarding and Life-guarding Services

An NMT Master that implements the Node Guarding functionality maintains a
network database where the expected states of all the devices in the network are
recorded. The Master then polls each device regularly, retrieving their states and
comparing them to the values in the database. Any differences will cause a network
error to be signalled locally by the NMT Master to the application, which then should
take appropriate actions to ensure that all devices go to a safe state.
For the NMT Slave, the Node Guarding protocol starts on reception of the first
request from the Master. The protocol for the Node Guarding service is shown in Figure
3.40.

Table 3.15 State codes for Node Guarding

Code State
4 Stopped
5 Operational
127 Pre-operational
 107

Figure 3.40 Node Guarding protocol

The NMT Master issues a remote frame with the message identifier that was
assigned for the Node Guarding polling of a particular device. This message triggers the
transmission of a reply by the Slave, containing a single data byte. In this reply the
Slave indicates which state it is in, using the seven least significant bits in byte 0. The
codes used to signal each state are shown in Table 3.15. Additionally, a Toggle bit (bit 7
in byte 0) is used. The value of this bit must be changed in successive polling cycles and
failure to do so implies the signalling of an error by the NMT Master to its local
application. The value of the Toggle bit for the first transmission should be 0.
Two very important parameters related with the operation of the Node Guarding
protocol are the Guard Time and the Lifetime Factor. These parameters are the basis for
the Life-guarding service and are represented in a Slave's Object Dictionary at indexes
100CH and 100DH respectively.
The Guard Time is the time interval that should elapse between two Node Guarding
polling cycles. The Lifetime Factor defines the time limit for the reception of a Node
Guarding message by the Slave: if a Node Guarding message is not received during this
time, an error will be signalled by the NMT Slave to the application, so that appropriate
action can be taken. The protocol for the Life-guarding service, shown in Figure 3.41, is
based on the procedure just described. The Life-guarding service is therefore a provider-
initiated service, on the NMT Slave side, through which the application is notified of an
error in the Node Guarding protocol, probably due to a failure of the NMT Master.
The Guard Time parameter is indicated in milliseconds. The Lifetime Factor defines
the Life-guarding time limit as a factor of the Guard Time. If the values of the Guard
Time and Lifetime parameters are 0, which is the default situation, the Slave will not
monitor the action of the Master. The implementation of the Guard Time and Lifetime
Factor mechanisms is optional.
Finally, it is important to note that the NMT Master must implement some kind of
time-out mechanism, so that it can signal an error if a Node Guarding reply is not
 108

received. This is mentioned in the CANopen specification, but the actual

implementation is left as application specific.
The Node Guarding mechanism should be active in all states, even state Stopped.
The identifier used in the Node Guarding protocol is derived from the Node ID of the
Producer as will be seen in Section 3.8.4 and it is unchangeable.
Node Guarding is an optional feature in CANopen devices. However, it must be
implemented if a device does not support the Heartbeat message discussed in the next
section.

Figure 3.41 Life-guarding protocol

3.8.3.2 Heartbeat Service

As discussed in the previous section, the Node Guarding service is based on a
polling mechanism whereby the NMT Master sends a request to each Slave in order to
obtain information about its state.
The Heartbeat service fulfils exactly the same purpose as the Node Guarding
service. However, the protocol for this service removes from the Master the strain of
having to poll each Slave.
The Heartbeat service follows the Producer/Consumer model. The philosophy of the
Heartbeat service is that there is one device on the network called the Heartbeat
Consumer, not necessarily the device operating as NMT Master, that is monitoring the
state of at least one other CANopen node called the Heartbeat Producer.
The protocol for the Heartbeat service is shown in Figure 3.42.
Typically, the roles of Consumer and Producer will be carried out by the NMT
Master and Slave, respectively. CANopen accepts the existence of more than one
Consumer for the Heartbeat message, but this will not be the usual situation. The
protocol for the Heartbeat service consists basically in the Producer placing periodically
a message on the network signalling its state. The Consumer monitors the arrival of
these messages and signals when a state error or a timeout is detected.
The State Codes used in the Heartbeat protocol are the same ones used in the Node
Guarding protocol listed in Table 3.15.
 109

Figure 3.42 Heartbeat protocol

There are two parameters associated with the Heartbeat protocol:

• The Heartbeat Producer Time is configured on the Producer device and it
determines the time that should separate the transmission of two Heartbeat
messages.
• The Heartbeat Consumer Time is configured on the Consumer device and it
determines the time that should separate the reception of two Heartbeat messages.
The value of this parameter sets the time interval that the Heartbeat Consumer waits
before signalling an error indicating that the Heartbeat message was not received.

The Heartbeat Producer Time is stored in Index 1017H in the Object Dictionary of
the Heartbeat Producer as a multiple of 1 millisecond. The Heartbeat Consumer time is
stored in Index 1016H in the Object Dictionary of the Heartbeat Consumer. Since the
Heartbeat Consumer can monitor more than one device, the 1016H entry is an ARRAY
with up to 127 entries. Each entry holds an UNSIGNED32 value divided into two bit
fields as shown in Table 3.16.

Table 3.16 Heartbeat Consumer Time entry

Bit Number Meaning
31 to 24 Reserved
23 to 16 Node ID of Producer
15 to 0 Heartbeat Consumer Time

The identifier used in the Heartbeat protocol is derived from the Node ID of the
Producer as will be seen in Section 3.8.4 and it is unchangeable. In fact, the message
identifier used in the Heartbeat protocol is the same one used in the Node Guarding
protocol. For this reason, the two protocols cannot be active at the same time in a given
device. The CANopen specification states that in devices that implement both the Node
Guarding and the Heartbeat protocol, the latter takes precedence. In other words, when
such a device is configured with a Heartbeat
Producer Time greater than zero, the device assumes that the Heartbeat protocol
should be used and deactivates the Node Guarding mechanism.
 110

3.8.4 Pre-defined Connection Set

To spare the systems integrator some of the work involved in building CANopen
applications, particularly simple ones, a default scheme for the allocation of identifiers
to devices is defined in the CANopen Communication Profile.
The CANopen default identifier allocation scheme can be thought of as a predefined
Master/Slave connection set that allows the implementation of peer-to-peer
communication between an Application Master device and the remaining Slave nodes
without the need for an identifier distribution process.
This default configuration is available in each device after the Initialisation phase,
when the device enters the Pre-operational state. It can then be partially changed using
SDOs.
The default message identifiers that each Slave device will use for data exchange
with the Application Master are composed of two functional parts, as shown in Figure
3.43.

Figure 3.43 Default identifier functional structure

The Functional Code part of the identifier will determine its priority, according to
the function it will be used for. The Module (Node) ID part of the identifier will permit
different nodes using identifiers from the same functional group without
causing conflicts.
The full set of default identifiers for peer-to-peer communication between
Application Master and Slaves is shown in Table 3.17.

Table 3.17 Default message identifier allocation for peer-to-peer communication

Object Function Code (binary) Resulting Identifiers
Emergency Object 0001 129-255
PDO1 (transmit) 0011 385 -511
PDO1 (receive) 0100 513 -639
PDO2 (transmit) 0101 641 - 767
PD02 (receive) 0110 769 - 895
PDO3 (transmit) 0111 897 - 1023
PDO3 (receive 1000 1025 - 1151
PDO4 (transmit) 1001 1153- 1279
PD04 (receive) 1010 1281 - 1407
SDO (transmit) 1011 1409- 1535
SDO (receive) 1100 1537 - 1663
NMT Error Control and Boot-up service 1110 1793 - 1919

This set-up allocates message identifiers to each device for eight Process Data
Objects (four receive and four transmit PDOs), one Service Data Object (two identifiers
are required for this purpose) and the Emergency Object. An additional identifier is
allocated for the NMT Error Control services (Node Guarding and Heartbeat), as well as
 111

the Boot-up Service that share the same message identifier. The Boot-up service will be
discussed in Section 3.8.6.
In addition to the message identifiers that allow the Application Master to
communicate with each Slave on a peer-to-peer basis, the CANopen Pre-defined
Connection Set also reserves message identifiers for messages broadcasted on the bus as
shown in Table 3.18.

Table 3.18 Default message identifier allocation for broadcast objects

Object Function Code (binary) Resulting Identifiers
NMT Module Control 0000 0
Synchronisation Object 0010 128 (80H)
Time Stamp 0011 256 (100H)

3.8.5 Allocation of Identifiers by a Configuration Tool

A good approach when building a CANopen network is to start with the default
identifier allocation discussed in the previous section and modify it for application
specific purposes.
In networks where the identifier allocation is to be altered by a Configuration Tool,
using SDOs, there are some recommendations that should be taken into account.
As a guideline for the allocation of message identifiers, the CANopen
Communication Profile contains some recommendations regarding how to distribute the
different Communication Objects throughout the CAN message identifier range. These
recommendations are summarised in Table 3.19.
The SYNC Object should be assigned the highest priority in the network so as to
minimise drifts in the Communication Cycle Period. Emergency messages are also
given very high priority identifiers, for fast error signalling. The Time Stamp messages
should be allocated an identifier in the same priority range but with lower priority than
the Emergency messages.

Table 3.19 Suggested Communication Object priority allocation

Priority Communication Object
Highest  SYNC
(low identifier)  Emergency
 Network timing (TIME STAMP)
 Synchronisation messages (other)
 Synchronous PDOs
Lowest  Asynchronous PDOs
(high identifier)  SDOs

In another priority group are the PDOs, which should have lower priority than the
previous objects, but higher than SDOs. Among PDOs, synchronous PDOs should be
given higher priorities so that the behaviour of the cyclic traffic can be more consistent,
as mentioned in Section 3.6.2. Finally the identifiers with lowest priority should be used
for SDOs.

3.8.6 CANopen Network Boot-up Procedure

The CANopen Boot-up Procedure, defined in DS301 as the standard way of starting
the operation of a CANopen network, must be supported by all CANopen devices. This
procedure consists of the following steps:
 112

• Once the devices terminate the internal initialisation process, they enter the Pre-
operational state. The entry into Pre-operational state must be signalled by all
devices using the Boot-up service that will be introduced in this section.
• At this stage, the default identifier allocation scheme will be active and SDOs can be
used to further configure the devices. The configuration of CANopen nodes is
usually performed by a Configuration Application residing on the node that operates
as the Client of the default Server SDOs implemented by each device.
• Before starting the normal operation of the network, it might be useful to start the
transmission of the Synchronisation Object, if it is used, while the devices remain in
Pre-operational state. This will permit the devices consuming the Synchronisation
Object to synchronise themselves before normal operation is initiated.
• At this stage Node Guarding, if supported, can be started using the parameters
configured in step one.
• Finally, the devices are placed in Operational state and all types of communication
are then enabled.

The latest version of the CANopen Communication Profile defines a new mandatory
NMT service through which the NMT slaves must signal the end of their initialisation
process, and their entry into Pre-operational state: the Boot-up service.
The protocol for the Boot-up service consists of a single message sent by each
Slave, using the same message identifier used by the Heartbeat protocol or the Node
Guarding protocol. This message must carry one byte only, containing the value zero.
The protocol for the Boot-up service is shown in Figure 3.44.

Figure 3.44 Node Guarding protocol

3.8.7 Minimum Capability Device

Some very simple devices will not have the processing capability nor the resources
that are required to implement all the functions described in the CANopen
Communication Profile e.g. the dynamic PDO mapping scheme discussed in Section
3.6.4.2. In fact, there is a minimum set of capabilities that any device must have in order
to be able to co-operate with full capability devices on the same network. These
capabilities are:
• Network Management Node ID parameter.
• Object Dictionary complying with the applicable Device Profile.
• One Server SDO and the associated mandatory Object Dictionary entries. These
entries must not allow write accesses so that the configuration of the SDO
parameters is unchangeable.
 113

• Support of the following NMT services: Reset Node, Reset Communication, Enter
Pre-operational State, Start Remote Node, Stop Remote Node and Boot-up.
• Support of one of the following NMT services: Node Guarding or Heartbeat
Message.

3.9 ELECTRONIC DATA SHEETS (EDS) AND DEVICE

CONFIGURATION FILES (DCF)
Electronic Data Sheets and Device Configuration Files are standardised ways of
conveying device information to the user of the device, specified by CANopen. The
existence of such standardised media should permit the implementation of tools that can
perform automatically a set of tasks such as the configuration of CANopen devices.
The Electronic Data Sheet and Device Configuration File formats discussed in this
book are based on version 3.0 of the CANopen Communication Profile. Version 4.0 of
this specification does not include these definitions because they are under revision by
the CAN in Automation group. For updated information on the revision of the EDS and
DCF definitions, the authors suggest that interested readers should contact the CiA.
The format for EDS and DCF documents is defined for electronic storage. The
resulting files will be ASCII-coded, and it is recommended to use the ANSI character
set.
An Electronic Data Sheet describes the following features in a device:
• The communication functionality and objects that are implemented according
toDS301.
• The device specific functionality and objects that are implemented according to the
CANopen Device Profiles.
• The manufacturer specific functionality of the device.

The EDS describes only the features of the device that are not configuration
dependent; it is therefore a template that is always a valid description of the device,
regardless of its configuration.
A Device Configuration File, on the other hand, describes not only which objects a
device implements but also their values for a particular configuration. The baudrate and
the Node ID of the device are also included in a DCF. Therefore, several DCFs can be
based on a single EDS, reflecting several possible device configurations.
An EDS should be supplied by the vendor of a particular device as part of its
documentation. If no Electronic Data Sheet is supplied, the default EDS for that
particular type of device (based on the applicable Device Profile) can be used and must
be valid.
Device Configuration Files can be very useful for storing a particular configuration
of a device that will need to be restored later on. It is then possible for an automatic
configuration tool to pick up this file and perform the configuration automatically.

3.9.1 Structure of an Electronic Data Sheet

An Electronic Data Sheet is functionally divided into three main blocks, each block
with one or more sections:
• File Information - there is only one section in this part of the EDS and it contains a
description of the file, the date and time of its creation and other basic information.
 114

• General Device Information Section - there is only one section in this part of the
EDS and it contains information about the device's manufacturer and product type
information. It also describes what capabilities are implemented on the device e.g.
whether it supports the dynamic mapping of PDOs.
• Object Dictionary Sections - the number of sections in this part of the EDS will
depend on the device's Object Dictionary. These sections list the Object Dictionary
entries that are implemented on the device, along with their default values.

The beginning of a section in an EDS is indicated by the section name keyword

enclosed in square brackets: [KEYWORD]. Following the indication of the beginning
of the section, the complete set of parameters for that section is listed and each
parameter is presented in the format: KEYWORD=VALUE.
The structure of an EDS is described in more detail in the following subsections.

3.9.1.1 File Information Section

The structure of the File Information section is shown below.

[FileInfo]
FileName= File name according to DOS restrictions
FileVersion= File version ( UNSIGNED8 )
FileRevision= File revision ( UNSIGNED8 )
Description= File description ( 255 characters )
CreationTime= File creation time (characters in format hh:mm(AM|PM))
CreationDate= Date of file creation ( characters in format mm-dd-yyyy )
CreatedBy= Name or description of file creator ( 255 characters )
ModificationTime= Time of last modification (characters in format hh:mm(AM|PM))
ModificationDate= Date of last modification ( characters in format mm-dd-yyyy )
ModifiedBy= Name or description of the modification ( 255 characters)

3.9.1.2 General Device Information Section

The structure of the General Device Information section is shown below.

[DeviceInfo]
VendorName= Vendor name ( 255 characters )
VendorNumber= Vendor code ( UNSIGNED32 )
ProductName= Product name ( 255 characters )
ProductNumber= Product number ( UNSIGNED32 )
ProductVersion= Product version ( UNSIGNED8 )
ProductRevision= Product revision ( UNSIGNED8 )
OrderCode= Product order code (255 characters)
LMT_ManufacturerName= Manufacturer name part of LMT address ( 7 characters )
LMT_ProductName= Product name part of LMT address ( 7 characters )
Baudrate_10= Supported baudrates ( 0 = not supported, 1 = supported )
Baudrate_20=
Baudrate_50=
Baudrate_100=
Baudrate_125=
Baudrate_250=
Baudrate_500=
Baudrate_800=
Baudrate_1000=
SimpleBootUpMaster= Minimum Boot-up master functionality
( 0 = not supported, 1 = supported )
 115

SimpleBootUpSlave= Minimum Boot-up slave functionality

( 0 = not supported, 1 = supported )
ExtendedBootUpMaster= Extended Boot-up master functionality
( 0 = not supported, 1 = supported )
ExtendedBootUpSlave= Extended Boot-up slave functionality
( 0 = not supported, 1 = supported )
Granularity= Number of objects that can be mapped in a PDO
( 0 = fixed mapping, 1-64 = granularity )

The Extended Boot-up Master and Slave functionalities are related with the
CANopen Extended Boot-up Procedure that was included in Version 3.0 of the
CANopen Communication Profile but is not present in Version 4.0. This is also the case
of the LMT Manufacturer Name and LMT Product Name parameters, used by CAL
Layer Management services.

3.9.1.3 Object Dictionary Sections

In the part of a EDS that describes the Object Dictionary of the device, the entries
are grouped according to their nature: Data Types, Mandatory Objects, Optional Objects
and Manufacturer Specific Objects.
The Data Types that a device supports are listed in a section with the following
format:

[StandardDataTypes]
0x0001= Supported data types ( 0 = not supported, 1 = supported )
0x0002=
0x0003=
0x0004=
0x0005=
0x0006=
0x0007=
0x0008=
0x0009=
0x000A=
0x000B=
0x000C=
0x000D=
0x000E=
0x000F=
0x0020=
0x0021=
0x0022=

All Data Types defined in DS301 Version 3.0 are listed according to their Object
Dictionary entries, and the supported objects are signalled with a value of 1.
For each of the remaining classes of objects (Mandatory, Optional and Manufacturer
Specific), the supported entries are first listed in an index section and then they are
presented in more detail in object-specific sections.
All supported objects of a given class are listed in an index section with the
following structure:
 116

[KEYWORD]
SupportedObjects= Number of supported entries
l=0x<INDEX> 1st supported entry
2=0x<INDEX> 2nd supported entry
3=0x<INDEX> 3rd supported entry
4=0x<INDEX> 4th supported entry

The possible KEYWORD values for these index sections are: MandatoryObjects,
OptionalObjects and ManufacturerObjects. All entries that are listed in these index
sections are then represented in the EDS by additional sections describing them in a
more detail. These sections have the following format for each Object Dictionary entry:

[0x<INDEX>]
SubNumber= Number of Sub-indexes available at this Index ( UNSIGNED8 )
ParameterName= Parameter name ( 255 characters )
ObjectType= Object code (Refer to Table 3.4)
DataType= Object Dictionary Index of the data type of the object.
LowLimit= Low limit of object value (if applicable )
HighLimit= High limit of object value (if applicable )
AccessType= Access type ( ro, wo, rw, rwr, rww )
DefaultValue= Default Value (if applicable)
PDOMapping= Object can or cannot be mapped ( 0 = not supported, 1 = supported )

If, at a given Index, the SubNumber parameter is nonzero, this means that a series of
sections follow, describing each of the Sub-indexes in more detail. These sections have
the following structure:

[0x<INDEX>sub<SUB INDEX>]
ParameterName= Parameter name ( 255 characters )
ObjectType= Object code (Refer to Table 3.4 )
DataType= Object Dictionary Index of the data type of the object.
LowLimit= Low limit of object value (if applicable )
HighLimit= High limit of object value (if applicable )
AccessType= Access type ( ro, wo, rw, rwr, rww )
DefaultValue= Default Value (if applicable )
PDOMapping= Object can or cannot be mapped
( 0 = not supported, 1 = supported )

Note that not all entries in this type of section are mandatory e.g. the DefaultValue
entry may not be applicable to particular Object Dictionary entries.

3.9.1.4 Additional EDS Sections

There are two additional sections that can appear in an EDS.
The first section can be used to introduce comments. Its format is as follows:

[Comments]
Lines= Number of comment lines ( UNSIGNED 16 )
Linel= lst line of comments ( 255 characters )
Line2= 2nd line of comments ( 255 characters )
Line3= 3rd line of comments ( 255 characters )
…
 117

The second section is used to indicate which data types can be referenced in PDO
mappings so as to program the device to ignore a particular part of the PDO data
(dummy mapping). The format for this section is the following:

[DummyUsage]
Dummy0001= Data type at Index 1 (1 = can be referenced, 0 = cannot be referenced)
Dummy0002= Data type at Index 2 (1 = can be referenced, 0 = cannot be referenced)
Dummy0003= Data type at Index 3 (1 = can be referenced, 0 = cannot be referenced)
Dummy0004= Data type at Index 4 (1 = can be referenced, 0 = cannot be referenced)
Dummy0005= Data type at Index 5 (1 = can be referenced, 0 = cannot be referenced)
Dummy0006= Data type at Index 6 (1 = can be referenced, 0 = cannot be referenced)
Dummy0007= Data type at Index 7 (1 = can be referenced, 0 = cannot be referenced)

Only data types at Indexes 1 to 7 can be used for dummy mapping and these data
types must be supported by the device.

3.9.2 DCF-specific Sections and Keywords

A DCF is virtually identical to an EDS. However, DCFs contain an additional
section entitled Device Commissioning and additional keywords in the sections that are
common to EDS files.
The Device Commissioning section describes the conditions in which the device is
configured to operate. Its structure is the following:

[DeviceCommissioning]
NodeID= Device's Node ID ( UNSIGNED8 )
NodeName= Node name part of the NMT address (7 characters)
Baudrate= Device's baudrate ( UNSIGNED 16 )
NetNumber= Number of the network ( UNSIGNED32 )
NetworkName= Network name ( 255 characters )
LMT_SerialNumber= Serial number part of LMT address ( 14 characters [0-9])

Of these parameters, only the Node Name and the LMT Serial Number have no
parallel in Version 4.0 of the CANopen Communication Profile. Both of these
parameters are related to the CAN Application Layer.
DCFs contain the following keywords in addition to the ones described in the
previous section for EDS files:
• In the File Information section, the parameter 'LastEDS=' is used to indicate the
EDS on which the DCF was based. The EDS name is indicated according to DOS
restrictions.
• In the object sections, the parameter 'ParameterValue=' is used to indicate the value
with which each entry is configured. Additionally, if the Object Type is 'DOMAIN',
it is possible to indicate the files that can be read or written to when downloading or
uploading that Object Dictionary entry using the keywords 'DownloadFile=' and
'UploadFile='. A 'DOMAIN' is a data type used to represent large variable amounts
of data e.g. executable program code.

3.10 OTHER CANopen FEATURES

The CANopen Communication Profile specifies mechanisms that are sufficient for
the definition of profiles for devices which provide relatively low level I/O functionality
such as encoders, drives, etc. However, when it comes to profiling the functionality of
 118

an intelligent device, such as a PLC running an application, additional mechanisms are

required.
The CiA has been developing an extension to the CANopen Communication Profile
that can be applied to such intelligent devices. This extension is referenced as DS302
and is a 'Framework for Programmable CANopen devices'. The mechanisms defined in
this document will serve as a basis for the development of Device Profiles for intelligent
devices.
The communication mechanisms covered in DS302 are:
• Definition of a SDO Manager device that can handle the dynamic establishment of
SDO connections between devices.
• Definition of a CANopen Manager device, clarifying the issue of what type of
functionality must a network controller device implement.
• Definition of dynamically allocated Object Dictionary entries that can be used for
the representation of remote I/O data on programmable nodes such as PLCs.
• Definition of a general mechanism for downloading program data and functions to
devices.
• Definition of a Configuration Manager device that will be able to detect and
configure unconfigured nodes during system boot-up.
• A remote node debugging mechanism in the form of an Operating System command
and prompt.
• A multiplexor PDO which allows transferring a large number of parameters using
the same message identifier without changing the PDO mapping. This type of PDO
also supports a node group mechanism to address several nodes simultaneously.

In the following, an overview of some of these issues will be given.

3.10.1 Definition of a CANopen Manager device

It is very important to keep in mind that a CANopen network is always used to
support a distributed application. From the application's point of view, a device will run
the central part of the software, controlling the system, and that is called the Application
Master. This device, as all others in the network, will be using CANopen to
communicate.
From the network point of view, there are several mechanisms that must be
implemented to ensure a reliable transfer of information. These mechanisms will be
based on Master / Slave, Client / Server or Producer / Consumer relationships. Hence, in
addition to the Application Master that controls the application, several other entities
will be active in a CANopen network, controlling other aspects of the system. These
are:
• NMT Master - It is important to note, however, that usually the NMT Master is
implemented as part of the Application Master, as it is very important for the
operation of the network.
• SDO Manager - this functionality will be discussed in Section 3.10.2. It is an
optional functionality responsible for handling the dynamic establishment of SDO
connections. If implemented, it must reside with the NMT Master on the same node.
• Configuration Manager - this functionality will be discussed in Section 3.10.4. It is
an optional functionality, which provides mechanisms for configuration of nodes in
 119

a system during boot-up. The Configuration Manager may or may not reside on the
same node as the NMT Master.
• SYNC Producer - the SYNC Producer is an optional functionality that is responsible
for transmitting the SYNC Object. It may reside on any node in a CANopen system.
• Time Stamp Producer - the Time Stamp Producer is an optional functionality, which
is responsible for transmitting the Time Stamp object. It may reside on any one node
in a CANopen system.

Although it is not mandatory to do so, it is often the case when most of these
functionalities are implemented on the same node. To describe this characteristic of
CANopen, a new concept is defined in DS302: the CANopen Manager. A node is
called the CANopen Manager if it implements at least the NMT Master and SDO
Manager functionalities and, optionally, the Configuration Manager functionality.

3.10.2 SDO Manager and Dynamic Establishment of SDO Connections

The SDO Manager is defined in DS302 as the device that controls the dynamic
establishment of SDO connections between devices in a CANopen network.
To keep track of all SDO connections that are active on the bus, the SDO Manager
maintains a table where it stores all the information about which device is using which
SDO connection.
The existence of at least one Service Data Object through which each device can be
configured is mandatory in CANopen. For this, each device must implement a default
Service Data Object, using the message identifiers pre-defined in the CANopen
Communication Profile (see Section 3.83). DS302 further specifies that these default
objects cannot be used by any device other than the SDO Manager, unless a dynamic
connection is established under the Manager's supervision. Additional SDOs may be
optionally supported by some devices and the use of these must also be requested from
the SDO Manager.
For a connection to be established between two devices, both of them must be
configured for this purpose. The SDO Manager accepts requests from one device to
establish a Service Data Object connection to another device, and configure both
devices automatically so that the communication is established.
For this to be possible, DS302 specifies a new service called Dynamic SDO Request,
which can be invoked by a device requesting the new connection. This service indicates
to the SDO Manager that one of the devices is requesting a new connection, but it does
not indicate which device or any other details about the connection to be established.
Therefore, on receiving the service indication, the SDO Manager will proceed to
poll each device using the default Service Data Objects, checking which device issued
the request. Each device in the network will implement an Object Dictionary entry
where this information will be available for the SDO Manager to read.
When the device that issued the request is found, the SDO Manager creates a new
SDO connection with it where the SDO Manager will be the Server. The requesting
device is then able to write the details of the connection it is requesting to a dedicated
Object Dictionary entry on the SDO Manager.
The SDO Manager then checks to see if any SDOs are available on the destination
device and, if the connection is possible, it configures both devices to communicate
with each other. For this, the Manager needs to configure the message identifiers and
 120

enable the SDOs in each device, matching the input SDO of one device to the output
SDO of the other and vice-versa.

3.10.3 Programmable Device I/O

When writing a program for an intelligent device that will be controlling a
distributed application, some of the variables (input or output) referenced in this
program will correspond to parameters which can only be accessed through the
network. In the particular case of a CANopen network, the interface between the
internal variables of a device and the network is the Object Dictionary. Hence, a
mechanism is needed through which the remote variables that are to be used in the
program can be linked to entries in the device's Object Dictionary so that their values,
updated through the network, are accessible to the program.
The way in which this type of variable will be handled will vary according to the
programming language that is used. However, it can be assumed that some kind of
declaration attribute such as EXTERN will be required. Moreover, the compilation /
linking of a program that uses this type of variable will require tools that are able to
dynamically relate the variables with the correct locations in the Object Dictionary of
the device, using Index and Sub-index information.
For this purpose, DS302 specifies a mechanism called Dynamic Index Assignment.
This mechanism consists of reserving an area on a device's Object Dictionary that can
be used to automatically map program variables. This area will be divided into
segments, one for each data type and one for each information flow direction i.e. input
or output. Variables of the same type will be organised as arrays.
This information will then be available to the Network Configuration Tool, in the
form of a Device Configuration File, so that it can set-up the communication
mechanisms that will support these variables.
The information contained in the DCF can also be used by the software building tool
to relate the EXTERN program variables to the appropriate Object Dictionary entries.

3.10.4 Configuration Manager

The Configuration Manager, defined in DS302, handles device configuration during
the network boot-up. Basically this device will have access to Device Configuration
Files for all the devices in the network, and use them to bring each device from its
default configuration to the one defined in the corresponding DCF.
DS302 defines several mechanisms for DCF and EDS storage, as well as
mechanisms for determining whether a device has stored its previous configuration,
whether this configuration is consistent with the DCF and if it needs to be reconfigured.

3.10.5 Multiplexor PDO and Node Group Addressing

The usage of normal PDOs requires a certain amount of node configuration if
several Object Dictionary entries are to be accessed using the same message identifier.
This is due to the fact that the PDO mapping must be altered using SDOs each time a
different entry is to be accessed. This problem gets even worse if the PDO is intended
for several nodes, since all of them must be reconfigured. Another choice is to use
several PDOs, however, in this case, the number of supported PDOs of normal
CANopen nodes is rapidly exceeded.
 121

To cope with this problem, DS302 defines a new mechanism called a Multiplexor
PDO. This type of PDO is capable of writing to any Object Dictionary entry. Its format
is illustrated in Figure 3.45.

Figure 3.45 Format of the Multiplexor PDO

The Multiplexor field holds the Index and Sub-index of the Object Dictionary entry
to be accessed, coded in a similar way to SDOs. The f field holds a format flag, and the
Address field will have different meanings, depending on the value of the/flag.
The basic mode of operation of the Multiplexor PDO is obtained by setting f to 1
and the Address field to 0. The group of nodes configured to receive this PDO will use
the Multiplexor field to identify the Object Dictionary entry that is being accessed and
update it using the data stored in the Data field.
In addition to this operation mode, the functionality of the Multiplexor PDO is
extended to permit the implementation of two other useful data transfer mechanisms:
• Setting f to 1 and inserting a Node ID in the Address field, it is possible to address
only one of the nodes configured to receive the PDO. This can be a very helpful
feature, since it will permit avoiding a lot of the node configuration work that would
be required to prevent all the other nodes in the group from accepting the
information.
• Setting f to 0, the Address field will hold the Node ID of the source node. This
makes it possible for the receiver to identify the node transmitting the PDO and take
appropriate action based on this information.

The mechanisms described above make it possible to implement group-addressing

schemes in a CANopen network. Before DS302 no formal tool was defined for this
purpose and it was necessary to find ad-hoc solutions whenever group addressing was
required. These solutions would involve either extensive node configuration and
reconfiguration or a large number of PDOs. Using the Multiplexor PDO this can be
achieved in an elegant way.
A good example of a situation where the use of the Multiplexor PDO would
simplify the configuration process is the one discussed in Section 3.6.4.2 and shown in
Figure 3.34. Assuming that all the Digital Output Devices were configured to operate
using a Multiplexor PDO with the same identifier, the configuration of the PDO
communication parameters discussed in the example for the receiver devices could be
achieved with four messages only: one for each Object Dictionary entry. This would cut
by half the total number of configuration data transfers.
 122

CHAPTER 4
CANopen Implementation Issues
Chapter Objectives
When you have completed this chapter you should:
• Understand the difficulties associated with implementing CANopen.
• Understand how a typical CANopen device is implemented.
• Understand how a multiple CANopen device module is implemented
• Be aware that there is a trade off between efficiency and functionality in CANopen
implementations.
• Recognise the message burst problem and its causes in CANopen networks.
• Be able to construct a CANopen network.
• Be familiar with the details of CANopen communication.

4.1 INTRODUCTION
CANopen was developed as the result of an European project that focused on how
CAN technology could be used in industrial automation systems, for real-time control
of components such as digital and analogue I/O devices, drives, man-machine or
machine-operator interfaces, vision systems, and many others. Its purpose is to simplify
system integration and device standardisation in CAN based systems.
As all protocol specifications, CANopen does not contain implementation-specific
information. In fact, the CANopen specification only describes the external behaviour
of devices. For this reason, even after reading the CANopen specifications, one may
still find it difficult to grasp all the aspects of CANopen implementation and CANopen-
based system integration.
This chapter attempts to fill some of the gaps in the information available to
CANopen users. It has been written as a practical guide to CANopen and it is aimed at
both systems integrators and device manufacturers.

4.2 USING CAN HARDWARE IN A CANopen CONTEXT

In order to implement CANopen some consideration must be given to the
communication services and functionality to be implemented in the device. A good
place to start is the utilisation of the CAN controller. This has implications both for the
reception of CAN messages and for the transmission of data. In this section, this and
other related issues will be discussed.

4.2.1 Revision of CAN Hardware Platforms

Before moving on to the details of CANopen implementation, it is interesting to
revisit some of the concepts discussed in Chapter 2 regarding CAN hardware
implementations.
In terms of CAN hardware, two configurations exist. One is to use a standalone
CAN controller attached to the external address and data bus of a
processor/microcontroller. The alternative is to use a microcontroller with integrated
CAN controller; in which case, the CAN controller is accessed over the
microcontroller's internal address and data bus.
 123

CAN hardware implementations tend to vary slightly from manufacturer to

manufacturer in the way that the programming registers are set up and the function that
they perform. However, two common forms of CAN hardware implementation exist:
Basic CAN and Full CAN. These two types of CAN hardware implementation both
produce CAN telegrams in the same format; however, the type of CAN controller that is
used has implications for processor loading and, therefore, for the amount of bus traffic
that a given processor can handle effectively without overloading.
Both Full CAN and Basic CAN hardware implementation have varying extents of
message filtering capabilities allowing individual or a group of messages to be
selectively filtered out by the CAN controller hardware using acceptance filters. The
configuration of acceptance filters is achieved through the manipulation of registers
provided by the CAN controller for this purpose. These registers are usually called
Acceptance Mask registers.
An incoming message is filtered according to its identifier: provided the identifier of
the message passes the filtering, the message is loaded into a CAN controller data buffer
area, ready for reading by the processor. Interrupt facilities between the CAN controller
and processor are then used to notify the latter that an incoming message has been
received and that it is ready for the processor to read.
The effect of the filtering is to prevent the main processor from being interrupted
every time a CAN message is transmitted on the bus.
A Basic CAN controller has a limited filtering capability, restricting acceptance of
messages to certain groups of identifiers. Therefore, it will be up to the associated
processor to software filter the incoming telegrams. This loads the processor more than
pure hardware filtering such as that provided by Full CAN controllers.
Full CAN controllers have several data buffer areas, each capable of storing the data
for a CAN telegram. Each buffer area or message object has its own filter that accepts
one CAN identifier. The CAN controller will automatically put the incoming CAN
message in the correct object according to its identifier. The processor is interrupted
only once an incoming message has been placed in its designated buffer area and an
interrupt register allows the processor to determine which message object accepted the
message data. The typical features of a Full CAN controller layout are illustrated in
Figure 4.1.
The number of objects within the CAN controller (10 in this case) can be restrictive
in some applications that require a node to receive a high number of different
identifiers. However, it is common place that one of the message objects can be
configured to receive all identifiers or a subset of them, acting like a Basic CAN
controller.
 124

Figure 4.1 Typical Full CAN controller layout

4.2.2 Message Reception: CANopen Filtering Requirements

CANopen communication can involve a number of different services that use
different sets of CAN identifiers and offer different types of functionality for data
transfer. The implementation of these services requires that the CAN controller is able
to filter a number of CAN messages from the bus traffic and pass them on to the
CANopen software for processing.
Using a Full CAN controller the individual message objects must be set-up for
reception of particular pieces of information. Using Basic CAN the identifiers would be
filtered using several 'if-then' constructs in a receive message interrupt routine. In this
case, it is not possible to use any hardware filtering as the Basic CAN acceptance filter
can only be configured to receive specific ranges or groups of identifiers. The spread of
identifiers used in CANopen does not make this possible.
In a very simple CANopen device that uses only one PDO and that does not
consume the Synchronisation Object, the allocation of message objects for message
reception in a Full CAN controller can be as shown in Table 4.1.

Table 4.1 Receive identifier allocation for a simple node

Service Default Receive Identifier Allocation Object
Network Management 0H 1
Node Guarding 700H+Node ID (1792+Node ID) 2
SDO Request 600H+Node ID (1536+Node ID) 3
Receive PDO 200H+Node ID (512+Node ID) 4

It is clear from the previous table that only a small portion of the capabilities of a
typical Full CAN controller would be used in this type of application. In fact, this is the
type of implementation where the usage of a Basic CAN controller would be advisable,
particularly because it is in simple devices that low-cost is more important for the
success of the product on the market.
 125

On the other hand, in a CANopen device where two PDOs are to be received,
synchronous PDO communication and time stamping are to be used, and where an
additional Server SDO is to be implemented, eight message objects are likely to be
required for message reception in a Full CAN controller. The required objects for this
particular case and a possible allocation of message reception tasks are summarised in
Table 4.2.
Contrary to the previous example, in this type of implementation the use of a Full
CAN controller is justifiable, simply because of the increased software efficiency that it
brings.

Table 4.2 Typical message object allocation scheme in a Full CAN controller
Service Default Receive Identifier Allocation Object
Network Management 0H(0) 1
Node Guarding 700H+Node ID (1792+Node ID) 2
SDO Request #1 600H+Node ID (1536+Node ID) 3
Receive PDO 1 200H+Node ID (512+Node ID) 4
Receive PDO 2 300H+Node ID (768+Node ID) 5
Synchronisation Object 80H(128) 6
Time Stamp Object 100H(512) 7
SDO Request #2 - 8

4.2.3 Transmission of CANopen Data

The way in which CAN objects are transmitted depends on the services that are to
be implemented in a CANopen device and on how short a response time is required.
The most common method of transmitting CAN telegrams for both Basic and Full CAN
controllers is to use a simple First-In, First-Out (FIFO) circular queue. The CAN
controller can then be configured to generate a transmit interrupt on successful
transmission of a message. The associated interrupt routine can then take the next
message in the queue and load it into the transmit buffer of the controller. If the
message is first in the queue, it is loaded directly into the transmit buffer. This then
initiates a cyclic transmission of further queue contents.
A second but less efficient method is to use a timer interrupt to transmit a message
every time a timer tick occurs. Again, a FIFO queue can be put to good use in such
circumstances. It must be ensured that the timer tick interval is sufficiently small to
ensure that the messages are transmitted fast enough and to avoid an ever-lengthening
queue. On the other hand, too short a timer tick may mean that the controller attempts to
transmit a message before the transmission of the previous message has finished. In this
case, precautions must be taken to avoid disrupting the ongoing transmission.
With both methods, one object of the CAN controller can be reserved specifically
for transmission of data in the queue.
There is a problem associated with both of these transmission methods. Some
information must be transmitted due to the occurrence of some kind of event or initiated
by reception of some kind of request over the bus. This is particularly true when
transmitting synchronous PDO data. In this situation, a PDO telegram is transmitted on
reception of a Synchronisation telegram. Using a queue, reception of the
Synchronisation Object would add a PDO to the transmission queue. If there
 126

are many messages preceding the newly added PDO, the PDO may not be
transmitted within an acceptable period of time. This argument also applies to remote
frame and event modes of PDO transmission.
A solution for this problem, when using a Full CAN controller, is to reserve a
message object purely for transmission of the PDO. Therefore, an interrupt routine
associated with reception of the Synchronisation telegram can initiate transmission of
the PDO simply by flipping a few bits of the corresponding message object. Other,
lower priority messages such as SDOs and Node Guarding responses can be added to
the FIFO queue as normal.
Basic CAN controllers generally have only one transmit buffer so that a similar
arrangement is not possible: all messages must be transmitted through the buffer and
therefore it is not possible to dedicate separate transmit objects for higher priority PDO
transmission. In such a case the transmit interrupt routine must take into account the fact
that there are pending higher priority PDO telegrams to transmit. These can be loaded
into the transmit buffer ahead of any FIFO queued messages (Figure 4.2). In addition,
care must be taken to make sure that the CAN transmit buffer is empty before trying to
load in new telegram data for transmission.

Figure 4.2 Example of a timer tick interrupt routine for message transmission

These arguments also apply to Full-CAN controllers where the number of message
objects is at a premium and one wishes to use only one object for transmission of data,
reserving the others for reception purposes.
In any case, using large queues for message transmission, especially of process
critical data (PDOs), in some ways defeats the purpose of having message
 127

prioritisation. It must be remembered that, in the case of Full CAN controllers,

generally some free objects will be available after allocating objects for message
reception. These can be dedicated for transmission purposes to give optimal
performance. Following this line of thought, the reasonably complex node in Table 4.2
can be updated to show the full object allocation scheme for both transmit and receive
objects. This is summarised in Table 4.3.

Table 4.3 Transmit and receive object allocation (12 Objects)

Service Default Receive ID Allocation Object
Network Management 0H(0) 1
Node Guarding 700H+Node ID (1792+Node ID) 2
SDO Request #1 600H+Node ID (1536+Node ID) 3
Receive PDO 1 200H+Node ID (512+Node ID) 4
Receive PDO 2 300H+Node ID (768+Node ID) 5
Synchronisation Object 80H (128) 6
Time Stamp Object 100H(512) 7
SDO Request #2 - 8
Transmit PDO 1 180H+Node ID (384+Node ID) 9
Transmit PDO 2 280H+Node ID (640+Node ID) 10
SDO Response 580H+Node ID (1412+Node ID) 11
Emergency Telegram 80H+Node ID (128+Node ID) 12

4.2.4 CAN Messages and Message Bursts

The hardware interface between the CAN controller and the processor can play a
major part in the communication process in a CANopen device. Whether one is using
Basic or Full CAN controllers it is vitally important that messages are retrieved from
the CAN controller receive buffer areas before they are overwritten by other incoming
messages. This is especially true at high network speeds, as the inter-frame space
becomes smaller (Table 4.4).

Table 4.4 Worst-case inter-frame spacing

Baudrate Inter-frame Space
1000 Kbit/sec 47 us
500 Kbit/sec 94 (is
250 Kbit/sec 188 us
125 Kbit/sec 376 us

Given this data, it is generally not possible for a processor to retrieve a message
from the CAN controller buffer and process it in time before the next message arrives.
In some cases, the CAN hardware implements its own buffering scheme whereby
multiple areas of buffer memory in the hardware are used to store incoming telegrams.
However, in most cases received messages should be placed in a buffer area for
processing at a later date so that they are not overwritten and therefore lost. If possible,
copying to a buffer is best done using the on-chip facilities available. For example, the
Philips 80C592 microcontroller's on-chip DMA facilities allow the transfer of a CAN
message from its receive buffer to internal data memory in a period of two instruction
cycles.
In situations of message bursts at high bus speeds the number of back-to-back
messages is not the only important factor that needs to be taken into consideration. The
 128

length of each CAN message also plays a vital role. If all the messages in the 'burst' are
of 8 bytes in length, the processor has more time before having to deal with the next
message in its receive buffer. If the burst contains messages of just a few bytes in
length, a particular processor may not be able to deal with them in time. In other words,
it is not only the number of messages in the burst but also the length of each message
that counts. The authors have encountered this problem at an early stage of
implementation of an automation cell. In their cell, the master (based on a Basic CAN
controller) could quite happily cope with bursts of messages carrying 8 bytes of data,
but it could not cope when those bursts included one or two messages carrying only two
bytes of data.
Finally, it is important to note that a device suffering from message overruns must
be able to detect this situation and notify the application accordingly. If this does not
occur, the application might not be aware that an error had occurred until it was too late
to avoid irrecoverable damage.

4.2.5 Minimising Message Bursts o n a CANopen Network

To minimise the number of errors caused by message bursts it is necessary to take
this issue into consideration during the design stages of the network. In fact, poor design
decisions can originate networks where message bursts are frequent when their
occurrence should be reduced to a minimum.
Generally, the highest rate of message bursts will occur when most of the devices
are operating in a synchronous transmission mode. When this is the case the master of
the application has to deal with several back-to-back incoming messages every time the
Synchronisation Object is broadcast on the network. In CANopen it is possible to
reduce this effect by configuring nodes to transmit PDO data every 'X' Synchronisation
telegrams. However, there will always be a case where all nodes using Synchronous
PDO transmission transmit their data on every 'Y' number of Synchronisation Objects as
shown in Figure 4.3.

Figure 4.3 Different PDO transmission rates

In Figure 4.3, three nodes A, B and C are configured to transmit PDOs on every
Synchronisation Object (node A), every other Synchronisation Object (node
B) and every third Synchronisation Object (node C). The highest message burst on
the bus will occur every 6th Communication Cycle, which represents the worst case
situation for this network.
 129

Another source of message bursts exists when several nodes are configured to
transmit information in event mode. In this mode, there is no way to predict accurately
when each node will want to transmit information on the bus as this will depend on
application specific events. This is particularly true in a device such as an analogue
input module. For such a module, it is possible to configure it to transmit a PDO
telegram on a difference or delta change (see points C and F in Figure 4.4) of its input
signal. Too small a difference value, e.g. transmit on a change of 1 bit in the input
value, will cause the module to flood the bus with messages.

Figure 4.4 PDO transmission events for an analogue input module

Similarly, when using analogue modules, it is possible to configure them to transmit

an event PDO if a limit value is exceeded. In some devices, associated with this limit is
a hysteresis value that prevents the signal from triggering an event PDO transmission,
provided the signal does not change by more than the hysteresis value while oscillating
around the limit. Once again the hysteresis value must not be made too small so as to
minimise message bursts, but, on the other hand, it must not be made so large that an
event is missed. For example, in Figure 4.4, an event PDO is transmitted at point A
when the analogue signal has exceeded the upper limit. At point B no event PDO is sent
as the signal has remained within the hysteresis limits. This is not true at points D and E
where the signal has hit the lower limit, wandered outside the hysteresis limit and then
hit the lower limit value again. Here, an event PDO is sent at both point D and point E.

4.3 IMPLEMENTATION OF MULTIPLE DEVICE MODULES

The latest version of the CANopen Communication Profile, DS301 Version 4.0,
clarifies an issue formerly left out in the CANopen specification. This issue concerns
the implementation of CANopen modules that include the functionality of
more than one CANopen Device Profile. This type of CANopen implementation is
called a Multiple Device Module. An example of the need to accommodate Multiple
Device Modules is a multiple axis controller where several implementations of the same
standardised device defined in the Device Profile DS402 for Drives and Motion Control
must be included in the same CANopen module.
 130

The problem that device developers faced when they wished to implement the
functionality of several Device Profiles in the same CANopen module was that the
requirements for compatibility with each Profile were conflicting. These conflicts
concerned the use of the same Object Dictionary entries by each type of standardised
device for different purposes.
The approach adopted in the CANopen Communication Profile to resolve the
conflicts associated with Multiple Device Modules consists in a segmentation of the
Object Dictionary areas where such conflicts exist, so as to accommodate the
functionalities of up to eight different standardised devices.
The areas of the Object Dictionary that are affected by these modifications are
shown in Table 4.5.

Table 4.5 Object Dictionary organisation in Multiple Device Modules

Single Device Modules Multiple Device Modules
Index Object Index Object
0000 Not used 0000 Not used
0001-00 IF Static Data Types 0001-00 IF Static Data Types
0020-003F Complex Data Types 0020-003F Complex Data Types
0040-005F Manufacturer Specific Data Types 0040-005F Manufacturer Specific Data Types
0060-007F Device Profile Static Data Types 0060-007F Device Profile #0 Static Data Types
0080-009F Device Profile Complex Data Types 0080-009F Device Profile #0 Complex Data Types
00A0-00BF Device Profile #1 Static Data Types
00C0-00DF Device Profile #1 Complex Data Types
… …
00A0-0FFF Reserved
0220-023F Device Profile #7 Static Data Types
0240-025F Device Profile #7 Complex Data Types
0260-OFFF Reserved
1000-1FFF Communication Profile Area 1000-1FFF Communication Profile Area
2000-5FFF Manufacturer Specific Profile Area 2000-5FFF Manufacturer Specific Profile Area
6000-67FF Standardised Profile Area #0
6800-6FFF Standardised Profile Area #1
6000-9FFF Standardised Profile Area
… …
9800-9FFF Standardised Profile Area #7
A000-FFFF Reserved A000-FFFF Reserved

As can be seen in Table 4.5 the most significant change in the Object Dictionary of
a Multiple Device Module is that the Standardised Profile Object Dictionary section is
divided into eight segments numbered from 0 to 7. The Object Dictionary entries
defined in each Device Profile that is supported by the implementation are stored in one
of these segments, starting on Segment 0. Additionally, at the last Index in each
segment, a Device Type entry similar to the one defined in DS301 for Index 1000H
indicates to which Device Profile corresponds the information stored in that segment.
Complementarily, the entry at Index 1000H is modified to indicate FFFFH in its two
most significant bytes in the case of Multiple Device Module implementations (the two
least significant bytes in this entry indicate the Device Profile code that corresponds to
the device functionality stored in Segment 0 of the Standardised Profile Object
Dictionary area).
Similarly to what happens in the Standardised Profile area of the Object Dictionary,
the Object Dictionary area reserved for Device Profile Data Types was enhanced to
accommodate up to eight different device functionalities. Table 4.5 shows how eight
Object Dictionary Index segments are provided for this purpose in Multiple Device
Modules. The Data Type entries in each of these segments must match the standardised
 131

device functionality stored in the corresponding segment in the Standardised Profile

Object Dictionary area.
• Finally, since each CANopen Device Profile defines default PDO configurations,
the CANopen Communication Profile also resolves the conflicts in storing the PDO
Communication Parameters of these default PDOs in the Object Dictionary of
Multiple Device Modules. These conflicts are solved as follows:
• Each standardised device can have up to 64 receive PDOs and 64 transmit PDOs.
Therefore, the Object Dictionary areas reserved for PDO Communication
Parameters and PDO Mapping Parameters will be divided in segments of 64 entries
each.
• The Communication Parameters corresponding to the PDOs of the first standardised
device implemented in a module should be placed in the Object Dictionary
segments starting at Indexes 1400H and 1800H for receive and transmit PDOs
respectively. The PDOs for which the module has default CAN identifiers will all be
located in these areas.
• Accordingly, the PDO Mapping Parameters corresponding to the PDOs of the first
standardised device implemented in a module should be placed in the Object
Dictionary segments starting at Indexes 1600H and 1A00H for receive and transmit
PDOs respectively.
The PDO Communication Parameters for the default PDOs defined by each
additional Device Profile supported by the implementation should be placed in
successive segments. For example, the PDO Communication Parameter entry for the
first receive PDO of the second standardised device functionality implemented in a
module should be stored at index 1420H at the position of the 65th receive PDO.
Similarly, the PDO Mapping Parameter entry for the same PDO should reside at
index 1620H.

4.4 OTHER SOFTWARE AND HARDWARE CONSIDERATIONS

Other aspects of the hardware in a CANopen implementation have some effect on
the performance of a CANopen node. These include access to I/O facilities integrated
onto the node and also the nature of the interface facilities between the CAN controller
and the processor.
CANopen also provides facilities for more powerful functions such as the
implementation of dynamic mappings on devices. Obviously such facilities require
larger protocol processing overheads. Careful consideration of what facilities should be
implemented within a CANopen device, given the processing power available, is
required, as any oversight in this area can lead to the loss of messages.

4.4.1 The Processor/CAN Controller Interface

In systems where the CAN controller is independent from the main processor, the
interface between the two is important in terms of the speed at which it operates. Most
standalone controllers are interfaced in the usual way via the address and data bus of the
controller. However, a device such as the Intel 82527 can operate at a different clock
speed from the main processor. To overcome problems reading and writing to such a
controller over the address and data bus it is often necessary to insert a few delay
instructions (normally a series of NOP instructions) before reading data or writing new
information to the controller. Care must also be taken not to disturb this delay with a
 132

new incoming CAN interrupt and therefore the CAN interrupt line must be disabled
during this period. This in itself creates extra overheads in dealing with incoming and
outgoing CAN messages.

4.4.2 Hardware Access to I/O Devices

In some devices the hardware I/O access is not memory mapped but interfaced via
different means such as the microcontroller's on-board serial UART. The usage of such
schemes means that the act of reading or writing to the interface can take time. During
this time, new data may have been received by the CAN interface and there is a
requirement to make sure that the I/O data is processed quickly enough by the
microcontroller application program. Failure to do this will probably result in loss of
process information and incorrect process operation. At the very least, the
microcontroller software should be able to detect when this situation has occurred and
notify the master application accordingly.

4.4.3 Software Overheads

In a simple CAN device such as an I/O module in which the contents of the PDOs
are fixed, the microcontroller is dedicated to the processing of incoming and outgoing
CAN telegrams and to the reading and writing of I/O data. In this case, the software is
very simple, comprising only a few very small loops and interrupt routines, and the
processor should have no problem in processing all the information in the time
available.
A lot of extra processing overhead is incurred when using a dynamic PDO mapping
scheme, whereby the variables mapped into the PDO are referenced in a mapping
structure elsewhere in the memory. In such a case, the I/O application now has to spend
a lot of time accessing the device's Object Dictionary. This also applies to multiplexed
PDO variables where the Index and Sub-index of the data contained within the PDO
telegram are transmitted as part of the PDO telegram contents, and are used as yet
another form of dynamic mapping mechanism.
To give an example of this, an I/O application with a Basic CAN controller was sent
messages on a 20ms synchronous basis with approximately 5% bus loading at 1 Mbit/s
(contribution to the traffic was from other devices on the network). With no dynamic
mapping scheme the processor could quite happily cope with the incoming PDO traffic
that it was sent. Using the same hardware and software but with a dynamic PDO
mapping scheme, on average 3 out of 4 PDO
telegrams were ignored as the processor could no longer service them in time before
another PDO telegram arrived. This situation could obviously be improved using a Full
CAN controller, relieving the processor from having to perform software filtering of
telegrams that are not relevant to the device. Still, the point remains that the processing
overhead brought by the implementation of a particular communication mechanism
needs to be weighed against the processing power available and the advantages of
supporting this mechanism.

4.4.4 Implementation Remarks

CANopen provides a flexible and powerful open industrial communication solution
with many attractive features. However, the number of different communication
services required to implement some of these features merits careful consideration of
 133

the CAN hardware requirements. In this section the main conclusions of the discussions
in the previous sections regarding CANopen implementations will be summarised.
In general, microcontrollers incorporating Basic CAN controllers (such as the
Motorola 68HC11X and the Philips 80C592) are cheaper than their Full CAN
counterparts (such as the Siemens C167 or the Intel 80C196CA) as they are less
complex at the silicon level. However, for implementation purposes, much less filtering
and message transmission overheads are incurred using a Full CAN device and the
development of a CANopen implementation is somewhat easier, requiring less code and
memory space. However, this should not rule out Basic CAN in CANopen applications
from the very simple to the more complex. It is the experience of the authors that a node
offering quite complex CANopen features can be implemented in approximately 10
Kbytes of ROM and 500 bytes of memory using a Basic CAN device.
It must be remembered that when implementing CANopen software, the decisions
made as to what CANopen features are implemented are dependent on the processing
power of the hardware. Of primary importance at the CAN level is that the software is
able to detect when the hardware has become overrun (i.e. an incoming message has
overwritten a previously received message whose contents were lost in the process). In
general the following factors will have the greatest impact on the successful functioning
of a CANopen device:
• The CAN hardware - a Full CAN controller will interrupt the main device processor
less than a Basic CAN controller (which then has to software filter the message
identifiers). Code and memory space generally will be smaller using a Full CAN
controller. Software filtering of CAN messages requires more complex software and
hardware using a Basic CAN Controller.
• The rate at which PDOs are transmitted between devices in the network - high speed
of transmission may cause overrun in the CAN controller (message loss) or the
inability to respond to PDO information due to overheads on accessing hardware.
The use of confirmed services (SDOs or ad-hoc solutions using PDOs) can alleviate
these problems as a device only sends a new request to write or read data based on
receiving a confirmation acknowledging the previous request.
• Dynamic mapping of PDO data or use of multiplexed PDOs - dynamic mapping
consumes a large amount of processing power. Generally a multiple static mapping
scheme, whereby several PDOs can be enabled or disabled but have predefined or
fixed mappings, requires less processing overheads than a truly dynamic scheme.
• Hardware access schemes - a node that transmits and receives I/O data must be able
to convert this data to and from PDO telegrams. The time taken to access or set this
data can play a large part in how well the device performs and determine its
response times to changes regarding both its inputs and its outputs. Generally, if the
outputs and inputs are memory mapped on a slave device, then access to I/O
functionality will require less processor instruction cycles, compared to the situation
where I/O requires access over some other hardware mechanism. For example,
many expandable I/O module systems have their own internal serial bus system,
which can be slow.
• The baudrate and CAN message lengths - lower baudrates and longer message
lengths increase inter-frame spacing and therefore a device has more time to process
an incoming message when compared with higher baudrates and/or shorter message
lengths.
 134

4.5 CONSTRUCTING A CANopen NETWORK

When putting a CANopen network together, there is a series of preliminary steps
that have to be taken, and that require particular care. Some of the most important steps
when planning CANopen implementations are:
• Establish as much as possible, and a priori, what is required of the distributed
application that is to be implemented. This analysis will include the types of sensors,
actuators and intelligent devices that require interfacing, the type and amount of data
that needs transferring, as well as the timing restrictions that apply to this data, etc.
• Once the objective is well defined, it is possible to think about how to implement
the system, e.g. how to distribute the application, what types of devices to use
considering that the solution should provide a satisfactory compromise between
performance and cost, etc.
• If the structure of the application is well defined it is then possible to evaluate what
are the requirements of the CANopen network e.g. speed of response, network
traffic, number of nodes, etc. Also, for each node, it is possible to establish what
CANopen mechanisms will be required e.g. number and type of PDOs, number of
SDOs, NMT capabilities, etc.
• Using all the information gathered in the previous steps, the systems integrator may
try to select the devices he/she will be using in the application from the range of
products available on the market. This is not always a simple task since both the
functionality of each device and its communication capability are of prime
importance. Other important factors when choosing the devices to be used in a
network are the cost, the availability, the technical support, etc. Other aspects like
conformance testing and interoperability testing are also growing in importance.

When the preliminary design stage is completed and the practical implementation is
started, the following aspects should be given special attention:
• When installing the cabling, and if some of the devices are to be powered via the
bus, it is important to ensure that the power supplies used for this purpose can
provide sufficient power, and that the voltage drops across the network do not
influence the device's functionality. Additionally, and if the network will be
operating in noisy environments, appropriate shielding must be used to protect the
network from interference.
• If the EMI generated by the CAN bus is damaging to a particular application,
appropriate filtering may be required. Some CAN transceivers, like the Philips
82C250, permit controlling the slope of the transitions of the CAN bus, which is the
source of the EMI, to a certain extent.
• Every node in the network must be set to work at the same baudrate (this is usually
done by setting hardware switches). Furthermore, it is important to ensure that the
length of the network is within the recommended values for a particular baudrate
and that the bus line is properly terminated.
• Every node in the network must have a unique Node ID so that no conflicts arise
when the devices are being addressed. The selection of the Node ID parameter is
also usually done by setting hardware switches.
• When performing the system boot-up it is important to keep track of the default
message identifiers that are allocated to the devices. It is vital that no identifier is
 135

allocated for transmission by two different devices, which would result in a conflict
during the operation of the network.
• Before commissioning the network to normal operation, all the CANopen
mechanisms that will be used must be fully configured in a consistent way using
SDOs. For example, if the Synchronisation Object is being used, special care must
be taken when selecting the value of the Communication Cycle Period: its value
must satisfy the timing requirements for the application and all devices in the
network must be capable of handling it. Furthermore, it is vital to ensure that all
nodes are capable of transmitting their PDOs within one Communication Cycle
Period. Note that this configuration stage will also include the allocation of message
identifiers during network boot-up.
• When establishing PDO connections between two devices, it is essential that the
mappings used for the PDOs are compatible. Otherwise the transfer of information
will be meaningless.

4.6 INFORMATION FOR CANopen DEVICE DEVELOPERS AND

MANUFACTURERS
Some additional aspects of the practical implementation of a CANopen device will
be discussed in this section. The points covered here may be useful for device
manufacturers who are involved in the development of new CANopen devices.
Some issues that should be taken into account when developing a CANopen device
are:
• A CANopen device should have two CAN bus connectors so that, if required, CAN
bus continuity can be ensured without using T-connectors. Furthermore, and if
possible, a CANopen device should have a CANopen compatible bus terminator
resistor that can be optionally shunted across the bus. Both these features are very
helpful to the end user in a practical implementation.
• The process of setting the Node ID and the baudrate parameters on the device
should be as easy and unambiguous as possible, so that the operation of plugging a
device into the network is simple and the risk of a configuration error is minimised.
• If opto-isolators are used to provide galvanic isolation from the CAN bus, it is very
important to evaluate the influence of this feature on the driving capability of the
device. It is estimated that each 10ns of additional propagation delay introduced by
an opto-isolator placed between the controller and the transceiver reduces the
maximum bus length by 4m.
• In some applications, the occurrence of message bursts (message serialisation) may
be expected. This is the case, for example, when the number of Synchronous PDOs
is considerable. Here, a large number of consecutive transmissions may be expected
on the bus after the transmission of the Synchronisation Object. The problem of how
a device should handle such bursts is an important issue, especially in the case of
Basic CAN controllers where message filtering is handled by the software. The
developer must try to optimise as much as possible the performance of the
acceptance filtering in the device so as to minimise the possibility of message loss.
Additionally, it should be ensured that any loss of messages is detected and
signalled, e.g. using an Emergency Object.
• A very important aspect for the success in the commercialisation of a device is the
documentation that is supplied with it. The end user depends very much on the
 136

quality of the information available on the devices he/she is using to implement a

distributed application. Particularly important is the existence of an Electronic Data
Sheet that follows the standardised format, and that allows the systems integrator to
use automatic configuration tools when setting up the network.
• Adding non-volatile memory to a device, where the device can store its
configuration can be a very useful feature. This type of device need only be
configured once, and this can be done off-line. After the correct configuration is
stored, the device can be brought into normal operation in a minimum of time, as
long as no change has to be performed on the stored configuration.

4.7 AN EXAMPLE OF CANopen-B ASED SYSTEM INTEGRATION

CANopen provides the systems integrator with a very powerful and flexible set of
tools that can be used to implement data exchange between devices. With these tools, a
distributed control application can be built, in which multiple nodes cooperate by
sharing process information via a single CAN bus.
When CANopen was not on the market, the way in which each device would use
CAL services to fulfil its communication needs was not well specified. This
task was left to the systems integrator who, for each application, had to come up
with a different control and information flow concept. In this sense, CANopen can be
looked at as a standard method for system integration using a subset of the CAN
Application Layer services. This standardisation makes the tasks of systems integrators
easier, though for many it is still difficult to implement CANopen by simply referring to
the CANopen specification. In the following, an example is presented in order to clarify
the usual way of designing a distributed application using the CANopen protocol.

4.7.1 Constructing a CANopen Network (An Example)

For this example an application with very simple requirements has been chosen.
Although simple, this example is a good way of demonstrating the process of putting
together a distributed control application based on CANopen.
The hypothetical system we will be looking at consists of a temperature
measurement application. Let us say, a manufacturer of a hypothetical product wishes to
implement a system that measures temperature in different spots of a manufacturing
cell. This system has the following requirements:
• There are eight locations where temperature measurements have to be taken. The
time constant related to the variation of these temperatures has a value in the order
of 10 minutes.
• The values of these temperatures have to be displayed in real-time on the monitor of
a PC located in a protected area about ten metres away from the cell.
• In a particular spot in the cell itself there is an analogue display showing the value
of the temperature at one of the spots in the cell, also in real-time. The location
whose temperature is shown in this display is selected by turning on one of eight
switches. The functionality of this display must be maintained.

Forgetting for a minute the very low probability that an application with these
requirements will ever be needed in a manufacturing process, let us follow the design
procedure established in Section 4.5 and devise a way of implementing it using
CANopen.
 137

4.7.1.1 Step One - Collecting Information

The first step in the design procedure is to collect as much detailed information
about the application as possible. Important bits of information in this particular case
would be, for example, the following:
• What are the actual locations where the measurements have to be taken and where
the data has to be displayed? This information is very important because this will
determine not only the placement of the CANopen devices that will be used, but
also the length of the CAN bus interconnecting them. The total length of the CAN
bus determines the maximum baudrate that can be used in the network.
• What types of sensors are used to measure temperature and what is the nature and
range of the signals that they produce at their outputs?
• What type of analogue display is being used?
• Is there a PC available to be used in the application? Is this PC equipped with a
PC/CAN interface?
• What is the budget for the implementation of this system?

Let us say there is a temperature measurement system previously installed on the

cell (using the analogue display and the eight switches), as shown in Figure 4.5.

Figure 4.5 Old temperature measurement system

As can be seen from Figure 4.5, the analogue signals from the temperature sensors
are multiplexed onto a single line that is then connected to the analogue display (a
common voltmeter). The reason for this is that the sensors are all located close to each
other, but about ten metres away from the analogue display. The variation of the signals
from the temperature sensors (after conditioning) is in the range of 0V to 10V and the
 138

analogue display's scale is adapted to show appropriate temperature values. The block
of eight switches implements a mechanical process of mutual exclusion whereby only
one of the switches can be on at a time. This block presents at its output eight digital
lines, one for each switch, where 0V indicates an open switch and 24V indicates a
closed switch. The eight digital lines are then coded into a 3-bit binary number,
indicating the selected sensor, and this number is used as the selection code for the
analogue multiplexor. A special circuit shown as the 'binary coding block' in Figure 4.5
performs the conversion to binary. The binary coding block and the analogue
multiplexor are connected through a 3-bit parallel bus.
Finally, let us say that there is no PC available in the original application and one
has to be bought that is equipped with a PC/CAN interface card and that suits the needs
of the system to be implemented.
In short, the task of the systems integrator is to use CANopen to upgrade the
existing system to incorporate a remote PC, monitoring the temperatures of all eight
sensors, whilst maintaining the functionality of the previous system.

4.7.1.2 Step Two - Distributing the Application

A possible (although by no means ideal) way of implementing a distributed
application to perform the tasks described in the previous section is shown in Figure
4.6. This solution uses four CANopen devices in addition to a PC. These devices are:
• A digital input module with at least 8 digital input lines.
• A digital output module with at least 3 digital output lines.
• An analogue input module with at least 1 channel.
• An analogue output module with at least 1 channel.

In Figure 4.6 it can be seen that we chose to use the PC displaying the temperature
values as the network master. By doing this we avoid having an additional device
connected to the network performing only Network Management services and other
CANopen-related tasks. There are systems on the market that are able to perform these
tasks; however, they represent a significant additional cost. On the other hand this will
force us to include these tasks in the PC application we will have to develop.

In very general terms the operation of the system can be described as follows:
• The PC will sequentially select a different line in the analogue multiplexor using the
remote digital output module.
• For each of these lines the PC will read the value of the temperature from the remote
analogue input module and display it on-screen.
• At the same time, the PC will keep track of the status of the 8-switch block using the
remote digital input module.
• Using this information, the PC is able to identify which of the temperature sensors is
selected to be displayed on the voltmeter and, when this line is read from the
analogue multiplexor, the value collected can also be sent to an analogue output
module connected to the analogue display.
 139

Figure 4.6 The distributed application

In order for it to be possible to select the right CANopen devices to implement this
application, we need first of all to specify in more detail how the network will operate.
Only then can we assess which capabilities are required from each device and choose
from the devices available on the market (from the devices that satisfy the technical
requirements, those that offer more in terms of cost, quality, confidence, etc.).
The first parameter usually to be defined when designing a CANopen network is the
baudrate at which the network will operate. In this case, we estimate the necessary bus
length to be 25 metres. In Chapter 2 it was mentioned that the higher the bus length, the
lower the recommended bus rate for the operation of a network. In fact, 25 metres is the
maximum bus length at which it is recommended to use a baudrate of IMbit/s.
Additionally, by looking at the time constant related to the temperatures that are being
monitored, we can have an idea of how fast the temperature data should be updated.
Since the referred time constant is approximately 10 minutes, it is safe to say that if we
set a frequency of data collection of 1 second, it would be more than enough to provide
a satisfactory resolution. Considering that at 500Kbit/s the biggest CAN message that
can be transmitted takes less than a quarter of a millisecond, it is obvious that at this
baudrate the requirements of this application can be easily met (in fact, even at lOKbit/s
they would be easily met). Let us arbitrarily set the baudrate for this application at
500Kbit/s, since virtually all CANopen devices available on the market support this
value.
 140

Having established that the data from the temperature sensors should be updated at
least once a second, one way of guaranteeing this is to implement a data transfer scheme
based on synchronous exchange of data. Given the fact that eight pieces of data have to
be collected from the analogue input module every second, it would be logical to set the
Communication Cycle Period at 125 milliseconds. Figure 4.7 shows how such a
transmission scheme would operate in a situation where, for example, sensor number 2
has been selected to be displayed in the analogue display.
In Figure 4.7 it can be seen that the Synchronisation Object will be transmitted by
the PC every 125 milliseconds, setting the Communication Cycle Period at the
previously defined value. Both the analogue input module and the digital input module
will be configured to transmit a Synchronous PDO on reception of every
Synchronisation message. These PDOs will carry the values of the temperature
readings in the case of the analogue input and the status of the switch block in the case
of the digital input module. The value of each temperature reading will be collected by
the PC and shown on-screen. Simultaneously, the status of the switch block will be
checked and, when the temperature reading coincides with the sensor selected in the
switch block, a message will be sent to the analogue output module connected to the
voltmeter, updating the value being displayed on it. On every Communication Cycle a
different sensor will be selected by the PC, sending a PDO to the digital output module
with a new selection code for the multiplexor. Using this scheme, all temperature
sensors will be read in eight successive Communication Cycles i.e. in one second, as
required.

Figure 4.7 Synchronous data exchange scheme

It remains to be said that although it is important that the PDOs carrying data to the
PC are configured as synchronous PDOs (with a transmission Type parameter with a
value of 1, indicating PDO transmission on every Communication Cycle), it is vital that
the PDOs carrying data transmitted by the PC are configured as asynchronous event
PDOs. This is to guarantee that the data are instantly updated on the outputs of the
digital and analogue output modules when a PDO is received. This is particularly
important in the case of the digital output module so that the multiplexor has enough
time to stabilise its output when switching from one sensor to the other.
 141

4.7.1.3 Steps Three and Four - Selecting Appropriate CANopen Devices

Now that all aspects of the operation of our network have been addressed, we are in
a position to set the required characteristics for each of the CANopen devices that will
be needed. These are the following:
• Digital input module - for a digital input module to be suitable for this application it
will have to support communication at 500Kbit/s and at least one transmit PDO,
carrying the values of at least 8 digital input lines. Ideally, and to avoid signal
conditioning the digital signals from the switch-block, the digital input module
selected should be compatible with the voltage levels available. This device must
also support synchronous communication.
• Digital output module - for a digital output module to be suitable for this application
it will have to support communication at 500Kbit/s and at least one
• receive PDO, where the values of at least 3 digital output lines are mapped. If the
voltage levels of the output signals of the digital output module are not compatible
with the multiplexor circuit, a small interface will have to be developed.
• Analogue input module - for an analogue input module to be suitable for this
application it will have to support communication at 500Kbit/s and at least one
transmit PDO, carrying the value of at least one input channel. Ideally, and to avoid
signal conditioning the digital signals from the multiplexor circuit, the analogue
input module selected should be compatible with the voltage levels available. This
device must also support synchronous communication.
• Analogue output module - for an analogue output module to be suitable for this
application it will have to support communication at 500Kbit/s and at least one
receive PDO, where the value of at least one analogue output channel is mapped.
Ideally, and to avoid signal conditioning the signal fed to the voltmeter, the
analogue output module selected should be compatible with voltage levels of 0 to
10V. Additionally, it would be very useful if the format used by the analogue output
module to encode the analogue value is the same as the one used by the analogue
input module, as this will avoid the need for additional code for value conversion.

None of the devices is required to implement dynamic PDO mapping. Furthermore,

and for the sake of simplicity NMT Error Control services will not be used in this
system. However, it is usually advisable to use Node Guarding or the Heartbeat service
and it is clear that in this application there is enough bus bandwidth available to
accommodate much more than the four Node Guarding or Heartbeat message exchanges
that would be required in each Communication Cycle.
Based on these requirements it would be possible to choose from the CANopen
devices available on the market those that best suit our needs.
The last task that a systems integrator would have to carry out in order to implement
this system would be to purchase a PC carrying a PC/CAN interface card and to write
the software for the Application/Network Manager. The tasks to be performed by this
software are the following:
• Boot-up each device in the network - the boot-up procedure in this network can be
very simple, providing that the CANopen devices selected comply with the default
status specified in the protocol for I/O modules. It is safe to say that the default PDO
mapping configurations of CANopen I/O modules are compatible with the
requirements of this application. Furthermore, since the devices in the network will
only exchange messages with the network manager, it is possible to design the
 142

application in such a way that the default identifiers in the devices are used. If this is
the case, the only configuration that will be required on boot-up consists of setting
the appropriate transmission modes for the PDOs.
• Send the first multiplexor code to the digital output module so that on reception of
the first Synchronisation Object, after the devices are put on Operational state, the
analogue multiplexor selects the first temperature sensor and the analogue input
module can perform the required conversion.
• Start transmitting the Synchronisation Object every 125 milliseconds.
• Move all devices to Operational state.
• For every temperature measurement received, update the corresponding value on-
screen.
• For each reading of the status of the switch-block, check whether the current
temperature measurement value should be sent to the analogue display and, if so,
transmit it.
• On every Communication Cycle send a new multiplexor code to the digital output
module.

The implementation of such an application would be fairly easy even for a systems
integrator with minimal knowledge of CANopen (as long as the software development
know-how was there, of course).
In the next section, examples of the bus-traffic produced by this system both on
boot-up and normal operation are presented.

4.7.2 Usage of CANopen Communication Objects (An Example)

This section contains a summary of how CANopen Communication Objects are
used in the system designed in the previous section.
Given the simplicity of the system, and the fact that a central processor will control
its entire operation, it is natural that the default message identifier allocation scheme
defined in CANopen satisfies the requirements of this application. As discussed in
Chapter 3, Section 3.8.4, the CANopen Pre-defined Connection Set of identifiers is
derived from the Node ID configuration of each module in the network. Table 4.6
shows how the CANopen devices used in this application can be configured regarding
the Node ID parameter.

Table 4.6 Node ID configuration

Device Node ID
Analogue Output Module 1
Analogue Input Module 2
Digital Output Module 3
Digital Input Module 4

The Node ID configuration is performed by the system integrator using the facilities
included in each device for this purpose (e.g. dip-switches), prior to connecting the
devices to the network. This allows the modules to communicate, without conflicts,
using the default communication identifier scheme, as soon as they are powered up.
 143

4.7.2.1 NMT Communication Objects

The only NMT services used in the application in question are the NMT Module
Control services. Using these services, the network manager, operating as
NMT Master, is able to regulate the operation of the network by issuing commands
to the other devices, operating as NMT Slaves.
The NMT Module Control services can be addressed to individual devices, using the
Node ID parameter. However, it is common that in simple applications, such as this
one, all devices are addressed simultaneously using broadcasted commands that carry
the Node ID 0.
All the NMT Module Control services use the null CAN message identifier in their
protocols. Consequently, all CANopen devices are prepared to receive messages
carrying the null CAN identifier and interpret these messages as NMT Module Control
commands.
In the hypothetical application that is being discussed the NMT Module Control
services are used primarily to control the system boot-up. Additionally, they can be used
to halt the operation of the system in a co-ordinated manner, or even to recover from
error situations.
When the CANopen devices lying on the network are powered up, they enter the
Pre-operational state. In this state they can be configured using SDOs as will be
discussed in the next section. When the configuration is terminated, all the devices can
be put into Operational state using the Start Remote Node service.
In situations when it is necessary to stop the operation of the system using a co-
ordinated and safe method, the Enter Pre-operational State command can be sent to all
devices, causing them to enter Pre-operational state. This renders communication using
PDOs inactive and therefore halts the operation of the network. In this type of situation,
the operation of the network can be resumed using the Start Remote Node service.
Finally, if an error detection mechanism is implemented on the network manager,
e.g. by monitoring the reception of PDOs, an error recovery mechanism can be
implemented depending on the Reset Node service. By issuing a Reset Node to all
devices, the network manager is capable of resetting the whole system and then
performing an error diagnosis procedure before booting-up the network all over again.

4.7.2.2 Service Data Objects

The CANopen default identifier allocation scheme provides each device in a
CANopen network with the means it needs to communicate using Service Data Objects.
In fact, every CANopen device must implement a default Server SDO through which it
can be configured and for which it is allocated two default identifiers: one to receive
requests and one to transmit responses.
The allocation of CAN message identifiers for SDO communication in the case of
the example that is being analysed is summarised in Table 4.7.

Table 4.7 Message identifier allocation for SDO communication

Node ID 1 2 3 4
Device Analogue Output Analogue Input Digital Output Digital Input
Receive SDO ID 601H 602H 603H 604H
Transmit SDO ID 581H 582H 583H 584H
 144

The network manager can use these message identifiers to communicate with each
device individually, in order to configure them, before starting the normal operation of
the network.
As will be seen in the next section, device configuration using SDOs is necessary in
this application to set the communication parameters of the PDOs used in each device to
values that meet the requirements of the system.

4.7.2.3 Process Data Objects

The operation of the system designed in Section 4.7.1 is based on the
Synchronisation Object. CANopen reserves message identifier 80H for this object and,
by default, all devices that consume the Synchronisation Object are configured to
receive messages with this identifier. The network manager of the distributed
application must place the Synchronisation Object on the bus at the required rate.
The PDOs that are used by each device on the network must have communication
parameters that are compatible with the task that each device performs in the distributed
application. In fact, the bulk of the network boot-up procedure in this system consists of
the configuration of these parameters, when their default values do not meet the
requirements of the application.
The PDO mappings are also vital for the correct operation of the devices.
Fortunately, all CANopen devices provide default mappings for their PDOs. These
default mappings are defined in the CANopen Device Profiles and they are designed to
satisfy the requirements of most applications that use CANopen devices of a particular
type.
In the case of the I/O modules used in the application at hand, the default PDO
mappings can be used without alteration. In fact, the CANopen Device Profile for I/O
Modules states that devices of this type should implement default PDOs carrying the
values of the digital/analogue input/output signals to which they are connected.
Table 4.8 shows the Process Data Objects used in this example, their
communication and their mapping parameters.

Table 4.8 Message identifier allocation for SDO communication

Node ID 1 2 3 4
Device Analogue output Analogue input Digital output Digital input
PDO ID 301H 282H 203H 184H
Direction Receive Transmit Receive Transmit
Transmission
255 1* 255 1*
Type
Mapped Analogue output Analogue input Digital output Digital input
Parameters signals (16 bits) signals (16 bits) signals (8 bits) signals (8 bits)
Index 6411H Index 6401H Index 6200H Index 6000H
Mapped Objects Sub-indexes Sub-indexes Sub-indexes Sub-indexes
1 to 4 1 to 4 1 to 8 1 to 8

The parameters that are not supported by I/O Modules in their default configuration
are signalled in Table 4.8. These parameters require configuration using SDOs.

4.7.3 Message Exchange in CANopen Networks (An Example)

In the communication logs that will be presented in this section, each CAN message
that is recorded occupies only one line and is stored in the following format:
 145

t.tttt iii dd d0 d1 d2 d3 d4 d5 d6 d7

where t.tttt stands for the time instant when the message was recorded (in
seconds), iii stands for the message identifier, dd holds the message direction relative
to the network manager, and d0/d7 are the data bytes. All numerical values are shown
in hexadecimal format.
A boot-up sequence of the system described in the previous sections would look
something like the set of messages shown in Table 4.9. Note that the Node ID of each
CANopen module, referred in the following discussion, can typically be set using DIP-s
witches.

Table 4.9 Message exchange sequence for the boot-up procedure

12.801 601 Tx 2E 1 14 2 FF 0 0 0
Node 1
12.811 581 Rx 60 1 14 2 0 0 0 0
36.119 602 Tx 22 1 18 1 83 2 0 80
36.132 582 Rx 60 1 18 1 0 0 0 0
Node 2
37.876 602 Tx 22 2 18 1 83 2 0 0
37.888 582 Rx 60 2 18 1 0 0 0 0
49.119 603 Tx 2E 0 14 2 FF 0 0 0
Node 3
49.152 583 Rx 60 0 14 2 0 0 0 0
73.475 604 Tx 2E 0 18 2 1 0 0 0
Node 4
73.594 584 Rx 60 0 18 2 1 0 0 0
Mux data 99.832 203 Tx 0
SYNC 110.913 80 Tx
Start 111.058 0 Tx 1 0

The configuration of the analogue output module (Node 1) consists simply of an

SDO write operation to Index 0x1401 and Sub-index 0x02. This Object Dictionary
entry holds the transmission type parameter for the second receive PDO of this device
(which is reserved for analogue devices) and the value written to it is OxFF, indicating
an Asynchronous Event PDO. It was mentioned previously that this will force the
analogue output module to update the value of its output channel as soon as the PDO is
received.
The configuration of the analogue input node (Node 2) consists of two SDO write
operations. The first one deactivates the default transmit PDO which resides
at Index 0x1801. This is done by setting the 32nd bit of Sub-index 0x01 to one. The
second SDO transfer activates an additional PDO that resides at Index 0x1802 using the
reverse procedure i.e. setting the 32nd bit of Sub-index 0x01 to zero. The identifier used
for this PDO is the default identifier for the 2nd transmit PDO in a CANopen device
(which is reserved for analogue devices). The reason for this is that this CANopen
device does not allow changing the transmission type parameters of its PDOs; instead it
offers several PDOs with different functionalities for the user to choose from. The PDO
at Index 0x1802 is a synchronous transmit PDO as required in this application.
The configuration of the digital output module (Node 3) consists simply of an SDO
write operation to Index 0x1400 and Sub-index 0x02. This Object Dictionary entry
holds the transmission type parameter for the first receive PDO of this device (which is
reserved for digital devices) and the value written to it is OxFF which indicates an
asynchronous event PDO. It was mentioned previously that this will force the analogue
output module to update the value of its output channel as soon as the PDO is received.
 146

Finally, the configuration of the digital input module (Node 4) consists simply of an
SDO write operation to Index 0x1800 and Sub-index 0x02. This Object Dictionary
entry holds the transmission type parameter for the first transmit PDO of this device
(which is reserved for digital devices) and the value written to it is 0x01 which indicates
a synchronous PDO triggered by the reception of every Synchronisation Object.
After configuring the communication parameters of the devices, the network
manager sends a PDO to the digital output module, setting the initial code for the
analogue multiplexor at zero. This PDO carries only one byte and the three least
significant bits contain the referred code.
Finally, the network manager starts transmitting the Synchronisation Object and
moves all devices to Operational state using a Start Remote Node message addressed to
all devices.
A sequence of messages corresponding to eight Communication Cycles of normal
operation of the same system is shown in Table 4.10.

Table 4.10 Message exchange sequences for normal network operation

SYNC 0.1266 80 Tx
Switches 0.1272 184 Rx 2 0
Temperature 0.1280 282 Rx 39 54 0 0 0 0 0 0
Mux data 0.1606 203 Tx 1
SYNC 0.2516 80 Tx
Switches 0.2520 184 Rx 2 0
Temperature 0.2532 282 Rx 41 5 0 0 0 0 0 0
Display 0.2816 301 Tx 41 5 0 0 0 0 0 0
Mux data 0.2854 203 Tx 2
SYNC 0.3763 80 Tx
Switches 0.3769 184 Rx 2 0
Temperature 0.3780 282 RX 42 68 0 0 0 0 0 0
Mux data 0.4094 203 Tx 3
SYNC 0.5015 80 Tx
Switches 0.5021 184 Rx 2 0
Temperature 0.5033 282 Rx 41 65 0 0 0 0 0 0
Mux data 0.5356 203 Tx 4
SYNC 0.6266 80 Tx
Switches 0.6272 184 Rx 2 0
Temperature 0.6282 282 Rx 36 86 0 0 0 0 0 0
Mux data 0.6604 203 Tx 5
SYNC 0.7514 80 Tx
Switches 0.7521 184 Rx 2 0
Temperature 0.7530 282 Rx 39 98 0 0 0 0 0 0
Mux data 0.8385 203 Tx 6
SYNC 0.8766 80 Tx
Switches 0.8772 184 Rx 2 0
Temperature 0.8784 282 Rx 44 4 0 0 0 0 0 0
Mux data 0.9633 203 Tx 7
SYNC 10.015 80 Tx
Switches 10.021 184 Rx 2 0
Temperature 10.032 282 Rx 42 31 0 0 0 0 0 0
Mux data 10.913 203 Tx 0
SYNC 11.292 80 Tx

Each Communication Cycle begins with a Synchronisation Object. The occurrence

of this message triggers the transmission of two PDOs by the digital input and by the
analogue input devices. These PDOs carry the values of the switches and a temperature
 147

measurement, respectively. The PDO transmitted by the digital input module contains
two data bytes because the device used in this example has 16 digital input lines. The
switches are connected to the eight least significant of these lines and are mapped on the
first byte of the PDO (in this case switch 2 is selected). The PDO transmitted by the
analogue input device contains eight bytes of data because the device used for this
example has four analogue input channels and each of them takes two bytes in the PDO.
The output of the multiplexor is connected to the first of these channels. Also in every
Communication Cycle, the network manager sends a new multiplexor code to the digital
output module as explained above. Finally, when the switch selected coincides with the
sensor being read (in this case on the second Communication Cycle) a PDO is sent to
the analogue output module updating the temperature value being displayed. The
analogue output module used in this example uses representations for the analogue
values which are compatible with those used by the analogue input module. This means
that the data received from the analogue input module can be sent unaltered to the
analogue output module.
 148

CHAPTER 5
CANopen Conformance Testing
Chapter Objectives
When you have completed this chapter you should:
• Understand the purpose of Conformance Testing.
• Be aware of the need for Conformance Testing.
• Know the current status of CANopen Conformance Testing.
• Know the structure of the CANopen Conformance Testing procedures.
• Understand the purpose of each test and how each test will be carried out.

5.1 INTRODUCTION
The CANopen protocol has come a long way since its origin in the European project
ASPIC, and it is taking its final steps towards standardisation, under the control of the
CAN in Automation (CiA) organisation.
At this point, a set of profiles has been produced, that constitutes the CANopen
specifications. It is necessary to ensure that CANopen implementations comply with
these specifications, so that the integrity of the standard can be safeguarded. This
process is called Conformance Testing and it is in this area that much of the work being
done recently on the CANopen protocol is centred.
In Chapter 3 it was established that the CANopen Communication Profile (DS301)
is the central part of the CANopen protocol, as it defines the basic communication
mechanisms that all devices must use and implement in order to communicate.
Additionally, it defines the format of the Electronic Data Sheets (EDS) that should be
provided with CANopen devices, containing information about the features
implemented in the devices, mainly for use with automatic configuration tools. The
Conformance Testing procedures already developed for the CANopen protocol cover
only this central part of the specification.
The Conformance Testing procedures for DS301 were developed by a CiA Special
Interest Group (SIG) established for this purpose. The SIG members are those members
of the CiA that have an interest in the outcome of the activities carried out in the field of
CANopen Conformance Testing.
The results of the work done by the CANopen Conformance Testing SIG were
compiled in a document entitled "Test Description for CANopen Devices" which can be
obtained from the CiA. In short, the issues covered in this document are the following:
• Scope - the document provides a framework for testing conformance to DS301. This
document can also be looked at as a guide for the implementation of a CANopen
Conformance Testing Tool and it was indeed used for this purpose, as will be
discussed further on in this section.
• EDS Test - the document specifies a set of tests to be performed on an EDS file that
must be provided by the manufacturer along with the Device Under Test (DUT).
Since the EDS will be the source of information about the device for automatic
configuration tools (not to mention Conformance Testing Tools themselves), the
testing of this file is as critical as the testing of the device itself.
 149

• Device Test - the document specifies a set of tests to be performed on the DUT by a
Conformance Testing tool connected to it through a CANopen network. These tests
refer only to the communication mechanisms defined in DS301.
• CANopen Test Interface - the document states that a CANopen Conformance
Testing Tool must be compatible with different PC/CAN interfaces. This will allow
users to support it with any PC/CAN interface, reducing to a minimum the cost of
the tool. For this to be possible, a standard software interface that will connect the
test tool to the PC/CAN interface is defined. This software will take the form of a
DLL and it will be the only part of the software that depends on the hardware
platform.

The test description produced by CANopen Conformance Testing SIG was used by
the CiA as a basis for the development of a CANopen Conformance Testing Tool. This
tool is now available at the CiA headquarters for official Conformance Testing of
CANopen devices. Manufacturers of CANopen devices can submit their products to the
CiA to obtain Conformance Certification. Additionally, manufacturers can purchase the
official CANopen Conformance Testing Tool from the CiA and use it to detect
implementation errors before submitting their products for official testing.
The authors developed an equivalent set of tools for Conformance Testing of
CANopen devices, as part of a Ph.D. programme at Newcastle University, UK. These
tools perform elaborate testing of the EDS and DUT under Windows 95/98, offering an
intuitive user interface. They can be very useful for pre-conformance testing by the
vendors and manufacturers of CANopen products during the development of their
implementations.
The following sections contain a thorough description of what, according to the
authors' experience, is expected of a conformant CANopen implementation. This
description provides a generic view of these requirements, and it is structured in such a
way that the scope of the tests is emphasised.

5.2 EDS TESTS

The conformance test of a CANopen device is composed of two stages: the test of
the EDS file for the DUT, and the test of the device itself.
The CANopen Conformance Testing procedures currently in use are based on the
EDS file format that has been specified in the CANopen Communication Profile,
Version 3.0. This format is described in Chapter 3, Section 3.9.
The test of the EDS file must be successfully completed before the test of the DUT
is initiated. The reason for this is that the Device tests make use of information that
must be retrieved from the EDS file, and this information cannot be used unless the
conformance of the EDS file is verified previously.
The first step in testing a CANopen device will be therefore to load the EDS file into
the test tool and to test it for conformance to the standard format defined in
DS301. While the EDS file is being loaded into memory, it will be tested for syntax
errors that are considered unacceptable in terms of further analysis of the file. The exact
tests that are performed will depend on the implementation of the test tool in general
and, in particular, on the way in which the storage of the EDS file data in memory is
handled. In other words, these tests are focused on low level characteristics of the EDS
file and, as such, their scope is encompassed by the actual EDS Conformance tests
 150

described in the following sections. The EDS Conformance tests are divided in three
groups:
• Completeness Tests - these tests aim to check whether the structure of the EDS file
is correct. These tests must be passed before any other analysis of the EDS can be
performed.
• Value Ranges Tests - these tests check whether all the entries in the EDS have
values that are within the value range defined in DS301 for the parameters that they
describe.
• Consistency Tests - these tests check all the cross-references within the EDS file. It
is clear that for these tests to be performed it is required that all the previous ones
must have been passed.

5.2.1 Completeness Tests

Completeness tests aim to ensure, on one hand, that the structure of the EDS file is
correct, containing all the mandatory sections specified in DS301, and that these
sections are not repeated. On the other hand, the contents of each section specified in
DS301 will also be analysed to check for unknown keywords, repeated keywords and
for the presence of all mandatory keywords.
The tests are not extended further because in DS301 the manufacturer is given the
freedom to include manufacturer-specific sections in a EDS. The presence of unknown
sections is therefore not an error, and the contents of these sections cannot be tested.

5.2.1.1 Mandatory Sections Test

The Mandatory Sections test consists in going through the EDS file checking for the
presence of the following mandatory sections: FileInfo, DeviceInfo,
StandardDataTypes, MandatoryObjects, OptionalObjects, ManufacturerObjects,
Comments and DummyUsage. The EDS file will also be checked for repeated
occurrences of these section keywords.
There are other EDS sections which are specified in DS301 such as the
<Index>ObjectLinks sections, the <Index> sections and the <Index>sub<Sub-index>
sections. However, the requirements on the existence of these other sections depend on
the DUT and can only be assessed based on the contents of other sections in the EDS.
Therefore, any errors concerning the existence of these sections can only be checked in
the Consistency tests that will be described further on. Nevertheless, the contents of
these sections are tested in the Standard Sections test and in the Value Ranges test.

5.2.1.2 Standard Sections Test

The Standard Sections test aims to verify the contents of the EDS sections that are
specified in DS301. Both mandatory and optional keywords are considered and the
following errors will be signalled:
• Unknown keywords found.
• Repeated occurrence of known keyword.
• Mandatory keyword not found.

The keywords allowed in the FileInfo section are shown in Table 5.1.
 151

Table 5.1 FileInfo section keywords

Mandatory Keywords FileName, FileVersion, FileRevision, Description, CreationTime,
CreationDate, CreatedBy, ModificationTime, ModificationDate,
ModifiedBy
Optional keywords

The keywords allowed in the DeviceInfo section are shown in Table 5.2.

Table 5.2 DeviceInfo section keywords

Mandatory Keywords VendorName, VendorNumber, ProductName, ProductNumber,
ProductVersion, ProductRevision, OrderCode, LMT_ManufacturerName,
LMT_ProductName, SimpleBootMaster, SimpleBootSlave,
ExtendedBootUpMaster, ExtendedBootUpSlave, Granularity
Optional keywords Baudrate_10, Baudmte_20, Baudrate_50, Baudrate_100, Baudrate_125,
Baudrate_250, Baudrate_500, Baudrate_800, Baudrate_l000,
DynamicChannelsSupported

The keywords allowed in the StandardDataTypes section are shown in Table 5.3.

Table 5.3 StandardDataTypes section words

Mandatory Keywords
Optional keywords 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008,
0x0009, 0x000A, 0x000B, 0x000C, 0x000D, 0x000E, 0x000F, 0x0020,
0x0021, 0x0022

The keywords allowed in the DummyUsage section are shown in Table 5.4.

Table 5.4 DummyUsage section words

Mandatory Keywords Dummy000l, Dummy0002, Dummy0003, Dummy0004, Dummy0005,
Dummy0006, Dummy0007
Optional keywords

The keywords allowed in a section of the type <Index> where the SubNumber
keyword does not appear or has a value of 0 are shown in Table 5.5.

Table 5.5 <Index> section keywords when SubNumber=0 or non-existent

Mandatory Keywords ParameterName, ObjectType, DataType, AccessType, PDOMapping
Optional keywords SubNumber, DefaultValue, HighLimit, LowLimit

The DefaultValue, HighLimit and LowLimit keywords are not allowed on sections
where the DataType is larger than 8.
The keywords allowed in a section of the type <Index> where the SubNumber
keyword has a value greater than 0 are shown in Table 5.6. In this case, the object is
represented in the EDS by the section being analysed and by one or more sections of the
type <Index>sub<Sub-index>.

Table 5.6 <Index> section keywords when SubNumber>0

Mandatory Keywords SubNumber, ParameterName
Optional keywords ObjectType, DataType, AccessType, PDOMapping
 152

The keywords allowed in a section of the type <Index>sub<Sub-index> are shown

in Table 5.7.

Table 5.7 <Index>sub<Sub-index> section keywords

Mandatory Keywords ParameterName, ObjectType, DataType, AccessType, PDOMapping
Optional keywords SubNumber, DefaultValue, HighLimit, LowLimit

Again, the DefaultValue, HighLimit and LowLimit keywords are not allowed on
sections where the DataType is larger than 8.
In the sections Mandatory Objects, OptionalObjects, ManufacturerObjects the
keywords that are allowed depend on the value of the entry SupportedObjects, which is
a mandatory entry in all of these sections. The absence of this keyword (or an invalid
value for this keyword) in any of these sections makes it impossible for the remainder of
the contents of the section to be tested. The valid range for the SupportedObjects
keyword is an integer value between 0x0 and 0xFFFF. When a valid value is found, this
value defines the set of other valid keywords for that section. These keywords are
mandatory and they are of the form <value> where value is an integer number in
decimal representation starting on the value 1 and ending on the value specified in the
SupportedObjects keyword. Obviously if the SupportedObjects entry has a value of 0,
the set of valid keywords is composed only of the SupportedObjects keyword.
The set of valid keywords for the MandatoryObjects, OptionalObjects and
ManufacturerObjects sections is summarised in Table 5.8.

Table 5.8 MandatoryObjects, OptionalObjects and ManufacturerObjects section keywords

Mandatory Keywords SupportedObjects, 1, 2, 3, 4, ..., <value of SupportedObjects entry>
Optional keywords

The Comments section works in a similar way to the previous sections: there is a
mandatory keyword, in this case the keyword Lines, with a range of 0x0 to 0xFFFF,
which defines the remaining mandatory keywords of the section. Here, the keywords are
of the format Line<value> and, again, if the Lines entry has a value of 0, no other entry
is allowed in this section.
The set of valid keywords for the Comments sections is summarised in Table 5.9.

Table 5.9 Comments section keywords

Mandatory Keywords Lines, Line1, Line2, Line3, Line4, ..., Line<value of Lines entry>
Optional keywords

The <Index>ObjectLinks sections also work in a similar way to the previous

sections: there is a mandatory keyword, in this case the keyword ObjectLinks, with a
range of 0x0 to 0xFFFF, which defines the remaining mandatory keywords of the
section. Here, the keywords are of the format <value> and, again, if the ObjectLinks
entry has a value of 0, there will be no other entry in this section.
The set of valid keywords for the <Index> ObjectLinks sections is summarised in
Table 5.10.

Table 5.10 <Index>ObjectLinks section keywords

Mandatory Keywords ObjectLinks, 1, 2, 3, ..., <value of ObjectLinks entry>
Optional keywords
 153

5.2.2 Value Ranges Test

The Value Ranges test consists in going through every entry in the EDS and
checking the value of each entry against the legal range defined in the test specification
for that entry.
The data types and the value ranges for which the EDS entries will be tested are
shown in Table 5.11.

Table 5.11 EDS entry data types and ranges

Range Keywords
UNSIGNED8 FileVersion, FileRevision, ProductVersion, ProductRevision, SubNumber
0 to FFH
UNSIGNED 16 SupportedObjects, Lines
0 to FFFFH
UNSIGNED32 VendorNumber, ProductNumber, VendorNumber
0 to FFFFFFFFH
B00LEAN Baudratel000, Baudrate800, Baudrate500, Baudrate250, Baudrate_100,
0 to 1 Baudrate125, Baudrate100, Baudrate50, Baudrate20, Baudrate10,
SimpleBootUpMaster, SimpleBootUpSlave, ExtendedBootUpMaster,
ExtendedBootUpSlave, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005,
0x0006, 0x0007, 0x0008, 0x0009, 0x000a, 0x000b, 0x000c, 0x000d,
0x000e, 0x000f, 0x0020, 0x0021, 0x0022, Dummy0001, Dummy0002,
Dummy0003, Dummy0004, Dummy0005, Dummy0006, Dummy000,
PDOMapping
STRING Description, CreatedBy, VendorName, ProductName, OrderCode,
255 ASCII characters ParameterName, Line<value>
STRING LMT_ManufacturerName, LMT_ProductName
7 ASCII characters
TIME CreationTime, ModificationTime
00:00AM to 11:59AM
12:00PM to 11:59PM
DATE CreationDate, ModificationDate
dd-mm-yyyy
ro, wo, rw, rwr, rww, AccessType
const
INTEGER DataType
1 to9FH
INTEGER ObjectType
0, 2, 5, 6, 7, 8, 9
DOS Restrictions FileName
INTEGER Granularity
0 to 64

The legal range for entries of the type <value> in the sections MandatoryObjects,
OptionalObjects and ManufacturerObjects and <Index>ObjectLinks depends on the
actual section. This is shown in Table 5.12.
 154

Table 5.12 Range of <value> entries

Section Range
INTEGER
MandatoryObjects
1000H to 1001H
INTEGER
OptionalObjects 1002H to lFFFH
6000H to 9FFFH
INTEGER
ManufacturerObjects
2000H to 5FFFH
INTEGER
<Index> ObjectLinks
0001H to FFFFH

The ranges for the HighLimit and LowLimit entries depend on the actual data type
of the object. This is shown in Table 5.13. It is also important to keep in mind that the
value of the HighLimit entry cannot be lower the value of the LowLimit entry.

Table 5.13 Range of standard data types

Data Type Range
INTEGER
B00LEAN
0 to 1
INTEGER
SIGNED8
-128 to 127
INTEGER
SIGNED16
-32768 to 32767
INTEGER
SIGNED32
-2147483648 to 2147483647
INTEGER
UNSIGNED8
0 to FFH
INTEGER
UNSIGNED 16
0H to FFFFH
INTEGER
UNSIGNED32
0 to FFFFFFFFH
FLOAT
FLOAT
-3.402823466E38 to 3.402823466E38

Finally, the range of the DefaultValue entry is set by the HighLimit and LowLimit
entries. When they are not present, the range set by the data type of the object (Table
5.13) applies.

5.2.3 Consistency Tests

The Consistency tests aim to verify the internal references inside the EDS file. In
other words, when the value of an entry refers to another section in the EDS, the
existence of this other section and any relevant parameters in it must be checked.

5.2.3.1 Dummy Usage Test

The Dummy Usage test is very simple: it consists of verifying that every entry in the
DummyUsage section that has a value of 1 corresponds to a data type that is supported
by the DUT. In other words, an entry in the DummyUsage section with a value of 1
implies that the entry in the StandardDataTypes section corresponding to the data type
in question must also have a value of 1.
 155

5.2.3.2 Supported Objects Test

The Supported Objects test aims to check the Object Dictionary part of the EDS file.
From the MandatoryObjects, OptionalObjects and ManufacturerObjects sections, the
test tool will collect information about the structure of the Object Dictionary: the
Indexes of all the objects supported by the DUT.
For each of these Indexes a search will be performed on the EDS looking for an
<Index> type section for the corresponding object. If no such section is found or if it is
found more than once, an error will be signalled.
If an EDS section satisfying these requirements is found, the test tool will then
determine whether the SubNumber entry has a value greater than 0 (in this case, this
object will also be represented by one or more sections of the type <Index>sub<Sub-
index>). When this is the case, a search will be performed throughout the EDS file for
sections of the type <Index>sub<Sub-index> for the Index of that particular object and
with Sub-indexes ranging from 0 to the value of the SubNumber entry minus 1.
An additional test can be performed on the EDS whereby the existence of sections
of the type <Index> or <Index>sub<Sub-index> that were not referenced can be
reported as errors.

5.2.3.3 Object Links Test

The Object Links test is also a very simple test. The test tool will go through the
entries in each <Index>ObjectLinks section and retrieve the Indexes of the objects that
are referenced. Each of these objects must be supported by the DUT and, therefore,
must be represented in the EDS by a section of the type <Index>. The test tool will look
for these sections and signal an error when they are not found or when the same sections
are found more than once.

5.2.3.4 PDO Mappings Test

The purpose of the PDO Mappings test is to verify that the entries mapped onto the
PDOs of the DUT do exist and that they are suitable for that mapping. The mappings of
transmit PDOs are tested separately from the mappings of receive PDOs,
The PDO Mapping parameters for receive PDOs are stored in Indexes ranging from
1600H to 17FFH. Each object in this range will be subject to the following test: •
• For Sub-indexes greater than 0, the DefaultValue entry is mandatory so that the
reference can be checked automatically. The tool will pick up this default value and
extract the referencing information from it.
• If the object referenced is a data type (dummy mapping), the size of the mapping
will be compared to the size of the data type. Any mismatch will be signalled as an
error. Additionally, any data type used as a dummy mapping must be supported and
have a value of one in the corresponding entry in the DummyUsage section.
• If the object referenced is not a data type, a search will be performed for the section
containing information about this object (this section can be either of type <Index>
or of type <Index>sub<Sub-index>) and if this section is not found an error will be
signalled. An error will also be signalled if the section is found more than once.
• When a section containing the referenced information is found, the tool will check if
the PDOMapping entry of that section has a value of 1, indicating that the mapping
is permitted. If this is not the case, an error will be signalled.
 156

• Finally, the AccessType entry of the referenced section will be checked. In the case
of receive PDOs, valid values for the access type are wo and rww.

The PDO Mapping parameters for transmit PDOs are stored in Indexes ranging from
1A00H to 1BFFH. Each object in this range will be subjected to a test which is similar
to the one described for the receive PDOs. The only difference lies in the test that is
performed on the value of the AccessType entry of the referenced sections. In this case,
the valid values are ro and rwr.

5.3 DEVICE TESTS

The Device tests should not be initiated until the EDS for the DUT has been tested
successfully. This is because Device tests make use of this EDS file for obtaining
information about the DUT.
Before starting the Device test procedures, there are certain issues that must be
considered by the user. These issues concern the configuration of the test tool with
DUT-specific information: information that cannot be retrieved from the EDS file. This
configuration is essential if communication is to be established with the DUT and if the
tests that are performed are to be compatible with its features. The DUT-specific
information consists of the following parameters:
• NODE ID - this parameter corresponds to the value of NODE ID at which the DUT
is configured to respond. This parameter is used for NMT addressing and for
computing the default communication identifiers used by the DUT. If it is not
correct, the DUT will not respond as expected and the test will fail.
• Baudrate - this parameter will determine the baudrate at which the PC/CAN
interface will be configured for communication. Unless it is set to the same value as
the DUT's, no communication will be possible and the PC/CAN interface will signal
a transmission error when the test is initiated.
• Time-out values - the time-out values determine how long the tool will wait before
assuming that a particular event has occurred. In the case of message time-outs
(PDO or SDO) this event would be the failure of the DUT to respond. In the case of
the reset time-out, this event would be the end of the initialisation procedure of the
DUT.

In this section the Device tests will be thoroughly described. All Device tests are
performed sequentially but before each test is initiated the node has to be reset. This can
be achieved by using the NMT Module Control services and it is the only way to ensure
that each test is initiated with the DUT at a well-defined state.
Throughout the description of the Device tests, whenever the Start Remote Node,
Stop Remote Node, Enter Pre-operational State, Reset Communications and Reset Node
protocols are referred to be used, without any other information, it means that the DUT
will be individually addressed using the Node ID parameter. Whenever global
addressing is to be used (Node ID = 0) this will be specifically mentioned in the
description of the tests.
The Device tests are divided into the following eight groups:
• Protocol Verification Tests - these tests aim to verify the correct implementation of
the basic CANopen communication mechanisms: PDOs and SDOs.
 157

• Object Dictionary Tests - these tests aim to verify the implementation of the DUT's
Object Dictionary against its EDS and against the CANopen specification.
• Parameter Storage/Restorage Test - these tests aim to complement the Object
Dictionary Tests by verifying features that were left unchecked. In particular, these
tests target the Object Dictionary entries associated with the storage and restorage of
parameters.
• Emergency Tests - these tests aim to verify the implementation of the Emergency
Object and associated Object Dictionary entries.
• Error Control Tests - these tests aim to verify the implementation of the NMT Error
Control mechanisms and associated Object Dictionary entries.
• Synchronisation Tests - these tests aim to verify the implementation of the
Synchronisation Object and associated Object Dictionary entries.
• Verification of Network States - these tests aim to verify the implementation of the
NMT Slave state diagram defined in DS301. In particular, these tests check that the
functionality of the device within each state complies with the standard.
• Verification of State Transitions - these tests aim to verify the implementation of the
NMT Slave state diagram defined in DS301. In particular, these tests check that the
transitions between network states are correctly implemented.

The tests are independent of each other, in such a way that they can be performed in
an arbitrary order. For this to be possible, it was necessary to make the test procedures
redundant in the sense that some of them overlap in their scope.

5.3.1 Protocol Verification Tests

As previously mentioned, the Protocol Verification tests are concerned with the
basic CANopen mechanisms for data transfer: Service Data Objects and Process Data
Objects.

5.3.1.1 Service Data Objects Test

The SDO test will begin with an attempt to read an Object Dictionary entry of
mandatory implementation. The object used for this purpose will be the Device Type
object (Index 1000H and Sub-index 0). If the SDO transfer is aborted this will mean
that an error exists in the DUT's implementation, since the object in question is of
mandatory implementation and its Access Type permits read accesses.
The second step in the SDO test is to attempt a SDO read operation from an object
that should not exist in the DUT's Object Dictionary. The entry used for this purpose
will be the object at Index 1000H and Sub-index 1. The test tool will expect an Abort
SDO Transfer message from the DUT. If the transfer is completed with success this will
mean that an error exists in the implementation of the DUT.
The SDO Communication Parameters of the default SDO that reside at Index 1200H
are then uploaded one by one and compared to their default values that are a part of the
CANopen predefined connection set of message identifiers. These entries must also
have ro access type, so that the device must abort write operations to these entries.
The test will proceed with a SDO read operation from an entry containing
information that takes more than 4 bytes, so that the segmented SDO protocol can be
tested. The test tool will go through the EDS file for the DUT, looking for Object
Dictionary entries that may meet this requirement. When such an entry is found an
attempt will be made to read from it. The search will continue until the segmented
 158

protocol is tested or no more entries remain. Any errors that are found will be signalled
to the user. The same procedure used to test segmented SDO transfers is then used to
verify block SDO transfers.
For the previous SDO read operations, the default communication identifiers,
defined in CANopen, will be used. The message identifier used for the Client-to-Server
message is equal to 1537+(NODE ID-1). The message identifier used for the Server-to-
Client message is equal to 1409+(NODE ID-1). Throughout the testing of the DUT,
whenever SDO transfers are performed, these identifiers will be used.
Apart from the errors described above, the following SDO protocol errors will also
have to be detected and signalled during this test:
• SDO Response Time-out - the DUT failed to issue a response using the Server-to-
Client identifier within the time period defined by the SDO Timeout parameter
specified for the DUT.
• SDO Protocol Error - the DUT did issue a response, however, this response is not
compliant with the CANopen standard. The protocol errors that will be detected by
the test tool are: more than one SDO responses received, wrong Index or Sub-index,
unknown Server Command Specifier and SDO messages with less than 8 bytes. In
the case of segmented or block SDO transfers there are additional protocol errors
that can occur, such as errors concerning the toggle bit and the size of the data.
These will all be indicated as protocol errors.

Throughout the remainder of this test and the execution of all other tests, whenever
a SDO transfer is performed, time-out errors and SDO protocol errors will have to be
continuously monitored for and they will be signalled when they occur.
Finally, the SDO test will terminate with a verification of the implementation of
other Server SDOs supported by the DUT. If the SDO Communication Parameters of
other Server SDOs are found in the Object Dictionary of the DUT (if they exist, these
parameters will reside in the Index range 1201H to 127FH) the test tool will try to
configure these SDOs with suitable CAN message identifiers. In this case, the
identifiers used in each SDO link must be different from the default message identifiers
allocated to the DUT for SDO communication to prevent conflicts with the mandatory
Server SDO. In cases where the Server SDO configuration is successful, an attempt will
be made to read a mandatory Object Dictionary entry using the newly established SDO
link. Any errors that are found will be signalled to the user.

5.3.1.2 PDO Communication Parameter Test

The test will begin with a SDO-based search of the DUT's Object Dictionary,
looking for the PDO Communication Parameters of the receive PDOs implemented in
it. This operation will begin at Index 1400H and go up to Index 15FFH. The parameter
read from each Index will be the COB-ID used by the PDO at Sub-index 1. The test tool
will check that only the first four PDOs can be active by default and that the
communication identifiers of these PDOs agree with their pre-defined default values.
The same procedure will then be repeated for transmit PDOs, scanning the Index
range from 1800H to 19FFH.
The final step of the PDO test will be to request the transmission of a PDO by the
DUT. For this to be possible, an active transmit PDO must be detected in the Object
Dictionary of the DUT. This will be done by reading the PDO Communication
Parameters of the transmit PDOs supported by the DUT until a PDO meeting these
 159

requirements is found. In CANopen it is specified that the only transmit PDOs that may
be active by default will be located at indexes ranging from 0x1800 to 0x1803. When
this is proved, the DUT will be put to Operational state by means of a Start Remote
Node NMT message. Finally, an RTR message with the identifier used by the detected
PDO will be sent to the DUT. Assuming no CAN errors occur, one of two events will
bring the PDO Test to an end. Either a PDO is received correctly, in which case no error
will be signalled, or a time-out is detected, meaning that the DUT failed to reply within
the PDO Time-out specified for the DUT, in which case a time-out error will be
signalled.

5.3.1.3 PDO Mapping Parameter Test

This test aims to check the implementation of the PDO mapping mechanism in the
DUT. This includes not only the verification of the correctness of the default mapping
in terms of the references to objects in the Object Dictionary but also changing this
mapping, if possible.
The test is performed by going through the EDS file looking for the PDO Mapping
Parameters that correspond to the PDOs implemented in the DUT. (Entries of this type
are stored in Indexes ranging from 1600H to 17FFH for receive PDOs and in Indexes
ranging from 1A00H to 1BFFH for transmit PDOs.)
For entries in the range corresponding to receive PDO mappings, the following test
will be performed:
• Using a SDO, the tool will read Sub-index 0 of the mapping parameter from the
DUT. This Sub-index contains the number of Object Dictionary entries mapped
onto the PDO. If the number of mapped entries is larger than 64, an error will be
signalled to the user and no further testing will be performed on that particular
mapping parameter. The same happens if the transfer is aborted or if any other error
occurs.
• If no error is detected, the remaining Sub-indexes of this object will be read using
SDOs. If any of these transfers is aborted or if there is some inconsistency in the
size of the data received, an error will be signalled to the user. The information
about the mapped objects will be stored by the tool so that it can be used in the
remainder of the test. During this process the structure of the data received will be
analysed. In particular, when all the Sub-indexes have been read, the total size of the
mapping will be computed and compared to the maximum value, which is 64 bits. If
the total mapping size exceeds this value, an error will be signalled.
• The next step in the test is to attempt to access the mapped objects. The tool will try
to read from the entries mapped onto the PDO. If the transfers are aborted or any
other error occurs, an error will be signalled to the user. Also, if any of the mappings
is a dummy mapping, the tool will check in the EDS file whether or not the dummy
usage of that particular data type is supported.
• The test will proceed with the test tool trying to read from the PDO Mapping
Parameter in question a Sub-index entry that should not be supported. If this transfer
is not aborted, an error will be signalled to the user.

The following steps in the test will only be performed if the PDO Mapping
Parameter has an access type of rw, meaning that it can be altered:
• The tool will attempt to write a new valid mapping for the PDO e.g. the default
mapping but reversing the order of the mapped objects. If this operation does not
 160

succeed, an error will be reported to the user. Additionally, the tool will try to write
one mapped object too many to the entry. If the operation is successful, an error will
also be reported.
• Next, the tool will check if the DUT accepts mappings that are too long. This will be
done in two ways. The first way is to write to Sub-index 0 a value larger than 64,
meaning that there would be more than 64 mapped objects, which is not permitted.
If the DUT accepts the value, an error will be signalled. The second way is to map
onto the PDO a set of objects that take more than the 64 bits that are permitted. If
the mapping is accepted, an error will be signalled.
• The next step in the PDO Mapping test will be to try to map an Object Dictionary
entry with Access Type rwr onto the receive PDO, which is not permitted. For this
purpose, the tool will go through the EDS file looking for an entry suitable for
mapping that meets this requirement. If such an entry is found, an attempt will be
made to map it onto the PDO. If the operation succeeds, an error will be signalled.
• Finally, the test will terminate with the tool trying to map onto the PDO a
nonexistent Object Dictionary entry. If the mapping is accepted, an error will be
signalled.

For entries in the range corresponding to transmit PDO mappings, the test
performed will be very similar to the one just described. The only difference lies in the
fact that the tool will attempt to map onto the PDO an entry with access type rww
instead of an entry with access type rwr.

5.3.2 Object Dictionary Tests

The Object Dictionary tests are intended to verify that the implementation of the
Object Dictionary of the DUT agrees with the contents of its EDS file i.e. verifying that
the supported objects are implemented correctly and that no other objects exist in the
Object Dictionary of the DUT.

5.3.2.1 Communication Specific Area Test

The Communication Specific Area test aims to verify the implementation of objects
in the area of the Object Dictionary, ranging from Index 1000H to Index 19FFH.
The test tool will go through the EDS file of the DUT and for each entry (the main
Index section for single-entry objects or all the Sub-index sections in multiple-entry
objects) in this range the following tests will have to be performed:
• The entry will be read using a SDO transfer. If an error of any type occurs or the
transfer is aborted, an error will be signalled to the user and the test will not proceed
for this entry. Note that for entries with an access type of wo, the test cannot be
performed.
• If the transfer is successful and the default value for the entry is indicated in the
EDS file, the data received will be compared to this default value. Any mismatch,
including data size incompatibilities, will be signalled as an error to the user. The
value of the entry will also be compared to the values of the HighLimit and
LowLimit keywords in the EDS, if these exist (the value of the entry must be within
the range that the HighLimit and LowLimit parameters define). For a very restricted
set of Object Dictionary entries, a data format and default value error check will also
be performed on the data. These formats and default values are defined in DS301
and they are listed in Table 5.14. In addition to the entries shown in Table 5.14, the
 161

default values of the entries that hold the default communication identifiers
allocated to the device are also verified.
• When writing is not permitted in a particular entry (access types ro or const), an
attempt will be made to perform a SDO write operation to it e.g. using the data
previously read. If the transfer is not aborted, an error will be signalled to the user.
• Finally, if writing is permitted to a particular entry and if one or both of the
HighLimit or the LowLimit values are indicated in the EDS file these must also be
tested. For example, these values can be written to the object and, if any of the
transfers is aborted, an error can be indicated to the user.

Table 5.14 Entries with pre-defined values and formats

Object Dictionary Entry Pre-defined Format
Profile Number
4[0-9][0-9]
Index=1000H Sub-index=0
Communication Cycle Period
0
Index=1006H Sub-index=0
Synchronous Window Length
0
Index=1007H Sub-index=0
Guard Time
0
Index=100CH Sub-index=0
Lifetime Factor
0
Index=100DH Sub-index=0
High Resolution Time Stamp
0
Index=1013H Sub-index=0
Inhibit Time EMCY
0
Index=1015H Sub-index=0
Consumer Heartbeat Time
0
Index=1016H Sub-index=0
Producer Heartbeat Time
0
Index=1017H Sub-index=0

5.3.2.2 Device and Manufacturer Specific Area Test

The Device and Manufacturer Specific Area test is very similar to the
Communication Specific Area test. It aims to verify the implementation of objects in the
area ranging from Index 2000H to Index 9FFFH.
The test tool will go through the EDS file of the DUT and for each entry in this
range (the main Index section for single-entry objects or all the Sub-index sections in
multiple-entry objects) the following test will be performed:
• A SDO read operation will be performed on the entry. If an error of any type occurs
or the transfer is aborted, an error will be signalled to the user and the test will not
proceed for this entry. Note that for entries with an access type of wo, the test cannot
be performed.
• If the transfer is successful and the default value for the entry is indicated in the
EDS file, the data received will be compared to this default value. Any mismatch,
including data size incompatibilities, will be signalled as an error.
• When writing is not permitted in a particular entry (access types ro or const), an
attempt will be made by the tool to perform an SDO write operation to it, using the
data previously read from it. If the transfer is not aborted, an error will be signalled.
• Finally, if writing is permitted to a particular entry, an attempt will be made by the
tool to perform a SDO write operation to it e.g. using the data previously read from
 162

it. If the transfer is aborted or any other error occurs, an error will be signalled to the
user.

5.3.2.3 Remaining Area Test

The Remaining Area test is a very simple test that aims to check if there are any
hidden Object Dictionary entries in the DUT i.e. if there are any entries in the DUT's
Object Dictionary that are not indicated in the EDS.
To perform the test, the tool will go through the Index range 0000H to FFFFH and,
for every Index not supported in the EDS file, an attempt will be made to perform an
SDO read operation from Sub-index 0. If the transfer is not aborted, that means a hidden
entry has been found and an error will be signalled to the user.

5.3.3 Parameter Storage/Restorage Test

The Parameter Storage/Restorage test aims to verify the implementation of the
mechanisms for storage and restorage of Object Dictionary parameters in devices that
support them.
Firstly, the functionality of the Sub-index 1 entries at indexes 1010H and 1011H are
tested. These entries are used to store and restore parameters in all areas of the Object
Dictionary.
The storage test consists of the following steps:
• The Guard Time parameter and/or the Heartbeat Producer Time parameter,
depending on which entry is supported by device, will be changed to a non-default
value i.e. a value different than 0.
• The second step in the test is to read the information in Index 1010H and Sub-index
1. This information indicates if the parameter storage functionality is supported by
the device and, therefore, is used to determine if the test should proceed.
• The test tool then tries to store the parameters in the Object Dictionary by writing a
wrong signature code to Index 1010H and Sub-index 1. If the device accepts the
wrong signature, an error is signalled.
• The next step in the test is to effectively store the parameters, this time using a
correct signature code. The storage is verified by resetting the node using the Reset
Node service and reading the value of the entries modified in the initial stage of the
test. If the storage was successful, the values in these entries should be different than
zero.
• The test proceeds with the test tool reading the information at Index 1011H and
Sub-index 1 in order to determine if the parameter restorage functionality is
supported by the DUT.
• If the restorage functionality is supported, then the test tool will try to restore the
default Object Dictionary parameters, first by writing a wrong signature code to
Index 1011H and Sub-index 1; and then by writing the correct signature code to the
same entry. In the first case, an error will be signalled if the wrong signature is
accepted. On the other hand, if the proper restorage procedure is successful, the
node will be reset and the entries that were modified in the beginning of the test will
be checked, confirming that the correct default values have been reinstated.
• If the restorage functionality is not supported by the DUT, the Object Dictionary
entry modified in the beginning of the test will be written with its original value and
the parameters will be stored once again.
 163

The test previously described will then be repeated for Sub-index 2 at Indexes
1010H and 1011H. The storage and restorage functionalities accessible through these
entries apply to parameters in the Communication Profile area of the Object Dictionary
only.

5.3.4 Emergency Test

The Emergency test aims to verify the correctness of the implementation of the
Emergency Object functionality, i.e. the Object Dictionary entries related to it.
For the first part of this test to be performed the DUT must implement the COB-ID
Emergency Message object at Index 1014H and Sub-index 0. The test will begin with
the tool performing a SDO read operation from this object. If the transfer is aborted,
meaning that the DUT does not support the 1014H entry, the test will not go any
further.
If the transfer is successful, the tool will retrieve the value of the Emergency
message identifier. If this value doesn't match the pre-defined default value for this
parameter, which is an 11-bit identifier equal to 128+(Node ID), an error will be
signalled. The same will happen if there is an error in the size of the data returned.
The Object Dictionary entries at Index 1001H and Index 1003H are also tested since
they contain information about the error status of the device. The former of these
entries, the Error Register, is mandatory and must hold an UNSIGNED8 value at Sub-
index 0. The Pre-defined Error Field entry, at Index 1003H, is not mandatory, but if
supported it must hold at least Sub-indexes 0 and 1.

5.3.5 Error Control Tests

The Error Control Tests aim to verify the correctness of the implementation of the
NMT Error Control services: the Node Guarding, the Life-guarding and the Heartbeat
services.

5.3.5.1 Node Guarding and Life-guarding Test

The Node Guarding and Life-guarding test aims to verify the correctness of the
implementation of the Node Guarding mechanism, as well as the Object Dictionary
entries related to it.
Firstly, the Object Dictionary entries corresponding to the Guard Time and Lifetime
Factor parameters are read and their default values are checked.
If no errors are detected, the tool will proceed to Guard the DUT three times using
the default Node Guarding identifier. If the node fails to respond, if there is an error in
the state indicated by the DUT or if an error is detected in the toggle bit of the Node
Guarding message, these will be reported to the user.
To terminate the test, a set of RTR messages will be sent to the DUT, covering the
Node Guarding identifier range (1793 to 1919). If the DUT responds to a Node
Guarding message not carrying the correct default identifier, an error will be signalled
to the user.
The Life-guarding mechanism cannot be tested since the action that a NMT Slave
should take, if the Master fails to perform the Node Guarding protocol correctly, is not
defined.
 164

5.3.5.2 Heartbeat Test

The Heartbeat Test aims to verify the correctness of the implementation of the
Heartbeat protocol, if it is supported by the device.
The test begins with the test tool reading the 1017H entry from the Object
Dictionary of the DUT. If the transfer is aborted then the test does not proceed; the test
tool assumes that the device does not support the Heartbeat protocol. If the transfer is
successful, the value that was uploaded must be null, since this is the default value
imposed on the Heartbeat Producer Time entry.
If the Heartbeat service is supported by the DUT, the test tool writes to Index 1017H
a valid value for the Heartbeat Producer Time parameter. This should trigger the DUT
to begin transmitting Heartbeat messages periodically. The test tool then verifies that
these messages are received at the correct rate, within a tolerance of 20%. The test tool
also verifies that the state indications contained in the Heartbeat messages is correct.
If no errors are found, the test will proceed with a write operation that resets the
Heartbeat Producer time to zero. This should terminate the Heartbeat protocol, and this
fact is verified by the test tool: an error is signalled if further Heartbeat messages are
received.
If the device supports the Heartbeat Consumer Time object at index 1016H the
default values of the Heartbeat Consumer Time entries are also verified: these values
must also be null. Furthermore, the test tool will try to configure two entries in this
array with the same Heartbeat Producer Node ID. If the DUT accepts this configuration,
an error will be signalled to the user.

5.3.5.3 Heartbeat / Node Guarding Precedence Test

This test aims to verify that the Heartbeat service has precedence over the Node
Guarding and Life-guarding protocols in the DUT implementation, as stated in the
CANopen Communication Profile.
In fact, regardless of the Node Guarding and Life-guarding configuration, if the
Heartbeat protocol is activated, i.e. if the Heartbeat Producer Time parameter is given a
non-zero value, this protocol should become the only NMT Error Control service active
on a CANopen device.
The test consists of the following steps:
• Firstly, the Heartbeat Producer Time entry (Index 1017H) is read in order to
determine if the device supports the Heartbeat service. If the transfer is not aborted,
the test tool assumes that the DUT supports this service and proceeds to write a null
value to this entry. On the other hand, if the transfer is aborted, the test does not
proceed.
• Secondly, the test tool reads the Guard Time and Lifetime Factor entries from the
DUT's Object Dictionary. If one of these entries is not supported by the DUT, this
test cannot be carried out. On the other hand, if both these entries are supported, the
test tool writes null values to both of them, deactivating the Life-guarding protocol.
• At this point in the test the Heartbeat protocol should be deactivated and the Node
Guarding protocol should be operational. The test tool will then wait, during a
predefined time interval, for the arrival Heartbeat message that should not arrive. If
a Heartbeat message is received, an error is signalled.
• The test proceeds with a verification that the Node Guarding protocol is operating
correctly. If the Node Guarding protocol is not working properly, the test tool will
signal an error to the user.
 165

• At this point, the test tool will activate the Heartbeat protocol by writing a non-zero
value to Index 1017H in the DUT's Object Dictionary. The reception of a Heartbeat
message is then verified by the test tool, to ensure that the Heartbeat protocol is
operating properly.
• Finally, the test will be terminated with an attempt to activate the Life-guarding
protocol. For this purpose, the Guard Time and Lifetime Factor entries are written
with valid, non-zero, values. This should not affect the Heartbeat protocol and, for
this reason, the test tool then verifies that this protocol is still operating properly.

5.3.6 Synchronisation Test

The Synchronisation test aims to verify the correctness of the implementation of the
synchronisation mechanism, as well as the Object Dictionary entries related to it.
For the first part of this test to be performed the DUT must implement the COB-ID
SYNC Message object at Index 1005H and Sub-index 0. The test will begin with the
tool performing a SDO read operation from this object. If the transfer is aborted,
meaning that the DUT does not support the 1005H entry, the test will not go any
further.
If the transfer is successful, the tool will retrieve the value of the Synchronisation
Object message identifier. If this value doesn't match the predefined default value for
this parameter, which is an 11-bit identifier with value 128, an error will be signalled.
The same will happen if there is an error in the size of the data returned.
If no errors are detected, the tool will proceed to verify the synchronisation
mechanism itself. For this to be possible, the test tool will look for an active transmit
PDO in the Object Dictionary. This is done by reading the PDO Communication
Parameters of the PDOs supported by the DUT until a PDO meeting these requirements
is found. When an active transmit PDO is found, the test tool will test the
synchronisation mechanism in the following way:
• Using an SDO write operation, the Transmission Type parameter of the PDO (Sub-
index 2 in the corresponding PDO Communication Parameter entry) will be set to
10, meaning that the DUT should transmit a PDO every tenth occurrence of the
Synchronisation Object.
• The DUT will be put in Operational state using a Start Remote Node message.
• Ten or more successive SYNC messages will be sent to the DUT. If there is no PDO
transmission on every tenth SYNC message or if a PDO is received on any other
occurrence of this message, an error will signalled.

Finally, for devices that indicated in the data retrieved from Index 1005H that they
may operate as Synchronisation Object Producers, the test will proceed with the
following steps:
• The test tool will use a SDO transfer to configure the Communication Cycle Period
parameter (Index 1006H) to 100 milliseconds.
• The production of the Synchronisation Object will be initiated through the
functionality of Index 1005H.
• The test tool will verify that the Synchronisation Object is received at the correct
rate, within a given tolerance e.g. 20%.
 166

5.3.7 Verification of Network States

The Verification of Network States tests aim to verify that the behaviour of the DUT
in the Operational, Pre-operational and Stopped states agrees with the CANopen
specification. Additionally, the test tool verifies the default state that the DUT enters
after being reset. This is called a State 'Reset' test.
Throughout the Verification of Network States tests, the state of the DUT must be
monitored using the Node Guarding protocol and/or the Heartbeat protocol depending
on the services implemented on the device. In the following tests, whenever a state
monitoring is required, the test tool will first try to use the Node Guarding protocol and
then the Heartbeat protocol. Throughout the tests, any errors found in these protocols
will be signalled to the user.
The test of the Pre-operational state functionality will begin with the node being
reset by means of a Reset Node service. This will be followed by a SDO read operation
from the mandatory object at Index 1000H. This is done because SDOs must be active
in Pre-operational state; they are a very important part of the
functionality of the DUT in this state. If the read operation is not successful, an error
will be signalled to the user and the test will not proceed.
The state of the DUT is then verified using the NMT Error Control services, and it is
expected that the device will report that it is in Pre-operational state.
The final step of the test will be to request the transmission of a PDO by the DUT.
For this to be possible, the test tool will first look for an active transmit PDO in the
Object Dictionary. This is done by reading the PDO Communication Parameters of the
PDOs supported by the DUT until a PDO meeting these requirements is found. When
an active transmit PDO is found, the test tool will send a RTR message with the
identifier of the detected PDO to the DUT. Assuming no CAN errors are detected, one
of two events will occur; either a PDO is received correctly by the test tool, in which
case an error will be signalled because PDOs are not allowed in Pre-operational state; or
a time-out is detected, meaning that the DUT failed to reply within the PDO Time-out
time specified for the DUT, in which case no error will be signalled.
The test of the functionality of the Operational state is almost identical to the Pre-
operational, therefore a detailed description of this test is not necessary. In short, the test
consists of the following procedure:
• The DUT will be initially reset using the Reset Node service.
• The state of the DUT will be tested using the NMT Error Control protocols to verify
that it is in Pre-operational state.
• The DUT will be moved to Operational state using the Start Remote Node service.
• The mandatory object at Index 1000H will be read and if any errors occur this will
mean that the SDOs are not operating correctly in Operational state, indicating a
faulty implementation. SDOs must be available in the Operational state.
• The state of the DUT will once again be tested to verify that it is in Operational
state.
• The tool will look for an active transmit PDO in the DUT in the same way as in the
Pre-operational test.
• If an active transmit PDO is found in the device, the transmission of that PDO will
be requested and failure to respond will indicate a faulty implementation. PDOs
must be available in the Operational state.
 167

Again, the test of the functionality of the Stopped state is almost identical to the Pre-
operational test, therefore a detailed description of this test is not necessary. In short, the
test consists of the following procedure:
• The DUT will be initially reset using the Reset Node service.
• The state of the DUT will be tested using the NMT Error Control protocols to verify
that it is in Pre-operational state.
• The tool will look for an active transmit PDO in the DUT in the same way as in the
Pre-operational test.
• The DUT will be moved to Stopped state using the Stop Remote Node service.
• The mandatory object at Index 1000H will be read and, if the transfer is successful,
this will mean that the SDOs are operating correctly in Stopped state, indicating a
faulty implementation. SDOs must be off-line in the Stopped state.
• The state of the DUT will once again be tested to verify that it is in Stopped state.
• If an active transmit PDO was found in the device, the transmission of that PDO
will be requested and a successful response will indicate a faulty implementation.
PDOs must be off-line in the Stopped state.

Finally, the test of the functionality of the 'Reset' state is also similar to the Pre-
operational state test. There is, however, a difference in that what is being tested is not a
formal network state but, in fact, the restoration of the default status of the device after
it is reset. As before, a detailed description of this is not necessary. In short, the test
consists of the following procedure:
• The DUT will be initially reset using the Reset Node service.
• The state of the DUT will be tested using the NMT Error Control protocols to verify
that it is in Pre-operational state.
• A well-defined set of Object Dictionary entries will be written with non-default
values; if one or more of the transfers are aborted, meaning that the entries are not
supported, the entries are ignored. These entries and the non-default values that are
used for this purpose are shown in Table 5.15. From this Table, it is possible to
verify that one of the modified entries will be the object at Index 1014H, which
holds the COB-ID Emergency Object parameter.
• The DUT will be reset using the Reset Node protocol.
• The test tool will verify the state of the DUT and it is expected that the DUT reports
that it is in Pre-operational state.
• The tool will verify that the default values for the entries that were previously
accessed have been restored: it will perform the required SDO read operations and
compare the read values with the default ones. Any errors or discrepancies will be
signalled to the user.

Table 5.15 Object Dictionary entries used for the State 'Reset' test
Object Dictionary Entry Default Value
Index 1005H 128
Index 1006H 0
Index 1007H 0
Index 1012H 256
Index 1014H 128+Node ID
 168

5.3.8 Verification of State Transitions

The Verification of State Transitions tests aim to verify that the state diagram
defined in DS301 for a NMT Slave device is correctly implemented by the DUT.
Namely, these tests are concerned with the way in which a device responds to
external signals, in this case NMT services that are used to change its state. There
are four Verification of State Transitions tests:
• Transition to Pre-operational.
• Transition to Operational.
• Transition to Prepared.
• Transition to Reset.

Throughout the Verification of State Transitions tests, the state of the DUT must be
monitored using the Node Guarding protocol and/or the Heartbeat protocol depending
on the services implemented on the device. In the following tests, whenever a state
monitoring is required, the test tool will first try to use the Node Guarding protocol and
then the Heartbeat protocol. Throughout the tests, any errors found in these protocols
will be signalled to the user.
The first step in the transition to Pre-operational state will be to reset the node using
the Reset Node service. The test proceeds, using the NMT Error Control protocols to
verify the state of the DUT, and it is expected that the DUT will report that it is in Pre-
operational state. Any other response will mean that an error exists in the protocol
implementation.
After this, the DUT will be moved into Operational state by the test tool, using a
Start Remote Node message. This transition will be verified using the NMT Error
Control protocols once again. The DUT is expected to report that it is in Operational
state.
The next step will be to return the DUT to Pre-operational state using an Enter Pre-
operational State message. This transition will again be verified using the NMT Error
Control protocols. The DUT is now expected to report that it is in Pre-operational state.
The DUT will then be moved into Stopped state using a Stop Remote Node
message. This transition will once more be verified using the NMT Error Control
protocols. The DUT is expected to report that it is in Stopped state.
Finally, the test tool will move the DUT back into Pre-operational state using the
Enter Pre-operational State command. This final transition will again be verified using
the NMT Error Control protocols. The DUT is expected to report that it is in Pre-
operational state.
The transitions to Pre-operational state will not be completely tested until the
response of the DUT to global addressing in the NMT commands is considered. This
issue is addressed in the remainder of the test: first the DUT will be reset using the
Reset Node command, addressed to all nodes (Node ID = 0), and then the test
previously described is repeated using also global addressing.
The Transition to Operational and Transition to Prepared states tests are very similar
to the Transition to Pre-operational test: the DUT is moved from state to state using the
appropriate CANopen services and its state is monitored using the NMT Error Control
protocols. The procedure for these tests is summarised in Table 5.16 and Table 5.17.
 169

Table 5.16 Transition to Operational State test procedure

Initial State CANopen Service Final State
- Reset Node Pre-operational
Pre-operational Start Remote Node Operational
Operational Stop Remote Node Stopped
Stopped Start Remote Node Operational
- Reset Node (all) Pre-operational
Pre-operational Start Remote Node (all) Operational
Operational Stop Remote Node (all) Stopped
Stopped Start Remote Node (all) Operational

Table 5.17 Transition to Prepared State test procedure

Initial State CANopen Service Final State
- Reset Node Pre-operational
Pie-operational Stop Remote Node Stopped
Stopped Start Remote Node Operational
Operational Stop Remote Node Stopped
- Reset Node (all) Pre-operational
Pre-operational Stop Remote Node (all) Stopped
Stopped Start Remote Node (all) Operational
Operational Stop Remote Node (all) Stopped

Finally, the Transition to Reset test differs slightly from the previous ones, even
though the principles of the test procedure are the same. This procedure is summarized
in Table 5.18. It is important to keep in mind that each transition is verified using the
NMT Error Control protocols.

Table 5.18 Transition to Reset testprocedure

Initial State CANopen Service Final State
- Reset Node Pre-operational
Pre-operational Start Remote Node Operational
Operational Reset Communications Pre-operational
Pre-operational Reset Node (all) Pre-operational
Pre-operational Start Remote Node (all) Operational
Operational Reset Communications (all) Pre-operational

5.4 THE CANopen TEST INTERFACE (C.O.T.I.)

In the beginning of this chapter, while discussing the CANopen Conformance
Testing specification produced by the relevant CiA Special Interest Group, it was
mentioned that this document defines a standard software interface that should be used
by test tools to access the CAN hardware. This standard software interface is called the
CANopen Test Interface or, in short, C.O.T.I.
The reason for the specification of this interface is to allow any hardware platform
to serve as a basis for CANopen Conformance Testing Tools. This concept is better
explained with the aid of the block diagram shown in Figure 5.1.
In Figure 5.1 it is shown that whatever CANopen Conformance Testing tool is used,
it will look for the same software interface to the CAN hardware. This interface, the
C.O.T.I., will be in the form of a WINDOWS DLL.
Hence, in order to use a particular CAN card to do the testing, all that is required is
to develop a DLL that, using this card, is able to offer the specified C.O.T.I.
 170

functionality to the test tool. The development of this DLL is not a complex task,
requiring only a basic knowledge of CAN and of the CAN hardware in question and a
bit of programming.

Figure 5.1 Block diagram of CANopen Conformance Testing platforms

The C.O.T.I. consists of the following functions:

• COTI_InitBoard - this function must be the first to be called by the test tool. Since
the CAN hardware cannot be shared, this function will check whether the hardware
is already being used by any other application. If it is, the operation fails. If it isn't, a
hardware handle will be returned to the test tool. This handle will subsequently be
used as a parameter, by the tool, whenever it uses the C.O.T.I. Finally, the CAN
hardware will be reset, losing its entire communication configuration. This means
that, before using the CAN hardware, the COTI_InitCan function must be called.
• COTI_CancelBoard - this function can be called by the test tool when it has finished
using the C.O.T.I. so that the C.O.T.I. is free for other applications to use it.
• COTI_ResetBoard - this function can be called by the tool to reset the hardware.
Again, its entire communication configuration will be lost, and the COTI_InitCan
function will have to be called before using the hardware.
• COTI_InitCan - this function must be called by the test tool before it tries to
communicate using the CAN hardware. Basically it is used to configure the
communication parameters of the hardware, such as the baudrate and the type of
CAN identifier that will be used.
• COTI_ReadBoardInfo - this function can be called by the tool to collect information
about the hardware platform e.g. the type of hardware, the versions of the hardware
and the firmware in it, etc.
• COTI_ReadBoardStatus - this function can be called by the test tool to monitor the
global status of the hardware e.g. how much of the processor's capacity is being
used or if there has been any data lost in the communication between the test tool
and the hardware.
• COTI_ReadCanInfo - this function can be used by the test tool to collect
information about the CAN hardware e.g. the type of CAN controller, etc.
 171

• COTI_ReadCanStatus - this function can be used by the test tool to monitor the
status of the CAN hardware e.g. if messages have been lost, what is the error status
of the CAN controller, etc.
• COTI_ReadObj - this function can be used by the test tool to retrieve a message
with a particular identifier from the receive queue.
• COTI_TransmitObj - this function can be used by the tool to transmit a message.
• COTI_RequestObj - this function can be used by the test tool to transmit a RTR
message and retrieve the data returned in the response, if a response is received.
• COTI_SetTimeout - this function can be called by the tool to wait for a specified
time delay to elapse. It is used to implement time-out mechanisms.

For a more detailed description of the technical aspects of the C.O.T.I., refer to the
CANopen Conformance Testing specification.
 172

CHAPTER 6
Example of a CANopen Implementation
Chapter objectives
When you have completed this chapter you should:
• Know what is a digital I/O module.
• Understand the hardware requirements of a simple digital I/O module.
• Understand the structure of a typical CANopen implementation.
• Know how message transmission is handled in a typical CANopen implementation.
• Know how message reception is handled in a typical CANopen implementation.
• Understand how an Object Dictionary is implemented in a typical CANopen
implementation.
• Understand how synchronous and asynchronous PDOs can be implemented.

6.1 INTRODUCTION
CANopen, based on the popular Controller Area Network (CAN) represents an ideal
networking system for distributed control systems and overcomes some of the
limitations inherent to other network protocols. In order to understand the
implementation of CANopen on devices, an example is given in this chapter which
should aid field engineers to implement CANopen on their own devices. This example
covers a digital I/O implementation.
Often, in industrial automation environments, sensors and actuators have to be
placed at geographically remote locations. It is common for devices of these types to be
located at considerable distances from the processing units that use them to carry out a
particular task. When this is the case, a possible solution, and one that is gaining
increasing popularity, is to use an autonomous I/O module, located close to the sensors
and actuators, providing the application with an interface to these devices. For this to be
possible, the application must be distributed between the remote I/O module and the
local processor(s), by using a communication network such as CANopen, to allow the
different parts to co-operate.
This example describes the development of a CANopen I/O module based on the
SAB-C167CR-LM chip from Siemens. The device is able, on one hand, to interface
with sensors and actuators using digital signals and, on the other hand, to communicate
using the CANopen protocol. In other words, the I/O module makes sensors and
actuators accessible via the CAN bus, using the CANopen protocol (Figure 6.1). The
objective is to show that CANopen can be implemented over new hardware platforms,
in minimum time, with satisfactory results.
 173

Figure 6.1 Operation of an I/O module

6.2 OVERVIEW OF THE SAB-C167CR-LM MICROCONTROLLER

In this section, the SAB-C167CR-LM chip (C167) will be introduced. Only the
features of the microcontroller which are relevant for this particular application will be
discussed.
The C167 chip is part of the Siemens C166 microcontroller family and it is a
powerful tool for embedded control applications. A general block diagram of this
microcontroller is shown in Figure 6.2.

Figure 6.2 Simplified block diagram of the SAB-C167CR-LM

Some of the most important features of this microcontroller are:

• The processor core is optimised for high instruction bandwidth (fast execution) and
high performance when processing jump instructions. The interrupt response-time is
minimised by allowing the interruption of multiple-cycle instructions such as
multiply and divide. Additionally, the context switching time is also optimised by
increasing the flexibility in handling multiple internal register banks.
• The total addressable memory space is 16Mbytes including both internal and
external code and data areas, organised in a 'Von Neumann' memory model i.e. the
code and data areas share the same address range. Internal memory areas provide
access to 2Kbytes of on-chip RAM and to the Special Function Registers (SFRs)
 174

that permit access to the embedded peripherals. The embedded XRAM provides
2Kbytes of additional on-chip memory. It is
• connected to an internal XBUS and therefore it is accessed as external memory.
• The interrupt system of the C167 is based on a multiple priority interrupt manager.
Interrupt sources may be freely prioritised and they can also be grouped. This allows
the user to prevent interrupt routines of the same priority from interrupting each
other. Each of the possible interrupt sources has a dedicated vector location that
holds the address of the corresponding interrupt service routine. Additionally, each
interrupt source has a dedicated interrupt control register.
• The C167 provides up to 111 parallel I/O lines. These lines may be used for general
purpose I/O, by the integrated peripherals or for the external buses. The operation of
the I/O pins is configurable by accessing dedicated Special Function Registers.
• The C167 has two general-purpose timer units that can be used for timing, event
counting, pulse width measurement and other functions. The first timer unit contains
three timers/counters while the second unit contains two timers/counters and a 16-
bit capture/reload register. Each timer can operate independently or may be
concatenated with another timer of the same unit. There are three Special Function
Registers associated with each timer, which provide access to timer data, timer
control and timer interrupt control.

In addition to these features, and perhaps most important of all for the purpose of
this application, is the fact that the C167 carries an embedded CAN controller.
This integrated CAN controller is capable of handling the transmission and
reception of CAN frames according to the CAN Specification 2.0 i.e. it is able to handle
standard frames (11-bit identifiers) as well as extended frames (29-bit identifiers). It
provides Full CAN functionality on 15 message objects i.e. the filtering can be
performed exclusively by the controller. Moreover, Message Object 15 can also be
configured for Basic CAN functionality i.e. several messages can be accepted and the
remaining filtering done by software. All message objects work independently and can
be manipulated without influencing one another. Each of the message objects has a
unique identifier and its own set of control and status bits.
The CAN controller contains a memory area that provides storage for the 15
message objects and for the global CAN module control and configuration registers.
This memory space is accessible to the CPU (mapped onto the CPU's memory space),
behaving as a dual-port memory area.
The registers that can be used for the general control of the CAN controller are:
• Control Register - this register allows the CPU to put the controller in an
initialisation state, to enable CAN interrupts or perform other control functions.
• Status Register - through this register, the CPU is able to monitor the status of the
controller.
• Bit Timing Register - this register allows the CPU to program the temporal
properties of the frames in the CAN bus.
• Mask Registers - using the two global mask registers, it is possible to control which
message identifiers are accepted by the controller. These registers establish which
bits in the identifiers are relevant for message filtering in all message objects.
 175

As mentioned above, in addition to the latter registers, the CPU has also available in
its memory space 15 message objects. Each message object is composed of eight data
bytes, an arbitration register and two control and configuration registers (Figure 6.3).

Figure 6.3 CAN controller message object

The Message Control Register is used to act upon each message object (request
transmission, activate object, deactivate object, etc.) as well as to monitor the message
object's status (interrupt pending, new data, etc.). The Message Configuration Register
is used to establish the direction of the message object and to set/get the number of data
bytes in the message. The Arbitration Register plays different roles in transmit and
receive objects: in transmit objects the Arbitration Register holds the message identifier
to be transmitted; in receive objects the Arbitration Register is used for acceptance
filtering.
Since the CAN module is connected to the microcontroller as an X-peripheral, it is
able to interrupt the CPU via a reserved vector called XPO (external Peripheral 0). This
vector is similar to other interrupt vectors in the microcontroller, and it is programmed
via a register called XPOIC.
The on-chip CAN module of the C167 does not incorporate the Physical Layer for
connection to the CAN bus. This must be provided externally by a transceiver.

6.3 HARDWARE IMPLEMENTATION

6.3.1 Introduction
The first step in the process of developing a hardware implementation for a
particular application is the establishment of the general specifications that the circuit
must comply with. The set of hardware specifications established for the digital I/O
module in this example was:
• Implementation of the CAN Physical Layer according to the CANopen Reference
Model.
• The baudrate and the Node ID (parameters used in the CAN network) should be
configurable through dip switches or jumpers.
• Implementation of eight digital inputs and eight digital outputs.
• The DC power supply applied to the model should be 24V as this is a value
commonly used in industrial environments.

Figure 6.4 shows a photograph of the hardware implementation described in this

section.
 176

Figure 6.4 Photograph of the digital I/O module

6.3.2 Circuit Schematics and Explanation

The discussion contained in this section will be based on the circuit schematics,
presented in Appendix I.

6.3.2.1 The C167 Microcontroller and Supporting Hardware

Sheet 1 of the circuit schematics contains the C167 microcontroller. Connected to
pins 137, 138 and 140 of the C167 are the reset circuit (a single lµF capacitor at pin
140) and the oscillator circuit (containing a 5MHz crystal). It is important to mention
that the C167 contains an internal Phase Locked Loop that multiplies the oscillator
frequency by a factor of four. Consequently, the microcontroller's internal clock will
oscillate at a frequency of 20MHz.
Also in Sheet 1 of the schematics, an external EPROM can be identified. This is a
27C256 EPROM that can hold up to 32Kbytes of data. On the other hand, no external
RAM is used in this circuit. This is due to the fact that the C167 holds the 2Kbytes of
internal RAM characteristic of the C166 family, as well as 2Kbytes of additional on-
chip RAM for user applications, which is sufficient for this application.
The connections between the C167 and the EPROM comprise the 8-bit data bus, the
15-bit address bus and two control lines: A15 and /RD. These control lines ensure that
the EPROM will be accessible to the C167 in the bottom of its memory space i.e. from
address 0000h to address 7FFFh, and that no erroneous write operations can be
addressed at the EPROM. The reason why the EPROM is placed at the bottom of the
address range is to comply with the internal organisation of the C167, according to
which the interrupt vectors and the address of the program to be run are stored in the
initial bytes of its memory space.
As can be seen from the schematic, the least significant bits of the microcontroller's
Port 0 are used as the data lines. Port 1 is used for the address lines, although only its
alternate function as address bus is shown in the schematic.
 177

The four pull-down resistors connected to pins POL.6, POL.7, P0H.1 and P0H.4 are
used to inform the C167 during system reset of the hardware configuration that it will
be operating in.

6.3.2.2 The CAN Physical Layer

Most of the requirements for the implementation of the CAN Physical Layer are
accomplished by connecting the 82C250 chip, shown in Sheet 1 of the circuit
schematics, to the C167.
The 82C250 works as an interface between the CAN controller and the CAN bus: it
is a transceiver. It provides differential transmit capability and differential receive
capability to the CAN controller, connecting it to the bus according to the CAN
specification. This chip is intended for high-speed applications supporting baudrates of
up to IMbit/s. Additionally, it provides protection against short circuits and electrical
transients in the bus.
As can be seen from the schematics, the connections between the C167 and the
transceiver are limited to two lines: the CAN_TxD and the CAN_RxD lines. These lines
correspond to the output and input serial terminals of the CAN controller in the C167,
and they are adapted to the differential format required by the CAN bus through the
82C250 chip. The transceiver presents at its output the CAN-compatible CANH and
CANL lines for connection to the bus.
Pin 8 of the 82C250 (pin RS) is used to control the fall and rise times of the signals
put on the CAN bus and therefore permits regulating the electromagnetic interference
generated by the chip (the shorter the rise and fall times, the higher the generated
interference). The value of the resistor placed between this pin and ground determines
these times. In this case, the pin is short-circuited to ground, which means that the chip
is configured to provide minimum fall and rise times, since the reduction of generated
interference is not a critical issue in this application.
The connection to the CAN bus is provided by the two 9-pin connectors visible in
Sheet 2 of the circuit schematics. These connectors correspond to the standard 9-pin
connectors described in the CAN specification. By using two connectors (one male and
one female), it is possible to connect the module to the bus, ensuring bus continuity for
connection of other nodes without using a T-connector. The pin assignments in the 9-
pin connectors are in accordance to those established for CANopen.
When the module is to be used as a bus terminator, a resistor must be placed
between the bus terminals. The 120 Q resistor visible in Sheet 2 of the circuit
schematics serves this purpose, and it may be connected to the bus terminals by means
of a jumper.

6.3.2.3 The I/O Lines

The hardware specification for the I/O module requires eight input lines and eight
output lines. To meet these requirements, two 8-bit ports of the C167 were assigned to
the referred I/O functions: Port 6 pins constitute the eight input lines and Port 7 pins the
eight output lines.
A 20-pin flat-cable connector (shown in Sheet 2) provides external access to the I/O
lines. This connector is primarily intended to serve as an interface to signal conditioning
circuitry. However, the I/O lines can be directly connected to sensors and actuators
through this interface if signal conditioning is not required, i.e. if isolation and signal
conversion to/from TTL levels are not needed.
 178

The twenty pins of the I/O connector are divided into two 10-pin functional blocks
that carry out input and output functions, respectively.
The first ten pins of the connector are assigned to the eight input lines (pins 1 to 8),
ground (pin 9) and VCC (5 V at pin 10). The upper half of the I/O connector is assigned
to the eight output pins (pins 11 to 18) and ground (pin 19). The output lines from the
microcontroller (Port 7) are not connected directly to the external connector. Instead, the
output signals are fed through a current buffer (the 74LS244 chip in Sheet 1), which is
able to supply up to 50mA of DC current in each output line.

6.3.2.4 Additional Remarks

There are a few additional details of the digital circuit that require explanation.
As previously mentioned, the power supply to be connected to the processor board
is 24V. However, the digital circuit requires a 5V power supply which, for protection
purposes, should be isolated from the external supply. The external connector for the
24V power supply is shown in Sheet 2 of the circuit schematics with the caption of
POWER_MICRO. The power supply lines are then connected to a 2 W DC-DC
modular converter.
It was mentioned when discussing the hardware specifications that two network
parameters, the baudrate and the Node ID, would have to be set through jumpers or dip-
switches. In the circuit, four bits are used to set the Node ID (the least significant bits
from Port 8 of the C167), permitting the user to choose between sixteen different values
for this parameter. Although in a CAN network, it is possible to have more than sixteen
different nodes, it is important to notice that by allowing only sixteen different values
for the Node ID the functionality of the device is not compromised in the least. The
reason for this is that the Node ID range can be extended by altering the software of the
implementation.
The implementation of the baudrate selection functionality requires that at least
eight different values can be chosen. Therefore, four bits are sufficient to meet this
requirement and the upper four bits from the microcontroller's Port 8 are used for this
purpose.
The eight jumpers required to set the values of these parameters are shown in Sheet
2 of the schematics.

6.4 SOFTWARE IMPLEMENTATION

6.4.1 Introduction
The software implemented in the I/O module described in this example was written
in the C programming language. It is composed of a considerable number of functions
and procedures; an explanation of the program's operation addressing details of the C
code produced would be long, and will not be presented for this reason. Instead, the
presentation of the software will be addressed in a more general way: it will start with
the introduction of the software's global structure and, subsequently, move on to a more
comprehensive explanation of the different functional blocks of which it is composed.
The CANopen implementation in the digital I/O module discussed in this example
incorporates the following features:
• One Service Data Object, which is mandatory for all CANopen devices.
• One transmit and one receive event (asynchronous) PDO, which are mandatory for
digital I/O modules.
 179

• One transmit and one receive synchronous PDO.

• The Node Guarding protocol.
• The Emergency Object.
• The CANopen NMT Slave state diagram and supporting NMT Module Control
services, which are mandatory for all CANopen devices.
• The CANopen boot-up procedure, which is mandatory for all CANopen devices.

A block diagram of the software is presented Figure 6.5.

Figure 6.5 Block diagram of the software

Each of the blocks in the diagram will be explained in the following sections,
however, it is important to explain, first of all, how the program works in practice.
Three routines form the basis for the operation of the whole module:
• main() - this is the main procedure of the software, and it controls the global flow of
the program. It basically consists of a while loop in which all aspects of the module's
operation are monitored so that appropriate action is taken as soon as the module's
status changes. A status change can happen due to a modification in the state of the
input lines, due to the occurrence of an internal error or due to the reception of
CANopen data-transfer messages or NMT requests.
• CAN_int( ) - this is the interrupt service routine for the CAN controller. It is
invoked every time an event occurs on the CAN controller. This, in general,
corresponds to the reception of a message that requires processing. This routine
interprets incoming messages and passes them to the appropriate software functional
block by storing them in a memory buffer. This routine also handles autonomously
most of the Node Guarding protocol.
• Tx_serv_int( ) - this is the interrupt service routine for Timer 3 in the
microcontroller, which is programmed to produce an overflow interrupt roughly
every 50ms. Every time such an interrupt occurs, this routine checks the
transmission buffers which connect this part of the software to all of the software's
main functional blocks, and transmits any pending messages as soon as possible.

In short, virtually all tasks related to the exchange of CAN messages are performed
by these two interrupt service routines, which interface with the remaining software
through receive and transmit memory buffers, supported by a set of status flags.
 180

6.4.2 The Module Control Block

The Module Control Block, that can be seen in Figure 6.5, handles global system
control and configuration at reset, including communications boot-up, and it is
responsible for the implementation of the NMT services described in the CANopen
Communication Profile.
The CANopen Communication Profile describes node behaviour through a state
diagram, where transitions are triggered by NMT Module Control services. This state
diagram was described in Chapter 3 and it is implemented by the main( ) program
function.
On ‘power-on’ the module goes through an initialisation process that, in addition to
performing the hardware and software start-up configuration, leaves the device ready
for communication using a set of default identifiers.
After initialisation the module enters the Pre-operational state in which the module
can be accessed using SDOs. SDOs can be used to get information about the module by
reading from the Object Dictionary or to change the module's configuration by writing
to the Object Dictionary. In the Pre-operational state, apart from permitting SDO
accesses, the device waits for an NMT command.
When the device configuration procedure terminates, the device can be put in
Operational state by a Start Remote Node NMT indication, where all of its
functionalities will be available according to the established configuration. The node
can be put back into the Pre-operational state by an Enter Pre-operational State
indication. Transitions to Stopped state, where only the NMT services remain active,
can be triggered using the Stop Remote Node service.
At any time, the module can be caused to fully reset itself by a Reset Node
indication or simply to return to its default communication configuration settings by a
Reset Communication indication.

6.4.2.1 Initialisation
After 'power on', the module enters its initialisation phase, under the supervision of
the main() module. The following tasks are carried out in this phase:
• Setting of the CAN controller's global configuration. One of the features that must
be configured is the baudrate, which is selected according to the value hardwired in
the configuration jumpers. Baudrate values of 1Mbit/s, 500Kbit/s, 250Kbit/s,
100Kbit/s and 20Kbit/s can be selected by changing the hardwired value from 0 to
4.
• Initialisation of all the message buffers that permit the functional blocks to
communicate with the transmit and receive interrupt service routines.
• Initialisation of the Emergency Object parameters setting the error record to a 'no
error' status.
• Initialisation of an 'inputs-changed' event detector so that event PDOs can operate
properly.
• Configuration of the microcontroller's interrupt service system.
• Initialisation of the Timer 3 system so that the corresponding interrupt service
routine is invoked every 50ms.
• Initialisation of the microcontroller's I/O ports to function as inputs or outputs.
 181

Following this low level initialisation, the module enters a communication

configuration phase in which the default values for the communication parameters are
established. This procedure leads the module into entering the Pre-operational state with
the following default communications configuration:
• Object Dictionary entries are initialised to their start-up values. Namely, the output
lines are all set to zero, and the PDO operation is set to receive and transmit event
PDOs only.
• The message identifiers are set to the default values defined in the CANopen
Communication Profile and shown in Table 6.1. These values depend on the Node
ID (NID) selected in the configuration. Since a null Node ID is not permitted, the
value that is assumed for this parameter is the value indicated in the jumpers, plus
one. The CAN controller's message objects 2 to 9 are configured to transmit and
receive the Communication Objects used by the device.
• The module is prepared to receive and transmit the NMT Module Control messages
specified in the CAN Communication Profile. The messages that have to be
received for this purpose have identifier 0. The CAN controller's message object 14
is configured to accept messages with this identifier. Additionally, the node must
accept and transmit Node Guarding messages and message object 1 is in charge of
this function.

When the initialisation procedure is terminated, and just before entering the Pre-
operational state, the implementation automatically carries out the Boot-up Service
protocol. This protocol consists simply in the transmission of a message with the
identifier reserved for the Node Guarding messages and carrying a single byte of data
with a null value. Message object 1 in the CAN controller is used for this purpose.

Table 6.1 Default communication identifiers

Communication Object Identifier CAN Controller Message Object
NMT Module Control 0 14
Output Event PDO 385+NID-l 5
Output Synchronous PDO 641+NID-l 4
Input Event PDO 513+NID-l 7
Input Synchronous PDO 769+NID-l 6
Output SDO 1409+NID-l 9
Input SDO 1537+NID-l 8
Emergency Object 129+NID-l 3
Sync Object 128 2
Node Guarding Telegram 1793+NID-l 1

6.4.2.2 Implementation of NMT Services

The NMT services implemented in the module, apart from the Node Guarding
protocol, are the ones that can cause it to change its state. The protocol for all of these
services uses the null message identifier and the messages exchanged contain only two
data bytes. The first byte contains the Command Specifier that identifies the NMT
service, and the second byte contains the Node ID of the node for which the indication
is intended. A service can be addressed to all nodes by indicating a null Node ID, and
this is why no device can have a Node ID of value 0.
The module implements the following services:
 182

• Start Remote Node (NMT Command Specifier 1) - this service moves the module
from the Stopped or Pre-operational state to the Operational state.
• Stop Remote Node (NMT Command Specifier 2) - this service moves the module
from the Operational or Pre-operational state to the Stopped state.
• Enter Pre-operational State (NMT Command Specifier 128) - this service causes the
module to leave the Operational or Stopped state and enter the Pre-operational state.
• Reset Node (NMT Command Specifier 129) - this service causes the device to
perform a full hardware and software reset.
• Reset Communication (NMT Command Specifier 130) - this service causes the
device to return to its default communication configuration.

The implementation of these NMT services is achieved by programming message

object 14 in the CAN controller to accept messages with the null identifier. The CAN
interrupt service routine then changes the state of the device according to the NMT
command specifier received. Note that the state diagram of the device is implemented
by using a global variable to keep the current state of the device. This variable is
constantly checked by different parts of the software implementation, so that the
behaviour of the device agrees to what is specified in CANopen. Hence, changing the
state of the device means altering the value held by the referred global variable.
The Node Guarding protocol is also fully implemented, and serves its purpose of
permitting the NMT Master to detect erroneous changes in the state of the NMT Slave.
The module uses the CAN controller's Message Object 1, configured to respond to
remote frames with the Node Guarding identifier, issuing replies according to the
protocol specification. Since the Node Guarding protocol basically requires a simple
remote frame response to be transmitted, its software implementation is limited to a few
lines of code in the CAN interrupt service routine that change the toggle bit after each
transmission. Additionally, every time a change occurs in the device's state, this
parameter is updated in the message object holding the Node Guarding telegram.

6.4.3 The Service Data Object and Object Dictionary Block

The SDO block uses two CAN messages to allow other nodes to access the module's
Object Dictionary. One of the messages is used for transmission of data and it is
handled by the CAN controller's message object 9. The other message is used for data
reception and is handled by the CAN controller's message object 8. The actual
transmission and reception of data is performed by the two interrupt service routines
already described. These routines interface with the functions handling the SDO
communication through memory buffers.
When the module is in the Pre-operational or Operational state, the SDO receive
buffer is constantly monitored for Object Dictionary access.
The messages exchanged for SDO communication follow the SDO data transfer
protocols, as specified in the CANopen Communication Profile. When an incoming
message is detected in the SDO receive buffer, it is passed on to a function that
identifies the SDO protocol that is being invoked by the Client so that the correct
procedure is followed and an appropriate response can be issued.
Two services are used in the implementation for SDO data transfer:
• Initiate SDO Upload - this service is used to request read operations from the Object
Dictionary in the module. It is usually used to begin a multiple message SDO upload
protocol. However, it can also be used for expedited transfers of up to 4 data bytes
 183

using only one message exchange. Since in this module, all Object Dictionary
entries take no more than 4 bytes, only this expedited transfer mode is implemented.
• Initiate SDO Download - this service is used to perform write operations to the
Object Dictionary. For the same reason as before, only the expedited protocol is
supported.

Additionally, the service Abort SDO Transfer is also supported by the device. This
service permits the module to signal an error in the data transfer protocol. For example,
when a received SDO message contains an unrecognised request Command Specifier,
an Abort SDO Transfer message is sent to the Client carrying an error code that
indicates that a 'service parameter with an invalid value' has been detected.
In the following sections, the Object Dictionary implemented in the device will be
presented, followed by the procedure adopted when performing Object Dictionary
accesses.

6.4.3.1 The Object Dictionary

The operation of the Object Dictionary in this device is based on two functions that
perform write and read accesses on it. One of the functions takes as parameters the
Index and the Sub-index of the object being accessed, as well as the data to be written
into the Object Dictionary, and it returns a value indicating the success or failure of the
write operation. The second function takes as parameters the Index and Sub-index of the
object to be accessed and it returns the data read and a value indicating the success or
failure of the read operation. The structure of these functions is usually based on a
SWITCH statement or a succession of IF statements that, according to the Index and
Sub-index, store / return the corresponding data values or signal access errors. For write
operations, the size and format of the data must also be checked for compatibility with
the data type of the entry that is being accessed.
The structure of the Object Dictionary implemented in the module is shown in Table
6.2 where, along with the Index and Sub-index used to access the object, are listed the
name of the object, the type of object (Read / Write) and a short explanation of the
operation of the object.

Table 6.2 Object Dictionary entries

Index Sub-index Object R/W Meaning
Device Type Reading this entry returns a code which
1000 0 R indicates that this device implements digital
I/O functionalities.
Error Register Reading this entry returns one byte with the
error status of the device. A null value
1001 0 R
indicates no error. A value of 1 indicates a
generic CANopen error.
Pre-defined Error Field Reading this entry returns the number of
errors detected and signalled using the
0 R/W
Emergency Object. Writing to this entry resets
1003
the error record.
Reading these entries returns four bytes with
>0 R
an error code.
COB-ID SYNC Message This entry allows setting and reading the
1005 0 R/W message identifier used by the
Synchronisation Object.
1008 0 Manufacturer Name R Returns ‘NU’.
 184

1009 0 Hardware Version R Returns '1.0'.

100A 0 Software Version R Returns '2.1'.
100C 0 Guard Time R Returns 0, the default value for this entry.
100D 0 Lifetime Factor R Returns 0, the default value for this entry.
COB-ID Emergency Object This entry allows setting and reading the
1014 0 R/W message identifier used by the Emergency
Object.
Identity Object This entry contains coded identification
1018 0 R
information about the device.
Receive PDO 001 Object of type PDO Communication
1400 all R/W
(Event PDO) Parameter.
Receive PDO 003 Object of type PDO Communication
1402 all R/W
(Synchronous PDO) Parameter.
Receive PDO 001 Mapping Returns 1, meaning that only one object is
0 R
Parameter mapped in the PDO.
1600 Returns a 4 byte code indicating that it is a 8-
1 R bit long mapping of Index 6200H, Sub-index
1.
Receive PDO 003 Mapping Returns 1, meaning that only one object is
0 R
Parameter mapped in the PDO.
1602 Returns a 4 byte code indicating that it is a 8-
1 R bit long mapping of Index 6200H, Sub-index
1.
Transmit PDO 001 Object of type PDO Communication
1800 all R/W
(Event PDO) Parameter.
Transmit PDO 003 Object of type PDO Communication
1802 all R/W
(Synchronous PDO) Parameter.
Transmit PDO 001 Mapping Returns 1, meaning that only one object is
0 R
Parameter mapped in the PDO.
1A00 Returns a 4 byte code indicating that it is a 8-
1 R bit long mapping of Index 6000H, Sub-index
1.
Transmit PDO003 Mapping Returns 1, meaning that only one object is
0 R
Parameter mapped in the PDO.
1A02 Returns a 4 byte code indicating that it is a 8-
1 R bit long mapping of Index 6000H, Sub-index
1.
Read 8 Inputs Returns 1: the number of 8 input blocks on the
0 R
6000 device.
1 R Allows reading the eight input lines.
Write 8 Outputs Returns 1: the number of 8 output blocks on
0 R
the device.
6200
Allows reading and writing to the eight output
1 R/W
lines.

All the mandatory Object Dictionary entries and some of the optional ones defined
in the CANopen Communication Profile and in the Device Profile for I/O modules are
implemented. Further information about all entries can be found in these specifications.
The reason why the PDO001 entries are used for the event PDOs is because this is
specified as mandatory in the Device Profile for I/O modules. For the same reason, the
PDO002 entries are left unused, since they are reserved for Analogue I/O
functionalities.
 185

6.4.3.2 Object Dictionary Read and Write Operations

It was mentioned previously that read accesses to the Object Dictionary are
requested from the node using the Initiate SDO Upload protocol. On the other hand,
write accesses to the Object Dictionary are made using the Initiate SDO Download
protocol.
When a SDO request is received, the message is passed to a function that identifies
the service that is being invoked by the Client. If the invoked service is the Initiate SDO
Upload service, the function that implements Object Dictionary read operations is called
to fetch and return the referenced data. If this read operation is successful, the module
issues an Initiate Domain SDO response carrying the data to be transferred. If this read
operation is unsuccessful an Abort SDO Transfer message is sent containing an error
code that indicates an 'Access Error'.
On the other hand, if the invoked service is an expedited Initiate SDO Download,
the function that implements Object Dictionary write operations is called to verify the
compatibility of the data and to store it. If this write operation is successful, the module
issues an Initiate SDO Download response confirming the reception and acceptance of
the transferred data. If the write operation is unsuccessful, an Abort SDO Transfer
message is sent containing an error code indicating an 'Access Error'.

6.4.4 The Process Data Object Block

When the device is in the Operational state, the basic functionalities of the device
are accessible through Process Data Objects. This channel permits synchronous and
event data transfers with minimum protocol overhead.
Process Data Object communication in this implementation uses five
Communication Objects: two event PDOs, two synchronous PDOs and the
Synchronisation object. For this purpose, five of the CAN controller's message objects
(message objects 2, 4, 5, 6 and 7) are dedicated to the transmission and reception of
these messages.
According to the Device Profile for I/O Modules, it is mandatory for a digital I/O
module to implement an input and an output event (asynchronous) PDO. This
specification also requires that the configuration of these PDOs is available at the
entries of the Object Dictionary that correspond to the receive and transmit PDO001 as
referred to in the previous section.
The implementation of additional PDOs is optional. However, for a digital I/O
module designed to be used in industrial environments, it is very useful to support
synchronous PDOs and this is why two additional input and output PDOs of this type
were implemented. The configuration of these PDOs is available at the entries of the
Object Dictionary that correspond to the receive and transmit PDO003, since the
PDO002 entries are reserved for analogue I/O functionalities.
In the following sections the operation of synchronous and event PDOs will be
explained.

6.4.4.1 Event PDOs

The implementation of an input and an output event PDO is mandatory. They permit
writing to the output digital lines and reading from the input digital lines with minimum
response time.
The PDOs do not contain protocol information: all the data bytes in the data frame
contain useful information. This is possible because both sender and receiver know how
 186

the device's functionalities are mapped in the data bytes of the data frame. This mapping
is available in the Object Dictionary, and it may or may not be changeable (in this case
it is fixed).
In the particular case of a Digital I/O module, the mandatory PDOs must map the
values of the I/O lines. Therefore, in this implementation, the first byte in the
receive PDO data frames is mapped onto the eight output lines. On the other hand,
the first byte in the transmit PDO data frames is mapped onto the eight input lines.
In practice, when an event PDO is received, the CAN interrupt service routine
retrieves the first data byte from the data frame, and places it in a memory buffer. In
Operational state, this memory buffer is permanently monitored and when it is full, the
data byte in it is picked up and sent to the digital output lines.
Transmit event PDOs work in a different way. Their transmission is triggered by the
occurrence of an event internal to the module. The event that triggers the transmission
of an event PDO is the detection of a change in the values of the input lines. When such
an event is detected the new value of the input lines is placed in a memory buffer, so
that it can be transmitted the next time the timer interrupt service routine is invoked.
These mechanisms will only operate if the PDOs are enabled in the corresponding
Object Dictionary entries. The start-up configuration defined by CANopen for I/O
modules enables the default PDOs.

6.4.4.2 Synchronous PDOs

The input synchronous PDO implemented in this module works in a similar way to
the input Event PDO. The only difference lies in the fact that the value received is only
sent to the output lines when a Synchronisation message is received. This permits the
implementation of synchronised actuation on a network.
On the other hand, the only difference between output synchronous and event PDOs
is that synchronous PDOs are transmitted when a certain number of Synchronisation
messages is received. This allows the implementation of synchronised data collection
mechanisms which are usually required in standard industrial applications, i.e. cyclic
PDO communication.
The start-up configuration for the I/O module disables both receive and transmit
synchronous PDOs.

6.4.5 The Emergency Object Block

The Emergency Object is used by CANopen devices to report the occurrence of
internal errors. In fact, when an error occurs, the device, whatever state it is in, is forced
to suspend all operation until the error has been reported.
The basis for the operation of the Emergency Object is a data array in which the
codes for the detected errors are stored. Each time an error is added to the array, the
module stops the normal operation and reports the detected errors by sending
Emergency messages carrying the appropriate error codes, until there are no more errors
left to report. Message object 3 in the CAN controller is used to handle Emergency
telegrams. The structure of these telegrams is as follows:
• Bytes 0 and 1 hold one of the CANopen mandatory error codes 00O0H or 1000H,
indicating that no error condition remains in the device or that a Generic Error
condition remains in the device respectively.
• Byte 2 holds the status code stored in the Error Register entry of the Object
Dictionary.
 187

• Byte 3 holds an application specific error code that specifies the error that has been
detected, as will be explained below.
• The remaining bytes hold additional application specific information about the error
condition, such as the number of errors that have to be reported and the state of the
device.

In this particular module, the possible sources for internal errors are:
• SDO OVERRUN - this error is signalled when an SDO message is received before
the previous one has been processed. In this case, the application specific error code
is 4.
• COMMUNICATION ERROR: CAN BUS-OFF - this error is signalled when the
CAN interrupt service routine is invoked due to the CAN controller entering the
bus-off state. In this case, the application specific error code is 12H.

The Emergency Object is represented in the Object Dictionary by three entries: the
Error Register, the Pre-defined Error entries and the COB-ID Emergency Object entries.
 188

APPENDIX 1
Circuit schematics
189
 190

Glossary
BSP Bit Stream Processor JIT Just In Time

BTL Bit Timing Logic OSI Open Systems Interconnection

CAL CAN Application Layer LMT Layer Management

CAN Controller Area Network MAC Medium Access Control

CiA CAN in Automation MID Module Identifier

CIL CPU Interface Logic NMT Network Management

CAN based Message
CMS NRZ Non-Return-to-Zero
Specification
COB Communication Object PC Personal Computer

COTI CANopen Test Interface PCB Printed Circuit Board

CRC Cyclic Redundancy Check PCI Protocol Control Information

Carrier Sense Multiple
CSMA/CD PDO Process Data Object
Access / Collision Detection
DBT Distributor PDU Protocol Data Unit

DCF Device Configuration File PLC Programmable Logic Controller

DLC Data Length Code RTR Remote Transmission Request

DPLL Digital Phase Locked Loop SDO Service Data Object

EDS Electronic Data Sheet SDU Service Data Unit

EOF End of Frame SFR Special Function Register

FCS Frame Check Sequence SJW Synchronisation Jump Width

ID Identifier SME Small-Medium Enterprises

IDE Identifier Extension SOF Start of Frame

International Standards
ISO TCL Transceiver Control Logic
Organisation
IT Information Technology
 191

References
Barbosa M, Farsi M and Carvalho A [1998] "Implementation of a CANopen Digital I/O
Module Based on the SAB-C167CR-LM", Proceedings of IECON'98, Aachen,
1998.
Barbosa M, Farsi M and Ratcliff K [1998] "CANopen Implementation Made Easy",
Department of Electrical & Electronic Engineering, University of Newcastle upon
Tyne, 1998.
CiA [1996] "CAN - A Serial Bus System Not Just For Vehicles", CAN in Automation
Organisation, 1996.
CiA DS-102 [1994] "CAN Physical Layer for Industrial Applications", CAN in
Automation Organisation, 1994.
CiA DS-201 [1996] "CAN Reference Model", CAN in Automation Organisation, 1996.
CiA DS-202 to DS-207 [1996] " CAN Application Layer Specification", CAN in
Automation Organisation, 1996.
CiA DS-301 [1996] "CANopen Communication Profile for Industrial Systems", CAN
in Automation Organisation, 1996.
CiA DS302 [1998] "Framework for Programmable CANopen Devices" CAN in
Automation Organisation, 1998.
CiA DS-401 to DS-406 [1996] "CANopen Device Profiles", CAN in Automation
Organisation, 1996.
Farsi M [1993] "Flexible and Reliable Robotics Cells in Factory Automation",
Proceedings of the IEEE International Conference on Systems, Man and
Cybernetics, Le Touquet, France, pp 520-525, 1993.
Farsi M [1994] "Flexible Robotics Cells in Factory Automation: Communication
Concept", 3rd IEEE Conference on Control Application, CSS 94, Glasgow, UK,
pp. 1763-1768, 1994.
Farsi M [1995] "A Production Cell Communication Model In Factory Automation
Using The Controller Area Network", Proceedings of XII International
Conference On Systems Science, Wroclaw, Poland, pp 90-95, 1995.
Farsi M [1996] "Open Communication Solutions, CANopen", Proceedings of
Fieldbuses and Communications for Drives and Motion Control, Drives and
Control 1996 Exhibition & Conference, Telford, UK, pp 27-32, 1996.
Farsi M [1997] "An introduction to CANopen and profiling", IEE Workshop on
CANopen Implementation, IEE, Savoy Place, London, UK, 1997.
Farsi M, Booth R and Ratcliff K [1994] "Device Communication For Flexible
Manufacturing: A New Concept", Ninth International Conference on System
Engineering, Coventry Poly., UK, pp 328-334, 1994.
Farsi M and Ratcliff K [1996] "CANopen, Configure Device Testing", Proceedings of
FieldComm Conference 96, Hinckley Island Hotel, Leicester, UK, 1996.
 192

Farsi M and Ratcliff K [1997] "CANopen: Conformance and Device Testing" ICSE'97,
Coventry University, UK, pp 242-247, 1997.
Farsi M and Ratcliff K [1997] "Introduction to CANopen and implementation",
CANopen Workshop, IEE, Savoy Place, London, UK, 1997.
Farsi M, Ratcliff K and Barbosa M [1999] "An Overview of Controller Area Network",
Computing and Control Engineering Journal, Volume 10, Number 3, IEE, 1999.
Farsi M, Ratcliff K and Barbosa M [1999] "An Introduction to CANopen", Computing
and Control Engineering Journal, Volume 10, Number 4, IEE, 1999.
Gerhard Gruhler [1993] "Bus selection procedure", Aspic Project - Report D2, STA
Rutlingen, Germany, 1993.
Halsall F [1996] "Data Communications, Computer Networks and Open Systems", 4th
Edition, Addison-Wesley, 1996.
Hewlett Packard [1998] "HCPL-7710, HCPL-0710 40ns Propagation Delay, CMOS
Optocoupler, Datasheet", Hewlett Packard, 1998.
Intel [1995] "8x196 Microcontroller Family, Datasheet", Intel, 1995.
ISO7498 [1984] "Information Processing Systems - Open Systems Interconnection -
Basic Reference Model", ISO, 1984.
ISO 11898 [1993] "Road Vehicles, Interchange of Digital Information - Controller Area
Network (CAN) for high-speed Communication", ISO, 1993.
McLaughlin R [1997] "Introduction to CAN", CANopen Workshop, IEE, Savoy Place,
London, UK, 1997.
Monk F [1997] "Producer/Consumer the New Network Paradigm", Fieldcomms UK '97
Conference, Hanover International Hotel, Leicestershire, UK, 1997.
Motorola [1996] "MC68HC05X4, MC68HC705X4 Technical Data, Datasheet",
Motorola, 1996.
Philips [1996] "P8x592 8-bit microcontroller with on-chip CAN, Datasheet", Philips
Semiconductors, 1996.
Philips [1997] "PCA82C250 CAN Controller Interface, Datasheet", Philips, 1997.
Robert Bosch GmbH [1991] "CAN Specification 2.0", Robert Bosch GmbH,
1991.
Ratcliff K and Farsi M [1997] "A low cost configuration tool for CANopen networks",
CAN Newsletter, Department of Electrical & Electronic Engineering, University
of Newcastle upon Tyne, 1997.
Ratcliff K and Farsi M [1997] "Implementation of CANopen on Optimised Control
Motion Controller", Department of Electrical & Electronic Engineering,
University of Newcastle upon Tyne, 1997.
Ratcliff K and Farsi M [1998] "Implementation of CANopen in PCs, Nextmove on
Optimised Control Motion Controllers", Department of Electrical & Electronic
Engineering, University of Newcastle upon Tyne, 1998.
 193

Siemens [1997] "SAE81C90/91 Standalone Full CAN Controller, Datasheet", Siemens,

1997.
Siemens [1997] "SAB 80C167 Microcontroller with Integrated Full CAN, Datasheet",
Siemens, 1997.
Young K, McLaughlin R T and Piggin R S H [1998] "Fieldbus Selection", Proceedings
of FCI98, 1998.
Zeltwanger H [1997] "CAN Communication Model and its Implications", CAN
Solutions Directory, Miller Freeman, CAN in Automation Organisation, Germany,
1997.