E531827 00E CAN Fieldbus

Structure and function of the field bus 1 communication protocol

E 531 827 / 00 E

Connecting third-party devicesto the

MCS-5 FIELD BUS 1Documentation for design engineers

assuring you

certification:

Quality assurance in design/development,production, installation and service

Guide Page IFRIEDRICHSHAFEN

E 531 827 / 00 E 04.99

Table of contents

Table of contents I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abbreviations IV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Preface Contents and target audience of this document 3. . . . . . . . . . . . . . . . . . .

1 System overview 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1 Structure of the MCS-5 system 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Structure of the communication protocol in layer 1 5. . . . . . . . . . . . . . . . . . . .

1.2.1 Brief description of the attributes in the communication protocol 5. . . . . . . . 1.3 Structure of the communication protocol in layer 2 6. . . . . . . . . . . . . . . . . . . .

1.3.1 Data type definition in layer 2 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1.1 Data type Measuring point 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 Device data and project data 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Device data 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Project data 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Description of the field bus 1 protocol 10. . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Measuring point transmission 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 Services and transmission modes 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1.1 Cycle times 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1.2 Cycle times for third-party devices 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1.3 Delta value generation 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1.4 Multiplex variable (MUX) 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 PDU measuring point data format 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2.1 Assignment of data field byte 6 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2.2 Possible assignments of data field byte 2, 3, 4 and 5 11. . . . . . . . . . . . . . . . . . 2.1.3 Measuring point normalization 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3.1 Measuring point normalization for third-party devices 12. . . . . . . . . . . . . . . . . . 2.1.4 Sensor Defect handling 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4.1 Sensor Defect for third-party devices 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Missing Data handling 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5.1 Missing Data for third-party devices receiving 13. . . . . . . . . . . . . . . . . . . . . 2.1.5.2 Missing Data for third-party devices transmitting 13. . . . . . . . . . . . . . . . . . .

GuideFRIEDRICHSHAFEN

Page II

E 531 827 / 00 E 04.99

Table of contents (cont.)

2.2 Network monitoring NMT 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1 Monitoring of interfaces and devices 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1.1 Node address 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1.2 NMT Alive PDU 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1.3 COB ID for network monitoring 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2 Data format of the NMT Alive PDU 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Brief description of the attributes in the NMT Alive PDU data format 16. . . . 2.2.3.1 Meaning and assignment of the attributes 16. . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.4 Field bus 1 redundancy and redundancy switching 17. . . . . . . . . . . . . . . . . . . . 2.2.4.1 Redundancy 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4.2 Redundancy switching 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4.3 Criteria for switching from the default interface to the

redundant interface 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Service mode: Download 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.1 Downloading project data 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Data transmission saving 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Download criterium: Checking data validity 18. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Client consistency check of project data 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Overview of download protocol services 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6 Data format of the download protocol services 20. . . . . . . . . . . . . . . . . . . . . . . . 2.3.6.1 Download PU Data Enable Request 20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6.2 Download PU Data Request 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6.3 Download PU Data Response 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6.4 Download PU Data 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.7 Operating states of the client 22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.7.1 Bootup mode 22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.7.2 Download mode 22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.7.3 Measuring point transmission mode 23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.7.4 Overview of operating states and operating state transitions in

tabular form 23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.8 Download sequence control flow chart from the client perspective 24. . . . . . .

Guide Page IIIFRIEDRICHSHAFEN

E 531 827 / 00 E 04.99

Table of contents (cont.)

3 Project data for third-party devices 26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Description of project data structure 26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Structure of the project data module 27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Description of the segments in the project data module

and their attributes 28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.1 Segment 1: OS-9 module header (length: 34 bytes) 28. . . . . . . . . . . . . . . . . . . 3.1.2.2 Segment 2: User data length (length: 4 bytes) 28. . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.3 Segment 3: User data header part 1 (length: 16 bytes) 29. . . . . . . . . . . . . . . . 3.1.2.4 Segment 4: User data header part 2 (length: 8 bytes) 30. . . . . . . . . . . . . . . . . 3.1.2.5 Segment 5: Measuring point attributes (length: n x 16 bytes,

whereby n is max. 128) 30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.6 Segment 6: Normalization tables (length specific) 31. . . . . . . . . . . . . . . . . . . . . 3.1.2.7 Segment 7: Checksum (length: 2 bytes) 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.8 Segment 8: Filler bytes 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.9 Segment 9: OS-9-CRC (length: 4 bytes) 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Description of the normalization tables 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.1 Structure of the normalization tables 32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1 Normalization table representing data direction = 0 32. . . . . . . . . . . . . . . . . . . . 3.2.1.2 Normalization table representing data direction = 1 33. . . . . . . . . . . . . . . . . . . . 3.2.1.3 Influence of data direction on the X/Y values 33. . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.4 Normalization method 34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.5 Linear interpolation of the values 34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Structure of the normalization tables 35. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Page IV

E 531 827 / 00 E 04.99

Abbreviations

Ack field Ack field (used for positive confirmation of receipt from any CAN bus noderegardless of the station concerned)

CAN Controller Area Network (bus standard)COB CAN Object (CAN telegram transmitted on the CAN bus)COB ID CAN Object Identifier (part of the CAN telegram which determines object

priority during transmission)CRC Test sequence for detecting faults during data transmission

(length: 15 bit CRC + 1 bit CRC delimiter)

DLC Data Length Code Field (data length in bytes (Data Field));(max. adjustable length: 8 bytes)

EOF End Of Frame (each data and data request telegram is terminated by a bitsequence comprising 7 recessive bits)

FB 1 Field bus 1

