CANopen network design has traditionally been

performed either too sepa-rately from the software de-sign or network configura-tion has erroneously been included into application software. Separate network design has significantly im-proved the overall efficiency of the development projects, but only slightly enhanced production, maintenance and service of the systems. Including network configu-ration into the application has lead into problematic dependencies between ap-plications and communica-tions. Problems have been met during the whole life cy-cle of the systems, mostly because traditional network design flow expects some SW (software) design to get an interface description(s) for application programma-ble node(s).

This article presents a new approach for combin-ing network and SW design. Network design remains as separate and parallel task with SW design. Application interface declaration and network abstraction can be

CANopen network design andIEC 61131-3 software design

Heikki Saha (Sandvik Mining and Construction), Magnus Wikman, Patrik Nylund (TK Engineering)

imported from EDS (elec-tronic data sheet) or DCF (device configuration file) file into SW design instead of manual writing. After completing the SW devel-opment, compiled execut-ables can be linked to the DCF files to enable consis-tent production and service processes. Commitment to the technology can be de-layed by introducing the in-terfaces before performing any SW design and inde-pendently of the program-ming languages and envi-ronments.

Case example has been successfully created with IEC 61131-3 PLC en-vironment. Communication interface specification was exported from experimen-tal system modeling frame-work. Standard CANopen network design tools and file formats were utilized throughout the process and only one conversion tool had to be implement-ed. The PLC (programma-ble logic controller) used in the example is typical mo-bile PLC in the market with limited CANopen device

only. CANopen NMT mas-ter had to be implemented in IEC 61131-3-application, but it did not prevent using the standard CANopen net-work design process.

Introduction

Traditional way of work-ing with mobile PLCs and CANopen networks, pre-sented in Figure 1, ex-pects technology commit-ment in too early phase and does not support consis-tent manufacturing and field service. Too much manu-al work is needed between IEC 61131-3 and CANopen designs during the process. Full design flow, hardware abstraction and API (ap-plication programming in-terface), as completely de-fined for LIN (local inter-connect network), are not well specified for CANopen and applications tend to become too closely cou-pled with object dictionary indexes and communica-tion parameters. CiA 405 (CANopen interface profile for IEC 61131-3 program-

mable devices) defines only signaling interface and for-gets the process aspects in-cluding the design-time pa-rameter and signal declara-tions and abstraction meth-ods. Moreover CiA 306 (electronic data sheet spec-ification for CANopen) con-centrates on the core net-work design covering signal connections, frame trans-missions and device pa-rameter settings. CANopen profile database (CODB) file format as a base for EDS is still in working draft state, which has reduced its visi-bility among developers.

Later in this article CODB, EDS and DCF files signify more file roles than exact file formats. When CANopen XML (CiA 311 CANopen device descrip-tion, XML schema defini-tion) is in plausible state, it can replace the old file for-mats offering same features and some more.

Use of dynamically al-located network variables (see CiA 306 and CiA 405) will conflict with the way of working because detailed

Figure 1: CANopen design flow traditionally linked with IEC 61131-3 environment

Figure 2: CANopen design flow more systematically linked with IEC 61131-3 environment

52 CAN Newsletter 3/2009

Dev

elop

men

t

EDS will be needed be-fore using them, or there is no way to import signal ab-straction after assigning the dynamic variables using more generic EDS.

C/C++ CANopen im-plementations either can read configuration direct-ly from DCF (as defined in CiA 306) or have a utility tool converting DCF into a stack-specific configura-tion format either design- or even run-time.

One major problem with the traditional approach is too early commitment into IEC programming language – application interface dec-larations shall currently be written in IEC 61131-3-proj-ect (PRO), where they can be exported as an EDS file. Sometimes target plat-form and programming lan-guage can be defined after few preliminary design cy-cles, which will cause over-head in traditional approach – getting the first design for evaluation expects some amount of IEC 61131-3-pro-gramming, which shall pos-sibly be discarded later if platform or language has to be changed.

Lack of convenient method to import data from network design to the soft-ware design forms another abstraction problem. Sys-tematic method to man-age NMT master con-figuration does not exist – settings shall be given via IEC 61131-3-code instead of standard objects NMT start-up (1F80h) and slave assign-

ment (1F81h) (see CiA 302-2 CANopen additional appli-cation layer functions, part 2: Network management). Of course NMT master it-self shall also be included into the IEC 61131-3-appli-cation if it is not supported by the PLC run-time.

Network design tools have been available for years but configuration and software downloads are not simple tasks with them. Easy-to-use production and service tools are new in the market, while standard DCF files have supported point-ing to a compiled binary for long time. Legacy pro-gram download interfaces and methods have been used instead of standard CANopen program down-load interface.

