BootUp of the FC510x
Introduction
The firmware in the FC510x CANopen PCI card treats each individual node separately. The first action following the system start is to check for the presence of the expected nodes, and whether they basically correspond to the devices that have been configured. Following this, each node is parameterized and started, independently of the others. The starting behavior of a node is described below.
1. Reset All Nodes
The starting sequence begins with the global Reset Communication telegram, so that all nodes are brought in to a defined initial state
2. Identify Node
Presence of the nodes is first established through an SDO upload of the object 0x1000 (Device Type). The content supplied by a node is checked for agreement with the expected value. Object 0x1000 is composed of the profile number and of the additional information - both values can be found on the CAN Node tab.
If both the additional information and the profile number are set to "0", the contents returned for object 0x1000 is not checked. An answer containing an SDO abort protocol cannot be tolerated; the process is interrupted.
For values other than zero, the next step is only taken if the value is as expected. Otherwise the process is aborted and the node enters state 0x04 (SDO syntax error at start-up if an SDO abort message has been received or if the data length is incorrect) or state 0x05 (if there is an SDO data mismatch at start-up or the value do not comply) and an appropriate error message is displayed in the dialog box.
If the node does not answer the SDO upload telegram, then the SDO protocol is interrupted after a timeout (approx. 2 seconds) and then repeated after a waiting time (of approx. 1 second) until the node answers. In this phase, the node is in state 0x02 (node not found).
If the vendor ID, the product code, the serial no. or the revision no. have been configured to values other than zero on the CAN Node's tab, then the corresponding values are read and compared in the node's object 0x1018. The booting process is only continued if they are as expected.
3. Set SYNC Time
If synchronous PDOs have been configured, an attempt is now made to enter the given Sync Cycle Time into object 0x1006 (SYNC interval). Because this object is optional, the boot up is still continued even if the node acknowledges negatively - it is, however, necessary for the node to answer.
4. Set PDO Parameter
If the "Auto-download PDO parameters" checkbox on the CAN node's tab has been selected (which it is by default) then the PDO parameters for all the configured PDOs are now written. These are the identifier and the transmission type. The Inhibit Time and the Event Time are only written at this stage if they have been configured to have values other than zero.
If a node answers an SDO download of the PDO parameters with an SDO abort protocol, then the corresponding entry is then read (SDO upload) and compared with the value to be written. If they are in agreement, the process continues. In this way it is possible for read-only PDO parameters to be tolerated, provided they agree with the configured values.
The next step is only taken if the download, or the comparison with existing values, is successful. Otherwise the process is aborted, and the node enters state 0x04 or 0x05, and the appropriate error message is displayed in the dialog box.
5. Set Guarding/Heartbeat
If a value other than zero has been configured for the Guard Time, the appropriate parameters are now written to the nodes. Because the heartbeat process generates less bus loading than guarding, an attempt is first made to start this form of node monitoring on the CANopen nodes.
Heartbeat: The guard time is entered as the producer heartbeat time (0x1017) and the product of (guard time x life time factor) is entered as the consumer heartbeat time (0x1016). The FC510x card then transmits cyclically 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 appropriate error message being sent to the dialog box.
6. Download User Parameter
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 if 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 parameterized 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 remaining at 0x17.
Example of a boot up sequence:
Node with node ID1, identifier in hex code.
Time ID DLC DATA Description0.1244 00 2 82 00 Reset communication all nodes
All nodes are moved into source state
0.1252 601 8 40 00 10 00 00 00 00 00 [1000,00] Initiate Upload Rq.
First attempt to find knot 1 - node is still in Reset
2.1316 601 8 80 00 00 00 00 00 04 05 05040000 [0000,00] Abort: SDO protocol timed out
Node has not answered within SDO Time-out (2 sec), SDO is broken off
2.7875 701 1 00 Boot-up
Node has carried out reset and contacts 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. Reading 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 (401dez) and Add. 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 answers 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
Now the Identifier for of TxPDO1 is 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
Identifier for TxPDO2 is 0x281
4.2223 581 8 60 01 18 01 00 00 00 00 [1801,01] Initiate Download Rsp
4.2230 601 8 23 00 14 01 01 02 00 00 01 02 00 00 [1400,01] Initiate Download Rq. expedited
Identifier for RxPDO1 is 0x201
4.2347 581 8 60 00 14 01 00 00 00 00 [1400,01] Initiate Download Rsp
4.2356 601 8 2f 00 18 02 ff 00 00 00 ff [1800,02] Initiate Download Rq. expedited
Transmission type for TxPRO1 is 0xFF=255
4.2737 581 8 60 00 18 02 00 00 00 00 [1800,02] Initiate Download Rsp
4.2744 601 8 2f 01 18 02 ff 00 00 00 ff [1801,02] Initiate Download Rq. expedited
Transmission type for TxPRO2 is 0xFF=255
4.3133 581 8 60 01 18 02 00 00 00 00 [1801,02] Initiate Download Rsp
4.3141 601 8 2f 00 14 02 ff 00 00 00 ff [1400,02] Initiate Download Rq. expedited
Transmission type for RxPRO1 is 0xFF=255
4.3252 581 8 60 00 14 02 00 00 00 00 [1400,02] Initiate Download Rsp
4.3264 601 8 2b 17 10 00 64 00 00 00 64 00 [1017,00] Initiate Download Rq. expedited
Heartbeat Producer Time is 0x64=100ms
4.3279 581 8 60 17 10 00 00 00 00 00 [1017,00] Initiate Download Rsp
4.3287 601 8 23 16 10 01 2c 01 7f 00 2c 01 7f 00 [1016,01] Initiate Download Rq. expedited
Heartbeat Consumer Time ist 0x012C=300ms, Node ID des Heartbeat Producers (hier: FC5101) ist 0x7F
4.3304 581 8 60 16 10 01 00 00 00 00 [1016,01] Initiate Download Rsp
4.3312 601 8 23 00 55 00 00 00 ff ff 00 00 ff ff [5500,00] Initiate Download Rq. expedited
User Parameter: Index 0x5500, SI 0, Wert 0x00 00 FF FF
4.3321 701 1 7f T0 Preoperational
Node 1 sends first heartbeat telegram, FC5101 starts controlling
4.4679 581 8 60 00 55 00 00 00 00 00 [5500,00] Initiate Download Rsp
4.4686 601 8 2f 23 64 00 01 00 00 00 01 [6423,00] Initiate Download Rq. expedited
User Parameter: Index 0x6423, SI 0, Wert 0x01
4.4700 581 8 60 23 64 00 00 00 00 00 [6423,00] Initiate Download Rsp
4.4707 00 2 01 01 Start Node
Node 1 is transferred individually in operational
4.4717 701 1 7f T0 Preoperational
The next heartbeat telegram is sent before the status crossing is concluded
4.4986 181 1 00 00
Node 1 is operational and sends his TxPDO1 and TxPDO2
4.4989 281 4 00 00 00 00 00 00 00 00
4.5786 701 1 05 T0 Operational
4.6390 281 4 00 00 08 00 00 00 08 00
4.6411 281 4 00 00 00 00 00 00 00 00
4.6891 701 1 05 T0 Operational
4.7951 701 1 05 T0 Operational
4.9032 701 1 05 T0 Operational
5.0048 281 4 00 00 08 00 00 00 08 00
5.0070 281 4 00 00 00 00 00 00 00 00
5.0094 701 1 05 T0 Operational
5.0153 281 4 00 00 08 00 00 00 08 00
5.0174 281 4 00 00 00 00 00 00 00 00
5.1129 701 1 05 T0 Operational
....
5.4755 00 2 01 00 Start all nodes
Now all nodes are started
5.4847 201 1 00 00
approx. 1 sec after start of node 1 the RxPDO1 is sent for the first time