I/O device Input/Output device (receiving and transmitting device)

ms MillisecondsMUX Multiplex value (first byte of the CAN data field required for unambiguous

process data identification)

NMT Network Management (part of the communication protocol, for networkmonitoring, performs network services)

PB Process busPDU Protocol Data Unit (data field of the CAN telegram)PLC Programmable Logic ControllerPLC Node Process bus node address of the associated PLCPU Projektierungsumgebung, project implementation environment

(for the MCS-5 field bus 1)

RTR Remote Transmission Request

Guide Page VFRIEDRICHSHAFEN

E 531 827 / 00 E 04.99

Abbreviations (cont.)

sec SecondsSDF Sensor Defect (special bit designation for detecting sensor failure)SW_ED_1 First information block concerning software editionSW_ED_2 Second information block concerning software editionSW_MOD Project data modification statusSW_REV Project data revision statusSW_TYPE Software for a specific type of deviceSW_VAR Software variant


Page VI

E 531 827 / 00 E 04.99

(This page intentionally blank)

System overview Chapter 1Page 1FRIEDRICHSHAFEN

E 531 827 / 00 E 05.99

Preface

Contents and target audience of this document

This manual is divided into three chapters.

Chapters 1 and 2 are intended for all personnel wishing to familiarize themselves with thestructure and function of the MCS-5 field bus 1 protocol.

Chapter 3 is intended for design engineers developing third-party devices. A third-partydevice is a device produced by another manufacturer which exchanges process data withthe MCS-5 system in accordance with the field bus 1 protocol.

Special project data must be created for the third-party device to allow it to participate incommunication on field bus 1. MTU plant project engineers have a graphic project imple-mentation environment at their disposal for this. The plant project engineer also integratesthe third-party device in the MCS-5 plant by agreement with the manufacturer of the third-party device. Project data for the third-party device are created as a result.

Chapter 3 describes the structure of the project data and the project data module in detail.

Chapter 12Page System overviewFRIEDRICHSHAFEN

E 531 827 / 00 E 05.99



E 531 827 / 00 E 05.99

Chapter 1

System overview


E 531 827 / 00 E 05.99

1 System overview

This chapter provides an overview of the structure of the Entire MCS-5 system Field bus 1 communication protocol

1.1 Structure of the MCS-5 system

A differentiation is made between Management level Field automation level

in the MTU Monitoring and Control System MCS-5 automation system.

A maximum of 31 devices can be connected to field bus 1 in the MCS-5 system (1 PLC +30 MTU I/O devices or third-party devices). The figure below illustrates the structure of anMCS-5 system:

Management Computer Unit

Process bus (redundant)

PLC PLC

Field bus 1 Field bus 1

MTUI/O device

MTUI/O device

MTUI/O device

MTUI/O device

MTUcoupler

MTU EngineControl

Unit

Management level

Field automation level

Third-partydevice

Fig. 1: Structure of an MCS-5 system


E 531 827 / 00 E 05.99

1.2 Structure of the communication protocol in layer 1

A communication protocol has been especially developed for the MCS-5 system. It corres-ponds to the ISO/OSI layer model whereby only layers 1, 2 and 7 are used. Parts of theother layers are included in layer 7.

Standard CAN frames are used exclusively in communication layer 1. The CAN telegramfor layer 1 has the following structure:

DLCfieldRTR

CRCfield

Ackfield

EOFfield

Startbit COB ID Data field

Fig. 2: Structure of the CAN telegram in layer 1

Some parts of this telegram, particularly the data field (field 5) are described in thismanual in more detail.

1.2.1 Brief description of the attributes in the communication protocol

Start bit Start bit (dominant bit, identifies the start of the telegram)

COB ID CAN Object Identifier (11 bits)

RTR Remote Transmission Request (1 bit)Always set to zero

DLC Data Length Code fieldLength (in bytes) of the user data (Data field); max. adjustable length: 8 bytes

Data field User dataThe length of the data field is: 0 to 8 bytes

CRC Test sequence to detect faults during data transmission,length: 15 bits CRC + 1 bit CRC delimiter

Ack field Ack field Used for positive confirmation of receipt from any CAN bus node regard-less of the station concerned

EOF End Of FrameEach data and data request telegram is terminated by a bit sequence of 7recessive bits.


E 531 827 / 00 E 05.99

1.3 Structure of the communication protocol in layer 2

Only the inner blocks of the CAN telegram described are visible in layer 2: COB ID RTR DLC Data field

The start and end blocks (start bit or Ack field and EOF) are only taken into considerationin layer 1.

1.3.1 Data type definition in layer 2

Communication objects are divided into various types of data in layer 2. A type of data isdescribed by:

Assignment to a fixed COB ID value range.Overall value range: 0 to 2031

Data length definition DLC of 8 bytes Structural evaluation of the data field

Various services are supported in communication depending on the type of datatransmitted.

1.3.1.1 Data type Measuring point

Measuring point is a possible data type. This data type is used to transmit process data.Measuring points are transmitted with the WRITE_REQ service. WRITE_REQ is acyclic, non-confirmed service.


E 531 827 / 00 E 05.99

1.4 Device data and project data

The individual devices require several definitions to fulfill their communication tasks.Definitiions which do not depend on a particular plant are largely implemented in the soft-ware. Other definitions must be inparted to the devices during initial start-up. A differentia-tion is made between device data and project data.

1.4.1 Device data

Device data are device settings which are required to allow the device to execute simplebasic functions. When the device data have been set, the device can establish contactwith other devices or service mode can be started.

Device data are e.g. the CAN baud rate and the node address. These data are stored in anon-volatile memory during initial start-up.

