SIST-TP CEN/TR 16815:2016
(Main)CleANopen - Application profile for municipal vehicles
CleANopen - Application profile for municipal vehicles
This Technical Report provides a set of CANopen application profile specifications that describes the CleANopen embedded body control network of municipal vehicles, e.g. refuse collecting trucks.
It specifies the CANopen communication interfaces and the application functionality of several functional elements (virtual devices).
It does not specify CANopen devices.
The CleANopen application profile specifications consist of several parts dealing with the following:
- general definitions;
- functionality of the virtual devices;
- pre defined PDOs and SDOs;
- application objects.
CleANopen - Anwendungsprofil für Kommunalfahrzeuge
CANopen - Profil d’application aux véhicules municipaux
CleANopen - Aplikacijski profil za uporabo na komunalnih vozilih (za zbiranje odpadkov)
To tehnično poročilo vsebuje sklop specifikacij za aplikacijski profil CANopen, ki opisuje vgrajeno mrežo CleANopen za nadzor komunalnih vozil, npr. vozil za zbiranje odpadkov.
Določa komunikacijske vmesnike CANopen in aplikacijsko funkcionalnost več funkcijskih elementov (virtualne naprave).
Ne določa naprav CANopen.
Specifikacije aplikacijskega profila CleANopen zajemajo več delov, v katerih je obravnavano naslednje:
– osnovne definicije;
– funkcionalnost virtualnih naprav;
– vnaprej določeni PDO in SDO;
– aplikacijski objekti.
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TP CEN/TR 16815:2016
01-januar-2016
CleANopen - Aplikacijski profil za uporabo na komunalnih vozilih (za zbiranje
odpadkov)
CleANopen - Application profile for municipal vehicles
CleANopen - Anwendungsprofil für Kommunalfahrzeuge
CANopen - Profil d’application aux véhicules municipaux
Ta slovenski standard je istoveten z: CEN/TR 16815:2015
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
43.160 Vozila za posebne namene Special purpose vehicles
SIST-TP CEN/TR 16815:2016 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TP CEN/TR 16815:2016
---------------------- Page: 2 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815
TECHNICAL REPORT
RAPPORT TECHNIQUE
November 2015
TECHNISCHER BERICHT
ICS 35.240.60; 43.040.15; 43.160
English Version
CleANopen - Application profile for municipal vehicles
CleANopen - Profil d'application aux véhicules CleANopen - Anwendungsprofil für
municipaux Kommunalfahrzeuge
This Technical Report was approved by CEN on 23 February 2015. It has been drawn up by the Technical Committee CEN/TC
183.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2015 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 16815:2015 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
Contents Page
European foreword . 3
1 Scope . 4
2 Normative references . 4
3 Terms and definitions . 4
4 Acronyms . 5
5 Abbreviations . 6
6 General architecture . 6
7 Physical layer specification . 13
8 Error handling . 14
9 Data type specification . 15
10 Object dictionary entries . 15
11 Pre-defined TPDO communication . 52
12 Manufacturer-specific TPDOs . 493
13 Pre-defined RPDO communication . 494
14 Manufacturer-specific RPDOs . 902
15 Pre-defined additional SDO communication. 902
16 Object dictionary . 951
Annex A (normative) Manufacturer-specific TPDOs for unit-specific use . 1094
Annex B (normative) Manufacturer-specific RPDOs for unit-specific use . 1100
Annex C (informative) Measurement process . 1106
Bibliography . 1109
2
---------------------- Page: 4 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
European foreword
This document (CEN/TR 16815:2015) has been prepared by Technical Committee CEN/TC 183 “Waste
management”, the secretariat of which is held by DIN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
This document is based on the version 2.0 of the CiA 422 specification series describes the embedded
body control network of refuse collecting vehicles (RCV). It specifies the CANopen (EN 50325-4)
communication interfaces and the application functionality of several functional elements (virtual
devices). It does not specify CANopen devices.
This document is structured as follows:
st
the 1 part (Clauses 3 to 9) contains general definitions and describes the functionality of the
virtual devices as well as the CANopen physical layer requirements and recommendations.
nd
the 2 part (Clause 10) provides a detailed overview of communication and application
parameters supported by the different virtual devices. Virtual devices include the body controller,
and the change container, compaction, lifter, identification, measuring A and B, bin classification,
washing, truck gateway as well as GPS units. Also a monitoring device is described
rd
the 3 part (Clauses 11 to 15) and its sub-parts specify the pre-defined Process Data Objects (PDO)
and the additional pre-defined SDOs. The pre-defined Transmit-PDOs for all virtual devices ares
specified in Clause 11. This includes the PDO communication parameter set as well as the PDO
mapping parameter set. The corresponding Receive-PDOs are specified in Clause 13. The SDO
communication between bin classification units and measuring units is specified in Clause 15.
th
the 4 part (Clause 16) specifies the application parameters. This covers the process data (mainly
mapped into PDOs), configuration data, and diagnostic information (both mainly transmitted by
SDO communication services). In this clause are defined parameter pools for the measuring units,
and the data read as well as write for identification units. Other introduced parameters include
support profile version, extended status for measuring units and measuring ident controllers.
3
---------------------- Page: 5 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
1 Scope
This Technical Report provides a set of CANopen application profile specifications that describes the
CleANopen embedded body control network of municipal vehicles, e.g. refuse collecting trucks.
It specifies the CANopen communication interfaces and the application functionality of several
functional elements (virtual devices).
It does not specify CANopen devices.
The CleANopen application profile specifications consist of several parts dealing with the following:
general definitions;
functionality of the virtual devices;
pre-defined PDOs and SDOs;
application objects.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO/IEC 646, Information technology — ISO 7-bit coded character set for information interchange
ISO 11898-2, Road vehicles — Controller area network (CAN) — High-speed medium access unit
SAE J1939-71, Recommended practice for a serial control and communication network — Vehicle
application layer
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
CleANopen unit
virtual device that provides functional elements specified in this application profile
3.2
functional element
atomic application function
3.3
virtual device
part of the logical device as defined in [CiA301]
3.4
left side
when viewing forward, the left side
4
---------------------- Page: 6 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
3.5
pitch
angle from the front to the back of the vehicle (see Figure 1)
Figure 1
3.6
right side
when viewing forward, the right side
3.7
roll
angle from the left to the right side of the vehicle (see Figure 2)
Figure 2
4 Acronyms
The acronyms given in documents CiA301, CiA413 series and SAEJ1939 apply for this standard, too.
BCU Bin classification unit
BC Body controller
MIC Measuring ident controller
CAN Controller area network
CCU Change container unit
COB Communication object
COB-ID COB identifier
CSDO Client SDO
CU Compaction unit
GPS Global positioning system
5
---------------------- Page: 7 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
GPSU GPS unit
IDU Identification unit
IVN In-vehicle network
LSB Least significant bit
LU Lifter unit
MSB Most significant bit
MU Measuring unit
SSDO Server SDO
TGU Truck gateway unit
WU Washing unit
5 Abbreviations
Acc. Access
Cat. Category
const constant
ro read-only
rw read/write
6 General architecture
6.1 General
This application profile specification describes the virtual devices of municipal vehicle bodies
(CleANopen units). Figure shows a simple example: The BC virtual device controls the overall system,
however the other virtual devices communicate directly by means of PDOs. The virtual interfaces are
implemented as CANopen interfaces or as CANopen device internal interfaces if the virtual devices
reside in the same CANopen device. If the virtual interfaces between virtual devices are implemented as
CANopen interfaces they use SDO or PDO services to read or write application objects.
6
---------------------- Page: 8 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
Figure 3 — Virtual devices interconnection (example)
Most of the application objects are mapped into pre-defined PDOs.
If an implemented application object is not mapped into one of the pre-defined PDOs, other CANopen
devices can access them by means of SDO.
The CSDOs, which corresponds to the Default SSDO, shall be implemented always in the BC virtual
device.
CANopen devices compliant to this application profile without BC functionality shall not implement any
CSDO that relates to Default SSDO.
For systems not comprising a BC, additional SDO channels are needed.
This application profile pre-defines some SDO channels for dedicated functionality.
For some virtual devices up to eight instances are specified. The instances with the very same number
belong to one sub-system, e.g. LU 1, MU-A 1, and WU 1 belong to sub-system 1; LU 2, MU-B 2, and WU 2
belong to sub-system 2.
When the BC is implemented, it is connected to all sub-systems.
6.2 Communication to the in-vehicle networks
The communication to the truck’s in-vehicle networks is possible by means of truck gateways provided
by the truck manufacturer. There are different implementations on the market as shown in the
examples given in Figure 4.
In the past, most truck manufacturers provided digital and analog inputs and outputs (a). In this
implementation example, the TGU only transmits and receives those objects that are not used by the BC.
It is also possible to implement the TGU in a generic I/O module compliant to [CiA 401 (b)]; it provides
than TGU-compliant PDOs.
Nowadays, some truck manufacturers provide a [CiA 413] or [CiA 422] compliant truck gateway (c). In
this implementation example, the truck gateway provides TPDOs and RPDOs that correspond to those
provided by the TGU.
7
---------------------- Page: 9 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
Figure 4 — Truck gateway implementation examples
If the TGU is implement in the very same CANopen device as the BC, the communication can be done
device-internally without transmitting COBs on the CAN network.
6.3 Numbering of the lifter units (LUs)
The LUs can be positioned on the vehicle in different ways. The numbering of the LUs as given in this
clause shall be used for the vehicles implementing this specification. The lifter units shall be
enumerated from left to right while standing in front of the lifter. One compartment consists of four LUs
st
in maximum. The 1 compartment consists of LUs 1 to 4. If there is a second compartment on the truck
(e.g. for organic waste) it consists of the LUs 5 to 8. For other configurations it is up to the system
integrator to provide the LU numbering.
Figure 5 specifies the LU numbering for the single compartment front loader.
Figure 6 specifies the LU numbering for the single compartment rear loader.
Figure 7 specifies the LU numbering for the single compartment left side loader.
Figure 8 specifies the LU numbering for the single compartment right side loader.
Figure 9 specifies the LU numbering for the two-compartment rear loader.
Figure 10 specifies the LU numbering for the two-compartment combined rear and side loader.
8
---------------------- Page: 10 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
Figure 5 — LU numbering for the single compartment front loader
Figure 6 — LU numbering for the single compartment rear loader
Figure 7 — LU numbering for the single compartment left side loader
9
---------------------- Page: 11 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
Figure 8 — LU numbering for the single compartment right side loader
Figure 9 — LU numbering for the two compartment rear loader
Figure 10 — LU numbering for the two compartment combined rear and side loader
6.4 Virtual device description
6.4.1 General
Every virtual device represents a specific functional unit. Some of them can be installed multiply in one
application.
10
---------------------- Page: 12 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
The following brief descriptions give an overview on the functionality of the different virtual devices.
The supported application objects are summarized in the clause on functionality of the virtual devices
of this application profile.
The detailed PDO interfaces are specified in the appropriate clause on pre-defined Process Data Objects
(PDO) of this application profile.
The detailed application objects are specified in the appropriate clause of this application profile.
6.4.2 Body controller (BC)
The BC is the interface to the hydraulic and the pneumatic power supply of the disposal vehicle. Related
to its operating mode some other units request optionally the supply of pressure from the BC. Other
units need optionally the BC status information (e.g. to estimate the intervals of maintenance) for their
operations.
6.4.3 Bin classification unit (BCU)
The BCU classifies a waste bin attached to the lifter. Other units — virtual devices — use this
classification for sequence control purposes:
LU lifts and empties or does not lift and does not empty the bin.
WU washes or does not wash the bin.
The BCU implements optionally the measuring ident controller (MIC) functional element. The MIC
combines the results of identification (through the IDU) and a measuring (through the MU). The MIC
coordinates the correct matching of measured values and the waste bin using information from IDU and
LU. The MIC can detect (using the LU) the emptying of a waste bin with or without transponder.
There are up to eight BCU (1 to 8) instances possible in one logical CleANopen network.
6.4.4 Change container unit (CCU)
The CCU is used for changing the collecting reservoir (container) of a disposal vehicle. It is also used for
providing information about the mounted container (fixed or changeable).
6.4.5 Compaction unit (CU)
The CU is used for compacting the waste and for providing information about the compaction process. It
is used for synchronizing and for coordinating its activities with the LU. Other units use optionally the
CU status information (e.g. to estimate the intervals of maintenance).
6.4.6 GPS unit (GPSU)
The GPSU is used for providing geographical positioning as well as date and time information, which is
recorded by other units.
6.4.7 Identification unit (IDU)
The IDU is used for identifying waste bins by identifying a transponder attached to the waste bin. It can
also write information to the transponder. The identification process is started by means of an explicit
11
---------------------- Page: 13 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
start command received from the MIC or automatically, when the IDU is supporting continuous
identification.
6.4.8 Lifter unit (LU)
The LU is used for controlling the emptying procedure of a single waste bin. It is also used for informing
additionally other units:
about the state of a lifter,
if a waste bin is attached or not,
about the position of the lifter and whether the lifter is in the measuring window or not.
It is possible to configure the LU. For example, that the lifter adjust its speed in the emptying process.
This is needed to consider the particular features of some other units (e.g. MU). The LU is used for
communicating with the CU to inform it whether the CU is or not in operation. The LU is used for
communicating with the BC to demand power supply (e.g. hydraulic).
There are up to eight LU (1 to 8) instances possible in one logical CleANopen network.
6.4.9 Measuring unit (MU)
The MU is used for issuing measurement results acquired while treating the bin or the container. The
MU is used for abstracting particularly the functionality of scales or devices to measure the volume. As
scale the MU is used for measuring the weight of waste in the waste bin. As volume measurement device
the MU provides the volume of the disposed waste.
In some cases, it is necessary to measure up to two physical values on one lifter (e.g. weight and
volume). For this case, the Measuring Unit A and Measuring Unit B are provided.
Especially for scales, modes for manual and automatic measuring are implemented. While automatic
measurement the scale controls the entire weighing process. While manual measuring the user is
responsible for control of the measuring process.
There are up to eight MU-A (1 to 8) and up to eight MU-B (1 to 8) instances possible in one logical
CleANopen network.
6.4.10 Truck gateway unit (TGU)
The TGU is used for providing the access to the in-vehicle networks of the truck.
6.4.11 Washing unit (WU)
The WU is used for cleaning the waste bins. The LU provides the waste; it allows and starts the washing
process. The WU informs about the state of the washing process and the washing equipment. While
washing, no movement of the lifter is allowed.
There are up to eight WU (1 to 8) instances possible in one logical CleANopen network.
12
---------------------- Page: 14 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
7 Physical layer specification
7.1 General
The CAN interface shall be compliant to the definitions and recommendations given in ISO 11898-2 and
[CiA 301] and [CiA 303-1].
7.2 Bit rate
The physical CANopen device compliant to this application profile shall provide a default bit rate of 250
kbit/s and shall use the bit timing as specified in [CiA 301]. Other bit rates defined in [CiA 301] can be
supported.
7.3 Bus topology
The bus topology shall be compliant to the definitions and recommendations given in ISO 11898-2,
[CiA 301] and [CiA 303-1].
7.4 Bus cable
The bus cable used shall be compliant to the definitions and recommendations given in ISO 11898-2
and [CiA 303-1].
7.5 Bus connector
The bus connector used shall be compliant to the definitions and recommendations given in
ISO 11898-2 and [CiA 303-1].
7.6 Node-ID assignment
The assignment of a node-ID is required for every physical CANopen device. The assignment of
node-IDs is manufacturer specific. For a better plug and play behaviour the assignment of the node-IDs
is recommended as shown in Table 1.
Table 1 — Recommended node ID assignment
Device Node-ID
Body controller (BC) 10
Compaction unit (CU) 11
Container change unit (CCU) 12
Lifter unit (LU) 1 to 8 20 to 27
Bin classification unit (BCU) 1 to 8 30 to 37
Identification unit (IDU) 1 to 8 50 to 57
Measuring unit A (MU-A) 1 to 8 60 to 67
Measuring unit B (MU-B) 1 to 8 70 to 77
Washing unit (WU) 1 to 8 80 to 87
Truck gateway unit (TGU) 89
GPS unit (GPSU) 90
Monitoring device 1 to 8 91 to 98
13
---------------------- Page: 15 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
If more than one virtual device is integrated to one CANopen device, the lowest node-ID shall be used.
8 Error handling
8.1 Principle
Emergency messages shall be triggered by internal errors in the physical device and they are assigned
to high priority to ensure that they get access to the bus without latency. By default, the Emergency
messages shall contain the error field with pre-defined error numbers and additional information.
8.2 Error behaviour
If a serious device failure is detected the physical device shall enter by default autonomously the
pre-operational state. If object 1029 is implemented, the physical device can be configured to enter
h
alternatively the stopped state or remain in the current state in case of a device failure. Device failures
shall include the following communication errors:
Bus-off conditions of the CANopen interface,
Life guarding event with the state ‘occurred’;
Heartbeat event with state ‘occurred’.
Severe device errors also can be caused by device internal failures.
8.3 Additional error code specification
Devices compliant to this application profile specification can use the error codes as defined in
[CiA 301].
The third byte of the Emergency message (first byte of) described in the EMCY protocol in [CiA 301]
shall be used as defined in Figure 11.
7 4 3 0
Virtual device number (see Table 2) Number of virtual device (1 to 8)
MSB LSB
Figure 11 — Byte number 3 of the EMCY message
14
---------------------- Page: 16 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
Table 2 — Virtual device numbers
Virtual device name Number
01
BC
h
03
CCU
h
04
CU
h
05
LU
h
06
IDU
h
07
MU-A
h
08
BCU
h
09
WU
h
0B
MU-B
h
0C
GPSU
h
0D
TGU
h
9 Data type specification
The application objects specified in this application profile use the data types defined in [CiA 301]. The
BOOLEANn data type is specified in this part of the application profile.
Data of basic data type BOOLEANn is represented as bit sequences of length n bit. The value attains a
combination of TRUE and FALSE. The value TRUE (res. FALSE) is represented by the bit value 1 (res. 0).
The profile-specific basic data types are specified in Table 3.
Table 3 — Profile specific basic data type definitions
Index Object Name Examples
0060 bit , bit
DEFTYPE BOOLEAN2
h 1 2
0061 bit , bit , bit
DEFTYPE BOOLEAN3
h 1 2 3
bit , bit , bit ,
1 2 3
0062
DEFTYPE BOOLEAN4
h
bit
4
10 Object dictionary entries
10.1 General
Every CANopen device compliant with this application profile supports some general communication
and application objects as well as virtual device specific application objects. It consists of one or more
virtual devices as defined in [CiA301]. A virtual device shall not be distributed to several CANopen
devices. Each virtual device supports a set of mandatory function-depending application objects and
can implement additionally a variable set of optional application objects.
15
---------------------- Page: 17 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
All objects are specified by means of object and entry description as defined in [CiA301]. The
description attributes are defined in [CiA301]. The category attribute indicates, if an object shall be
supported (Mandatory) or can be supported (Optional). The access attribute indicates, if an object is
constant (const), read only (ro), read/write (rw) or write only (wo). Read only indicates that this object
shall not be written via the bus; read/write allows to read and to write this object; and write only means
that this object shall be not read via the bus. The default value attribute defines the behavior of objects
after power-on or NMT application reset.
The information given in 10.3 about application objects mapped into PDOs is informative, except the
mapped dummy objects, they shall be mapped.
10.2 General communication objects
10.2.1 General
CANopen devices compliant with this application profile use default values for some communication
objects (1000 to 1FFF ), which are not specified in all details in [CiA301]. In the following sub-clauses
h h
these default values are specified in details.
10.2.2 Object 1000 : Device type
h
This object describes the type of device and its functionality. The object and entry description are given
in [CiA301]. Figure 12 shows the object structure and Table 4 defines the values for the virtual device
code field.
31 24 23 16 15 0
Device profile number: 422
Virtual device code reserved (0)
d
MSB LSB
Figure 12 — Object structure
Table 4 — Virtual device code values
Code Function
01
Body controller (BC)
h
02
reserved for compatibility reason
h
03
Change container unit (CCU)
h
04
Compaction unit (CU)
h
05
Lifter unit (LU)
h
06
Identification unit (IDU)
h
07
Measuring unit A (MU-A)
h
08
Bin classification unit (BCU)
h
09
Washing unit (WU)
h
16
---------------------- Page: 18 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
Code Function
0A
reserved for compatibility reason
h
0B
Measuring unit B (MU-B)
h
0C
GPS unit (GPSU)
h
0D
Truck gateway unit (TGU)
h
0E
reserved for future use by CiA
h
::::: :::::
FD
reserved for future use by CiA
h
FE
Monitoring device
h
FF
reserved
h
10.2.3 Object 1001 : Error register
h
The device profile specific bit in the error register is reserved for future use. The object and entry
description are given in [CiA301].
10.2.4 Object 1016 : Consumer heartbeat times
h
This object shall be implemented, if the CANopen device receives event-triggered PDOs. The consumer
heartbeat times are manufacturer-specific. The object and entry description are given in [CiA301].
10.2.5 Object 1017 : Producer heartbeat time
h
This object shall be implemented. The heartbeat producer time shall be set to > 0 by default; the value is
manufacturer-specific. The object and entry description are given in [CiA301].
10.2.6 Object 1018 : Identity
h
This object is mandatory and contains in sub-index 01 the unique vendor-ID assigned by CiA.
h
Sub-index 02 to 04 are optional. The object and entry description are given in [CiA301].
h h
10.2.7 Object 1029 : Error behavior
h
This object specifies to which state the physical device shall be set, when a communication error or a
device internal error is detected. Besides the specification given in [CiA301] the following sub-indexes
can be implemented optionally. If the entire object is not implemented the CANopen device shall behave
as the default values define.
Table 5 defines the values.
17
---------------------- Page: 19 ----------------------
SIST-TP CEN/TR 16815:2016
CEN/TR 16815:2015 (E)
Table 5 — Value definition
Value Definition
Change to NMT state Pre-operational
00
h
(only if currently in NMT state Operational)
01
No change of the NMT state
h
02
Change to NMT state Stopped
h
The object description and the entry description for sub-index 00 and 01 are given in [CiA301].
h h
Table 6 specifies the entry description for sub-index 02 .
h
Table 6 — Entry description for sub index 02h
Attribute Value
02
Sub-index
h
Description Internal device error
Access rw
Entry category Optional
PDO mapping No
00 to 02
Value range
h h
00
Default value
h
10.2.8 Object 1F80 : NMT startup
h
This object shall be implemented. The object entry description is given in [CiA302-2]. The default value
shall be the value for self-starting devices (see [CiA303-2]).
10.3 Supported application objects, PDOs, and SDOs
10.3.1 General
If a specif
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.