IMC05-CAN, Version 2.0: March 2000

Technical Description
Order number: 6AR1943-3AL00-2AA0 March 2000
IMC05-CAN, Version 2.0

Order number: 6AR1403-3AL00-1AA0
Driver Software for CAN Communication with the SICOMP-IMC05 Compact

Computer
SICOMP Industrial Microcomputer

(4)J31069-D2048-U001-A1-7618
IMC05-CAN
Changes in the technical description

Release Overview of Changes Release
1)
Status Date
A0 Initial release 10/97
A1 Expanded functionality 03/00
1) Corresponds to the fourth block of digits of the drawing number in the footer
Notes:
SICOMP® is a registered brand name of Siemens AG.
IBM AT® and IBM PC® are registered brand names of International Business Machines Corp.
INTEL® is a registered brand name of INTEL Corp.
MS-DOS®, Windows® and Windows NT® are registered brand names of Microsoft.
CANAs and PowerCAN are brand names of SiE GmbH
All other designations in this documentation may be brand names whose use by third parties for their own purposes may violate
the rights of the owners.
Passing on and duplication of this document, utilization and revelation of its contents is not permitted without express
permission. Violators will be prosecuted. All rights reserved, particularly in the event a patent is granted or a utility model is
registered.
No liability is assumed with regard to the freedom of third party rights of the circuits, descriptions and tables specified. The
information in the technical descriptions specifies products but not characteristics. The product described in this documentation
may require a license. Ask your Siemens office.
Subject to changes in availability and technology without prior notice. ES43/Ka/WW8.0/VS5.0/A4
©Siemens AG 2000, All Rights Reserved

2 (4)J31069-D2048-U001-A1-7618
IMC05-CAN
Table of Contents
1 Product Overview 5
1.1 Function Overview 5

1.2 Configuration Program - CANsetter 6
1.3 Scope of Delivery 6
2 Installation 7
2.1 CANopen Library 7

2.1.1 System Prerequisites 7
2.1.2 Installation Procedure 7
2.2 Adjustment of the Configuration Program CANsetter 9
2.2.1 System Prerequisites 9
2.2.2 Installation Procedure 9
3 How the Software Functions 10
3.1 The Object Directory 10

3.1.1 Communication-Related Parameters 10
3.1.2 IMC05-Related Parameters 12
3.1.3 Application Variables 13
3.2 Using the Service Programs 14
4 IMC05 in the CAN Network 16
4.1 Configuring the IMC05 as CAN Node 16

4.1.1 Object 1000h: Device Type 17
4.1.2 Object 1001h: Error Register 17
4.1.3 Object 1004h: Number of PDOs Supported 18
4.1.4 Object 1005h: COB-ID of the Synchronization Telegram 19
4.1.5 Object 1006h: Communication Cycle Period 19
4.1.6 Object 1007h: Synchronous Window Length 19
4.1.7 Object 100Bh: Node ID 20
4.1.8 Object 100Fh: Number of SDOs Supported 20
4.1.9 Objects 1200h to 127Fh: Parameter of the Server SDOs 21
4.1.10 Objects 1280h to 12FFh: Parameter of the Client SDOs 22
4.1.11 Objects 1400h to 15FFh: Communication Parameter of the Receiving PDOs 23
4.1.12 Objects 1600h to 17FFh: Mapping Parameter of the Receiving PDOs 24
4.1.13 Objects 1800h to 19FFh: Communication Parameter of the Sending PDOs 26
4.1.14 Objects 1A00h to 1BFFh: Mapping Parameter of the Sending PDOs 27
4.1.15 Object 2000h: Number of Slave Nodes 28
4.1.16 Object 2001h: Transmission Speed 28
4.1.17 Objects 2100h to 21FFh: Parameter of the Slave Nodes 28
4.2 The Interface to the User Software 30
5 Description of the Library Functions 31
5.1 Initializing the CAN Network 31

5.1.1 Initializing the CANopen Driver 31
5.1.2 Initializing Master Node 32
5.1.3 Starting Processing of the Nodes 33

(4)J31069-D2048-U001-A1-7618 3
IMC05-CAN
5.1.4 Setting the Slave Nodes to the Pre-Operational State 34

5.1.5 Resetting Slave Nodes 35
5.1.6 Resetting the Communication Parameters of Slave Nodes 36
5.2 Using the Object Directory (Master) 37
5.2.1 Reading the Entry of the Object Directory 37
5.2.2 Writing an Entry in the Object Directory 38
5.2.3 Fetching the Lower Limit of an Object Directory Entry 39
5.2.4 Fetching the Upper Limit of an Object Directory Entry 40
5.3 PDO Services 41
5.3.1 Saving Events 41
5.3.2 Saving and Immediate Notification 42
5.3.3 Requesting Receiving PDO Via RTR 43
5.3.4 Defining a Receiving Response Message 44
5.3.5 Defining a Sending Response Message 44
5.3.6 Cyclic Sending of PDOs 45
5.4 SDO Services 46
5.4.1 Reading an Entry from the Object Directory of a Slave Node 46
5.4.2 Writing an Entry to the Object Directory of a Slave Node 47
5.4.3 Reading the Object Directory of the Master Node 48
5.4.4 Writing to the Object Directory of the Master Node 48
5.5 Synchronized Events 49
5.5.1 Defining a Synchronized Function Call 49
5.6 Trouble-Shooting 50
5.6.1 Error Flags 50
5.6.2 Defining Error Detection 51
6 Preparing a Configuration with CANsetter and DCFcomp 52
7 Sample Application 54
8 Fundamental CAN Functions 64
8.1 Initializing the CAN Controller 64

8.2 Sending Objects 65
8.3 Sending Remote Objects 66
8.4 Reading Objects 67
8.5 Fetching Received Objects 67
A Bit Timing Recommended by CiA CANopen 68

4 (4)J31069-D2048-U001-A1-7618
IMC05-CAN Product Overview
1 Product Overview
During the last few years CAN has achieved an important position in automation since almost all
automation systems have devices which must communicate with each other. But there was a problem.
Since there was no standard which could be used in controller technology, many system developers
used their own protocols.
The library which we are describing here is an implementation of the "CANopen Communication
Profile for Industrial Applications" which was defined by "CAN in Automation International Users and
Manufacturers Group (CiA e.V.)." This communication profile is based on the CAN Applications Layer
(CAL). It contains the real-time communication model and protocol which all devices in the network
have in common. Device profiles describe device-specific functions.
This description will give you a basic understanding of the characteristics of the CANopen driver. It will
also help you to get started with a CAN application for IMC05. In addition, the individual C functions
will be described in detail.
Remember that this publication cannot possibly describe all unique features and capabilities of the
CAN bus. If you need such information, see the applicable standards of "CAN in Automation e.V." or
CiA for short (e.g., "CANopen Communication Profile DS-301").
1.1 Function Overview
IMC05
Device 1
CANopen library
Object directory
CAN bus
User
CAN driver
software
Device 2
Figure 1.1 Principal layout of a CANopen application with the IMC05
The application is to exchange data with other devices via the CAN bus. Similar to a mailbox, the
object directory is used as the interface. Data which were sent by other bus stations can be received
and stored for the application in defined application objects (variables) of the object directory. This
information can also be requested specifically from other network nodes.
In reverse, various user data of the object directory can be made available to the other devices. This
can be done either automatically (i.e., cyclically at certain time intervals) or on request.

(4)J31069-D2048-U001-A1-7618 5
Product Overview IMC05-CAN
The CAN driver handles the complete data communication with the CANopen protocol using the
communication parameters in the object directory. In addition, the IMC05 is the NMT master (NMT =
network management) and is thus responsible for booting, monitoring, and synchronization of the
NMT slaves.
1.2 Configuration Program - CANsetter

If you want to use the library functions without additional service programs, you will have to adjust the
1)
OBJDICT.C file to your application with an editor. However, the CANsetter service program offers
you a convenient way to make the entries in the object directory for the CANopen nodes of the IMC05.
An electronic data sheet (EDS) with all standard settings of the IMC05 is used to add the variables,
process data objects (PDOs) and service data objects (SDOs) for your application and set the
standard values to those required by your application.
CANsetter then generates a device configuration file (DCF) (i.e., a complete and configured ASCII file
from the original EDS).
The DCFcomp service program then takes the information of the NAME.DCF device configuration file
and generates two files.
· A binary file - NAME.BIN - with all information of the object directory for loading to the flash
memory of the IMC05
· A header file - NAME.H - for linking the names from the object list to your application
If some entries in the object directory have to be changed later, you only have to load the new binary
file to the IMC05 afterwards and not the complete application.
1.3 Scope of Delivery

· 1 driver floppy disk (IMC05-CAN V2.0 library)
· 1 floppy disk for adaptation of CANsetter (IMC05-CAN V2.0 Tools)
· Technical Description, English
1)
For example, from Vector Informatik GmbH in Stuttgart