1.4.2 Project data

All other settings required by the FB 1 device to participate in network operations andcommunication are referred to as project data.

Device and project data are defined during the project implementation phase of theMCS-5 plant. The plant project engineer has a graphic project implementation environ-ment at his disposal for this.

Device data are defined on completion of project implementation. The project implementa-tion environment automatically generates the project data for the individual devices.


E 531 827 / 00 E 05.99


Protocol description Chapter 2Page 9FRIEDRICHSHAFEN

E 531 827 / 00 E 05.99

Chapter 2

Description of the field bus 1 protocol

Chapter 210Page Protocol descriptionFRIEDRICHSHAFEN

E 531 827 / 00 E 05.99

2 Description of the field bus 1 protocol

2.1 Measuring point transmission

2.1.1 Services and transmission modes

Measuring points are transmitted in the field automation level with the WRITE_REQservice. WRITE_REQ is a non-confirmed service. The receiver need not acknowledgereceipt of the measuring point to the transmitter.

2.1.1.1 Cycle times

The FB 1 device transmits the measuring points cyclically. The cycle times for each indivi-dual measuring point can be selected as a multiple of the basic cycle (200 ms). The cycletimes are defined for the device by the project data.

2.1.1.2 Cycle times for third-party devices

A cycle time of 400 ms is set for third-party devices for reasons of simplicity. It is notnecessary to set the date for each measuring point to be transmitted in the project data.

2.1.1.3 Delta value generation

The transmitting devices generate a delta value for the measuring points to relieve thebus: Transmission only takes place within the set cycle when the value of a measuringpoint changes.

If a value does not change within 20 sec, the measuring point is transmitted nevertheless.This superordinate transmission cycle of 20 sec allows Missing Data to be detected inthe receiving devices.

Refer to chap. 2.1.5 Missing Data handling for details.

2.1.1.4 Multiplex variable (MUX)

The first user data byte is used as a multiplex variable (see first byte of data field segmentenlargement in fig. 3). The multiplex variable and COB ID together identify each measuring point unambiguouslythroughout the system.


E 531 827 / 00 E 05.99

2.1.2 PDU measuring point data format

2.1.2.1 Assignment of data field byte 6

The figure below illustrates the communication protocol (see also fig. 2) with two segmentenlargements.

The first segment enlargement shows the structure of the data field for the PDU measu-ring point data format.

The second segment enlargement shows the bit assignment of the status byte (byteno. 6).

Startbit COB ID

RTR DLCfield Data field

CRCfieldfield

Ackfield

EOFfield

ByteContents

BitContents

MUX Analog/binary measured value Status

SDF bit

Fig. 3: Bit assignment of the status byte (byte no. 6)

2.1.2.2 Possible assignments of data field byte 2, 3, 4 and 5

The table below shows the possible data formats of the PDU measuring points (byte 2,byte 3, byte 4 and byte 5):

Possible values DesignationAnalog measuring point Normalized measured value

SDF_VALUEMD VALUE

Binary measuring point TRUE = 1FALSE = 0SDF_VALUEMD VALUE

Sensor Defect SDF_VALUE: 2147483647 (Hex: 0x80000001)Missing Data MD_VALUE: 2147483647 (Hex: 0x7FFFFFFF)

Tab. 1: PDU measuring point data formats


E 531 827 / 00 E 05.99

2.1.3 Measuring point normalization

All measuring points on FB 1 are transmitted with a normalized base. A base unit isdefined for each physical measured variable. For example, each pressure is transmittedas a multiple of the base unit 0.01 mbar.

The electrical sensor values are transmitted in physical base units. The normalizationinformation is provided for the MCS-5 acquisition devices in the project data.

The normalization information is stored in curve tables. The acquisition device performsnormalization as a linear interpolation on the basis of the given points of the curve. Referto chap. 3.2.1 Structure of the normalization tables for further information about curvetables.

2.1.3.1 Measuring point normalization for third-party devices

Third-party devices require information to convert the MCS-5 measuring point into themeasuring point normalized for the third-party device and to convert the measuring pointnormalized for the third-party device into the MCS-5 measuring point. Normalization isalso described on the basis of curve tables in this case.

2.1.4 Sensor Defect handling

The MCS-5 acquisition devices perform sensor defect handling. On detecting the sensordefect,

The measuring point is set to SDF_VALUE (see tab. 1) and The SDF bit is set in the status byte (see fig. 3)

The SDF bit is evaluated in the PLC to allow the sensor defect to be displayed by themanagement computer. The information about the sensor defect is passed on in the PLC.This takes place during process data processing. All measuring points derived from anSDF_VALUE measuring point are also set to SDF_VALUE. The SDF bit is not passedon.

2.1.4.1 Sensor Defect for third-party devices

A third-party device informs the MCS-5 system about a sensor defect by setting theexpected measuring point to SDF_VALUE. The SDF bit in the status byte (data field byteno. 6) is not set.


E 531 827 / 00 E 05.99

2.1.5 Missing Data handling

As described in chap. 2.1.1.3 under Delta value generation, all measuring points aretransmitted at least every 20 sec. The FB 1 devices detect Missing Data from the mea-suring points on the basis of delta value generation. A receiving monitoring timeout of 30sec is applied to each expected measuring point. The measuring point value is set toMD_Value (byte 2, byte 3, byte 4 and byte 5) when this timeout has expired.

2.1.5.1 Missing Data for third-party devices receiving

The third-party device checks measuring point reception by a 30 sec monitoring timeout.

2.1.5.2 Missing Data for third-party devices transmitting

If a component responsible for acquiring a measuring point fails in the third-party device,the third-party device transmits this measuring point with MD_VALUE.

