HBM QuantumX Operating Manual

Operating Manual | Bedienungsanleitung

English Deutsch

CANBus

/

Hottinger Baldwin Messtechnik GmbH
Im Tiefen See 45
D-64239 Darmstadt
Tel. [phone]
Fax [phone]
[e-mail]
www.hbm.com

Mat.: 7-2002.4461
DVS: A4461-2.0 HBM: public

03.2017

E Hottinger Baldwin Messtechnik GmbH.

Subject to modifications.
All product descriptions are for general information only.
They are not to be understood as a guarantee of quality or
durability.

Änderungen vorbehalten.
Alle Angaben beschreiben unsere Produkte in allgemeiner
Form. Sie stellen keine Beschaffenheits- oder Haltbarkeits
garantie dar.

Operating Manual | Bedienungsanleitung

English Deutsch

/

CANBus

Receive / Transmit

English

1 Safety instructions 5........................................

2 Markings used 12............................................

2.1 The markings used in this document 12..........................

3 QuantumX / SomatXR documentation 14......................

4 CANbus 15..................................................

5 QuantumX / SomatXR and CAN 16............................

5.1 General information 16........................................

5.2 CAN bus 18..................................................

5.2.1 LEDs status display 20........................................

5.2.2 Receiving CAN messages 22...................................

6 Functional description 23....................................

6.1 Global parameters 23.........................................

6.1.1 Bit rates 23..................................................

6.1.2 CANBus line termination 23....................................

6.1.3 Error handling 24.............................................

6.2 Error events 25...............................................

6.2.1 Detecting transmit and receive path errors 25.....................

6.2.2 LED and error status behavior 25...............................

6.2.3 Possible error causes in CAN mode 26..........................

6.2.3.1 CANbus warning, CANbus error, CANbus OFF 26..................

6.2.3.2 CAN “Receiver Overrun” 26......................................

6.2.3.3 CAN “Transmitter Overrun” 27...................................

6.2.3.4 CAN decoder “Timeout” 27......................................

6.2.3.5 CAN decoder “Loss of Signal” 27.................................

6.2.3.6 Module resources 28...........................................

6.3 State indication by LED 28.....................................

6.3.1 MX840B 28..................................................

6.3.2 MX471B 29..................................................

6.4 CAN decoder: receiving CAN data 31............................

2 A4461-2.0 HBM: public CANBus

6.4.1 Remote frames (RTR) 31......................................

6.4.2 User-defined data type selection 31.............................

6.4.3 Calculation rule data types 32..................................

6.4.4 Floating point scaling 32.......................................

6.4.6 Integer scaling 36.............................................

6.5 CAN encoder (mappable CAN transmit messages) 39.............

6.5.1 Motivation 39.................................................

6.5.2 Signal source definition 39.....................................

6.5.3 Measured value scaling 40.....................................

6.5.4 Data types and bit positions of a measured value 41...............

6.5.5 Transmit data in the event of an error 42.........................

6.5.6 CAN message parameters 43..................................

6.5.6.1 Data length of the CAN message 43..............................

6.5.7 Example of the different signal sources within a single CAN

message 44..................................................

6.5.8 Transmission type 46..........................................

6.5.8.1 Control 47.....................................................

6.5.8.2 Timer 47......................................................

6.5.8.3 SourceChange 47..............................................

6.5.8.4 IsoEvent 48...................................................

6.5.9 Constraints for MX840B 48.....................................

6.6 Data bit numbering systems according to the vector DBC format 49.

6.6.1 Numbering systems used in QuantumX / SomatXR

parameterization 49............................................

6.6.1.1 INTEL Standard format 50.......................................

6.6.1.2 MOTOROLA Forward MSB format 51.............................

6.6.2 Other numbering systems not used in QuantumX / SomatXR

parameterization 52...........................................

6.6.2.1 MOTOROLA Forward LSB format 53.............................

6.6.2.2 MOTOROLA Backward format 54................................

6.6.2.3 INTEL Sequential format 55.....................................

6.6.2.4 MOTOROLA Sequential format 56................................

CANBus A4461-2.0 HBM: public 3

7 QuantumX / SomatXR and CCP / XCP-on-CAN 57..............

7.1 Introduction to CCP and XCP 57................................

7.2 MX471B and CAN / XCP-on-CAN 58............................

7.3 Initialization per XML 60.......................................

7.4 Starting and stopping with the "CANECU" control item 60..........

7.5 General Workflow 61..........................................

8 Glossary 71.................................................

4 A4461-2.0 HBM: public CANBus

1 Safety instructions

Notice

The safety instructions described here also apply to the
power pack NTX001 and the active backplane BPX001
and BPX002.

Appropriate use

A module integrated into the CANbus by the relevant
connector is to be used exclusively for measurement and
test tasks. Use for any purpose other than the above is
deemed to be non-designated use.

To ensure safe operation, the module must only be ope
rated as described in the general operating manual and in
accordance with the information detailed in this document.
It is also essential to comply with the legal and safety re
quirements for the application concerned during use. The
same applies to the use of accessories.

Safety instructions

Each time you start up the module, you must first run a
project planning and risk analysis that takes into account
all the safety aspects of automation technology. This par
ticularly concerns personal and machine protection.

Additional safety precautions must be taken in plants
where malfunctions could cause major damage, loss of
data or even personal injury. In the event of a fault, these
precautions establish safe operating conditions.

This can be done, forexample, by mechanical
interlocking, error signaling, etc.

CANBus A4461-2.0 HBM: public 5

Safety instructions

Notice

The module must not be connected directly to a power
supply system. The supply voltage must be 10 V … 30 V
(DC).

General dangers of failing to follow the safety
instructions

Every module is a state of the art device and as such is
failsafe. The module may give rise to residual dangers if
it is inappropriately installed and operated by untrained
personnel. Any person instructed to carry out installation,
commissioning, maintenance or repair of the modules
must have read and understood the Operating Manuals
and in particular the technical safety instructions.

The scope of supply and performance of the modules
only covers a small area of measurement technology. In
addition, equipment planners, installers and operators
should plan, implement and respond to the safety
engineering considerations of measurement technology
in such a way as to minimize residual dangers. On-site
regulations must be complied with at all times. There
must be reference to the residual dangers connected
with measurement technology. After making settings and
carrying out activities that are password-protected, you
must make sure that any controls that may be connected
remain in safe condition until the switching performance
of the module has been tested.

6 A4461-2.0 HBM: public CANBus

Safety instructions

Maintenance and cleaning

The modules are maintenance-free.

S Before cleaning, disconnect all connections.

S Clean the housing with a soft, slightly damp (not wet!)

cloth. Never use solvent, as this could damage the
label or the housing.

S When cleaning, ensure that no liquid gets into the

module or connections.

Bus connecting and Outputs

Particular attention must be paid to safety when
connecting to the CANbus and when sending CANbus
messages. Ensure that integration alone, status or
control signals cannot initiate any actions that may pose
a danger to persons or the environment.

Product liability

In the following cases, the protection provided for the
device may be adversely affected. Liability for device
functionality then passes to the operator:

S The device is not used in accordance with the operat

ing manual.

S The device is used outside the field of application de

scribed in this section.

S The operator makes unauthorized changes to the

device.

Warning signs and danger symbols

Important instructions for your safety are specifically
identified. It is essential to follow these instructions in
order to prevent accidents and damage to property.

CANBus A4461-2.0 HBM: public 7

Safety instructions

Safety instructions are structured as follows:

WARNING

Type of danger
Consequences of non-compliance
Averting the danger

S Warning sign: draws attention to the danger
S Signal word: indicates the severity of the danger

(see table below)

S Type of danger: identifies the type or source of the

danger

S Consequences:describes the consequences of non-

compliance

S Defense: indicates how the danger can be avoided/

bypassed.

Danger classes as per ANSI

Warning sign, signal word Meaning

WARNING

CAUTION

Note

This marking warns of a potentially dangerous situ
ation in which failure to comply with safety require
ments may result in death or serious physical injury.

This marking warns of a potentially dangerous situ
ation in which failure to comply with safety require
ments may result in slight or moderate physical injury.

This marking draws your attention to a situation in
which failure to comply with safety requirements may
lead to damage to property.

8 A4461-2.0 HBM: public CANBus

Safety instructions

Working safely

The supply connection, as well as the signal and sensor
leads, must be installed in such a way that
electromagnetic interference does not adversely affect
device functionality (HBM recommendation: "Greenline
shielding design", downloadable from the Internet at
http://www.hbm.com/Greenline).

Automation equipment and devices must be covered
over in such a way that adequate protection or locking
against unintentional actuation is provided (e.g. access
checks, password protection, etc.).

When devices are working in a network, these networks
must be designed in such a way that malfunctions in
individual nodes can be detected and shut down.

Safety precautions must be taken both in terms of
hardware and software, so that a line break or other
interruptions to signal transmission, e.g. via the bus
interfaces, do not cause undefined states or loss of data
in the automation device.

Error messages should only be acknowledged once the
cause of the error is removed and no further danger
exists.

Conversions and modifications

The module must not be modified from the design or
safety engineering point of view except with our express
agreement. Any modification shall exclude all liability on
our part for any resultant damage.

In particular, any repair or soldering work on
motherboards (exchanging components) is prohibited.
When exchanging complete modules, use only original
parts from HBM.

CANBus A4461-2.0 HBM: public 9

Safety instructions

The module is delivered from the factory with a fixed
hardware and software configuration. Changes can only
be made within the possibilities documented in the
manuals.

Qualified personnel

Important

This device is only to be installed and used by qualified
personnel strictly in accordance with the specifications
and with the safety rules and regulations which follow.

Qualified persons means persons entrusted with the
installation, fitting, commissioning and operation of the
product who possess the appropriate qualifications for
their function. This module is only to be installed and
used by qualified personnel, strictly in accordance with
the specifications and the safety rules and regulations.

This includes people who meet at least one of the three
following requirements:

S Knowledge of the safety concepts of automation tech

nology is a requirement and as project personnel, you
must be familiar with these concepts.

S As automation plant operating personnel, you have

been instructed how to handle the machinery and are
familiar with the operation of the modules and techno
logies described in this documentation.

S As commissioning engineers or service engineers,

you have successfully completed the training to qual
ify you to repair the automation systems. You are also
authorized to activate, ground and label circuits and
equipment in accordance with safety engineering
standards.

10 A4461-2.0 HBM: public CANBus

Safety instructions

It is also essential to comply with the legal and safety
requirements for the application concerned during use.
The same applies to the use of accessories.

CANBus A4461-2.0 HBM: public 11

Markings used

2 Markings used

catman is a registered trademark of Hottinger Baldwin
Messtechnik GmbH.

All trademarks and brands used in this document are
trade names and/or trademarks belonging to the respec
tive product or the manufacturer/owner. Hottinger
Baldwin Messtechnik GmbH does not lay claim to any
other than their own trade names/trademarks.

2.1 The markings used in this document

Important instructions for your safety are specifically
identified. It is essential to follow these instructions, in
order to prevent damage.

Symbol Significance

Note

CAUTION

Important

Tip

Device -> New Bold text indicates menu items, as well as dialog and

This marking draws your attention to a situation in
which failure to comply with safety requirements can
lead to damage to property.

This marking warns of a potentially dangerous situ
ation in which failure to comply with safety require
ments may result in slight or moderate physical injury.

This marking draws your attention to important infor
mation about the product or about handling the prod
uct.

This marking indicates application tips or other infor
mation that is useful to you.

window titles in the user interfaces. Arrows between
menu items indicate the sequence in which the
menus and sub-menus are opened.

12 A4461-2.0 HBM: public CANBus

Markings used

SignificanceSymbol

Bitrate, 500 Bold text in italics indicates inputs and input fields in

the user interfaces.

Emphasize
See…

Italics are used to emphasize and highlight text and
identify references to sections, diagrams, or external
documents and files.

CANBus A4461-2.0 HBM: public 13

QuantumX / SomatXR documentation

3 QuantumX / SomatXR documentation

The QuantumX / SomatXR family documentation con
sists of

S the QuantumX / SomatXR operating manual in PDF

format

S the data sheets in PDF format

S the operating manuals for the CX22B-W data recorder

S the operating manual for the EtherCAT®

gateway CX27B in PDF format

S the product descriptions for accessories in PDF‐for

mat

S a comprehensive online help with index and easy

search options which is available after the installation
of a software package (e.g. MX Assistant, cat
man®EASY). Information about module and channel
configuration can also be found here.

1)

