Tab 'CANopen Manager

Table 313: “General”
“Node-ID”	The node number identifies the CANopen Manager as unique (range of values: 1...127).
“Check and Fix Configuration”	Opens the dialog of the same name. See below for details.
“Autostart CANopen Manager”	: The CANopen Manager starts automatically (switches to OPERATIONAL mode) after all required slaves are ready. : The CANopen Manager has to be started from the application. The function block `‎CiA405.NMT‎` can be used to do this. Hint: As long as the CANopen Manager is not in OPERATIONAL mode, no PDOs are sent (outputs refreshed).
“Polling of optional slaves”	: When a slave does not respond during the boot sequence, the CANopen Manager interrogates it every second until it does respond. Constantly polling the slave increases the bus cycle time, which can interfere with the application (especially motion applications). You can deactivate polling to avoid this behavior. If polling is deactivated, then a slave is detected again when it sends a bootup message.
“Start slaves”	: The CANopen Manager is responsible for starting the slaves. : You have to start the slaves from the application. Use the CiA405 NMT function block to do this.
“NMT start all (if possible)”	: If the “Start slaves” option is activated, then the CANopen Manager starts all slaves with an "NMT Start All" command. The "NMT Start All" command is not executed as long as optional slaves are not yet ready to be started. In this case, the CANopen Manager starts each slave individually. The "NMT Start All" command can be guaranteed only in a project without optional slaves.
“NMT error behavior”	“Restart slave”. If an error occurs during slave monitoring (NMT Error Event), then the slave is restarted automatically by the stack (NMT Reset + SDO Configuration + NMT Start). “Stop slave”. If an error occurs during slave monitoring (NMT Error Event), then the slave is stopped. Then you have to reset the slave from the application, using the CiA405 NMT function block.

Table 314: “Guarding”
Working with heartbeat messages is an alternative method of monitoring. It can be executed from both master and slave nodes, as opposed to node guarding. Normally the master sends heartbeat messages to the slaves.
“Enable heartbeat producing”	The master sends heartbeats. They define the time interval in the “Producer time”. When the slaves are provided with the heartbeat function, a heartbeat consuming entry from the slave is created for the master. Then the Node-ID and the 1.5x heartbeat interval of the master are applied. : Node guarding is enabled for the slaves. The settings from the EDS file of the slaves are used for this. If the values there cannot be used, then default values are used. Note that a CANopen Slave device can also be configured as a heartbeat producer.
“Node-ID”	Unique identification (1-127) of the heartbeat producer on the bus
“Producer time (ms)”	Interval length between successive heartbeats (in milliseconds)
“Redundancy Node-ID”	Requirement: A “Redundancy Configuration” object is inserted below the application. Unique identification (1-127) of the redundant heartbeat producer on the bus
“Redundancy wait time (µs)”	Requirement: A “Redundancy Configuration” object is inserted below the application. Duration of how long the passive controller waits for the heartbeat of the active controller. If this time is exceeded, then the passive controller takes on the active role.

Table 315: “SYNC”
“Enable SYNC producing”	: The CANopen manager sends SYNC telegrams (disabled by default) The synchronous PDOs are sent directly after the SYNC telegram.
“COB-ID (Hex)”	CAN-ID of the SYNC telegram. Range of possible values: [1...2047].
“Cycle period (µs)”	Interval length (in microseconds) after which the SYNC telegram is sent
“Window length (µs)”	Length of the time frame for synchronous PDOs (in microseconds)
“Enable SYNC consuming”	: (disabled by default). Another device must produce the SYNC telegrams that are received by the CANopen Manager.

NOTICE

If SYNC producing is enabled for the CANopen manager, then you are not permitted to select the “Enable SYNC producing” option for all other bus devices.

Table 316: “TIME”
“Enable TIME producing”	: (disabled by default). The CANopen Manager sends TIME messages.
“COB-ID (Hex)”	(Communication Object Identifier): identifies the time stamp of the message. Default values: [0...2047], preset 16#100
“Producer time (ms)”:	Interval (in milliseconds) when the time stamp is sent. This value has to be a multiple of the task cycle time. Possible values [0, 65535]

The run time has to support high resolution timestamps. If not, then an error message is displayed.

See also

Dialog 'Check and Fix Configuration'

If you insert several devices below the CANopen manager, then error messages may report multiple assigned Node-IDs or invalid COB-IDs. The “Check and Fix Configuration” button opens a dialog for solving these conflicts.

For conflicts with Node-IDs or PDO COB-IDs, you can click “Edit Conflicts” to open a dialog with detailed information.

Table 317: “Node-ID and COB-ID conflicts”
“Doubled node number”	List of all devices with identical IDs. In the field of the “Node-ID” column, you can enter new node numbers for the affected devices.
“Incorrect and double assignment of PDO COB-IDs”	The COB-IDs that are generated automatically from the device description files may not be permitted. All incorrect entries are listed with the respective device names, Node-IDs, and indexes. There are three options for correcting invalid COB-IDs: Correct the displayed formula for calculating the COB-IDs so that a valid COB-ID results. You can change the formula in the respective table element. Accept the automatic suggestion for the COB-ID by clicking the respective button. Accept all automatic suggestions by clicking the “Use Suggested COB-ID” button.

Corrected entries are removed from the displayed list automatically.

You can solve timing problems automatically by using the “Automatic Repair”. The command modifies all timing values to compatible values. (The time should be a multiple of the task time.)