The third-party device measuring points in the remaining FB 1 devices are set toMD_VALUE should the third-party device fail completely.


E 531 827 / 00 E 05.99

2.2 Network monitoring NMT

2.2.1 Monitoring of interfaces and devices

2.2.1.1 Node address

Each FB 1 device has its own network management NMT. NMT monitors network opera-tion of its own and other devices. The CAN interfaces are monitored starting in its owndevice. Any faults which occur are rectified automatically. Each FB 1 device has an unam-biguous node address on the FB 1 line. The node address is a part of the device data.

The number of FB 1 devices on one line is restricted to 31. The devices are assignedFB 1 addresses 1 31. The individual FB 1 device does not know the exact network confi-guration and therefore monitors all 30 other possible devices. The PLC always has nodeaddress 1.

2.2.1.2 NMT Alive PDU

The NMT Alive PDU is a special COB (see fig. 2 Structure of the communication proto-col), with which each FB 1 device signals its presence in the network. The NMT AlivePDU is transmitted cyclically every 500 ms. Each FB 1 device can thus check any otherFB 1 device.

The timeout for the NMT Alive PDU is 1.2 sec. When FB 1 is of a redundant design, theNMT Alive PDUs are transmitted on both interfaces. The FB 1 devices are monitoredseparately at both interfaces.


E 531 827 / 00 E 05.99

2.2.1.3 COB ID for network monitoring

As the individual FB 1 devices transmit their NMT Alive PDUs asynchronously, eachdevice requires an unambiguous COB. This is achieved by assigning a device-specificCOB ID. The COB ID number is determined on the basis of the FB 1 node address.

The COB ID number is calculated in accordance with the formula: 1980 (NMT constant) +

The process bus node address of the associated PLC is also included in the data field ofthis COB. This means that a network error is detected if two FB 1 devices with the sameFB 1 node address (but located in different FB 1 lines) are relocated.

Other data field elements of this COB identify the device and the device software used.These data are provided by the NMT for other applications in the device, they are notrequired for network monitoring.

The PLC signals failure of FB 1 devices to the management computer. The PLC, in con-trast to the other FB 1 devices, knows the precise network configuration.


E 531 827 / 00 E 05.99

2.2.2 Data format of the NMT Alive PDU

The segment from the data field (see fig. 2 Structure of the CAN telegram in layer 1)shown below illustrates the detailed structure of the data field for the NMT Alive PDUdata format.

The first data byte of the user data is always used as multiplex variable (MUX).

1SPS NODE

2SW TYP

3SW VAR

4SW ED 1

5SW ED 2

6SW REV

7SW MOD

8MUX

ByteContents

Fig. 4: Structure of the data field for the NMT Alive PDU data format

2.2.3 Brief description of the attributes in the NMT Alive PDU data format

2.2.3.1 Meaning and assignment of the attributes

MUX Multiplex variable. The MUX is set to 0.

SPS node Process bus node address of the associated PLC. The node address isindicated in the project data.

SW_TYPE Identification of the device with the software (SW). SW_TYPE is defined by MTU. The definition is indicated in the projectdata.

SW version: SW_VAR: Software variant SW_ED_1: Software edition, first information block concerning software

edition (full information: SW_ED_1_ED_2 ) SW_ED_2: Software edition, second information block concerning

software edition (full information: SW_ED_1_ED_2 ) SW_REV: Project data revision status SW_MOD: Project data modification status

The information concerning the software version is provided by the third-party manufactu-rer. This makes it possible to clearly identify third-party software in other devices.

Refer to the project data for project data identification.


E 531 827 / 00 E 05.99

2.2.4 Field bus 1 redundancy and redundancy switching

2.2.4.1 Redundancy

On redundant versions, all devices are connected both to the default interface and theredundant interface. The network nodes for the individual devices are monitored separa-tely at both interfaces. Each device counts the active devices at the interface concerned.Active devices are devices from which the NMT Alive PDUs are received on time.

The information about whether a redundant interface is provided is imparted to the FB 1devices as a datum in the project data.

2.2.4.2 Redundancy switching

The interface to which measuring points are transmitted is determined in the networknode monitoring cycle (1.2 sec). This is the interface at which more active devices aredetermined at this point in time. It is also referred to as the active interface. Measuringpoints are only transmitted at the active interface.

All devices appear as masters when redundancy is switched. They decide independentlyabout when interface switching is to take place. It takes a little time until all remainingdevices transmit at the same interface should one or several devices fail. This has noinfluence on the response of the system in operation.

This redundancy switching applies to transmission only.A device always receives measuring points at both interfaces regardless of which inter-face is currently operating as the active interface.

2.2.4.3 Criteria for switching from the default interface to the redundant interface

Two states are possible as a result of network monitoring regarding interface monitoring: The number of active devices at the default interface is greater or equal to the

number of active devices at the redundant interface.The default interface is defined as the active interface in this case.

The number of active devices at the default interface is less than the number ofactive devices at the redundant interface.The redundant interface is defined as the active interface in this case.


E 531 827 / 00 E 05.99

2.3 Service mode: Download

2.3.1 Downloading project data

The memory of the PLC stores all project data of the associated FB 1 devices. The dataare non-volatile. Before an FB 1 device can transmit its measuring points actively on theFB 1, it must check that it has the currently valid project data.

A special download protocol is used for this test and for downloading project data betweenPLC (data server) and FB 1 device (client).

The download protocol is only supported at the default interface when FB 1 is of redun-dant design.

2.3.2 Data transmission saving

Correct transmission of a single CAN telegram is saved in layer 1 in the CAN controller.

