Product Documentation PSL/PSV CAN Valve Actuationdownloads.hawe.com/7/7/B7700_CAN-Manual-en.pdf ·...

Product DocumentationPSX CAN Valve Actuation

Revision: 720Date: 10.11.2017

Copyright

All rights reserved. No parts of this work may be reproduced in any form or by anymeans - graphic, electronic, or mechanical, including photocopying, recording, taping,or information storage and retrieval systems - without the written permission of thepublisher.

Products that are referred to in this document may be either trademarks and/or registeredtrademarks of the respective owners. The publisher and the author make no claim tothese trademarks.

While every precaution has been taken in the preparation of this document, the publisherand the author assume no responsibility for errors or omissions, or for damages resultingfrom the use of information contained in this document or from the use of programs andsource code that may accompany it. In no event shall the publisher and the author beliable for any loss of profit or any other commercial damage caused or alleged to havebeen caused directly or indirectly by this document.All rights reserved.

Printdate: November 13, 2017

B 7700 CAN ManualRevision: 720 (10.11.2017)

Contents

1 General Information 131.1 Scope of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 Hazard Symbols and Notes . . . . . . . . . . . . . . . . . . . . . . . . 131.3 Liability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4 Transport and Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.6 Maintenance, Repair and Disposal . . . . . . . . . . . . . . . . . . . . 171.7 Technical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.7.2 Electrical Parameters . . . . . . . . . . . . . . . . . . . . . . . . 191.7.3 Hydraulic Parameters . . . . . . . . . . . . . . . . . . . . . . . . 201.7.4 Environmental and Operating Conditions . . . . . . . . . . . . . 20

1.8 Accessories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.8.1 Connector Socket . . . . . . . . . . . . . . . . . . . . . . . . . . 211.8.2 Cable specification . . . . . . . . . . . . . . . . . . . . . . . . . 271.8.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.8.4 Starter-Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.9 Protocol Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2 CAN Interface 292.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.1.1 CAN Bus Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . 302.1.2 CAN Bus Termination . . . . . . . . . . . . . . . . . . . . . . . 312.1.3 Line Layout and Net Topology . . . . . . . . . . . . . . . . . . . 31

2.2 Protocol Philosophies Overview . . . . . . . . . . . . . . . . . . . . . 332.2.1 J1939 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2.2 CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3 CAN Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.1 Telegram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.3 Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.4 Typical Bus Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 CiA-301 Reference 383.1 Structure of the Documentation . . . . . . . . . . . . . . . . . . . . . . 383.2 Essential Concepts of CANopen . . . . . . . . . . . . . . . . . . . . . 38

3.2.1 Device Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.2 CAN Master and CAN Slaves . . . . . . . . . . . . . . . . . . . 39


Contents

3.2.3 Data Objects, Telegram Types . . . . . . . . . . . . . . . . . . . 403.2.4 Object Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.5 Nomenclature, Definitions, Notes . . . . . . . . . . . . . . . . . 413.2.6 CANopen Default Identifier Distribution . . . . . . . . . . . . . . 43

3.3 Safety Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.3.1 Node Guarding . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3.2 Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.3 Setpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4 Process Data Objects (PDOs) . . . . . . . . . . . . . . . . . . . . . . 483.4.1 Setpoints and Setpoint Processing . . . . . . . . . . . . . . . . 483.4.2 Data Format for Setpoints . . . . . . . . . . . . . . . . . . . . . 493.4.3 Actual Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.4 Communication with PSL/PSV CAN-Tool . . . . . . . . . . . . . 493.4.5 PDO transmission types . . . . . . . . . . . . . . . . . . . . . . 50

3.5 Service Data Objects (SDOs) . . . . . . . . . . . . . . . . . . . . . . . 503.5.1 SDO Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.5.2 SDO save . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6 Emergency Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.7 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.7.1 Communication State Machine (CSM) . . . . . . . . . . . . . . 543.7.2 Communication State . . . . . . . . . . . . . . . . . . . . . . . . 553.7.3 Network Management Telegrams (NMT) . . . . . . . . . . . . . 553.7.4 LSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.7.5 Participant Identification by LSS . . . . . . . . . . . . . . . . . . 583.7.6 Identification Flashing . . . . . . . . . . . . . . . . . . . . . . . 603.7.7 Participant Identification by operating the hand lever . . . . . . 60

4 CiA-401 Reference 624.1 Essential Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . 624.2 Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.1 Automatic Startup . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3 Setpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3.1 Setpoint Message (PDO Master to Slave) . . . . . . . . . . . . 634.3.2 Setpoint Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.3.3 Several Setpoints per telegram . . . . . . . . . . . . . . . . . . 644.3.4 Zero Setpoint for activation . . . . . . . . . . . . . . . . . . . . 65

4.4 Diagnostic Data (PDO Slave to Master) . . . . . . . . . . . . . . . . . 654.4.1 Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.4.2 Data Content Response Message . . . . . . . . . . . . . . . . 66

4.5 Safety Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5 CiA-408 Reference 675.1 CiA-408 Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1.1 Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1.2 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.1.3 Device State Machine (DSM) . . . . . . . . . . . . . . . . . . . 695.1.4 Device Control Word (DCW) . . . . . . . . . . . . . . . . . . . . 715.1.5 Device Status Word (DSW) . . . . . . . . . . . . . . . . . . . . 71


Contents

5.1.6 State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2 Communication Procedure . . . . . . . . . . . . . . . . . . . . . . . . 72

5.2.1 Startup Communication Functions . . . . . . . . . . . . . . . . 725.2.2 Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.2.3 PDO Master to Slave (RXPDO) . . . . . . . . . . . . . . . . . . 745.2.4 PDO Slave to Master (TXPDO) . . . . . . . . . . . . . . . . . . 755.2.5 Error Management and Error Codes . . . . . . . . . . . . . . . 765.2.6 Position Control Errors . . . . . . . . . . . . . . . . . . . . . . . 77

5.3 Valve Nodes as Plug&Play Slave for PLVC Control Modules . . . . . . 795.4 Flow sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.5 CANopen Object Dictionary . . . . . . . . . . . . . . . . . . . . . . . . 845.6 Configuration of CANopen Master Devices . . . . . . . . . . . . . . . 85

5.6.1 EDS File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.6.2 Add CANopen-Manager . . . . . . . . . . . . . . . . . . . . . . 865.6.3 Add CANopen-Device . . . . . . . . . . . . . . . . . . . . . . . 875.6.4 Master heartbeat configuration . . . . . . . . . . . . . . . . . . 875.6.5 Slave heartbeat configuration . . . . . . . . . . . . . . . . . . . 885.6.6 Configuration of transmit PDO at the Master . . . . . . . . . . . 905.6.7 Configuration of the Receive PDO at the Slave . . . . . . . . . 905.6.8 SDOs Configuration . . . . . . . . . . . . . . . . . . . . . . . . 91

6 J1939 936.1 Basic information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.2 Adressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.3 Boot Up Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.4 Setpoint Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.5 Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.6 Error Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.7 Migration of HAWE J1939 firmware prior 2767 to current

J1939/CANopen Combibuild firmware . . . . . . . . . . . . . . . . . . 986.8 Temperature Information . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7 Protocol Independent Information 1017.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.1.1 Protocol Variants . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.1.2 Parameter Presettings . . . . . . . . . . . . . . . . . . . . . . . 102

7.2 Diagnosis LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.3 Error Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.3.1 Self Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.3.2 Error During Operation . . . . . . . . . . . . . . . . . . . . . . . 1047.3.3 Limited Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.3.4 LED Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.3.5 Standard error field . . . . . . . . . . . . . . . . . . . . . . . . . 1057.3.6 CAN Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.4 Parameter Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.4.1 Parameters in EEPROM and RAM . . . . . . . . . . . . . . . . 1087.4.2 Efficiency of Parameter Changes . . . . . . . . . . . . . . . . . 1087.4.3 Communication Parameters . . . . . . . . . . . . . . . . . . . . 109


Contents

7.4.4 Application Parameters . . . . . . . . . . . . . . . . . . . . . . . 1097.4.5 Reading and Writing Parameters . . . . . . . . . . . . . . . . . 109

7.5 Preprocessing of Setpoints . . . . . . . . . . . . . . . . . . . . . . . . 1097.5.1 Over Temperature Protection . . . . . . . . . . . . . . . . . . . 1107.5.2 Fine control range or increased dynamics . . . . . . . . . . . . 1117.5.3 Setpoint reduction (Override) . . . . . . . . . . . . . . . . . . . 1137.5.4 Ramps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

8 Software 1168.1 HAWE DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.2 PSXCANc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.2.1 How to get a free PSXCANc License . . . . . . . . . . . . . . . 1178.2.2 Connection to the bus . . . . . . . . . . . . . . . . . . . . . . . 1188.2.3 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198.2.4 Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.2.5 Error Management . . . . . . . . . . . . . . . . . . . . . . . . . 1248.2.6 Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268.2.7 Advanced options . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8.3 Electronic Datasheets (EDS) . . . . . . . . . . . . . . . . . . . . . . . 128

9 Starter-Set 1299.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299.2 Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

10 Calibrating Interfaces 13210.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13210.2 Calibrating Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A Appendix 134A.1 Error Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134A.2 Error Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

A.2.1 NO_ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137A.2.2 CURRENT_CONTROL . . . . . . . . . . . . . . . . . . . . . . . 137A.2.3 SFT_UBAT_RANGE . . . . . . . . . . . . . . . . . . . . . . . . 137A.2.4 VOL_SUPPLY_HIGH . . . . . . . . . . . . . . . . . . . . . . . . 138A.2.5 VOL_SUPPLY_LOW . . . . . . . . . . . . . . . . . . . . . . . . 138A.2.6 T_LIMIT_HIGH . . . . . . . . . . . . . . . . . . . . . . . . . . . 138A.2.7 TEMP_HIGH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138A.2.8 TEMP_LOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.2.9 CURRENT_ITG . . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.2.10 POS_ITG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.2.11 SFT_STROM_ZERO . . . . . . . . . . . . . . . . . . . . . . . . 140A.2.12 SFT_HALL_ZERO . . . . . . . . . . . . . . . . . . . . . . . . . 140A.2.13 SFT_UBAT_ZERO . . . . . . . . . . . . . . . . . . . . . . . . . 140A.2.14 SFT_HT_SHORT . . . . . . . . . . . . . . . . . . . . . . . . . . 141A.2.15 SFT_HT_OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . 141A.2.16 SFT_PWM_SHORT . . . . . . . . . . . . . . . . . . . . . . . . 141A.2.17 SFT_PWM_OPEN . . . . . . . . . . . . . . . . . . . . . . . . . 142


Contents

A.2.18 SFT_OPEN_A . . . . . . . . . . . . . . . . . . . . . . . . . . . 142A.2.19 SFT_OPEN_B . . . . . . . . . . . . . . . . . . . . . . . . . . . 142A.2.20 SFT_CHANGE_COIL . . . . . . . . . . . . . . . . . . . . . . . 142A.2.21 COIL_RES_HIGH . . . . . . . . . . . . . . . . . . . . . . . . . . 143A.2.22 COIL_RES_LOW . . . . . . . . . . . . . . . . . . . . . . . . . . 143A.2.23 SFT_RESIST_DIFF . . . . . . . . . . . . . . . . . . . . . . . . 143A.2.24 SFT_RESIST_A . . . . . . . . . . . . . . . . . . . . . . . . . . 143A.2.25 SFT_RESIST_B . . . . . . . . . . . . . . . . . . . . . . . . . . 144A.2.26 RAMTEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144A.2.27 FLASH_CHECKSUM . . . . . . . . . . . . . . . . . . . . . . . . 144A.2.28 EEPROM_CHECKSUM . . . . . . . . . . . . . . . . . . . . . . 144A.2.29 EEPROM_VERIFY . . . . . . . . . . . . . . . . . . . . . . . . . 145A.2.30 WATCHDOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145A.2.31 STATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145A.2.32 STARTUP_SFT . . . . . . . . . . . . . . . . . . . . . . . . . . . 145A.2.33 LIMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146A.2.34 ILLEGAL_ERRTRANSMASK . . . . . . . . . . . . . . . . . . . 146A.2.35 ILLEGAL_VALVEDATA . . . . . . . . . . . . . . . . . . . . . . . 146A.2.36 SETPOINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146A.2.37 SETP_NEQU_NEUTRAL . . . . . . . . . . . . . . . . . . . . . 147A.2.38 SETP_TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . . . . 147A.2.39 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147A.2.40 GUARD_TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . . . 148A.2.41 POS_MINUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148A.2.42 POS_PLUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148A.2.43 POS_PLAUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

A.3 SDO Index CANopen 301 . . . . . . . . . . . . . . . . . . . . . . . . . 149A.4 SDO Index CANopen 408 . . . . . . . . . . . . . . . . . . . . . . . . . 151A.5 Object Dictionary CiA-301 . . . . . . . . . . . . . . . . . . . . . . . . . 155

A.5.1 Device Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155A.5.2 Error register . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155A.5.3 Predefined error field . . . . . . . . . . . . . . . . . . . . . . . . 155A.5.4 COB-ID SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . . 158A.5.5 Manufacturer device name . . . . . . . . . . . . . . . . . . . . . 158A.5.6 Manufacturer hardware version . . . . . . . . . . . . . . . . . . 159A.5.7 Manufacturer software version . . . . . . . . . . . . . . . . . . . 159A.5.8 Guard time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159A.5.9 Life time factor . . . . . . . . . . . . . . . . . . . . . . . . . . . 159A.5.10 Store parameter field . . . . . . . . . . . . . . . . . . . . . . . . 160A.5.11 Restore default parameters . . . . . . . . . . . . . . . . . . . . 160A.5.12 COB-ID EMCY . . . . . . . . . . . . . . . . . . . . . . . . . . . 161A.5.13 Inhibit time emergency . . . . . . . . . . . . . . . . . . . . . . . 161A.5.14 Consumer heartbeat time . . . . . . . . . . . . . . . . . . . . . 161A.5.15 Producer heartbeat time . . . . . . . . . . . . . . . . . . . . . . 162A.5.16 Identity object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162A.5.17 Receive PDO communication parameter 0 . . . . . . . . . . . . 163A.5.18 Receive PDO mapping parameter 0 . . . . . . . . . . . . . . . 163


Contents

A.5.19 Transmit PDO communication parameter 0 . . . . . . . . . . . . 164A.5.20 Transmit PDO communication parameter 0 . . . . . . . . . . . . 165A.5.21 Transmit PDO mapping parameter 0 . . . . . . . . . . . . . . . 165A.5.22 NMT startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166A.5.23 J1939 Identification . . . . . . . . . . . . . . . . . . . . . . . . . 166A.5.24 supply voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167A.5.25 electronic temperature . . . . . . . . . . . . . . . . . . . . . . . 168A.5.26 coil resistance A . . . . . . . . . . . . . . . . . . . . . . . . . . 169A.5.27 coil resistance B . . . . . . . . . . . . . . . . . . . . . . . . . . 169

A.6 Object Dictionary CiA-408 . . . . . . . . . . . . . . . . . . . . . . . . . 170A.6.1 Node-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170A.6.2 Baud rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170A.6.3 Flowshare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170A.6.4 Tracking error tolerance limit . . . . . . . . . . . . . . . . . . . . 171A.6.5 Curve Form A Number of Entries . . . . . . . . . . . . . . . . . 172A.6.6 Curve Form B Number of Entries . . . . . . . . . . . . . . . . . 173A.6.7 Override A Number of Entries . . . . . . . . . . . . . . . . . . . 174A.6.8 Override B Number of Entries . . . . . . . . . . . . . . . . . . . 174A.6.9 Nominal flow A number of entries . . . . . . . . . . . . . . . . . 175A.6.10 Nominal flow A value . . . . . . . . . . . . . . . . . . . . . . . . 175A.6.11 Nominal flow A unit . . . . . . . . . . . . . . . . . . . . . . . . . 176A.6.12 Nominal flow B number of entries . . . . . . . . . . . . . . . . . 176A.6.13 Nominal flow B value . . . . . . . . . . . . . . . . . . . . . . . . 176A.6.14 Nominal flow B unit . . . . . . . . . . . . . . . . . . . . . . . . . 177A.6.15 Voltage supply lower limit . . . . . . . . . . . . . . . . . . . . . 177A.6.16 Voltage supply upper limit . . . . . . . . . . . . . . . . . . . . . 177A.6.17 Self test max delay . . . . . . . . . . . . . . . . . . . . . . . . . 178A.6.18 Power Reduction start temperature . . . . . . . . . . . . . . . . 178A.6.19 Power Reduction end temperature . . . . . . . . . . . . . . . . 179A.6.20 Setpoint timeout . . . . . . . . . . . . . . . . . . . . . . . . . . 179A.6.21 Output inverting sign . . . . . . . . . . . . . . . . . . . . . . . . 180A.6.22 Vpoc demand value generator ramp acceleration2 (A-positive) . 180A.6.23 Vpoc demand value generator ramp deceleration2 (A-negative) 181A.6.24 Vpoc demand value generator ramp acceleration2 (B-positive) . 181A.6.25 Vpoc demand value generator ramp deceleration2 (B-negative) 182A.6.26 Section Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183A.6.27 PDO setpoint format (HAWE/CiA-408) . . . . . . . . . . . . . . 183A.6.28 Device control word . . . . . . . . . . . . . . . . . . . . . . . . . 184A.6.29 Device status word . . . . . . . . . . . . . . . . . . . . . . . . . 184A.6.30 Device mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184A.6.31 Device control mode . . . . . . . . . . . . . . . . . . . . . . . . 184A.6.32 Device error code . . . . . . . . . . . . . . . . . . . . . . . . . . 185A.6.33 Vpoc setpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185A.6.34 Vpoc actual value . . . . . . . . . . . . . . . . . . . . . . . . . . 186A.6.35 Vpoc demand value generator ramp type . . . . . . . . . . . . . 186A.6.36 Vpoc demand value generator ramp acceleration (A-positive) . 187A.6.37 Vpoc demand value generator ramp deceleration (A-negative) . 187


A.6.38 Vpoc demand value generator ramp acceleration (B-positive) . 188A.6.39 Vpoc demand value generator ramp deceleration (B-negative) . 189A.6.40 Vpoc dither type . . . . . . . . . . . . . . . . . . . . . . . . . . 190A.6.41 Vpoc dither amplitude . . . . . . . . . . . . . . . . . . . . . . . 190A.6.42 Vpoc dither frequency . . . . . . . . . . . . . . . . . . . . . . . 191

Suggestions for improvement 192

Bibliography 193

Glossary 195

Index 203

List of Figures

1.1 Setup of a Complete Valve Section with Electronics and Connector . . 181.2 electronic housing with contact-pod . . . . . . . . . . . . . . . . . . . 211.3 AMP mating Connector and its corresponding pin assignment . . . . . 221.4 Additional Accessories for the AMP Connector . . . . . . . . . . . . . 231.5 AMS-mating connector and its corresponding pin assignment . . . . . 241.6 Additional Accessories for the AMS Connector . . . . . . . . . . . . . 251.7 DT-mating connector and its corresponding pin assignment . . . . . . 261.8 Pin numeration DT-Mating Connector . . . . . . . . . . . . . . . . . . 26

2.1 Recommended Architecture for Grounding and Shielding of CAN BusSystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2 Shielding bus lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3 Format of a Data Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4 Bustopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1 Flowchart Node Guarding . . . . . . . . . . . . . . . . . . . . . . . . . 453.2 Flowchart Life Guarding . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3 Communication State Machine CiA-301 . . . . . . . . . . . . . . . . . 54

5.1 Device State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2 Activation of the PLVC41 CAN Masters . . . . . . . . . . . . . . . . . 815.3 Overview of the CAN Nodes . . . . . . . . . . . . . . . . . . . . . . . 825.4 50% setpoint reduction by flow sharing . . . . . . . . . . . . . . . . . . 845.5 Add device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.6 append CANopen Manager as device . . . . . . . . . . . . . . . . . . 875.7 CANopen Manager selection . . . . . . . . . . . . . . . . . . . . . . . 885.8 configuration of the hearbeat producer time . . . . . . . . . . . . . . . 88


5.9 selection of CANopen device . . . . . . . . . . . . . . . . . . . . . . . 895.10 configuration of heartbeat consumer time . . . . . . . . . . . . . . . . 895.11 SDO configuration telegramm . . . . . . . . . . . . . . . . . . . . . . . 905.12 Sync CANopen Master configuration . . . . . . . . . . . . . . . . . . . 905.13 Sync CANopen master configuration . . . . . . . . . . . . . . . . . . . 915.14 SDO configuration of device . . . . . . . . . . . . . . . . . . . . . . . . 92

7.1 Illustration of Over Temperature Protection . . . . . . . . . . . . . . . 1117.2 Nonlinear Curve Transformation . . . . . . . . . . . . . . . . . . . . . 1127.3 Ramp Characteristics and Control Parameters . . . . . . . . . . . . . 113

8.1 Start-up dialog PSXCANc tool . . . . . . . . . . . . . . . . . . . . . . 1178.2 Start-up dialog filled with information . . . . . . . . . . . . . . . . . . . 1178.3 Baudrate selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.4 Information about detected nodes . . . . . . . . . . . . . . . . . . . . 1198.5 Firmware download . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208.6 Verify the correct firmware . . . . . . . . . . . . . . . . . . . . . . . . . 1218.7 Parameter table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.8 Error table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.9 Application: toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268.10 Scope together with setpoint generator . . . . . . . . . . . . . . . . . 1278.11 Edit a CAN message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

9.1 Cable provided with the starter-set . . . . . . . . . . . . . . . . . . . . 1309.2 PCAN-USB-adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

List of Tables

1.1 Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 Electrical Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3 Electrical Parameters CAN Interface . . . . . . . . . . . . . . . . . . . 191.4 Electrical Parameters PSL - 12V . . . . . . . . . . . . . . . . . . . . . 191.5 Electrical Parameters PSL - 24V . . . . . . . . . . . . . . . . . . . . . 201.6 Operating Conditions and Environmental Checks . . . . . . . . . . . . 201.7 Protection class of connectors . . . . . . . . . . . . . . . . . . . . . . 27

2.1 Recommended Bus Line Length Limits . . . . . . . . . . . . . . . . . 302.2 CAN Data Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1 Entries in the Object Dictionary . . . . . . . . . . . . . . . . . . . . . . 413.2 CANopen Default Identifier Distribution . . . . . . . . . . . . . . . . . 433.3 Format Node Guarding Telegram . . . . . . . . . . . . . . . . . . . . . 453.4 Content Node Guarding Response Messages . . . . . . . . . . . . . . 45


List of Tables

3.5 Format Heartbeat Telegrams . . . . . . . . . . . . . . . . . . . . . . . 473.6 Description of PDO transmission types . . . . . . . . . . . . . . . . . 503.7 SDO Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.8 SDO Control Bytes M → S . . . . . . . . . . . . . . . . . . . . . . . . 513.9 SDO Control Bytes S →M . . . . . . . . . . . . . . . . . . . . . . . . 513.10 SDO Transfer Error Message . . . . . . . . . . . . . . . . . . . . . . . 523.11 SDO Transfer Abort Codes . . . . . . . . . . . . . . . . . . . . . . . . 523.12 SDO save . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.13 Emergency Objects (EMCY) . . . . . . . . . . . . . . . . . . . . . . . 533.14 Error classes in the error register . . . . . . . . . . . . . . . . . . . . . 533.15 Permitted Telegrams, According to CSM State . . . . . . . . . . . . . 543.16 Transitions of the Communication State Machine CiA-301 . . . . . . . 553.17 Communication Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.18 NMT Commands for Controlling the CSM . . . . . . . . . . . . . . . . 553.19 Communication sequence LSS, readdress . . . . . . . . . . . . . . . 573.20 Communication Sequence LSS, Activation . . . . . . . . . . . . . . . 583.21 Communications Process, Broadcast . . . . . . . . . . . . . . . . . . 593.22 Communications process, response of the slaves to a Broadcast telegram 593.23 Requirement Identification Flashing . . . . . . . . . . . . . . . . . . . 60

4.1 Set all nodes to Active . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.2 Format setpoint telegram CiA-401 . . . . . . . . . . . . . . . . . . . . 634.3 Mapping of Setpoints to Oil Flow . . . . . . . . . . . . . . . . . . . . . 644.4 Zero setpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5 Format Diagnosis Telegram CiA-401 . . . . . . . . . . . . . . . . . . . 654.6 Diagnostic Information in the PDO . . . . . . . . . . . . . . . . . . . . 66

5.1 Meaning of the Operating Modes . . . . . . . . . . . . . . . . . . . . . 675.2 States of the Device State Machine . . . . . . . . . . . . . . . . . . . 705.3 Device Control Word and Transitions of the Device State Machine . . 715.4 LSB Device Status Word . . . . . . . . . . . . . . . . . . . . . . . . . 725.5 Boot up Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.6 Activation Sequence for all Slaves . . . . . . . . . . . . . . . . . . . . 735.7 Activation Telegram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.8 Activation Telegram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.9 RPDO (Setpoint Format) . . . . . . . . . . . . . . . . . . . . . . . . . 745.10 Setpoint Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.11 Examples for setpoint messages . . . . . . . . . . . . . . . . . . . . . 755.12 Device Control and Status Word (DCW and DSW), Byte 0 . . . . . . . 755.13 TXPDO (Actual Value Format) . . . . . . . . . . . . . . . . . . . . . . 765.14 Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.15 Nominal Increments per design size . . . . . . . . . . . . . . . . . . . 785.16 Parameter Description Position Control Errors . . . . . . . . . . . . . . 785.17 Node-IDs in the Process . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.1 J1939 Configuration Values . . . . . . . . . . . . . . . . . . . . . . . . 936.2 J1939 Parameter Group Numbers . . . . . . . . . . . . . . . . . . . . 946.3 Boot Up Message, Sent Once After Power Up . . . . . . . . . . . . . . 94


List of Tables

