SI-Unit and scaling management in CANopen

Various kind of incon-sistencies have been

typical problems in design of distributed control sys-tems. The first solved issue was an automated genera-tion of signal and parameter abstraction from CANopen project avoiding the incon-sistent names between ap-plication software and com-munication [1]. The use of meta information of signals and local parameters, such as name, minimum, maxi-mum and default values has already been implemented to avoid the most common inconsistencies [2].

Producers NMT state is used for monitoring the status of signal producer devices [2] and connections between the devices [5]. Name, network and node identifiers, object index and sub-index are included into meta information of re-mote parameters to avoid inconsistent parameter ac-cesses [2]. A method for management of CANopen emergency error codes has been introduced to fill the main missing feature of CANopen [4].

One of the most sig-nificant remaining source of inconsistencies in system designs is, how to apply the SI-Units and scaling used by the sensors, actuators and I/O devices to the application programs. Main challenge during the de-sign is that both SI-SI-Unit and scaling may need to be adjusted during the de-velopment and it shall be guaranteed that same val-ues will be used by both producer and consumer devices.

CANopen provides an excellent basis for sys-tematic management of the SI-Unit and scal- ing information by defining representation of SI-Units with prefixes [6]. Some de-vice profiles already sup-port definition of the signal physical units via object dictionary [11], [13] or fixed unit with adjustable scaling [12], [14]. Support of more detailed scaling than just a prefix varies between the device profiles and imple-mentation, because option-al objects may also have an effect on SI-Unit and scal-ing details.

Though there is not dedicated meta informa-tion for SI-Unit and scaling of object dictionary objects, such information can be

synthesized from various parameter object values.

The approach can-not cover all signals and parameters, but provides an excellent workaround while better support is in-cluded into corresponding CANopen standards.

The most common-ly used device profiles are reviewed and basics of CANopen projects are presented first. Then, an example implementa-tion using combined pres-sure and temperature transmitter is described in more detailed level. After description of the imple-mentation, discussion of the results and notices are presented. The con-clusions are set as a last topic.

Author

Dr. Heikki Saha TK Engineering

P.O. Box 810FI-65101 Vaasa

Tel.: +358-6-35763-00 Fax: +358-6-35763-20

info@tke.fi

Linkswww.tke.fi

CompanyTKE Engineering,

CiA member since 2006, focuses on CAN education and training,

engineering, application-specific developments,

and import as well as sales. The offered

products include CAN PC-interface modules, data-loggers, displays, network infrastructure

components, and tools as well as software.

Dr. Heikki Saha