/ Ethernet

These documents can be found

S on the QuantumX / SomatXR system CD supplied

with the device

S After installation of the MX Assistant on the hard drive

of your PC, which can be reached through the Win
dows start menu

S Up-to date versions are always available from our In

ternet site at www.hbm.com

1)

EtherCAT® is a registered brand and patented technology, licensed by Beckhoff Automation
GmbH, Germany

14 A4461-2.0 HBM: public CANBus

4 CANbus

CANbus

This manual is intended to support you in connecting
your QuantumX or SomatXR system to a CANbus with
the following modules:

- MX471B(-R)

- MX840B(-R)

In the following we will refer to these modules as
MX471B and MX840B and only state the SomatXR
modules in case of significant differences.

When using the CX23-R data recorder there are some
restrictions related to the CANbus options (see CX23-R
manual).



The catman
have extensive online Help and can be used to configure
a CAN port.

This manual shows you:

EASY or MX Assistant software packages

S How to parameterize a CANbus node

The following documentation is also available:

S General operating manual

S Data sheets MX840B or MX471B

S Online Help in the catmanEASY and MX-Assistant

software

CANBus A4461-2.0 HBM: public 15

QuantumX / SomatXR and CAN

5 QuantumX / SomatXR and CAN

5.1 General information

The MX471B module provides four independent CAN
bus nodes that are all electrically isolated from each
other and power supply. Module MX840B provides an
electrically isolated CANbus node on channel 1.

Connected devices are not directly addressed during
data transmission on a CAN bus. A unique identifier de
notes the contents of a message (e.g. rotational speed or
engine temperature).

The identifier also signifies the priority of the message.

Message = identifier + signal + additional information

Device connected to the bus = node

Each node on the MX471B can be parameterized either
as a receiver or as transmitter (gateway). The online help
that comes with the respective software package
provides detailed information about parameterization.

Notice

To ensure normal operation, the CAN bus needs to be
terminated at both ends, and only there, using appropri
ate termination resistors.
A 120-ohm termination resistor can be individually con
nected in the module by software. Termination is also
required when short cables with low bit rates are used.

Please refer to the data sheet for the relation between bit
rate and maximum bus line length.

16 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CAN

The configuration of a node is retained after switching the
modules off and on.

For decoding signals at a rate greater than 2000/s,
please set up signal inputs 1 to 8 on the MX471B. The
signal buffers of these signal inputs have been expanded
accordingly.

CANBus A4461-2.0 HBM: public 17

QuantumX / SomatXR and CAN

5.2 CAN bus

Receiving CAN signals:

- MX471B, MX840B (channel 1)

Transmitting CAN signals:

- MX471B

- MX840B (measurement signals within the module
only)

- The MX Assistant software can generate a DBC file
from the list of all the messages that have been
sent

Receiving CCP or XCPoverCAN signals:

- MX471B only

QuantumX

MX840B

MX471B

Channel 1

CAN High

CAN Low

CAN-GND

Sub-HD 15-pin

6

1

11

5

15

10

7

8

6

Sub-D 9-pin

1

6

9

5

7

2

6

18 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CAN

SomatXR

MX471B-R

M12 5‐pin

4

5
3

CAN-High

CAN-Low

CAN-GND

Grey

Green

Grey/Black

MX840B-R

Channel 1
ODU 14‐pin

11

12

13

White

Blue

Black

Notice

Ensure correct termination with termination resistors is
made, as shown in Fig. 5.1. The MX840B does not have
any termination. The MX471B and the SomatXR
MX840B-R have an internal termination that can be activ
ated via software.

CANBus A4461-2.0 HBM: public 19

QuantumX / SomatXR and CAN

Termination
resistance
120

Node 1 . . . . . .

Fig. 5.1 Bus termination resistors

The adapter cable 1-KAB418 is used to connect the
D-SUB-15HD device sockets of the QuantumX MX840B
to standard D-SUB plugs with a standardized CiA assign
ment of the MX840B to standard CAN plugs (D-SUB-9).

5.2.1 LEDs status display

CAN LEDs “BUS”

Termination
resistance
120

Node n

System LED

CAN LEDs “Channel”

Fig. 5.2 QuantumX MX471B front view

20 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CAN

CAN LEDs “BUS”

CAN LEDs “Channel”

Fig. 5.3 SomatXR MX471B-R front view

For module-related status displays (error messages) see
also section 6.3.

System LED

Green Error-free operation

Yellow System is not ready, boot procedure running

Flashing yellow Download active, system is not ready

Red Error, faulty synchronization

System LED

CAN-LEDs (BUS)

Green flickering Bus is error-free and activity on CAN

Constant green Bus is error-free and no activity on CAN

Yellow flickering Intermittent bus errors (warning) and activity on CAN

Constant yellow Intermittent bus errors (warning) and no activity on CAN

Red on Bus error, CAN interface in "Bus-OFF" status

CANBus A4461-2.0 HBM: public 21

QuantumX / SomatXR and CAN

CAN LEDs (channel)

Constant green Channel is ready for operation

Flashing yellow Firmware download active

Yellow on Boot process running

Red on Channel has errors

Ethernet LED (only QuantumX)

Green on Ethernet link status is OK

Flashing yellow Ethernet data transmission ongoing

5.2.2 Receiving CAN messages

To be able to receive CAN messages, the node must be
able to identify the relevant messages. This can be done
directly on the node or, in a reproducible way, by previ
ously generated messages in the sensor database. Indi
vidual messages can be linked to the node by dragging
from the sensor database and dropping them where re
quired.

CAN databases type *.dbc can also be read into the
sensor database. If no CAN database is available, it can
also be created. Editors for this purpose are provided by
different companies.

Received CAN messages are instantly "time-stamped" in
measurement mode. This enables directly acquired
measured quantities and CAN messages to be acquired
and analyzed in parallel and synchronously in the entire
system.

22 A4461-2.0 HBM: public CANBus

6 Functional description

6.1 Global parameters

6.1.1 Bit rates

Parameterization of the CAN bit rate is extended as of
firmware version 4.6. You can select a required bit rate,
the sample point and the synchronization jump width
(SJW) in a view.

A bit rate (value in bits/s) must be specified for
parameterization. In addition to this, “SamplePointRatio”
selects a required sample point and “SJW” a
synchronization jump width between 1 and 4 time quanta.

Once the parameterization has been forwarded, it is
verified in the module and a setting is made that is as
close as possible to the required parameters. The
parameterization can now be read back, and the values
actually set at the time can be read out from the relevant
XML tags preceded by “Active”. Users are free to assign
the values that are read back to meet their own require
ments.

Functional description

The chosen factory setting is: Bit rate = 1000 kbit/s,
SamplePointRatio = 87.5 %, SJW = 4.

6.1.2 CANBus line termination

All the MX471B variants and the MX840B-R can switch
CAN bus line termination on or off via parameterization.
The MX840, MX840A and MX840B do not support
internal line termination.

CANBus A4461-2.0 HBM: public 23

Functional description

6.1.3 Error handling

There are applications in which individual error events
are critical and must be permanently indicated, even if
the cause of the error has long been eliminated. In other
applications, it is desirable for the LED and the error
status to indicate the current state of CAN bus and
module, and for errors to automatically be deleted when
their cause is eliminated.

So in the MX Assistant, make a selection in the “CAN
bus settings” under “Error mode” to indicate how the
module should behave when transient errors occur:
If the “automatic, delayed” method is selected, the
error is automatically deleted from the error status after
the set delay time, and the state of the LED changes to
normal once the cause of the error has been eliminated.
Accordingly, the module shows the current state of the
CAN bus after the set delay.

If the “when reading” method is selected, the error sta
tus remains, and is also indicated by the LED, until the
error status has been read out of the module. So pro
vided the cause of the error no longer exists, the error
status and the state of the LED only change to normal
once the error status has been read out. This is also a
reliable way to detect individual error events without
having to constantly monitor the error status during mea
surement. However, this method does not always reflect
the current state of the CAN bus.

24 A4461-2.0 HBM: public CANBus

Functional description

6.2 Error events

6.2.1 Detecting transmit and receive path errors

Errors in the transmit direction (from the module to the
CAN bus) are then only monitored if data has been
configured for sending in the module parameterization.
Conversely, errors are then only detected in the receive
direction (CAN bus to module) if at least one CAN
receive decoder is actively configured.

6.2.2 LED and error status behavior

The LED glows yellow whenever a BUS warning occurs,
and red in all other error situations.

A timeout and “loss of signal” are indicated by a yellow
LED, provided monitoring has been activated. This is
because the “MaxRepetitionTime” value selected in the
decoder parameterization was greater than “0”.

The error register can be read out via the MX Assistant.
The LED follows the status messages in the error
register, see Chapter 3.

Error events often only occur sporadically and briefly. If
the application also requires reliable detection of one-off
events, you can set “error mode” in the parameterization
(see Section 1.3) so that errors are only deleted when
the error status is read out.

CANBus A4461-2.0 HBM: public 25

Functional description

6.2.3 Possible error causes in CAN mode

6.2.3.1 CANbus warning, CANbus error,

An internal counter in the module’s CAN controller counts
the bus errors in accordance with the CAN standard.
When the first threshold is exceeded, a “Warning” is set,
and after that, an “Error”. If the cause of the error is
promptly eliminated, Warning and Error are automatically
deleted again.

If the error still remains, “BUS OFF” will ultimately be set.
The bus will become inactive/switch off. Once the cause
of the error is eliminated, the state in the module is
deleted by an external BUS reset, parameterization or
re-starting the module. A BUS reset can be triggered by
all MX471B and MX840B variants, but not by MX840 and
MX840A.

Errors on the CAN bus are then counted in the CAN
controller, for instance, if no correct response is received
from the other side during transmission (because no
recipient responds by acknowledging), or if the bus is
malfunctioning due to a short circuit, incorrect bus termi
nation, mixed operation at different bit rates, or other
(usually) electrical properties.

CANbus OFF

6.2.3.2 CAN “Receiver Overrun”

If the CAN controller in the module cannot read out the
data quickly enough, the data present on the CAN bus
are lost, and the “Overrun” flag is set. At this moment in
time, no-one knows whether the lost data are relevant,
that is, whether the CAN identifier for this message is
parameterized in the decoder.

26 A4461-2.0 HBM: public CANBus

Functional description

Once the data from the CAN bus have been read, they
are placed in a temporary buffer, from which messages
are then regularly read out and decoded. All the MX840A
module variants can decode on average 20,000 mea
sured values per second from the CAN data. If this value
is exceeded, the temporary buffer overflows, which
results in an error message.

6.2.3.3 CAN “Transmitter Overrun”

If the transmit data cannot be properly sent because the
bus is malfunctioning or overloaded, for example, this
error is entered into the error status.

6.2.3.4 CAN decoder “Timeout”

The parameter “MaxRepetitionTime” is used to define a
timeout. Whenever a CAN message has been decoded,
the time to the earlier receipt of this message is
determined. If this is greater than this timeout, a
measured value marked as invalid is included in the
signal current, and an error is indicated.

6.2.3.5 CAN decoder “Loss of Signal”

Unlike a “Timeout”, there is no additional decoded CAN
message when there is a “Loss of signal”. The following
applies to MX840B: If the signal fails completely within
128 ms, this is detected and a measured value marked
as invalid is included in the signal current. This message
is deleted again as soon as the next message has been
decoded.

CANBus A4461-2.0 HBM: public 27

Functional description

6.2.3.6 Module resources