6 (4)J31069-D2048-U001-A1-7618
IMC05-CAN Installation
2 Installation
2.1 CANopen Library
2.1.1 System Prerequisites
Software requirements on the development computer

· RMOS3 V3.20
· IMC05-BSP
The following CADUL tools are required for program development and system generation.
· Compiler: Organon CC386, starting with V611 G
· Linker: Organon LINK386, starting with V181
· Assembler: Organon AS386, starting with V278
· Debugger: Organon XDB, starting with V250 F (not absolutely necessary)
Note:
A basic knowledge of RMOS is required for system generation using this description. Siemens offers
training programs. For details, contact your Siemens office.
2.1.2 Installation Procedure

1. Start your development computer.
2. Make a backup copy of the product floppy disk. For example, you can use the command
diskcopy in the MS-DOS prompt. Store the original floppy disk in a safe place.
3. If not already done, install RMOS V3.20.
4. If not already done, install IMC05-BSP.
5. Place the copy of the product floppy disk in the floppy disk drive, and execute INSTALL.EXE from
the floppy disk.
6. Follow the instructions which appear on your monitor screen.

(4)J31069-D2048-U001-A1-7618 7
Installation IMC05-CAN
Installed files
During installation, a subdirectory \SYSIMC5\CAN is set up in the RMOS directory with the following
files.
File Name Meaning

CANIMC05.LIB Library file with the basic CAN functions and the CANopen
operations
CANOPN05.H Header file for linking in the CANopen functions
OBJDICT.C File for definition of the object directory
BCAN05.H Header file for linking in the basic CAN functions
Do not use together with CANOPN05.H and OBJDICT.C!
In addition, an APLCAN directory is set up. It contains a sample application for CAN and CANopen.
For more details, see the readme file READCAN.2P0.
System generation
You will need CANIMC05.LIB, OBJDICT.C and CANOPN05.H for the normal functions of CANopen. If
you only need the fundamental CAN functions, use CANIMC05.LIB and BCAN05.H.
1. Enter the following lines in the RMOS builder file RM3E_EX.BLD.
...
VGA_IOSEG
(
BASE=00900000h,
LIMIT=0ffffh
),
CANCONTR_SEG
(
BASE=00910000h,
LIMIT=07fffh
),
PERIPH_SEG
(
BASE=00920000h,
LIMIT=07fffh
),
2. Adjust the generation file (e.g., GENSYSC.BAT) to link in CANIMC05.LIB and OBJDICT.C.

8 (4)J31069-D2048-U001-A1-7618
IMC05-CAN Installation
2.2 Adjustment of the Configuration Program CANsetter
2.2.1 System Prerequisites
Software requirements on the development computer
CANsetter must have already been installed. For more details, see manufacturer's information.
2.2.2 Installation Procedure

1. Make a backup copy of the product floppy disk. For example, you can use the command
diskcopy in the MS-DOS prompt. Store the original floppy disk in a safe place.
2. Place the copy of the product floppy disk in the floppy disk drive, and execute INSTALL.EXE from
the floppy disk.
3. Follow the instructions which appear on your monitor screen.
4. Copy the file CANDRV.INI from the floppy disk to the Windows directory, and replace the file with
the same name there.
Installed files
During installation, the following files are set up or replaced in the CANsetter installation directory
(e.g., \CANSET).
Path and File Name Meaning

EDS\IMC05.EDS Electronic data sheet of IMC05 with the features and standard
settings for an IMC05 CAN node
EDS\IMC05.BMP Icon for identifying an IMC05 on the CANsetter desktop
EXEC\DCFCOMP.EXE Service program DCFcomp. See chapter 6.
CANDRV\SIECAN.DLL Driver library for the PC cards CANAs and PowerCAN
CANDRV\DVINSTAL.INI Update of the CANsetter driver list. Contains SIECAN.DLL.
Setting the CAN card
There are two ways to set the CAN driver on the development computer to the CAN card which you
are using.
· Start the CAN driver from the CANsetter program group. Select the driver for the CAN card
(CANAs or PowerCAN), and then perform the rest of the installation.
Or
· Using a text editor, open the file CANDRV.INI from the Windows directory, and enter the CAN
card (CANAs or PowerCAN) and the related input/output address in the section [SiECAN]. An
example is shown below.
[SiECAN]
CardType=PowerCAN
IOAddress=0x300
...

(4)J31069-D2048-U001-A1-7618 9
How the Software Functions IMC05-CAN
3 How the Software Functions

3.1 The Object Directory
The object directory contains a table of all information required for the device and network
configuration (similar to the device configuration file). The object directory of the IMC05 is divided into
the following parameter areas.
Parameter Area Index Contents

Communication-related 1000h to 1FFFh · Number and type of PDOs
parameters · Number and type of SDOs
· Communication cycle period
· Synchronization telegram
· Own node ID
· Linking of the receiving and sending PDOs to user
variables (mapping)
IMC05-related parameters 2000h to 5FFFh · Baud rate of the network
· Number and characteristics of all connected CAN
devices (slave nodes)
User variables Starting with 6000h Any user-related data. Examples:
· Switching states of digital and analog inputs or
outputs
· Engine speed, torque
3.1.1 Communication-Related Parameters
As the name indicates, the communication-related section contains parameters required to exchange
data with other devices.
Process data objects (PDOs) are defined which are used for communication with real-time data. A
PDO is a CAN telegram which has an identifier. This identifier and the desired type of transmission are
set here just as are the application objects which are to be sent or received as user data (max. of 8
bytes) with the PDO. This assignment is called mapping. See chapter 4.1.12.

10 (4)J31069-D2048-U001-A1-7618
IMC05-CAN How the Software Functions
The following table shows the types of transmission for a receiving or sending PDO.
Type of Transmission Description Remarks

0 Non-cyclic, synchronous
1 to 240 Cyclic, synchronous Cycle time = communication cycle period x (number of
synchronization telegrams between two PDO
transmissions)
241 to 251 Reserved
252 Synchronous, on RTR
request
253 Asynchronous, on RTR
request
254 Asynchronous For manufacturer-related event
255 Asynchronous For device-related event
The following figure illustrates the meaning of the transmission type and the "communication cycle
period" and "synchronous window length" parameters. The standard identifier for the synchronization
telegram (no data bytes) is 80h.
Communication Cycle Period Synchronous Window Length
SYNC SYNC SYNC SYNC Time
Explanation
SYNC Synchronization telegram
Synchronous, cyclic PDO (transmission type 2)
Synchronous, non-cyclic PDO (transmission type 0)
Asynchronous PDO (transmission type 245 or 255)
Figure 3.1 Use of PDOs with different transmission types
In addition to the PDOs, service data objects (SDOs) are also provided for the communication service.
They are confirmed. This means that, when SDOs are used, a response is always expected as to
success or failure of the service. If confirmation is not received within a certain period of time, the
SDO service is also not successful. Since there is always some dead time while waiting for
acknowledgments, SDOs are much slower than PDOs. For this reason, SDOs are usually used to
configure parameters of other network stations in the state "pre-operational." For the node which
begins the SDO service, this is a client SDO. For the others, this is a so-called server SDO.

(4)J31069-D2048-U001-A1-7618 11
The data to be transferred are not specified by mapping and may vary. The other station is specified
by its node ID for each SDO (point-to-point connection). In addition, a sending and a receiving
identifier must be established for each client or server SDO.
3.1.2 IMC05-Related Parameters
The manufacturer-related portion of the object directory is used to enter information on the
configuration of the network.
This information includes the transmission speed to be used and the number and characteristics of the
other devices in the network. All nodes are entered in a list here with their node IDs. In addition, it is
specified whether the minimum or the extended bootup is to be used for them as NMT slaves when
the IMC05 starts. In extended bootup, additional parameters (e.g., for node guarding) are specified.
With either type of bootup, either the preset values for the identifiers of the device PDOs (calculated
with the node ID) must be used or the identifiers must be set by SDOs before the start of the network
in the "pre-operational" state.
The IMC05 guards every device in the node list if this was specified during the start. This means that
the IMC05 sends a request telegram at certain time intervals (guard time) to the node and this node
must respond. If not, a guard error is triggered. In reverse, if the IMC05 fails to send a request
telegram within a certain time interval (guard time x lifetime factor), the node itself switches to the
"disconnected" state.
Caution
The guard time must be greater than the communication cycle period!