6.4 J1939 Setpoint Configuration Parameters . . . . . . . . . . . . . . . . 956.5 Setpoint Message, to be Sent Cyclically . . . . . . . . . . . . . . . . . 956.6 J1939 Status Configuration Parameter . . . . . . . . . . . . . . . . . . 966.7 Status Message, Sent Cyclically . . . . . . . . . . . . . . . . . . . . . 966.8 Example for Status Messages . . . . . . . . . . . . . . . . . . . . . . 976.9 Error Group Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.10 J1939 Configuration Parameter (prior to 2767) . . . . . . . . . . . . . 986.11 J1939 Configuration Parameter (revision 2767 and later) . . . . . . . . 996.12 J1939 Temperature Request . . . . . . . . . . . . . . . . . . . . . . . 1006.13 J1939 Temperature Response . . . . . . . . . . . . . . . . . . . . . . 100

7.1 Error referring to parameter value . . . . . . . . . . . . . . . . . . . . 1067.2 Assignment error message to operating time parameters . . . . . . . 1067.3 CAN Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.4 Ramp Parameters 1. Ramp . . . . . . . . . . . . . . . . . . . . . . . . 1147.5 Ramp Parameters 2. Ramp . . . . . . . . . . . . . . . . . . . . . . . . 114

8.1 Baudrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238.2 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.3 Error description - startup selftest . . . . . . . . . . . . . . . . . . . . 125

9.1 Order Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

10.1 Calibrating Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

A.1 Overview of Possible Errors . . . . . . . . . . . . . . . . . . . . . . . . 136A.2 Object Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151A.3 Object Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154


1. General Information

This document serves as an addition to the manual [7] and describes the variant ofCAN actuated PSL/PSV proportional valves. It is targeted at programmers as well aselectricians to supply information for programming or commissioning.

1.1. Scope of this Document

With the help of this documentation the commissioning of valve batteries and the devel-opment of ECU software should be possible. Users of PSL/PSV CAN valve nodes getpresented all essential device properties.

As far as necessary basics of CAN technology will be explained. For detailed informationabout the function of CAN networks or components please refer to literature like [14],[17] or [10].

1.2. Hazard Symbols and Notes

Please pay attention to the hazard symbols and notes given in Table 1.1. Text passagesmarked with those symbols have increased significance.

Symbol Meaning Potential consequences

Impending danger Death or severe injuries

Dangerous situation Light injuries

Harmful situation Damage to components

Tips & information Fun at work

Table 1.1.: Symbols



1.3. Liability

This description is an integral part of the device. It contains information concerning thecorrect handling of the PSL/PSV CAN valve node and must be read prior to installationor use.

WARNING

Non-compliance with the notes or any use outside the intended usage outlinedin the following, wrong installation or faulty handling can seriously impair andendanger the safety of people and machinery and will result in the exclusion ofany liability and warranty claims.

Follow the instructions in the description.

The manufacturer of the complete system who selects hydraulic components is responsi-ble for choosing an adequate combination of products and assuring that all performanceand safety requirements of the application are met.

HAWE Hydraulik SE reserves the right to alter its products without prior notice. This alsoapplies to products already ordered provided that such alterations can be made withoutsubsequent changes being necessary in specifications already agreed.

This manual is aimed at all those persons who can be regarded as “competent” in theunderstanding of the EMC- and the low-voltage guideline. The wiring of the valves mustbe performed by an electrician and must be activated by trained programmers and/orservice technicians.

WARNING

System integrators are responsible for the correct integration of all hardware andsoftware components.

Furthermore, it is up to the user to comply with the standards (e.g. DIN EN ISO 13849)relevant for his usage and to realize a system architecture appropriate to the safetyrequirement.

NOTE

Monitor and feedback signal processed by integral electronics must not be used



for safety machine relevant function.

HAWE Hydraulik accepts no liability in case of technical or typographical defects in thismanual.HAWE Hydraulik accepts no liability for damage caused by any kind of delivery, perfor-mance or usage of the produkt.Usage names, trade names and trade marks are usually registered and protected namesor characters, which are subject to statutory provisions.

1.4. Transport and Storage

As with hydraulic components, care should be given to appropriate storage and suitablepackaging of the product. There are no special requirements arising from the combinationof control electronics and valve.

NOTE

The plastic connector socket can only carry a limited mechanical load and is notsuited for the use as handle! The socket might brake from the bank.

Don’t use the connector socket as handle.

1.5. Installation

The following notes must be observed to guarantee safe operation of the PSL/PSVCAN valve node and to prevent shortening the product’s lifecycle through inappropriateoperating conditions:

- The valves should not be mounted in the vicinity of machine parts and modulesdeveloping great heat (e.g. exhaust).

- The distance to radio-emitting installations must be sufficient.

- There must be an emergency shutdown for the voltage supply. The emergency offswitch must be mounted on the machine or vehicle that is easily accessible for themachine or facility operator. The machine or vehicle manufacturer must guaranteethat a safe state is achieved when the emergency off switch is activated.



- One of the safety mechanisms against bus interruptions supported by the device(Node Guarding (see subsection 3.3.1) or Heartbeat (see subsection 3.3.2)) mustbe used.

- The power supply must be fuse-protected, in accordance with the maximumpower consumtion per valve bank. For every valve section a maximum current ofapproximately 1.5A at 12V power supply and 0.8A at 24V must be provided for.

- Ground lines must be dimensioned in accordance with the maximum currents flow-ing through them. The reference potential for all CAN bus participants connectedto one branch should vary as little as possible between the devices and be identicalwith the ground connection for the power supply.

- All connectors used for joining the valve bank must be properly secured againstwater penetration by applying all necessary gaskets and seals.

- The bus lines to be used must be suited to CAN bus networks. Preferably the linesshould be twisted and shielded. The characteristic impedance must be approx.120 Ω.

- Terminating resistors with 120 Ω have to be provided for both two ends of the CANbus network.

- Valve electronics and the respective solenoid body are sealed and screwed to-gether. Therefore they should not be separated. Care should be given to propersealing during reassembly when replacing the valve spool or valve body.

- In the event that the bus and power supply lines are separated from the valvesections during maintenance or servicing, it is mandatory to use new cables forreassembly. Care has to be taken that the end cap is properly positioned. Cablesare available as spare parts.

- During installation and storage the valve bank must remain at a sufficient distanceto strong sources of magnetic fields (static or time varying).

- In case of parameter changes the enduser is responsible for the consistency ofthe transmitted data. Not in any case the valve electronics can detect inconsistentparameters which might cause undefined behaviour.

WARNING

Electric welding causes massive surges.

Electronics can be damaged.

All valve nodes must be disconnected during electric welding works.

The following has to be observed during operations:



- Proper operation is only guaranteed in a temperature range between -40 C to+85 C.

- If the device detects internal overheating, operations are limited to a certaintemperature range, i.e. at reduced performance.

- The power supply voltage must be within the specified working range. Excessiveor permanent deviations may damage the electronics.

WARNING

Especially the surface of the solenoid may become hot during operation!

In case of contact serious burns are possible.

Don’t touch the surface of the solenoid.

1.6. Maintenance, Repair and Disposal

Because the valve electronics do not contain any components that have to be servicedby the end customer, it is not permitted to open the housing. Only the manufacturer mayundertake repair or service work.

NOTE

Unauthorized separation of valve electronics and solenoid leads to loss of war-ranty claims!

Don’t separate valve electronics and solenoid unauthorized.

Disposal must be in accordance with national environmental laws.

1.7. Technical Data

1.7.1. General

Proportional directional spool valves serve to control both, the direction of movementand the load-independent, stepless velocity of the hydraulic consumers.



This way several hydraulic actuators may be moved simultaneously, independently fromone other at different velocities and pressures. This applies as long as the sum requiredfor the partial flows is within the total delivery supplied by the pump and the pump cansupply the pressure levels required for operating all consumers. See also [7].

Advantages of the variant with CAN actuation are as follows:

- Simplified wiring

- Integrated position transducer

- Valve calibration done by producer, no need for alignment by end customer

- Configurable valve characteristics (linearization, fine control range etc.)

- Adjustable ramps (limited change speed of oil flow)

- Fast response behavior

- Maximum volume flow can be limited by parameter

- Diagnostic facility (temperature, current spool position, fault detection)

Figure 1.1 shows the layout of a CAN-PSL section. The housing for the solenoid and theelectronics are mounted on top of the spool valve section [7].

104.

2

39

34.75

Connector

Electronics

Housing for the solenoid

Spool valve section

Figure 1.1.: Setup of a Complete Valve Section with Electronics and Connector

The connection socket attached to the electronics’ housing establishes the electriccontact with the element. At least one, maximum two, connection sockets shall beprovided for each valve bank.



1.7.2. Electrical Parameters

Table 1.2 and Table 1.3 provide an overview of electrical parameters and their limit valuesfor the valve driver and its CAN interface.

Parameter Sym. Min Max Unit CommentSupply voltage UB 10 30 V Maximum spool actuation can only

be guaranteed as of 12V.Currentconsumption

IB 0.05 2.0 A Current consumption depends onsupply voltage, elevated maximumcurrents are also possible (start-up moment).

Power consump-tion

PB 1 50 W Valid for normal operation. Duringstart-up higher values might occur.

Table 1.2.: Electrical Parameters

For detailed information concerning CAN interface please refer to section 2.1.

Parameter Symbol Value rangeOutput voltage, bus supply VDD 5 VTransfer rate fbit 50k - 1Mbit/sSlew rate SR 5 V/µs

Table 1.3.: Electrical Parameters CAN Interface

If the PSL/PSV CAN valve bank is operated as pass-through, i.e. it is fitted with twocontact sockets and integrated into the bus line, attention must be given to the maximumpower load of the contact sockets. If necessary those bus participants with high powerconsumption should not be supplied through the valve bank, but receive their own powersupply. It is recommended that the average current at the contact sockets exposed tothe greatest loads shall not exceed 10A.

The following two tables 1.4 and 1.5 show the current carrying capacity (at 25 C envi-ronmental temperature) for all connector-base versions.

PSL2 PSL 3 PSL 5 UnitstandBy 50 50 50 mAImin 250 365 300 mAImax 645 500 700 mA

Table 1.4.: Electrical Parameters PSL - 12V



PSL2 PSL 3 PSL 5 UnitstandBy 30 30 30 mAImin 140 205 140 mAImax 350 430 380 mA

Table 1.5.: Electrical Parameters PSL - 24V

1.7.3. Hydraulic Parameters

Hydraulic parameters can be obtained from the document for HAWE PSL/PSV valves[7].

1.7.4. Environmental and Operating Conditions

Table 1.6 provides an overview of the operating conditions for which qualification testshad been carried out.

Test criterion Industrial standard CommentEMC Irradiation ISO 11452-2 60V/mEMC Emission ISO 14982Protection type IP67 DIN 40050-9Salt spray test DIN EN 680068-2-11 500hShock test DIN EN 680068-2-29 25g, 3 axesVibration DIN EN 680068-2-6Temperature change DIN EN 680068-2-14 -40 C - 85 C (1.5K/min)Cold DIN EN 680068-2-1 -40 CMoist warmth DIN EN 680068-2-30 95% humidity, 24hDry warmth DIN EN 680068-2-2 85 C, 16h

Table 1.6.: Operating Conditions and Environmental Checks

INFORMATION

The valves, type PSL/PSV, with integrated CAN control electronics can be operated in anambient temperature range between -40 C to +85 C. As high temperatures acceleratethe aging of electronic components, it is recommended to maintain sufficient distance toheat sources when installing these components and to avoid exposure to heat.

In addition, the basic rules for hydraulic components as specified in [7] must be observed,in particular those measures aimed at limiting maximum oil temperature.



1.8. Accessories

1.8.1. Connector Socket

Connectors are available in three variants that are designated AMP, AMS and DT.Connection sockets with integrated termination resistor are also available for delivery.The different possible configurations can be selected from the type code in [6].

In the following Figure 1.2 a valve bank with a fitting connector is shown. Depending onthe mating connector an AMP Connector, an AMS Connector or a DT Connector can beplaced on such a valve bank.

Figure 1.2.: electronic housing with contact-pod

INFORMATION

Connection sockets can be fitted to either side of a valve bank. Dependent on thecustomer application and the corresponding bus topology, valve batteries can be fittedwith one or two sockets. The internal connection forwards the CAN signal as well as thesupply voltage through the valve bank, enabling the bus to be continued on the secondconnection socket.

NOTE

The plastic connector socket can only carry a limited mechanical load and is not



suited for the use as handle! The socket might brake from the battery.

Don’t use the connector socket as handle.

The mating connector to the AMP Connector and its corresponding pin assignment isshown in Figure 1.3.

4 Power - / GND3 CAN-H2 CAN-L1 Power +

Figure 1.3.: AMP mating Connector and its corresponding pin assignment

The mating connector to the AMP Connector (see Figure 1.3) can be ordered with theHAWE reference number 6217 0180-00 or with the reference number 282764-1 fromTyco Electronics.



Additional accessories for the AMP Connector can be seen in the following Figure 1.4.

Figure 1.4.: Additional Accessories for the AMP Connector

1. AMP mating Connector

2. protection cap

3. small contacts for wires with a diameter of 0.5mm2 − 1.0mm2

4. large contacts for wires with a diameter of 1.5mm2 − 2.5mm2

5. single wire seal for small contacts

6. single wire seal for large contacts

To connect the wires of a cable to the fitting contacts, a crimping tool is necessary. Moredetailled information can be found at the end of this chapter.



The mating connector to the AMS Connector and its corresponding pin assignment isshown in Figure 1.5.

1 CAN-L2 Power +3 Power - / GND4 CAN-H

Figure 1.5.: AMS-mating connector and its corresponding pin assignment

The mating connector to the AMS Connector (see Figure 1.5) can be ordered with theHAWE reference number 6217 0181-00 or with the reference number 1-967 059-1 fromTyco Electronics.



Additional accessories for the AMS Connector can be seen in the following Figure 1.6.

Figure 1.6.: Additional Accessories for the AMS Connector

1. AMS mating Connector

2. protection cap

3. small contacts for wires with a diameter of 0.5mm2 − 1.0mm2

4. large contacts for wires with a diameter of 1.5mm2 − 2.5mm2

5. single wire seal for small contacts

6. single wire seal for large contacts

To connect the wires of a cable to the fitting contacts, a crimping tool is necessary.

A suitable crimping tool can be ordered under the reference number 729710 F28/95e.g from the company “Hoffmann GmbH Qualitätswerkzeuge”, Munich. This tool canbe used for the assembly of both, the AMP mating Connector and the AMS matingConnector.



The mating connector to the DT Connector and its corresponding pin assignment isshown in Figure 1.7.

1 CAN-H2 CAN-L3 Power +4 Power - / GND

Figure 1.7.: DT-mating connector and its corresponding pin assignment

The corresponding pin numeration is depicted in Figure 1.8.

1

2 3

4

Figure 1.8.: Pin numeration DT-Mating Connector

NOTE

This pin numeration corresponds with the DT-Mating Connector. The assingmentof pin 1 of the Mating Connector meets contact 1 of the Connector regarding theDT-Connector which is positioned at the valve bank.

The DT-Connector is manufactured by Tyco Electronics, the manufacturer code is “DT06-4S”



Required components for the DT-Connector:Housing manufacturer code DT06-4s 1 pieceBackshell with strain-relief item number 1011-263-0405 1 pieceWedgelock item number W4S 1 pieceFemale contacts item number 0462-201-16141 4 pieces

Protection class:

Connector: Protection class:AMS IP 54AMP IP 54DT IP 68

Table 1.7.: Protection class of connectors

1.8.2. Cable specification

To achieve the best reliability possible, we recommend cables produced by the company“Lapp”. A possible configuration connecting to a DT-Connector can be the “UNITRONICBUS CAN” cable with a diameter of 0.75mm2 (US specification: AWG 18-19). This cablecan be bought with its item number “2170270” at Lapp.

1.8.3. Software

Every valve section can be parameterized using the parameterization software PSXCANc(8.2), which is distributed by HAWE.

Functionality of the Software:

• Firmware download

• Change values of the Parameters

• Errorhandling

• Watching of internal state variables of the valve

• manual setpoint generator

Standard procedure is to parameterize via the CANopen communication protocol andthe associated software tools. Configuration tools that support CAN electronic datasheets (EDS Files) can also be used.

WARNING

System integrators are responsible for the correct integration of all hardware and



software components.

1.8.4. Starter-Set

By Using the Starter-Set it is possible to communicate with HAWE CAN Valves and totest their functionality. Mainly it is used by programmers of Controlling software and forbus simulation.

Articel: Partnumber:Starter-Set 3405 4200-00

It is possible to get detailed information in chapter 9.

1.9. Protocol Versions

The valve actuation (PSL/PSV CAN valve nodes) might be ordered with different variantsof the communication protocol. Actually supported are the CANopen device profilesCiA-408 und CiA-401 as well as J1939.

For details about those protocols and their subversions please refer to chapter 4, chap-ter 5 and chapter 6.

Regarding the selection of the appropriate protocol for the customer application pleaserefer to section 2.2 as well as subsection 3.2.1.


2. CAN Interface

CAN (Controller Area Network) has established itself as open and non-manufacturer-specific producer standard for automotive applications and process automation. A widevariety of producers for sensors, control units and actors make use of this technology.

In the following basics about CAN networks and especially the interface of electronicallyactuated hydraulic components will be presented. The focus lies clearly on generalinformation.

Hydraulic valves that are controlled via CAN bus are used to process digital setpointcommands and supply the required volume of oil to the connected consumers. A setpointgenerator with CAN interface or an electronic control unit is in charge of generating thesetpoints as well as coordinating the data traffic in the entire system.

In general, ECUs connected to the CAN bus, must be able to solve the following tasks:

- Transmission of set point values and feedback of diagnostic data

- Parameter setting and start-up

- (Fault-) diagnosis

- Safeguarding against bus interruptions

Different protocols on layer 7 of the OSI reference model [9] are commonly used toarrange communication between the individual participants. The most widely used are:

- J1939

- CANopen

- DeviceNet

The following text represents a short overview of these and their characteristic differences.In addition, general information is provided on CAN bus systems and notes on layouts.

For detailed information about function of CAN networks or components as well as thephysical properties of this bus system please refer to literature like [14] or [10].

For detailed information on protocols please refer to chapter 3, chapter 5 and chapter 6.


2. CAN Interface

2.1. Hardware

The CAN bus (controller area network) is an asynchronous, serial bus system thatrequires only two wires for the data transmission. According to their signal levels theyare denoted by CAN_HIGH and CAN_LOW.

Twisted-pair cables with a characteristic impedance of 108 − 132 Ω are recommendedas bus line (according to ISO 11898-2 “high speed medium access unit”).

The protocols CAN 2.0 A & B and J1939, based either on 11 or 29 bit address data,are commonly used for data transmission formats (OSI layers 1 to 2). Both variants aresupported by the PSL/PSV CAN valve nodes on the hardware side.

The reference potential for the CAN bus is internally connected to the 0V signal of thepower supply.

NOTE

The CAN transceivers of the valve electronics are not galvanically insolated fromthe supply voltage.

If there are potential offsets, functional impairment and damage can happen.

It is up to the user to prevent level shifting between the (ground-) connections ofthe various bus participants.

2.1.1. CAN Bus Baud Rate

Each bus system must be assigned to all participants identical transfer rates. A compro-mise between the required transmission rate (or fault tolerance) and geometric length ofthe bus has to be found.

The transfer rate may vary depending on the length of the bus line. In Table 2.1 valuescan be defined. Note the relationship between transmission rate (baud rate) and maxi-mum allowable cable lengths. Also note the embodiment (linear vs. star topology) of thebus system.

Transfer rate Bus length Maximum length for tap line100 kbit/s 600 m 25 m125 kbit/s 500 m 20 m250 kbit/s 250 m 10 m500 kbit/s 100 m 5 m1000 kbit/s <20 m 1 m

Table 2.1.: Recommended Bus Line Length Limits


2. CAN Interface

250kbit/s are used as standard setting for PSL/PSV valve nodes. It is suggested to usea linear bus topology minimizing the length of tap lines. See also subsection 2.1.3.

2.1.2. CAN Bus Termination

Every CAN network must have two terminating resistors, each 120 Ω and installed at therespective ends of the bus lines.

If power is switched off, 60 Ohms (two times 120 Ohms in parallel) should be measuredbetween CAN_HIGH and CAN_LOW, if termination is installed properly.

INFORMATION

Connection contact sockets, mounted to the valve bank and containing a bus termination,are available as accessory for the PSL/PSV CAN valve banks (see section 1.8). Thestandard variant of these connection sockets does not have a termination.

2.1.3. Line Layout and Net Topology

NOTE

Improper wiring reduces the performance of the bus.

Star topology and too long tap lines lead to communication disorder.

The attempt to realize a linear network topology and to avoid tap lines shouldgenerally be made.

If this is not possible, the maximum length of the tap lines should follow the specificationsin Table 2.1, appropriate to the respective transfer rate.

An exemplary diagram of a CAN network is illustrated in Figure 2.1.


2. CAN Interface

+ Power

-centralneutralpointground

B

CH CL

CC

H CL

ACH CL

E

CH CL

DCH

CL

120Ω

120Ω

Figure 2.1.: Recommended Architecture for Grounding and Shielding of CAN BusSystems

Following recommandations can be derived from the example network:

- For suppression of interference radiation and/or minimizing of interference trans-mission at least twisted signal lines should be applied for longer sections of the busline. Additional shielded cables with defined impedance (120 Ω) would be better.

- The construction of the bus network should preferably be linear and terminated atboth ends with a load resistance of 120 Ω.

- Shielding of the CAN line can be neglected if the bus lines are short with only lowEMC loads. See fieldbus device A.

- There must not be a potential shift between the individual CAN users. Ground(GND) lines of all CAN devices have to be sufficiently dimensioned and routedtogether to one single point.

- If interference signals on the supply network are obtained, a local separation of thebus line is recommended.

- Tap lines for connecting individual participants to the bus should be kept short.See fieldbus device A.

- Medium length Tap lines should be twisted or shielded. See fieldbus device C.

- If the fieldbus device is far away from the main strand, a bus line leading to theparticipant and further from there should be used, but no Tap line. See fieldbusdevice E.


2. CAN Interface

In case of applicating shielded bus lines, one-sided direct connections of the shieldshould be designated to avoid ground loops.

Figure 2.2 shows one possible example for shielding the bus lines. One can alternativelyuse decoupling capacitors between the shield and the ground.

Figure 2.2.: Shielding bus lines

2.2. Protocol Philosophies Overview

The J1939 and CANopen protocols are examples for different protocol philosophies.Both protocols are basically covering the solution to identical assignments:

- Unique assignment of set point to valve

- Format definition for setpoint and status messages

- Format definition for access to internal parameters/data

- Safeguarding mechanisms for bus interruptions

The two protocol families differ substantially in their approach to these assignments.

While CANopen [4], and its extension for hydraulic valves CiA-408 [1], are geared towardstandardizing the valves and hence the internal software, the focus of J1939 is on thePlug&Play functionality in the vehicle section, without giving the valve producers anyguidelines for implementation.

Concerning safeguards against bus interruptions, CANopen proposes two safeguardingmechanisms, while J1939 leaves this issue all up to the user software.

WARNING

System integrator must take measures against communication disruption if this


2. CAN Interface

can lead to dangerous situation, for example by implementing a second shut-down path.

2.2.1. J1939

The J1939 protocol [11] was developed in the mid 80’s by SAE (Society of AutomotiveEngineers) and was used rapidly and widely in the automation segment, above all in utilityvehicles. It controls communication between the different bus participants by making asensible allocation of the 29-bit address layer to the participants and applications. Fixedaddresses and file formats are reserved to enable the engine control devices, brakingsystems etc. to exchange information. For a good description of this philosophy see also[15].

The advantage of this approach is its simplicity. With SAE’s catalog of identifiers (seealso [11]) it is possible to develop software tools that can decode any number up to 253of participants connected to the CAN bus and their messages. This enables direct andcomprehensive diagnostics. An address range for 16 “auxiliary valves” and their setpoint format is reserved for the valve actuation.

Key data for J1939:

- Higher-layer protocol, that uses CAN as physical layer

- Maximum bus length: 40 m

- Standard baud rate 250 kbit/s

- Maximum 30 physical nodes (ECUs) on one bus branch

- Maximum 253 individual participants (controller applications, CA). One controldevice can contain multiple CAs

2.2.2. CANopen

The CANopen protocol was developed as European equivalent to J1939 by the companyBosch as part of an ESPRIT project. Today the associated documentation is maintainedand updated by the user association CAN in Automation (CiA) (CiA). The protocolextension CiA-408 [1] is specifically geared to fluid applications. It was created on thebasis of the underlying documentation CiA-301 [4] and the preparatory work of theVDMA.

CiA-408 in particular makes a few sweeping assumptions regarding the internal set-up of the device software of electronically actuated hydraulic components. Thus, itpresupposes the implementation of two state machines (communication and application),which have to be initialised, before the valves can be operated.


2. CAN Interface

The master has to implement the start-up procedure.

CANopen has established itself as recognized standard, so that software, used fordiagnosis and parameterization, is commercially available. Instead of a fixed addresscatalog CANopen is using an interface description (EDS electronic data sheet) thatallows a detailed description of the scope of services and the available interfaces for anyCANopen participant.

Moreover, the protocol has also been integrated into the programming systems for PLCcontrols (e.g. CoDeSys). This means that the user only needs a minimum knowledge inorder to integrate, for example, the decentralized valve actuators into the programmingby means of an EDS file.

2.3. CAN Basics

Independant of the protocol used, the bus bus physics of CAN-networks defined in theISO 11898 causes similarities of all protocol implementations.

The following subsections provide a brief overview of essential characteristics.

2.3.1. Telegram

CAN messages are telegrams, which are data packages with a few bytes of user data.Table 2.2 shows the set-up of these telegrams.