It is true to say that totaled across all CAN connections,
the MX471B can decode up to 100,000 signals per
second and create CAN messages for sending. If this
value is exceeded, CAN message decoding and creation
is interrupted until once again, less signals are received
or being created. This ensures that the module remains
accessible even in an overload situation. A relevant error
code is entered in the module error status, and all status
LEDs glow constantly red.

6.3 State indication by LED

A distinction is made between the general kind of error
message (see Chapter 5.2.1), such as an incorrect bit
rate setting, and errors that are dependent on the receive
or transmit parameterization. If no transmit channel is
parameterized, errors in the sending direction will be
ignored. Conversely, there is no error signaling from CAN
receiving, if no CAN signals are parameterized in the
receive direction.

If the connection LED does not glow green in normal
mode, there are usually error messages present, which
can be read out via the error status.

6.3.1 MX840B

The behavior of the channel LED in CAN operating mode
is described for the MX840B. The flickering of the LED
during activity on the CAN bus is not synchronized with
the individual messages.

28 A4461-2.0 HBM: public CANBus

Functional description

Connection LED Function

constant green CAN BUS activated, no errors or failures
flickering green CAN BUS activated, no errors, activity on the CAN. (since

firmware 4.0)

constant orange CAN controller in “BUS WARNING” state. Receive signal time

monitoring indicates a constant or brief failure of the external
CAN signal source.

flickering orange CAN controller defective at times (“BUS WARNING”). Activity

on the CAN.
(since firmware 4.0)

flashing orange Firmware is being updated. Only switch off the module once

prompted to do so by the update program!

constant red CAN controller in “BUS ERROR” state, or loss of data in the

receiver because of buffer overflow. Transmit data are lost
because no CAN recipient is accepting the CAN messages,
or because of other CAN BUS malfunctions.

flashing red CAN controller indicates “BUS OFF”, it is not possible to

receive or transmit CAN messages. Check the bit rate of all
the connected nodes, and for reverse polarity or short circuits.
It may take a reset to reactivate the CAN controller.
If the other channel LEDs and the system LED are also flash
ing red, there is a hardware defect.

6.3.2 MX471B

BUS LED Function

constant green CAN BUS activated, no errors, no activity on the CAN
flickering green CAN BUS activated, no errors, activity on the CAN
constant orange CAN controller defective at times (“BUS WARNING”). No

activity on the CAN.

CANBus A4461-2.0 HBM: public 29

Functional description

FunctionBUS LED

flickering orange CAN controller defective at times (“BUS WARNING”). Activity

on the CAN.

constant red CAN controller indicates “BUS OFF”, it is not possible to

receive or transmit CAN messages.

Connection LED Function

constant green CAN BUS activated, no errors or failures
constant orange CAN controller in “BUS WARNING” state. Receive signal time

monitoring indicates a constant or brief failure of the external
CAN signal source.

flickering orange CAN controller defective at times (“BUS WARNING”). Activity

on the CAN.
(since firmware 4.0)

flashing orange Firmware is being updated. Only switch off the module once

prompted to do so by the update program!

constant red CAN controller in “BUS ERROR” state, or loss of data in the

receiver because of buffer overflow. Transmit data are lost
because no CAN recipient is accepting the CAN messages,
or because of other CAN BUS malfunctions. Computing
resources in the module are exceeded: Too many signals
have to be decoded and/or too many CAN messages are to
be sent.

flashing red CAN controller indicates “BUS OFF”, it is not possible to

receive or transmit CAN messages. Check the bit rate of all
the connected nodes, and for reverse polarity or short circuits.
It may take a reset to reactivate the CAN controller.
If the other channel LEDs and the system LED are also
flashing red, there is a hardware defect.

30 A4461-2.0 HBM: public CANBus

Functional description

6.4 CAN decoder: receiving CAN data

6.4.1 Remote frames (RTR)

A CAN master transmits remote frames to promptly
request data. None of the MX module types support
remote frames (RTR). These messages are discarded
when received.

6.4.2 User-defined data type selection

The CAN decoder constantly distinguishes between the
data format in which data are extracted from the CAN
message and the data format in which they are available
as a signal in the QuantumX / SomatXR system. The
CAN decoder behaves differently, depending on the com
bination of the two data types. This may seem confusing
at first, but it allows integer values to constantly be han
dled as such, so that the processing of the digital I/O
data is not corrupted and the floating point calculations
are as accurate as possible.

Once the data bytes have been received by the CAN
bus, they are handled as the raw data type, as specified
in the parameterization (“RawValueFormat”). The signal
that will later be used throughout the system is defined
by the output format (“SignalFormat”). The integer data
types will also be checked to establish whether they are
signed (INT32 and INT64) or not (UINT32 and UINT64).

The data type for interpreting the mode-dependent signal
is always assumed to be UINT64. The mode length can
be selected between 1 and 64. It is not possible to scale
the “ModeValue”; nor does there seem to be any point to
doing so.

CANBus A4461-2.0 HBM: public 31

Functional description

If the selected combination of start bit and length is
invalid, the CAN decoder will not change over to the
conversion rule and set an error message. The CAN
decoder continues to work with the old rule, until a valid
one has been transmitted.

6.4.3 Calculation rule data types

Since firmware version 4.3.1, the rules described in the
table below apply to the conversion of data types, taking
into account the scaling calculation:

signal_value = ( raw_value * factor ) +
offset

To make sure that the calculation remains as accurate as
possible, and that integer values will not be corrupted
even when scaling is used, the scaling calculation is
divided into two processes. The data types for “raw”,
“factor” and “offset” are calculated differently.

6.4.4 Floating point scaling

Provided at least one of the values of “factor” or „offset“
have been parameterized with a floating point value, the
CAN raw signal “raw_value” will first be converted to a
floating point value (REAL64). In this case,“factor” and
“offset” are always of the floating point data type
(REAL64). The intermediate result will then be converted
into the data type that has been specified as the “Signal
Format”.The application of floating point numbers means
that rounding errors are inherent.

If the data type for “SignalFormat” is 64-bit integer, the
decimal places of the floating point value are truncated
before the final conversion from REAL64 to UINT64 or

32 A4461-2.0 HBM: public CANBus

Signal format

INT32

1)

1)

1)

1)

REAL32

REAL64

UINT32

Functional description

INT64. In all other cases, the floating point value is first
rounded to an integer.

The table below only applies to the “floating point scaling”
described here:

Data format used

for

“factor” and

“offset”

Data format

Raw data

REAL32
REAL64

UINT32

INT32

UINT64

INT64
REAL32
REAL64

UINT32

INT32

UINT64

INT64
REAL32

REAL64

UINT32

INT32

UINT64

INT64
REAL32
REAL64

INT32

INT64

UINT32
UINT64

Raw data are con

verted to the

calculation format

REAL64 REAL64

REAL64 REAL64

REAL64 REAL64

REAL64 REAL64

CANBus A4461-2.0 HBM: public 33

Functional description

REAL32
REAL64

2)

INT64

UINT64

1)

When the intermediate value (REAL64) is converted to the 64-bit data format of the signal format,
it is rounded up to the next integer.

2)

When the intermediate value (REAL64) is converted to the 64-bit data format of the signal format,
the decimal places are truncated.

2)

UINT32

INT32

UINT64

INT64
REAL32
REAL64

INT32

INT64

UINT32
UINT64

REAL64 REAL64

REAL64 REAL64

REAL32: single precision floating point, size 32-bit,
gemäß IEEE 754

REAL64: double precision floating point, size 64-bit, as
per IEEE 754

Conversion of the example in the module highlighted in
color:

C: int32_t raw;

double factor, offset;
int32_t signal = (int32_t)

(round((double)raw * factor) +
offset) );

Pascal: var

raw: LongInt;
factor, offset: Double;
signal: LongInt

begin