12 (4)J31069-D2048-U001-A1-7618
3.1.3 Application Variables
The application-related section of the object directory contains the actual process variables which the
application provides to other devices via the CAN bus or vice versa.
Only those data are transported via the CAN bus which are specified in the communication
parameters of the PDOs (mapping).
The IMC05 is a programmable device. It differs from "less complex" CAN nodes (e.g., input/output
modules) in that the required CANopen application variables cannot be specified from the outset (e.g.,
in a device profile). The various applications of the IMC05 as a CANopen device may have very
different constellations. This is why the IMC05 supports dynamic {variable} objects.
In principle, the application objects in the object directory can be defined as desired starting with index
6000h. However, for clarity's sake, we recommend combining these into type sectors (entered in an
array).
The following arrays are predefined for the IMC05 (based on CiA DS405 for programmable devices).
1) 1)
Start Index Input Array Access Start Index Output Array Access
A000h Integer8 ro A480h Integer8 rww
A040h Unsigned8 ro A4C0h Unsigned8 rww
A080h Boolean ro A500h Boolean rww
A0C0h Integer16 ro A540h Integer16 rww
A100h Unsigned16 ro A580h Unsigned16 rww
A1C0h Integer32 ro A640h Integer32 rww
A200h Unsigned32 ro A680h Unsigned32 rww
A240h Float (32) ro A6C0h Float (32) rww
1) ro = Read only
rww = Read and write, only write with PDOs
256 variables can be used for each array (subindex 0 to 255). If this is not sufficient, an additional
array of this type can be set up in the next index.
Note:
To avoid wasting the resources of the IMC05 unnecessarily, define only those objects (also PDOs
and SDOs) in the object directory which you actually need.

(4)J31069-D2048-U001-A1-7618 13
3.2 Using the Service Programs
IMC05
Boot flash
03FF FFFF RS232
Boot loader program
03FE 0000 Development PC

User flash Windows 95 / 98
005F FFFF
CAN config. data Download FlashCAN
CAN standard data CAN fn Init()

DcfComp
System application BIN file for download
0040 0000
H file for application
RAM
000F FFFF
CANsetter
HEAP: DCF
SDOs Configuration file
Global CAN data SD
PDOs Os IMC05.EDS -
electronic
0000 0000 CAN bus data sheet
Figure 3.2 Principle of creating the CAN configuration for IMC05
To configure the IMC05 without any additional service programs, the entries of the object directory
must be defined for the desired configuration in the file OBJDICT.C
Note:
When making the entries, make absolutely sure that the sequence of index and subindex is correct.
When the system is generated, these object directory data are compiled and then made available as
the standard configuration after being loaded to the flash memory of the IMC05.
When the CANopen driver is initialized with the function CAN_fn_Init, all required objects and lists are
created dynamically in heap memory.

14 (4)J31069-D2048-U001-A1-7618
The CANsetter service program makes it much easier to configure the IMC05 as a CANopen network
node.
CANsetter uses an electronic data sheet (EDS) as the starting point of additional processing. All
general properties of the IMC05 CANopen node are specified here. These characteristics can be used
later as the framework for all special configurations.
The required application objects, PDOs and SDOs can be supplemented in the object directory with
CANsetter. In addition, the various values of the parameters can be set for the desired configuration.
Since several network nodes can be processed at the same time, you can coordinate the identifiers of
the PDO or SDO connections, for example. After all settings have been made, CANsetter generates a
device configuration file (.DCF = Device Configuration File).
The included service program DCFcomp creates a binary file and a header file from this file. The
header file can be integrated in the system application to permit access to the entries in the object
directory under their names. The binary file with the configuration data is loaded to the user flash
memory of the IMC05 where it replaces the standard configuration. When the CAN_fn_Init function
initializes the CANopen driver, the new configuration is used as the basis for the dynamic generation
of the objects and lists. This makes it easy to change the data of the CANopen configuration since the
complete system application doesn't have to be loaded to the IMC05 every time.
In addition, CANsetter can be used to read entries from the object directories on the IMC05 with SDO
accesses via the CAN bus and change them for testing purposes. After the system is restarted, the
configuration stored in the flash memory is used again.

(4)J31069-D2048-U001-A1-7618 15
IMC05 in the CAN Network IMC05-CAN
4 IMC05 in the CAN Network

4.1 Configuring the IMC05 as CAN Node
The desired configuration is obtained by making a series of entries in the object directory. Cf.
chapter 3.1.
Table 4.1 Layout of the object directory
1)
Index Object Meaning Data Type Access M/O
Type
1000h VAR Device type Unsigned32 ro M
1001h VAR Error register Unsigned8 ro M
1004h ARRAY Number of PDOs supported Unsigned32 ro O
1005h VAR COB-ID of the synchronization telegram Unsigned32 rw O
1006h VAR Communication cycle period Unsigned32 rw O
1007h VAR Synchronous window length Unsigned32 rw O
100Bh VAR Node ID Unsigned32 ro O
100Fh VAR Number of SDOs supported Unsigned32 ro O
1200h RECORD Parameter of the first server SDO SDOParameter ro O
... Parameter of other server SDOs (max. rw O
of 128)
1280h RECORD Parameter of the first client SDO SDOParameter rw O
... Parameter of other client SDOs (max. of rw O
128)
1400h RECORD Communication parameter of the first PDOCommPar rw O
receiving PDO
... Communication parameter of additional
receiving PDOs (max. of 512)
1600h ARRAY Mapping parameter of the first receiving PDOMapping rw O
PDO
... Mapping parameter of additional
receiving PDOs (max. of 512)
1800h RECORD Communication parameter of the first PDOCommPar rw O
sending PDO
... Communication parameter of additional
sending PDOs (max. of 512)
1A00h ARRAY Mapping parameter of the first sending PDOMapping rw O
PDO
... Mapping parameter of additional
sending PDOs (max. of 512)
2000h VAR Number of slave nodes Unsigned8 rw M
2001h VAR Transmission speed Unsigned16 rw M
2100h RECORD Parameter of the first slave node NodeParameter rw O
... Parameter of additional slave nodes
(max. of 255)
1) ro = Read only
rw = Read and write
The individual objects will now be described in detail.

16 (4)J31069-D2048-U001-A1-7618
IMC05-CAN IMC05 in the CAN Network
4.1.1 Object 1000h: Device Type
This object describes the type of device to be configured and thus its functionality. The IMC05
complies with CiA DS405 for programmable devices.
Object type VAR (variable)
Data type Unsigned32
Access ro (read only)
Mandatory Yes
Format MSB LSB
Expanded information (16 bits) Device profile number (16 bits)
Value 405h
4.1.2 Object 1001h: Error Register
This object can be used to indicate internal errors of the device. The functions of the CANopen library
use the CAN_by_ErrorFlags variable internally.
Data type Unsigned8
Mandatory Yes
Value range 0: No error

1: General error
Standard value 0

(4)J31069-D2048-U001-A1-7618 17
4.1.3 Object 1004h: Number of PDOs Supported
This object contains information on the number of PDOs used. A distinction is made between sending
and receiving PDOs and between synchronous and asynchronous PDOs. See chapter 3.1.1.
Object type ARRAY
Number of elements 3
Mandatory No (optional)
Subindex 0: Number of PDOs used
Format MSB LSB
Number of receiving PDOs (16 bits) Number of sending PDOs (16 bits)
Value range 0 to 01FF01FFh
Standard value 0
Subindex 1: Number of synchronous PDOs
Format MSB LSB
Number of synchronous receiving Number of synchronous sending

PDOs (16 bits) PDOs (16 bits)
Value range 0 to 01FF01FFh
Standard value 0
Subindex 2: Number of asynchronous PDOs
Format MSB LSB
Number of asynchronous receiving Number of asynchronous sending

PDOs (16 bits) PDOs (16 bits)
Value range 0 to 01FF 01FFh
Standard value 0

18 (4)J31069-D2048-U001-A1-7618
4.1.4 Object 1005h: COB-ID of the Synchronization Telegram
This object specifies the identifier of the synchronization telegram and states whether the device
generates the synchronization telegram itself or only uses received synchronization telegrams. The
IMC05 generates the synchronization telegram itself.
Access rw (read and write)
Format MSB LSB
0100 0000 0000 0000 0000 0 Identifier (bits 0 to 10)
Standard value 4000 0080h
4.1.5 Object 1006h: Communication Cycle Period
This object specifies the communication cycle period in microseconds. See chapter 3.1.1.
Value range ³ 1000 (1 msec)
Standard value 100 000 (100 msec)
4.1.6 Object 1007h: Synchronous Window Length
This object specifies the synchronous window length in microseconds. See chapter 3.1.1.
Value range ³ 1000 (1 msec)
Standard value 50 000 (50 msec)

