BECKHOFF FC5101 - Manual (Page 40)

Eiserstraße 5 / D-33415 Verl / Telefon 05246/963-0 / Telefax 05246/963-149
40
its heartbeat telegram with the smallest configured guard time (the guard times can be set individually for each
node). If the node refuses the entry of the consumer heartbeat time, then it is assumed that the node does not
support monitoring of the master - this is tolerated. If entry of the producer heartbeat time also fails, then the
guarding protocol is configured.
Guarding: If the node does not support the heartbeat, then the guarding parameters (guard time, 0x100C and
life time factor, 0x100D) are entered.
If this attempt also fails, then the start-up process is aborted, and the node enters state 0x04, with an appropri-
ate error message being sent to the dialog box.
6. Download User Parameters
The objects added manually on the SDO tab are now transmitted to the node by SDO download. Once again, if
the SDO is interrupted the value is fed back and checked for agreement, so that read-only parameters can be
tolerated. The process only continues it successful, and otherwise is aborted.
7. Start Node
After all the parameters have successfully been downloaded, the node is switched into the operational state by
means of an individual Start_Remote_Node telegram. RxPDOs are first sent to the nodes about 1 s after this
start telegram, and the guarding or heartbeat protocol begins. Node monitoring by heartbeat does not start until
the node's producer heartbeat telegram has been received for the first time.
Because CANopen does not provide explicit confirmation of the start process, it is only possible to evaluate the
first arrival of the transmit PDOs. Until all the configured TxPDOs have arrived, the state of the node remains
set to 0x17 (expected TxPDO is missing).
After all configured nodes have been found, successfully parameterised and individually started, the FC510x
card again sends a global Start_Remote_Node telegram (with node ID=0).
8. SYNC
SYNC telegrams are first sent after the linked task with the highest priority has been started. Synchronous
TxPDOs are also therefore triggered until this task is running - this can also be a reason for the node state re-
maining at 0x17.
Example of a boot up sequence:
Node with node ID1, identifier in hex code.
Time ID DLC DATA description
0.1244 00 2 82 00 Reset communication all nodes
All nodes are set to their initial state
0.1252 601 8 40 00 10 00 00 00 00 00 [1000,00] Initiate Upload Rq.
First attempt to find node 1 - node is still reset
2.1316 601 8 80 00 00 00 00 00 04 05 05040000 [0000,00] Abort: SDO protocol
timed out
Node has not responded within the SDO timeout period (2 sec), SDO is aborted
2.7875 701 1 00 Boot-up
Node has carried out its reset process, and announces itself with boot up message
4.1391 601 8 40 00 10 00 00 00 00 00 [1000,00] Initiate Upload Rq.
Second attempt to find node 1. Read access to object 0x1000
4.1411 581 8 43 00 10 00 91 01 07 00 91 01 07 00 [1000,00] Initiate Upload Rsp.
expedited
Node 1 answers with profile no. 0x191 (401 dec) and additional info 0x07
4.1418 601 8 40 18 10 01 00 00 00 00 [1018,01] Initiate Upload Rq.
The Vendor ID is read
4.1434 581 8 43 18 10 01 02 00 00 00 02 00 00 00 [1018,01] Initiate Upload Rsp.
expedited
Node 1 with vendor ID 0x02 (= Beckhoff)
4.1442 601 8 23 00 18 01 81 01 00 00 81 01 00 00 [1800,01] Initiate Download
Rq. expedited
The identifier for TxPDO1 is now written: 0x181
4.1831 581 8 60 00 18 01 00 00 00 00 [1800,01] Initiate Download Rsp
Node 1 confirms the download
4.1840 601 8 23 01 18 01 81 02 00 00 81 02 00 00 [1801,01] Initiate Download
Rq. expedited