signal:= LongInt(Round ((Int64(raw)
* factor) + offset );

34 A4461-2.0 HBM: public CANBus

Functional description

6.4.5 CAN raw data reception

All CAN messages received are available as unfiltered
signals. At present, the signal can be transmitted by
streaming protocol (<DaqAvailable>), however, not within
the module group via Firewire (<RtAvailable>).

When raw data reception has been activated, the signal
list displays the signal for Connector 2 with a reference:
„CanRawReceiver_Connector2.Signal1“

6.4.5.1 CAN raw data in the signal

The signal makes available the following data:
CAN-Id, with Bit 31 determining the Frame format:

Bit 31 = 0: Base Format; Bit 0010: CAN-Identifier.
Bit 31 = 1: Extended Format: Bit 0028: CAN-Identifier

DLC: Number of data bytes; value between 0 and 8
Data: 0 to 8 bytes are transmitted in the signal, depen

ding on “DLC”.

The time stamp on data reception is part of the higher­level streaming data.

Details on signal encoding can be found in the docu
mentation defining the streaming protocol.

6.4.5.2 Parameterization

Parameterization individually switches on and off CAN
raw data reception for each CAN connector (<Active>).
In addition, the signal, like many other signals in the

CANBus A4461-2.0 HBM: public 35

Functional description

QuantumX / SomatXR system, includes a name
(<ChannelName>) and an ID specifying whether this
name was set by the user or taken from the default
settings (<OriginOfName>).

6.4.6 Integer scaling

If the values for both “factor” and “offset” have been
parameterized with an integer, particular emphasis is
given to the accuracy of the integer. The aim is to avoid
rounding errors that are critical if the integer values rep
resent boolean states.

The “raw_value” raw data are also taken from the CAN
bus in the raw data format (“RawValueFormat”) first, but
are then converted to a calculation format that depends
on the data type of “signal_value” (“SignalFormat”), as
given in the table below. The “factor” and “offset” are also
calculated with the data type given in the table. The inter
mediate result is ultimately converted to the data format
specified as the “SignalFormat”.

The table below only applies to the “integer scaling”
described here.

36 A4461-2.0 HBM: public CANBus

Functional description

Signal format

REAL32

REAL64

INT32

UINT32

Data format

Raw data

REAL32
REAL64

UINT32

INT32

UINT64

INT64
REAL32
REAL64

UINT32

INT32

UINT64

INT64
REAL32 REAL32

REAL64 INT64

UINT32

INT32

UINT64

INT64
REAL32 REAL32
REAL64 REAL64

INT32 INT32

INT64 INT64

UINT32 UNIT32
UINT64 UNIT64

Raw data are con

verted to the

calculation format

REAL64 REAL64

REAL64 REAL64

INT32

INT64

Data format used

for

“factor” and

“offset”

INT32

INT32

UNIT32

CANBus A4461-2.0 HBM: public 37

Functional description

INT64

UINT64

REAL32: single precision floating point, size 32-bit,
gemäß IEEE 754

REAL64: double precision floating point, size 64-bit, as
per IEEE 754

REAL32
REAL64

UINT32

INT32

UINT64

INT64
REAL32
REAL64

INT32 INT32

INT64 INT64

UINT32
UINT64

INT64 INT64

INT64

UNIT64 UNIT64

INT64

Conversion of the example in the module highlighted in
color:

C: double raw;

int32_t factor, offset;
int32_t signal = (int32_t)

( ((int64_t)raw * factor) +
offset );

Pascal: var

raw: Double;
factor, offset: LongInt;
signal: LongInt

begin

signal := LongInt((Int64(raw)
* factor) + offset );

38 A4461-2.0 HBM: public CANBus

Functional description

6.5 CAN encoder (mappable CAN transmit messages)

6.5.1 Motivation

Since firmware version 4.6, the MX471B can send
several signals within a CAN message, and measured
values can also be converted to an integer format, with a
resultant signal length of 1 to 64 bits.

With the generally defined CAN encoder, it is possible to
send up to 128 signal sources in up to 128 different CAN
messages, with several different signal sources being
“mapped” within a single CAN message. This allows up
to 64 signal sources to be transmitted in each CAN
message. The number of signal sources is determined
on the basis of compatibility with the previous
<CanTransmit> implementation, and is limited by the
internal system resources.

The user parameterizes an individual CAN identifier
<Identifier> for each CAN Nachricht, as well as the
frame format <ExtendedFrame> (Base/Extended Identi
fier) and a name <ChannelName>, to appear in the PC
software interfaces.

6.5.2 Signal source definition

What is sent and where does it go?

Data from several different sources can be transmitted in
each CAN Nachricht. As data 1 bit in length can also be
“mapped”, it is conceivable to have up to 64 different
sources in a single CAN message. The signal source in
the system (e. g. “ModuleReference” = “UUID = 1234”,
“SignalReference” = “AnalogIn_Connector1.Signal2”), the

CANBus A4461-2.0 HBM: public 39

Functional description

<DataFormat> (e. g. Real32, Integer32) and the kind of
coding <BitSequence> (Intel/Motorola) are defined for
each source. The sources can be measured values from
the QuantumX / SomatXR system transmitted via
FireWire, or can also be decoded data received by the
CAN bus.

A signal source is typically taken from another MX
module. The “ModuleReference” must be set. If the
“ModuleReference” points to the module itself, or if its
specification is left empty, the data to be received at this
or another CAN bus connection within this module, can
act as the transmit data source. The module behaves as
a “gateway”.

The point at which the data are written and the number of
bits in the CAN message are defined for each source,
see Section 5.4.

The CAN message in which the data defined in this way
will be sent, is specified with the parameters <Identifier>
and <ExtendedFrame>. These parameters can also be
found in the XML Subtree <CanMessage>, which defines
the CAN message and its transmission. This means that
the <CanMessage> only has to be parameterized once.
The different signal sources refer directly to the relevant
CAN message.

6.5.3 Measured value scaling

As with the decoder of the CAN receiver, signals from
the source can be scaled with <Factor> and <Offset>,
before they are transmitted. This is particularly important
if you want to transmit a floating point value as an inte
ger, a practice that is widespread in the CAN world.
For example, if you want to send the floating point value
with an accuracy of 3 decimal places as an integer, you

40 A4461-2.0 HBM: public CANBus

Functional description

imagine a decimal point at the third position of the integer
value and multiply the source signal by 1000. (“1.2345“
becomes “1234”).

Scaling is carried out with double precision (REAL64), i.e.
the resulting integer value will be rounded in the lower
bits.

Selection of the UINT64 data type guarantees one-to-one
transfer of all bits, with no scaling being performed. The
values in <Factor> and <Offset> will be ignored.

6.5.4 Data types and bit positions of a measured value

Measured values usually occur in the system as REAL32
(float). If the measured values are also to be transmitted
as a floating point value, the data format <DataFormat>
must be chosen accordingly. The number of bits to be
transmitted is defined in <SignalLength> as 32 (float) or
64 (double).

Type conversion is also possible, so that the data in the
CAN message will be sent as integers, with any length
between 1 and 64 bits. The resolution of the measured
value is therefore variable. This achieves a differenzierte
Datentyp-Umwandlung.

First the measured value is scaled as a floating point
value. If the transmit data format <DataFormat> is
selected as an integer value, the conversion to a 32-bit or
64-bit integer takes place now. Then, starting with the
MSB of the resultant integer value, the number of bits
defined in <SignalLength> are mapped into the CAN
message. This means that the most significant bits of a
measured value are always transmitted.

CANBus A4461-2.0 HBM: public 41

Functional description

Ultimately, the parameter <StartBit> defines at which
point the resultant data are included in the CAN mes
sage, and <BitSequence> defines which rule is to be
applied (INTEL or MOTOROLA, see Chapter 6).

The parameters <DataFormat>, <StartBit>, <Signal
Length> and <BitSequence> have a corresponding
meaning in the CAN decoder, which is why no other
names for the parameters are selected here either.

6.5.5 Transmit data in the event of an error

If the signal source has yet to return a value, or if the sig
nal source transmits an error value (e. g. because of
overloading, or an unconnected sensor), a defined value
must be entered in the CAN message. The user can
select this value with the XML parameters for
<ValueOnError>.

“Internal”: The selection of the error value is determined
by the module. If <DataFormat> defines a floating point
value, “2,0E15” is sent in the event of an error. If <Type>
is set to “BitArray”, or <DataFormat> is parameterized to
an integer or boolean, “0” is transmitted. This
corresponds to the behavior of the module when
<ValueOnError> did not yet exist, and is the factory set
ting.

“Float”: This selection is only permitted if the
<DataFormat> defines a floating point value. Then im
Fehlerfall der Wert aus <Value> gesendet.

“Integer”: This selection is only permitted if the
<DataFormat> defines an integer value. Then the value
from <Value> is transmitted in the event of an error.

“Hex”: This selection is valid for all values of
<DataFormat>. In the event of an error, the hex string is

42 A4461-2.0 HBM: public CANBus

Functional description

sent as a hexadecimal numerical value, taking
<BitSequence> into account. The number of bits is deter
mined by the <SignalLength> of the source. The bits of
the error value are transmitted, starting with Bit 0 of the
error value.

6.5.6 CAN message parameters

How are CAN messages transmitted?

The contents of a CAN message, that is, which source
data are to be “mapped” in which CAN message at which
point, are defined in the subtree <Source>. The header
of the CAN message is defined in the <CanMessage>
subtree.

The parameters <Identifier> and <ExtendedFrame> in
the subtree <Source> establish the <CanMessage> into
which this signal source is to be “mapped”.

6.5.6.1 Data length of the CAN message

The data in CAN messages are always multiple bytes.
The length of the CAN message corresponds to the
number of bytes required to transmit all the signal
sources actively “mapped” into this CAN message.

If, for example, only the first 18 data bits of a CAN mes
sage are mapped, the data length of the CAN message
<ByteCount> is 3 bytes.

It is always possible and acceptable to have “gaps” in the
CAN message. Their unspecified bits are transmitted
with “0”.

CANBus A4461-2.0 HBM: public 43

Functional description

The parameter <ByteCount> provides information about
the length of the currently parameterized CAN message.
It can only be read out, it cannot be set.

If you want to reduce the load on the CAN bus as a test,
you can temporarily set the <Active> tag of a <Source>
to “false”. The remaining parameters for this source are
retained, but are not active. When the source is later
reactivated by setting the <Active> tag to “true”, all the
previously defined parameters of this source become
active again. When the inactive source at the end of a
CAN message is “mapped”, the number of data bytes of
the CAN message is shortened accordingly. If, on the
other hand, it is situated between additional sources, the
data length of the CAN message does not change, the
relevant bits of this source are filled in with “0”.

6.5.7 Example of the different signal sources within

Data from different sources are to be transmitted within a
single CAN message.

a single CAN message

First a measured value is coded into the CAN message
as a float value. Then a float value of a mathematical unit
is transmitted at bit position 33 as an 18-bit long signed
integer taking 2 decimal places into account. Ultimately,
starting from bit position 52, three bits are sent with
switching states that were previously received in the
same module via the CAN bus.

Required parameters, specified by the user. Bold italic
marks the values that are mandatory, in order to meet
the above conditions:

The same values for <Identifier> and <Frameformat>
apply to all sources.

44 A4461-2.0 HBM: public CANBus

Functional description

Source 1:

Input: ModuleReference = “UUID = 001234”,
Signal Reference = “AnalogIn_Connector1.Signal2”
Type = MeasVal
DataFormat = REAL32
Factor = 1.0
Offset = 0.0
BitSequence = INTEL
StartBit = 0
(SignalLength wird automatisch auf 32 gesetzt auf
grund DataFormat = REAL32)

Source 2:

Input: ModuleReference = “UUID = 001256”,
Signal Reference = “Math_Index2.Signal1”
Type = MeasVal
DataFormat = Signed Integer32
Factor = 100.0 (verschiebt den Messwert der Signal
quelle um 2 „gedachte“ Nachkommastellen)
Offset = 0.0
StartBit = 33
SignalLength = 18
BitSequence = INTEL
(Nachdem der Float-Wert mit 100 multipliziert und
danach in einen Signed-Integer32-Wert konvertiert
wurde, werden aus diesem Integer-Wert die Bits 31
bis 8 INTEL-codiert gesendet)

Source 3:

Input: ModuleReference = “ ”, SignalReference =
“CanReceiver_Connector2_Decoder1.Signal1”
Type = MeasVal
DataFormat = Unsigned Integer32
Factor = 1.0
Offset = 0.0
StartBit = 52
SignalLength = 3

CANBus A4461-2.0 HBM: public 45

Functional description

Bit 55

(1 bit)

0

(not used)

Bits 54 …

52

(3 bits)

Signal

from the

CAN

decoder

(Source 3)

As packets can only ever be transmitted in byte size on
the CANbus, this CAN message has a data length of 7
bytes.

With the CAN Receive functionality (CAN decoder
<CanInChannel>) in the MX840B, or of another CAN
channel of an MX471B, this CAN message can be
directly decoded again to four different signals, by taking
over <DataFormat>, <StartBit>, <BitSequence> and
<SignalLength> from the above parameterization.

BitSequence = INTEL
This produces this CAN message

Bit 51 …

49 (3

bits)

0 0 0

(not used)

Bits 48 … 33

(24 bits)

Measured
value from
the mathe

matical unit

(Source 2) as

an 18-bit inte

ger value

Bit 32

(1 bit)

0

(not used)

Bits 31 … 0

(32 bits)

Measured value

from the analog
input (Source 1)

as a float value

(REAL32)

6.5.8 Transmission type

When does transmission take place?

For a CAN message, <TransmissionType> defines when
the message on the CAN bus is to be sent. There are
various modes to choose from. The transmitted value is
always the one actually present at this time. If a value for
a source is not yet known, the value parameterized in
Section 5.5 is transmitted.

46 A4461-2.0 HBM: public CANBus

Functional description

6.5.8.1 Control

A CAN message is only sent when a control indicating
the connector and the index of the CAN message has
been transmitted. A control can be transmitted, for exam
ple, by using the MX Assistant menu or button.

6.5.8.2 Timer

The user defines a time interval (in microseconds). The
CAN messages are sent automatically at this time inter
val. If “Interval = 0” is set, no CAN messages are sent.

The transmission of a CAN message can also be trig
gered by a control (see Section 5.8.1).

The data in the CAN message correspond to the
instantaneous value and are not synchronized to the data
source.

In the MX471B, we implement timer resolution by count
ing the isochronous events (1200 Hz). The period of the
CAN messages thus corresponds to multiples of
1/1200 seconds.

In the MX840B, triggering occurs in 1 ms steps, with the
shortest period being 10 ms per CAN message.

6.5.8.3 SourceChange

If the value of the source for the value most recently sent
changes by the absolute value <Delta>, the CAN mes
sage is transmitted. <Delta> is defined in the parameters
of each source. If several measured values are “mapped”
in a CAN message, the entire CAN message is sent
when a source changes.

CANBus A4461-2.0 HBM: public 47

Functional description

The transmission of a CAN message can also be trig
gered by a control (see Section 5.8.1).

6.5.8.4 IsoEvent

This corresponds to the behavior implemented in the
MX471B up to and including firmware version 4.4: The
CAN message is sent when one of the “mapped” signal
sources has been received isochronously (via Firewire).
<Divisor> can also be used to establish that only every n
received isochronous events are sent. This can reduce
the workload of the CAN bus, if measured values with
low dynamics (e. g. temperature) are to be sent,
for example.

In addition, the transmission of a CAN message can also
be triggered by a control item (see Section 5.8.1).

6.5.9 Constraints for MX840B

The MX840B is able to send measured values obtained
within the module via CAN messages. There are clear
constraints here, for reasons of performance. CAN map
ping is not possible.

To maintain compatibility with the new XML trees in the
MX471B, the MX840B will also only use the new XML
trees. This allows both the module types to be
parameterized with the same software interface.

The MX840B will also only be able to send a maximum of
10 different CAN messages, and each CAN message will
only be able to have 1 source, corresponding to an ana
log measured value within the module.

So these parameters cannot be freely selected in the
MX840B, they are fixed as stated:

48 A4461-2.0 HBM: public CANBus

Functional description

Type = MeasVal
DataFormat = REAL32
Factor = 1.0
Offset = 0.0
StartBit = 0 bzw. 7 (depending on „BitSequence“)
SignalLength = 32
BitSequence = INTEL or MOTOROLA
CanMessage TransmissionType = “Control” or
“Timer”

A received CAN message cannot be forwarded via CAN.
The signal source must also be taken from within the
module, that is:

ModuleReference (empty or “UUID=[own UUID]”),

SignalReference = “AnalogIn_Connector[2…8].Sig
nal1”

The parameters from <ValueOnError> are supported.

For timer-controlled transmission, a measured value can
only be sent every 10 ms, or less often. Please note that
up to and including firmware version 4.4, the parameter
<Period> has been given in milliseconds. To ensure that
the future use of this parameter is the same as in the
MX471B, <Period> must be given in microseconds in the
MX840B as well in future, with a resolution of 1000 μs.

6.6 Data bit numbering systems according to the vector DBC format

6.6.1 Numbering systems used in QuantumX / SomatXR parameterization

The data for the measured values can be interpreted in
different numbering systems.

CANBus A4461-2.0 HBM: public 49

Functional description

The formats “INTEL Standard”, “MOTOROLA Forward”
and “MOTOROLA Backward” use the following “saw
tooth” data bit numbering system:

The formats “INTEL Sequential” and “MOTOROLA
Sequential” use the following sequential data bit
numbering system. It corresponds to the sequence in
which the bits are received by the CAN bus:

Byte 0 (from the CAN controller)
Bit 7 6 5 4 3 2 1 0

Byte 1
15 14 13 12 11 10 9 8

Byte 0 (from the CAN controller)
Bit 0 1 2 3 4 5 6 7

Byte 1
0 1 2 3 4 5 6 7

6.6.1.1 INTEL Standard format

For signals in “INTEL Standard” format, the stated “Start
bit” is the position of the least significant bit (“lsb”) of the
measured value, and the bit significance increases to the
left, numbering from the start bit, as shown in the exam
ple below.

The following applies for data reception in the CAN
decoder: If the data type is signed, this is always
assumed in the “msb” and is filled with 1 when right­shifting to the intermediate value. If the “BitSequence” or
“ModeBitSequence” element has the value “1”, this

50 A4461-2.0 HBM: public CANBus

Functional description

decoding is used both for the measured value and for the
mode information.

“INTEL Standard” format example, start bit = 9,
length = 12:

Bit no. within the data byte

7 65432 1 0

7 6 5 4 3 2 1 0 0

15

²

23 22 21

31 30 29 28 27 26 25 24
39 38 37 36 35 34 33 32 4
47 46 45 44 43 42 41 40 5
55 54 53 52 51 50 49 48 6
63 62 61 60 59 58 57 56 7

14

²

13

²

12

²

20

msb ²19²

11

²

10

²

18

²

9

Start bit/

lsb

17

²

8 1

16

²

2

3

index

Data

6.6.1.2 MOTOROLA Forward MSB format

For signals in the internal CANdb “MOTOROLA Forward
MSB” format, the stated “Startbit” is the position of the
most significant bit (“msb”) of the measured value, and
the bit significance decreases to the right, as shown in
the example below.

The following applies to receiving data in the CAN
decoder: If the data type is signed, this is always
assumed in the “msb” and when receiving CAN mes
sages, is filled with 1 when right-shifting to the
intermediate value. If the “BitSequence” or “ModeBitSe
quence” element has the value “0”, this decoding is used

CANBus A4461-2.0 HBM: public 51

Functional description

both for the measured value and for the mode informa
tion.

Internal CANdb “MOTOROLA Forward MSB” format
example, start bit = 13, length = 12:

Bit no. within the data byte

7 6 5 43210
7 6 5 4 3 2 1 0 0

13

15 14

23

²

31 30 29 28 27 26 25 24 3
39 38 37 36 35 34 33 32 4
47 46 45 44 43 42 41 40 5
55 54 53 52 51 50 49 48 6
63 62 61 60 59 58 57 56 7

22

²

Start bit/

msb

21

²

12

²

20

²

11

²

19

²

10

²

18

² lsb

9

²

17 16 2

8

²

1

index

Data

6.6.2 Other numbering systems not used in QuantumX / SomatXR parameterization

The following tables are for your information, so that
other numbering systems can be transposed into a for
mat that is used for MX parameterization.

52 A4461-2.0 HBM: public CANBus

Functional description

6.6.2.1 MOTOROLA Forward LSB format

Internal CANdb “MOTOROLA Forward LSB” format
example, start bit = 18, length = 12:

Bit no. within the data byte

7 6543 2 10

7 6 5 4 3 2 1 0 0

15 14

23

²

31 30 29 28 27 26 25 24 3
39 38 37 36 35 34 33 32 4
47 46 45 44 43 42 41 40 5
55 54 53 52 51 50 49 48 6
63 62 61 60 59 58 57 56 7

22

²

13

msb ²12²

21

²

20

²

11

²

19

²

10

²

18

Start bit/

lsb

9

²

17 16 2

8

²

1

index

Data

CANBus A4461-2.0 HBM: public 53

Functional description

6.6.2.2 MOTOROLA Backward format

In this format, numbering starts from the last bit to be
sent. This means that the start bit depends on the num
ber of bytes to be sent.

Internal CANdb “MOTOROLA Backward” format
example, data length = 8, start bit = 42, length = 12:

Bit no. within the data byte

7 6543 2 10

63 62 61 60 59 58 57 56 0

55 54

47

²

39 38 37 36 35 34 33 32 3
31 30 29 28 27 26 25 24 4
23 22 21 20 19 18 17 16 5
15 14 13 12 11 10 9 8 6

7 6 5 4 3 2 1 0 7

46

²

53

msb ²52²

45 44

²

51

²

43

²

50

²

42

Start bit/

lsb

49

²

41 40 2

48

²

1

index

Data

The same use information, sent in 3 data bytes:

54 A4461-2.0 HBM: public CANBus

Functional description

Internal CANdb “MOTOROLA Backward” format, data
length = 3, start bit = 2, length = 12:

Bit no. within the data byte

7 6543 2 10

23 22 21 20 19 18 17 16 0

15 14

7

²

0 12345 6 7

0 1 2 3 4 5 6 7 0

8

²

16 17 18

24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39 4
40 41 42 43 44 45 46 47 5
48 49 50 51 52 53 54 55 6
56 57 58 59 60 61 62 63 7

6

²

9 10

13

msb ²12²

5 4

²

6.6.2.3 INTEL Sequential format

Internal CANdb “INTEL Sequential” format example, start
bit = 14, length = 12:

Bit no. within the data byte

11

²

²

19

msb ²20²

11

²

3

²

12

²

10

²

2

Start bit/

lsb

13

²

21

²

9

²

1 0 2

14

Start bit/

lsb

22

²

8

²

15 1

23

²

1

2

3

index

Data

index

Data

CANBus A4461-2.0 HBM: public 55

Functional description

6.6.2.4 MOTOROLA Sequential format

Internal CANdb “MOTOROLA Sequential” format
example, start bit = 10, length = 12:

Bit no. within the data byte

0 1234 5 67

0 1 2 3 4 5 6 7 0

8 9

16

²

24 25 26 27 28 29 30 31 3
32 33 34 35 36 37 38 39 4
40 41 42 43 44 45 46 47 5
48 49 50 51 52 53 54 55 6
56 57 58 59 60 61 62 63 7

17

²

10

msb ²11²

18 19

²

12

²

20

²

13

²

21

Start bit/

lsb

14

²

22 23 2

15

²

1

index

Data

56 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CCP / XCP-on-CAN

7 QuantumX / SomatXR and CCP / XCP-on-CAN

7.1 Introduction to CCP and XCP

Modern Electronic Control Units (ECUs) in vehicles com
municate in different protocols with each other or with
tuning or analysis tools. The “Universal Measurement
and Calibration Protocol “or short XCP is a modern proto
col focusing parameterization / calibration or tuning of
parameters and data fields of ECUs. As a side task one
can use XCP acquiring signal information from ECUs
which are normally not part of the standard ECU-2-ECU
communication - for example internal signaling or sensor
information of the ECU.

The physical connection between the measurement tool
and the ECU is still the same bus but the “measurement
and calibration protocol” is activated by separate tools
like data recorders or tuning tools. XCP has been
established as a world-wide by an ASAM working com
mittee (Association for Standardization of Automation
and Measuring Systems) as standard.

The “X” stands for the variable and interchangeable
transport layer, which might be CANbus (XCP-on-CAN),
FlexRay (XCP-on-FlexRay) or Ethernet (XCP-on-Ether
net). XCP succeeds CCP (CAN Calibration Protocol),
which has been developed with the conceptual idea of a
read and write access to internal ECU data only via CAN.

XCP offers the ability to acquire measured values “event
synchronous” to processes in ECUs. This ensures
consistency of the data between one another.

CANBus A4461-2.0 HBM: public 57

QuantumX / SomatXR and CCP / XCP-on-CAN

7.2 MX471B and CAN / XCP-on-CAN

The MX471B offers 4 individually configurable CAN ports
which can be parameterized to work on CCP or XCP-on­CAN and thus to read signal values from ECUs. In this
mode the MX471B works as logger. Once communica
tion to the ECU is established, the ECU sends data in a
cyclic period.

CX22B-W
Recorder

MX840B
Universal

MX471B
CAN

ECU

Fig. 7.1 Example configuration MX471B and communication

over CCP / XCP-on-CAN

Preconditions

S ECU supports one of the following protocols:

S CCP version 2.1 or higher

S XCP-on-CAN Version 1.1 or higher

S .a2l parameter description file from ECU supplier

available

58 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CCP / XCP-on-CAN

S If ECU is locked by “Seed & Key” mechanism, corre

sponding *.skb file has to be available

S CANape version 10.0 or higher installed (might also

work with previous versions, but not tested)

S MX471B with latest firmware available

S Data Recorder CX22B-W or PC with latest MX

Assistant tool available

Hardware Setup

S Connect one of the MX471B ports to the CAN net

work

S Connect MX471B Ethernet port to a Laptop

MX Assistant

Fig. 7.2 Hardware Setup

CANBus A4461-2.0 HBM: public 59

QuantumX / SomatXR and CCP / XCP-on-CAN

7.3 Initialization per XML

The initialization is performed with XML parameters in file
"AddConnParam.xml", XPath:

…<CanBus><ECU>.

The content of a vector DBC file must be written to the
<DBC> tag as a string. If a "seed and key binary" file will
be used, its content must be written as a string to the
<SKB> tag.

Writing these data items initializes the CAN bus for the
CCP/XCP protocol.

If the XML tag <Active> was set to "1", processing starts
immediately. Otherwise processing does not begin until a
control item is written.

After the module is restarted the data items that were
previously entered in the XML tags are automatically
activated.

The "MXAssistant" PC software provides the "CAN bus" ­"Settings…" dialog in the "Channel" tab. The required
parameters can be set in the following "CCP / XCP via
CAN" dialog.

7.4 Starting and stopping with the "CANECU" control item

This control item can be used with firmware versions 4.8
and later.

If the <Active> tag has been set to "0", processing will
not begin until the "CANECU" control item is written.

As a precondition, protocol processing must have been
initialized by setting the <DBC> parameter and in some
cases also the <SKB> parameter.

60 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CCP / XCP-on-CAN

Processing can be stopped and started again at any time
using this control item. The "CANECU" control item uses
these parameters to start and stop:

Connector Number of the CAN bus connections

(„1…4“, „0“: all)

Index Index of the ECU, currently always "1".

Mode Choose the functionality "1": Start / Stop

Value Choose between Start ("1") and Stop ("0")

The "catman" PC software maps control in a correspon
ding dialog based on the control item.

7.5 General Workflow

Start CANape from Vector Informatik and read in the
*.a2l file. Now create a measurement configuration with
all the relevant signals you need acquire by MX471B.
Now convert the measurement configuration to a *.dbc
file.

Start MX Assistant and read in *.dbc and *.skb files (if
applicable) and download it to the device. Immediately
CCP or XCP-on-CAN communication will be started bet
ween ECU and MX471B. This service can also be
activated and deactivated by a script running in catman
(under work).

MX Assistant

CANBus A4461-2.0 HBM: public 61

QuantumX / SomatXR and CCP / XCP-on-CAN

Step 1 - Create Measurement Configuration using
CANape

S ·Create new CANape project

S ·Create new CCP or XCP device, depending on the

protocol that is implemented on the ECU

S ·Create a measurement configuration with all the

signals that you want to record with MX471B. Take
care that measurement mode is cyclic. Polling mode
is not yet suported.

Step 2 – Configure “Seed & Key” option and adjust
“Init” settings using CANape

S ·If the ECU does not support “Seed & Key” option you

have to disable it in the Protocol Settings of the
Device Configuration

S ·If the ECU supports “Seed & Key” you have to select

the *.skb file.

62 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CCP / XCP-on-CAN

CANBus A4461-2.0 HBM: public 63

QuantumX / SomatXR and CCP / XCP-on-CAN

S ·Switch to Expert settings tab. Modify INIT_RETRIES

= 100 and INIT_RETRY_DELAY = 2000 (recom
mended values).
MX471B will try to start communication with ECU 100
times and every 2000ms. This is important if ECU is
powered up after MX471B.

64 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CCP / XCP-on-CAN

Step 2b – Only for XCP-on-CAN – Adjust Protocol
Settings in Device configuration (not necessary for
CCP):

S ·Set parameter”DAQ_CALCU

LATE_FIRST_PIDS_WHEN_OFFLINE” to “yes”

CANBus A4461-2.0 HBM: public 65

QuantumX / SomatXR and CCP / XCP-on-CAN

S ·Set “Consistency mode” to “ODT”

and “Identification field type” to “Absolute”

66 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CCP / XCP-on-CAN

Step 3 - Export Measurement configuration to a *.dbc
file using CANape:

S ·Select ECU in Logger Configuration (Tools -> Logger

configuration) and click on “Create file” button.

S => *.dbc file is created in your CANape project direc

tory

Step 4 – Configure MX471B using *.dbc file and MX
Assistant:

S ·Open MX Assistant and connect to your MX471B

S ·Select Channel 1 of the MX471B and open CAN Bus

settings

S ·Enter Bit rate of your CAN network

S ·Activate Termination if necessary

S ·Select the *.dbc file created in step 3

S ·If ECU is locked by Seed & Key mechanism you

have to select the *skb file.

S ·If ECU is not locked, leave field blank

S ·Click OK button

CANBus A4461-2.0 HBM: public 67

QuantumX / SomatXR and CCP / XCP-on-CAN

If the check box next to Active is set, processing starts
immediately. If the check box is not selected, processing
does not begin until a control item is written.

68 A4461-2.0 HBM: public CANBus

QuantumX / SomatXR and CCP / XCP-on-CAN

Result: All configured signals are now visible on
CAN Bus 1

Step 5 – You can now open Catman and start mea
surement

Configuration of a Gateway Mode

The MX471B can also be used as a gateway transferring
XCP-on-CAN or CCP signals to CAN. In this mode XCP
or CCP Messages are received on one port of the
MX471B and are sent out as standard CAN messages
on another port.

Configuration steps in MX Assistant

1. Switch to Outputs tab

2. Uncheck checkbox “Show only isochronous”

3. Drag and drop signals from Sources section to a CAN
Output.

CANBus A4461-2.0 HBM: public 69

QuantumX / SomatXR and CCP / XCP-on-CAN

4. Adjust CAN IDs in that way, that every signal has its
own unique ID. In this example 385, 386, 387, 388:
(An automatic assignment of consecutive IDs can be
done via CAN bus settings -> Assign message IDs).

70 A4461-2.0 HBM: public CANBus

8 Glossary

QuantumX / SomatXR and CCP / XCP-on-CAN

A2L

Extension of a Device Description File of an ECU.
Standardized by ASAM.

ASAM

Association for Standardisation of Automation and
Measuring Systems

CCP

CAN Calibration Protocol. Standardized by ASAM.

DBC

Data Base CAN: File format for CAN communication

ECU

Electronic Control Unit

Seed & Key

Mechanism to lock the ECU against unauthorized
access

XCP

Universal Calibration Protocol. Can be used on diffe
rent networks: CAN, FlexRay, Ethernet. Standardized
by ASAM.

CANBus A4461-2.0 HBM: public 71

QuantumX / SomatXR and CCP / XCP-on-CAN

72 A4461-2.0 HBM: public CANBus

Operating Manual | Bedienungsanleitung

English Deutsch

/

CANBus

Empfangen / Senden

Deutsch

1 Sicherheitshinweise 5......................................

2 Verwendete Kennzeichnungen 12.............................

2.1 In dieser Anleitung verwendete Kennzeichnungen 12..............

3 QuantumX / SomatXR‐Dokumentation 14......................

4 Der CANBus 15..............................................

5 QuantumX / SomatXR und CAN 16............................

5.1 Übersicht 16.................................................

5.2 Anschluss CANbus 17.........................................

5.2.1 Zustandsanzeige LEDs der Geräte 20...........................

5.2.2 CAN-Nachrichten empfangen 22................................

6 Funktionsbeschreibung 24...................................

6.1 Globale Parameter 24.........................................

6.1.1 Bitraten 24...................................................

6.1.2 Terminierung des CANBus 24..................................

6.1.3 Fehlerbehandlung 25..........................................

6.2 Fehlerereignisse 26...........................................

6.2.1 Erfassen von Fehlern des Sende‐ und Empfangsweges 26.........

6.2.2 Verhalten der LED und des Fehlerstatus 26......................

6.2.3 Mögliche Fehlerursachen im CAN‐Betrieb 27.....................

6.2.3.1 CANBus Warning, CANBus Error, CANBus OFF 27................

6.2.3.2 CAN „Receiver Overrun“ 27.....................................

6.2.3.3 CAN „Transmitter Overrun“ 28...................................

6.2.3.4 CAN Dekoder „Timeout“ 28.....................................

6.2.3.5 CAN Dekoder „Loss of Signal“ 28................................

6.2.3.6 Modul‐Ressourcen 29..........................................

6.3 Zustandsanzeige per LED 29...................................

6.3.1 MX840B 29..................................................

6.3.2 MX471B 30..................................................

6.4 CAN‐Dekoder: Empfang von CAN‐Daten 32......................

2 A4461-1.0 HBM: public CANBus

6.4.1 Remote‐Frames (RTR) 32.....................................

6.4.2 Benutzerdefinierte Auswahl der Datentypen 32...................

6.4.3 Datentypen der Rechenvorschrift 33.............................

6.4.4 Fließkomma‐Skalierung 33.....................................

6.4.5 CAN‐Rohdaten‐Empfang 37....................................

6.4.5.1 CAN‐Rohdaten im Signal 37.....................................

6.4.5.2 Parametrierung 37.............................................

6.4.6 Ganzzahl‐Skalierung 38.......................................

6.5 CAN‐Encoder (Mappable CAN‐Sende‐Nachrichten) 41............

6.5.1 Motivation 41.................................................

6.5.2 Definition der Signalquellen 41..................................

6.5.3 Skalierung des Messwertes 42.................................

6.5.4 Datentypen und Bit‐Positionen eines Messwertes 43..............

6.5.5 Sendedaten im Fehlerfall 44....................................

6.5.6 Parameter der CAN‐Nachricht 45...............................

6.5.6.1 Datenlänge der CAN‐Nachricht 45...............................

6.5.7 Beispiel für verschiedene Signalquellen innerhalb einer einzigen

CAN‐Nachricht 46............................................

6.5.8 Transmission‐Type 49.........................................

6.5.8.1 Control 49....................................................

6.5.8.2 Timer 49......................................................

6.5.8.3 SourceChange 50.............................................

6.5.8.4 IsoEvent 50...................................................

6.5.9 Einschränkungen für MX840B 51...............................

6.6 Zählweisen der Datenbit gemäß Vector‐DBC‐Format 52...........

6.6.1 Zählweisen, in QuantumX / SomatXR‐Parametrierung genutzt 52...

6.6.1.1 Format INTEL‐Standard 53.....................................

6.6.1.2 Format MOTOROLA Forward MSB 54............................

6.6.2 Weitere Zählweisen, nicht in QuantumX / SomatXR‐Parametrierung

genutzt 55...................................................

6.6.2.1 Format MOTOROLA Forward LSB 56............................

6.6.2.2 Format MOTOROLA Backward 56...............................

6.6.2.3 Format INTEL Sequential 58....................................

6.6.2.4 Format MOTOROLA Sequential 59..............................

CANBus A4461-1.0 HBM: public 3

7 QuantumX / SomatXR und CCP / XCP-on-CAN 60..............

7.1 Einführung in CCP und XCP 60.................................

7.2 MX471B und CAN / XCP-on-CAN 61............................

7.3 Initialisierung per XML 63......................................

7.4 Start und Stopp per Control „CANECU“ 64.......................

7.5 Allgemeiner Arbeitsablauf 65...................................

8 Glossar 76..................................................

4 A4461-1.0 HBM: public CANBus

1 Sicherheitshinweise

Hinweis

Die hier aufgeführten Sicherheitshinweise gelten auch für
das Netzteil NTX001 und die Modulträger BPX001 und
BPX002.

Bestimmungsgemäße Verwendung

Ein Modul welches über den jeweiligen Anschluss an den
CANbus integriert wird, ist ausschließlich für Mess‐ und
Testaufgaben zu verwenden. Jeder darüber hinausge
hende Gebrauch gilt als nicht bestimmungsgemäß.

Zur Gewährleistung eines sicheren Betriebes darf das
Modul nur nach den in der allgemeinen Bedienungs
anleitung und den in diesem Dokument dargestellten
Angaben betrieben werden. Bei der Verwendung sind
zusätzlich die für den jeweiligen Anwendungsfall erforder
lichen Rechts‐ und Sicherheitsvorschriften zu beachten.
Sinngemäß gilt dies auch bei Verwendung von Zubehör.

Sicherheitshinweise

Vor jeder Inbetriebnahme der Module ist eine Projektie
rung und Risikoanalyse vorzunehmen die alle Sicher
heitsaspekte der Automatisierungstechnik berücksichtigt.
Dies betrifft vor allem den Personen‐ und Anlagenschutz.

Bei Anlagen, die aufgrund einer Fehlfunktion größere
Schäden, Datenverlust oder sogar Personenschäden
verursachen können, müssen zusätzliche Sicherheitsvor
kehrungen getroffen werden. Im Fehlerfall stellen diese
Vorkehrungen einen sicheren Betriebszustand her.

Dies kann z. B. durch mechanische Verriegelungen, Feh
lersignalisierung, Grenzwertschalter usw. erfolgen.

CANBus A4461-1.0 HBM: public 5

Sicherheitshinweise

Hinweis

Ein Modul darf nicht unmittelbar an ein Stromversor
gungsnetz angeschlossen werden. Die Versorgungs
spannung darf 10 V ... 30 V (DC) betragen.

Allgemeine Gefahren bei Nichtbeachten der
Sicherheitshinweise

Jedes Modul entspricht dem Stand der Technik und ist
betriebssicher. Von dem Modul können Restgefahren
ausgehen, wenn es von ungeschultem Personal unsach
gemäß eingesetzt und bedient wird. Jede Person, die mit
Aufstellung, Inbetriebnahme, Wartung oder Reparatur
des Modules beauftragt ist, muss die Bedienungsanlei
tungen und insbesondere die sicherheitstechnischen Hin
weise gelesen und verstanden haben.

Der Leistungs‐ und Lieferumfang der Module deckt nur
einen Teilbereich der Messtechnik ab. Sicherheitstechni
sche Belange der Messtechnik sind zusätzlich vom Anla
genplaner/Ausrüster/Betreiber so zu planen, zu realisie
ren und zu verantworten, dass Restgefahren minimiert
werden. Jeweils existierende Vorschriften sind zu beach
ten. Auf Restgefahren im Zusammenhang mit der Mes
stechnik ist hinzuweisen. Nach Einstellungen und Tätig
keiten, die mit Paßwort geschützt sind, ist
sicherzustellen, dass evtl. angeschlossene Steuerungen
in einem sicheren Zustand verbleiben, bis das Schaltver
halten des Moduls geprüft ist.

Wartung und Reinigung

Die Module sind wartungsfrei. Beachten Sie bei der Rei
nigung des Gehäuses folgende Punkte:

6 A4461-1.0 HBM: public CANBus

Sicherheitshinweise

S Trennen Sie vor der Reinigung die Verbindung zu al

len Anschlüssen.

S Reinigen Sie das Gehäuse mit einem weichen und

leicht angefeuchteten (nicht nassen!) Tuch. Verwen
den Sie auf keinen Fall Lösungsmittel, da diese die
Beschriftung oder das Gehäuse angreifen könnten.

S Achten Sie beim Reinigen darauf, dass keine Flüssig

keit in das Modul oder an die Anschlüsse gelangt.

Busanbindung und Ausgänge

Bei Anbindung an den CANbus sowie beim Senden von
CANbus‐Nachrichten muss in besonderem Maß auf die
Sicherheit geachtet werden. Stellen Sie sicher, dass die
reine Einbindung, Status‐ oder Steuersignale keine Aktio
nen vornehmen, die zu einer Gefahren für Mensch oder
Umwelt führen.

Produkthaftung

In den folgenden Fällen kann die vorgesehene Sicherheit
des Gerätes beeinträchtigt sein. Die Haftung für die Ge
rätefunktion geht dann auf den Betreiber über:

S Das Gerät wird nicht entsprechend der Bedienungs

anleitung benutzt.

S Das Gerät wird außerhalb des in diesem Kapitel be

schriebenen Anwendungsbereichs eingesetzt.

S Am Gerät werden vom Betreiber unautorisiert Ände

rungen vorgenommen.

Warnzeichen und Gefahrensymbole

Wichtige Hinweise für Ihre Sicherheit sind besonders ge
kennzeichnet. Beachten Sie diese Hinweise unbedingt,
um Unfälle und Sachschäden zu vermeiden.

CANBus A4461-1.0 HBM: public 7

Sicherheitshinweise

Sicherheitshinweise sind wie folgt aufgebaut:

WARNUNG

Art der Gefahr
Folgen bei Nichtbeachtung
Gefahrenabwehr

S Warnzeichen: macht auf die Gefahr aufmerksam
S Signalwort: gibt die Schwere der Gefahr an (siehe

folgende Tabelle)

S Art der Gefahr: benennt die Art oder Quelle der Ge

fahr

S Folgen: beschreibt die Folgen bei Nichtbeachtung
S Abwehr: gibt an, wie man die Gefahr vermeidet/um

geht

Gefahrenklassen nach ANSI

Warnzeichen, Signalwort Bedeutung

WARNUNG

VORSICHT

Hinweis

Diese Kennzeichnung weist auf eine mögliche
gefährliche Situation hin, die – wenn die Sicherheits
bestimmungen nicht beachtet werden – Tod oder
schwere Körperverletzung zur Folge haben kann.

Diese Kennzeichnung weist auf eine mögliche
gefährliche Situation hin, die – wenn die Sicherheits
bestimmungen nicht beachtet werden – leichte oder
mittlere Körperverletzung zur Folge haben kann.

Diese Kennzeichnung weist auf eine Situation hin,
die – wenn die Sicherheitsbestimmungen nicht
beachtet werden – Sachschäden zur Folge haben
kann.

8 A4461-1.0 HBM: public CANBus

Sicherheitshinweise

Sicherheitsbewussten Arbeiten

Der Versorgungsanschluss, sowie Signal‐ und Fühlerlei
tungen müssen so installiert werden, dass elektromagne
tische Einstreuungen keine Beeinträchtigung der Geräte
funktionen hervorrufen (Empfehlung HBM
”Greenline‐Schirmungskonzept”, Internetdownload
http://www.hbm.com/Greenline).

Geräte und Einrichtungen der Automatisierungstechnik
müssen so verbaut werden, dass sie gegen unbeabsich
tigte Betätigung ausreichend geschützt bzw. verriegelt
sind (z. B. Zugangskontrolle, Passwortschutz o.ä.).

Bei Geräten die in einem Netzwerk arbeiten sind diese
Netzwerke so auszulegen, dass Störungen einzelner
Teilnehmer erkannt und abgestellt werden können.

Es müssen hard‐ und softwareseitig Sicherheitsvorkeh
rungen getroffen werden, damit ein Leitungsbruch oder
andere Unterbrechungen der Signalübertragung, z. B.
über Busschnittstellen, nicht zu undefinierten Zuständen
oder Datenverlust in der Automatisierungseinrichtung
führen.

Fehlermeldungen dürfen nur quittiert werden, wenn die
Ursache des Fehlers beseitigt ist und keine Gefahr mehr
existiert.

Umbauten und Veränderungen

Das Modul darf ohne unsere ausdrückliche Zustimmung
weder konstruktiv noch sicherheitstechnisch verändert
werden. Jede Veränderung schließt eine Haftung unse
rerseits für resultierende Schäden aus.

Insbesondere sind jegliche Reparaturen, Lötarbeiten an
den Platinen (Austausch von Bauteilen) untersagt. Bei
Austausch gesamter Baugruppen sind nur Originalteile
von HBM zu verwenden.

CANBus A4461-1.0 HBM: public 9

Sicherheitshinweise

Das Modul wurde ab Werk mit fester Hard‐ und Softwa
rekonfiguration ausgeliefert. Änderungen sind nur im
Rahmen der in den Handbüchern dokumentierten Mög
lichkeiten zulässig.

Qualifiziertes Personal

Wichtig

Dieses Gerät ist nur von qualifiziertem Personal aus
schließlich entsprechend der technischen Daten in Zu
sammenhang mit den nachstehend aufgeführten Si
cherheitsbestimmungen und Vorschriften einzusetzen
bzw. zu verwenden.

Qualifizierte Personen sind Personen, die mit Aufstel
lung, Montage, Inbetriebsetzung und Betrieb des Produk
tes vertraut sind und über die ihrer Tätigkeit entspre
chende Qualifikationen verfügen. Dieses Modul ist nur
von qualifiziertem Personal ausschließlich entsprechend
der technischen Daten in Zusammenhang mit den Si
cherheitsbestimmungen und Vorschriften einzusetzen
bzw. zu verwenden.

Dazu zählen Personen, die mindestens eine der drei fol
genden Voraussetzungen erfüllen:

S Die Sicherheitskonzepte der Automatisierungstechnik

werden als bekannt vorausgesetzt und sie sind als
Projektpersonal damit vertraut.

S Als Bedienungspersonal der Automatisierungsanlagen

sind sie im Umgang mit den Anlagen unterwiesen und
mit der Bedienung der in dieser Dokumentation be
schriebenen Modulen und Technologien vertraut.

S Als Inbetriebnehmer oder im Service eingesetzt ha

ben sie eine Ausbildung absolviert, die Sie zur Repa

10 A4461-1.0 HBM: public CANBus

Sicherheitshinweise

ratur der Automatisierungsanlagen befähigt. Sie ha
ben zusätzlich die Berechtigung, Stromkreise und
Geräte gemäß den Normen der Sicherheitstechnik in
Betrieb zu nehmen, zu erden und zu kennzeichnen.

Bei der Verwendung sind zusätzlich die für den jeweiligen
Anwendungsfall erforderlichen Rechts‐ und Sicherheits
vorschriften zu beachten. Sinngemäß gilt dies auch bei
Verwendung von Zubehör.

CANBus A4461-1.0 HBM: public 11

Sicherheitshinweise

2 Verwendete Kennzeichnungen

catman ist ein eingetragenes Warenzeichen der
Hottinger Baldwin Messtechnik GmbH.

Alle in diesem Dokument verwendeten Warenzeichen
oder Marken weisen nur auf das jeweilige Produkt oder
den Inhaber des Warenzeichens oder der Marke hin.
Hottinger Baldwin Messtechnik GmbH erhebt damit
keinen Anspruch auf andere als die eigenen Warenzei
chen oder Marken.

2.1 In dieser Anleitung verwendete Kennzeichnungen

Wichtige Hinweise für Ihre Sicherheit sind besonders ge
kennzeichnet. Beachten Sie diese Hinweise unbedingt,
um Schäden zu vermeiden.

Symbol Bedeutung

Hinweis

VORSICHT

Wichtig

Tipp

Diese Kennzeichnung weist auf eine Situation hin,
die – wenn die Sicherheitsbestimmungen nicht
beachtet werden – Sachschäden zur Folge haben
kann.

Diese Kennzeichnung weist auf eine mögliche
gefährliche Situation hin, die – wenn die Sicherheits
bestimmungen nicht beachtet werden – leichte oder
mittlere Körperverletzung zur Folge haben kann.

Diese Kennzeichnung weist auf wichtige Informa
tionen zum Produkt oder zur Handhabung des Pro
duktes hin.

Diese Kennzeichnung weist auf Anwendungstipps
oder andere für Sie nützliche Informationen hin.

12 A4461-1.0 HBM: public CANBus

Sicherheitshinweise

Gerät -> Neu Fette Schrift kennzeichnet Menüpunkte sowie Dialog‐

und Fenstertitel in Programmoberflächen. Pfeile zwi
schen Menüpunkten kennzeichnen die Reihenfolge,
in der Menüs und Untermenüs aufgerufen werden.

Bitrate, 500 Fett‐kursive Schrift kennzeichnet Eingaben und Ein

gabefelder in Programmoberflächen.

Hervorhebung
Siehe …

Kursive Schrift kennzeichnet Hervorhebungen im
Text und kennzeichnet Verweise auf Kapitel, Bilder
oder externe Dokumente und Dateien.

CANBus A4461-1.0 HBM: public 13

QuantumX / SomatXR‐Dokumentation

3 QuantumX / SomatXR‐Dokumentation

Die Dokumentation der QuantumX / SomatXR-Familie
besteht aus

S der QuantumX and SomatXR‐Bedienungsanleitungen

im PDF‐Format

S den Datenblättern im PDF-Format

S der Bedienungsanleitung des Datenrekorders

CX22B-W

S der Bedienungsanleitung des EtherCAT®

net-Gateways CX27/B im PDF-Format

S den Produktbeschreibungen für Zubehörteile im

PDF‐Format

S einer umfangreichen Online-Hilfe mit Index und kom

fortabler Suchmöglichkeit, die nach Installation eines
Softwarepaketes (z. B. MX-Assistent, catman®AP)
zur Verfügung steht. Hier finden Sie auch Hinweise
zur Konfiguration der Module und Kanäle.

Sie finden diese Dokumente

S auf der mit dem Gerät gelieferten QuantumX /

SomatXR-System-CD

S nach Installation des MX-Assistenten auf der Fest

platte ihres PCs, zu erreichen über Windows-Start

S immer aktuell auf unseren Internetseiten unter

www.hbm.com/

1)

EtherCAT® ist eine eingetragene Marke und patentierte Technologie,
lizensiert durch die Beckhoff Automation GmbH, Deutschland

1) / Ether