(4)J31069-D2048-U001-A1-7618 19
4.1.7 Object 100Bh: Node ID
This object contains the own node ID of the IMC05 in the CAN network.
Format MSB LSB
0 (reserved) 0 (reserved) 0 (reserved) Node ID
Standard value 1
4.1.8 Object 100Fh: Number of SDOs Supported
This object contains information on the number of SDOs used. A distinction is made between server
and client SDOs (see chapter 3.1.1). The first server SDO must always be present.
Format MSB LSB
Number of client SDOs (16 bits) Number of server SDOs (16 bits)
Value range 0 to 80h (client SDOs), 1 to 80h (server SDOs)
Standard value 1

20 (4)J31069-D2048-U001-A1-7618
4.1.9 Objects 1200h to 127Fh: Parameter of the Server SDOs
These objects contain the parameters of those SDOs for which the IMC05 is the server. The first
server SDO (index 1200h) must be present as the standard SDO. All other server SDOs are optional.
Object type RECORD
Data type SDOPar
Subindex 0: Number of entries
Data type Unsigned8
Value 3
Subindex 1: COB-ID client à server (receiving)
Access Index 1200h: ro (read only)

Index 1201h to 127Fh: rw (read and write)
Value Index 1200h: 600h + node ID

Index 1201h to 127Fh: None
Subindex 2: COB-ID server à client (sending)


Subindex 3: Node ID of the SDO client
Data type Unsigned8

Value Index 1200h: 0


(4)J31069-D2048-U001-A1-7618 21
4.1.10 Objects 1280h to 12FFh: Parameter of the Client SDOs
These objects contain the parameters of those SDOs for which the IMC05 is the client.
Object type RECORD
Data type SDOPar
Data type Unsigned8
Value 3
Subindex 1: COB-ID client à server (sending)
Value 600h + server node ID (standard SDO of the server)
Subindex 2: COB-ID server à client (receiving)
Value 580h + server node ID (standard SDO of the server)
Subindex 3: Node ID of the SDO server
Data type Unsigned8

22 (4)J31069-D2048-U001-A1-7618
4.1.11 Objects 1400h to 15FFh: Communication Parameter of the

Receiving PDOs
These objects contain the communication parameters of those PDOs which the IMC05 is to receive.
Object type RECORD
Data type PDOCommPar
Data type Unsigned8
Value 4
Subindex 1: COB-ID of the PDO

Index 1401h: 300h + node ID
Index 1402h to 15FFh: None
Subindex 2: Type of transmission
Data type Unsigned8
Value See chapter 1.2.1.
Subindex 3: Inhibit time
Value 0 (not used)

(4)J31069-D2048-U001-A1-7618 23
Subindex 4: Priority group
Data type Unsigned8
Value 0 (not used)
4.1.12 Objects 1600h to 17FFh: Mapping Parameter of the Receiving

PDOs
These objects specify the mapping of the receiving PDOs (i.e., determine which application objects
will be received with the PDO of the IMC05). The maximum 64 data bits (8 bytes) of a PDO are
distributed on receipt to the application objects assigned here.
Object type RECORD
Number of elements 2 to 65
Data type PDOMapping
Subindex 0: Number of application objects transferred
Value range 1 to 64
Subindices 1 to 64: Mapping of the application objects
Format MSB LSB
Index (16 bits) Subindex (8 bits) Object length in

bits (8 bits)

24 (4)J31069-D2048-U001-A1-7618
Example of mapping the application objects
PDO Mapping Object Directory

Subindex 0: 3 Index Subindex Name
Subindex 1: 6062 0008h ... ... ...
Subindex 2: 6093 0210h 6038h 00h Application object 1
Subindex 3: 6038 0008h ... ... ...
6062h 00h Application object 2
... ... ...
Figure 4.1 Example of mapping the application objects
The following distribution to the application objects applies to the corresponding receiving PDO.
PDO
Byte 0 Bytes 1 and 2 Byte 3
Object Directory
Index Subindex Name
... ... ...
... ... ...
... ... ...
Figure 4.2 Example of the distribution of data in the receiving PDO

(4)J31069-D2048-U001-A1-7618 25
4.1.13 Objects 1800h to 19FFh: Communication Parameter of the Sending

PDOs
These objects contain the communication parameters of those PDOs which the IMC05 is to send.
Object type RECORD
Data type PDOCommPar
Data type Unsigned8
Value 4
Subindex 1: COB-ID of the PDO

Index 1801h: 280h + node ID
Index 1802h to 19FFh: None
Subindex 2: Type of transmission
Data type Unsigned8
Value See chapter 3.1.1.
Subindex 3: Inhibit time
Value 0 (not used)

26 (4)J31069-D2048-U001-A1-7618
Subindex 4: Priority group
Data type Unsigned8
Value 0 (not used)
4.1.14 Objects 1A00h to 1BFFh: Mapping Parameter of the Sending PDOs
These objects specify the mapping of the sending PDOs (i.e., determine which application objects will
be sent with the PDO of the IMC05). During sending, the maximum 64 data bits (8 bytes) of a PDO are
filled with the application objects assigned here. Cf. example in chapter 4.1.12.
Object type RECORD
Number of elements 1 to 64
Data type PDOMapping
Subindex 0: Number of application objects transferred
Value range 1 to 64
Subindices 1 to 64: Mapping of the application objects
Format MSB LSB
Index (16 bits) Subindex (8 bits) Object length in

bits (8 bits)

(4)J31069-D2048-U001-A1-7618 27
4.1.15 Object 2000h: Number of Slave Nodes
This object specifies the number of existing slave nodes. When this value is changed, the CANopen
driver must be initialized again.
The parameters of the network nodes listed here are specified by indices 2100h to 21FFh.
Data type Unsigned8
Mandatory Yes
Value range 0 to 255
Standard value 0
4.1.16 Object 2001h: Transmission Speed
This object specifies the transmission speed which the IMC05 is to use. The speed must be the same
value for all nodes in the CAN network. When this value is changed, the master node must be
initialized again.
Mandatory Yes
Value range 1000: 1 Mbit/sec

800: 800 kbit/sec
500: 500 kbit/sec
250: 250 kbit/sec
125: 125 kbit/sec
50: 50 kbit/sec
20: 20 kbit/sec
10: 10 kbit/sec
Standard value 1000 (1 Mbit/sec)
4.1.17 Objects 2100h to 21FFh: Parameter of the Slave Nodes
The parameters of the slave nodes in the network are set in these objects. The number of indices is
the value in object 2000h. When one of these values is changed, the CANopen driver must be
initialized again.

28 (4)J31069-D2048-U001-A1-7618
Object type RECORD
Data type NodeParameter
Data type Unsigned8
Value range 4
Subindex 1: Node ID
Data type Unsigned8
Value range 1 to 255 (1 to 127 for preset COB-IDs)
Subindex 2: Extended bootup
Data type Unsigned8
Value range 0: Minimum bootup

1: Extended bootup (when node guarding is used)
Subindex 3: Load the configuration
Data type Unsigned8
Value range 0 (not used)
Subindex 4: Node ID of the emergency telegram
Value range 80h + node ID

(4)J31069-D2048-U001-A1-7618 29
4.2 The Interface to the User Software

While SDOs and PDOs are used to access data in the object directory on the CAN bus side, the user
can read or write data via the interface of the C library on the IMC05 side. In addition, the library
provides all functions required for initialization, configuration and operating the CANopen network, as
well are for communication. For a detailed description of these functions, see chapter 5.
When the header file generated by the service program DCFcomp is linked to the C program of the
application, the entries in the object directory can also be addressed by name and not only by index
and subindex.
DCFcomp uses the names which are specified in the device configuration file (.DCF). For arrays,
records and structures, the field name of the variables is added to the name of the structure and
separated by an "_." Blanks are also replaced by an underline.
Some examples are listed below.

Table 4.2
Index Subindex Object Name Data Type Access M/O
Type
2000h 0 VAR number_of_slave_nodes Unsigned8 rw M
2001h 0 VAR baudrate Unsigned16 rw M
6100h 0 ARRAY WeidmuellerDO8 Unsigned8 ro O
1 ARRAY modul1 Unsigned8 rw O
...
CAN_fn_ReadObjectDict(baudrate, &dw_Baudrate);
CAN_fn_ReadObjectDict(number_of_slave_nodes, &dw_Data);
CAN_fn_WriteObjectDict(WeidmuellerDO8_modul1, 0xAA);
CAN_fn_WriteObjectDict(WeidmuellerDO8_modul2, 0x55);
Notes:
The general rules of ANSI-C apply to names (e.g., special characters are not permitted and only the
first 31 characters of the name are used). Longer names (e.g., for structures with field name) will
cause problems.
To obtain good code, use short, unique names.
DCFcomp doesn't check to determine whether the same name exists more than once.

30 (4)J31069-D2048-U001-A1-7618
IMC05-CAN Description of the Library Functions
5 Description of the Library Functions