Length 11-bit 29-bit Meaning1 bit SOF SOF Start of frame11/29 bit 11 bit CAN ID 29 bit CAN ID Identifier (priority)1 bit RTR RTR Remote transmission request bit6 bit Control field Control field Data length code, etc0..8 byte Data Data Data field2 byte CRC CRC Checksum2 bit ACK ACK Acknowledge bit7 bit EOF EOF End of frame

Table 2.2.: CAN Data Frame

The protocol families differ in the length of the address field (CAN identifier) that isprefixed to every telegram. The size of the data field (see Table 2.2) is identical,consisting in every case of a maximum of 8 bytes. This range is split up into individualdata according to the specific protocol. Figure 2.3 shows the format of a 11-bit Dataframe.


2. CAN Interface

Start-

of-F

ram

e

Field

(1bit

)

ArbitrationField (11bit)

Control Field (6bit) Data Field(0-8byte)

CRC Field (16bit) Ackno

wledge

Field

(2bit

)

End-of-FrameField (7bit)

RTR-Bit reserved CRC Delimiter ACK Slot ACK Delimiter

Figure 2.3.: Format of a Data Frame

2.3.2. Addressing

The address field allocated to every telegram has to assign recipient/sender/purposeto the telegrams. Address fields with 29 bit (J1939) as well 11 bit (CANopen) haveestablished themselves.

CAN object-ID (COB-ID) and/or CAN identifier (CAN ID) have established themselvesas designation for the address field.

All protocols have in common that every participant has or gets a number assigned thatis unique in the network. The standard designation for these participants is Node-ID.The conversion of the node-ID to the COB-ID is specific to each protocol.

2.3.3. Data Formats

Fields with a length of 1, 2, 4 or 8 byte are commonly used for the transfer of data values.The little endian data format is common for the values that are made up of multiple bytes,which means that the most significant byte is transmitted last.

Negative values are transmitted as two’s complement. For more detailed information onthat and various different data formats, such as strings and floating point values, pleaserefer to [4](chapter 7.1.4 to 7.1.6).

2.3.4. Typical Bus Setup

Figure 2.4 shows the typical structure of a CAN network (during commissioning).


2. CAN Interface

Figure 2.4.: Bustopologie

In addition to different devices required for the actual application, a PC-supporteddiagnosis tool is connected to the bus. It is used for monitoring the data flow and forconfiguring individual participants.

A master (controller unit) is installed on the bus in order to provide a variety of slavemoduls (valve nodes) with set point commands. It evaluates the feedback informationcoming from the nodes or it evaluates the position information coming from varioussensors connected to the bus.


3. CiA-301 Reference

CANopen has become a widely used communication protocol providing a standardframework for communication between devices in CAN networks. It is based on theCiA-301 [4] standard that is published by the user association CiA (CAN in Automation(CiA)).

Corresponding documents may be acquired via internet under the following address:http://www.can-cia.de/.

A more simplified form of integrating CANopen participants in various developer environ-ments or diagnosis systems (PC tools for commissioning) consists of inserting a detaileddevice specification into corresponding programs through an EDS file.

Figure 2.4 provides a schematic overview of such an arrangement, which is one of thestrong points of CANopen.

For more appropriate introductions refer to text books like [10], [17] or [14]

Aim of this chapter is to offer a basic introduction into the philosophy of CANopen and toexplain the different elements of the standard. Reference is regularly made to specificfeatures of the control of hydraulic actuators.

3.1. Structure of the Documentation

In this chapter the basics of CANopen, i.e. the details given in the device profile CiA-301[4] are explained.

This is the basis for understanding the device profiles CiA-401 and CiA-408. See section4 and 5.

For experts or impatient readers reference shall be made to section 5.2, which providesan exemplary explanation of the boot-up operation and the transmission of set pointsaccording to CiA-408.

3.2. Essential Concepts of CANopen

In this section essential characteristics of CANopen systems will be presented. Thosecan be derived directly from the CiA-301 standard.



3.2.1. Device Profiles

The users Group of CAN in Automation (CiA) attributes a number of several so-called“device profiles” to the large number of different CAN devices, grouping them into classesaccording to their functionality.

Though essential properties (especially communication procedures) are defined inthe device profile CiA-301 [4], numerous device-specific extensions exist with specificcharacteristics depending on the application.

With the assistance of the VDMA and various hydraulic component manufacturers thedevice profile CiA-408 [1] was created for specific applications such as fluid engineeringcomponents like valves. It is based on the profile entitled “Fluid Power Technology”,version 1.5, published by the VDMA.

The standard defines data formats and commands for the internal status administration,setpoint transfer, parameterization and the processing of error states.

HAWE recommends its customers to select the CiA-408 protocol version due to itsfunctionality and flexibility. Chapter 5 offers detailed information about the specialfunctions.

Alternatively (for a simplified actuation of the valve) the device profile CiA-401 [3] spe-cialized on input and output modules might be used. See also chapter 4. It offers theadvantage of significantly lower complexity.

3.2.2. CAN Master and CAN Slaves

The CANopen standard distinguishes between masters and slaves1. A single networkmight contain several masters as well as several slaves.

PSL/PSV CAN valve nodes serve as distributed actuators and behave therefore likeCAN slaves. In complex control assignments a CAN master, typically in form of a centralcontrol unit, is required for their actuation and transmission of setpoints, activationcommands etc. This unit has to oversee the following assignments:

- Coordinated boot-up of the entire network

- Setpoint generation

- Setpoint transmission to individual valves

- Higher-order error management

- Function monitoring for activated CAN participants

- Transmission/evaluation of diagnosis information

- Higher-order functions, such as activating/deactivating of hydraulic power

1terminology defined in CANopen DS301 4.4.1



Of elevated significance is the last mentioned point.

In the event that the connection to the control device is interrupted, the valves can detectthis via timeouts and will independently revert into a safe mode, i.e. they switch into aneutral position. However, this assumes that one of two monitoring mechanisms, thatare provided in the protocol, is activated, which is strongly recommended. Please referto subsection 3.3 for details.

WARNING

Potential danger of unwanted movement caused by broken cables!

3.2.3. Data Objects, Telegram Types

The CANopen standard [4] distinguishes between the following data objects (telegramtypes):

- PDO (Process data object)

- SDO (Service data object)

- NMT (Network management)

- EMCY (Emergency object)

- SYNC (Synchronization)

Process data objects (PDOs) are telegrams that are cyclically sent and apply to theactual function of the particular CAN participant. PDOs are responsible for the majorpart of the busload in a CANopen network. They undertake the most important task ofthe CAN participants: transmission of data to or from a slave.

Service data objects (SDOs) are sent in irregular intervals and are used for parameteri-zation.

The SDOs provide write and read access to the internal data of the valve, and to readout or write parameters. Basic of this philosophy is the so-called object dictionary (seesubsection 3.2.4), representing a list of entries with the associated indices, which makesthe internal data structures of any slave accessible.

Please also observe the information given in subsection 3.2.5 regarding the directionalinformation of PDOs. See also section 3.5 for detailed information about sending andreceiving SDOs.

In addition to the PDOs and SDOs there are also commands for network management(NMT) as well as prioritized identifiers to communicate errors, so-called emergencyobjects (EMCY). See also sections 3.2.6, 3.6 and 3.7.3 for details.



3.2.4. Object Dictionary

A so-called object dictionary determines the heart peace of the CANopen philosophy.Normally it represents the main content of all devices build on CiA-301.

The key invention is to give all users of a CANopen slave access to all readable orwritable parameters in a standardized way. The purpose of device specific device profilesis to define parameters which are generally valid for some group of application devices.This happens by introduction of access code numbers (2byte index + 1byte sub-index).

It is left to device manufacturers to implement access possibilities to particular elementsof the device profile. Some device profiles also contain mandatory dictionary entries,enhancing the CiA-301.

The object dictionary is split up into the categories listed in table 3.1.

Type Index Draft StandardCommunication objects 0x1xxx CiA-301 V4.02 [4]Manufacturer objects 0x2xxx See appendix A.4.21Profile specific objects 0x6xxx CiA-401 V3.0 [3]Profile specific objects 0x6xxx CiA-408 V1.5.2 [1]

Table 3.1.: Entries in the Object Dictionary

Telegrams, that are defined in CiA-301, enable the request of additional information onparameters (like read or write permissions or physical units). As CiA-301 is the commonbasis for which a separate address space is reserved and included in all specific profiles,numerous commercial software products might be used for comfortably parameterizingCANopen slaves. The user does not have to deal with details of the communication (tocompose or analyze telegrams byte-by-byte).

This is also based on the concept of EDS (electronic data sheet) files in which all acces-sible parameters of a CANopen slave can be defined. Please also refer to subsection2.3.4 as well as section 8.3.

3.2.5. Nomenclature, Definitions, Notes

The following shows the communication functions in table format. Reference is made touniform designations for which the following definitions shall apply:

Direction Information

Data telegrams sent by the central control device to the valve, i.e. from master to slave,are designated M → S. Telegrams going the opposite direction from slave to the centralcontrol device (master) are designated with S →M . The information in the column DIR(direction) indicates the flow direction.



Telegram Length

In the case that a CAN telegram contains less than the maximum possible 8 byte, it willonly be shown with the number of required bytes. The table format does not explicitlyshow the length of the telegram. It is recommended to send telegrams to the valves withan exactly specified length.

Addressing, IDs

Every CAN bus participant has a unique identifier from 0-127, the so-called node-ID.The implicit assumption is that the central control device (the master of the network)has 0 as node-ID. Unless explicitly specified otherwise, the designation node-ID alwaysrefers to the valve affected.

The destination address contained in every CAN telegram, which is also designated asCAN identifier, is termed in the following as COB-ID (CAN object-ID).

RXPDOs, TXPDOs

Process data objects (PDOs) are telegrams that are frequently transmitted, e.g. actualvalues and setpoints.

The designations RXPDO and TXPDO, which are contingent on the position, are gen-erally omitted to avoid misconceptions. In case that they will be used nonetheless, thevalve serves as reference point. Instead, the nomenclature is used whereby master =setpoint generator and slave = valve = setpoint recipient. In most cases the direction ofinformation S →M or M → S is explicitly specified.

Byte Sequence

Data bytes are numbered on the bus in the sequence of their transmission, i.e. startingwith byte 0. With data types made up of multiple bytes, MSB (most significant byte)signifies the highest value byte and LSB (least significant byte) the lowest value byte.

Bit Fields

In bit fields the bit 0 designates the lowest value data bit.

Prefixed Integer Values

Negative numbers are displayed as one’s complement.



3.2.6. CANopen Default Identifier Distribution

Due to the 11-bit addressing the address space of CANopen comprises 211 = 2048possible COB-IDs. The number of 27 = 128 potential participants enables dividing theentire address space into 16 partitions with the length 128, which can have variousfunctions assigned.

DIR Address range Hexadecimal COB-ID FunctionM → S 0 0 0 NMTM → S 128 0x080 128 Sync commandS →M 129 - 256 0x080 - 0x0FF 128 + Node-ID Emergency ObjectS →M 384 - 511 0x180 - 0x1FF 384 + Node-ID TxPDO1M → S 512 - 639 0x200 - 0x27F 512 + Node-ID RxPDO1S →M 640 - 767 0x280 - 0x2FF 640 + Node-ID TxPDO2M → S 768 - 895 0x300 - 0x37F 768 + Node-ID RxPDO2S →M 896 - 1023 0x380 - 0x3FF 896 + Node-ID TxPDO3M → S 1024 - 1151 0x400 - 0x47F 1024 + Node-ID RxPDO3S →M 1152 - 1279 0x480 - 0x4FF 1152 + Node-ID TxPDO4M → S 1280 - 1407 0x500 - 0x57F 1280 + Node-ID RxPDO4S →M 1408 - 1535 0x580 - 0x5FF 1408 + Node-ID TxSDOM → S 1536 - 1701 0x600 - 0x67F 1536 + Node-ID RxSDOS →M 1792 - 1829 0x700 - 0x77F 1702 + Node-ID NMT

Table 3.2.: CANopen Default Identifier Distribution

Table 3.2 shows this distribution. A telegram’s COB-ID initially allows to define theallocation to a partition (from the 4 highest value bits). This defines the function, i.e.whether it is for example a PDO from master to slave or for example a SDO answer fromslave to master.

The last 7 bit of the COB-ID specify who is sending the telegram or to whom it is beingsent. Please note the direction information as listed in table 3.2. In the event that a slaveis sending to a master, the node-ID of the sending slave must be used. Telegrams sentfrom the master to a slave the node-ID of the recipient must be used.

3.3. Safety Mechanisms

The task of all safety mechanisms implemented in CANopen is the detection of faults orinterruptions in communication. So it is specifically the role of mutual monitoring whetherbus users are still operating and able to communicate.

For actuators, in the case of a communication interruption, the typical risk is an unwantedactivation. A potential fault scenario is that the corresponding actuator will not notice thestop command of his master because of a disturbed or interrupted communication andwill remain active with the latest setpoint.



CANopen provides seperated hedging mechanism (Node Guarding, Heartbeat) and-f/or setpoint transmission (Setpoint Timeout) to infer the full functionality of the buscommunication.

CANopen offers two methods for protection:

- cyclic query of the status of the node by a master: “node guarding” principle

- automatic transmission of a cyclic message by cyclic slave/master: “heartbeat”principle

We strongly recommend to enable one of these two monitoring mechanisms on the partof the valve node. The simultaneous use of both processes (Node Guarding, Heartbeat)is mutually exclusive because of the use of different functionality in the same COB-ID.

More frequently used is the heartbeat process which is generally more flexible andrequires less bandwidth. The CiA-408 [1] favors heartbeat too.

The cyclical setpoint transmission could be activated without any problems among oneof the mechanisms mentioned above

3.3.1. Node Guarding

Node Guarding means actively query the state of the Communication State Machine of aslave by his master. Therefore a bit (called RTR bit) that is reserved in a message headerto retrieve messages is used. The slave is asked to send its current state immediately(NMT state, state variable).

The basic procedure is described in figure 3.1. The supervising master sends a requestmessage to the monitored slave whose immediate response is expected. In the absenceof it a state of emergency “Node Guarding Event” is generated.



NMT Master

NodeGuardTime

NodeGuardTime

request

confirm

request

indicationNode Guarding Event

COB-ID=1792 + Node-ID

Remote transmit Request

0 11t

6. . . 0s



NMT Slave

indication

response

indication

Figure 3.1.: Flowchart Node Guarding

The format for request and response messages is decribed in tables 3.3 and 3.4.

DIR COB-ID B0M → S 0x700 + Node-ID (RTR) -S →M 0x700 + Node-ID See table 3.4

Table 3.3.: Format Node Guarding Telegram

Additionally it is possible to change a toggle bit in the response message for furthermonitoring which confirms that the slave does not only respond, but also has intrinsicactivity.

bit7 bit6 - bit0Toggle bit Slave communication status see 3.7.1

Table 3.4.: Content Node Guarding Response Messages

In practice often more important than the function of supervision of the slaves is testingthe connection to the master. For this purpose the same request message is also usedfor the Node Guarding method (see table 3.3).



The inquery for the condition of the monitored NMT-slaves should happen cyclically bythe master. The time between two requests is called the guard time. This value is usedas the expected value for the arrival of messages.

To configure a slave the object 100Ch is provided which indicates the guard time inmilliseconds. By configuring Parameter 115, namely PAR_NODEGARD_TIME the samesettings can be achieved. The default value is zero. A non-zero value of this parameteractivates the Node Guarding mechanism.

The cyclic query message from the master gives the slave the possibility to examine thefunctioning of the master. In order to become adjustable robust, a tolerance factor isdefined how many times the cycle time must be exceeded to actually activate an internalerror (“life-guarding event”).

The so-called Life Time Factor, object 100Dh, is responsible for this. It can also beconfigured by Parameter 115, namely PAR_NODEGUARD_FACTOR. The NMT slavechecks to see if he was interrogated within the so-called “Node Life Time”(Node GuardTime · Life Time Factor).

If this did not happen, the slave must act on the assumption that the NMT master is notin normal operation. He then activates a “Life Guarding Event”. If the Node Life Time is0, there is no monitoring of the master.

In detail the timing is shown in figure 3.2. In case of monitoring the function of the masterby the slave the term “life guarding” is common.



NMT-Master

NodeGuardTime

NodeLifeTime1

request

confirm

request

confirm



0 11t

6. . . 0s



0 11t

6. . . 0s

s: Status NMT-Slavet: toggle Bit

NMT-Slave

indication

response

indication

response

Life Guarding Event

1 : Node Life Time = Guard Time * Life Time Factor (CIA-301 Object 0x100C und 0x100D)

Figure 3.2.: Flowchart Life Guarding

3.3.2. Heartbeat

The Heartbeat process does not distinguish between master and slave, but betweenproducers and consumers of Heartbeats.

A producer “Heartbeat Producer” automatically sends his status in defined intervals inorder to prove his ability to communicate. The interval between two Heartbeat messagesfrom a so-called Heartbeat Producer is defined by the object 1017h or by the parameter117 (PAR_HEARTBEAT_PRODUCER). At a value of 0, the sending of Heartbeats isdisabled.

DIR COB-ID B0HP → HC 0x700 + Node-ID Slave Communication Status see 3.7.1

Table 3.5.: Format Heartbeat Telegrams



It is up to the other bus users to evaluate the sent Heartbeats; an evaluation is made bythe so-called “Heartbeat Consumer”.

A “heartbeat consumer time” is set in object 1016h, or in parameter 116, namelyPAR_HEARTBEAT_CONSUMER. This object contains an u32 data field in sub-index 1,which stores the Heartbeat Time in bit 0 to 15. The consumer time should be 1.5 – 2times longer than the producer time to ensure that a missing heartbeat really is lost andnot just delayed.

This time interval describes the maximum time until the next Heartbeat Telegram mustbe received. Otherwise, a Heartbeat Event is generated.

For every “Heartbeat Consumer” an associated producer has to be named, whoseHeartbeat should be monitored. Corresponding configuration is done by passing thenode-ID of the producer, which is denoted in bit 16 to 23 as u8 of the object 1016h.

3.3.3. Setpoint

For activation of cyclical setpoint transmission the timeout parameter for expectedsetpoints has to be set with a value different from 0.

The Object Setpoint timeout has the index 2200h and should be set with values 3 to 4times as big as the typical setpoint rate. Alternatively the setpoint timeout can be set viaParameter 119, namely PAR_ERR_SP_TIMEOUT.

Heartbeat and setpoint timeout can be active together. In this case, a heartbeat telegramresets the timeout counter for the setpoint timeout.

“Reading and Writing Parameters” is described in chapter 7.4.5.

3.4. Process Data Objects (PDOs)

As the detailed format definition for PDOs is not part of CiA-301 but is given in devicespecific profiles like CiA-401 or CiA-408, only superficial information about PDOs can begiven here.

3.4.1. Setpoints and Setpoint Processing

The different device profiles (CiA-301, CiA-401 and CiA-408) do not define a uniquesetpoint format. CiA-408 has no detailed description how to do that, but refers to theVDMA fluid profile [13] section 7.1.2.

In order to avoid the impracticable use of physical units for volume flows, the setpointsfor PSL/PSV CAN valves are always scaled relative to the nominal maximum flow of thevalve section. The corresponding value range and the implementation of the directioninformation depends on the device profile which is used.



The setpoint transmitted can also be (temporarily) changed by the valve. This happensfor example if the user has specified ramps, i.e. if quick setpoint changes shall be limitedfor mechanical reasons.

By changing the parameter the maximum flow can be limited, so that the softwaresimulates a valve with a smaller nominal quantity. In this case the quantity delivered bythe valve corresponds with the setpoint that has been linearly scaled down.

Given the appropriate parameterization a non-linear connection can be defined bet-ween setpoint and valve opening, e.g. if the realization of a fine-tuning area shall beelectronically realized.

3.4.2. Data Format for Setpoints

For data values made up of a multitude of single bytes the “little endian” format is mainlyused in CANopen systems. 2

In the little endian format the least significant byte (LSB) is stored in the smallest storageaddress. This type of data coding is also known as “intel format”.

The little endian format is used, among others, for the CiA-408 setpoint definition, i.e.within the CAN setpoint messages the higher-value byte is sent “later”. The typicalsetpoint length is 2 bytes.

3.4.3. Actual Value

During operations every valve section provides cyclical feedback on the actual flow valuecalculated from the position of the spool. Account must be taken in this context, that thisis based on the assumption that there is ideal pressure supply of the valve.

The actual values reported back from the valve always refer to the nominal amount inparts-per-thousands specific to the hydraulic section.

Analog to the setpoints, the little endian format is also used for coding 2 bytes values.

3.4.4. Communication with PSL/PSV CAN-Tool

The PC servicetool uses Rx/Tx-PDO4 for communication purposes with connectedPSL/PSV CAN valves.

Additionally, PSL/PSV CAN valves use TxPDO3 for acyclic transmission of ASCII tracedata. To deactivate this transmission please set CANopen object 2010.0 to 1.

2

In big endian encoded values, the most significant byte is stored on the lowest memory address.Typical representative of this format are Motorola CPU’s and IBM mainframes. See also [4].

The curious term originates, according to [16], from the satirical novel Gulliver’s Travels by JonathanSwift [12], in which the dispute over whether an egg is turned over at its sharp or thick end, caused theinhabitants of Lilliput to split into two hostile camps called the “little endian” and the “big endian”.



3.4.5. PDO transmission types

Typically the CANopen master can be configured to generate a cyclic SYNC message.The SYNC message has a low COB-ID and therefore a high priority.This ID is configured in object 1005h and has a default value of 0x80. For PSXCANdevices only the default values of 0x80 is possible.

There is only one SYNC message producer, but there can be any number of SYNCconsumer.

Configuration of PDO behaviour is done with:

• Receive PDO1 communication parameter with object 1400.2h

• Transmit PDO1 communication parameter with object 1800.2h

Possible parameter values are described in Table 3.6. Supported values for PSXCANvalves are denoted with "+" in the “Supported” column.

Value Description Supported0x00 synchronous (acyclic) -0x01 synchronous (cyclic, every sync) +0x02 synchronous (cyclic every second sync) +0x03 synchronous (cyclic jeden third sync) +. . . . . . +0xF0 synchronous (cyclic every 240th sync) +0xF1 reserved -. . . . . . -0xFB reserved -0xFC RTR-only (synchronous) -0xFD RTR-only (event-driven) -0xFE event driven (manufacturer specific) -0xFF event driven (device / application profile specific) +

Table 3.6.: Description of PDO transmission types

RTR-only types are not possible for Receive PDOs.

The default value for TPDO1 is event timer (0xFF), a configurable timer that emits onetelegram every x milliseconds. The value x is configured in 1800.5h or parameter 118(CAN_STATUS_TIME). The default value is 20ms.

3.5. Service Data Objects (SDOs)

The CANopen standard CiA-301 provides so-called SDOs (service data objects) to queryor change parameters of CAN slaves. A separate address range is provided for this astable 3.2 shows.



Generally, access takes place via a so-called index (16 bit) and a corresponding sub-index (8 bit). The SDOs exchanged are of any size. An appropriate control byte isused to regulate the data transfer. The assignment of index and sub-index is on closeconnection with the concept of the so-called object dictionary. See also section 5.5.

3.5.1. SDO Structure

Table 3.7 shows the set-up of SDO telegrams. The control device is designated asmaster, while the valves connected to the bus are depicted as slaves. The CAN objectidentifier (COB-ID) always contains the node-ID of the slave, in one case as recipient ofthe request and in the other case as sender of the answer.

DIR COB-ID Byte 0 Byte 1 Byte 2 Byte 3 Byte 4-7S →M 1408 (0x580) + Control Index Index Subindex Data

Node-ID (Slave) byte LSB MSBM → S 1536 (0x600) + Control Index Index Subindex Data

Node-ID (Slave) byte LSB MSB (reserved)

Table 3.7.: SDO Structure

A distinction must be made between reading and writing requests to the slave. In thecase of a reading request, the data field in bytes 4-7 is not used, while it contains thecorresponding data in case of a writing request.

The access and data type is coded in byte 0 (control byte) of the telegram. Table 3.8provides a list of potential values of the control byte that might occur in requests frommaster to slave.

DIR Control byte Meaning Bytes 4-7M → S 0x40 Read access Reserved - initialized with 0x00M → S 0x23 Write access 4-byte DataM → S 0x27 Write access 3-byte DataM → S 0x2B Write access 2-byte DataM → S 0x2F Write access 1-byte Data

Table 3.8.: SDO Control Bytes M → S

Table 3.9 shows the slave’s answer, sent in case of success.

DIR Control byte Meaning Bytes 4-7S →M 0x43 Read access 4-byte DataS →M 0x47 Read access 3-byte DataS →M 0x4B Read access 2-byte DataS →M 0x4F Read access 1-byte DataS →M 0x60 Acknowledgement Write access Reserved

Table 3.9.: SDO Control Bytes S →M



Attention should be given to the fact that write commands are answered with the sameacknowledgement telegram (0x60 in byte 0).

Every SDO received by and addressed to the slave is answered, although read- aswell as write commands can fail for different reasons, i.e. be rejected by the slave (orthe master). Specific reasons are transmitted in form of error codes using the answertelegram.

DIR Byte 0 Byte 1 Byte 2 Byte 3 Byte 4-7S →M 0x80 Index Index Subindex abort code

Table 3.10.: SDO Transfer Error Message

Table 3.11 provides an overview of the abort codes that are supported by HAWE CANPSL/PSV.

Abort Code Meaning0x06090030 Parameter outside permitted range0x06010002 Write command on read only parameter0x06020000 Unknown index0x06090011 Unknown sub-index0x08090020 Transfer not possible0x05040000 Protocol timed out

Table 3.11.: SDO Transfer Abort Codes

3.5.2. SDO save