Figure 1: The seven base SI-Units and their interdependencies (clockwise from the top: Kelvin (temperature), second (time), meter (length), kilogram (mass), candela (luminous intensity), mole (amount of substance, and Ampere (electric current)

30 CAN Newsletter 3/2013

CA

Nop

en

SI-Units in CANopen device profiles

Only some the most com-mon device profiles are cov-ered by the review of this article. The presented con-cept also applies for other profiles. The purpose of the review is to briefly summa-rize the objects, where SI-Unit and scaling information is available. Readers are advised to read the device profile documents for fur-ther details.

I/O devices accord-ing to CiA 401 can support units only if an optional ob-jects are supported [9].

Unit for analog inputs is located at 6430h and for analog outputs at 6450h. However, because of the general purpose nature of I/O devices, there are sig-nificant risks for inconsis-tency. First, sensors and actuators cannot be unam-biguously identified over an-alog signal path. Therefore it cannot be guaranteed that the connected sensor or ac-tuator supports the signal type, for which the I/O de-vice has been configured. Invalid combinations may look working properly over a wider signal value range, which may lead to incor-rect behavior or even safety risk. Furthermore, the men-tioned objects define the SI-Unit, but no scaling, which may be implemented differ-ently in different devices. Units are typically not used for outputs of joysticks and pedals. Joystick and ped-al devices are indicated by higher word of the device type [10].

Transmitters accord-ing to CiA 404 are sim-ple to manage. There are a set of objects defining the units and scalingof each channel [11].

SI-Unit with prefix is lo-cated at 6131h and the num-ber of digits supported by the channel at 6132h. Scal-ing and offsets are used for calibration of the sensing element. Transmitters has been selected as a proof of concept because of the

simple and unambiguous approach along with the common implementations. Transmitters can be main-ly identified based on the higher word of device type – pressure and temperature transmitters support only analog inputs.

Encoders are even simpler, because CiA 406 clearly defines how to con-figure the encoder output signals. Furthermore, rota-ry and linear encoders have dedicated objects and the detailed encoder type is in-dicated in the higher word of the device type [12]. Mea-suring step is given directly as µm for linear encoders. For rotary encoders, mea-suring step shall be comput-ed from the number of steps per revolution. Measuring step for linear encoders is located at 6005h and the number of steps per revo-lution for rotary encoders is located at 6001h. The unit of speed information is always measuring units per sec-ond. Most common param-eters, such as preset and CAM thresholds, use the same unit with scaled out-put signal. If scaling is dis-abled, default values of the scaling objects can be used instead. Scaling and preset are activated from operating parameters object, which is located at 6000h.

Hydraulic drives are covered by CiA 408. SI-Unit with prefix may be defined for each set-point and ac-tual value signal [13]. If unit is not defined, internal res-olution shall be used as a relative set-point or actual value. Internal resolution is defined in the device pro-file and it may be either 16 bit (IR) or 32 bit (IR32). For example, set-point for spool position control is located at 6300h and pressure control at 6380h. Sub-index one of each object is used for the value itself.

SI-Units and prefixes are given in optional sub-in-dexes two and three. Same principle applies for actu-al spool position and actu-al pressure located at 6301h

SENSORS FOR MOBILE MACHINES

Absolute Rotary Encoders and Inclinometers

Reliable Measurement under Harsh Conditions

High Protection Class: IP69K

Fieldbus and Analog Interfaces

Safety and ATEX – Ex-Proof

Versions Available

Successfully Integrated in

Concrete Pumps, Drilling Machines,

Working Platforms, Cranes, Wheel Loaders,

Leader Masts and More

POSITALGermany, Singapore and USA

www.posital.com, info@posital.com

www.posital.com

objects may be utilized in applica-tion programming. Device commis-sioning section provides target lo-cation informa-tion, which may be used e.g. in diag-nostics [3], [5] and generating unique variable names. Information of de-vice type and iden-tity may be used for determining the type of target de-vice and required format and con-tents of the export.

Conversion processUnit synchroniza-tion has been in-cluded as part of the IEC 61131-3 communication abstraction gen-

eration presented earlier [1], [2]. There has been al-ready a reservation for unit information in the present-ed code examples. The abstraction generation is divided into three parts – CANopen project parse, project analysis and device specific abstraction export.

CANopen project parser just reads project information into memory as efficiently as possible. Parser independent of the analysis and export en-ables further improvement

System design tools may use their own file formats, but the main contents is al-ways equal and it is easy to convert the proprietary files into standard format before other conversions. It is pre-sented earlier, how calls to external add-on applica-tions for e.g. code header export can be included into EDS and DCF files [1].

Main information source is included into ob-ject dictionary description part of DCF files [2]. All de-fined meta information of

and 6381h respec-tively. Axis con-trol set-points and actual values are included also as pairs, both with optional SI-Units and prefixes. Set-points and actual values are located at 6500h and 6501h for velocity control, at 6580h and 6581h for force or pres-sure control and at 6600h and 6601h for position control.

Inclinometers follow device pro-file CiA 410. Main parameter for in-clinometers is just a resolution of the output angles at 6000h [14].

The first po-tential source for errors is, that if 16-bit output signals are used, maximum resolu-tion cannot be supported for the full 360 degrees mea-suring range. Main parame-ters, presets and differential offsets are using same unit with the output signals.

CANopen project and DCF filesEach CANopen project con-sists of a set of DCF files – one for each device [7]. The DCF-files forming a project are listed in an additional project file, nodelist.cpj [2].

[6131sub1] ParameterName=P_Physical_Unit ParameterValue=0x004E0000 [6131sub2] ParameterName=T_Physical_Unit ParameterValue=0x002D0000 [6132sub1] ParameterName=P_Decimal_Digits ParameterValue=3 [6132sub2] ParameterName=T_Decimal_Digits ParameterValue=0 [9130sub1] ParameterName=TestPres DataType=0x4 AccessType=rwr PDOMapping=1 [9130sub2] ParameterName=TestTemp DataType=0x4 AccessType=rwr PDOMapping=1

Figure 2: Excerpt of an example transmitter DCF with output signal and SI-Unit

SI-UnitsThe International System of Units

(SI-Units) represents the physical units of

the metric system. It is internationally

standardized in the ISO/IEC 80000 series

of standards. The standard also specifies

the International System of Quantities (ISQ). The

SI-Units have been nearly globally adopted: Only Liberia, Myanmar,

and the United States of America have not

adopted SI-Units as their official system of weights

and measures.

(* @GLOBAL_VARIABLE_LIST := TEST_MAIN_Vars *) (* @PATH := '' *) VAR_GLOBAL : (* Volatile variables from D001.DCF at Thu Jul 04 18:34:35 2013 *) TestPres AT %MD256: DINT := 0; TestTemp AT %MD257: DINT := 0; : (* Variable details from D001.DCF at Thu Jul 04 18:34:35 2013 *) dTestPres: dtDINT := ( ParName := 'TestPres', Unit := 'mbar', DefVal := 0, MinVal := 0, MaxVal := 400000, Status := 0); dTestTemp: dtDINT := ( ParName := 'TestTemp', Unit := 'deg C', DefVal := 0, MinVal := 0, MaxVal := 1250, Status := 0); END_VAR (* @OBJECT_END := TEST_MAIN_Vars *)

Figure 3: Excerpt of an example signal abstraction with SI-Units

32 CAN Newsletter 3/2013

CA

Nop

en

to e.g. support XDC files instead of DCFs when for-mat becomes finalized and commonly adopted in the industry. Optionally nodel-ist.cpj may be replaced with proposed nodelist.graphml [3], if adopted as part of CiA 311 [8] as proposed. Pa-rameter values are defined during the system design, based on the system re-quirements. Thus, EDS files cannot be used as a source.

Analysis part is source and target format indepen-dent, which enables flex-ible analysis of the project information and synthesis of information. Information synthesis is required, be-cause a lot of information is distributed either in multiple objects of each DCF file or even in multiple DCF files. PDO connections between the devices can be followed based on CAN-IDs. Con-nections can be expanded into signal level by reading corresponding mapping in-formation. After finding out signal connections, units need to be determined. As described earlier, support-ed device profile shall be read first. Then the sup-ported units and scaling can read and computed from corresponding objects and added to the meta in-formation of the signals. A simplified excerpt of a source DCF is presented in Figure 2.

The use of indepen-dent export enables de- vice specific outputs. It

is required because dif-ferent formats are used by different IEC 61131-3 development environ-ments and because the exact contents of the ex-port requires some target API specific declarations. In the future the variation will be reduced, because PLCopen has defined an XML-based standard in-formation interchange for-mat [15]. The target may be automatically detect-ed based on the values of device type and identity objects. An excerpt of tar-get signal abstraction with full meta information is pre-sented in Figure 3. Scaling is embedded as a part of the unit in the example, because a standardized approach does not exist.

Discussion and conclusionInternal configuration af-fects on the units in most of the devices and therefore it is best to retrieve the units and scaling from the system project into abstraction lay-er of application software. Configuration is stored in standard DCF-files, where it can be accessed in a ven-dor, tool and device inde-pendent way. One interest-ing topic for future research is, how the device parame-terization can be simplified.

The concept may be expanded to cover param-eters and other device pro-files, too. Main parameters

Figure 4: HMIs may convert the SI-Units to national units for convenience, but the CANopen devices must not communicate non SI-Units

Control units

from the ESX®-family

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

ESX®-3XL32bit-controller with 136 I/Os, Approved for safety related applications (SIL2, PLd)

ESX®-IOXCAN-Bus I/O-Modules

ESX®-TC3Teleservice module with GSM, GPRS, GPS, Wi-Fi, Bluetooth®, Ethernet and USB

Pioneering new technologiesPioneering new technologies

Pressure transmitter

with thin-film measuring element

• especially for applications in mobile machines and commercial vehicles• highest media compatibility• pressure ranges from 0 ... 25 bar to 0 ... 1000 bar

(Overall accuracy in the temperature compensated range: 1%)• max. media temperature 150°C / max. ambient temperature 125°C• wetted parts and case in stainless-steel• CAN-Bus interface

ESX®

M01-CAN

ESX

®-3

XL E

SX®-IO

X E

SX®-T

C3

ExhibitionsAgritechnica, Hannover10. – 16.11.2013Halle 17, Stand A3410. – 16.11.2013Halle 17, Stand A34

www.sensor-technik.de

Sensor-Technik Wiedemann GmbHAm Bärenwald 6 · 87600 Kaufbeuren GermanyTelephone +49 (0) 83 41-95 05-0

SPS/IPC/DRIVES, Nürnberg26. – 28.11.2013Halle 7, Stand 7-169

Anzeige_CAN-Newsletter_01-2013 - ESX, M01-CAN - 100x297.indd 1 21.06.2013 13:23:29

and pending warnings and alarms are clearly in-dicated in a predefined format. Hydraulic drives support fixed format ob-jects for various device and program control purposes. Resolution and operating parameters are available in a predefined format for inclinometers.

SI-Unit and scaling information may also be added into system design tools to enable they to include such information into communication data-bases (DBC) to improve network analyses. Both DBC and many analyzer programs already support signal scaling and physi-cal units. One approach could be standardization of the presentation of signal and parameter meta information – especially scaling – in IEC 61131-3 as co-operation of CiA and PLCopen.

Following the CANopen device profiles and stan-dard storage formats is essential, also to get SI-Unit and scaling manage-ment working. Traditional CANopen concepts provide

of CANopen encoders, pre-set and CAMs are using the same SI-Unit and scal-ing with the position signal. CANopen transmitters use the same scaling for prima-ry output signal, net output after tare function as well as optional controller and lim-it functions using input sig-nals. Same defined scaling is used for all signals and parameters in CANopen in-clinometers. Drive profiles are the most complex and will need to be analyzed further.

All device profiles support objects using pre-defined format, from which type definitions may be de-fined in code header mod-ules. In the future, along with the CiA 311, such in-formation may be included into the XDD and XDC files. Such objects are e.g. polar-ity, filter enable, output error mode control and transmis-sion event control objects for I/O devices. Transmitters support additionally sensor type, filtering and operation-al mode controls. Encoders support operational mode control and status in a fixed format. Both supported

good basis for unit manage-ment, without dependen-cies on system tools, device vendors or types. The ap-proach may be easily im-proved further. The most essential is to get the XDD/XDC formats finalized and into use because of more complete support of object units and enumeration.

Systematic and auto-mated SI-Unit and scaling management will increase the design process perfor-mance further by reduc-ing a need to read written manuals and enter such parameter values manually as a raw values. However, the most significant benefit is an avoidance of system configuration inconsisten-cies in projects, caused by the human mistakes.

Especially ever in-creasing functional safe-ty requirements demand the realization of designed safety integrity level in sys-tem assembly and service. Systematic information management has a key role, because most of the design information inconsisten-cies potentially decrease the safety performance of systems.

There are fixed val-ues for units and scaling in the simplest devices and it is wasting of memory to include corresponding constant information in read-only objects.

The information is mostly needed only in de-sign time, one approach could be to introduce a to-tally new access type – info – for objects, for which the EDS files contain important constant value information for design tools but which are not implemented in the devices. Another approach could be to introduce a new object flag to indicate that an object is for information only and not implement-ed in the device. Modern systematic and automated design information manage-ment requires all possible meta information to be able to provide maximum efficiency.

References[1] Saha H., Wikman M., Nylund P., CANopen network design

and IEC 61131-3 software design, CAN Newsletter 1/2009, pp. 52–58

[2] Saha H., Improving development efficiency and quality of distributed IEC 61131-3 applications with CANopen system design, 13th iCC proceedings (2012), pp. 10-15 – 10-21

[3] Helminen M., Salonen J., Saha H., Nykänen O., Koskinen K. T., Ranta P., Pohjolainen S., A New Method and Format for Describing CANopen System Topology, 13th iCC proceedings (2012), pp. 06-11 – 06-18

[4] Saha H., Experimental CANopen EEC management, CAN Newsletter 1/2013, pp. 12–18

[5] Saha H., Exception management in CANopen systems, CAN Newsletter 2/2013, pp. 12–17

[6] CiA 303-2: Representation of SI-Units and prefixes[7] CiA 306-1: CANopen Electronic datasheet – Part 1: General

definitions and electronic data sheet specification[8] CiA 311: CANopen device description – XML schema

definition[9] CiA 401-1: CANopen profile for I/O modules – Part 1:

Generic I/O modules[10] CiA 401-2: CANopen profile for I/O modules – Part 2:

Joysticks[11] CiA 404: CANopen device profile for measurement devices

and closed-loop controllers[12] CiA 406: CANopen device profile for encoders[13] CiA 408: CANopen device profile for fluid power technology

proportional valves and hydrostatic transmissions[14] CiA 410: CANopen device profile for inclinometers[15] XML Formats for IEC 61131-3, Technical Paper, PLCopen

Technical Committee 6, Version 2.01 – Official Release, PLCopen, 2009, 80 p.

Prefix multiple codes

01h: 101 = deca (da)02h: 102 = hecto (h)

03h: 103 = kilo (M)06h: 106 = mega (M)

09h: 109 = giga (G)0Ch: 1012 = tera (T)0Fh: 1015 = peta (P)12h: 1018 = exa (E)

Prefix fraction codes

FFh: 10-1 = deci (d)FEh: 10-2 = centi (c)FDh: 10-3 = milli (m)

FAh: 10-6 = micro (µ)F7h: 10-9 = nano (n)F4h: 10-12 = pico (p)

F1h: 10-15 = femto (f)EEh: 10-18 = atto (a)

34 CAN Newsletter 3/2013

CA

Nop

en

www.can-cia.org

For more details please contact the CiA office at marketing@can-cia.org

Sponsored by Ixxat Automation

Eurosites République in Paris (FR), November 12 - 13, 2013

Session I: Keynotes

Dr. M. Schreiner (Daimler): CAN FD from a view point of an OEM

n.n.: CiA 447 for special purpose car assistant

Session II: CAN FD applications

P. Decker (Vector Informatik): High speed reprogramming and calibration with CAN FD: A case study

Dr. G. Hickman (Etas): Speed up your calibration with CAN FD

Dr. C. Quigley (Warwick Controls): The potential of CAN FD technology to impact upon FlexRay

Session III: Network design

I. Amato (Fiat Group Automobiles): BE/E-architecture exploration for multiple busses at FGA using a simulation tool

D. Lopez (Freescale): Convergence of bandwidth, robustness and energy saving challenges on CAN physical layer

N. Navet (University of Luxemburg): Quantile-based performance evaluation on CAN

Session IV: CAN FD device design

D. Leu (Inicore): Next generation CAN FD controller core

K. Lennartsson (Kvaser): How to implement and utilize high bit-rate in your system

F. Hartwich (Robert Bosch): Bit time requirements for CAN FD

Session V: Physical layer

M.-M. Hell (Infineon): The physical layer in the CAN FD world

M. Kresta (ON Semiconductor): ECU with simulated partial networking functionality: An alternative approach to ISO 11898-6 CAN transceivers

R. Lieder (Renesas Electronics Europe): Cost and energy efficiency for partial / pretended networking on CAN

Session VI: Verification

D. Bollati (C & S group): CAN FD conformance testing: Minimum requirement to safeguard interoperability

A. Lekidis (Verimag): A model-based design flow for CAN-based systems

Dr. H. Saha (TK Engineering): Analysis of residual errors and their consequences in CANopen systems

Session VII: Gateway solutions

R.-A. Lima de Cristo (Aker Solutions): Characteristics of CAN for subsea equipment and description of a compatibility test method

Gladys Diaz (University of Paris 13): UML model of a gateway for the interconnection of IEEE 1609 and Controller Area Network

Dr. L. Rauchhaupt (ifak e. V.): Coexistance considerations for wireless CAN systems with safety requirements

Session VIII: CAN FD system design

S. Monroe (Texas Instruments): Solutions of CAN and CAN FD in a mixed network topology

Dr. M. Merkel (Ixxat Automation): CANopen on CAN FD

A. Mutter (Robert Bosch): Calculation of the CAN FD oscillator tolerance

14th international CAN conference