This library contains the software required for the communication with OSI layer 7 which is defined in
the CANopen communication profile DS 301 regarding use of CAN as the installation bus. It provides
a way to configure and transmit real-time data and also supplies a routine for synchronizing devices.
The IMC05 is an NMT and synchronous master node. The identifiers are assigned when the device
and network configuration is generated.
5.1 Initializing the CAN Network
5.1.1 Initializing the CANopen Driver
Syntax int CAN_fn_Init(unsigned char by_TaskPriority)
Parameters Parameter Name Meaning

By_TaskPriority Priority of the cyclic communication task
Recommended value: 250
Return value 1: Function executed successfully

0: Initialization not possible
Description This function initializes the communication task with the specified priority. The
function must be called before you can use the CANopen driver.
Example #include <imc05bas.h>

#include "canopen05.h"
void testinitfunction (void)

{
if (CAN_fn_Init(250) == 0)
{
bg_outtext ("Initialisation not possible!");
return;
}
if (CAN_fn_CreateNode() == 0)
{
bg_outtext ("Cannot enter state preoperational!");
}
}

(4)J31069-D2048-U001-A1-7618 31
Description of the Library Functions IMC05-CAN
5.1.2 Initializing Master Node
Syntax int CAN_fn_CreateNode(void)

0: Initialization not possible
Description This function performs the basic initialization of the node. This gives you the
pre-operational state.
Only communication via SDOs is possible in this state. The standard COB-IDs
derived from the node IDs are used for this.
Configuration of device parameters and PDOs and assignment of application

objects (PDO mapping) are possible when performed by the particular device.
Example See chapter 5.1.1.

32 (4)J31069-D2048-U001-A1-7618
5.1.3 Starting Processing of the Nodes
Syntax int CAN_fn_StartNodes(void)
Return value 1: Nodes are started.

Other: Error code
Description The NMT master uses this function to make all nodes sign themselves off,
perform their additional local initialization (based on the configuration
parameters) and then sign themselves on again.
Afterwards, all nodes in the network are identified, the parameters for node
guarding are set, and node guarding is started.
Finally, synchronization is started by cyclically sending the synchronization

telegram. All nodes assume the "operational" state. Communication can now
also be performed via PDOs.
If a device doesn't support the expanded network initialization, the minimum

bootup is performed instead.

void testfunction (void)

{
if (CAN_fn_StartNodes() == 1)
{
bg_outtext ("Network is operational");
}
else
{
bg_outtext ("Network is not operational");
}
}

(4)J31069-D2048-U001-A1-7618 33
5.1.4 Setting the Slave Nodes to the Pre-Operational State
Syntax int CAN_fn_EnterPreoperationalState(unsigned char NodeID)

NodeID Node ID (0 to 255)
0: All nodes in the network

0: Function not possible
Description The NMT master uses this function to force one slave node or all slave nodes
in the network to assume the pre-operational state. Afterwards, PDOs can be
disabled or the configuration can be modified with SDOs.
If the own node ID is specified or all nodes are addressed, the master is also
set to the pre-operational state.


{
if (CAN_fn_EnterPreoperationalState(255) == 1)
{
bg_outtext ("All nodes put to preoperational");
}
}

34 (4)J31069-D2048-U001-A1-7618
5.1.5 Resetting Slave Nodes
Syntax int CAN_fn_ResetNode(unsigned char NodeID)


Description The NMT master uses this function to force the complete resetting of one
slave node or all slave nodes in the network. The application of the node and
the parameters of the entire object directory are set to the power-on values.
The node then assumes the pre-operational state.
If the own node ID is specified or all nodes are addressed, the master is also
reset.


{
if (CAN_fn_ResetNode(2) == 1)
{
bg_outtext ("Reset of node 2 is done");
}
}

(4)J31069-D2048-U001-A1-7618 35
5.1.6 Resetting the Communication Parameters of Slave Nodes
Syntax int CAN_fn_ResetCommunication(unsigned char NodeID)


Description The NMT master uses this function to force the communication parameters in
the object directory of a slave node or all slave nodes in the network to be
reset to the power-on values. The node then assumes the pre-operational
state.