To store parameter changes in EEPROM memory, a SDO Object 0x1010.1 save com-mand is necessary.

To avoid accidental storage, the command is only executed when signature “save” isused as command, as shown in table 3.12.

DIR COB-ID B0 B1 B2 B3 B4 B5 B6 B7M → S 0x600 + 4B Index Index Sub “e” “v” “a” “s”

Node-ID write LSB MSB IndexM → S 0x600+ 0x23 0x10 0x10 0x01 0x65 0x76 0x61 0x73

Node-ID

Table 3.12.: SDO save

3.6. Emergency Objects

Emergency objects (EMCY) are highly prioritized messages that are sent unrequestedby one CAN participant. These messages notify an important status change of the



participant and are sent on COB-ID 0x80h + node-ID with a length of 8 bytes. Mostly itis an error in the device that triggers such a message.

DIR COB-ID B0 B1 B2 B3..B7S →M 0x80 + Node-ID Error code Error code Error class 0

Table 3.13.: Emergency Objects (EMCY)

It is possible to fetch the amount of currently active errors by reading Object 1003.0h.Reading the subindices 1003.1 to 1003.16 you get the corresponding error codes.

The error code in bytes 0 and 1 of the EMCY object is little endian formatted and possibleerror messages are listed in the appendix A.

In addition, an error class is transmitted in the PDO byte 2, which can be recalled in theerror register (SDO index 1001h) too. Possible values for the error register are shown intable 3.14.

Bit Hex. bitmask Meaning0 0x01 General error1 0x02 Current2 0x04 Voltage3 0x08 Temperature4 0x10 Communication error5 0x20 Device profile specific6 0x40 Reserved (always 0)7 0x80 Manufacturer specific

Table 3.14.: Error classes in the error register

Error messages are identical for the CANopen profiles CiA-401 and CiA-408.

Independend from the emergency object the PDO allows a simplified but less detailedway to read status and error messages. This is explained in section 5.2.5.

Additional information about error management that is not CANopen specific can befound in section 7.3.

3.7. Network Management

As a separate sub-functionality the CANopen standard defines the network management(NMT). Specifically it is about the control of the communication behavior of different busparticipants.

Usually CANopen slaves are configured to behave initially passive apart from a singlebootup message. After power up they are waiting to be enabled by their master.



The functions of network-management are closely linked with standardized internal statemachines. See also subsection 3.7.1.

3.7.1. Communication State Machine (CSM)

The startup of digital electronic bus devices is typically implemented by means of aninternal state machine which controls the boot-up of every device when when volt-age is supplied. It might also contain procedures for a self test and the start of thecommunication functions.

Some properties and characteristics of this state machine for CAN slaves directly followthe standard CiA-301 [4], especially what regards the communication functionality. Thecorresponding state machine is depicted in figure 3.3.

Initialisation[C1]

Pre-Operational[C2]

Stopped[C5]

[C7]

Operational

[C3] [C4] [C8]

[C6]

Figure 3.3.: Communication State Machine CiA-301

Contingent on the momentary status of the CSM only specific telegram types (see table3.15) are received or sent.

Telegram type Initialisation Pre-Operational Operational StoppedBootup message •PDO •SDO • •Sync message • •NMT • • •

Table 3.15.: Permitted Telegrams, According to CSM State

A start telegram sent by the master is required in order to activate a CANopen participantthat has just been switched on. This can either activate pinpointed individual participantsor all at the same time.

The associated commands that cause transitions between the states are called NMTcommands. See section 3.7.3.



In general the CSM is used to administrate all communication. Remanent parameters(communication parameters), which include addresses, timeouts, etc., are attributed tothe CSM in the internal memory of the CAN slave (EEPROM).)

Transition ExplanationC1 Power switch on the deviceC2 Hardware initialization completedC3,C7 (external) request pre-operationalC4,C8 (external) operational requirementC5,C6 (external) request stopped

Table 3.16.: Transitions of the Communication State Machine CiA-301

Table 3.16 outlines the transitions shown in the state chart 3.3.

Table 3.18 shows the command sequences for the operating states of the slaves. If B1 =0x00, the command affects all nodes on the bus.

3.7.2. Communication State

The states shown in figure 3.3 are assigned numerical values.

Status Status (dez) Status (hex)INIT 0 0x00PREOPERATIONAL 127 0x7FOPERATIONAL 5 0x05STOPPED 4 0x04

Table 3.17.: Communication Status

These will be sent by the slave for example per Node Guard or Heartbeat protocol.

3.7.3. Network Management Telegrams (NMT)

The master controls the bus with NMT commands. This way individual slaves canbe started and stopped. Table 3.18 provides a list of commands for controlling thecommunication state machine of the slaves.

DIR COB-ID B0 B1 EffectM → S 0x00 0x01 Node-ID activateM → S 0x00 0x02 Node-ID deactivateM → S 0x00 0x80 Node-ID after pre-operationalM → S 0x00 0x81 Node-ID resetM → S 0x00 0x82 Node-ID communication reset

Table 3.18.: NMT Commands for Controlling the CSM



The recipient-ID (node-ID) of the NMT telegram is specified in byte 1. If all slaves shallbe addressed B1 = 0x00 has to be sent.

3.7.4. LSS

A methode for configuring and addressing is offered by the CiA 305 Draft StandardProposals [2], the so called Layer Setting Services (LSS). The task is to modify the maincommunication parameters like node-id and baudrate, by running network.

The advantage of the process carried out, defined by CiA, is that thereby networks canbe maintained, where duplication of node-IDs arise. This may be the case if, for example,by alteration configured valve banks or sections without prior redirection are connectedto another CAN network.

The address setting by LSS is not based on the currently setted node-id but on a uniqueidentification of the device, checking it’s serialization. Internal data fields of the busparticipant are used therefore:

- Vendor ID

- Product Code

- Revision Nr.

- Serial Number

These data, used for unique identification, correlate to the entry 0x1018 of the CANOpenObject dictionarys (Identity Object). To detect those parameters for all participantsconnected to the bus, see section 3.7.5.

A 32 Bit range is provided for each number. Therefore it is possible to identify eachparticipant in a theoretical address space of 128 bit.

For a correct address change the following consecutive steps must be carried out:

- Put each participant in configuration mode (Stop of the output)

- Activation of exactly one participant by unique combination of Vendor ID, ProductCode, Revision Nr. and Seriennumber

- Address change of the single activated participant

The messgae sent by the activated node, confirms the successful activation. The masterhas to ensure the receipt of a response, taking the uniqeness of the serial number forgranted. The address change can take place now.



DIR COB-ID DLC B0 B1 FunctionM → S 0x7E5 8 0x11 NNID Transmit new Node-IDS →M 0x7E4 8 0x11 Error Code Acknowledgement change

Node-IDM → S 0x7E5 8 0xFB NSECID Transmit new Sections-IDS →M 0x7E4 8 0xFB Error Code Acknowledgement change

Sections-IDM → S 0x7E5 8 0xFC NBANKID Transmit new Bank-IDS →M 0x7E4 8 0xFC Error Code Acknowledgement change

Bank-IDM → S 0x7E5 8 0x17 - Save configuration remanentS →M 0x7E4 8 0x17 Error Code Acknowledgement storageM → S 0x7E5 8 0x04 0x00 Quit configuration mode

Table 3.19.: Communication sequence LSS, readdress

The corresponding sequence is shown in table 3.19. The node commits the transmissionof the new Node-ID (NNID). In case of success an error code with value 0 will be returned,if the transmitted Node-ID will not be accepted by the node, a error code with value 1 isreturned. The diagnosis LED of the node will be switched into the mode IdentificationFlashing, if the activation was successful. See also section 3.7.6.

- remanent storage of the new address information: remantent storage of configura-tion has to take place, in case of success, it will be committed by the bus devicewith 0.

- system reboot of the new addressed bus device: restart is necessary to activatethe configuration. This can be done by disconnection of its power or by resetrequest by NMT.

Identifiers 0x7E5 (from the Master) and 0x7E4 (from the Slave), on which the protocol isworked through, are used for LSS communication. The specification provides that eachtelegram has to have 8 data bytes, even though parts will remain eventually unused.Unused bytes will be filled with the value 0.

There is also a need to ensure, that devices to be configured are inactiv. This can beachieved by stopping the Communikation Statemachine and subsequent invitation toquit the Configuration Mode. See also 3.7.1.



DIR COB-ID DLC B0 B1 B2 B3 B4 FunctionM → S 0x000 2 0x02 0x00 - - - All participants after

NMT StopM → S 0x7E5 8 0x04 0x00 - - - Configuration

mode waitingM → S 0x7E5 8 0x40 LSB → MSB Vendor IDM → S 0x7E5 8 0x41 LSB → MSB Product CodeM → S 0x7E5 8 0x42 LSB → MSB Revision Nr.M → S 0x7E5 8 0x43 LSB → MSB Serial numberS →M 0x7E4 8 0x44 - - - - Acknowledgment

Table 3.20.: Communication Sequence LSS, Activation

Table 3.20 describes the sequence of the activation. All participants are set into the‘Stopped Mode‘ by the master, urge all bus participants to quit the Configuration Modeand sends four consecutive telegrams, attract exactley one participants.

3.7.5. Participant Identification by LSS

The mechanisms for readdressing of bus participants, as described in the previousparagraph, assumes that including the serial number it must be known which devicesare currently connected to the bus. For activation of a participant all components of theIdentity Objects are required.

This presents the user with the major challenge to have all this data available for usingLSS Services.

To store the current valid data of all existing participants in the remanent storage ofthe master migth be one potetial solution. At powerup the master migth compare thestored data with the reality. Therefore missing devices (caused by change) are clearlyidentifiable.

This approach will not work if in case of service newly added bus participants have to beidentified. Therefore we offer as extension and addition to the LSS mechanismn of theCiA two other possibilities:

- Participant Identification by broadcast

- Activation of the diagnosis LED (Identification Flashing) in order to find participants.See also sections 3.7.6.

A broadcast command ensures that all PSX valve nodes register themself and announcetheir serial number.

For this reason the LSS mechanism of targeted re-addressing is appicable for newlyadded nodes.

The Identification Flashing is useful to explicitly associate the actually activated nodewith its installation position. This is particularly important if multiple Bus Participants are



changed simultaneously. Thus, it can be verified, which participant (with unique serialnumber) is installed on which position.

Participant Identification by Broadcast

A telegram, part of the NMT address space, is used as broadcast object, see table 3.21.

DIR COB-ID DLC B0 FunctionM → S 0x7E5 8 0xFF Broadcast for Participant Identification

Table 3.21.: Communications Process, Broadcast

A response of all slaves may be delayed, up to 3 second after the broadcast. To equalizethe response telegrams sent on the same COB-ID, each node chooses a random delayafter receiving the request.

The associated response message contains the serial number of the node and itsNode-ID, see table 3.22.

DIR COB-ID DLC B0 B1 B2 B3 B4 B5 B6 B7S →M

0x7E4 8 0xFF LSBSerial

MSBSerial

Node-ID

BNK SEC

Table 3.22.: Communications process, response of the slaves to a Broadcast telegram

The master is able to detect possible duplications of node-ids in the incoming responsesafter a broadcast telegram by using the node-id entry in B5. Furthermore, it is possibleto readdress individual slaves to a new node-id, using the serial number.

For further information, the term of bank (BNK) and the number to name the section(SEC, correspponds to the installation position) within the bank, will be transmitted.Newly delivered valve blocks ex factory are initialized with those values.

Vendor ID

All HAWE CANOpen products have the Vendor ID 711 = 0x2C7, listed at the CIA.

Product Code

The Product Code of CAN PSX valves is 1.



Revision Nr.

Technical modifications may increase the revision number. This is the reason why0xFFFFFFFF is accepted as a wildcard additional to a readable revision number.

3.7.6. Identification Flashing

A red-green flashing sequence of the diagnosis LED is called Identification Flashingwhere red-green alternate permanently. This enables locating of a CAN-PSX valvenode in the CAN network, but only if the master has activated the Identification Flashingespecially for this participant.

This could be arranged in two ways:

- Activation by LSS (for preparation readdressing), see table 3.20

- Targeted activation of a single CAN-PSX valve node knowing it’s node-id

In the first case the Identification Flashing signals the successful participant activation,which must preceed a Readdressing by LSS. Before the readdressing takes place, thereis the possbility to control the selection of the right participant and eventually stop thereaddressing process.

An activation by node-id is described in table 3.23.

DIR COB-ID DLC B0 B1 B2 FunctionM → S 0x7E5 8 0x37 Node-ID 0x07 Requirement Identification

Flashing

Table 3.23.: Requirement Identification Flashing

3.7.7. Participant Identification by operating the hand lever

There is another possbililty for a unique identification of CAN PSX valves if they areequipped with a hand lever. Application is re-commissioning or the case of failure wheresingle sections or blocks were changed and have to be identified uniquely.

It is possible for a user/service technician to select a valve uniquely by using the handlever. The caused movement of the slide provokes internally a position error withoutappropriate setpoint value. The valve mentions the deviation from the required positionand places an error message on the bus

This behaviour depends on the following conditions:

- valve block is powered

- no settpoint setting

- Tracking error monitoring is activated (recommended default)



Under these conditions, using the belonging emergency objects, a participant identifica-tion is possible. Therefore see sections 3.6 and 3.7.3.

Disadvantage of the method is, that the response is based on the node-id of currentvalve node. Readressing is not possible if IDs are duplicated. Therefore CAN PSX valvenodes offer the additional possibility to trigger the identification telegram by hand lever,as shown in table 3.22.

Precondition are:

- valve block is powered

- no settpoint setting

- affected (or all) participant(s) has (have) been set to the state NMT Stopp (seetable 3.20)

- Tracking error monitoring is activated (recommended default) with parameterRGL_CONT_LIM_DIST (nr. 58 > 0)



Distributed actuators and sensors used for distributed applications are the subject ofCiA-401. Basic features of communication are taken from CiA-301. A specialization influid power components is not provided.

Since valves can be considered as actuators as well, for simple applications the use ofthis device profile is logical.

4.1. Essential Characteristics

For end users, who do not want or need to use the functional range of CiA-408 in detail,CiA-401 is a recommended alternative. The simplicity of the device profile ensures thatbus participants can be put into operation as fast as possible.

The simplified handling of the CiA-401 profile results in particular from the absence of theinternal state machine (as required in the CiA-408 [1] for standard-compliant hydrauliccomponents) and a much simplified fault management.

Using appropriate parameters, even the standard activation required for the CANopenslaves connected to the bus, might be skipped. After voltage supply, CAN slaves will thenbe able to go into operation automatically, without the need of an activation messagefrom the master. See also subsection 4.2.1.

4.2. Startup

In principle, the boot-up behavior of a CANopen slave is defined by the base specificationCiA-301. In practice this means that activation must be done by the master before theslave is fully operational (transmission and reception of PDOs).

For further simplification of the behavior, it is possible to achieve an automatic activationby means of parameterization.



4.2.1. Automatic Startup

By default, a CAN slave behaves passively after the start and waits for the activationmessage from his master.

DIR COB-ID B0 B1M → S 0x00 0x01 0x00

Table 4.1.: Set all nodes to Active

Table 3.15 shows which functions are possible depending on the state of communication.

To achieve a further simplified handling, HAWE’s CAN PSL/PSV valve controllers canbe configured to activate the communication automatically. Object 1F80.0 serves thispurpose as well as parameter 127 (PAR_NMTSTARTUP) does. If the default value 0 ischanged to 3, automatic startup will be enabled.

After connecting the voltage supply, the CAN slave will be forced to enter into activecommunication state and is ready to process PDOs or sends a status PDO.

The restriction, that has to be considered with automatic activation too, is the requiredsending of the zero setpoint as the first setpoint to the valve in order to put it intooperation.

See also subsection 4.3.4.

4.3. Setpoints

Setpoint values are cyclically transmitted from the master to the slave by PDO1(seeTable 3.2)

4.3.1. Setpoint Message (PDO Master to Slave)

Setpoints can be communicated via process data objects (see section 3.4 PDOs ).

The HAWE PSXCAN DS401 firmware uses 8 bit setpoints with the following format:

DIR COB-ID B0 B1 B2 B3 B4 B5 B6 B7M → S 0x200 + Node-ID SP0 SP1 SP2 SP3 SP4 SP5 SP6 SP7

Table 4.2.: Format setpoint telegram CiA-401



4.3.2. Setpoint Format

For the setpoint of a valve section, one byte is provided i.e a resolution of the workspaceof the valve (B-side - A-side) in 254 steps is possible.

Normally, only SP0 is used to tranfer setpoints to the valve, observing the setpoint bytesSP0 . . . SP7 listed in Table 4.2.

The setpoints are coded as signed integers (two’s complement). See also Table 4.3,where the assignment of setpoint command and oil flow is shown.

Setpoint (HEX) Setpoint (DEZ) Meaning0 0 Neutral7F 127 100% A-side81 -127 100% B-side80 128 undefined

Table 4.3.: Mapping of Setpoints to Oil Flow

The consumption of only one byte of the setpoint telegram to control a valve opensthe possibility to use B1 - B7, using a setpoint telegram, to operate up to eight valvessimultaneously.

Default setting is to use a separate message for each valve setpoint and the value of B0(see Table 4.2) as a setpoint command.

4.3.3. Several Setpoints per telegram

In some CAN networks for example by remote control receivers setpoints for severalreceivers are bundeled into one telegram.

User who want use this functionallity to evaluate a single setpoint telegram for severalvalves should, however, consider the following, please:

- Each valve section corresponds to a stand-alone CAN participant with its own andunique node-ID. A valve bank consists of as many participants as there are CANsections.

- Feedback on the status of the individual valves can therefore only be made throughdifferent PDOs. The addresses are calculated from their node-ID. See Table 3.2.

- The COB-ID to be used for the setpoint cannot be derived clearly from the node-ID of the CAN slave, but must be specified separately. Therefore parameter123 (PAR_MULTI_SP_COBID, range: 0-2047) of each valve, receiving from thattelegram has to be initialized with that COB-ID.In CANopen object 0x2810 can be used for this purpose.



- Each valve section must be told which one of the eight user data bytes shall be usedas setpoint. This is achieved by setting parameter 124 (PAR_MULTI_SP_BYTE) toa value between 0 and 7.In CANopen object 0x2811 can be used for this purpose.

4.3.4. Zero Setpoint for activation

When restarting or due to prior deactivation, the first setpoint sent to the valve has to bethe zero setpoint in order to put it into operation.

DIR COB-ID B0M → S 0x200 + NodeID 0x00

Table 4.4.: Zero setpoint

Otherwise the acceptance of the non-zero setpoint will be refused and an internal errorwill be generated.

This mechanism serves as a hedge against sudden displacement of the valve e.g. ifcommunication to the CAN master is interrupted.

4.4. Diagnostic Data (PDO Slave to Master)

In the device profile CiA-401, the feedback of diagnostic data is provided by the slaves.It should be noted that each valve section acts as a self-sufficient participants and sendsits own telegram. See also subsection 4.3.3.

4.4.1. Frame Format

In operation, the valve periodically reports its diagnostic messages by PDO. See alsosection 3.4.

It should be noted that in contrast to setpoint messages the diagnostic messages obtainjust one telegram for each valve section.

DIR COB-ID B0 B1 B2 B3 B4 B5S →M 0x180 + Node-ID DI0 DI1 DI2 DI3 DI4 DI5

Table 4.5.: Format Diagnosis Telegram CiA-401

The corresponding COB-ID is then calculated from the offset value for PDO1 (0x180)and the node-ID of the valve section.



4.4.2. Data Content Response Message

In case of operation each valve section cyclically reports the actual flow value calculatedfrom the slider position. It should be noted that an ideal pressure supply of the valve isassumed.

The PDO also contains the error codes, error classes and a temperature reading.

The meaning of diagnostic information is shown in Table 4.5 in detail:

Byte Meaning ReferenceDI0 Error class see Table 3.14DI1 Error code reservedDI2 Temperature electronics +50CDI3 ReservedDI4 Oil flowDI5 Oil flow inverted

Table 4.6.: Diagnostic Information in the PDO

4.5. Safety Policy

As protection against communication disruptions Node Guarding and Heartbeat areprovided as standard CANopen CiA-301 mechanisms, to ensure uninterrupted commu-nication from slaves to master control. See also section 3.3.



The standard CiA-301 is for CANopen essential and has been expanded with furtheradditional device specific requirements in order to offer a meaningful standardizationof components. In this chapter the device profile CiA-408 which was designated tohydraulic components with CAN interface will be explained.

5.1. CiA-408 Specifics

This section explains the principal concepts derived from the CiA-408 standard “Deviceprofile fluid power technology proportional valves and hydrostatic transmissions” [1]. Therequirements are specific and focused on hydraulic components, typical parameters ofthese components and their behavior.

The standard in particular provides very detailed guidelines regarding the valve’s softwarebehavior for activation and error management. To this extent the specification goes farbeyond the CANopen typical object dictionary (directory) and its entries.

5.1.1. Operating Modes

CiA-408 defines a series of possible operating modes. For hydraulic valves it pro-poses the following control and regulation modes in object 6043h (parameter 57,“PAR_DEV_CTRL_MODE”), as shown in Table 5.1

Control mode Meaning0 Control mode not defined (substitute value for valves)1 Spool position control open loop2 Spool position control closed loop3 Pressure control valve open loop4 Pressure control valve closed loop5 p/Q-control valve6 Open loop movement (substitute value for hydrostatic axis)7 Velocity control axis8 Force/pressure control axis9 Position control axis10 Positional dependent deceleration11..127 Reserved

Table 5.1.: Meaning of the Operating Modes



For PSL/PSV CAN valve nodes currently control mode 2 is supported. This means thatthe setpoint is proportional to the required oil flow quantity. The position of the valvespool is measured internally and adjusted to the position corresponding with the requiredflow.

5.1.2. State Machines

Following the specifications defined in [4] and [1], the control software of a CAN slavemodule must make a distinction between two partially independent acting state machines.

Within CiA-301 the so-called communication state machine (CSM) was already estab-lished. It controls the communication of the bus participants. See subsection 3.7.1. Thecommunication state machine (CSM) ensures the controlled startup of the communica-tion interface and can be deactivated if required. Figure 3.3 shows the correspondingstate diagram.

The CiA-408 goes beyond the communication behavior defined in CiA-301 and setsguidelines concerning the actual functionality of the bus participant. Therefore a so-calleddevice state machine (DSM) is defined.

For control (e.g. of a proportional valve), the necessary state transitions have to berequired by external activation commandsand This has to take place before operationalreadiness is achieved. See subsection 5.1.3.

In order to start operating, the following sequence of commands is required according toCiA-408:

- Command to start communication (activation of CSM)

- Transition command in active status

- Transmission of a setpoint command with setpoint 0

After this starting sequence the valve is ready for operation and various setpoints otherthan zero can be transmitted.

For a detailed presentation of the internal state machine and its control commands seealso subsection 5.1.3.



5.1.3. Device State Machine (DSM)

The device state machine controls the actual functionality of the slave. Its internal statesdecide the operating status and operational readiness of the valve.

Figure 5.1 shows the status diagram of the device state machine (DSM), while Table 5.2outlines the meaning of the individual states. The shown RMDH in the figure correspondto the Device Status Word, shown in Table 5.3.

Not_Ready

do / RMHD=0000[D0]

Init

do / RMHD=1000

[D1]

Disabled

do / RMHD=1001

[D7] [D2]

Hold

do / RMHD=1011

[D6] [D3]

Device_Mode_Active

do / RMDH=1111

[D5] [D4]

Fault

do / RMHD=0001[D10]

[D13]

Pre_Hold Fault_Hold

do / RMHD=0011[D11]

Fault_Reaction

do / RMHD=0111[D8]

[D9]

[D12]

R=ReadyM=Device Mode ActiveH=HoldD=Disabled

do / sends RMHD asDevice Status Word (DSW)

Figure 5.1.: Device State Machine



Condition ExplanationNot ready -Electronics is supplied

-Device initializes hardware and software-Self test-Device functionality is deactivated

Init -Parameters can be set-Device functionality is deactivated-Waits for state transition to “Active”

Disabled -Parameters can be set-State transitions can be obtained through DCW-Device functionality is deactivated

Hold -Parameters can be set-State transitions can be obtained from DCW-Hold setpoint is activated (HAWE: hold setpoint = 0)-External setpoints are ignored

Device mode -Parameters can be setActive -State transitions can be obtained through DCW

-The configured device mode is active-Change device modes (index 0x6043) is not allowed

Fault reaction -Is activated automatically in case of errors-Parameters can be set-Run a configurable error response (eg: ramp down)-Devices remain functional during a ramp down

Fault hold -Parameters can be set-The actual or preset-hold value becomes setpoint-External setpoints are ignored

Fault -Parameters can be set-Device functionality is deactivated

Pre hold -Intermediate state, no functional significance

Table 5.2.: States of the Device State Machine



5.1.4. Device Control Word (DCW)

External control of the DSM is carried out by the master via the so-called device controlword (DCW). It is used to request the status transitions shown in Figure 5.1. The DCWis transmitted simultaneously with the setpoint as integral part of the PDOs that arecyclically sent to the slave. See also Table 5.3 as well as subsection 5.2.3.

Only the last 4 bits are used for requesting the state transitions.

Transition Explanation Control Word3 2 1 0R M H D

D0 Switch on voltage supply for device InternalD1 Hardware initialization successfully completed InternalD2 Bit “Disable” high, self test successful x x x 1D3 Bit “Hold” high x x 1 1D4 Bit “Device Mode Active” high x 1 1 1D5 Bit “Device Mode Active” low x 0 x xD6 Bit “Hold” low x 0 0 xD7 Bit “Disable” low x 0 0 0D8 Error InternalD9 Error reaction terminated InternalD10 Error reset (to positive edge of R) 1 x 0 xD11 Error reset (to positive edge of R) 1 x 1 xD12 Error reaction terminated Internal