The article contin-ues with the overview of the improved CANopen/IEC 61131-3 -co -des ign flow. A detailed case ex-ample follows the introduc-tion. The case example has been divided into seven phases following the overall design process from defini-tion of the application signal and parameter interface to system assembly and be-havioral verification.

Integrated design

The most significant differ-ence between the current and proposed approach is, that in the proposed ap-proach design is always done before implementa-tion. As long as all designs

Figure 3: Imported global variable definitions in the IEC 61131-3 environment

are saved as standard de-sign file formats, design will be mapped with technology in the implementation phase and technology changes af-fect on the implementations only.

More systematic ap-proach for EDS design of an application program-mable device can be tak-en by dividing the interface under design into multiple CODB files. CANopen de-vice-, manager- and gate-way-specific features of the platform are indepen-dent of the applications and can be efficiently reused when managed with COD-Bs. Aforementioned divi-sion also enables fine-grain option management among optional CANopen services provided by the platform. Di-vision into platform- and ap-plication-specific interfaces intrinsically enables appli-cation interface description either manually or as export from a system model.

After EDS has been composed, it contains the whole interface descrip-tion of a device’s single in-terface. Application signals and parameters already have their names, types and default values. There-fore EDS file is a natural choice for source of the in-terface declarations import to the IEC 61131-3-environ-ment. All needed variables with default values can be imported from the EDS file instead of entering them manually. Because at least some of the current values deviate from the default values, the final configu-ration – including dynamic network variables – will be ready after completing the network design, which ex-ists in DCF files. If all appli-cation signals are already mapped into network vari-ables in respective COD-Bs, the abstraction can be imported from the EDS file. The abstraction links sig-nals and parameters named according to the application with the respective object dictionary objects enabling use of application names in

the application. Automated management of the map-pings ensures that equal names are used in both ap-plication and communica-tion.

Seamless integration into production and field- service is offered via DCF and signal database (DBC) files. If a target platform sup-ports SW download via the object dictionary, compiled application binaries can be linked to the domain type objects with “Download-File” property of the object to enable combined soft-ware and parameter down-loads with standard tools in production and service operations. DBC format is de-facto and supported by most analyzer vendors. It is generated by the network design tool during the net-work design and it defines signals, messages and how signals are mapped into messages. Signal defini-tions can include scaling, unit and optional enumer-

ation. The analyzers can present signals in a well-un-derstandable format based on the definitions. Unfortu-nately standardized log-file format does not exist, which would enable cross-use of log-files among analyzers.

Phase 1: Enteringapplication signal andparameter interface

Both manually written and exported signal and pa-rameter declarations from system model were tested. Interface has been divided into four parts to help man-ual entry:

� Platform-specific CANopen device imple-mentation, which con-tains all objects pro-vided by the CANopen device implementation of the target platform (see CiA 301 CANopen appli-cation layer and commu-nication profile)

� CANopen NMT master implementation, which contains the objects

supported by the NMT master implemented in the target platform (see CiA 302-2)

� Application-specific pa-rameters are located in manufacturer-specific objects

� Application-specific sig-nal definitions located into network variable area (see CiA 405)

Readers are advised to re-fer to CiA 306 for detailed description of the CANopen profile database format. Based on the writers’ expe-rience, writing and testing a good template will signif-icantly help manual CODB writing. Error-free CODBs enable extremely fast and convenient EDS design.

Phase 2: EDS design EDS files for intelligent

sensors and actuators and generic I/O devices shall be provided by device vendors. EDS design for applica-tion programmable devices can not be completed with-out defining the application interface. As presented in the description of the previ-ous phase, an EDS file can be constructed from one or more CODB files. After gen-erating the CODBs in a way defined in the phase 1, an EDS can be created by just combining contents of all CODBs required by the ap-plication.

After including all ob-ject definitions, generic EDS file and device information shall be inserted. To speed-

Figure 4: Example device configuration wizard

Figure 5: Imported CAN initialization in the IEC-environment

54 CAN Newsletter 3/2009

Dev

elop

men

t

up the entering of the ge-neric information, EDS-tem-plates can be used.

Phase 3: Communication interface description import into IEC-environment

The IEC 61131-3-ap-plication needs global vari-ables for holding signal and parameter values. Defini-tions of the global signal and parameter variables with default values can be imported from either EDS or DCF files. Ability to import the definitions from a stan-dard design file enables cy-clic development and easy update of the definitions af-ter changes. After importing

the definitions, application can be developed in paral-lel with the network design. If network design affects on the mapping between the variables and object diction-ary objects, final linking can be imported from the DCF file after the network design has been completed.

A special tool (DCF-to-EXP converter) had to be written to be able to trans-late EDS or DCF file into ex-port file of the IEC 61131-3-environment. Separate utility is for temporary use and evaluation only – the best solution would be to in-clude such an import direct-ly into IEC 61131-3-environ-ments.