A 16-bit checksum of the project data is generated to check that all CAN telegrams havebeen received. The checksum is calculated by adding the individual byte values of theproject data. The checksum is transmitted directly after the project data.

2.3.3 Download criterium: Checking data validity

Project data is downloaded by the PLC as required.Downloading is necessary when project data varies between client and server.The checksum described in chap. 2.3.2 helps to determine whether the current data in the client are valid. The client transmits its checksum with the server request. The serverdetermines validity by comparing this checksum with the checksum of the project dataavailable in the server.


E 531 827 / 00 E 05.99

2.3.4 Client consistency check of project data

The client checks the consistency of its project data before making the server request. Itcompares the calculated checksum with the stored checksum.

The client uses the checksum value 0xFFFF(HEX) on making the request if project dataare inconsistent or the client still has no project data.

2.3.5 Overview of download protocol services

The following services are differentiated in the download protocol:

Download service Brief description Transmittingdevice

PU Data Enable Request PLC request to FB 1 devices to startdownloading. Takes place after the PLC has booted

PLC

PU Data Request Download request of the FB 1 device:The PLC is requested to check validity ofthe data and transmit current data ifnecessary. Takes place after the FB 1 device has

booted or After receiving the Enable Request

service

FB 1 device(client)

PU Data Response Download response of the PLC Data valid:

PLC only transmits the Responseservice.

Data invalid:PLC transmits the Response servicewith details of the new data andsubsequently transmits the data.

PLC

PU DATA Transmission of the data PLCTab. 2: Download protocol services


E 531 827 / 00 E 05.99

2.3.6 Data format of the download protocol services

The download protocol differentiates between 4 services. The length of the data field is8 bytes for all services.

Abbreviations used in the telegrams:

Designation Meaningservice_id Indicates the number of the servicenode_nr Corresponds to the FB 1 node address of the clientpdu_count Number of COBs following this telegramchecksum Describes the checksum of the data on the server or on the

clientdata Project data transmitted from the PLC

Tab. 3: Abbreviations used in the telegrams

2.3.6.1 Download PU Data Enable Request

This service is started by the PLC.The assignment number of the COB ID is 0.

0xFA 0xFA 0xA5 0xFF 0x0A 0x0A 0xFF0xA51 2 3 4 5 6 7 8Byte

Contents

Fig. 5: Data format of the Download PU Data Enable Request


E 531 827 / 00 E 05.99

2.3.6.2 Download PU Data Request

This service is started by the FB 1 device, the client.The assignment number for the COB ID is: 1900 + .

service_id node_no checksum 0 0 0mux = 0Contents1 2 3 4 5 6 7 8Byte

Fig. 6: Data format of the Download PU Data Request

Contents of the bytes: For the multiplex variable: MUX = 0. For the service ID: service_id = 8. For the checksum: Client data checksum

2.3.6.3 Download PU Data Response

This service is started by the PLC.The assignment number for the COB ID is: 1932 + .

service_id node_no pdu_count checksum 0mux = 0Contents1 2 3 4 5 6 7 8Byte

Fig. 7: Data format of the Download PU Data Response service

Contents of the bytes: For the multiplex variable: MUX = 0. For the service ID: service_id = 9. For the checksum: Server data checksum

2.3.6.4 Download PU Data

This service is started by the PLC.The assignment number for the COB ID is: 1932 + .

dataContents1 2 3 4 5 6 7 8Byte

Fig. 8: Data format of the Download PU Data service


E 531 827 / 00 E 05.99

2.3.7 Operating states of the client

2.3.7.1 Bootup mode

The client is in the device initialization phase and is booting up. The device still has noinformation about the network state of other FB 1 devices during this phase.

2.3.7.2 Download mode

The client transmits the Download Request service every 5 sec and waits to receive theDownload Response. Actual downloading is initiated on receiving the Download Re-sponse.

In the Download Response data field, the client receives the information about whetherits project data are valid. Downloading has been completed if this is the case and theclient goes in to measuring point transmission mode.

If the project data are invalid, the data field provides information about the new projectdata subsequently transmitted. Only the COB ID is determined by the protocol in theDownload PU Data service used to transmit the project data. The entire data field isused to increase the flow of data.

The Download PU Data services are transmitted in blocks whereby each block consistsof a fixed number of COBs. The NMT Alive PDUs inform the PLC when a block has beencompletely received by the client. This form of block acknowledgement requires the clientto stop cyclic transmission of its NMT Alive PDUs on entering download mode.

When the client has consistent project data and determines PLC failure by NMT timeout, itgoes into measuring point transmission mode.


E 531 827 / 00 E 05.99

2.3.7.3 Measuring point transmission mode

In measuring point transmission mode, the client receives or transmits the measuringpoints in accordance with the project data. The client checks all other devices with theactive NMT and transmits its NMT Alive PDUs cyclically.

2.3.7.4 Overview of operating states and operating state transitions in tabularform

Current state Transition criteria Transition toBootup mode Bootup completed Download modeDownload mode 1. After PLC NMT Alive PDU timeout

2. When consistent PU data are availableMeasuring pointtransmissionmode

Download mode 1. After PLC NMT Alive PDU timeout2. When consistent PU data are missing

Download mode

Download mode Download completed successfully Measuring pointtransmissionmode

Download mode Download completed unsuccessfully Download modeMeasuring pointtransmissionmode

Receipt of Download Enable Request Download mode

Tab. 4: Overview of operating states and operating state transitions


E 531 827 / 00 E 05.99

2.3.8 Download sequence control flow chart from the client perspective

Client indownload mode

Start TIMEOUT_1 = 5 sec