14 A4461-1.0 HBM: public CANBus

4 Der CANBus

Diese Anleitung unterstützt Sie beim Anschließen Ihres
QuantumX- oder SomatXR-Systems an einen CAN-Bus
mit den folgenden Modulen:

Im Folgenden werden diese Module als MX471B und
MX840B bezeichnet. Die SomatXR-Module werden nur
im Falle wesentlicher Unterschiede speziell genannt.

Bei Verwendung des Datenrekorders CX23-R gibt es
einige Einschränkungen hinsichtlich der CAN-Bus­Optionen (siehe CX23-R‐Anleitung).

Der CANBus

- MX471B(-R)

- MX840B(-R)

Die Konfiguration eines CAN‐Ports kann über die
Software catman
men werden, die über eine ausführliche Onlinehilfe
verfügen.

Diese Anleitung zeigt Ihnen:

S Wie Sie einen CANbus‐Knoten parametrieren.

Zusätzlich steht folgende Dokumentation zur Verfügung:

S Allgemeine Bedienungsanleitung

S Datenblätter MX840B oder MX471B

S Onlinehilfen in der Software catmanEASY und MX-

Assistent

CANBus A4461-1.0 HBM: public 15



EASY oder MX‐Assistent vorgenom

QuantumX / SomatXR und CAN