Parameters readable from the object dictionary and mappable output sig-nals are in lines 14 to 16 and parameters writable to the object dictionary and mappable input signals are in lines 19 to 21 of the Fig-ure 3. Variable names with data types and default val-ues are read from the EDS file. Node-ID (identifier), bit-

rate and CANopen initializa-tion variables in lines 2 to 11 are not needed in a PLC with CANopen device and manager implemented into PLC run-time.

Phase 4: The networkdesign

Network design has been well-known process for long time and its details are not in the scope of this article. One should notice that in addition to the sig-nal connections manage-ment, the network design phase consists of schedu-lability analysis and safe-ty analysis for every net-work under design. Most of the current network design tools offer graphical user in-terface for signal connec-tion management with vari-ous error checks. Network design covers signal con-nection management and defines all frame transfers. Typically tools offer name-value pair based access to device parameters. Ob-ject names and parameters are read from the EDS file. Name-value based config-uration is widely supported by the standard configura-tion tools, but it may not be convenient enough for con-figuration of complex device functions.

Therefore DCF post-edit applications offer easi-er and faster device param-eter configuration. Another possibility is use of plug-ins with network design tools if interfaces exist. Figure 4 presents an experimental device configuration wizard for DIN-A CANopen valve driver capable of loading de-fault values from and storing set values to the DCF file. It provides graphical config-uration interface and pre-vents the user to set illegal parameter value combina-tions.

Phase 5: Importing CANopen abstraction into SW design

Figure 6 presents the options, with which the rest of the CANopen ab-straction can be converted

Figure 6: Exporting object-to-variable mappings and NMT master settings from DCF to IEC-environment

Pioneering new technologiesPioneering new technologies

ESX®-Family

ESX®-LT

ESX®-MICRO

freely programmable controllers (in C and IEC61131-3)applications in mobile work machines and commercial vehicles

ESX®-C2CModule for mobile data collection and remotemaintenance and diagnostics via GSM/GPRS orBluetooth® wireless technology

ESX®-DIOS/DIOMI/O-Modules for extension of the I/O-layer of amaster-controller (e. g. ESX®) via CAN-Bus

ESX®-3XL32bit-controller with 150MHz clock frequencyand 136 I/Os

Am Bärenwald 6 · 87600 Kaufbeuren · Germany · Telephone +49 (0) 8341-9505-0

www.sensor-technik.de

www.sensor-technik.co.uk | www.stw-technic.com

Pressure transmitter

M01-CAN

especially for application in mobile machines and commercial vehicleshighest media compatibilitypressure ranges from 0 ... 25 bar to 0 ... 800 bar(Overall accuracy in the temperature compensated range: 1%)max. media temperature 150°C / max. ambient temperature 125°Cparts wetted and case in stainless-steellatest assembly processes according to ISO/TS 16949price competitive for series productionOEM versions availableCAN-Bus interface

AgritechnicaHannover, Germany8 – 14 November 2009Hall 16, Booth A17

SPS/IPC/DRIVESNuremberg, Germany24 – 26 November 2009Hall 7, Booth 169

Exhi

biti

ons

Dev

elop

men

t to the export-format of the IEC 61131-3-environment. The resulted file contains declaration of the applica-tion-specific parameters, mapping between global variables and both parame-ter and signal objects. Also NMT slave assignments are included, if the target plat-form will act as NMT mas-ter. Abstraction is imported after network design mostly because NMT master con-figuration was not available earlier.

One should notice that IEC code lines 2 and 10 are needed only because the CANopen implementation is not complete and not lo-cated in PLC run-time. IEC code lines 5 and 7 in the Figure 8 connect the appli-cation-specific parameter objects with the respective global variables defined ear-lier. Objects for application-specific parameters have always to be introduced and connected with the param-eter variables during appli-cation initialization because they will be totally different in different applications. To avoid errors, it is important to be able to import configu-ration instead of manual en-try.

In Fgure 7, IEC 61131-3-code lines 2 and 3 connect output signals to the stan-dardized network variable area of the object diction-ary. Lines 6 and 7 connect the input signals from the network variable area to the global variables. AT-key-word could also be used for connecting global variables with network variables, but in that way the input vari-

ables can be updated from CAN during the PLC cycle, which may lead to an erro-neous application behavior. Direct copying allows soft-ware designer to choose the correct time to update inputs and outputs.

Typical mobile PLCs in the market do not support NMT master embedded into run-time. Common so-lution is to write such in an IEC 61131-3-application in-stead.

Figure 8 presents ex-ample application body implemented as a state-machine. In initialization, CANopen device presented in details in Figure 5 is ini-tialized first and then NMT master is called cyclically, until it has started the whole system.

