CANopen Device

"CAN Node" tab

Node ID: Enter the general CANopen device node address here. If you select the "Automatic Adjust PDO COB IDs" box, the default identifier for the process data object can also be carried out after changing the node ID.

Profile no.: After CANopen, the parameter 0x1000 "Device Type" contains the number of the device profile supported by the device in both the lowest value bytes. These are entered here and compared with the device parameter present at the system startup. If no device profile is supported, the parameter will contain the value 0.

Add info: The additional information is located in the two highest value bytes of the object directory entry 0x1000 (device type).

FC510x: The target/actual configuration comparison is only done if Profile no. or Add. info (i.e. object directory entry 0x1000) is set to a value that is not null. If the expected values at the system startup do not match with the values present, the start of this node will be interrupted and a corresponding error message will appear in the Diag tab.

CIFx0-CAN: The values are continuously compared (even if "0" is entered in both). If values do not match, the node start is interrupted.

Guard time: The guard time determines the interval at which the node is monitored (node guarding). 0 signifies no monitoring.

Life time factor: Guard time x life time factor determines the watchdog length for the mutual monitoring of card and CANopen nodes. 0 indicates that the CANopen node is not monitoring the card. At 0 the card takes the Guard time directly as the watchdog length.

FC510x: This card also supports the heartbeat protocol and firstly attempts to start this form of node monitoring on the CANopen node (write access to objects 0x1016 and 0x1017 in the object directory). If this attempt fails, guarding is activated. The Guard time is entered as producer, heartbeat time and (guard time x lifetime factor) are entered as consumer heartbeat time. The card then transmits its heartbeat telegram with the smallest configured guard time (the guard times can be set individually for each node).

Emcy COB ID. and Guard COB ID are identifiers for emergency messages or the guarding protocol. They result from the node address.

Automatic PDO... Specifies whether TwinCAT should download the PDO communications parameters to the node at the system startup.

FC510x: If the download of the PDO parameters fails, the card attempts to read these parameters and compares them with the configured values. It thus also supports nodes which have implemented the default identifiers as read-only values, for example.

CIFx0-CAN: The PDO parameters are transmitted to the CANopen nodes, but it is tolerated if the nodes do not support these entries – only a confirmation of the SDO access is required (an SDO abort response is sufficient).

Vendor ID, Product code, Serial no., Revision no. (FC510x only): If values other than zero are entered here, these identity object entries (0x1018 in the object directory) are read at system startup and compared with the configured values. The corresponding node will only be started if the values match. It is also possible to compare a part of the value (e.g. Vendor ID and Product code) – then, only the non-desired parameters need to be set to null.

Node error response (FC510x only):

Stop node: After a detected node error, the node is set to "Stopped" state (NMT command "Stop remote node"). The node (according to each device profile) can then be switched to a safe state via the network status machine – SDO addressing is not possible in this mode.

No reaction: No NMT Stop remote node command after node error

Node restart (FC510x only):

Automatic restart: After a node error is detected, the card automatically attempts to restart the node. The start attempt is initiated by a Reset node command.

Manual restart: After a node error, this node remains in error state and is not restarted automatically. You can trigger a restart via "I/O reset".

Network reaction (FC510x only):

No reaction: The failure of a node has no effect on the other bus devices

Stop all nodes: After the failure of a node, all other previously started nodes are stopped (NMT Stop remote node command). You then need to restart the system.

General CAN node (FC510x only): If this checkbox is selected, the whole CANopen network management is disabled for this device, i.e. it is not started and monitored etc. The PDO entries are regarded as pure CAN telegrams (layer 2) and made available to the controller on an event-driven basis.

CANopen terminology is retained As the CANopen terminology is retained, even for general CAN nodes, it must be noted that RxPDOs are the telegrams sent by the Fc510x and TxPDOs are the received telegrams.

This option allows any CAN node to be connected to the TwinCAT, if the baud rate and the bit timing parameters match. The respective protocol can then be simulated within the PLC program. It is also possible to run CANopen devices and general CAN nodes within the same network – if there are no identifier overlaps (the system structure is such that you cannot use an identifier twice).

CANopen PDOs

Process Data Objects (PDOs) are CAN telegrams which transport process data without a protocol overhead. RxPDOs are received by node, TxPDOs are sent by the node. This description is contained in the System Manager from the perspective of the configured node, i.e. RxPDOs are sent by the TwinCAT, TxPDOs are received by the TwinCAT.