5 QuantumX / SomatXR und CAN

5.1 Übersicht

Das Modul MX471B bietet vier unabhängige CANbus­Knoten, die alle untereinander und zur Stromversorgung
potentialgetrennt sind. Das Modul MX840B bietet am
Kanal 1 einen CANbus‐Knoten, der galvanisch getrennt
ist.

Bei der Datenübertragung auf einem CANbus werden
keine Teilnehmer direkt adressiert. Ein eindeutiger Identi
fier kennzeichnet den Inhalt einer Nachricht (z.B. Dreh
zahl oder Motortemperatur).

Der Identifier steht auch für die Priorität der Nachricht.

Nachricht = Identifier + Signal + Zusatzinformation

Teilnehmer am Bus = Knoten

Jeder Knoten kann entweder als Empfänger oder als
Sender (Gateway) parametriert werden. Die Parametrie
rung im Detail wird in der jeweiligen Online-Hilfe des
Softwarepakets dargestellt.

Hinweis

Um einen störungsfreien Betrieb zu gewährleisten, muss
der CANbus an beiden Enden und nur dort mit einem
entsprechenden Abschlusswiderstand terminiert werden.
Ein 120 Ohm Abschlusswiderstand kann individuell im
Modul per Software zugeschaltet werden. Eine Terminie
rung ist auch schon bei kurzen Leitungen mit niedrigen
Bitraten erforderlich.