Table 5.3.: Device Control Word and Transitions of the Device State Machine

5.1.5. Device Status Word (DSW)

Every valve provides information on its actual status in form of a so-called device statusword (DSW), which is the counterpart to the device control word (DCW). It is cyclicallysent to the master via PDO. See also Table 5.4 and subsection 5.2.4.



Last four bits LSB Bedeutung0x0 Not Ready0x1 Fault0x2 -0x3 Fault Hold0x4 -0x5 -0x6 -0x7 Fault Reaction0x8 Init0x9 Disabled0xA Pre-Hold0xB Hold0xC -0xD -0xE -0xF Device Mode Active

Table 5.4.: LSB Device Status Word

5.1.6. State Transitions

State changes, which are not actively triggered by the device control word, are calledinternal transitions. Internal transitions can occur, for example if the supply voltage isswitched on or if the slave detects an error.

The transitions shown in the state chart in Figure 5.1 are explained in Table 5.3, wherebythe last 4 columns show the device control word from Table 5.12.

In case the communication state machine switches into the mode Stopped or Initializationduring operations, a transition to Fault Reaction is automatically executed in the devicestate machine. This can happen, for example, on account of a bus interruption.

5.2. Communication Procedure

The following provides an exemplary description of the setup and sequence of a commu-nication between master control and a valve segment according to CiA-408.

5.2.1. Startup Communication Functions

Immediately after the supply voltage has been activated all CAN nodes in the networkwill output an one-time boot up sequence in form of a status message and will behavepassively thereafter. See table below:



DIR COB-ID B0S →M 0x700 + Node-ID 0x00

Table 5.5.: Boot up Sequence

The timeout error detection is activated after the first setpoint telegram.

Even if no setpoint telegrams are sent to the valve yet, the corresponding error detectionis still deactivated via timeout.

A start telegram is required for further activation that releases the active communicationstate of the bus nodes. The command described in Table 5.6 can also be used to startall CAN nodes connected to the network.

DIR COB-ID B0 B1M → S 0x00 0x01 0x00

Table 5.6.: Activation Sequence for all Slaves

After receipt of this telegram all connected valve nodes will switch into active communi-cation state and, if they are configured in such a way, will cyclically transmit Heartbeat,Node Guarding signals or status messages.

Attention must be paid that a waiting period of approx. 700 ms is kept after the supplyvoltage has been switched on, before all CAN participants can be expected to be ablefor communication.

5.2.2. Activation

The control sequence described in subsection 5.2.1 releases the communication of thevalve node but not its function. This requires transition into the “active” operating state.State transitions are triggered with the so-called “device control word”, which is cyclicallytransmitted as element of the setpoint telegram. See also subsection 5.1.4.

For safety reasons, attention must be given to the very first setpoint having the value 0in the active state. Any setpoint value other than zero will trigger an error. This appliesalso for interim deactivations.

This procedure protects against unwanted fast movement after a loss of communication.This could happen when the radio transmission of a wireless joystick that is controllingvalves is blocked by walls or environmental influences.

The activation telegram (including zero setpoint) takes the following form:

DIR COB-ID B0 B1 B2 B3M → S 0x200 + Node-ID 0x0F 0x00 0x00 0x00

Table 5.7.: Activation Telegram



The 0x0F in byte 0 requests the immediate state transition into the active state. In caseof success the request is acknowledged by the valve via PDO:

DIR COB-ID B0 B1 B2 B3 B4 B5S →M 0x180 + Node-ID 0x0F 0x00 0x00 0x00 0x00 0x00

Table 5.8.: Activation Telegram

Byte 0 also contains the information regarding the activation state of the valve. Thefollowing two sections provide a more detailed explanation of this example.

5.2.3. PDO Master to Slave (RXPDO)

The process data objects (PDOs) that were presented as examples in subsection 5.2.2are used for transferring setpoints. Activation command (as well as the specific deactiva-tion) and valve setpoint are grouped together within one telegram.

In keeping with CAN standard addressing format (see subsection 3.2.6) and the setpointformat defined in CiA-408 [1] the PDOs for the setpoint transfer take the following format:

DIR COB-ID B0 B1 B2 B3M → S 0x200 + Node-ID DCW SP

Table 5.9.: RPDO (Setpoint Format)

Key element of the setpoint telegram is the so-called “device control word” (DCW) thatcontains the commands required for activation or deactivation. Of the 16 reserved bitsonly the four lowest value bits from byte 0 are being used (see Table 5.12). Byte 1 is notused.

The setpoint is transferred with 16 bit in bytes 2 and 3. There are 2 variants for scaling,which are shown in Table 5.10. Positive setpoints will result in a volume flow from port Pto port A, negative setpoints creates a volume flow to B. Examples for setpoint messagesare shown in Table 5.11.

The setting of the setpoint format takes place via object 2800h or parameter 128, namelyPAR_PROT_SUB. The default value is 1. The unchangeable PDO-mapping is listed inobject 0x1600 (receive) and 0x1A00 (transmit).

Setpoint Index 2800.0 Min MaxCiA-408 408 0xC000 (-16384) 0x4000(16384)HAWE Plug&Play 1 0xFC18 (-1000) 0x03E8(1000)

Table 5.10.: Setpoint Scale



Meaning B0 B1 B2 B3 setpointCiA-408first setpoint message 0% 0x07 0x00 0x00 0x00 0active A 18,3% 0x07 0x00 0xB8 0x0B 3000active B 18,3% 0x07 0x00 0x48 0xF4 -3000reset error A 50% 0x0F 0x00 0x00 0x20 8192active B 50% 0x07 0x00 0x00 0xE0 -8192active A 100% 0x07 0x00 0x00 0x40 16384active B 100% 0x07 0x00 0x00 0xC0 -16384HAWE Plug&Playactive A 20% 0x07 0x00 0xC8 0x00 200active B 20% 0x07 0x00 0x38 0xFF -200active second rampset A 50% 0x07 0x40 0xF4 0x01 500active B 50% 0x07 0x00 0x0C 0xFE -500active A 100% 0x07 0x00 0xE8 0x03 1000active B 100% 0x07 0x00 0x18 0xFC -1000active float 30% 0x07 0x80 0x2C 0x01 300

Table 5.11.: Examples for setpoint messages

Bit DCW DSW0 Disable Disabled1 Hold Enable Hold Enabled2 Device Mode Active Device Mode Active3 Reset Fault Ready14 Second Ramp Set15 floating position

Table 5.12.: Device Control and Status Word (DCW and DSW), Byte 0

The device control word tells the valve into which activation state it shall transfer.

The simultaneous transfer of multiple activation bits is also possible as the examplein subsection 5.2.2 shows. The valve will then pass through all activation levels, andif required will finally reach the active state. For a more detailed insight reference ismade of subsection 5.1.2 that outlines the concept of internal state machines and statetransitions in detail.

5.2.4. PDO Slave to Master (TXPDO)

The corresponding counterpart to the “device control word” is the cyclically transmitted“device status word” (DSW). It is contained in the first two bytes of the status telegramand transmits information on the activation state of the valve (see Table 5.12).



DIR COB-ID B0 B1 B2 B3 B4 B5S →M 0x180 + Node-ID DSW Q E

Table 5.13.: TXPDO (Actual Value Format)

In addition, the PDO that the valve cyclically sends, contains data on the current flow Q.Values from -1000 to 1000 are contained in bytes 2 and 3. They denote the estimated oilflow quantity in parts-per-thousand as reference to the maximum flow (nominal quantity)of the associated valve section.

For the PLVC Plug&Play version the PDO in bytes 4 and 5 is extended with the errorinformation. subsection 5.2.5 contains further details on error information. Bytes 4 and 5are not occupied in the version CiA-408.

5.2.5. Error Management and Error Codes

An internal error management system administers the errors detected by the valve. Thisincludes both errors from an external source (voltage limit values, insufficient spooldeflection due to faulty pressure supply, inappropriate setpoint transfers) as well asinternal error states.

Depending on the severity of an error, an internal status transition is triggered and thevalve (more precisely its device state machine) is transferred into another operating state.The information which errors trigger what reaction is stored internally in configurable bitmasks in the control software.

The transition D5 and D6 will be automatically executed, if an event in a PSX-CAN arises,being configuered to “disabled” in the error transition mask. To change from device mode“disabled” to device mode “acive”, no positiv edge to bit 3 of the DCW is necessary

If errors occur, the detailed error information is categorized and transferred to the CANbus. Table 5.14 provides an overview of the error categories contained on bytes 4 and5 of the PDO1 (S →M ). Some error bits represent the combination of different errorsbelonging semantically together. An overview of possible errors is shown in Appendix A.



Bit Meaning0 Internal error (self test)1 Bus command error (timeout)2 Coil resistance, current controller3 Overheating, automatic limitation4 Slide deflected too far5 Slide deflected too short6 first setpoint not equal to 07 Power supply too high/low8 Electronics temperature too low9 Electronics temperature too high10 -11 -12 -13 -14 Slide position detection implausible15 Status, unit is available

Table 5.14.: Error Codes

5.2.6. Position Control Errors

To assist users in handling non normal operation modes related to position control thePSXCAN valve allows the configuration of 3 warning / errors :

* POS_PLUS

- Spool moved further than requested

- Spool sends more oil to the consumer than requested

- Usually an error message

* POS_MINUS

- Spool moved not far enough

- Spool sends less oil to the consumer than requested

- Usually a warning

* POS_ITG

- Spool cannot follow the constant change of setpoint

- Per default deactivated

- Usually a warning



Since the amount of oil sent to the consumer cannot be measured, the valve has to relyon the measured spool position to estimate the oil flow. To detect problems in the positivespool overlap, the position control errors are based on the raw position. Table 5.15shows typical position values for nominal flow.

PSX Size Nominal Increments2 10003 15005 and 7 2000

Table 5.15.: Nominal Increments per design size

In Table 5.16 parameters controlling the generation of position control errors can befound. The parameter are prefixed with PAR_RGL_CONT_LIM (Parameter RegulatorContour Limit).

parameters DIST TPOS ITG TNEG FAK_20parameterindex

58 59 60 61 62

meaning allowedpositiondeviation forPOS_PLUSandPOS_MINUS

allowedtimedeviation

allowedintegraldeviation

allowed timedeviation forPOS_MINUS

TemperatureCompensa-tionMultiplier

unit PositionIncrements

Milli-seconds

IntegratorIncre-ments

Milliseconds Factor/ 20degreescelsius

CANopen-object

2085.1 2085.2 2085.3 2085.4 2085.5

range 0-1000 0-10000 0-20000 0-10000 1-100Standard 265 500 0 500 5

Table 5.16.: Parameter Description Position Control Errors

POS_PLUS Error

A POS_PLUS error is triggered when the spool’s actual position remains more than adistance “x” threshold above the desired target position over a certain period of time “t”.

- Distance “x” is PAR_RGL_CONT_LIM_DIST

- Period of time “t” is PAR_RGL_CONT_LIM_TPOS

This error is more serious than a POS_MINUS error because more oil is sent to theconsumer, which moves faster as result.



POS_MINUS Error

A POS_MINUS error is triggered when the spool’s actual position remains more than adistance “x” threshold below the desired target position over a certain period of time “t”.

- Distance “x” is PAR_RGL_CONT_LIM_DIST

- Period of time “t” is PAR_RGL_CONT_LIM_TNEG

This error/warning is less serious than POS_PLUS because the actor is moving slowerthan expected.

Temperature Compensation Factor

Low ambient temperature can result in more viscous oil. To compensate this effect andto avoid false error messages, the parameter PAR_RGL_CONT_LIM_FAK20 allows thecompensation of the effect by multiplying the allowed time deviation of the POS_PLUSand POS_MINUS errors by a factor per 20 degrees celsius.

Integral Deviation

Parameter RGL_CONT_LIM_ITG is a limit for generating the POS_ITG error. This erroris triggered when the PID controller hits the given limit for the integral part. This error isdeactivated for the default configuration.

5.3. Valve Nodes as Plug&Play Slave for PLVC ControlModules

As an advanced basis of the HAWE PLVC control device a Plug&Play configuration canbe used for CAN node. The external valves are managed -without communication isnecessary in the user program- by the operating system of the PLVC and can be usedanalog to already available output valves.

Plug&Play functionality expects merely the following requirement for the address assign-ment: The external and via CAN bus selected valves must be placed on CAN node-IDsfrom 32, all other data traffic and the belonging observation and security functions aremade by the PLVC.

The function block ACT_VALVE is used for control. Its documentation can be found inthe PLVC manual.

Example



1 prop (CHANNEL := PLVC ID )

with

1 Channel = PLVC ID

Single valves are addressed with consecutive indexes starting from 2000.

The indices of the double valves are calculated from 2000 + 2 · n, where n is the numberof the section. The combination of the IDs is shown in Table 5.17.

Section number. PLVC ID Node-ID COB-ID of setpoint Actual COB-ID1 2000 32 0x220 0x1A02 2002 34 0x222 0x1A23 2004 36 0x224 0x1A44 2006 38 0x226 0x1A65 2008 40 0x228 0x1A86 2010 42 0x22A 0x1AA7 2012 44 0x22C 0x1AC8 2014 46 0x22E 0x1AE9 2016 48 0x230 0x1B0

10 2018 50 0x232 0x1B2

Table 5.17.: Node-IDs in the Process

Each connected CAN node receives the required setpoint message with control word onreceive PDO1. The CANopen standard addressing is essential.

The CAN bus master of the PLVC has to be actived. This is achieved by setting theparameter 0 or -1 in the communication menu (Parameters→ Submenu 4: Communi-cation) to 1 as shown in Figure 5.2.



Figure 5.2.: Activation of the PLVC41 CAN Masters

The CAN baud rate must be set identical for all participants (Parameters→ Submenu7: Special Parameters).

In menu Prop. Valves shown in Figure 5.3 (Prop. Valves → Submenu 6: CAN-Valves), the function of the CAN nodes can be monitored. Here the setpoints, actualvalues and error messages are shown.



Figure 5.3.: Overview of the CAN Nodes

After committed setpoint message, the PLVC monitores the actual values of the CANnode on timeout (about 200ms). When the CAN node has received a setpoint message,it monitors this setpoint message on timeout (configurable).

5.4. Flow sharing

With flow sharing, sometimes called “Anti-Saturation”, one can evenly distribute theavailable pump volume for all/some PSXCAN valves. This feature is available withfirmware revision 2795 and greater.

Such situations will occur, when a machine is configured thus that the amount of oilneeded to drive several valves with 100%, setpoint exceeds the maximum pump flow.In these events the valves are “undersupplied”. These situations have to be avoided,because the valves distribute the volumeflow according to the load pressure of eachfunction. The highest load pressure is serviced least.Situations where undersupply occurs, can be avoided with this software module. Toachieve this, all valves are reducing their setpoints with a common factor, so that thesum of all volumeflow consumers, does not exceed the pump volume.

Prerequisites for this are:

• the CAN-11 bit ID 0x790 can be used by the PSXCAN valves

• all valves are configured similar to participate in the flow sharing

• the setpoint cycle-time is reasonable low (10..50ms) to achieve good results



For priorisation of functions, two groups are available. Group 0 is served first, if thenvolume flow is still available, it is distributet between the participants in group 1.

• parameter 21 (PAR_FLOWSHARE_CONFIG, CANopen-object 2017.1) configuredto 1 enables the flow sharing

• possible values for parameter 22 (PAR_FLOWSHARE_GROUP, CANopen-object2017.2) are currently 0 and 1

• parameter 23 (PAR_FLOWSHARE_PUMP_VOL, CANopen-object 2017.3) shouldbe configured a bit lower than the real pump flow in [ 1

10 lpm]

• the flow sharing algorithm uses the nominal flows, stored in Parameter 195(PARA_Q_NENN) and Parameter 197 (PAR_B_Q_NENN) that are also availablevia CANOpen SDO 2100.1 and 2101.1

• the flow sharing algorithm respects the configured overrrides in parameter 13 and33 (PAR_A_OVERRIDE und PAR_B_OVERRIDE) that are available via CANOpenSDO 2092.1 and 2093.1

This kind of flow sharing is not able to detect if a zylinder is in endposition and does notrequire oil.



Example

- Pumpflow: 30 lpm- required flow: 10 + 10 + 10 + 20 + 5 + 5 = 60 lpm- reduction factor: 50%

Valves

volumeflow in[lpm]

10

5

10

5

10

5

20

105

2.5

5

2.5

Figure 5.4.: 50% setpoint reduction by flow sharing

5.5. CANopen Object Dictionary

Section A.5 lists those portions of the object entries, which are read and/or changed withCAN PSL/PSV valves via the CANopen communication protocol.

The following legend applies to all objects:

• rw = readable and writeable

• ro = value only readable

• wo = value only writeable

• s = signed Integer

• u = unsigned Integer

• 0x**= hexadecimal value



Specific parameterization software (“HAWE CAN Node Tool”) provides further optionsfor diagnosis and parameterization.

WARNING

System integrators are responsible for the correct integration of all hardware andsoftware components.

5.6. Configuration of CANopen Master Devices

In this chapter CODESYS V3.5 Service Pack 9 is configured to work with PSXCANvalves in a CANopen network.

The safety mechanism Heartbeat is described in subsection 3.3.2.

If heartbeat is used with PSXCAN valves the safety mechanism “Setpoint-Timeout”should be disabled by setting object 2200 or parameter 119 to zero.

To achieve a basic communication the following configuration steps have to be done.

• insert the EDS file of the CANopen device into the IDE of the CANopen masterdevice

• configure CANopen Master and add CANopen device

• configure heartbeat on master und slave device

• configure PDO an master und slave device

5.6.1. EDS File

To communicate with CAN enabled HAWE components with a CODESYS enableddevice, the EDS file of the component has to be made available to CODESYS. The EDSfile can be found on the Website http://www.hawe.com/edocs (Downloads for electronicscomponents).

In CODESYS navigate to the menu Tools->Device-Repository. Use the button “Install” toselect the downloaded eds file with the file explorer.


http://www.hawe.com/edocs


5.6.2. Add CANopen-Manager

To add a CANopen-Manager right click on the CAN-bus and select “Add device”, likeshown in Figure 5.5.

Figure 5.5.: Add device

Select “3S - Smart Software Solutions GmbH” from the list of device manufacturer. Select“CANopen_Manager”. Confirm the selection with “Add device” like shown in Figure 5.6.



Figure 5.6.: append CANopen Manager as device

In the next step CANopen devices can be attached to the CANopen manager.

5.6.3. Add CANopen-Device

Every CANopen device has to be configured in the corresponding CANopen manager inCODESYS. To do this right click on the CANopen manager and select “Add device”.

Select the manufacturer “HAWE Hydraulik SE” in the next dialog.Select “CANNode” (if more than one version is available, select the newest). Confirmyour selection with the button “Add device”.

5.6.4. Master heartbeat configuration

Select the configuration dialog of the CANopen manager with a double click like shownin Figure 5.7.



Figure 5.7.: CANopen Manager selection

the default Heartbeat Producer-Time of 200ms can be adapted to the need of theapplication, like shown in Figure 5.8.

Figure 5.8.: configuration of the hearbeat producer time

5.6.5. Slave heartbeat configuration

Open the configuration dialog by double clicking the CANopen slave, as shown inFigure 5.9.



Figure 5.9.: selection of CANopen device

Select the expert configuration in the general section, to see all options as shown inFigure 5.10.

The Heartbeat-Consuming-Time can be checked or changed clicking on “Heartbeat-Consuming (1/1 active)”.

The value should be significantly lager as the producer-time, otherwise the commu-nication state machine of the slave would change to pre-operational because of thesmallest timing problems (see Figure 3.3). In Figure 5.10 the heartbeat-consuming-timeis configured to 300ms.

Figure 5.10.: configuration of heartbeat consumer time



Check the configured value in the SDOs tab, like in Figure 5.11. The values for producerand consumer time should match the values you configured.In Figure 5.11 the hexadecimal diggits correspond to the configured values 300 (=0x12C)and 200 (=0xC8).

Figure 5.11.: SDO configuration telegramm

5.6.6. Configuration of transmit PDO at the Master

Set the Sync-Producing to active and the Cycle Period to 20000µs (=20ms), as shown inFigure 5.12.

Figure 5.12.: Sync CANopen Master configuration

5.6.7. Configuration of the Receive PDO at the Slave

The transmit PDO of the master controller is the receive PDO of the PSXCAN valve. Thesettings of the PDOs are configutred at the PSXCAN valve.



Open the configuration of the “Receive PDO Communication Parameter” by doubleclicking. Select “cyclical - synchron (type 1-240)” as transmission type.

The value shows the number of Sync objects of the CANopen manager (at the master)that have to be received until the master sends a PDO.

Figure 5.13.: Sync CANopen master configuration

The configuration in subsection 5.6.6 and in Figure 5.13 ensures that the transmit PDOis sent every 20ms to the field device.

5.6.8. SDOs Configuration

The configuration tab SDO of the field device describes the configuration telegramswhich the CANopen manager in the master controller sends the field device.

Make sure to disable the option “generate all SDOs” in the SDO settings. Otherwise alldefault parameter from the EDS-file are written into the slave during booting or after areset of the slaves. Figure 5.14 shows a valid configuration.



Figure 5.14.: SDO configuration of device


6. J1939

This chapter gives a minimum introduction in protocol implementation using 29-bitidentifiers to drive HAWE PSL/PSV CAN valves.

6.1. Basic information

Features of the J1939-Standard are implemented by HAWE PSL/PSV CAN valves.

Setpoint and Status messages are initially defined in ISO 11783-7 (dated 10.08.2000).Protocol specific configuration values are given in table 6.1

Beschreibung Defaultwert Parameter CANopen IndexManufacturer Code 461 - -Source Address 128 131 2220.1Industry Group 0 132 2220.2Vehicle System Instance 3 133 2220.3Vehicle System 1 134 2220.4Function Instance 2 135 2220.5Function 129 136 2220.6

Table 6.1.: J1939 Configuration Values

6.2. Adressing

Typically, a valve bank consists of more than one valve section, every section has aunique number to distinguish the different valves. In accordance with the CANopenprotocol family every valve contains the internal identification parameter Source Addressin the range from 0-247 with a default value of 128.

This parameter can be configured with parameter 131 or CANopen index 2220.1.

Every valve section has to be considered as independent bus device, communicationhas to be established separately and every valve section requires an individual setpointtelegram.

Parameter 111 (PAR_CAN_ID with CANopen index 2000) controls the selection of theAuxiliary Valve given in table 6.2.

Using a value higher than 15 is not recommend for J1939 usage.


6. J1939

Auxiliary Valve Status PGN Command PGN0 65040 650721 65041 650732 65042 650743 65043 650754 65044 650765 65045 650776 65046 650787 65047 650798 65048 650809 65049 65081

10 65050 6508211 65051 6508312 65052 6508413 65053 6508514 65054 6508615 65055 65087

Table 6.2.: J1939 Parameter Group Numbers

6.3. Boot Up Message

After power up, every valve section sends once a boot-up message with Identifier0x18EEFF00 + Source Address that is detailed in table 6.3.

This message is described in SAE J1939-81 (May 2003) in chapter 4.1.1 in table 2.

Byte Bit Description0 7-0 Least significant byte of Identity Number1 7-0 Second byte of Identity Number2 7-5 Least significant 3 bits of Manufacturer Code2 4-0 Most significant 5 bits of Identity Number3 7-0 Most significant 8 bits of Manufacturer Code4 7-3 Function Instance4 2-0 ECU Instance5 7-0 Function6 7-1 Vehicle System6 0 Reserved7 7 Arbitrary Address Capable7 6-4 Industry Group7 3-0 Vehicle System Instance

Table 6.3.: Boot Up Message, Sent Once After Power Up


6. J1939

6.4. Setpoint Command

Each valve section expects regularly incoming setpoint information. Parameters in table6.4 configure how setpoint commands are received in J1939 mode.

Parameter Name DefaultValue

MinValue

Value(Example)

MaxValue

111 PAR_CAN_ID (Aux. Valve) 127 0 2 127113 PAR_CAN_MASTER_ID 0 0 17 255128 PAR_PROT_SUB 1 0 1939 32787

Table 6.4.: J1939 Setpoint Configuration Parameters

Example for Message: 0x0CFE3211

0x0C = 3 = Priority0xFE32 = 65074 = Auxiliary Valve Number 2 Command PGN0x11 = 17 = Source Address of the master ECU

Table 6.5 describes the message content.

Note that parameter 111 (PAR_CAN_ID with CANopen index 2000) controls the selectionof the Auxiliary Valve given in table 6.2.

Identifier DLC B0 B1 B20x0CFE3000+0x100*CAN-ID+Master SA 3 or 8 Flow Res. Direction

Table 6.5.: Setpoint Message, to be Sent Cyclically

The setpoint is given in byte B0 as decimal number in the range of 0 − 250 equaling0− 100%. This means setpoint scaling is 0.4 %.

In byte B2 the directional information is coded. If B2 = 0 the movement is blocked.B2 = 1 initiates movement in A-direction, B2 = 2 in B-direction.

In case communication breaks down the valve deactivates itself. To restart after acommunication breakdown or immediately after power up, the valve expects at least forone cycle to get transmitted a zero setpoint.

The Master Source Adress restricts the Source Adresses that are allowed to sendcommands to the adressed valve section. By default, parameter 113 with the namePAR_CAN_MASTER_ID is zero, meaning there are no restrictions.

We suggest to send this message every 10..50ms. The HAWE default is 20ms.


6. J1939

6.5. Status Information

After boot-up every valve sends cyclically information about its status. Especially, thevalves’ spool position results in an estimation for the actual flow (assuming sufficientsupply from the hydraulic pump).

Parameters in table 6.6 configure how status messages are sent in J1939 mode.

The message format for the status information is given in table 6.7. Examples in decimalformat are given in table 6.8.


MinValue

Value(Example)

MaxValue