{
if (CAN_fn_ResetCommunication(12) == 1)
{
bg_outtext ("Communication parameters of node 12
have been reset");
}
}

36 (4)J31069-D2048-U001-A1-7618
5.2 Using the Object Directory (Master)
5.2.1 Reading the Entry of the Object Directory
Syntax int CAN_fn_ReadObjectDict(unsigned long Entry,

unsigned long *Data)

Entry Entry of the object directory:
Bits 0 to 8: Subindex of the entry
Bits 9 to 24: Index of the entry
Example:
Entry = 140002h ® Index = 1400h
Subindex = 02h
Data Pointer to a variable for returning the entry

0: Entry not available
–1: Entry has "write only" attribute.
–2: Illegal data type
Description This function reads an entry from the object directory if this entry exists and if
a read access is permitted. The read value is returned in the specified
variables.


{
unsigned long dw_Data;
if (CAN_fn_ReadObjectDict(0x609400, &dw_Data) != 1)
{
bg_outtext ("Not possible to read from!");
return;
}
dw_Data &= 0xFFFF; /* variable is Unsigned16 */
dw_Data += 16;
CAN_fn_WriteObjectDict(0x609400, dw_Data);
}
The entry for this variable must be defined in the object directory
(OBJDICT.C). See CANopen communication profile DS-301. For example:
/*Entry |Obj.|DataTyp|Low|High|Deflt|Acc.|Mapp*/
{0x609400, 0x7, 0x0006, 10, 230, 0x1F, rw, 1},

(4)J31069-D2048-U001-A1-7618 37
5.2.2 Writing an Entry in the Object Directory
Syntax int CAN_fn_WriteObjectDict(unsigned long Entry,

unsigned long Data)

Data Data to be written

–1: Entry has "read only" attribute.
–2: Illegal data type
Description This function writes data to an entry of the object directory if this entry exists
and if a write access is permitted.
Example See chapter 5.2.1.

38 (4)J31069-D2048-U001-A1-7618
5.2.3 Fetching the Lower Limit of an Object Directory Entry
Syntax unsigned long CAN_fn_GetLowLimit(unsigned long Entry)

Return value 0: No lower limit available

Other: Lower limit of the object directory parameter
Description This function returns the lower limit for an entry of the object directory if this is
defined in the device configuration file.
It is the user's responsibility to ensure that the limit values are adhered to.
Example #include "canopen05.h"

{
unsigned short w_Variable;
unsigned long dw_Limit;
CAN_fn_ReadObjectDict(0x609400, &dw_Data);
dw_Limit = CAN_fn_GetLowLimit(0x609400);
if (dw_Data < dw_Limit)
{
w_Variable = dw_Limit;
CAN_fn_WriteObjectDict(0x609400, dw_Limit);
}
else
{
w_Variable = dw_Data;
}
}

(4)J31069-D2048-U001-A1-7618 39
5.2.4 Fetching the Upper Limit of an Object Directory Entry
Syntax unsigned long CAN_fn_GetHighLimit(unsigned long Entry)

Return value 0: No upper limit available

Other: Upper limit of the object directory parameter
Description This function returns the upper limit for an entry in the object directory if this is
defined in the device configuration file.
It is the user's responsibility to ensure that the limit values are adhered to.
Example #include "canopen05.h"

{
unsigned short w_Variable;
unsigned long dw_Limit;
CAN_fn_ReadObjectDict(0x609400, &dw_Data);
dw_Limit = CAN_fn_GetHighLimit(0x609400);
if (dw_Data > dw_Limit)
{
w_Variable = dw_Limit;
CAN_fn_WriteObjectDict(0x609400, dw_Limit);
}
else
{
w_Variable = dw_Data;
}
}

40 (4)J31069-D2048-U001-A1-7618
5.3 PDO Services
5.3.1 Saving Events
Syntax int CAN_fn_PDOStoreReq(unsigned int TPDO_Nr)

TPDO_Nr Number of the sending PDO (1 to 1FFh)

Description This function saves the application objects of a sending PDO which are
defined in its mapping parameters. Other nodes (clients) can then request to
read this PDO.
When the function is executed for a sending PDO which is already stored, this
is overwritten with the new data.
Note:
Only nine PDOs can be stored at the same time. When a tenth PDO is
saved, this overwrites the PDO which was stored first.


{
if (CAN_fn_PDOStoreReq(2) == 1)
{
bg_outtext ("Transmit PDO 2 is stored and
transmission may be requested by other nodes");
}
}

(4)J31069-D2048-U001-A1-7618 41
5.3.2 Saving and Immediate Notification
Syntax int CAN_fn_PDONotifyReq(unsigned int TPDO_Nr)


Description This function saves all application objects of a sending PDO which are defined
in its mapping parameters. The object is then reported to all other nodes
(clients) with synchronous or asynchronous transmission (depending on how
the transmission type is set).


{
if (CAN_fn_PDONotifyReq(1) == 1)
{
bg_outtext ("PDO 1 has been transmitted");
}
}

42 (4)J31069-D2048-U001-A1-7618
5.3.3 Requesting Receiving PDO Via RTR
Syntax int CAN_fn_PDOReadReq(unsigned int RPDO_Nr)

RPDO_Nr Number of the receiving PDO (1 to 1FFh)

Description This function requests a PDO from its server (asynchronous transmission).
The received data are entered in the application objects which are defined in
the mapping parameters of the receiving PDO.


{
if (CAN_fn_PDOReadReq(2) == 1)
{
bg_outtext ("Read of receive PDO 2 has been
requested to the other nodes");
}
}

(4)J31069-D2048-U001-A1-7618 43
5.3.4 Defining a Receiving Response Message
Syntax int CAN_fn_PDODefRecvInd(unsigned int RPDO_Nr,

void far (*ptr_IndFkt)(void) )

RPDO_Nr Number of the receiving PDO (1 to 1FFh)
ptr_IndFkt Pointer to the desired callback function

Description This function is used to set a callback function for a receiving PDO. This is
called when the specified PDO is received (i.e., in the following situations).
· The CAN_fn_PDONotifyReq function was executed on the server of the
PDO.
· The PDO was sent cyclically.
· The client itself had executed the CAN_fn_PDOReadReq function before.
The standard setting here is a NULL pointer.
Note:
The callback function should be kept as short as possible.


{
if (CAN_fn_PDODefRecvInd(1, fn_ReceivedPdo1) == 1)
{
bg_outtext ("Reception of RPDO 1 will be
indicated");
}
}
void far fn_ReceivedPdo1(void)

{
static unsigned long dw_Counter;
dw_Counter++;
}
5.3.5 Defining a Sending Response Message
Syntax int CAN_fn_PDODefTransInd(unsigned int TPDO_Nr,

void far (*ptr_IndFkt)(void) )

44 (4)J31069-D2048-U001-A1-7618

ptr_IndFkt Pointer to the desired callback function

Description This function is used to set a callback function for a sending PDO. This is
called when the PDO is sent because it was requested by a client with the
CAN_PDOReadReq function.
Note:
The callback function should be kept as short as possible.
Example Cf. chapter 5.3.4.
5.3.6 Cyclic Sending of PDOs
PDOs with a transmission type of 1 to 240 are automatically transmitted (synchronously). The
transmission type indicates how many synchronization telegrams there are between two PDO
transmissions. The user only has to ensure that the application objects which are specified in the
mapping parameters of the PDOs are updated in time.

(4)J31069-D2048-U001-A1-7618 45
5.4 SDO Services
5.4.1 Reading an Entry from the Object Directory of a Slave Node
Syntax int CAN_fn_ReadSlaveObjectDict(unsigned int CSDO_Nr,

unsigned long Entry,
unsigned long *Data)

CSDO_Nr Node ID of the SDO client
Example:
Entry = 140002h ® Index = 1400h
Subindex = 02h
Data Pointer to a variable for returning the entry

–1: Entry has "write only" attribute.
–2: SDO not available
–3: Protocol error
Description This function reads back an entry from the object directory of the specified
slave node if this entry exists and a read access is permitted. The read value
is returned in the specified variables.


{
unsigned char by_DigInput1;
if (CAN_fn_ReadSlaveObjectDict(1, 0x600000, &dw_Data)

== 1)
{
by_DigInput1 = (unsigned char)dw_Data;
}
else
{
bg_outtext ("Not possible to read from!");
}
}

46 (4)J31069-D2048-U001-A1-7618
5.4.2 Writing an Entry to the Object Directory of a Slave Node
Syntax int CAN_fn_WriteSlaveObjectDict(unsigned int CSDO_Nr,

unsigned long Entry,
unsigned long Data)

CSDO_Nr Node ID of the SDO client
Data Data to be written

–1: Entry has "read only" or "constant" attribute.
–2: SDO not available
–3: Protocol error
Description This function writes an entry to the object directory of the specified slave node
if this entry exists and a write access is permitted.


{
unsigned char by_DigOutput1 = 0x55;
dw_Data = by_DigOutput1;
if (CAN_fn_WriteSlaveObjectDict(1, 0x620000,
&dw_Data) == 1)
{
bg_outtext ("Digital data given out");
}
else
{
bg_outtext ("Not possible to give out!");
}
}

(4)J31069-D2048-U001-A1-7618 47
5.4.3 Reading the Object Directory of the Master Node
When a defined server SDO is used, this service reads the object directory of this node.
Slave: COB-ID client ® server
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7

40h Index LSB Index MSB Subindex Reserved Reserved Reserved Reserved
Master: COB-ID server ® client

42h Index LSB Index MSB Subindex Data Data Data Data
5.4.4 Writing to the Object Directory of the Master Node
When a defined server SDO is used, this service writes to the object directory of this node.
Slave: COB-ID client ® server

22h Index LSB Index MSB Subindex Data Data Data Data
Master: COB-ID server ® client

60h Index LSB Index MSB Subindex Reserved Reserved Reserved Reserved

48 (4)J31069-D2048-U001-A1-7618
5.5 Synchronized Events

With CANopen, you can synchronize events in the entire network by triggering this with
synchronization telegrams.
For instance, application data which were received with a synchronous PDO (command message) can
be updated and output again with the next synchronous PDO (actual message). When a
synchronization telegram arrives, a user-specific function is called in which the necessary application
data are updated.
5.5.1 Defining a Synchronized Function Call
Syntax int CAN_fn_DefSyncCall(void far (*ptr_SyncFkt)(void) )

ptr_SyncFkt Pointer to the desired callback function

Description This function sets a callback function which is to be called when triggered by a
synchronization telegram.


{
if (CAN_fn_DefSyncCall(fn_SyncTrigger) == 1)
{
bg_outtext ("Synchronised function call
installed");
}
}
void far fn_SyncTrigger(void)

{
static unsigned long dw_Counter;
dw_Counter++;
}

(4)J31069-D2048-U001-A1-7618 49
5.6 Trouble-Shooting
5.6.1 Error Flags
An error variable is defined whose individual bits of the application indicate that a serious error has
occurred on the master or in a slave node.
unsigned char CAN_by_ErrorFlags
When one of these bits is "1," this means that a particular error has occurred. The error flags must be
reset by the application.
Table 5.1 Meaning of the bits
Flag Error Effect
Bit 0 Bus-off for master Master node must be initialized again.
Bit 1 · With CANopen:
Monitoring error of the master Master is not ready.
· With standard CAN:
Overflow of receiving buffer Oldest telegram is overwritten.
Bit 2 Monitoring error (lifeguard error) of a slave All devices must be shut down and started
again.
Bit 3 Emergency telegram received –
Bit 4 Timing error of the synchronization window or All communication could not be executed since
the communication cycle there wasn't enough time.
Bit 5 No response to SDOs –
Bit 6 "Bus warning" state –
Bit 7 Bus error occurred –

50 (4)J31069-D2048-U001-A1-7618
5.6.2 Defining Error Detection
Syntax int CAN_fn_DefErrorCall(void far (*ptr_ErrorFkt)(void) )

ptr_ErrorFkt Pointer to the desired callback function

Description This function sets the callback function which is to be called when an error flag
is set in CAN_by_ErrorFlags.


{
if (CAN_fn_PDODefRecvInd(fn_ErrorOccured) == 1)
{
bg_outtext ("Errors will be indicated");
}
}
void far fn_ErrorOccured(void)

{
static char s_Output[50];
sprintf(s_Output, "Error: %u", CAN_by_ErrorFlags);

bg_outtext(s_Output);
}

(4)J31069-D2048-U001-A1-7618 51
Preparing a Configuration with CANsetter and DCFcomp IMC05-CAN
6 Preparing a Configuration with CANsetter

and DCFcomp
Preparing and configuring a new node for the IMC05
Proceed as shown below to generate the object directory data with the CANsetter service program.
1. Select the menu command Edit > New Node.
2. With the right mouse button, click the newly inserted node, and select the command
Configuration in the context menu.
3. In the dialog field Node Configuration, click the button Device Type.
4. In the dialog field Select EDS, click Siemens SICOMP-IMC05, and confirm with OK.
The basic configuration of the new node is generated with the standard settings from the
electronic data sheet of the IMC05 (IMC05.EDS).
5. In the dialog field Node Configuration, enter the remaining information, and confirm with OK.
The new node is indicated on the CANsetter desktop with the icon of the IMC05.
In either the dialog field Device Access or Variable list, you can then enter all required information in
the object directory of the IMC05. To do this, select either the command Device Access or Variables
list from the context menu of the IMC05.
· Add the variables, PDOs and SDOs, which you want to use, to your application, and adjust the
standard values to your configuration.
· Map your application variables for the generated PDOs, and select the identifier and the type of
transmission (cf. example).
· Set all configuration parameters such as node ID, number of PDOs and SDOs used,
communication cycle period, synchronous window length, number of slave nodes, slave
parameters, and so on.
· Then back up your project. CANsetter creates or adjusts the device configuration files (DCF) of all
nodes. You can read these files with the Windows editor.

52 (4)J31069-D2048-U001-A1-7618
IMC05-CAN Preparing a Configuration with CANsetter and DCFcomp
Compiling the device configuration file with DCFcomp
Select the command Compile DCF in the context menu of the IMC05.
This creates two files from the information of the current configuration file NAME.DCF.
· A binary file called NAME.BIN containing all information of the object directory for loading to the
flash memory of the IMC05
· A header file called NAME.H for linking in the names from the object list to your application
Afterwards, you can load the binary file ( NAME.BIN) with the SEND.EXE IMC05 service program to
the IMC05. You can make the familiar settings for the required parameters in the subdirectory
\FLASHCAN of the CANsetter installation directory. See technical description of the SICOMP-IMC05.
The sector of flash memory which is to be written is selected by changing the value in the define
instruction for C_DCF_FL_SEG in the header file CANOPN05.H.
If some entries in the object directory have to be changed later, you only have to load the new binary
file to the IMC05 afterwards and not the complete application.

(4)J31069-D2048-U001-A1-7618 53
Sample Application IMC05-CAN
7 Sample Application
Using a simple example, this chapter gives you a concise overview of the basic procedures involved in
creating a CANopen project with the IMC05.
1. Set up a new project in CANsetter, and save (e.g., under "imc5demo").
2. A not yet configured node appears on the desktop. Using the right mouse button, select the
command Configuration from the context menu. Enter the name and the node ID, and select the
IMC05 from the device type list. If this is not possible, repeat the steps listed in chapter 2.2.
3. Add two new nodes. Configure one as a Weidmüller digital input module and the other as a
Weidmüller digital output module.
4. The object directory can be processed with the commands Variables list or Device Access from
the context menu of the particular node.

54 (4)J31069-D2048-U001-A1-7618
IMC05-CAN Sample Application
5. Several objects are now added to the object directory of the IMC05.
Weid8DO, SyncCounter and Pdo1RecvCounter are dynamic output variables. Weid8DI and
StartNodes are dynamic input variables.
Weid8DO is for transmitting the output value to the Weidmüller DO8 module. Weid8DI is for
reading the inputs of the Weidmüller DI8 module.
SyncCounter and Pdo1RecvCounter are counter variables which are to be available as status
information.
StartNodes is a boolean variable which is set to 1 when the network is to be started.

(4)J31069-D2048-U001-A1-7618 55
6. A receiving PDO is defined for reading the digital inputs.
The transmission type is asynchronous. The standard identifier is calculated with 180h + 2 = 182h
in accordance with the input module.. The first data byte of the PDO is transferred to the object
Weid8DI with the index A4C0h and subindex 0.

56 (4)J31069-D2048-U001-A1-7618
7. Two sending PDOs are used to transfer the status information and set the digital outputs.
The type of transmission for both PDOs is cyclic, synchronous. The standard identifier for TPDO2
is calculated with 200h + 3 = 203h corresponding to the output module. No particular identifier is
selected for TPDO1.

(4)J31069-D2048-U001-A1-7618 57
Object Weid8DO with index A040h and subindex 0 is transferred with the first data byte of
TPDO2. SyncCounter occupies the first four bytes of TPDO1. Pdo1RecvCounter occupies the
next four bytes.
8. The remaining communication parameters must then be adjusted.
The number of available PDOs is set to two synchronous sending PDOs and one asynchronous
receiving PDO. The communication cycle period is set to 10 msec (value: 10000). The
synchronous window length is set to 5 msec (value: 5000).

58 (4)J31069-D2048-U001-A1-7618
9. Finally, the list of network nodes must be prepared and the transmission speed selected.
10. Now save your project. This generates the current device configuration file for IMC05.
11. Select the command Compile DCF from the context menu.
The service program DCFcomp generates the binary file and the header file.
12. Now create your application program, and link in the header file.
13. When the application is generated and loaded to the flash memory of the IMC05, the binary file
with the data of the CAN configuration can also be loaded retroactively from CANsetter. To do
this, select the command Load Flash from the context menu of the IMC05.
If the binary file cannot be loaded to the IMC05, check the configuration of the IMC05 node. See
chapter 6.

(4)J31069-D2048-U001-A1-7618 59
Sample application CANTEST.C
Below is the source code of the included sample application. When, for instance, you enter a 1 in the
"StartNodes" variable with CANsetter, the program starts the network, outputs two values alternately
on the output module, reads the current status of the input module, and signals when an error occurs.
/* ***********************************************************************
// CANTEST.C
//
//
// Task to test the CANOPEN.LIB for the IMC05/RMOS system
//
// version V2.0
// date January 22. 1999
//
// ********************************************************************** */
/*****************************************************************************/
/* incode identification */
/*****************************************************************************/
#if defined(_ARCHITECTURE_) || defined(CADUL)
const static char idstr [] =
{
"\0" "(C) SIEMENS AG 1997" "\0" /* In-code identification. */
"\1" "CANTEST.C" "\1"
"\2" "0002" "\2"
"\3" "SiE/Wein" "\3"
};
#endif /* defined(_ARCHITECTURE_) || defined(CADUL) */
/********** include definitions *******************************************/

#include <rmapi.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "imc05bas.h"
#include "canopn05.h"
#include "imc5demo.h"
/********** globals *******************************************************/
unsigned char b_ErrorOccured;

60 (4)J31069-D2048-U001-A1-7618
/********** functions *****************************************************/
/* function to increment SyncCounter object */

/* ---------------------------------------- */
void far fn_SyncTrigger(void)
{
static unsigned long dw_Data;
CAN_fn_ReadObjectDict(U32Out_SyncCounter, &dw_Data);
dw_Data++;
CAN_fn_WriteObjectDict(U32Out_SyncCounter, dw_Data);
}
/* function to increment Pdo1RecvCounter object */

/* -------------------------------------------- */
void far fn_ReceivedPdo1(void)
{
static unsigned long dw_Data;
CAN_fn_ReadObjectDict(U32Out_Pdo1RecvCounter, &dw_Data);
dw_Data++;
CAN_fn_WriteObjectDict(U32Out_Pdo1RecvCounter, dw_Data);
}
/* function to indicate occured errors */

/* ----------------------------------- */
void far fn_ErrorOccured(void)
{
b_ErrorOccured = 1;
}
/* ==================================================================== */
void _FIXED _FAR UserTask_1 (void)

{
char s_Ausgabe[50];
unsigned char by_Data;
b_ErrorOccured = 0; /* reset flag */
printf("\nUTASK_1: Start cyclic IMC05/RMOS3 CANopen test program ...\r\n");
bg_cleardevice();
bg_settextcolor (BG_BLACK,BG_WHITE);
bg_setcursortype (BG_NOCURSOR, BG_NOAUTOCURSOR);

(4)J31069-D2048-U001-A1-7618 61
/* initialisation */
/* -------------- */
bg_gotoxy (50, 50, PIXEL);
bg_selectfont(3);
bg_outtext ("CAN_fn_Init...");
if (CAN_fn_Init(250) == 0)
{
RmEndTask();
}

bg_selectfont(3);
bg_outtext ("CAN_fn_CreateNode...");
CAN_fn_CreateNode();
CAN_fn_DefErrorCall(fn_ErrorOccured);
/* wait for network start command */

do {
CAN_fn_ReadObjectDict(BoolInp_StartNodes, &dw_Data);
RmPauseTask(500);
} while (dw_Data == 0);

bg_selectfont(3);
bg_outtext ("CAN_fn_StartNodes...");
CAN_fn_StartNodes();
/* operation */
/* --------- */
CAN_fn_DefSyncCall(fn_SyncTrigger);
CAN_fn_PDODefRecvInd(1, fn_ReceivedPdo1);
CAN_fn_PDOStoreReq(2);
bg_cleardevice();
bg_gotoxy(50, 50, PIXEL);

bg_outtext ("CAN-Open Demo");

62 (4)J31069-D2048-U001-A1-7618
for (;;)
{
/* error occured ? */
if (b_ErrorOccured)
{
/* give out message */
sprintf(s_Ausgabe, "Error: %x ", CAN_by_ErrorFlags);
bg_outtext (s_Ausgabe);
b_ErrorOccured = 0;
/* handle error */
if (CAN_by_ErrorFlags & 0x01)
{
/* -> bus off */
CAN_by_ErrorFlags = 0;
CAN_fn_CreateNode();
}
else if (CAN_by_ErrorFlags & 0x14)
{
/* -> life guarding or timing error */
CAN_by_ErrorFlags = 0;
}
}
CAN_fn_PDOReadReq(1);
/* give out new value to Weid8DO */

CAN_fn_ReadObjectDict(U8Out_Weid8DO, &dw_Data);
if ((unsigned char)dw_Data == 0xAA)
{
by_Data = 0x55;
}
else
{
by_Data = 0xAA;
}
CAN_fn_WriteObjectDict(U8Out_Weid8DO, by_Data);
/* print input value of Weid8DI */

CAN_fn_ReadObjectDict(U8Inp_Weid8DI, &dw_Data);
sprintf(s_Ausgabe, "INPUT: %2x", (unsigned char) dw_Data);
bg_outtext (s_Ausgabe);
RmPauseTask(500);
}
/*------------------------------------------------------*/
/* End this task now */
/*------------------------------------------------------*/
RmEndTask();
}

(4)J31069-D2048-U001-A1-7618 63
Fundamental CAN Functions IMC05-CAN
8 Fundamental CAN Functions

The functions described in this chapter are not part of the CANopen definition. These are basic
functions from layer 2 of the CAN-OSI model.
These functions should only be used when there is no way to access devices with CANopen.
Caution
Do not use these functions with the CANopen protocol.
8.1 Initializing the CAN Controller

Syntax int BCAN_fn_InitContr(unsigned int filtermsb,
unsigned int filterlsb,
unsigned int btr0,
unsigned int btr1)

filtermsb Identifier filter setting (default 0)
filterlsb Identifier filter setting (default 0)
btr0 Bit timing register 0 (see appendix A)
btr1 Bit timing register 1

Description This function initializes the CAN controller with the selected transmission
speed and the settings of the global identifier mask. For more information on
the register settings, see the manual of the Intel 82527 CAN controller.

64 (4)J31069-D2048-U001-A1-7618
IMC05-CAN Fundamental CAN Functions
8.2 Sending Objects

Syntax int BCAN_fn_Transmit(unsigned char *data)

data Array (12 bytes). Contains the object to be transferred.
Byte 0: Identifier (low byte)
Byte 1: Identifier (high byte)
Byte 2: Reserved (must be 0)
Byte 3: Reserved (must be 0)
Byte 4: Length of the data (0 to 8)
Bytes 5 to 12: Data

Description This function sends the object transferred in data.

(4)J31069-D2048-U001-A1-7618 65
8.3 Sending Remote Objects

Syntax int BCAN_fn_TransmitRemote(unsigned long identifier)

identifier Identifier of the remote object to be transferred

Description This function sends the remote object with the specified identifier via message
object 3 of the Intel 82527 controller.
The BCAN_fn_ReadObject function can be used to read the received data from
the buffer.
Syntax int BCAN_fn_TransmitRemote2(unsigned long identifier)

identifier Identifier of the remote object to be transferred

Description This function sends the remote object with the specified identifier via message
object 4 of the Intel 82527 controller.
The BCAN_fn_ReadObject function can be used to read the received data from
the buffer.

66 (4)J31069-D2048-U001-A1-7618
IMC05-CAN Fundamental CAN Functions
8.4 Reading Objects

Syntax int BCAN_fn_ReadObject(unsigned char *data)

data An 11-byte array to return the received object
Byte 2: Reserved
Byte 3: Reserved
Byte 4: Data length (0 to 8)
Bytes 5 to 12: Data
byObjectNr Global variable for selection of the message object of the
Intel 82527 controller to be read

0: No new data available
Description This function returns a received object which was requested before with
BCAN_fn_TransmitRemote (byObjectNr = 3) or BCAN_fn_TransmitRemote2
(byObjectNr = 4).
8.5 Fetching Received Objects

Syntax int BCAN_fn_GetReceivedData(unsigned char *data)

data An 11-byte array to fetch the received object
Byte 0: Reserved
Byte 3: Reserved
Byte 4: Reserved
Byte 5: Data length (0 to 8)
Bytes 6 to 13: Data

Description This function returns a received object.

(4)J31069-D2048-U001-A1-7618 67
A Bit Timing Recommended by CiA CANopen

Transmis- Nominal Bit No. of Time Time Unit tq Placement of btr0 btr1 SJW
sion Speed Time tb Units per Bit Sample Point
1)
Bus Length
1 Mbit/sec 1 µsec 8 125 nsec 6 tq 0 14h 1
25 m (750 nsec)
800 kbit/sec 1.25 µsec 10 125 nsec 8 tq 0 16h 1
50 m (1 µsec)
500 kbit/sec 2 µsec 16 125 nsec 14 tq 0 1Ch 1
100 m (1.75 µsec)
(2)
250 m (3.5 µec)
2)
500 m (7 µsec)
50 kbit/sec 20 µsec 16 1.25 µsec 14 tq 9 1Ch 1
3)
1000 m (17.5 µsec)
20 kbit/sec 50 µsec 16 3.125 µsec 14 tq 18h 1Ch 1
3)
2500 m (43.75 µsec)
10 kbit/sec 100 µsec 16 6.25 µsec 14 tq 31h 1Ch 1
3)
5000 m (87.5 µsec)
1) Rounded length of the bus lines (in worst case scenario), based on a propagation delay of 5 nsec/m and the
following effective ECU internal I/O delay (ECU = Electrical Control Unit).
1 M to 800 kbit/sec 210 nsec
500 to 250 kbit/sec 300 nsec (incl. 2 x 40 nsec for optocoupler)
125 kbit/sec 450 nsec (incl. 2 x 100 nsec für optocoupler)
50 to 10 kbit/sec 1.5 tq; effective delay = average of (delay regressive ® dominant) and (delay dominant
® regressive)
2) Use of optocouplers recommended for bus lengths over 200 m. When optocouplers are used between CAN
controller and transceiver, the maximum bus length is decreased by 4 m per 10 nsec, depending on the
propagation delay of the optocouplers.
3) Bridge or repeater units may be required for bus lengths over 1 km.