Data valid?

Transmission of the nth projectimplementation block

All other blocks: 640 PDUs

pdu_count PDUs (all PU data)received?

received withinTIMEOUT_2 = 4 sec

Transmission of an NMT Alive PDU(block receipt confirmation)Start TIMEOUT_2 = 4 sec

Data transmission OK?Compare checksum with

checksum

Generation of checksum oftransmitted data

Client startsmeasured value

No

Yes

Yes

No

Yes

No

Yes

No

No

Yes

Transmission of a Download Request

Download Response withinTIMEOUT_1 = 5 sec

Receipt of a

Evaluation of the Download Response

Attributes of the Download Responsepdu_count = 0Checksum = Checksum data

Attributes of the Download Response receivedpdu_count = Number of PDUsChecksum = Checksum new data

Start TIMEOUT_2 = 4 sec

Block size (BLOCK_PDU_SIZE)1st block: 639 PDUs

BLOCK_PDU_SIZE PDUs

transmission mode

Fig. 9: Download sequence control flow chart from the client perspective

Thirdparty devices Chapter 3Page 25FRIEDRICHSHAFEN

E 531 827 / 00 E 05.99

Chapter 3

Project data for third-party devices

Chapter 326Page Thirdparty devicesFRIEDRICHSHAFEN

E 531 827 / 00 E 05.99

3 Project data for third-party devicesThe measuring points are defined in accordance with a list by order-specific agreementbetween MTU and the manufacturer of the third-party device. The measuring points in thislist are unambiguously identified by the two attributes Data block number and Data wordnumber. Furthermore, this list includes the direction of data and the normalization infor-mation in the minimum configuration (see chap. 3.2.1 Structure of the normalizationtables).

The plant project engineer integrates the third-party device in the MCS-5 plant on thebasis of this list. The project data transmitted to the third-party device via the downloadmechanism when running are generated as an end product. These data include all infor-mation required for communication.

Device data required and to be defined are: FB 1 node address FB 1 CAN settings:

Values of the two Bit Timing Registers of the CAN controller. The baudrate results from the values of these two registers.

The device data are passed on to the third-party device manufacturer after definition byMTU.

3.1 Description of project data structure

Project attributes are described in Motorola notation.

The structure shown in chap. 3.1.1 describes the structure of the binary file generated asa product of project implementation. OS-9 data module structure is already supportedmeaning that the module can be handled internally without modification by the PLC opera-ting system OS-9. Only the contents of the data module are relevant for the FB 1 client.


E 531 827 / 00 E 05.99

3.1.1 Structure of the project data module

The project data module is divided into 9 segments. Various attributes are defined in thesesegments.

The start and end of the module result from the OS-9 data module structure.

Client project data are described in the middle of the module.

OS-9 module header

User data length

User data headerPart 1

User data headerPart 2

Measured value attributes

Normalization tablesChecksumFiller bytes

OS-9 CRC 4 bytes

2 bytesspecific

n x 16 bytes

8 bytes

16 bytes

34 bytes

4 bytes

Clie

nt p

rojec

t data

Fig. 10: Structure of the project data module


E 531 827 / 00 E 05.99

3.1.2 Description of the segments in the project data module and their attributes

3.1.2.1 Segment 1: OS-9 module header (length: 34 bytes)

The OS-9 module header supports the OS-9 data module structure. The module can behandled internally without modification by the PLC operating system OS-9 in this way.

The OS-9 module header is not described in more detail as it remains invisible for theclient.

3.1.2.2 Segment 2: User data length (length: 4 bytes)

Information about the amount of data (in bytes) of the client project data. Only this part ofthe OS-9 module described is transmitted during downloading.

Attributes Meaning of the individual attributes LengthNumber of bytes Starting with the user data header (inclusive)

Ending with the checksum (inclusive)4 bytes

Tab. 5: Attributes of user data length


E 531 827 / 00 E 05.99

3.1.2.3 Segment 3: User data header part 1 (length: 16 bytes)

General information about the project data is included in the first part of the user dataheader.

Attributes Meaning of the individual attributes LengthOrder Order number 7 bytes

Edition Currently not assigned. The entered value iszero.

1 byte

SW type SW type is used in the NMT Alive PDU whenrunning.

1 byte

Domain type Domain data type. This information is not rele-vant for the third-party device.

1 byte

Domain length Domain length corresponds to user data length Starting with the user data header (inclusive) Ending with the checksum (inclusive)

2 bytes

Project data revision status

Transmitted in the NMT Alive PDU 1 byte

Project datamodification status

Transmitted in the NMT Alive PDU 1 byte

PLC process busnode address

PLC node address on the process bus 1 byte

FB 1 configuration Differentiates between simple or redundant fieldbus 1 design Value 1: Field bus 1 is of simple design Value 2: Field bus 1 is of redundant design

1 byte

Tab. 6: Attributes of the user data header part 1


E 531 827 / 00 E 05.99

3.1.2.4 Segment 4: User data header part 2 (length: 8 bytes)

Attributes Meaning of the individual attributes LengthInterface type Interface type defined by MTU 1 byteNumber of measuring points(max. 128)

Number of measuring points 2 bytes

Reserved bytes Reserved bytes 5 bytesTab. 7: Attributes of the user data header part 2

3.1.2.5 Segment 5: Measuring point attributes (length: n x 16 bytes, whereby nis max. 128)

Attributes Meaning of the individual attributes LengthCOB ID COB ID (transmitted with the measuring point) 2 bytesMUX Multiplex variable (transmitted with the

measuring point)1 byte

Offset to normali-zation table

Offset with reference to the normalization tablefor the measuring points.The offset is calculated from:Normalization table address minus user dataheader address

