Beckhoff CX8050, Документация

Страница: 69 / 169

CAN
CX8050, CX8051 - Embedded-PCs for
CANopen and CAN 69 Version: 1.4
11 bit
identifier 2 bytes of user data
0x00 0x02 0x00
Example 2
The following telegram resets node 17:
11 bit
identifier 2 bytes of user data
0x00 0x81 0x11
Boot-up message
After the initialization phase and the self test, the Bus Coupler sends the boot-up message, a CAN message
with no data bytes and with the identifier of the emergency message: CAN-ID = 0x700 + Node-ID. In this way
temporary failure of a module during operation (e.g. due to a voltage interruption), or a module that is
switched on at a later stage, can be reliably detected, even without Node Guarding. The sender can be
determined from the message identifier (see default identifier allocation).
It is also possible, with the aid of the boot-up message, to recognize the nodes present in the network at
start-up with a simple CAN monitor, without having to make write access to the bus (such as a scan of the
network by reading out parameter 0x1000).
Finally, the boot-up message communicates the end of the initialization phase; the Bus Coupler signals that
it can now be configured or started.
Note
Firmware BA
Up to firmware status BA the emergency identifier was used for the boot up message.
Format of the Boot-up message
11 bit
identifier 1 byte of user data
0x700
(=1792) +
Node-ID 0x00
Node Monitoring
Heartbeat and guarding mechanisms are available to monitor failures in the CANopen network. These are of
particular importance for CANopen, since modules do not regularly speak in the event-driven mode of
operation. In the case of "guarding", the devices are cyclically interrogated about their status by means of a
data request telegram (remote frame), whereas with "heartbeat" the nodes transmit their status on their own
initiative.
Guarding: Node Guarding and Life Guarding
Node Guarding is used to monitor the non-central peripheral modules, while they themselves can use Life
Guarding to detect the failure of the guarding master. Guarding involves the master sending remote frames
(remote transmit requests) to the guarding identifier of the slaves that are to be monitored. These reply with
the guarding message. This contains the slave’s status code and a toggle bit that has to change after every
message. If either the status or the toggle bit do not agree with that expected by the NMT master, or if there
is no answer at all, the master assumes that there is a slave fault.