Tab 'CANopen Manager - General'

General
Node-ID	The node number identifies the CANopen manager as unique and if corresponds to the number set on the module (value between 1 and 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. : You have to start the CANopen manager from the application. Use the CiA405 NMT function block 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 must reset the slave from the application, using the CiA405 NMT function block.

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 heartbeat messages that 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.

SYNC
Enable SYNC producing	: (disabled by default) The CANopen manager sends SYNC telegrams. 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 activate the Enable Sync Producing option for all other bus devices.

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 must be a multiple of the task cycle time. Possible values [0...65535].

Note

The runtime system must support high resolution timestamps. If not, then an error message is displayed.

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.

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 Used 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 adjusts all timing values to compatible values. (The time should be a multiple of the task time.)