68 (4)J31069-D2048-U001-A1-7618

IMC05-CAN, Version 2.0: March 2000

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IMC05-CAN, Version 2.0: March 2000

Hochgeladen von

Copyright:

Verfügbare Formate

Technical Description

Order number: 6AR1943-3AL00-2AA0 March 2000

IMC05-CAN, Version 2.0

Driver Software for CAN Communication with the SICOMP-IMC05 Compact

SICOMP Industrial Microcomputer

Changes in the technical description

©Siemens AG 2000, All Rights Reserved

1.1 Function Overview 5

2.1 CANopen Library 7

3 How the Software Functions 10

3.1 The Object Directory 10

4 IMC05 in the CAN Network 16

4.1 Configuring the IMC05 as CAN Node 16

5 Description of the Library Functions 31

5.1 Initializing the CAN Network 31

©Siemens AG 2000, All Rights Reserved

5.1.4 Setting the Slave Nodes to the Pre-Operational State 34

6 Preparing a Configuration with CANsetter and DCFcomp 52

8 Fundamental CAN Functions 64

8.1 Initializing the CAN Controller 64

A Bit Timing Recommended by CiA CANopen 68

©Siemens AG 2000, All Rights Reserved

1.1 Function Overview

Figure 1.1 Principal layout of a CANopen application with the IMC05