2 bytes

Data block number

Logical identifier of a measuring point block 1 byte

Data word number Logical identifier of a measuring point within ameasuring point block

1 byte

Data direction Direction of transmission.The following values are possible: Value 0: Data are transmitted from the third-

party device to the MCS-5 field bus 1 Value 1: Data are transmitted from the

MCS-5 field bus 1 to the third-party device

1 byte

Reserved bytes Reserved bytes 8 bytesTab. 8: Attributes of the measuring point attributes


E 531 827 / 00 E 05.99

3.1.2.6 Segment 6: Normalization tables (length specific)

The normalization tables are described in chap. 3.2.1 Structure of the normalizationtables.

3.1.2.7 Segment 7: Checksum (length: 2 bytes)

The checksum is a 16-bit cross-checksum to check completeness of data transmission.

The checksum results from the addition of the individual user data byte values.The checksum is generated by the transmitted data starting with the user data header.

3.1.2.8 Segment 8: Filler bytes

Bytes with a value of 0 which are inserted during data module generation to create anOS-9-specific module size.

3.1.2.9 Segment 9: OS-9-CRC (length: 4 bytes)

CRC checksum over the entire OS-9 data module.

3.2 Description of the normalization tables

All measuring points are transmitted with a normalized base on FB 1. A unit is defined foreach physical measured variable. Each pressure is, for example, transmitted as a multipleof the base unit 0.01 mbar.

The third-party device receives the required normalization information for converting thethird-party device normalized measuring point into the MCS-5 measuring point (and vice-versa) in normalization tables.


E 531 827 / 00 E 05.99

3.2.1 Structure of the normalization tables

The normalization tables represent an X/Y curve by straight lines defined in sections. Thestart and end of the individual straight lines are defined by curve points and are defined asinterpolation points in the tables with X/Y value entries. Intermediate values are calcula-ted by linear interpolation.

A differentiation is made between two data directions in the normalization tables. The twodata directions are:

Data direction = 0 (from the third-party device to the MCS-5 device) Data direction = 1 (from the MCS-5 device to the third-party device)

In both cases the first and last curve value are: Y0 = Y1 or Yn = Yn1

3.2.1.1 Normalization table representing data direction = 0

X axis: Third-party device normalized measuring point

Y axis: MCS-5 normalized measuring point

Pt. 3 (x3 / y3)

Pt. 2 (x2 / y2)Pt. 1 (x1 / y1)Pt. 4 (x4 = MD_VALUE / y4 = y3)

Pt. 0 (SDF_VALUE + 1 / y0 = y1)

Fig. 11: Representation of the measuring points as a curve data direction = 0


E 531 827 / 00 E 05.99

3.2.1.2 Normalization table representing data direction = 1

Y axis: Third-party device normalized measuring point

X axis: MCS-5 normalizedmeasuring point

Pt. 3 (x3 / y3)

Pt. 2 (x2 / y2)Pt. 1 (x1 / y1)Pt. 4 (x4 = MD_VALUE / y4 = y3)

Pt. 0 (SDF_VALUE + 1 / y0 = y1)

Fig. 12: Representation of the measuring points as a curve data direction = 1

3.2.1.3 Influence of data direction on the X/Y values

As the X/Y values of the measuring points also depend on the data direction, a furtherdifferentiation is made between the data directions:

From the third-party device to the MCS-5 (data direction = 0) X value: Physical measuring point of the third-party device Y value: Physical measuring point in accordance with MCS-5 normalization

From the MCS-5 to the third-party device (data direction = 1) X value: Physical measuring point in accordance with MCS-5 normalization Y value: Physical measuring point of the third-party device


E 531 827 / 00 E 05.99

3.2.1.4 Normalization method

Normalization is effected by the linear interpolation method: Determination of the pair of X values between which the X value lies Determination of the straight-line equation and calculation of the Y value

3.2.1.5 Linear interpolation of the values

In its simpliest configuration, a curve comprises 4 points whereby the following verticesare identified by the X/Y values:

First curve value X0 = SDF_VALUE + 1 (Hex: 0x80000000) Y0 = Y1

Last curve value Xn = MD_VALUE Yn = Yn1

Interpolation is only effected for X values in the range X1 X Xn1.

If the X value is < X1, the Y value is set to the value Y1.

If the X value is > Xn1, the Y value is set to the value Yn1.

The values are given in the tables as signed 4-byte integer values.


E 531 827 / 00 E 05.99


The measuring point attribute Offset to normalization table indicates the X value of thefirst curve point.

X0 table 0Y0 table 0

X1 table 0

Y1 table 0

Table 2

...

Table n

Xn table 0

Yn table 0

Offset x

Offset y

Offset z

...

...

Fig. 13: Structure of the normalization tables


E 531 827 / 00 E 05.99


Das Handbuch ist zur Vermeidung von Strungen oder Schden beim Betrieb zu beachten und daher vom Betreiber dem jeweiligenWartungs- und Bedienungspersonal zur Verfgung zu stellen. Auerhalb dieses Verwendungszwecks darf das Handbuch ohne unserevorherige Zustimmung nicht benutzt, vervielfltigt oder Dritten sonstwie zugnglich gemacht werden.

nderungen bleiben vorbehalten.

This handbook is provided for use by maintenance and operating personnel in order to avoid malfunctions or damage during operation.Other than for this purpose, the handbook shall not be reproduced, used or disclosed to others without our prior consent.

Subject to alterations and amendments.

