CANopen slave interface

There are two types of configuration. In the default configuration (delivery state) the CANopen data of the CANopen Slave interface map from the address 1000 of the BX5100/BC5150 and the first 4 PDOs are activated. In the TwinCAT configuration, any required configuration can be created via the System Manager and variables can be connected in any required combination with the CANopen slave interface.  

Default Configuration

In this configuration, the CANopen data are mapped as follows:

CANopen data

PDO number

Read/Write

BX process image

PDO 1

Rx/Tx

%IB1000...%IB1007/QB1000...%QB1007

PDO 2

Rx/Tx

%IB1008...%IB1015/QB1008...%QB1015

PDO 3

Rx/Tx

%IB1016...%IB1023/QB1016...%QB1023

PDO 4

Rx/Tx

%IB1024...%IB1031/QB1024...%QB1031

In the default configuration the Tx PDOs are only transferred in the event of a change.

More than 4 PDOs

Utilization of more than 4 PDOs can be specified in the TwinCAT configuration or in the default configuration. With the TwinCAT configuration the required PDOs are created in the System Manager file, and the configuration is transferred to the BX5100/BC5150. With the default configuration objects 0x14xx (for TxPDOs) and 0x18xx (for the RxPDOs) have to be used for this purpose before the node is started. The COB ID should be entered in subindex 1, and the data transfer type in subindex 2.

Example for PDO 5 of the node with address 11:
0x1804 subindex 1, length 4, value 0x68B
0x1804 subindex 2 length 1 value 0xFF (not necessarily required for activating the PDO)
0x1404 subindex 1 length 4 value 0x78B
0x1404 subindex 2 length 1 value 0xFF (not necessarily required for activating the PDO)

With the BX5100 a maximum of 32 PDOs can be used in each direction (32 TxPDOs and 32 RxPDOs). With the BC5150 a maximum of 16 PDOs can be used in each direction (16 TxPDOs and 16 RxPDOs).

PDO number

Read/Write

BX process image

PDO 5

Rx/Tx

%IB1032...%IB1039/QB1032...%QB1039

PDO 6

Rx/Tx

%IB1040...%IB1047/QB1040...%QB1047

PDO 7

Rx/Tx

%IB1048...%IB1055/QB1048...%QB1055

...

Rx/Tx

...

PDO 32

Rx/Tx

%IB1248...%IB1255/QB1248...%QB1255

Acyclic Synchronous

PDOs of transmission type 0 function synchronously, but not cyclically. An RxPDO is only evaluated after the next SYNC telegram has been received. In this way, for instance, axis groups can be given new target positions one after another, but these positions only become valid at the next SYNC - without the need to be constantly outputting reference points. A device whose TxPDO is configured for transmission type 0 acquires its input data when it receives the SYNC (synchronous process image) and then transmits it if the data correspond to an event (such as a change in input) having occurred. Transmission type 0 thus combines transmission for reasons that are event driven with a time for transmission (and, as far as possible, sampling) and processing given by the reception of "SYNC".

Cyclic Synchronous

In transmission types 1-240 the PDO is sent cyclically after each nth SYNC (n=1...240). Since transmission types can be combined on a device as well as in the network, it is possible, for example, for a fast cycle to be agreed for digital inputs (n = 1), whereas the data for analog inputs is transmitted in a slower cycle (e.g. n = 10). RxPDOs generally do not differentiate between the transmission types 0...240: a received PDO is set to valid with the next SYNC reception. The cycle time (SYNC rate) can be monitored (object 0x1006), so that if the SYNC fails the device reacts in accordance with the definition in the device profile, and switches, for example, its outputs into the error state. 

The CANopen CIFx0 PC cards always transmit under event control, even if the transmission type is set in the range from 1-240. This behavior is quite similar to transmission type 0. The FC510x PC cards support cyclic synchronous transmission types completely.

Asynchronous

The transmission types 254 and 255 are asynchronous, but may also be event-driven. In transmission type 254, the event is vendor-specific, whereas for type 255 it is defined in the device profile. In the simplest case, the event is the change of an input value - this means that every change in the value is transmitted.

Send delay time (inhibit time)

(BC5150 and BX5100 do not support this function.)

The Inhibit Time parameter can be used to implement a transmit filter that does not increase the reaction time for relatively new input alterations, but is active for changes that follow immediately afterwards. The send delay time describes the minimum time interval required between sending two identical telegrams. If the inhibit time is used, the maximum bus loading can be determined, so that the worst case latency can then be found.

CANopen slave interface 1:
Send delay time (inhibit time)

The transmitted PDOs become automatically spread out (transmit delay) as a result of the selected PLC cycle time - and there is little value in having the PLC run faster than the bus bandwidth permits. The bus loading, furthermore, can be significantly affected by the synchronous communication.

Event Timer

An event timer for transmit PDOs can be specified by subindex 5 in the communication parameters. Expiry of this timer is treated as an additional event for the corresponding PDO, so that the PDO will then be transmitted. If the application event occurs during a timer period, it will also be transmitted, and the timer is reset.

CANopen slave interface 2:
Event timer

In receive PDOs the timer parameter is used to specify the monitoring time for the respective PDO: The application will be notified if no corresponding PDO was received within the set time.