16 A4461-1.0 HBM: public CANBus

QuantumX / SomatXR und CAN

Im Datenblatt wird der Zusammenhang zwischen Bitrate
und maximale Leitungslänge des Busses dargestellt.

Die Konfiguration eines Knotens bleibt auch nach dem
Ab- und Anschalten der Module bestehen.

Sollten Sie Signale mit einer Rate größer als 2000/s de
kodieren, richten Sie bitte die Signaleingänge 1 bis 8 auf
dem MX471B ein. Bei diesen Signaleingängen wurden
hierfür die Signalpuffer vergrößert.

5.2 Anschluss CANbus

CAN-Signale empfangen:

- MX471B, MX840B (Kanal 1)

CAN-Signale senden:

- MX471B

- MX840B (nur modul-interne Messsignale)

- die Software MX‐Assistent kann aus der Liste aller
versendeten Nachrichten ein DBC‐file generieren

CCP oder XCP-over-CAN-Signale empfangen:

- nur MX471B

CANBus A4461-1.0 HBM: public 17

QuantumX / SomatXR und CAN

QuantumX

CAN-High

CAN-Low

CAN-GND

MX840B

Kanal 1

SubHD-15pol.

6

1

5

11

15

10

7

8
6

MX471B

SubD-9pol.

1