Le manuel devra tre observ en vue dviter des incidents ou des endommagements pendant le service. Aussi recommandons-nous lexploitant de le mettre la disposition du personnel charg de lentretien et de la conduite. En dehors de cet usage, le manuel ne pourra tre utilis ni reproduit ou rendu accessible de quelque autre manire des tiers, sans notre consentement pralable.

Nous nous rservons le droit dentreprendre toute modification.

El Manual debe tenerse presente para evitar anomalias o daos durante el servicio, y, por dicho motivo, el usuario debe ponerlo a disposicin del personal de mantenimiento y de servicio. Fuera de este fin de aplicacin, el Manual no se debe utilizar, copiar ni poner en manos de terceros, sin nuestro consentimiento previo.

Nos reservamos el derecho de introducir modificaciones.

No sentido de evitar falhas ou danos durante o servicio, o usurio deber cuidar de que o Manual esteja sempre disposio do pessoal encarregado com a manuteno e operao. Alm desta sua finalidade, o Manual no dever, sob qualquer pretexto, ser reproduzido parcial ou totalmente ou franqueado a terceiros sem prvia e expressa autorizao de nossa parte.

Reservamo-nos o direito de proceder modificaes.

Il manuale va consultato per evitare anomalie o guasti durante il servizio, per cui va messo a disposizione dall utente al personale addetto alla manutenzione e alla condotta. Senza nostra approvazione preventiva non ammesso impiegare il manuale per scopi diversi, riprodurlo o metterlo a disposizione di terzi.

Con riserva di modifiche.

Kytthiriiden ja teknisten vaurioiden vlttmiseksi on noudatettava ksikirjassa annettuja ohjeita, joten kirja on luovutettava huoltoja kytthenkilkunnan kyttn. Ksikirjaa ei saa ilman sen laatijan lupaa kytt muuhun tarkoitukseen, monistaa tai luovuttaa ulkopuolisille.

Oikeudet muutoksiin pidtetn.

MTU Motoren- und Turbinen-Union Friedrichshafen GmbH

88040 Friedrichshafen / Germany

Phone (0 75 41) 90 - 0 Telex 7 34 280 50 mt d Telefax (0 75 41) 90 - 61 23

1999

HOMETitleGuideTable of contentsAbbreviationsPreface

1 System overview1.1 Structure of the MCS-5 system1.2 Structure of the communication protocol in layer 11.2.1 Brief description of the attributes in the communication protocol

1.3 Structure of the communication protocol in layer 21.3.1 Data type definition in layer 21.3.1.1 Data type Measuring point

1.4 Device data and project data1.4.1 Device data1.4.2 Project data

2 Description of the field bus 1 protocol2.1 Measuring point transmission2.1.1 Services and transmission modes2.1.1.1 Cycle times2.1.1.2 Cycle times for third-party devices2.1.1.3 Delta value generation2.1.1.4 Multiplex variable (MUX)

2.1.2 PDU measuring point data format2.1.2.1 Assignment of data field byte 62.1.2.2 Possible assignments of data field byte 2, 3, 4 and 5

2.1.3 Measuring point normalization2.1.3.1 Measuring point normalization for third-party devices

2.1.4 Sensor Defect handling2.1.4.1 Sensor Defect for third-party devices

2.1.5 Missing Data handling2.1.5.1 Missing Data for third-party devices receiving2.1.5.2 Missing Data for third-party devices transmitting

2.2 Network monitoring NMT2.2.1 Monitoring of interfaces and devices2.2.1.1 Node address2.2.1.2 NMT Alive PDU2.2.1.3 COB ID for network monitoring

2.2.2 Data format of the NMT Alive PDU2.2.3 Brief description of the attributes in the NMT Alive PDU data format2.2.3.1 Meaning and assignment of the attributes

2.2.4 Field bus 1 redundancy and redundancy switching2.2.4.1 Redundancy2.2.4.2 Redundancy switching2.2.4.3 Criteria for switching from the default interface to the redundant interface

2.3 Service mode: Download2.3.1 Downloading project data2.3.2 Data transmission saving2.3.3 Download criterium: Checking data validity2.3.4 Client consistency check of project data2.3.5 Overview of download protocol services2.3.6 Data format of the download protocol services2.3.6.1 Download PU Data Enable Request2.3.6.2 Download PU Data Request2.3.6.3 Download PU Data Response2.3.6.4 Download PU Data

2.3.7 Operating states of the client2.3.7.1 Bootup mode2.3.7.2 Download mode2.3.7.3 Measuring point transmission mode2.3.7.4 Overview of operating states and operating state transitions in tabular form

2.3.8 Download sequence control flow chart from the client perspective

3 Project data for third-party devices3.1 Description of project data structure3.1.1 Structure of the project data module3.1.2 Description of the segments in the project data module and their attributes3.1.2.1 Segment 1: OS-9 module header (length: 34 bytes)3.1.2.2 Segment 2: User data length (length: 4 bytes)3.1.2.3 Segment 3: User data header part 1 (length: 16 bytes)3.1.2.4 Segment 4: User data header part 2 (length: 8 bytes)3.1.2.5 Segment 5: Measuring point attributes (length: n x 16 bytes, whereby n is max. 128)3.1.2.6 Segment 6: Normalization tables (length specific)3.1.2.8 Segment 8: Filler bytes3.1.2.9 Segment 9: OS-9-CRC (length: 4 bytes)

3.2 Description of the normalization tables3.2.1 Structure of the normalization tables3.2.1.1 Normalization table representing data direction = 03.2.1.2 Normalization table representing data direction = 13.2.1.3 Influence of data direction on the X/Y values3.2.1.4 Normalization method3.2.1.5 Linear interpolation of the values


Documents

E531827 00E CAN Fieldbus