Application execution is started after completion of the whole initialization. The network variable syn-chronization function pre-sented in details in Figure 7 is called in the end of each cycle because:� After initialization remote

outputs are set to the safe default values as soon as possible

� Input values are re-trieved for the first appli-cation cycle

� Input status variables re-main constant during the whole cycle and they can be directly used by the application

The simple NMT master is-sues an NMT reset commu-nication service for all de-vices and starts up devices sequentially so, that node existence monitoring and

NMT start node command for each device are inter-leaved to prevent possible NMT message bursts. The more device nodes exist, the longer time NMT master execution takes. The NMT master enables application start if all devices have been started. The NMT master and related optional servic-es are defined in CiA 302-2 and CiA 302-3 (CANopen additional application lay-er functions, part 3: Config-uration and program down-load).

Based on the sever-al years experience on the CANopen system integra-tion, the NMT master should absolutely be located into PLC run-time instead of IEC 61131-3-application be-cause:� It can be configured via

object dictionary simul-taneously with the other CANopen services by standard CANopen con-figuration download tools

� It will be more reliable� It will consume less pro-

cessing performance and memory

� The application can con-tain only the applica-tion-specific functionality, which will significantly reduce the testing effort of the applications

Phase 6: Configuration and software download based on DCF files

CANopen has well standardized file format and services for device configu-ration:� DCF files for carrying de-

vice configurations and references to the appli-cation program files (see CiA 306 and CiA 311)

� Layer setting services (LSS) for changing the bit-rate and node-ID (see CiA 305)

� SDO protocol for access-ing device parameters, including the application programs (CiA 302-3) in the object dictionary

The wide offering of the COTS (commercial off-the-shelf) devices cause some extra challenges, be-

cause many combinations of the services are support-ed. In example, LSS is not supported by all devices – some of them support pa-rameter objects instead.

Downloading of all pa-rameters every time may be too time-consuming during the configuration process. A way to define, which ob-jects should be updated and which should not, is need-ed. Moreover, additional in-formation will be needed to enable tools to provide user-friendlier user interfac-es for production and ser-vice people without deep technical knowledge of CANopen. Because such in-formation cannot be includ-ed into standard CANopen design files, additional pa-rameter file has been intro-duced to the configuration download tool. The con-trol file also contains addi-tional information to enable the tool unambiguous-ly set bit-rate and node-ID via device’s object diction-ary. Regardless of the ad-ditional control file, the tool relies on the standard DCF files as much as possible to provide seamless inte-gration to the preceding de-sign flow. The user can con-nect the tool into the device and the tool asks the user, into which known target po-sition for the found device the user wants to install it. After selecting the correct target position, the tool con-figures it based on the DCF, stores configuration, resets and verifies that all changes have been applied.

Phase 7: AnalysisThe last phase in the

design process is analysis (system verification). Net-work design tools offer sig-nal database (DBC) files for analyzers. Single DBC contains description of the whole communication in a single network. If more performance or finer-grain measurement setups are needed, the DBC files can be split into smaller ones to minimize analyzer-process-ing overhead. The same Figure 7: Imported variable synchronization function

56 CAN Newsletter 3/2009

Dev

elop

men

t

Lipowsky Industrie Elektronik GmbH Phone: + 49-(0)6151-93591-0 Fax: -28

Römerstr. 57 D-64291 Darmstadt Contact: info@lipowsky.de www.lipowsky.de

access LIN equipped devices

read, write and display data

monitor bus signals and timing

simulation of LIN master and slaves

control bus from your PC application

LIN-BUS Issues ?

compact and inexpensive solution

isolated USB-LIN interface

supports LIN V.1.2 to V.2.1 direct access to LIN-bus via DLL execution on Windows and Linux PC

operation with PC or standalone

BABY-LIN offers:

Distributed in the USA by DGE Inc. Phone: 248-293-1300

2870 Technology DR www.dgeinc.com

- - EMBEDDED SOLUTIONS CAN - LIN - TOOLS

ASCON

ASCON spa20021 Bollate (Milano) ItalyTel. +39 02 33 33 71Fax +39 02 35 04 243www.ascon.itsales@ascon.it

SigmaPAC®

ProgrammableAutomation ControllerDistributed AutomationSolutions based onCANopen• Advanced PID control• Logic and batch control• Open connectivity

to Most Major Fieldbuses• “OpenPCS” IEC61131-3

Programming System

Other ASCON ProductsControllers, Indicators, Transmitters and Acquisition Systems

CANopen I/O modules

CANopen I/O modules

Actuators & Transmitters

SCADA

Programming

Operator Panels

Control Unit

Ethernet

CANopen