111 PAR_CAN_ID (Aux. Valve) 127 0 2 127131 PAR_J1939_SA 128 0 130 247128 PAR_PROT_SUB 1 0 1939 32787118 PAR_CAN_STATUS_TIME 20 0 20 32000

Table 6.6.: J1939 Status Configuration Parameter

Example for Message: 0x0CFE1282

0x0C = 3 = Priority0xFE12 = 65042 = Auxiliary Valve Number 2 Estimated Flow PGN0x82 = 130 = Source Address of the valve

Identifier DLC B0 B1 B2 B3 B40x0CFE1080 + 0x100 *Node-ID + Valve SA

8 Flow A Flow B Dir. Err. LSB Err. MSB

Table 6.7.: Status Message, Sent Cyclically

The Source Address (PAR_J1939_SA) of the valve should be in the range of 128..247 toavoid conflicts with Global Source Addresses that are defined by J1939.

The Source Address is configured through one of the following means:

• during commissioning by the system integrator

• before ordering by filling out the document [8]

• if not configured before ordering, the default configuration is 192 + section number(PAR_VALVE_SECT_NR)

The flow is given in byte 0 when the valve operates at port A, in byte 1 when port B isdriven. In both cases a value of 125 defines a flow of zero. Additional information aboutthe direction of the flow is given in byte 2.


6. J1939

Maximum flow (100%) for port A is B0 = 225 which corresponds with the nominal flowvalue of the A-port. Maximum flow for port B corresponds with B1 = 25! That makes aresolution of 1% per bit for both, port A and port B.

Caution: Different scaling is used for the Setpoint Command (0,4% per bit, see sec-tion 6.4) and the actual value (1% per bit).

The directional information (port A active or port B active) is given in byte 2. B2 = 1denotes operation in A-direction, B2 = 2 in B-direction.

The combination of B0 = B1 = 125 and B2 = 0 stands for zero estimated flow, i.e. thevalve spool is in neutral position.

Identifier B0 dez B0 hex B1 dez B1 hex B2 Meaning0x0CFE1181 125 0x7D 125 0x7D 0 Node 1; no flow0x0CFE1383 225 0xE1 125 0x7D 1 Node 3; A port 100%0x0CFE1484 125 0x7D 25 0x19 2 Node 4; B port 100%0x0CFE1585 145 0x91 125 0x7D 1 Node 5; A port 20%0x0CFE1686 125 0x7D 105 0x69 2 Node 6; B port 20%0x0CFE1585 175 0xAF 125 0x7D 1 Node 5; A port 50%0x0CFE1686 125 0x7D 76 0x4C 2 Node 6; B port 49%

Table 6.8.: Example for Status Messages

The ISO 11783-7 suggests to repeat this message every 100ms. The default valueHAWE uses is 20ms.

6.6. Error Information

Information of error status is given in bytes B3 and B4 of the status message. Both formtogether a 16-bit error message, where each bit represents an error group. Table 6.9gives an overview of used error groups.


6. J1939

Bit Meaning0 Internal error (Selftest)1 Error Buscommand (Timeout, SP value)2 Coil ressitance, current control3 Overheating, limited functionallity4 Spool position too far out5 Spool position can not reach target6 Setpoint after restart != 07 Supply voltage too high/low8 Temperature too low9 Temperature too high10 Parameter/Valve data invalid11 Sticky spool movement12 -13 -14 Position detectiuon failure15 Status message, System alive

Table 6.9.: Error Group Codes

Special meaning has error bit 15, which stands not for an error, but for the life status ofthe valve.

Error bits are set and reset automatically when the corresponding error condition is metor when it disappears, respectively.

6.7. Migration of HAWE J1939 firmware prior 2767 to currentJ1939/CANopen Combibuild firmware

In J1939 firmware before 2767 auxiliary valve number and source address was definedonly through the CAN-ID. This could lead to situations with an address violation.

An example for parameters with firmware prior to 2767 is given in table 6.10 for a singlesection.


MinValue

Value(Example)

MaxValue

111 CAN_ID (Aux. Valve) 127 0 71 127113 PAR_CAN_MASTER_ID 0 0 17 247128 PAR_PROT_SUB 1 0 1939 32767118 PAR_CAN_STATUS_TIME 20 0 20 32000

Table 6.10.: J1939 Configuration Parameter (prior to 2767)

The values above produce the following COB-ID and their related messages:


6. J1939

• 0x0CFE7711 = Setpoint Command Message 0x0C = Priority 0xFE77 = (65143)d = PGN for Auxiliary Pressures 0x11 = (17)d = Source Address of Cruise Control

• 0x0CFE57C7 = Status Information Message 0x0C = Priority 0xFE57 = (65111)d = PGN for Air Suspension Control 0xC7 =(124)d = Source Address of the valve

An example for Combibuild J1939 / CANopen DS408 r2767 and later that gives thesame messages like in prior r2767 is shown in table 6.11.


MinValue

Value(Example)

MaxValue

111 CAN_ID (Aux. Valve) 127 0 71 127113 PAR_CAN_MASTER_ID 0 0 17 247128 PAR_PROT_SUB 1 0 1939 32767131 PAR_J1939_SA 128 0 199 247

Table 6.11.: J1939 Configuration Parameter (revision 2767 and later)

6.8. Temperature Information

The electronic temperature information can be requested with PGN 65164 and AuxiliaryTemperature 1.

• Parameter Group Number (PGN) (65164)d ((0xFE8C)hex)

• PDU Format 254

• PDU Specific 140

• Default Priority 7

• Suspect Parameter Number (SPN) 441

• Start Position Byte 0 / Data Length 8 bits

• Byte Order Littel Endian

• Scaling 1 C / bit

• Offset -40

• Min Operational Range -40 C

• Max Operational Range 210 C


6. J1939

Only the first Section of each Valve Bank will answer the request given in table 6.12.

Identifier DLC B0 B1 B20x18EAFF01 3 0x8C 0xFE 0x00

Table 6.12.: J1939 Temperature Request

An Example for a Temperature Response is given in table 6.13.

Identifier DLC B0 B1 B2 B3 B4 B5 B6 B70x1CFE8CA6 8 0x47 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Table 6.13.: J1939 Temperature Response

0xA6 = Value of PAR_J1939_SA (Parameter 131).

Actual temperature is: 0x47 = (71)d, Offset = -40, 71-40 = 31 C


7. Protocol Independent Information

Properties of PSL/PSV valve nodes, which don’t depend on the variant of the usedcommunication protocol directly, will be explained within this chapter. Protocols could beperceived as a shell which surrounds a core of central device properties.

7.1. Configuration

HAWE offers the following options to adapt valve batteries to the specific needs ofcustomers:

1. Independent adjustment by the customer; use of a protocol that enables adjust-ments (reparameterization).

2. Pre-configuration prior to delivery, no changes by the customer.

The minimal amount of information required for the ordering process are: the selectionof a protocol and an indication of the used CAN baud rate.

The configuration process is structured using an excel file [8] in which, relative to theassociated HAWE material number, customer predetermined specification data has tobe entered.

The type and number of the in detail required additional information depends on the typeof the desired protocol.

7.1.1. Protocol Variants

The selection of a protocol variant is the essential criterion for determining the desiredcommunication behavior of HAWE CAN PSL/PSV valve operations.

HAWE offers CANopen standard-based protocol variants (CiA-401, CiA-408) as well asa 29-bit-based protocol. The main properties of these are:



CiA-401

- General profile for local IO moduls

- Simple concept for activation, if necessary also automatic attempt without com-mand from the CAN master

- Possibility to activate several slave moduls from one setpoint telegram

CiA-408

- CANopen device profile that is specialized on hydraulic applications; typical param-eters of proportional valves are potentially adjustable by the user

- Preprocessing of setpoints

- Sophisticated concept for activation which ensures functions and automatic deacti-vation according to the error status

29 bit

- Simple profile that uses 29 bit addressing

- Simple concept of activation, attempt without master

- No parameterisation

7.1.2. Parameter Presettings

Depending on the selected sub-variant specifying different default values is mandatoryor optional.

In any case the addressing of the valve sections, i.e: the allocation of clear identificationnumbers, is necessary.

7.2. Diagnosis LED

The PSL/PSV valve nodes are fitted with a two-colored LED to enable error diagnosisindependent of bus connection. Corresponding LED blink codes indicate the currentoperating state or error at the front side of the valve. Please refer to subsection 5.1.2 fordetailed information on operating states.

A green, permanently illuminated, LED indicates a faultless active status. The redLED is off in this state. Non-active states, such as initialization, stand-by or errorstates are indicated with blink codes. A detailed overview of these states is provided insubsection 7.3.4.



7.3. Error Management

An error management system integrated into the firmware of field bus devices hasthe duty to detect error states that could potentially disrupt orderly operations, take upappropriate measures and communicate the error states.

Generally the internal error management system is in charge of the following duties:

- Detecting errors

- Assigning unambiguous error codes

- Triggering the corresponding state transitions (switch off)

- Categorizing individual errors into groups

- Communication to the higher-order control device

The CANopen communication standard as well as J1939 do not define detailed descrip-tion of the internal error handling of CAN slaves. But they define an address rangereserved for the singular transmission of an error message including a specific errorcode.

HAWE PSL/PSV valves with CAN actuation contain an internal error managementsystem which takes over the above mentioned issues for every protocol variant. Howerror conditions are communicated depends on the protocol version.

The following use of the term “error” is neutral in its meaning. As can be seen from thecodings and the transitions listed in Table 5.14 the significance an error can have coversa wide range, from mere warning messages to the immediate emergency switch-off ofthe valve.

The user is therefore situated somewhere between availability and comprehensivediagnosis. The same applies for the ability to reset error states.

This distinguishes between three categories:

- Automatic resetting, if the error is merely a warning (e.g. temporary overvoltage)

- Transition in switched-off mode, ability to reset via new activation and zero setpoint

- Serious error, triggers deactivation and cannot be reset via external command

- Error might be reset by external command; user can define desired error reaction

Configuration parameters exist for the last mentioned category, with which the valvebehaviour might be customized.



7.3.1. Self Test

After the supply voltage has been switched on, every PSL/PSV proportional valve withCAN control, will undertake a detailed self test, during which it checks the integrity of theremanent storage (program and data) as well as the functioning of all components thatcan be tested automatically.

The entire self test takes about 700 ms. In case an error state was detected, initializationis discontinued; the valve remains in zero position and cannot be activated, even throughexternal commands.

7.3.2. Error During Operation

Errors that occur during active operations (overvoltage, undervoltage, positioning error,etc.) are classified by their seriousness and trigger an internal state transition.

7.3.3. Limited Operation

Operations are limited if the valve detects internal overheating, but can remain operativeat a reduced performance.

7.3.4. LED Error Codes

The PSL/PSV proportional valves have a diagnosis LED fitted to their top side enablingdirect diagnosis independent of the connection to the CAN bus.

The operating state or the last error occured are displayed via this two-colored LED.Following should be noted:

- Operating states correspond to unicoloured blink codes

- Errors are stored in codes with two numerals

- The number of blinking sequences by the green LED stands for the first numeral(0x to 9x) of the error code

- The number of blinking sequences by the red LED stands for the second numeral(0x to 9x)

- A long break indicates the beginning of the following code

- Serious errors have priority

- The used implementation of the LED flash codes does not conform to CiA-303

- If there is no pause between red and green, it’s a question about the identificationflashing 3.7.6



In an error-free case the green permanent light signals the active valve mode, greenflashing indicates the other states of the device state machine (see also subsection 5.1.3).

Table A.1 shows the codes of the various operating modes as well as the error states.

7.3.5. Standard error field

Another option to get information on errors is to read from the standard error field. Itcontains the previous 16 errors, that occured to the valve section. One can access thiserror field via parameters 490 up to 505 (PAR_ERR_LIST_0, _1, ... , _15).

CANopen Object 1003 indicate the active errors.

The following Table 7.1 shows the error referring to the parameter value.

Hex-value Error flag

1 EEPROM_CHECKSUM2 EEPROM_VERIFY4 EEPROM_WRITE8 FLASH_CHECKSUM

10 STARTUP_SFT20 SETPOINT40 SETP_NEQU_NEUTRAL80 SETP_TIMEOUT

100 GUARD_TIMEOUT200 CURRENT_CONTROL400 POS_MINUS800 POS_PLUS

1.000 COIL_RES_HIGH2.000 COIL_RES_LOW4.000 VOL_SUPPLY_LOW8.000 VOL_SUPPLY_HIGH

10.000 TEMP_HIGH20.000 TEMP_LOW40.000 T_LIMIT_HIGH80.000 CAN

100.000 POS_PLAUS200.000 POS_ITG400.000 CURRENT_ITG800.000 PAR_LIMIT

1.000.000 RAMTEST2.000.000 STATE4.000.000 WATCHDOG8.000.000 EXT_SENS_TO

10.000.000 MAN_ACT20.000.000 COB_ID_COL

continues on next page...



...continues from previous page

Hex-value Error flag

40.000.000 RES80.000.000 DEBUG

Table 7.1.: Error referring to parameter value

Parameter 506, called PAR_ERR_NR, with default value 0, increments with everyrecorded error.

Every error field has a parameter assigned, namely parameters 470 up to 485, calledPAR_ERR_LIST_X_T, where X has the same number as the error field itself. Thoseparameters output the operation time until that assigned error occured.

The assignment of each error message parameter to its operating time parameter isshown in Table 7.2

Error Message Parameter Operation Time Parameter

490 470491 471...504 484505 485

Table 7.2.: Assignment error message to operating time parameters

7.3.6. CAN Errors

Another type of errors are CAN errors. With parameters 550 - 558 the total number ofoccurences of one specific CAN error can be accessed. Table 7.3 shows the specificparameter number, the name of the parameter and gives a short explanation to eachCAN error.

No. Name Description

550 PAR_ERR_CAN_BUSOFF increases by one, if CAN controller enters bus-offstate. This happens, when the internal transmiterror counter exceeds the number of 255. Thecontroller is not able to transmit anything on theCAN anymore.

continues on next page...



...continues from previous page

No. Name Description

551 PAR_ERR_CAN_SILENT increases by one, if CAN controller enters theerror passive state. This happens if either thereveive error counter or the transmit error counterexceeds 127 but the transmit error counter has tobe less than 256 (otherwise bus-off state). Theerror counters will decrement everytime, there isa valid massage on the bus.

552 PAR_ERR_RX every CAN controller has its internal receive errorcounter. This counter can be read via that param-eter. The counter increases with every time, thecontroller detects an error concerning the recep-tion of a CAN message.

553 PAR_ERR_TX every CAN controller has its internal transmit er-ror counter. This counter can be read via thatparameter. The counter increases with everytime, the controller detects an error concerningthe transmission of a CAN message.

554 PAR_ERR_CAN_BIT increases by one, if the controller detects a mes-sage sent by itself but with the signal being turnedaround at any position except the arbitration fieldor the acknowledge slot.

555 PAR_ERR_CAN_FORM increases, if one of the pre-defined recessive bits,namely CRC delimiter, ACK delimiter and EOFbits, is not recessive.

556 PAR_ERR_CAN_STUFF increases if a stuff error occurs. If a CAN con-troller receives six bits with the same value andas part of SOF, arbitration, control, data and CRCfield, the bit-stuffing rule has been broken, whichleads to that stuff error.

557 PAR_ERR_CAN_OTHER If an error, not described in that table occurs, thisparameter increases. One can have a look at theerror frame on the bus to get more information onthat errors.

558 PAR_ERR_CAN_OVER if a CAN controller receives a telegram while stillhaving an older telegram in the input buffer, theold telegram is lost and cannot be processedby the controller. In that case this parameter in-creases.

Table 7.3.: CAN Errors



To get an overview on the structure of a CAN Datatelegram including the declaration ofeach bit field see Figure 2.3.

7.4. Parameter Concept

All internal control variables that significantly influence the program sequence are de-signated as parameters. Unlike the constants they can be changed in principle. Parame-ters are stored in a remanent data memory (EEPROM).

Which and how parameters can be changed by the (end) user, is determined by thecommunication protocol used. The parameter set, that is generally available, is basedon the objects fixed in the CANopen device profile CiA-408. A reasonable selection ofoperating parameters for proportional valves is set there.

The adjustments for parameters are limited when using other communication protocols.

Generally, one might distinguish between “communication parameters” and “applicationparameters”. The first are responsible for all communication functions, while the latterconcern the actual application of a bus device.

7.4.1. Parameters in EEPROM and RAM

An EEPROM module serves as physical storage space for parameter data, where theyare stored together with the checksum information. A consistency check is performedwhen restarting the valve. In the event of a parameter inconsistency, an internal error istriggered.

For their further usage the parameter data are copied to the RAM. In keeping withthe CANopen standard, changes to the parameters (write commands) refer exactly tothis section of the RAM. To make a change permanent the command “Save” must beexecuted.

7.4.2. Efficiency of Parameter Changes

WARNING

The bulk of parameter data only becomes effective once the valve is restarted af-ter being cut from the voltage supply. This applies in particular for such essentialcommunication parameters as the baud rate.

Parameter changes are not applied immediately and can lead to unexpected be-havior after the restart. Cause and effect may be deferred!



Conscious restart after change of parameters to assess impact immediately.

In the special case of Baud rate change by the user he has to take care that it is appliedfor all valves of the same valve bank and subsequent saving of the changes in EEPROMis also done for all valves that have been changed.

7.4.3. Communication Parameters

The communication parameters control the communication behavior of the Slave. Es-sential are the baud rate setting, the node-ID of the slave, as well as activation or timeconstants for safety mechanism such as Node Guarding or Heartbeat.

7.4.4. Application Parameters

Exemplary application parameters are the ramp settings that shall limit the oil flow’sspeed of change in the event of setpoint jumps.

7.4.5. Reading and Writing Parameters

The CANopen commands defined in CiA-301 are used for polling or changing theparameter values. A detailed explanation how to execute reading and writing processesis provided by section 3.5.

7.5. Preprocessing of Setpoints

Various internal control parameters of HAWE PSL/PSV valve nodes can be set in a waythat a preprocessing of the setpoint commands (coming from controller or joystick) takesplace. The following aspects of the valve behavior can be affected by this parameter:

- Fine control range or increased dynamics: Nonlinear mapping of the setpoint toincrease the fine control range or sensitivity.

- Setpoint limitation (override): Linear reduction of setpoints. Simulates a valve witha smaller nominal amount.

- Ramps: The rate of change of the oil flow is restricted.

- Reversal of the direction



WARNING

If the control parameters switch from the default settings, the valve regulates anoil quantity that doesn’t correspond with the setpoint.

Ramps can lead to tracking of movements, even when the setpoint is 0.

Otherwise (default) the valve position follows the unmodified setpoint as fast as possible.

7.5.1. Over Temperature Protection

In order to counteract damage of control electronics by over temperature, an internpower limitation is implemented, which limits self-heating in case of over temperature.

This will be accomplished by reducing the control currents that are generated by thecontrol electronics. To enable anymore (limited) operation of the valve the power limitationworks continuously. The higher the temperature gets, the more the power of the valvewill be limited.

Having reached an intern temperature of 90 C the power limitation starts, at a tempera-ture of 120 C the valve is completely switched off. An illustration of this process can beseen in the following Figure 7.1.

It should be pointed out that the intern temperature of the control electronics dependsnot only on the ambient temperature but also on the oil temperature. According to therecommendations of the hydraulic documentation appropriate action should be taken tolimit oil temperature.



0

20

40

60

80

100

120

0 20 40 60 80 100 120 140

temperature [°C]

elec

tric

ial p

ower

[%]

Figure 7.1.: Illustration of Over Temperature Protection

The values of both temperatures, where the limitation starts and where it stops, canbe set in a certain range by the user himself. The respective default values are 90 Cand 120 C, i.e. if the parameters will not be modified, the temperature is reduced in atemperature range from 90 C to 120 C (See Figure 7.1). By changing the parameters itis only possible to start the limitation earlier, if required by the user.

start temperature end temperatureparameters PAR_TEMP_REDUCT_START PAR_TEMP_REDUCT_ENDparameter index 63 64CANopen-object 2113 2114range 65 C - 90 C 80 C - 120 C

default 90 C 120 C

7.5.2. Fine control range or increased dynamics

Via object 0x2090.1 for side A and object 0x2091.1 for side B the characteristics ofthe valve can be distorted. The non-linear mapping of setpoint to oil flow is shown inFigure 7.2.



A-side B-sideparameters PAR_A_KRUEMMUNG PAR_B_KRUEMMUNGparameter index 14 34CANopen-object 2090 2091range -1000 to 1000 -1000 to 1000default 0 0

0

100

200

300

400

500

600

700

800

900

1000

0 100 200 300 400 500 600 700 800 900 1000

Setpoint [Per Mille]

Oil

Flo

w N

omin

al A

mou

nt [P

er M

ille]

Figure 7.2.: Nonlinear Curve Transformation

By default (distortion parameter 0) the curve corresponds with a linear characteristic(purple dotted line).

If a fine control range is desired, i.e. a slow increase of the oil flow at low deflections ofthe control devices, the distortion corresponding to the green solid curve in the figurecan be activated in extreme cases. This represents a distortion parameter of 1000.

In the opposite case (if an increased momentum in the starting range is desired), adistortion can be adjusted according to the blue dashed dotted curve. This correspondsto a distortion parameter of −1000. Values between −1000 . . . 1000 allow a gradualadjustment in either direction.

The distortion of the setpoints can be chosen independently for A and B side.



7.5.3. Setpoint reduction (Override)

The other modification parameters (0x2092 for A side and 0x2093 for B side) serve toreduce the nominal amount. Default corresponds to a scaling with factor 1 (full nominalamount), this corresponds to 1000 per mill. A change in value to 500 per mill wouldcorrespond to a bisection of the nominal amount. The reduction of the setpoint may beselected independently for A and B side.

A-side B-sideparameters PAR_A_OVERRIDE PAR_B_OVERRIDEparameter index 13 33CANopen-object 2092 2093range 0-1000 0-1000default 1000 1000

7.5.4. Ramps

Ramps are used for the damping of setpoint steps, i.e. they set a maximum rate ofchange of the quantity of oil delivered from the valve. Ramps are denoted in milliseconds,this date refers to a setpoint step from the zero position to the nominal amount. Thereexist two ramp sets which can be toggled by PDO in Byte 0.

Actual Value

t in ms

I II

III IV

Figure 7.3.: Ramp Characteristics and Control Parameters

The corresponding control parameters are shown in Table 7.4 and Table 7.5.



Ramp time A acceleration (I) Ramp time A deceleration (II)parameters PAR_A_RAMP_ACE PAR_A_RAMP_DECEparameter index 10 11CANopen-object 6332.1 6333.1default 1 1

Ramp time B acceleration (III) Ramp time B deceleration(IV)

parameters PAR_B_RAMP_ACE PAR_B_RAMP_DECEparameter index 30 31CANopen-object 6335.1 6336.1default 1 1

Table 7.4.: Ramp Parameters 1. Ramp

Ramp parameters can be defined for both A and B side as well as increasing or de-creasing setpoints, i.e. acceleration and deceleration of the corresponding hydraulicconsumers.

An exemplary movement as a time-speed diagram is shown in Figure 7.3. Phase (I)demonstrates the case of the acceleration of a movement supplied by the A-side of thevalve. The corresponding slowing down (deceleration) complies with phase (II).

Similarly, the behavior of the movements fed by the B-side is influenced by controlparameters. It should be noted that phase (III), although representing a falling line inthe time-speed diagram, corresponds to an accelerated movement. Accordingly, thecorresponding deceleration takes place in phase (IV).

Ramp time A acceleration(2. Ramp)

Ramp time A deceleration(2. Ramp)

parameters PAR_A_RAMP_ACE2 PAR_A_RAMP_DECE2parameter index 40 41CANopen-object 2300.1 2301.1default 1 1

Ramp time B acceleration(2. Ramp)

Ramp time B deceleration(2. Ramp)

parameters PAR_B_RAMP_ACE2 PAR_B_RAMP_DECE2parameter index 42 43CANopen-object 2302.1 2303.1default 1 1

Table 7.5.: Ramp Parameters 2. Ramp

The second ramp set is only accessible in firmware variants DS408 and PLVC Plug&Play.The ramp set is capitalized via the device control word (DCW).



The properties of the DCW are described in subsection 5.2.3. If bit 0.5 (bit 13 of theDCW) in PDO0 is 1, ramp set 2 is assumed, otherwise ramp set 1 is used.


8. Software

To support the commissioning of CAN PSL/PSV valves, different PC software tools areoffered by HAWE. Those tools can be purchased by DVD or USB Stick. In particular, thefollowing steps will be facilitated:

• Direct communcation of valve electronics by means of a parameterization anddiagnostic tool for CAN valves, the “PSXCANc” developed by HAWE

• Facilitated intergation into CAN Open Systems using EDS files

In any case, using PC technology, a connection of the PC to the CAN network is needed.For this, usually, CAN-USB Dongles are used.

8.1. HAWE DVD

A DVD containing PC software, is e.g. part of the Starter-Set (see chapter 9), but mayalso be purchased independently from HAWE Hydraulik. The DVD contains the followingPSX-CAN specific elements:

- Service manual

- Technical data for PSL/PSV valves

- .NET 4.0 driver

- Driver for PEAK USB Dongle

- PC Software “PSXCANc”

- Parameter spezification

- Current EDS Files

- PLVC funcktion block for Plug&Play control of PSX-CAN valves

- Documentation and programming system HAWE control devices (PLVC)


8. Software

8.2. PSXCANc

The scope of this document is to describe the possible service interactions that can beperformed on HAWE PSL/PSV CANNode valve electronics. This can be realized e.g. bya HAWE developed software tool, called PSXCANc. The list below shows the possibleinteractions:

• Import/Export/Change of parameters

• Commissioning/Scope

• Firmware updates

• Error management

8.2.1. How to get a free PSXCANc License