6

9

5

7

2
6

18 A4461-1.0 HBM: public CANBus

QuantumX / SomatXR und CAN

SomatXR

MX471B-R

M12 5pol.

4

5
3

CAN-High

CAN-Low

CAN-GND

Grau

Grün

Grau/Schwarz

MX840B-R

Kanal 1
ODU 14pol.

11

12

13

Weiß

Blau

Schwarz

Hinweis

Sorgen Sie für eine korrekte Terminierung mit Abschluss
widerständen, wie in Abb. 5.1 dargestellt. Das Quan
tumX‐Modul MX840B enthält keine Terminierung, der
MX471B und der SomatXR MX840B-R enthalten eine
interne Terminierung, die über Software aktiviert werden
kann.

CANBus A4461-1.0 HBM: public 19

QuantumX / SomatXR und CAN

Abschluss­widerstand
120

Knoten 1 . . . . . .

Abb. 5.1 Busabschlusswiderstände

Zum Anschluss der D-SUB-15HD-Gerätebuchsen des
QuantumX MX840B an handelsübliche D-SUB-Stecker
mit standardisierter CiA‐Belegung dient das Adapterkabel
1-Kab418.

5.2.1 Zustandsanzeige LEDs der Geräte

CAN-LEDs “BUS”

Abschluss­widerstand
120

Knoten n

System-LED

CAN-LEDs “Kanal”

Abb. 5.2 QuantumX Frontansicht MX471B

20 A4461-1.0 HBM: public CANBus

QuantumX / SomatXR und CAN

CAN-LEDs “BUS”

CAN-LEDs “Kanal”

Abb. 5.3 SomatXR Frontansicht MX471B-R

Modulbezogene Zustandsanzeigen (Fehlermeldungen)
siehe auch Kapitel 6.3.

System-LED

Grün Fehlerfreier Betrieb

Gelb System ist nicht bereit, Bootvorgang läuft

Gelb blinkend Download aktiv, System ist nicht bereit

Rot Fehler, Synchronisation fehlerhaft

System-LED

CANBus A4461-1.0 HBM: public 21

QuantumX / SomatXR und CAN

CAN-LEDs (BUS)

Grün flackert Bus ist fehlerfrei und Aktivität auf CAN

Grün dauerhaft an Bus ist fehlerfrei und keine Aktivität auf CAN

Gelb flackert Bus ist zeitweise fehlerfhaft (Warning) und Aktivität auf CAN

Gelb dauerhaft an Bus ist zeitweise fehlerfhaft (Warning) und keine Aktivität auf

CAN

Rot an Bus ist fehlerfhaft, das CAN-Interace ist im Zustand “Bus-

OFF”

CAN-LEDs (Kanal)

Grün dauerhaft an Kanal ist betriebsbereit

Gelb blinkend Firmware1-Download aktiv

Gelb an Bootvorgang läuft

Rot an Kanal ist fehlerhaft

Ethernet-LED (nur QuantumX)

Grün an Ethernet Linkstatus ist in Ordnung

Gelb blinkt Ethernet Datenübertragung läuft

5.2.2 CAN-Nachrichten empfangen

Um CAN-Nachrichten empfangen zu können, müssen die
relevanten Nachrichten dem Knoten bekannt gemacht
werden. Das kann direkt auf dem Knoten oder wieder
holbar über vorher angelegte Nachrichten in der Sensor
datenbank erfolgen. Aus der Sensordatenbank können
einzelne Nachrichten per drag & drop mit dem Knoten
verbunden werden.

22 A4461-1.0 HBM: public CANBus

QuantumX / SomatXR und CAN

Es können auch CAN-Datenbasen vom Typ *.dbc in die
Sensordatenbank eingelesen werden. Steht keine CAN­Datenbasis zur Verfügung, kann diese auch selbst
erstellt werden. Unterschiedliche Firmen bieten hierzu
Editoren an.

Im Messbetrieb werden die empfangenen CAN-Nachrich
ten sofort ”zeitgestempelt”. Damit ist im Gesamtsystem
eine parallele und synchrone Erfassung und Analyse von
direkt erfassten Messgrößen und von CAN-Nachrichten
möglich.

CANBus A4461-1.0 HBM: public 23

Funktionsbeschreibung

6 Funktionsbeschreibung

6.1 Globale Parameter

6.1.1 Bitraten

Seit Firmware-Version 4.6 wird die Parametrierung der
CAN-Bitrate erweitert. In einer Ansicht kann man eine
gewünschte Bitrate, sowie den Abtastpunkt und die Syn
chronisationsweite (SJW) wählen.

Zur Parametrierung muss eine Bitrate (Wert in bit/s)
angegeben werden. Zusätzlich wählt man mit „Sam
plePointRatio“ ein gewünschten Abtastpunkt und mit
„SJW“ eine Synchronisationsweite zwischen 1 und 4
Time-Quanta.

Nachdem die Parametrierung abgesendet wurde, wird
diese im Modul geprüft und eine Einstellung vorgenom
men, die den gewünschten Parametern möglichst nahe
kommt. Man kann nun die Parametrierung zurücklesen
und aus den entsprechenden XML-Tags mit vorange
stelltem „Active“ die derzeit tatsächlich eingestellten
Werte auslesen. Es steht dem Anwender frei, diese
zurück gelesenen Werte nach eigenen Anforderungen zu
bewerten.

Werksseitig ist gewählt: Bitrate = 1000 kbit/s, Sam
plePointRatio = 87,5 %, SJW = 4.

6.1.2 Terminierung des CANBus

Alle Varianten von MX471B, sowie MX840B-R können
eine Terminierung des CAN-Bus per Parametrierung zu­oder abschalten. MX840, MX840A und MX840B unter
stützen keine interne Terminierung.

24 A4461-1.0 HBM: public CANBus

Funktionsbeschreibung

6.1.3 Fehlerbehandlung

Es gibt Anwendungen, bei denen einzelne Fehlerereig
nisse kritisch sind und dauerhaft angezeigt werden müs
sen, auch wenn die Fehlerursache längst behoben ist. In
anderen Anwendungen wünscht man sich, dass die LED
und der Fehlerstatus den momentanen Zustand des
CAN-Bus und Moduls anzeigt und Fehler automatisch
gelöscht werden, wenn deren Ursache beseitigt ist.

Im MX‐Assistent kann man daher in den „CAN-Bus-Ein
stellungen“ unter „Fehlermodus“ wählen, wie sich das
Modul beim Auftreten kurzzeitiger Fehler verhalten soll:
Wird die Methode „automatisch, verzögert“ gewählt,
wird der Fehler nach der einstellbaren Verzögerungszeit
automatisch aus dem Fehlerstatus gelöscht und die LED
wechselt in den Normalzustand, nachdem die Fehler
ursache beseitigt wurde. Das Modul zeigt demnach mit
der eingestellten Verzögerung des aktuellen Zustand des
CAN-Bus.

Wird die Methode „beim Lesen“ gewählt, bleibt ein
Fehlerstatus so lange bestehen und wird auch über die
LED signalisiert, bis der Fehlerstatus aus dem Modul
ausgelesen wurde. Sofern die Urschae des Fehlers nicht
mehr besteht, wird also der Fehlerstatus und die LED
erst dann in den Normalzustand wechseln, wenn der
Fehlerstatus ausgelesen wurde. Auf diese Weise können
auch einzelne Fehlerereignisse sicher erfasst werden,
ohne dass der Fehlerstatus während einer Messung dau
erhaft beobachtet werden muss. Allerdings gibt diese
Methode nicht immer den aktuellen Zustand des CAN­Bus wider.

CANBus A4461-1.0 HBM: public 25

Funktionsbeschreibung

6.2 Fehlerereignisse

6.2.1 Erfassen von Fehlern des Sende‐ und

Fehler in Senderichtung (vom Modul in den CAN-Bus)
werden nur dann überwacht, wenn in der Parametrierung
des Moduls Daten zum Versenden konfiguriert wurden.
Umgekehrt werden nur dann Fehler in Empfangsrichtung
(CAN-Bus in das Modul) detektiert, wenn mind. ein CAN­Empfangsdekoder aktiv konfiguriert ist.

6.2.2 Verhalten der LED und des Fehlerstatus

Die LED leuchtet gelb, wenn BUS-Warning auftritt, rot in
allen anderen Fehlerfällen.

Timeout und „Loss of signal“ werden mit gelber LED
signalisiert, sofern die Überwachung aktiviert wurde. Dies
erfolgt damit, dass in der Parametrierung eines Dekoders
der Wert „MaxRepetitionTime“ größer „0“ gewählt wurde.

Empfangsweges

Das Fehlerregister kann per MX‐Assistent ausgelesen
werden. Die LED folgt dabei den Statusmeldungen im
Fehlerregister, siehe Kapitel 3.

Fehlerereignisse treten oft nur nur sporadisch und kurz
zeitig auf. Wenn die Anwendung fordert, dass auch ein
malige Ereignisse sicher erkannt werden können, kann in
der Parametrierung (siehe Kapitel 1.3) der „Fehlermodus“
so eingestellt werden, dass Fehler erst mit dem Auslesen
des Fehlerstatus gelöscht werden.

26 A4461-1.0 HBM: public CANBus