SIST EN 16815:2019
(Main)CleANopen - Application profile for municipal vehicles
CleANopen - Application profile for municipal vehicles
This European Standard 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
CleANopen - Profil d’application aux véhicules municipaux
Le présent document fournit un ensemble de spécifications des profils d’application CANopen qui
décrivent le réseau de contrôle de caisse embarqué CleANopen des véhicules municipaux, par exemple les camions de collecte des déchets. Il spécifie les interfaces de communication CANopen et les fonctionnalités de l’application de plusieurs
éléments fonctionnels (dispositifs virtuels). Il ne spécifie pas les dispositifs CANopen.
Les spécifications des profils d’application CleANopen sont composées de plusieurs parties traitant des points suivants :
— définitions générales ;
— fonctionnalités des dispositifs virtuels ;
— objets PDO et objets SDO prédéfinis ;
— objets d’application.
CleANopen - Aplikacijski profil za komunalna vozila
Ta evropski standard podaja nabor 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 objekti PDO in SDO;
– aplikacijski objekti.
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.CleANopen - Aplikacijski profil za komunalna vozilaCleANopen - Anwendungsprofil für KommunalfahrzeugeCleANopen - Profil d’application aux véhicules municipauxCleANopen - Application profile for municipal vehicles43.160Vozila za posebne nameneSpecial purpose vehicles35.240.60Uporabniške rešitve IT v prometuIT applications in transportICS:Ta slovenski standard je istoveten z:EN 16815:2019SIST EN 16815:2019en,fr,de01-junij-2019SIST EN 16815:2019SLOVENSKI
STANDARDSIST-TP CEN/TR 16815:20161DGRPHãþD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16815
March
t r s { English Version
CleANopen æ Application profile for municipal vehicles CleANopen æ Profil d 5application aux véhicules municipaux
CleANopen æ Anwendungsprofil für Kommunalfahrzeuge This European Standard was approved by CEN on
u r December
t r s zä
egulations which stipulate the conditions for giving this European Standard the status of a national standard without any alterationä Upætoædate lists and bibliographical references concerning such national standards may be obtained on application to the CENæCENELEC Management Centre or to any CEN memberä
translation under the responsibility of a CEN member into its own language and notified to the CENæCENELEC Management Centre has the same status as the official versionsä
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á Serbiaá 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:
Rue de la Science 23,
B-1040 Brussels
t r s { CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Membersä Refä Noä EN
s x z s wã t r s { ESIST EN 16815:2019
Manufacturer-specific TPDOs for unit-specific use . 966 Annex B (normative)
Manufacturer-specific RPDOs for unit-specific use . 971 Annex C (informative)
Measurement process . 976 Bibliography . 979
the 1st 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.
the 2nd 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
the 3rd 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.
the 4th 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. According to the CEN-CENELEC Internal Regulations, the national standards organisations of the following countries are bound to implement this European Standard: 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, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 16815:2019
general definitions;
functionality of the virtual devices;
pre-defined PDOs and SDOs;
application objects. 2 Normative references The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. 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. ISO and IEC maintain terminological databases for use in standardization at the following addresses:
IEC Electropedia: available at http://www.electropedia.org/
ISO Online browsing platform: available at http://www.iso.org/obp 3.1 CleANopen unit virtual device that provides functional elements specified in this application profile 3.2 functional element atomic application function SIST EN 16815:2019
Figure 1
Pitch example 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
Roll example 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 SIST EN 16815:2019
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. SIST EN 16815:2019
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 in maximum. The 1st 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. SIST EN 16815:2019
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 SIST EN 16815:2019
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. The following brief descriptions give an overview on the functionality of the different virtual devices. SIST EN 16815:2019
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 start command received from the MIC or automatically, when the IDU is supporting continuous identification. SIST EN 16815:2019
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. SIST EN 16815:2019
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
If more than one virtual device is integrated to one CANopen device, the lowest node-ID shall be used. SIST EN 16815:2019
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 SIST EN 16815:2019
Virtual device numbers Virtual device name Number BC 01h CCU 03h CU 04h LU 05h IDU 06h MU-A 07h BCU 08h WU 09h MU-B 0Bh GPSU 0Ch TGU 0Dh
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 2
Profile specific basic data type definitions Index Object Name Examples 0060h DEFTYPE BOOLEAN2 bit1, bit2 0061h DEFTYPE BOOLEAN3 bit1, bit2, bit3 0062h DEFTYPE BOOLEAN4 bit1, bit2, bit3, bit4
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. SIST EN 16815:2019
Object structure Table 3
Virtual device code values Code Function 01h Body controller (BC) 02h reserved for compatibility reason 03h Change container unit (CCU) 04h Compaction unit (CU) 05h Lifter unit (LU) 06h Identification unit (IDU) 07h Measuring unit A (MU-A) 08h Bin classification unit (BCU) 09h Washing unit (WU) 0Ah reserved for compatibility reason SIST EN 16815:2019
10.2.3 Object 1001h: Error register 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 1016h: Consumer heartbeat times 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 1017h: Producer heartbeat time 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 1018h: Identity This object is mandatory and contains in sub-index 01h the unique vendor-ID assigned by CiA. Sub-index 02h to 04h are optional. The object and entry description are given in [CiA301]. 10.2.7 Object 1029h: Error behavior 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. Table 4
Value definition Value Definition 00h Change to NMT state Pre-operational (only if currently in NMT state Operational) 01h No change of the NMT state 02h Change to NMT state Stopped
Entry description for sub index 02h Attribute Value Sub-index 02h Description Internal device error Access rw Entry category Optional PDO mapping No Value range 00h to 02h Default value 00h
10.2.8 Object 1F80h: NMT startup 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 specific entity of a virtual device is implemented in the CANopen device (e.g. IDU 4), in all relevant application objects the related sub-indexes (in this example 04h) need to be implemented. If several entities of a virtual device are implemented in the CANopen device (e.g. LU 2 and LU 6), in all relevant application objects the two related sub-indexes (in this example 02h and 04h) need to be implemented. The CANopen device, which implements one or more entities of a virtual device, needs to support the related TPDOs and RPDOs. For example: If WU 3 and WU 5 are implemented, TPD 60 and TPDO 92 (containing the WU status and WU-to-BC request) as well as RPDO 64 and RPDO 96 (containing the WU-to-BC status) need to be supported (see Table 25). 10.3.2 General application objects Every CANopen device compliant with this application profile can implement the application objects shown in Table 7. The category, access, and default value attributes shall be used. Table 6
General application objects Index Name Cat. Acc. Default value 6000h Supported virtual device types (NOTE) C const Manufacturer-specific 6001h Supported profile version O const Manufacturer-specific 6008h Absolute work hours O ro No NOTE Mandatory for CANopen devices supporting more than one virtual device.
BC specific application objects Index Name Cat. Acc. Default value 6020h Body controller status M ro No 6100h Lifter unit status O rw 3FFFh 6130h Lifter unit body controller request M rw FFh 6131h Lifter unit body controller status M ro No 6140h Identification unit status O rw 3FFFh 6161h Measuring unit A extended status O rw 1FFF FFFFh 6171h Measuring unit B extended status O rw 1FFF FFFFh 6180h Bin classification unit status O rw 3FFFh 61A0h Washing unit status O rw 3FFFh 61B0h Washing unit body controller request O rw FFh 61B1h Washing unit body controller status O ro No 61C1h Measuring ident controller extended status O rw 3FFF FFFFh 6300h Compaction unit status O rw 3FFFh 6310h Compaction unit body controller request O rw FFh 6311h Compaction unit body controller status O ro No 6320h Change container unit status O rw 3FFFh 6330h Change container unit body controller request O rw FFh 6331h Change container unit body controller status M ro No 6406h Vehicle speed O rw FFFFh 6408h Engine speed O rw FFFFh 640Ah Maximum vehicle speed limit O rw FFh 6410h First clutch dependent PTO feedback O rw TRUE TRUE 6411h Second clutch dependent PTO feedback O rw TRUE TRUE 6412h Clutch independent PTO feedback O rw TRUE TRUE 6413h First engine mounted PTO feedback O rw TRUE TRUE 6414h Second engine mounted PTO feedback O rw TRUE TRUE 6416h Parking brake device active O rw TRUE TRUE SIST EN 16815:2019
In Table 9 it is specified, which PDOs the BC virtual device shall (category = M) and can (category = O) support. The PDO numbers and mapped application objects for virtual device entities are given for the entity 1 without brackets, the PDO number and mapped application objects (sub-index corresponds to the entity no.) for the entities 2 to 8 are given in brackets. If the CANopen device implements the corresponding TPDO and RPDO, the PDO is normally communicated device-internally and not via CAN. The PDO communication and mapping parameter sets are specified in detail in Clauses 11 to 15. SIST EN 16815:2019
PDOs supported by the BC virtual device PDO no. Cat. Mapped application objects TPDO 7 M 6020 00h, 6331 00h TPDO 10 O 6311 00h TPDO 32 (TPDO 48) (TPDO 64) (TPDO 80) (TPDO 96) (TPDO 112) (TPDO 128) (TPDO 144) O 6131 01h, 61B1 01h (6131 02h, 61B1 02h) (6131 03h, 61B1 03h) (6131 04h, 61B1 04h) (6131 05h, 61B1 05h) (6131 06h, 61B1 06h) (6131 07h, 61B1 07h) (6131 08h, 61B1 08h) TPDO 260 O 643C 01h, 6435 01h, 642D 00h, 642E 00h, 642F 00h, 6430 00h, 6431 00h, 643D 00, 643E 00h, 6432 00h, 67F0 00h RPDO 5 O 6320 00h, 6330 00h RPDO 9 O 6300 00h, 6310 00h RPDO 18 (RPDO 34) (RPDO 50) (RPDO 66) (RPDO 82) (RPDO 98) (RPDO 114) (RPDO 130) O 6100 01h, 6130 01h (6100 02h, 6130 02h) (6100 03h, 6130 03h) (6100 04h, 6130 04h) (6100 05h, 6130 05h) (6100 06h, 6130 06h) (6100 07h, 6130 07h) (6100 08h, 6130 08h) RPDO 20 (RPDO 36) (RPDO 52) (RPDO 68) (RPDO 84) (RPDO 100) (RPDO 116) (RPDO 132) O 6140 01h (6140 02h) (6140 03h) (6140 04h) (6140 05h) (6140 06h) (6140 07h) (6140 08h) RPDO 11 (RPDO 14) (RPDO 31) (RPDO 79) (RPDO 127) (RPDO 262) (RPDO 265) (RPDO 268) O 6161 01h, 0004 00h (6161 02h, 0004 00h) (6161 03h, 0004 00h) (6161 04h, 0004 00h) (6161 05h, 0004 00h) (6161 06h, 0004 00h) (6161 07h, 0004 00h) (6161 08h, 0004 00h) SIST EN 16815:2019
CCU specific application objects Index Name Cat. Acc. Default value 6020h Body controller status M rw 3FFFh 6100h Lifter unit status O rw 3FFFh 6140h Identification unit status O rw 3FFFh 6161h Measuring unit A extended status O rw 1FFF FFFFh 6171h Measuring unit B extended status O rw 1FFF FFFFh 6180h Bin classification status O rw 3FFFh 61A0h Washing unit status O rw 3FFFh 61C1h Measuring ident controller extended status O rw 3FFF FFFFh 6300h Compaction unit status O rw 3FFFh 6320h Change container unit status M ro No 6322h Change container unit position M ro No 6330h Change container unit body controller request M ro No 6331h Change container unit body controller status M rw FFh
In Table 11, it is specified which PDOs the CCU virtual device shall (category = M) and can (category = O) support. The PDO numbers and mapped application objects for virtual device entities are given for the entity 1 without brackets, the PDO number and mapped application objects (sub-index corresponds to the entity no.) for the entities 2 to 8 are given in brackets. If the CANopen device implements the corresponding TPDO and RPDO, the PDO is normally communicated device-internally and not via CAN. The PDO communication and mapping parameter sets are specified in detail in Clause 11 to 15. SIST EN 16815:2019
PDOs supported by the CCU virtual device PDO no. Cat. Mapped application objects TPDO 5 M 6320 00h, 6330 00h TPDO 6 M 6320 00h, 6322 00h RPDO 7 M 6020 00h, 6331 00h RPDO 9 O 6300 00h, 0005 00h RPDO 18 (RPDO 34) (RPDO 50) (RPDO 66) (RPDO 82) (RPDO 98) (RPDO 114) (RPDO 130) O 6100 01h, 0005 00h (6100 02h, 0005 00h) (6100 03h, 0005 00h) (6100 04h, 0005 00h) (6100 05h, 0005 00h) (6100 06h, 0005 00h) (6100 07h, 0005 00h) (6100 08h, 0005 00h) RPDO 20 (RPDO 36) (RPDO 52) (RPDO 68) (RPDO 84) (RPDO 100) (RPDO 116) (RPDO 132) O 6140 01h (6140 02h) (6140 03h) (6140 04h) (6140 05h) (6140 06h) (6140 07h) (6140 08h) RPDO 11 (RPDO 14) (RPDO 31) (RPDO 79) (RPDO 127) (RPDO 262) (RPDO 265) (RPDO 268) O 6161 01h, 0004 00h (6161 02h, 0004 00h) (6161 03h, 0004 00h) (6161 04h, 0004 00h) (6161 05h, 0004 00h) (6161 06h, 0004 00h) (6161 07h, 0004 00h) (6161 08h, 0004 00h) RPDO 27 (RPDO 43) (RPDO 59) (RPDO 75) (RPDO 91) (RPDO 107) (RPDO 123) (RPDO 139) O 6180 01h, 0006 00h (6180 02h, 0006 00h) (6180 03h, 0006 00h) (6180 04h, 0006 00h) (6180 05h, 0006 00h) (6180 06h, 0006 00h) (6180 07h, 0006 00h) (6180 08h, 0006 00h) SIST EN 16815:2019
10.3.5 Compaction unit All applications objects used by the CU virtual device are listed in Table 12. The category, access, and default value attributes shall be used. Table 11
CU specific application objects Index Name Cat. Acc. Default value 6020h Body controller status O rw 3FFFh 6100h Lifter unit status O rw 3FFFh 6102h Lifter unit position O rw FFFFh 6140h Identification unit status O rw 3FFFh 6161h Measuring unit A extended status O rw 1FFF FFFFh 6171h Measuring unit B extended status O rw 1FFF FFFFh 6180h Bin classification status O rw 3FFFh 61A0h Washing unit status O rw 3FFFh 61C1h Measuring ident controller extended status O rw 3FFF FFFFh SIST EN 16815:2019
In Table 13, it is specified, which PDOs the CU virtual device shall (category = M) and can (category = O) support. The PDO numbers and mapped application objects for virtual device entities are given for the entity 1 without brackets, the PDO number and mapped application objects (sub-index corresponds to the entity no.) for the entities 2 to 8 are given in brackets. If the CANopen device implements the corresponding TPDO and RPDO, the PDO is normally communicated device-internally and not via CAN. The PDO communication and mapping parameter sets are specified in detail in Clause 11 to 15. Table 12
PDOs supported by the CU virtual device PDO no. Cat. Mapped application objects TPDO 9 M 6300 00h, 6310 00h RPDO 5 O 6320 00h, 0005 00h RPDO 6 O 6320 00h, 6322 00h RPDO 7 O 6020 00h, 0005 00h RPDO 10 O 6311 00h RPDO 18 (RPDO 34) (RPDO 50) (RPDO 66) (RPDO 82) (RPDO 98) (RPDO 114) (RPDO 130) O 6100 01h, 0005 00h (6100 02h, 0005 00h) (6100 03h, 0005 00h) (6100 04h, 0005 00h) (6100 05h, 0005 00h) (6100 06h, 0005 00h) (6100 07h, 0005 00h) (6100 08h, 0005 00h) RPDO 19 (RPDO 35) (RPDO 51) (RPDO 67) (RPDO 83) (RPDO 99) (RPDO 115) (RPDO 131) O 6100 01h, 6102 01h (6100 02h, 6102 02h) (6100 03h, 6102 03h) (6100 04h, 6102 04h) (6100 05h, 6102 05h) (6100 06h, 6102 06h) (6100 07h, 6102 07h) (6100 08h, 6102 08h) SIST EN 16815:2019
10.3.6 Lifter unit All generic applications objects used by the LU virtual device are listed in Table 14. The category, access, and default value attributes shall be used. Table 13
LU specifics application objects Index Name Cat. Acc. Default value 6020h Body controller status O rw 3FFFh 6100h Lifter unit status M ro No 6102h Lifter unit position M ro No 6104h Lifter unit bin counter O ro No 6105h Lifter unit absolute bin counter O ro No 6108h Lifter unit configuration O ro No 610Ah Lifter unit measuring window low position O rw FFFFh 610Bh Lifter unit measuring window high position O rw FFFFh 6111h Lifter unit speed table up speed position 1 O rw FFFFh 6112h Lifter unit speed table up speed position 2 O rw FFFFh 6113h Lifter unit speed table up speed position 3 O rw FFFFh 6114h Lifter unit speed table up speed position 4 O rw FFFFh 6115h Lifter unit speed table up speed position 5 O rw FFFFh 6116h Lifter unit speed table up speed position 6 O rw FFFFh 6117h Lifter unit speed table up speed position 7 O rw FFFFh 6118h Lifter un
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...