When you sart PSXCANs for the first time, you have to enter some information to get acomputer based license.

Figure 8.1.: Start-up dialog PSXCANc tool

For a period of 7 days the tool may be without registration.

Please fill in owner name, company and mail with your personal information, e.g.:

Figure 8.2.: Start-up dialog filled with information


8. Software

1. If you have an installed mailing application on your computer, then please press“Send Mail” button. A mail dialog will be opened with the necessary information.

2. If you have no possibility to send a mail directly from your computer, please press“Save File” button and safe the license request file on an USB memory stick. Thensend this file to [email protected].

3. In resonse to this request we mail a license file. Please press “Load File” button toactivate the license on your computer.

8.2.2. Connection to the bus

Figure 8.3.: Baudrate selection

After starting the program the correct transfer rate has to be selected in the highlighteddrop down menu in Figure 8.3. By clicking the button right to the highlighted box, theprogram connects to the CAN network.

The result of a successfull connect is shown in Figure 8.4. There you can see, that aslave with node-id 36 was found. Additional details of the slave can be found in thedebug window.

The detected slaves are also shown in the menu bar that is labed “Current Nodes:“.By clicking on an entry, the corresponding device is selected for further functions likefirmware download.


8. Software

The device state of the currently(!) selected device is displayed in the upper right cornerof Figure 8.4. The traffic light right next to the current device state allows the manualselection of the 3 most important states:

• Device mode active (shown in green)

• Disabled (shown in yellow)

• Fault (shown in red)

For more information see subsection 5.1.3 and Figure 5.1.

Figure 8.4.: Information about detected nodes

8.2.3. Firmware

To download a firmware either use the green button in the tool bar, or the entry “Firmware->CANNode” under the “Actions” menu shown in Figure 8.5.


8. Software

Figure 8.5.: Firmware download

You can download the firmware to all HAWE CANNodes found in the acutal CAN networkby using “Firmware->all CANNodes” in the “Actions” menu.

The following file manager window lets you choose the firmware that will be downloadedto the CANNode(s). After a file is selected, the build properties of the this file aredisplayed for verification as shown in Figure 8.6.


8. Software

Figure 8.6.: Verify the correct firmware

After selecting “yes”, the progress of the download can be tracked in the info line at thebottom of the window. A successfull download is followed by a reboot of the device.


8. Software

8.2.4. Parameter

Figure 8.7 shows the parameter table. It is displayed when the highlighted button in thetoolbar is pressed or the related menu entry under “Actions” is selected.

Each column contains the parameters of one device.

In most cases but not in all the parameters of the different devices should be very similar.To support this idea the background of each parameter is color coded with the followingmeaning:

• white: equal, ok

• yellow: ok, but not the default value

• red: different, maybe not ok (the PAR_CAN_ID must be different!)

Figure 8.7.: Parameter table

If the mouse cursor is moved over a parameter, the tooltip shows the parameter descrip-tion, the minimum and maximum value of the parameter.

The button “RestoreDefault”, when clicked, resets every parameter to its default value.The last two buttons on the tool bar allow parameter import and export operations.

To change a parameter just click on its value field and type in the new value. Parametersare saved into RAM and into EEPROM. If parameters are changed and commited tothe device via the “Store” button, they are saved into the RAM. To save parametersremanently use the button “Save2EE” after “Store”.

NOTE

Please keep in mind that EEPROMs have a limited number of write cycles.

If a change of parameters is necessary it is a good habit to document the changes


8. Software

and export the parameter settings to a file.

Example - Change the NodeID

The parameter NodeID has the number 111 and is named “PAR_CAN_ID” (CANopen-object 2000), its current value is displayed in the rigth column.To change the value click into the value box and enter the new value. Confirm the valueby clicking “Enter”. After that store the changes by pressing “Store” and “Save2EE”.

NOTE

The changed NodeID is in effect after the next rebooted, by then it is accessiblewith its old value.

Example - Change the Baudrate

The parameter Baudrate has the number 112 and is named “PAR_CAN_BAUDRATE”(CANopen-object 2001), its current value is displayed in the rigth column.

transfer rate hexadecimal value decimal value125 kbit/s 0x125 293250 kbit/s 0x250 592500 kbit/s 0x500 12801000 kbit/s 0x1000 4096

Table 8.1.: Baudrate

To change the value click into the value box and enter the new value. It is possible toenter the hexadecimal value or the decimal value ( see Table 8.1). The service tool willsubmit the correct value.

Always make sure that all valves are set to the same baudrate!

Confirm the value with the key “Enter”. After that store the changes by pressing “Store”and “Save2EE”.

NOTE


8. Software

The changed Baudrate is in effect after the next reboot, until then it is only acces-sible with its old value.

8.2.5. Error Management

Clicking the highlighted button in Figure 8.8 opens a window that displayes the currenterror status of each found CANNode.

Figure 8.8.: Error table

Hovering the mouse cursor over the error, shows a tooltip that explains it. Possible errorsin the first row of Figure 8.8 are described in Table 8.2.

Error Value

EEPROM_CHECKSUM 1EEPROM_VERIFY 2EEPROM_WRITE 4FLASH_CHECKSUM 8STARTUP_SFT 10SETPOINT 20SETP_NEQU_NEUTRAL 40

table continued on next page. . .


8. Software

. . . continued from previous page

SETP_TIMEOUT 80GUARD_TIMEOUT 100CURRENT_CONTROL 200POS_MINUS 400POS_PLUS 800COIL_RES_HIGH 1000COIL_RES_LOW 2000VOL_SUPPLY_LOW 4000VOL_SUPPLY_HIGH 8000TEMP_HIGH 10000TEMP_LOW 20000T_LIMIT_HIGH 40000CAN 80000POS_PLAUS 100000POS_ITG 200000CURRENT_ITG 400000PAR_LIMIT 800000RAMTEST 1000000

Table 8.2.: Errors

The second row in Figure 8.8 is dedicated to the startup selftest. These errors aredescribed in Table 8.3.

Fehler Beschreibung WertSFT_UBAT_ZERO Supply voltage zero point exceeds limit 2000000SFT_STROM_ZERO Current measurement zero point exceeds

limit4000000

SFT_HALL_ZERO Internal spool position sensor zero point ex-ceeds limit

8000000

SFT_HT_SHORT Short circuited main transistor detected 10000000SFT_HT_OPEN Idling main transistor detected 20000000SFT_PWM_SHORT Short circuited PWM transistor detected 40000000SFT_PWM_OPEN Idling main PWM transistor detected 80000000SFT_RESIST_A Coil resistance A-side exceeds limit 100000000SFT_RESIST_B Coil resistance B-side exceeds limit 200000000SFT_RESIST_DIFF Difference between coil resistance A and B

side to high400000000

SFT_OPEN_A Coil side A idle 800000000SFT_OPEN_B Coil side B idle 1000000000SFT_CHANGE_COIL Coil has to be changed soon 2000000000SFT_UBAT_RANGE Supply voltage exceeds acceptable limit 4000000000

Table 8.3.: Error description - startup selftest


8. Software

8.2.6. Commissioning

Scope

The scope allows to view the dynamic operation of the valves.

By clicking the highlighted buttons shown in Figure 8.10, the scope window and thesetpoint generator opens. Both windows are shown in the screenshot.

The description of icons in the toolbar can be viewed in Figure 8.9.

Figure 8.9.: Application: toolbar

After starting the scope every variable is recorded even when the variable is not selectedin the caption. The meaning of items in the legend is given in the following list for mostof the cases:

0. filtered current1. unfiltered spool position2. filtered supply voltage3. filtered temperature4. unfiltered current5. filtered spool position6. pwm setpoint8. spool setpoint9. current setpoint

14. resistor A15. resistor B16. external setpoint

Setpoint generator

In general you have to ensure that the button “operational” is activated. In the windowfor modifying the setpoint there are two sliders. The upper slider allows to choose asetpoint in per mill. Its update rate is entered into an input box in the lower left cornerof the window. The default update rate is 20 milliseconds. The lower slider shows thecurrent flow in per mill. The user should be familiar with section 5.2 (CommunicationProcedure), to be able to understand the mode of operation of the setpoint generator.


8. Software

Figure 8.10.: Scope together with setpoint generator

8.2.7. Advanced options

By clicking the button “Operational” in the toolbar, a wake-up command will be sent toevery CAN device, whose state is changed to ’operational’ by the communication statemachine.

The drop down box highlighted in Figure 8.11 allows to send individual customised CANmessages with the format: COB-ID, Byte 0, Byte 1, . . . Byte 7.


8. Software

Figure 8.11.: Edit a CAN message

8.3. Electronic Datasheets (EDS)

For CANopen devices, manufacturers frequently offer machine-readable descriptions,so-called electronic data sheet files, that allow standard software to access services ofthe device.

HAWE offers EDS files for the PSL/PSV CAN actuated valves on request.


9. Starter-Set

The purpose of the starter-set is, to enable communication with HAWE CAN valves,working on the desk, without a totally functioning hydraulic overall system. Target groupare primarily programmers of the controller software of the system.

Using the starterkit a PC can be used as remote terminal (point to point connection to theCAN Dongle). It is also possible to operate complete bussystem simulation, containing alot of bus participants.

The scope of supply includes a valve section containing a magnet wafer. In case ofactivation it is possible to follow the mechanical deflection of the electronic solenoids, toregister wether and in which strength a setpoint setting reaches actually the valve.

9.1. Components

Your Starter-Set should include following parts:

• Valve electronics with respective solenoid body

• 4-pole AMP mating connector connected by a CAN-Bus-cable with a D-Sub andtwo 4-mm-clip-connectors (Figure 9.1)

• Installation-CD (see section 8.1) with driver software

• optional CAN USB Dongle (Fa. PEAK), see Figure 9.2

In addition to the delivery package a power supply (e.g.24V, 1A) is needed.

The Starter-Set and the required PEAK CAN USB Dongle can be ordered at HAWEHydraulik SE using the part number:

Articel Part numberPSX-CAN Starter-Set 3405 4200-00PEAK CAN USB Dongle 6219 2001-00

Table 9.1.: Order Information


9. Starter-Set

Figure 9.1.: Cable provided with the starter-set

If not otherwise requested, the valve electronics will be delivered with a CANopen DS408firmware, configured with a Baud rate of 250 kBit/s.

9.2. Commissioning

• connect the AMP-connector of the valve with the mating connector(Figure 1.3) withconnection cable

• connect the banana sockets following the polarization of the power supply (redcorresponds positive voltage)

• sufficient energy supply up to 1A at around 24V is typical

If the valve is mounted correctly, the LED on the top will start flashing.

For a direct connection of the cable with a USB-CAN Dongel or to get connected withother bus participants it cantains a 7-pin Sub-D plug with CAN default setting (Pin 2CAN-L, 7 CAN-H).

Futhermore, a switchable terminating resistor is integrated in the plug. It is possible toswitch this terminating resistor on or off by a little switch.


9. Starter-Set

Additional information about terminating resistors and correct interpretation of CAN busnetworks refer to subsection 2.1.2.

The valve section itself and the connection socket don’t have a termination resistor.

Normally, the Sub-D plug is connected with PC by a CAN-USB-adapter. An overview ofthe permissible limits is shown in Table 1.2. In principle, any PC-CAN Software can beused for actuation and monitoring the functionality of the CAN-bus, for example CANOpen configurations-tools

Using the PC Software refering the DVD, follow the installation instructions. The usershould be familiar with section 5.2. You can get additional information in chapter 8.

