Quick Start for Experienced Users

Target group

This brief introduction is intended for users who are already familiar with CAN. It clarifies the CAN messages that are required in order to work with BECKHOFF CANopen input/output groups in the initial configuration (default settings).

It remains necessary to read and use the full documentation.

Hardware configuration

The DIP switches must be used to set a consistent transmission rate and differing node addresses (node ID) on the Bus Couplers. The switch assignments are printed on the modules. It should be noted that CANopen uses address ”0" to address all modules (broadcast), so that this can not be set as the address of a particular module.

Starting the modules

CANopen allows the modules to be started with a single network management telegram:

11 bit identifier	2 bytes of user data
0x00	0x01	0x00

The first data byte here contains the start command (Start_Remote_Node), while the second data byte contains the node address (here: 0, which addresses all nodes).

The inputs and outputs are enabled after the modules have been started. In the default setting the modules communicate in event-driven mode, so that changes at the digital inputs are immediately transmitted and outputs are immediately set in accordance with received telegrams containing output data.

CAN identifier

The CAN identifiers for the input and output data are derived from the node address (1-63):

Data type	Default CAN identifier
digital inputs 1...64	0x180 (=384_dec) + node address
digital outputs 1...64	0x200 (=512_dec) + node address
analog inputs 1...4	0x280 (=640_dec) + node address
analog outputs 1...4	0x300 (=768_dec) + node address
analog inputs 5...8*	0x380 (=896_dec) + node address
analog outputs 5...8*	0x400 (=1024_dec) + node address
analog inputs 9...12*	0x480 (=1152_dec) + node address
analog outputs 9...12*	0x500 (=1280_dec) + node address

* The range is displaced correspondingly if more than 64 digital inputs or outputs are present. See the Default Mapping section.

Digital inputs

The CAN messages with digital input data are composed as follows:

11 bit identifier	1-8 bytes of user data (depending on the number of input terminals or extension modules)
0x180(=384_dec) + node ID	I0	I1	I2	I3	I4	I5	I6	I7

I0: input bytes on input terminals (or Fieldbus Box modules), from left to right.

Digital outputs

The CAN messages with digital output data have the following structure:

11 bit identifier	1-8 bytes of user data (depending on the number of output terminals or extension modules)
0x200(=512_dec) + node ID	O0	O1	O2	O3	O4	O5	O6	O7

O0: output bytes on output terminals (or Fieldbus Box modules), from left to right.

Analog inputs

CAN messages with analog input data look like this:

11 bit identifier	4-8 bytes of user data (depending on the number of analog inputs)
0x280(640_dec) + node ID	I0.0	I0.1	I1.0	I1.1	I2.0	I2.1	I3.0	I3.1

I x.0...I x.1: analog input x. The data format is described in detail in the object directory at object 0x6401.

The transmission behaviour of analog inputs

To avoid ”swamping" the bus with constantly changing analog input values, the analog CANopen input modules do not generate any data telegrams in the default state. The analog data can be read out by means of a remote access (Remote Transmit Request, a CAN message with no data and with the RTR bit set) to the analog input telegrams. Alternatively, of course, the module can be re-configured in such a way that an alteration of the input value does trigger the sending of a telegram. For this purpose a value > 0 is written into index 0x6423 of the object directory. The corresponding SDO telegram looks like this:

11 bit identifier	8 bytes of user data
0x600(=768_dec) + node ID	0x22	0x23	0x64	0x00	0x01	0x00	0x00	0x00

It is recommended that event control (where every change in the LSB is considered an event, resulting in the corresponding telegram being transmitted) is not used for the transmission of input data, but that either cyclic, synchronous transmission or the event timer is used to send the data. If event control is indeed used, then the quantity of data should be reduced by setting a delta value (object directory index 0x6426), limit values (0x6424 + 0x6425) or an inhibit time (no new data transmission until the inhibit time has elapsed, 0x1801ff). Details of parameter communication are found in the section on Service data: SDO..

Analog outputs

CAN messages with analog output data look like this:

11 bit identifier	4-8 bytes of user data (depending on the number of analog outputs)
0x300(=768_dec) + node ID	O0.0	O0.1	O1.0	O1.1	O2.0	O2.1	O3.0	O3.1

O x.0...O x.1: analog output x. The data format is described in detail in the object directory at object 0x6411.

Default identifier

The appendix contains a tabular summary of all the default identifiers. The CAN messages displayed on a CAN monitor can quickly and easily be identified with the help of that overview.

Stopping the modules

If necessary, the process data communication from the modules can be stopped with the following telegram:

11 bit identifier	2 bytes of user data
0x00	0x80	0xYZ

0xXX: node address; 0xYZ=0x00 addresses all the modules

Guarding

The telegrams described above are themselves adequate for many applications. Since, however, the modules operate in event-driven mode by default (no cyclical data exchange), the failure of a module is not necessarily detected. A remedy for this is provided here through monitoring the modules by cyclically interrogating their status, a process known as node guarding.

For this purpose a status telegram is requested cyclically by means of remote transmit request (RTR):

11 bit identifier	No user data in the request telegram (RTR)
0x700(=1792_dec) + node ID	(RTR bit set in the header)

The modules answer with a telegram that includes a status byte.

11 bit identifier	1 byte of user data
0x700(=1792_dec) + node ID	0xYZ

0xYZ: Status byte:
bits 6...0 contain the node status (0x7F=127: pre-operational, 0x05=operational; 0x04= stopped or prepared).
Bit 7 = toggle bit (inverts with every transmission).

So that the Bus Coupler can detect failure of the network master (watchdog function), the guard time (object 0x100C) and the life time factor (object 0x100D) must be set to have value different from 0. (Reaction time to failure: guard time x life time factor).

Heartbeat

As an alternative to guarding, the module can also be monitored by means of what is called the heartbeat. This involves a status telegram (the heartbeat) being issued cyclically by the node. Data request telegrams (remote frames) are not required.

In order to activate the heartbeat telegram, the producer heartbeat time must be set. This is done with the following SDO telegram:

11 bit identifier	8 bytes of user data
0x600(=768_dec) + node ID	0x22	0x17	0x10	0x00	0xcd	0xab	0x00	0x00

where 0xabcd is the desired heartbeat cycle time, expressed in milliseconds.

With the telegrams that have now been described you are in a position to start and stop the modules, read inputs, write outputs and to monitor the modules. Do not neglect to read the manual with attention. Only by doing so can you properly use the many features of the BECKHOFF CANopen Bus Coupler.