©Siemens AG 2000, All Rights Reserved

1.2 Configuration Program - CANsetter

1.3 Scope of Delivery

©Siemens AG 2000, All Rights Reserved

2.1.1 System Prerequisites

Software requirements on the development computer

2.1.2 Installation Procedure

©Siemens AG 2000, All Rights Reserved

File Name Meaning

For more details, see the readme file READCAN.2P0.

©Siemens AG 2000, All Rights Reserved

2.2 Adjustment of the Configuration Program CANsetter

2.2.1 System Prerequisites

Software requirements on the development computer

2.2.2 Installation Procedure

Path and File Name Meaning

Setting the CAN card

©Siemens AG 2000, All Rights Reserved

3 How the Software Functions

Parameter Area Index Contents

3.1.1 Communication-Related Parameters

©Siemens AG 2000, All Rights Reserved

Type of Transmission Description Remarks

Communication Cycle Period Synchronous Window Length

SYNC SYNC SYNC SYNC Time

SYNC Synchronization telegram

Synchronous, cyclic PDO (transmission type 2)

Synchronous, non-cyclic PDO (transmission type 0)

Asynchronous PDO (transmission type 245 or 255)

Figure 3.1 Use of PDOs with different transmission types

©Siemens AG 2000, All Rights Reserved

3.1.2 IMC05-Related Parameters

©Siemens AG 2000, All Rights Reserved

3.1.3 Application Variables

©Siemens AG 2000, All Rights Reserved

3.2 Using the Service Programs

03FE 0000 Development PC

CAN standard data CAN fn Init()