This adapter can be ordered at HAWE Hydraulik SE with part number 6219 2001-00 orat PEAK-System Technik (http://www.peak-system.com/).

Figure 9.2.: PCAN-USB-adapter

Optionally you can choose between a stan-dard version and an opto-decoupled ver-sion. The opto-decoupled version guaran-tees a galvanic isolation up to maximum500V between PC and CAN-side.Furthermore a CAN-monitor und a pro-gramming-interface is provided in this pack-age.


http://www.peak-system.com/

10. Calibrating Interfaces

In case of repair it is necessary to have the possibility to calibrate locally. Thereforefirmware version 2421 or higher is required.

10.1. Overview

After attaching the electronics on the valve it is necessary to adjust the electronics to thevalve. The zero point as well as the calibrating points for minimal and maximal flow ratehave to be set.

Ensure that the screws get fixed again with the correct torque given in HAWE Partsman.

To adjust the zero-point, the lever has to be in neutral position. The zero-point can beset.The calibrating point for the minimal flow rate is reached as soon as the actor is moving.The calibrating point for the maximal flow rate is reached as soon as the actor is movingwith nominal speed.The position transducer has to be calibrated with a setpoint message by bus, using thehandlever is not possible. Following section explains the Bus-commands being usedtherefore.

10.2. Calibrating Messages

It is possible to store calibrating values by using the write access of a SDO (Service DataObject SDO). The data content of a write command consists of a Magic Number1, shownin Table 10.1. After reception of the message the act valve checks if the neccessairyconditions for the calibrating step are complied with. If so, the calibrating data is savedin the remanent memory of the valve and the calibrating step is done.

1The magic number is a written value and defined to reduce the probability of a command running byaccident


10. Calibrating Interfaces

Nr. Index Bedeutung Value1 0x6043 Device Control Mode 0x012 0x2020.1 reset curve characteristics 0x489AB3243 0x2020.2 Zero point adjustment 0x489AB3284 0x2020.3 calibrating point; set minimal flow rate 0x489AB3265 0x2020.4 calibrating point; set maximal flow rate 0x489AB327

Table 10.1.: Calibrating Messages

The calibrating steps have to be performed in the given order.

The first step sets the operating mode to “current controlled” (also see subsection 5.1.1),so that all operating points can be adressed.

WARNING

Attention: While calibrating, the object 0x1010.1 should not be executed, sincethis would also save the Device Control Mode!

The lever has to be in neutral position for executing step 3.

Afterwards the operating points of minimal and maximal flow rate should be encounteredby setpoint-PDO’s for the A and the B side. The teach-in is done by the commands givenin step 4 and 5.


A. Appendix

A.1. Error Index

Error code Class LED code Meaning Reaction0h No error2211h 1 13 Current control error (transistor/coil) fault3410h 2 65 Supply voltage exceeds acceptable limit3411h 2 15 Supply voltage too high warning3412h 2 16 Supply voltage too low warning4110h 3 14 Limited operation because of over temperature warning4211h 3 25 Electronics temperature too high fault reaction4212h 3 24 Electronics temperature too low warning5230h 1 42 Current control error, possible supply problem fault5231h 7 38 Sticky spool movment warning5234h 1 52 Current measurement zero point exceeds limit during self test5235h 7 53 Internal spool position sensor zero point exceeds limit during self test5237h 2 51 Supply voltage zero point exceeds limit during self test5401h 7 54 Short circuited main transistor detected during self test5402h 7 55 Open main transistor detected during self test5403h 7 56 Short circuited PWM transistor detected during self test

Continuation on the next page ...

B7700

CA

NM

anualR

evision:720

(10.11.2017)

A.

Appendix

Page

135

... Continuation from the previous page (Table A.1)

Error code Class LED code Meaning Reaction5404h 7 57 Open main PWM transistor detected during self test5405h 1 62 Coil side A open5406h 1 63 Coil side B open5407h 1 64 Coil has to be changed soon5411h 1 37 Coil resistance too high warning5412h 1 36 Coil resistance too low warning5413h 1 61 Difference between coil resistance A and B side to high5414h 1 58 Coil resistance A-side exceeds limit during self test5415h 1 59 Coil resistance B-side exceeds limit during self test5510h 0 26 RAM test failed fault reaction5530h 1 33 Checksum flash failed fault5531h 1 34 Checksum EEPROM failed fault5532h 1 35 EEPROM verify failed fault reaction6010h 0 Software reset (watchdog) warning6100h 0 32 State machine error fault reaction6101h 1 12 Startup failed fault6320h 4 Parameter exceeds limit warning6321h 7 46 Parameters for error transitions are inconsistent6322h 7 - Internal valve data is inconsistent8101h 4 - Setpoint not feasible disabled8102h 4 21 Setpoint has to be neutral at start disabled8103h 4 22 Setpoint timeout disabled8110h 4 11 CAN internal fault disabled8130h 4 23 Node guarding failed disabled8301h 7 18 Spool does not reach setpoint warning


B7700

CA

NM

anualR

evision:720

(10.11.2017)

A.

Appendix

Page

136


Error code Class LED code Meaning Reaction8302h 7 19 Spool overshoots setpoint disabled8304h 7 41 Internal spool position sensor not feasible fault reaction

Table A.1.: Overview of Possible Errors

B7700

CA

NM

anualR

evision:720

(10.11.2017)

A. Appendix

A.2. Error Description

A.2.1. NO_ERROR

Name NO_ERRORCANopen Error(Class)

0 ()

BlinkcodeDescription No errorReactionpossible action

A.2.2. CURRENT_CONTROL

Name CURRENT_CONTROLCANopen Error(Class)

2211 (1)

Blinkcode 13Description Current control error (transistor/coil)Reaction faultpossible action Replacement of the valve section.

A.2.3. SFT_UBAT_RANGE

Name SFT_UBAT_RANGECANopen Error(Class)

3410 (2)

Blinkcode 65Description Supply voltage exceeds acceptable limitReactionpossible action Ensure that proper supply voltage is applied to the

device. If necessary, perform control measurement ofthe supply.


A. Appendix

A.2.4. VOL_SUPPLY_HIGH

Name VOL_SUPPLY_HIGHCANopen Error(Class)

3411 (2)

Blinkcode 15Description Supply voltage too highReaction warningpossible action Ensure proper power supply.

A.2.5. VOL_SUPPLY_LOW

Name VOL_SUPPLY_LOWCANopen Error(Class)

3412 (2)

Blinkcode 16Description Supply voltage too lowReaction warningpossible action Ensure proper power supply.

A.2.6. T_LIMIT_HIGH

Name T_LIMIT_HIGHCANopen Error(Class)

4110 (3)

Blinkcode 14Description Limited operation because of over temperatureReaction warningpossible action E.g. make sure the oil cooling’s limit temperature is

not reached.

A.2.7. TEMP_HIGH

Name TEMP_HIGHCANopen Error(Class)

4211 (3)

Blinkcode 25Description Electronics temperature too highReaction fault reactionpossible action Cause identification and repair.


A. Appendix

A.2.8. TEMP_LOW

Name TEMP_LOWCANopen Error(Class)

4212 (3)

Blinkcode 24Description Electronics temperature too lowReaction warningpossible action Replacement of the valve section.

A.2.9. CURRENT_ITG

Name CURRENT_ITGCANopen Error(Class)

5230 (1)

Blinkcode 42Description Current control error, possible supply problemReaction faultpossible action Replacement of the valve section.

A.2.10. POS_ITG

Name POS_ITGCANopen Error(Class)

5231 (7)

Blinkcode 38Description Sticky spool movmentReaction warningpossible action Ensure correct hydraulically operating conditions (oil

filtering, etc.).


A. Appendix

A.2.11. SFT_STROM_ZERO

Name SFT_STROM_ZEROCANopen Error(Class)

5234 (1)

Blinkcode 52Description Current measurement zero point exceeds limit during

self testReactionpossible action Replacement of the valve section.

A.2.12. SFT_HALL_ZERO

Name SFT_HALL_ZEROCANopen Error(Class)

5235 (7)

Blinkcode 53Description Internal spool position sensor zero point exceeds limit

during self testReactionpossible action Replacement of the valve section.

A.2.13. SFT_UBAT_ZERO

Name SFT_UBAT_ZEROCANopen Error(Class)

5237 (2)

Blinkcode 51Description Supply voltage zero point exceeds limit during self testReactionpossible action Replacement of the valve section.


A. Appendix

A.2.14. SFT_HT_SHORT

Name SFT_HT_SHORTCANopen Error(Class)

5401 (7)

Blinkcode 54Description Short circuited main transistor detected during self

testReactionpossible action Replacement of the valve section.

A.2.15. SFT_HT_OPEN

Name SFT_HT_OPENCANopen Error(Class)

5402 (7)

Blinkcode 55Description Open main transistor detected during self testReactionpossible action Replacement of the valve section.

A.2.16. SFT_PWM_SHORT

Name SFT_PWM_SHORTCANopen Error(Class)

5403 (7)

Blinkcode 56Description Short circuited PWM transistor detected during self

testReactionpossible action Replacement of the valve section.


A. Appendix

A.2.17. SFT_PWM_OPEN

Name SFT_PWM_OPENCANopen Error(Class)

5404 (7)

Blinkcode 57Description Open main PWM transistor detected during self testReactionpossible action Replacement of the valve section.

A.2.18. SFT_OPEN_A

Name SFT_OPEN_ACANopen Error(Class)

5405 (1)

Blinkcode 62Description Coil side A openReactionpossible action Replacement of the valve section.

A.2.19. SFT_OPEN_B

Name SFT_OPEN_BCANopen Error(Class)

5406 (1)

Blinkcode 63Description Coil side B openReactionpossible action Replacement of the valve section.

A.2.20. SFT_CHANGE_COIL

Name SFT_CHANGE_COILCANopen Error(Class)

5407 (1)

Blinkcode 64Description Coil has to be changed soonReactionpossible action


A. Appendix

A.2.21. COIL_RES_HIGH

Name COIL_RES_HIGHCANopen Error(Class)

5411 (1)

Blinkcode 37Description Coil resistance too highReaction warningpossible action Replacement of the valve section.

A.2.22. COIL_RES_LOW

Name COIL_RES_LOWCANopen Error(Class)

5412 (1)

Blinkcode 36Description Coil resistance too lowReaction warningpossible action Replacement of the valve section.

A.2.23. SFT_RESIST_DIFF

Name SFT_RESIST_DIFFCANopen Error(Class)

5413 (1)

Blinkcode 61Description Difference between coil resistance A and B side to

highReactionpossible action Replacement of the valve section.

A.2.24. SFT_RESIST_A

Name SFT_RESIST_ACANopen Error(Class)

5414 (1)

Blinkcode 58Description Coil resistance A-side exceeds limit during self testReactionpossible action Replacement of the valve section.


A. Appendix

A.2.25. SFT_RESIST_B

Name SFT_RESIST_BCANopen Error(Class)

5415 (1)

Blinkcode 59Description Coil resistance B-side exceeds limit during self testReactionpossible action Replacement of the valve section.

A.2.26. RAMTEST

Name RAMTESTCANopen Error(Class)

5510 (0)

Blinkcode 26Description RAM test failedReaction fault reactionpossible action Replacement of the valve section.

A.2.27. FLASH_CHECKSUM

Name FLASH_CHECKSUMCANopen Error(Class)

5530 (1)

Blinkcode 33Description Checksum flash failedReaction faultpossible action Replacement of the valve section.

A.2.28. EEPROM_CHECKSUM

Name EEPROM_CHECKSUMCANopen Error(Class)

5531 (1)

Blinkcode 34Description Checksum EEPROM failedReaction faultpossible action Replacement of the valve section.


A. Appendix

A.2.29. EEPROM_VERIFY

Name EEPROM_VERIFYCANopen Error(Class)

5532 (1)

Blinkcode 35Description EEPROM verify failedReaction fault reactionpossible action -

A.2.30. WATCHDOG

Name WATCHDOGCANopen Error(Class)

6010 (0)

BlinkcodeDescription Software reset (watchdog)Reaction warningpossible action Replacement of the valve section.

A.2.31. STATE

Name STATECANopen Error(Class)

6100 (0)

Blinkcode 32Description State machine errorReaction fault reactionpossible action Replacement of the valve section.

A.2.32. STARTUP_SFT

Name STARTUP_SFTCANopen Error(Class)

6101 (1)

Blinkcode 12Description Startup failedReaction faultpossible action Restart the valve, if the error is reproducible, exchange

the valve.


A. Appendix

A.2.33. LIMIT

Name LIMITCANopen Error(Class)

6320 (4)

BlinkcodeDescription Parameter exceeds limitReaction warningpossible action Control of the parameterization process.

A.2.34. ILLEGAL_ERRTRANSMASK

Name ILLEGAL_ERRTRANSMASKCANopen Error(Class)

6321 (7)

Blinkcode 46Description Parameters for error transitions are inconsistentReactionpossible action

A.2.35. ILLEGAL_VALVEDATA

Name ILLEGAL_VALVEDATACANopen Error(Class)

6322 (7)

Blinkcode -Description Internal valve data is inconsistentReactionpossible action

A.2.36. SETPOINT

Name SETPOINTCANopen Error(Class)

8101 (4)

Blinkcode -Description Setpoint not feasibleReaction disabledpossible action Adaptation of the controller software, send the correct

setpoints format.


A. Appendix

A.2.37. SETP_NEQU_NEUTRAL

Name SETP_NEQU_NEUTRALCANopen Error(Class)

8102 (4)

Blinkcode 21Description Setpoint has to be neutral at startReaction disabledpossible action Start with zero setpoints, and make sure that with

restart at least a zero setpoint is sent.

A.2.38. SETP_TIMEOUT

Name SETP_TIMEOUTCANopen Error(Class)

8103 (4)

Blinkcode 22Description Setpoint timeoutReaction disabledpossible action Regularly send a setpoint that arrives safely within the

prescribed monitoring period.

A.2.39. CAN

Name CANCANopen Error(Class)

8110 (4)

Blinkcode 11Description CAN internal faultReaction disabledpossible action Check the dimensioning of the CAN network. Is se-

lected baud rate appropriate to data traffic? Verifica-tion of interfaces (connectors), termination etc.


A. Appendix

A.2.40. GUARD_TIMEOUT

Name GUARD_TIMEOUTCANopen Error(Class)

8130 (4)

Blinkcode 23Description Node guarding failedReaction disabledpossible action The regularly sending of node guard requests or heart-

beats from the control unit has to be ensured. Possiblyalso adapt to tight tolerance window on the bus load.

A.2.41. POS_MINUS

Name POS_MINUSCANopen Error(Class)

8301 (7)

Blinkcode 18Description Spool does not reach setpointReaction warningpossible action Control of mechanical function, absence of operator

intervention, maybe changing of too close tolerancewindows in the lag error monitoring. Please note thatextremely cold temperatures can slow the responsetime of the valve.

A.2.42. POS_PLUS

Name POS_PLUSCANopen Error(Class)

8302 (7)

Blinkcode 19Description Spool overshoots setpointReaction disabledpossible action Control of mechanical function, absence of operator

intervention, maybe changing of too close tolerancewindows in the lag error monitoring. Please note thatextremely cold temperatures can slow the responsetime of the valve. An external back-up level shouldbe provided in order to disconnect hydraulic actuatorsfrom the pressure supply when this fault is detected.


A. Appendix

A.2.43. POS_PLAUS

Name POS_PLAUSCANopen Error(Class)

8304 (7)

Blinkcode 41Description Internal spool position sensor not feasibleReaction fault reactionpossible action Replacement of the valve section.

A.3. SDO Index CANopen 301

Index. Sub Name Default1000h Device Type 4081001h Error register 01003h 0 Predefined error field 01003h 1 Predefined error field 01003h 2 Predefined error field 01003h 3 Predefined error field 01003h 4 Predefined error field 01003h 5 Predefined error field 01003h 6 Predefined error field 01003h 7 Predefined error field 01003h 8 Predefined error field 01003h 9 Predefined error field 01003h A Predefined error field 01003h B Predefined error field 01003h C Predefined error field 01003h D Predefined error field 01003h E Predefined error field 01003h F Predefined error field 01003h 10 Predefined error field 01005h COB-ID SYNC 0x800000801008h Manufacturer device name HAWE1009h Manufacturer hardware version ””100Ah Manufacturer software version ””100Ch Guard time 0100Dh Life time factor 01010h 0 Store parameter field 11010h 1 Store parameter field 11011h 0 Restore default parameters 2



A. Appendix


Index Sub Name Default1011h 1 Restore default parameters 01011h 2 Restore default parameters 01014h COB-ID EMCY $NODEID+0x801015h Inhibit time emergency 01016h 0 Consumer heartbeat time 11016h 1 Consumer heartbeat time 01017h Producer heartbeat time 01018h 0 Identity object 41018h 1 Identity object 7111018h 2 Identity object 11018h 3 Identity object 121018h 4 Identity object 01400h 0 Receive PDO communication parameter 0 21400h 1 Receive PDO communication parameter 0 $NODEID+0x2001400h 2 Receive PDO communication parameter 0 2551600h 0 Receive PDO mapping parameter 0 21600h 1 Receive PDO mapping parameter 0 0x604000101600h 2 Receive PDO mapping parameter 0 0x630001101800h 0 Transmit PDO communication parameter 0 51800h 1 Transmit PDO communication parameter 0 $NODEID+0x1801800h 2 Transmit PDO communication parameter 0 2551800h 3 Transmit PDO communication parameter 0 01800h 5 Event Timer 201A00h 0 Transmit PDO mapping parameter 0 31A00h 1 Transmit PDO mapping parameter 0 0x604100101A00h 2 Transmit PDO mapping parameter 0 0x630101101A00h 3 Transmit PDO mapping parameter 0 0x604e00101F80h NMT startup 02220h 0 J1939 Identification 62220h 1 J1939 Source Adress 1282220h 2 J1939 Industry Group 02220h 3 J1939 Vehicle System Instance 32220h 4 J1939 Vehicle System 12220h 5 J1939 Function Instance 22220h 6 J1939 Function 1292900h 0 supply voltage 32900h 1 supply voltage 1202900h 2 supply voltage 0x262900h 3 supply voltage 0xFF2901h 0 electronic temperature 32901h 1 electronic temperature 23



A. Appendix


Index Sub Name Default2901h 2 electronic temperature 32901h 3 electronic temperature 02951h 0 coil resistance A 12951h 1 coil resistance A 02952h 0 coil resistance B 12952h 1 coil resistance B 0

Table A.2.: Object Dictionary

A.4. SDO Index CANopen 408

Index. Sub Name Default2000h Node-ID 1272001h Baud rate 5922070h 0 Flowshare 32070h 1 Flowshare configuration 02070h 2 Flowshare group 02070h 3 Flowshare pump volume [1/10 lpm] 4002085h 0 Tracking error tolerance limit 52085h 1 Tracking error tolerance limit position 2652085h 2 Tracking error tolerance limit time [ms] for

POS_PLUS500

2085h 3 Tracking error tolerance limit overflow integrator posi-tion controller (grabs at changing setpoints)

0

2085h 4 Tracking error tolerance limit time [ms] forPOS_MINUS

400

2085h 5 elongation factor of RGL_CONT_LIM_TPOS per -20kelvin

5

2090h 0 Curve Form A Number of Entries 32090h 1 Curve Form A 02090h 2 Curve Form A Unit 962090h 3 Curve Form A Prefix 0xFD2091h 0 Curve Form B Number of Entries 32091h 1 Curve Form B 02091h 2 Curve Form B Unit 962091h 3 Curve Form B Prefix 0xFD2092h 0 Override A Number of Entries 32092h 1 Override A 10002092h 2 Override A Unit 962092h 3 Override A Prefix 0xFD



A. Appendix


Index Sub Name Default2093h 0 Override B Number of Entries 32093h 1 Override B 10002093h 2 Override B Unit 962093h 3 Override B Prefix 0xFD2100h 0 Nominal flow A number of entries 32100h 1 Nominal flow A value 2502100h 2 Nominal flow A unit 0x44422100h 3 Nominal flow A prefix 0xFF2101h 0 Nominal flow B number of entries 32101h 1 Nominal flow B value 2502101h 2 Nominal flow B unit 0x44422101h 3 Nominal flow B prefix 0xFF2110h Voltage supply lower limit 902111h Voltage supply upper limit 3002112h Self test max delay 1502113h 0 Power Reduction start temperature 32113h 1 Power Reduction start temperature 902113h 2 Power Reduction start temperature 0x2D2113h 3 Power Reduction start temperature 02114h 0 Power Reduction end temperature 32114h 1 Power Reduction end temperature 1202114h 2 Power Reduction end temperature 0x2D2114h 3 Power Reduction end temperature 02200h Setpoint timeout 100022F0h Output inverting sign 02300h 0 Vpoc demand value generator ramp acceleration2

(A-positive)3

2300h 1 Vpoc demand value generator ramp acceleration2(A-positive)

1


3


0xFD

2301h 0 Vpoc demand value generator ramp deceleration2(A-negative)

3


1


3


0xFD



A. Appendix


Index Sub Name Default2302h 0 Vpoc demand value generator ramp acceleration2

(B-positive)3

2302h 1 Vpoc demand value generator ramp acceleration2(B-positive)

1


3


0xFD

2303h 0 Vpoc demand value generator ramp deceleration2(B-negative)

3


1


3


0xFD

2400h 0 Section Info 22400h 1 Section Info 12400h 2 Section Info 12800h PDO setpoint format (HAWE/CiA-408) 16040h Device control word 06041h Device status word 06042h Device mode 16043h Device control mode 2604Eh Device error code 06300h 0 Vpoc setpoint 36300h 1 Vpoc setpoint 06300h 2 Vpoc setpoint 36300h 3 Vpoc setpoint 0xFD6301h 0 Vpoc actual value 36301h 1 Vpoc actual value 06301h 2 Vpoc actual value 966301h 3 Vpoc actual value 0xFD6330h Vpoc demand value generator ramp type 36332h 0 Vpoc demand value generator ramp acceleration (A-

positive)3

6332h 1 Vpoc demand value generator ramp acceleration (A-positive)

1

6332h 2 Vpoc demand value generator ramp acceleration (A-positive)

3



A. Appendix


Index Sub Name Default6332h 3 Vpoc demand value generator ramp acceleration (A-

positive)0xFD

6333h 0 Vpoc demand value generator ramp deceleration (A-negative)

3


1


3


0xFD

6335h 0 Vpoc demand value generator ramp acceleration (B-positive)

3


1


3


0xFD

6336h 0 Vpoc demand value generator ramp deceleration (B-negative)

3


1


3


0xFD

6360h Vpoc dither type 16361h 0 Vpoc dither amplitude 36361h 1 Vpoc dither amplitude 3506361h 2 Vpoc dither amplitude 966361h 3 Vpoc dither amplitude 0xFD6362h 0 Vpoc dither frequency 36362h 1 Vpoc dither frequency 106362h 2 Vpoc dither frequency 36362h 3 Vpoc dither frequency 0xFD

Table A.3.: Object Dictionary


A. Appendix








A. Appendix

Suggestions for improvement

Suggestions for improvement referring to: PSXCAN Manual

Ideas to improve this manual:

Mistakes in this manual:

Sent by:Name:Company Name:Adress:

Please send to: HAWE Hydraulik SEStreitfeldstrasse 25D-81673 MuenchenFax: +49 (0)89 379100-1538email: [email protected]


Bibliography

[1] CiA. CiA 408 v1.5.2 – CANopen Device profile for fluid power technology propor-tional valves and hydrostatic transmissions. Technical report, CAN in Automatione.V., Nuremberg, 1 2005. www.can-cia.org. 33, 34, 39, 41, 44, 62, 67, 68, 74

[2] CiA. CiA 305 v2.2.0 – CANopen Layer setting services. Technical report, CAN inAutomation e.V., Nuremberg, 8 2008. www.can-cia.org. 56

[3] CiA. CiA 401 v3.0.0 – CANopen Device profile for generic I/O modules. Technicalreport, CAN in Automation e.V., Nuremberg, 6 2008. www.can-cia.org. 39, 41

[4] CiA. CiA 301 v4.2.0 – CANopen Application layer and communication profile.Technical report, CAN in Automation e.V., Nuremberg, 2 2011. www.can-cia.org.33, 34, 36, 38, 39, 40, 41, 49, 54, 68

[5] Christian Dressler, Olga Fischer, Monika Mack, and Reiner Zitzmann. CANdic-tionary V4. CAN in Automation e.V., 5 2008. 195

[6] HAWE Hydraulik SE, Munich. CAN-Direktansteuerung für Proportional-Wege-schieber Typ PSL und PSV, 2009. www.hawe.de. 21

[7] HAWE Hydraulik SE, Munich. Proportional-Wegeschieber Typ PSL und PSV, 2009.www.hawe.de. 13, 18, 20

[8] HAWE Hydraulik SE. CAN-knots parameter setting sheet. TypeMan+, B 7700 CANInstallation, 3 2011. www.hawe.de. 96, 101

[9] ISO/IEC. ISO/IEC 7498-1:1994 Information technology – Open Systems Intercon-nection – Basic Reference Model: The Basic Model. Technical report, ISO/IECCopyright Office, 6 1996. 29

[10] Olaf Pfeiffer, Andrew Ayre, and Christian Keydel. Embedded Networking with Canand Canopen. Copperhill Media Corporation, 4 2008. 13, 29, 38

[11] SAE. SAE Truck and Bus Control Communications Network Standards Manual -2007 Edition. Society of Automotive Engineers, 2007. 34

[12] Jonathan Swift. Gulliver’s Travels and Selected Writings in Prose and Verse, chap-ter Travels into Several Remote Nations of the World in Four Parts. By LemuelGulliver, First a Surgeon, and then a Captain of Several Ships. J. Hayward, NewYork, 1990. 49

[13] VDMA. Profile Fluid Power Technology – Proportional, Valves and HydrostaticTransmissions, Version 1.6. Technical report, Verband Deutscher Maschinen- undAnlagenbau e.V., Frankfurt/Main, 2009. www.vdma.org. 48


Bibliography

[14] Wilfried Voss. A Comprehensible Guide to Controller Area Network. CopperhillMedia Corporation, 8 2005. 13, 29, 38

[15] Wilfried Voss. A Comprehensible Guide to J1939. Copperhill Media Corporation, 62008. 34

[16] Wikipedia. Byte-Reihenfolge. www.wikipedia.de, 2009. 49

[17] Holger Zeltwanger (Hrsg). CANopen - Das standardisierte, eingebettete Netzwerk.VDE-Verlag, 7 2008. 13, 38


Glossary

Parts of this glossary were made with the help of the CiA CANdictionary [5].

application profile

Application profiles define all communication objects and application objects in alldevices of a network.

bit time

Duration of one bit to get from the transmitter to the receiver.

boot-up message

CANopen communication service transmitted whenever a node enters the pre-operational state after initialization.

bus

Topology of a communication network, where all nodes are reached by passivelinks. This allows transmission in both directions.

bus arbitration

If at the very same moment several nodes try to access the bus, an arbitrationprocess is necessary to control which node may transmit while the other nodeshave to delay their transmission. The bus arbitration process used in CAN protocolis CMSA/CD (Carrier Sense Multiple Access/Collision Detection) with AMP (Ar-bitration on Message Priority). This allows bus arbitration without destruction ofmessages.

CAN identifier

The CAN identifier is the main part of the arbitration field of a CAN data frame orCAN remote frame. It comprises 11 bit (base frame format) or 29 bit (extendedframe format) and indicates certain information uniquely in the network. The CANidentifier value determines implicitly the priority for the bus arbitration.

CAN in Automation (CiA)

The international users’ and manufacturers’ group founded in 1992 promotes CANand supports CAN based higher-layer protocols (www.can-cia.org).

CAN node

Synonym for CAN device.


Glossary

CANopen

Family of profiles for embedded networking in industrial machinery, medical equip-ment, building automation (e.g. lift control systems, electronically controlled doors,integrated room control systems), railways, maritime electronics, truck-based su-perstructures, off-highway and off-road vehicles, etc.

CAN_HIGH

Indicates the CAN_HIGH line in CAN-based networks. The CAN_HIGH line of ISO11898-2 compliant transceiver is in recessive state on 2,5 V and in dominant stateon 3,5 V.

CAN_LOW

Indicates the CAN_LOW line in CAN based networks. The CAN_LOW line of ISO11898-2 compliant transceiver is in recessive state on 2,5 V and in dominant stateon 1,5 V.

CiA-301

The CANopen application layer and communication profile specification covers thefunctionality of CANopen NMT slave devices.

CiA-303

Recommendation for CANopen cabling and connector pin assignments, coding ofprefixes and SI-units as well as LED usage.

CiA-401

The CANopen device profile for generic I/O modules covers the definition of digitaland analog input and output devices.

CiA-408

The CANopen device profile for hydraulic controllers and proportional valves iscompliant to the bus-independent VDMA device profile fluid power technology –proportional valves and hydrostatic transmission.

COB-ID

The COB-ID is the object specifying the CAN identifier and additional parameters(valid/- invalid bit, remote frame support bit, frame format bit) for the relatedcommunication object.

communication object

A communication object consists of one or more CAN messages with a specificfunctionality, e.g. PDO, SDO, emergency, Time, or Error Control.

communication profile

A communication profile defines the content of communication objects such asemergency, Time, Sync, Heartbeat, NMT, etc. in CANopen.


Glossary

CRC

See cyclic redundancy check.

cyclic redundancy check

The cyclic redundancy check (CRC) is performed by a polynomial implemented inthe transmitting as well as in the receiving CAN modules. The cyclic redundancycheck in the CAN data frame and CAN remote frame is a number derived from,and stored or transmitted with, a block of data in order to detect corruption. Byrecalculating the CRC and comparing it to the value originally transmitted, thereceiver can detect some types of transmission errors.

data frame

The CAN data frame carries data from a producer to one or more consumers. Itconsists of the start of frame bit, the arbitration field, the control field, the data field,the CRC field, the acknowledge field, the end of frame field.

data type

Object attribute in CANopen and DeviceNet defining the format, e.g. Unsigned8,Integer16, Boolean, etc.

device profile

A device profile defines the device-specific application data and communication ca-pability based on the related higher-layer protocol. For more complex devices theseprofiles may provide a finite state automaton (FSA), which enables standardizeddevice control.

DeviceNet

CAN based higher-layer protocol and device profiles definition. DeviceNet wasdesigned for factory automation and provides a well defined CAN physical layerin order to achieve a high off-the-shelf plug-and-play capability. The DeviceNetspecification is maintained by the ODVA (www.odva.org) non-profit organization.

EDS

See electronic data sheet.

electronic data sheet

Electronic data sheets describe the functionality of a device in a standardizedmanner. CANopen and DeviceNet use different EDS formats.

emergency

Pre-defined communication service in CANopen mapped into a single 8-byte dataframe containing a 2-byte standardized error code, the 1-byte error register, and5-byte manufacturer-specific information. It is used to communicate device andapplication failures.


Glossary

error code

CANopen specifies standardized error codes transmitted in emergency messages.

extended frame format

The extended CAN frame format uses the 29-bit identifiers in data frames as wellas in remote frames.

frame

Data link protocol entity specifying the arrangement and meaning of bits or bitfields in the sequence of transfer.

Heartbeat

CANopen and DeviceNet use the Heartbeat message to indicate that a node isstill alive. This message is transmitted periodically.

heartbeat consumer time

The heartbeat consumer time defines the time when a node is regarded as nolonger alive due to a missing Heartbeat message.

higher-layer protocol

Higher-layer protocols define communication protocols compliant to the transportlayer, session, presentation, or application layer as specified in the OSI referencemodel.

Identification Flashing

Permanent switching between red and green of the diagnosis LED, used to identifythe actual activated node physically..

identifier

Generally the identifier corresponds to the ID of a CAN. See CAN identifier.

index

16-bit address to access information in the CANopen object dictionary; for arrayand records the address is extended by an 8-bit sub-index.

ISO 11783

International standard defining the CAN based application profile used in agricul-ture and forestry machines and vehicles. It is based on the J1939 applicationprofile.


Glossary

J1939

The application profile defined by SAE (www.sae.org) specifies the in-vehiclecommunication in trucks and buses. It defines the communication services as wellas the signals including the mapping into CAN data frames by means of PGNs(parameter group numbers).

life guarding

Method in CAL and CANopen to detect that the NMT master does not guard theNMT slave anymore. This is part of the error control mechanisms.

line topology

Networks, where all nodes are connected directly to one bus line. CAN networksuse theoretically just line topology without any stub cable. However in practice youfind tree and star topologies as well.

message

A message in CAN may be a data frame or remote frame.

network management

Entity responsible for the network boot-up procedure and the optional configurationof nodes. It also may include node-supervising functions such as Node Guarding.

NMT

Abbreviation for network management in CAL and CANopen; See network man-agement.

NMT master

The NMT master device performs the network management by means of transmit-ting the NMT message. With this message, it controls the state machines of allconnected NMT slave devices.

NMT slave

The NMT slaves receive the NMT message, which contains commands for theNMT state machine implemented in CAL and CANopen devices.

node

Assembly, linked to the CAN network, capable of communicating across the networkaccording to the CAN protocols.

Node Guarding

Mechanism used in CANopen and CAL to detect bus-off or disconnected devices,which is part of the error control mechanisms. The NMT master sends a remoteframe to the NMT slave that is answered by the corresponding error controlmessage.


Glossary

node-ID

Unique identifier for a device required by different CAN based higher-layer protocolsin order to assign CAN identifiers to this device, e.g. in CANopen or DeviceNet.Using the pre-defined connection sets of CANopen or DeviceNet, the node-ID ispart of the CAN identifier.

object dictionary

The object dictionary is the heart of any CANopen device. It enables access to alldata types used in the device, to the communication parameters, as well as to theprocess data and configuration parameters.

OSI reference model

Layered communication model defining seven layers: physical, data link, network,transport, session, presentation, and application layer. In CAN based networksnormally just physical, data link, and application layer are implemented.

parameter group number

The parameter group number (PGN) identifies uniquely the parameter group (PG).The PGN is mapped into the 29-bit identifier.

PDO

See process data object.

PGN

See parameter group number.

pre-operational state

Part of the NMT slave state machine. In the NMT pre-operational state no CAN-open PDO communication is allowed.

priority

Attribute to a frame controlling its ranking during arbitration. In CAN data framesand remote frames, the identifier (ID) gives the priority. The lower the ID, the higheris the priority.

producer

In CAN networks a transmitter of messages is called a producer.

receive PDO

The receive process data object (RPDO) is a PDO that is received by a CANopendevice.


Glossary

remote frame

With a remote frame another node is requested to transmit the corresponding dataframe identified by the very same identifier. The remote frame’s DLC has the valueof the corresponding data frame DLC. The data field of the remote frame has alength of 0 byte.

remote transmission request

Bit in the arbitration field indicating if the frame is a remote frame (recessive value)or a data frame (dominant value).

reset

A CAN controller is reset by a command (may be hard-wired). Before the CANcontroller transits back to error active state, it has to detect 128 by 11 consecutiverecessive bit times.

RPDO

See receive PDO.

RTR

See remote transmission request.

SDO

See service data object.

service data object

The service data object (SDO) is a confirmed communication service that providesaccess to all entries in the CANopen object dictionary. An SDO uses two 8-byteCAN messages with different identifiers. The SDO may transmit segmented anyamount of data. Each segment (segmented SDO) or a number of segments isconfirmed (SDO block transfer).

SI-unit

International system of units for physical values as specified in ISO 1000:1983.

star topology

In some passenger cars, CAN networks are installed in a star topology terminatingthe network in the center of the star.

sub-index

8-bit sub-address to access the sub-objects of arrays and records in a CANopenobject dictionary.

termination resistor

In CAN high-speed networks with line topology, both ends are terminated withresistors (120 Ω) in order to suppress reflections.


Glossary

transmitter

A node from which a data frame or a remote frame originates; this node remainstransmitter until the bus is idle again or until the node loses arbitration.


Index

Activation, 73Address Field, 36Address Space, 43Advantages, 18

Bus Termination, 31

CAN, 29, 30CAN Basis Information, 29CAN Data Frame, 35CAN Hardware, 30CAN ID, 36CAN Interface, 29CAN Master, 39CAN Signal Lines, 30CAN Slave, 39CAN Telegram, 35CAN_HIGH, 30CAN_LOW, 30CANopen, 34, 38CANopen Standard Addressing, 43CiA, 38CiA-301, 38, 39CiA-401, 39, 62, 102CiA-408, 39, 67, 102COB-ID, 36, 42, 43CoDeSys, 35Communication Procedure, 72Communication Startup, 72Communication State Machine, 54, 68Concept CANopen, 39CSM, 54, 68Current Consumption, 19

Data Objects, 40DCW, 71, 74Device Control Word, 71Device Profile, 39Device State Machine, 68, 69Device Status Word, 71

DSM, 68DSM State Transitions, 72DSW, 71, 75

EDS, 41, 128Electronic Data Sheet, 27, 35, 38, 128EMC, 31EMCY, 40, 52Emergency Objects, 40, 52Environmental Conditions, 20

Galvanic Separation, 30

Heartbeat, 43, 66, 87

Index, 41, 51ISO 11898-2, 30

J1939, 34, 93

Layer Setting Services, 56Line Shielding for Signal Lines, 31LSS, 56

Net Topology, 31Network Management, 40Network Management Telegrams, 55NMT, 40, 43, 53, 55NMT Startup Command, 56Node Guarding, 43, 44, 66Node-ID, 36, 42, 43

Object Dictionary, 41OSI Reference Model, 29

Parameters, Electric, 19Parameters, Hydraulic, 20PDO, 40, 43, 90Process Data Object, 40Protocol Philosophies, 33Protocol Version, 39Protocols, 33


Index

RPDO, 74RXPDO, 74

SDO, 40, 43, 50SDO Transmission, 50Self Test, 104Service Data Object, 40Setpoint Message, 63Subindex, 41, 51SYNC, 50Synchronous Transmission, 50

Tap Lines, 31Telegram Lenght, 42Telegram Types, 40Termination Resistor, 31TPDO, 75TXPDO, 75


Disclaimer

Information in this document is provided solely in connection with HAWE products.HAWE Hydraulik SE and its subsidiaries ("HAWE") reserve the right to make changes,corrections, modifications or improvements, to this document, and the products andservices described herein at any time, without notice.

All HAWE products are sold pursuant to HAWE’s terms and conditions of sale.Purchasers are solely responsible for the choice, selection and use of the HAWE productsand services described herein, and HAWE assumes no liability whatsoever relating tothe choice, selection or use of the HAWE products and services described herein.

No license, express or implied, by estoppel or otherwise, to any intellectual propertyrights is granted under this document. If any part of this document refers to any thirdparty products or services it shall not be deemed a license grant by HAWE for the use ofsuch third party products or services, or any intellectual property contained therein orconsidered as a warranty covering the use in any manner whatsoever of such third partyproducts or services or any intellectual property contained therein.

UNLESS OTHERWISE SET FORTH IN HAWE’S TERMS AND CONDITIONS OF SALEHAWE DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY WITH RESPECT TOTHE USE AND/OR SALE OF HAWE PRODUCTS INCLUDING WITHOUT LIMITATIONIMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION),OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUALPROPERTY RIGHT.

UNLESS EXPRESSLY APPROVED IN WRITING BY AN AUTHORIZE REPRESEN-TATIVE OF HAWE, HAWE PRODUCTS ARE NOT DESIGNED, AUTHORIZED ORWARRANTED FOR USE IN MILITARY, AIR CRAFT, SPACE, LIFE SAVING, OR LIFESUSTAINING APPLICATIONS, NOR IN PRODUCTS OR SYSTEMS, WHERE FAIL-URE OR MALFUNCTION MAY RESULT IN PERSONAL INJURY, DEATH, OR SEVEREPROPERTY OR ENVIRONMENTAL DAMAGE.

Information in this document supersedes and replaces all information previously supplied.


Product Documentation PSL/PSV CAN Valve Actuationdownloads.hawe.com/7/7/B7700_CAN-Manual-en.pdf ·...

Documents

Transcript of Product Documentation PSL/PSV CAN Valve Actuationdownloads.hawe.com/7/7/B7700_CAN-Manual-en.pdf ·...