”PDO” tab

COB Id: The CAN identifier of this PDO. For every two send and receive PDOs per node, CANopen provides Default Identifiers. These can then be changed.

Trans.Type: The Transmission Type determines the send behavior of the PDO. 255 corresponds to the event driven send.

Inhibit time: Send Delay between two identical PDOs. Is entered in multiples of 0.1 ms.

Length: The length of the PDO is based on the mapped variables and cannot therefore be edit here.

Event Time (FC510x only): Enter the value for the Event Timer in ms. For send PDOs (here: RxPDOs, see above) the StartUp of this timer triggers an additional PDO send, for receive PDOs (here: TxPDOs) the arrival of a PDO within the pre-set value is monitored and the box state of the node is changed as appropriate. If 0, the parameter is not transferred to the node.

TwinCAT creates corresponding inputs in the node object directory based on the parameters entered here. These are transferred via SDO at the system start. You can view the inputs at the SDO tab. If this behavior is not required, you can deactivate "Auto Download of PDO Parameters" by selecting the checkbox at the CAN node tab.

Tree representation:

TwinCAT primarily provides two send and receive PDOs, marked with Default identifiers, for a general CANopen node. Superfluous PDOs can be selected and removed.

TxPDOs are sent by the CANopen node and generally contain inputs. RxPDOs are received by the node, i.e., sent by TwinCAT

Add variables to the PDOs by right clicking on "Inputs" and/or "Outputs" and selecting the corresponding variable(s). If several variables of the same type are inserted with a single action, the offset within the PDO will be created automatically. If variables are inserted one after another, you need to set the corresponding offset (start address within the CAN telegram) for each variable.

Pay attention to the order TwinCAT places the PDOs in the displayed order according to the object directory entries in the node. This way, for example, the PDO communication parameters of the third listed TxPDO are always written to index 0x1802 – regardless of the designation of the PDO in the System Manager. Thus, if only PDO1 and PDO3 are to be used, a PDO2 must also be entered – in this case without assigning variables. PDOs without variables are not transmitted and also not expected.

Context menu:

The menu alongside is obtained by right clicking on the general CANopen node. Here you can insert further Tx PDOs and/or Rx PDOs.

”SDOs” tab

SDO inputs sent to the node at StartUp are displayed/managed on this page. Inputs with an object index in straight brackets are automatically created based on the updated terminal configuration. Other inputs can be managed using ”Add”, ”Insert”, ”Delete” and ”Edit”.

”ADS” tab

In order to be able to read and write SDO objects during the running time (e.g. from the PLC), the node (Bus Coupler) can be allocated an ADS port (CIFx0-CAN). The FC510x always provides an ADS port for every node since the diagnostic information is transported via ADS. These ports can be used to read and write SDO objects using ADS read requests and/or write requests.

The ADS IndexGroup contains the CANopen object index and the ADS IndexOffset contains the CANopen SubIndex.

CANopen Emergency Object

Some CANopen status data and up to 5 emergency objects received from a node can be read from any TwinCAT program via ADS and/or signalled to any TwinCAT program. In this case, set ADS parameters as follows:

Port: 300

IndexGroup: 0x5000 + Device-ID

IndexOffset: Hi-Word: Node-ID, Lo-Word: 0x100

Length: 8 - 48

The diagnostic data is structured as follows:

Offset: 0: Nodestatus bits

Bit 7: Node is deactivated

Bit 3: Guarding protocol is active

Bit 2: parameterisation error

Bit 1: Emergency buffer overflow

Bit 0: Mode does not respond

Offset: 1,2: Node type (Index 0x1000)

Offset: 3,4: Profile Number

Offset: 5: Node State

1: Disconnecting

2: Connecting

3: Preparing

4: Prepared

5: Operational

127: Pre-Operational

Offset: 6: Current Error

30: Guarding malfunction

31: Node has changed status

32: Sequence error in guarding protocol

33: No answer from remote frame PDO

34: No answer during a node configuration

35: Incompatible node profile number

36: Incompatible node device type number

37: Unknown SDO response received

38: SDO syntax error

39: Node in STOP mode

Offset: 7: Number of Emergency Messages

Offset: 8-47: Emergency buffer (-> node description)

The data contain the status. The emergency buffer contains the last emergency messages received. The node status bits are collated in the box state diagnostic input.