This description is only intended for the use of trained specialists in control and automation engineering who
are familiar with the applicable national standards. It is essential that the following notes and explanations are
followed when installing and commissioning these components.
Liability Conditions
The responsible staff must ensure that the application or use of the products described satisfy all the requirements for safety, including all the relevant laws, regulations, guidelines and standards.
The documentation has been prepared with care. The products described are, however, constantly under development. For that reason the documentation is not in every case checked for consistency with performance
data, standards or other characteristics, and does not represent an assurance of characteristics in the sense of
§ 459, Para. 2 of the German Civil Code. In the event that it contains technical or editorial errors, we retain the
right to make alterations at any time and without warning. No claims for the modification of products that have
already been supplied may be made on the basis of the data, diagrams and descriptions in this documentation.
The responsible staff must ensure that the application or use of the products described satisfy all the requirements for safety, including all the relevant laws, regulations, guidelines and standards.
State at Delivery
All the components are supplied in particular hardware and software configurations appropriate for the application. Modifications to hardware or software configurations other than those described in the documentation are
not permitted, and nullify the liability of Elektro Beckhoff GmbH.
Personnel Qualification
This description is only intended for the use of trained specialists in control and automation engineering who
are familiar with the applicable national standards.
Description of safety symbols
The following safety symbols are used in this operating manual. They are intended to alert the reader to the
associated safety instructions.
Danger
Warning
Note
This symbol is intended to highlight risks for the life or health of personnel.
This symbol is intended to highlight risks for equipment, materials or the environment.
This symbol indicates information that contributes to better understanding.
CANopen is a widely used CAN application layer, developed by the CAN in Automation association, and which
has meanwhile been adopted for international standardisation.
Device Model
CANopen consists of the protocol definitions (communication profile) and of the device profiles that standardise
the data contents for the various device classes. Process data objects (PDO).are used for fast communication
of input and output data. The CANopen device parameters and process data are stored in a structured object
directory. Any data in this object directory is accessed via service data objects (SDO). There are, additionally, a
few special objects (such as telegram types) for network management (NMT), synchronisation, error messages
and so on.
9
Communication Types
CANopen defines a number of communication classes for the input and output data (process data objects):
· Event driven: Telegrams are sent as soon as their contents have changed. This means that the proc-
ess image as a whole is not continuously transmitted, only its changes.
· Cyclic synchronous: A SYNC telegram causes the modules to accept the output data that was previ-
ously received, and to send new input data.
· Requested: A CAN data request telegram causes the modules to send their input data.
The desired communication type is set by the "Transmission Type" parameter.
Device Profile
The Beckhoff CANopen devices support all types of I/O communication, and correspond to the device profile for
digital and analog input/output modules (DS401).
The default mapping has not been adapted to the profile version DS401 V2 because of the downward compatibility.
Transmission Rates
Nine transmission rates from 10 kbaud up to 1 Mbaud are available for different bus lengths. The effective utilisation of the bus bandwidth allows CANopen to achieve short system reaction times at relatively low data rates.
CAN is based on a linear topology. The number of devices participating in each network is logically limited by
CANopen to 128, but physically the present generation of drivers allows up to 64 nodes in one network segment. The maximum possible size of the network for any particular data rate is limited by the signal transit time
required on the bus medium. For 1 Mbaud, for instance, the network may extend 25 m, whereas at 50 kbaud
the network may reach up to 1000 m. At low data rates the size of the network can be increased by repeaters,
which also allow the construction of tree structures.
Bus access procedures
CAN utilises the Carrier Sense Multiple Access (CSMA) procedure, i.e. all participating devices have the same
right of access to the bus and may access it as soon as it is free (multi-master bus access). The exchange of
messages is thus not device-oriented but message-oriented. This means that every message is unambiguously
marked with a prioritised identifier. In order to avoid collisions on the bus when messages are sent by different
devices, a bit-wise bus arbitration is carried out at the start of the data transmission. The bus arbitration assigns
bus bandwidth to the messages in the sequence of their priority. At the end of the prioritisation phase only one
bus device occupies the bus, collisions are avoided and the bandwidth is optimally exploited.
Configuration and parameterisation
The TwinCAT System Manager allows all the CANopen parameters to be set conveniently. An "eds" file (an
electronic data sheet) is available on the Beckhoff website for the parameterisation of Beckhoff CANopen devices using configuration tools from other manufacturers.
Certification
The Beckhoff CANopen devices have a powerful implementation of the protocol, and are certified by CiA, the
CAN in Automation association.
On the card there are CAN terminating resistors (120 Ohms). These can be activated with a jumper (up to
hardware version 3) or with a switch (from hardware version 4) close to the CAN connectors.
The Flash Disk Socket is currently not in use.
11
Pin out
The CAN network is connected via 9-pin DB9 sockets with the following pin out:.
Fieldbus PCI cards may only be fitted by qualified personnel in accordance and the following
points must be observed.
· In order to protect the card from electrostatic discharge the user must be discharged before handling
the card or the PC.
· Before opening the PC housing it must be switched off, and the mains plug must be removed.
13
In may be necessary before fitting to set the jumper in order to activate the internal CAN bus terminating resistors, or to set the switch (as from hardware version 3). The jumper being set or the switch being on means that
the terminating resistor is connected.
The card can be fitted into any free PCI slot. Ensure that the PCI bus connector is making good contact, and
that the module is seated firmly. Fasten the module to the PC slot housing with the fixing screw.
Notes related to checking the CAN wiring can be found in the Trouble Shooting section.
CAN topology
CAN is a 2-wire bus system, to which all participating devices are connected in parallel (i.e. using short drop
lines). The bus must be terminated at each end with a 120 (or 121) Ohm terminating resistor to prevent reflections. This is also necessary even if the cable lengths are very short!
Since the CAN signals are represented on the bus as the difference between the two levels, the CAN leads are
not very sensitive to incoming interference (EMI): Both leads are affected, so the interference has very little
effect on the difference.
Bus length
The maximum length of a CAN bus is primarily limited by the signal transit time. The multi-master bus access
procedure (arbitration) requires signals to reach all the nodes at effectively the same time (before the sampling
within a bit period). Since the signal transit times in the CAN connecting equipment (transceivers, opto-
couplers, CAN controllers) are almost constant, the line length must be chosen in accordance with the baud
rate:
Baud Rate Bus length
1 Mbit/s < 20 m*
500 kbit/s < 100 m
250 kbit/s < 250 m
125 kbit/s < 500 m
50 kbit/s < 1000 m
20 kbit/s < 2500 m
10 kbit/s < 5000 m
*) A figure of 40m at 1 Mbit/s is often found in the CAN literature. This does not, however, apply to networks
with optically isolated CAN controllers. The worst case calculation for opto-couplers yields a figure 5 m at 1
Mbit/s - in practice, however, 20 m can be reached without difficulty.
It may be necessary to use repeaters for bus lengths greater than 1000 m.
Drop lines must always be avoided as far as possible, since they inevitably cause reflections. The reflections
caused by drop lines are not however usually critical, provided they have decayed fully before the sampling
time. In the case of the bit timing settings selected in the bus couplers it can be assumed that this is the case,
provided the following drop line lengths are not exceeded:
Baud Rate Drop line length Total length of all drop lines
1 Mbit/s < 1m < 5 m
500 kbit/s < 5 m < 25 m
250 kbit/s < 10m < 50 m
125 kbit/s < 20m < 100 m
50 kbit/s < 50m < 250 m
Drop lines must not have terminating resistors.
Star Hub (Multiport Tap)
Shorter drop line lengths must be maintained when passive distributors ("multiport taps"), such as the Beckhoff
ZS5052-4500 Distributor Box. The following table indicates the maximum drop line lengths and the maximum
length of the trunk line (without the drop lines):
Baud Rate Drop line length with multiport topology Trunk line length (without drop lines)
Screened twisted-pair cables (2x2) with a characteristic impedance of between 108 and 132 Ohm is recommended for the CAN wiring. If the CAN transceiver’s reference potential (CAN ground) is not to be connected,
the second pair of conductors can be omitted. (This is only recommended for networks of small physical size
with a common power supply for all the participating devices).
ZB5100 CAN Cable
A high quality CAN cable with the following properties is included in Beckhoff's range:
· 2 x 2 x 0.25 mm² (AWG 24) twisted pairs, cable colours: red/black + white/black
· double screened
· braided screen with filler strand (can be attached directly to pin 3 of the 5-pin connection terminal),
· flexible (minimum bending radius 35 mm when bent once, 70 mm for repeated bending)
· characteristic impedance (60 kHz): 120 Ohm
· conductor resistance < 80 Ohm/km
· sheath: grey PVC, external diameter 7.3 +/- 0.4 mm
· Weight: 64 kg/km.
· printed with "BECKHOFF ZB5100 CAN-BUS 2x2x0.25" and metre marking (length data every 20cm)
ZB5200 CAN/DeviceNet Cable
The ZB5200 cable material corresponds to the DeviceNet specification, and is also suitable for CANopen systems. The ready-made ZK1052-xxxx-xxxx bus cables for the Fieldbus Box modules are made from this cable
material. It has the following specification:
· 2 x 2 x 0.34 mm² (AWG 22) twisted pairs
· double screened braided screen with filler strand
· characteristic impedance (1 MHz): 126 Ohm
· conductor resistance 54 Ohm/km
· sheath: grey PVC, external diameter 7.3 mm
· printed with "InterlinkBT DeviceNet Type 572" as well as UL and CSA ratings
· stranded wire colours correspond to the DeviceNet specification
· corresponds to the DeviceNet "Thin Cable" specification
Screening
The screen is to be connected over the entire length of the bus cable, and only galvanically grounded at one
point, in order to avoid ground loops.
The design of the screening, in which HF interference is diverted through R/C elements to the mounting rail
assumes that the rail is appropriately earthed and free from interference. If this is not the case, it is possible that
HF interference will be transmitted from the mounting rail to the screen of the bus cable. In that case the screen
should not be attached to the couplers - it should nevertheless still be fully connected through.
17
Notes related to checking the CAN wiring can be found in the Trouble Shooting section.
Cable colours
Suggested method of using the Beckhoff CAN cable on Bus Terminal and Fieldbus Box:
BK51x0
pin
1 3 3 CAN
2 5 2 CAN Low
3 1 5 Screen Filler strand Filler strand
4 4 7 CAN high
5 2 9 not used
Fieldbus Box
pin
FC510x
pin
Function
Ground
ZB5100 cable colour
black/ (red) black
black blue
white white
(red) (red)
ZB5200 cable colour
FC510x: D-sub, 9 pin
The CAN bus cable is connected to the FC5101 and FC5102 CANopen PCI cards via 9-pin sub-D sockets, with
pins assigned as follows.
Pin Assignment
2
3
5
6
7
The unlisted pins are not connected.
CAN low (CAN-)
CAN ground (internally connected to pin 6)
Screen
CAN ground (internally connected to pin 3)
CAN high (CAN+)
Note: An auxiliary voltage of up to 30 V DC may be connected to pin 9. Some CAN devices use this to supply
the transceiver.
The BK51x0 Bus Couplers have a recessed front surface on the left hand side with a five pin connector.
The supplied CANopen socket can be inserted here.
The left figure shows the socket in the BK51x0 Bus Coupler. Pin 5 is the connection strip's top most pin. Pin 5 is
not used. Pin 4 is the CAN high connection, pin 2 is the CAN low connection, and the screen is connected to
pin 3 (which is connected to the mounting rail via an R/C network). CAN-GND can optionally be connected to
pin 1. If all the CAN ground pins are connected, this provides a common reference potential for the CAN transceivers in the network. It is recommended that the CAN GND be connected to earth at one location, so that the
common CAN reference potential is close to the supply potential. Since the CANopen BK51X0 Bus Couplers
provide full electrical isolation of the bus connection, it may in appropriate cases be possible to omit wiring up
the CAN ground.
ZS1052-3000 Bus Interface Connector
The ZS1052-3000 CAN Interface Connector can be used as an alternative to the supplied connector. This makes the wiring significantly easier. There are separate terminals for incoming and outgoing leads and a large
area of the screen is connected via the strain relief. The integrated terminating resistor can be switched externally. When it is switched on, the outgoing bus lead is electrically isolated - this allows rapid wiring fault location
and guarantees that no more than two resistors are active in the network.
LC5100: Bus connection via spring-loaded terminals
In the low cost LC5100 coupler, the CAN wires are connected directly to the contact points 1 (CAN-H, marked
with C+) and 5 (CAN-L, marked with C-). The screen can optionally be connected to contact points 4 or 8,
which are connected to the mounting rail via an R/C network.
The IPxxxx-B510, IL230x-B510 and IL230x-C510 Fieldbus Boxes are connected to the bus using 5- pin M 12
plug-in connectors.
Beckhoff offer plugs for field assembly, passive distributor's, terminating resistors and a wide range of preassembled cables for the Fieldbus Box system. Details be found in the catalog, or under www.beckhoff.de
The TwinCAT System Manager Tool is used to configure the FC510x CANopen PCI card. The System Manager provides a representation of the number of programs of the TwinCat PLC systems, the configuration of the
axis control and of the connected I/O channels as a structure, and organises the mapping of the data traffic.
For applications without TwinCAT PLC or NC, the TwinCAT System Manager Tool configures the programming
interfaces for a wide range of application programs:
· ActiveX control (ADS-OCX) for e.g. Visual Basic, Visual C++, Delphi, etc.
· DLL interface (ADS-DLL) for e.g. Visual C++ projects
· Script interface (ADS script DLL) for e.g. VBScript, JScript, etc.
System Manager – Features
- Bit-wise association of server process images and I/O channels
- Standard data formats such as arrays and structures
- User defined data formats
- Continuous variable linking
- Drag and Drop
- Import and export at all levels
Configuration by means of the TwinCAT System Manager
The procedure, and the configuration facilities in the System Manager are described below.
Shows in which logical PCI slot the card was detected and which IRQ is assigned to it. The IRQ is unused.
Master Node Id:
Node address for the FC510x. Value range: 1...127. Determines the identifier of the master heartbeat telegram.
Ensure that it is not the same as a slave node address.
Baud rate:
Set the Baud rate here. Automatically tests whether the connected slave also supports this baud rate.
Synchronization Mode:
The synchronization mode determines the accuracy of the CANopen SYNC telegram generation.
The highest priority task linked with the FC510x device controls the CANopen card and is thereby synchronized
with the fieldbus. All other tasks are served asynchronously via corresponding buffers. For all operating modes
you can individually set the communication type for each process data object (PDO) - event driven or synchronized (in each PDO tab). If one of the PDOs has been configured for synchronous operating mode, a SYNC
telegram is sent at the start of the cycle, which the slaves use to synchronize their actions with the master cycle.
Depending on the sync accuracy requirements of the application several modes can be selected. Please note,
that due to CAN technology a single SYNC telegram may jitter for one entire frame length it the bus is busy at
the time of sync generation. The SYNC accuracy therefore refers to the long time stability. Bus nodes that use
a phase locked loop (PLL) mechanism to synchronize themselves require a maximum long time stability or
accuracy of the SYNC.
In slave synchronization mode the card receives its time basis from a sync master. The sync master is selected
at the corresponding field.
· Sync Master: PC-Task. This is the default setting. The PC provides the time basis using the TwinCAT
Real Time. Depending on the settings the Task start (Default with TwinCAT NC) or the Task end (Default at TwinCAT PLC) triggers the SYNC telegram.
· Sync Master: Balanced PC Task. This operating mode as well generated the CANopen Sync cycle
with the long term accuracy of the PC time basis. However, the short term accuracy (interval between
two SYNC telegrams) is better that with Sync Master "PC-Task":
- Run time differences (e.g. caused by case dependent program calls) are leveled out,
- the FC510x delays pending transmit telegrams until the SYNC telegram was sent,
- the SYNC intervals are determined by the quartz timer of the FC510x card.
The card timer is adjusted in small steps to the PC-timer if the difference is larger that the value of the
"PLL Sync Time".
In this mode the SYNC telegram is delayed for the Shift Time after the end of the TwinCAT task cycle.
Here the shift time should be set to a value as small as possible - but large enough to allow the process data access by the TwinCAT task. The function "Calculate Equi-Times" helps to configure the optimal shift time. It is started by selecting the corresponding button.
In master synchronization mode the card generates its time basis locally. The SYNC is generated with long
time quartz accuracy. The start of the TwinCAT task is triggered by the card, delayed by the Shift Time. In this
mode the shift time value should be as large as possible. The function "Calculate Equi-Times" helps to configure the optimal shift time. It is started by selecting the corresponding button.
Cycle Time:
Displays the cycle time of the corresponding highest priority task. The value is updated when the TwinCAT
mapping is generated.
Sync-Cycle Multiplier:
CANopen SYNC Cycle Time = (Task) Cycle Time x Sync-Cycle Multiplier. Event driven PDO communications
and cyclic synchronized PDO communication are frequently combined when used in conjunction with CANopen. In order to be able to respond rapidly to an event, the TwinCAT task cycle time has to be less than the
CANopen SYNC cycle time.
Sync-Cycle time
Shows the cycle time of the CANopen SYNC telegram. This cycle time is derived from the highest priority task
which has process data linked to the card, and the Sync Cycle Multiplier.
Sync-Tx-PDO Delay:
Directly after the SYNC telegram, the synchronized slaves send their input data/actual values. The FC510x can
delay the sending of the output data / set value (TxPDOs from the perspective of the card) in order to minimize
the telegram burst directly after the SYNC. The Sync-Tx-PDO delay parameter is used to set this delay in percent of the Sync Cycle Time.
Task Cycle Time = 2000µs, Sync Cycle Multiplier = 5, Sync Tx-PDO Delay =40[%]. Event driven
PDOs can be processed by the PLC task every 2 ms. The CANopen sync cycle is 10 ms, the
FC510x sends its synchronized PDOs 4ms (=40% of 10ms) after SYNC.
25
Search...:
Searches for all connected FC510x channels. Select those required. In the case of an FC5102 both channels A
and B appear. These behave in logical terms like two FC5101 cards.
Hardware Configuration …:
In which the address of the FC510x is set in the lower memory area (below 1 MB) of the PC.
Upload Configuration:
Scans the CANopen network and adds all detected equipment to the device (FC510x) (only available when no
box has been configured). In the case of Beckhoff boxes, reads the configuration precisely. In the case of external devices, the PDO configuration and the identity object are read and evaluated.
Verify Configuration:
Allows one to compare the expected (configured) network configuration with the actual (physically present)
configuration. The data from the CANopen Identity object is read an compared. In the case of Beckhoff Boxes
the connected Bus Terminals or Extension Modules are identified ad compared. In preparation.
Firmware:
Shows the current firmware version of the FC510x.
Firmware Update...:
Update the FC510x card firmware version here. Warning: The TwinCAT System must be stopped for this function.
”ADS” tab
The FC510x is an ADS device with its own net ID, which can be changed here. All ADS services (diagnosis,
non-cyclical communication) going to the FC510x must address this net ID.
See ”Online Display of DPRAM" in the System Manager Documentation.
Input Diagnosis
The FC510x automatically provides various diagnostic variables which describe the status of the card and the
CANopen network:
cycleCounter: Is incremented at the end of each firmware cycle in order that this variable can indicate whether
the last cycle was completed before the task was started.
Error: Shows the number of slaves whose Box State is not equal to zero. Only check the BoxState of the slaves if this value is other than 0.
ActualCycleTime: Shows the current cycle time in 4/25 µs. This variable is only updated when all slaves are
involved in the data exchange (and when error is 0)
DiagFlag: Shows whether the diagnostics information on the card has changed. This can be read off using
ADS Read. For that purpose, specify the net ID of the FC510x, the port number 200 and the IndexGroup
0xF100. The IndexOffset and the length then relate to the diagnostic data. (Note: The Box States are also available as box variables.)
Offset 1-127: BusStatus List, 1-127 one byte per station address which contains the station status (see BoxState for CANopenboxes)
Global State: Various diagnostic and status displays for the FC510x. The byte in GlobalState(0) shows the
status of the card in relation to the TwinCAT system: RUN, RESET, OFFLINE and STOP are distinguished.
GlobalState(2) gives information about the status of the CAN controller: "CAN Warning Limit Reached" and
"Bus Off" are displayed. Warning limit reached means that the send/receive error counter on the CAN controller
has exceeded the value 96. BusOff means that the CAN controller can no longer participate in bus communication; this is caused by an excessive number of CAN errors (Error Frames). In this case there is a serious physical error in the CAN network. (e.g. too little or too much matching resistors, at least a device with an incorrect
baudrate, short circuit etc.) The bus off state is only left by a card reset. Details about further global state data,
see comments in ”Online” tab.
LastAdsError: Shows the error code of the last ADS access error, e.g. if an attempt has been made to read
the diagnostic data for a deactivated node.
CycleFailedCounter: Counts the number of firmware cycles which could not be completed before the associated task wanted to re-read/re-write the process image. If this counter is incremented, the task cycle time has
been set too low for the actual network configuration.
27
BusLoad: Shows the current bus load in %. The Bus Load is an important design criterion for CAN networks.
The value shown is a average value over 100ms.
The BK51x0 Bus Coupler and the IPxxx-B510 fieldbus box are installed in the CANopen bus. Those specific
properties which distinguish them from other Bus Couplers and/or Fieldbus Box modules are described below.
Following Bus Couplers are currently supported by TwinCAT:
Types Description
BK5100
BK5110
BK5120
LC5100
IPxxxx-B510
ILxxxx-B510
"BK51x0/IX-B510" tab
Bus Coupler
Economy Buskoppler
Bus Coupler, successor of BK5100
Low-cost Bus Coupler
Fieldbus Compact Box: CANopen in/output module, protection class IP67
Fieldbus Coupler Box: Expandable CANopen in/output module, protection class IP67
Node Id: Sets the node ID of the CAN bus device (between 1 and 63 (BK51x0) and/or 1 and 99 (IPxxxx-B510)).
This value must comply with the value set at the Bus Coupler and/or at the compact box.
Guard time: Cycle time for the node monitoring (node guarding).
Life time factor: Guard time multiplied produces the watchdog time for the monitoring of the master by the
coupler (life guarding). Life guarding is deactivated if the lifetime factor is set to zero.
Inhibit time: Displays the minimum send interval for PDOs (telegrams) with analogue and special signals. If
more than digital 64 signals are present, these are also provided with this Inhibit Time.
Event Time: Sets the Event Timer Value for Transmit PDOs. The expiration of this timer is regarded as additional event for the corresponding PDO. Thus the PDO is being sent. If the application event occurs during the
event timer period the PDO is sent as well and the timer is reset.
K-Bus Update: Calculates the anticipated duration of a complete update of the terminal bus (according to type
and number of connected terminals).
Trans.Type: Gives the Transmission Type for digital / analogue input telegrams. 254 + 255 corresponds to the
event-driven transfer, 1 … 240 are synchronous transfer types. For further details see also BK51X0 manual.
Firmware Update: Enables the updating of the coupler firmware via the serial interface (requires KS2000 software package interface cable).
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 on the basis of 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 provides an ADS port at all times 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. For details see Chapter SDO Communication
"Diag" tab
The diag tab displays the diagnosics information. The window contents are not refreshed cyclically. If required
dial the "Refresh" button. The represented diagnosis information can be also questioned by ADS.
CANopen devices which are not recognised by the TwinCAT System Manager can be incorporated into the
network by selecting the box ”CANopen Node”. The CAN(open) messages (PDOs) can be configured directly
for these devices. This will guarantee the optimum flexibility of this general CANopen interface.
When using the FC510x, this box also enables you to receive and send any CAN identifier - this enables communication with any CAN node. The only condition is the support of at least one of the Baud Rates supported
by the FC510x.
"CAN Node" tab
Node ID: Enter the general CANopen device node address here. If you select the ”Auto Adapt 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 supported device
profile in both the lowest value bytes. These are entered here and compared at the system StartUp with the
device parameters present. If no device profile is supported, the parameter will contain the value 0.
Add Info: The additional info is located in both the highest value bytes of the object directory entry 0x1000 (device type).
FC510x: Comparison of the set/actual configuration takes place only if the profile no. or add info
(i.e. object directory entry 0x1000) are configured to a value other than zero. If the expected data
at the system start do not comply with the values present, the StartUp 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
comply, the node StartUp is interrupted.
Guard Time: The guard time determines the interval in which the node is monitored (node guarding). 0 signifies
no monitoring.
Life time factor: Guard time x lifetime 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 as producer heartbeat time
and (guard time x lifetime factor) as consumer heartbeat time are entered. The card then transmits
its heartbeat telegram with the smallest configured guard time (the guard times can be set indi-
Emcy COB Id. and Guard COB Id. are the identifiers for emergency messages and/or guarding protocol and
are based on the node address.
Automatic PDO... Specifies whether TwinCAT should download the PDO communications parameters to the
node at the system start.
FC510x: If the download of the PDO parameters fails, the card attempts to read these parameters
and compares them with the configured values. In this way, it supports only those nodes which,
e.g. have implemented the default identifiers as read-only values.
CIFx0-CAN: The PDO parameters are transferred to the CANopen node, but allowance is made if
the node does not support these inputs - requires only the conformation of the SDO access (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 inputs (0x1018 in the object directory) are read off at the system StartUp and compared with the configured values. The corresponding node will be started only if the values coincide. It is also
possible to compare one part of the value (e.g. vendor ID and product code) - in this case set the not desired
parameters to zero.
Node Error Response (FC510x only):
Stop Node: After a recognised node error, the node is set to ”Stopped” mode (NMT command
"Stop Remote Node"). The node (according to each device profile) can then be switched to a safe
mode via the network status machine - SDO addressing is not possible in this mode.
31
No Response: No NMT stop remote node command after node error
Node Restart (FC510x only):
Automatic Restart: After a recognised node error the card automatically attempts to restart the
node. The StartUp attempt is initiated by a node reset command.
Manual Restart: After a node error, this node remains in error mode and is not restarted automatically. You can actuate a restart via "I/O-Reset".
Network Response (FC310x only):
No Response: The failure of a node has no effect on the other bus devices
All Nodes Stop: 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 you have selected this checkbox, the entire CANopen network management for this device is deactivated. It is not started, monitored etc. The PDO inputs are detected as pure CAN
(2-layer) telegrams and enable the controller to operate in event driven mode.
Warning: As the CANopen terminology is retained, even in the case of the general CAN nodes, you
need to take into account the fact 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 comply. 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.
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 behaviour 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 on the basis of the parameters entered
here. These are transferred via SDO at the system start. You can view the inputs at the SDO tab. If this behaviour is not required, you can deactivate "Auto Download of PDO Parameters" by selecting the checkbox at the
CAN node tab.
Tree Representation:
TwinCAT firstly provides two send and receive PDOs, 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.
Warning: Please note that TwinCAT assigns the PDOs to the object dictionary entries in the node using
the sequence in which the system manager displays the PDOs. For instance the PDO communication parameter of the third listed TxPDO are always written to index 0x1802 - independent of the name of the PDO in the
system manager. So if only PDO1 and PDO3 are to be used, PDO2 has to be entered as well - in this case
without variables assigned. PDOs without variables are not sent and are not expected by the card.
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
33
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 on the basis of 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 provides an ADS port at all times 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.
The configuration options for a CANopen device are available in eds files (electronic data sheets) in a standard
data format. The data format is specified in CiA DSP 306. A tool is available from the CAN-in-Automation e.V.
user association with which this data format can be checked.
Since it was found that a large number of eds files do not properly observe the standard, Beckhoff have until
now not supported eds files in the system manager. The direct configuration of PDO parameters makes it possible to adapt to the devices that are to be incorporated, and also to use devices that do not entirely meet the
standard.
CANopen allows the distributed network to boot in a very simple way. After initialisation, the modules are automatically in the Pre-Operational state. In this state it is already possible to access the object directory using
service data objects (SDOs) with default identifiers, so that the modules can be configured. Since default settings exist for all the entries in the object directory, it is in most cases possible to omit any explicit configuration.
Only one CAN message is then required to start the module: Start_Remote_Node: Identifier 0, two data bytes:
0x01, 0x00. It switches the node into the Operational state.
Network Status
The states and the state transitions involved as CANopen boots up can be seen from the state diagram:
35
Pre-Operational
After initialisation the bus coupler goes automatically (i.e. without the need for any external command) into the
Pre-Operational state. In this state it can be configured, since the service data objects (SDOs) are already active. The process data objects, on the other hand, are still locked.
Operational
In the Operational state the process data objects are also active.
If external influences (such as a CAN error, or absence of output voltage) or internal influences (such as a KBus error) mean that it is no longer possible for the bus coupler to set outputs, to read inputs or to communicate, it attempts to send an appropriate emergency message, goes into the fault state, and thus returns to the
Pre-Operational state. In this way the NMT status machine in the network master can also immediately detect
fatal errors.
Stopped
In the Stopped state (formerly: Prepared) data communication with the coupler is no longer possible - only NMT
messages are received. The outputs go into the fault state.
The network management messages have a very simple structure: CAN identifier 0, with two bytes of data content. The first data byte contains what is known as the command specifier (cs), and the second data byte contains the node address, the node address 0 applying to all nodes (broadcast).
11 bit identifier 2 byte of user data
0x00 cs Node-ID
The following table gives an overview of all the CANopen state transitions and the associated commands
(command specifier in the NMT master telegram):
Status
transition
(1) - The initialisation state is reached automatically at power-up
(2) - After initialisation the pre-operational state is reached automatically - this
Starts the module, enables outputs, starts transmission of PDOs.
Outputs go into the fault state, SDO and PDO switched off.
cs = 129 = 0x81 Reset_Node. Carries out a reset. All objects are reset to their power-on
defaults.
cs = 130 = 0x82 Reset_Communication. Carries out a reset of the communication functions.
Objects 0x1000 - 0x1FFF are reset to their power-on defaults.
Example 1
The following telegram puts all the modules in the network into the error state (outputs in a safe state):
11 bit identifier 2 byte of user data
0x00 0x02 0x00
Example 2
The following telegram resets node 17:
11 bit identifier 2 byte of user data
0x00 0x81 0x11
Boot-up message
After the initialisation phase and the self test, the bus coupler sends the boot-up message, a CAN message
with one data byte (0) and the identifier of the guarding or heartbeat message: CAN-ID = 0x700 + Node-ID. In
this way temporary failure of a module during operation (e.g. due to a voltage interruption), or a module that is
switched on at a later stage, can be reliably detected, even without Node Guarding. The sender can be determined from the message identifier (see default identifier distribution).
It is also possible, with the aid of the boot-up message, to recognise the nodes present in the network at startup with a simple CAN monitor, without having to make write access to the bus (such as a scan of the network
by reading out parameter 0x1000).
Finally, the boot-up message communicates the end of the initialisation phase; the bus coupler signals that it
can now be configured or started.
Note
Up to firmware status BA the emergency identifier was used for the boot up message.
Heartbeat and guarding mechanisms are available to monitor failures in the CANopen network. These are of
particular importance for CANopen, since modules do not regularly speak in the event-driven mode of operation. In the case of "guarding", the devices are cyclically interrogated about their status by means of a data request telegram (remote frame), whereas with "heartbeat" the nodes transmit their status on their own initiative.
Guarding: Node Guarding and Life Guarding
Node Guarding is used to monitor the non-central peripheral modules, while they themselves can use Life
Guarding to detect the failure of the guarding master. Guarding involves the master sending remote frames
(remote transmit requests) to the guarding identifier of the slaves that are to be monitored. These reply with the
guarding message. This contains the slave’s status code and a toggle bit that has to change after every message. If either the status or the toggle bit do not agree with that expected by the NMT master, or if there is no
answer at all, the master assumes that there is a slave fault.
Guarding procedure:
37
Protocol
The toggle bit (t) transmitted in the first guarding telegram has the value 0. After this, the bit must change (toggle) in every guarding telegram so that the loss of a telegram can be detected. The node uses the remaining
seven bits to transmit its network status (s):
s Status
4 = 0x04 Stopped (formerly: prepared)
5 = 0x05 Operational
127 = 0x7F Pre-Operational
Example
The guarding message for node 27 (0x1B) must be requested by a remote frame having identifier 0x71B
(1819
0x85, whereas in the Pre-Operational state it alternates between 0x7F and 0xFF.
). If the node is Operational, the first data byte of the answer message alternates between 0x05 and
If the master requests the guard messages in a strict cycle, the slave can detect the failure of the master. In this
case, if the slave fails to receive a message request from the master within the set Node Life Time (a guarding
error), it assumes that the master has failed (the watchdog function). It then puts its outputs into the error state,
sends an emergency telegram, and returns to the pre-operational state. After a guarding time-out the procedure
can be re-started by transmitting a guarding telegram again.
The node life time is calculated from the guard time (object 0x100C) and life time factor (object 0x100D) parameters:
Life time = guard time x life time factor
If either of these two parameters is ”0” (the default setting), the master will not be monitored (no life guarding).
Heartbeat: Node Monitoring without Remote Frame
In the heart beat procedure, each node transmits its status message cyclically on its own initiative. There is
therefore no need to use remote frames, and the bus is less heavily loaded than under the guarding procedure.
The master also regularly transmits its heartbeat telegram, so that the slaves are also able to detect failure of
the master.
Heartbeat procedure
Protocol
The toggle bit is not used in the heart beat procedure. The nodes send their status cyclically (s). See Guarding.
The firmware in the FC510x CANopen PCI card treats each individual node separately. The first action following the system start is to check for the presence of the expected nodes, and whether they basically correspond
to the devices that have been configured. Following this, each node is parameterised and started, independently of the others. The starting behaviour of a node is described below.
1. Reset All Nodes
The starting sequence begins with the global Reset Communication telegram, so that all nodes are brought in
to a defined initial state.
2. Identify Node
Presence of the nodes is first established through an SDO upload of the object 0x1000 (device type). The content supplied by a node is checked for agreement with the expected value. Object 0x1000 is composed of the
profile number and of the additional information - both values can be found on the CAN Node tab.
If both the additional information and the profile number are set to "0", the contents returned for object 0x1000
is not checked. An answer containing an SDO abort protocol cannot be tolerated; the process is interrupted.
39
For values other than zero, the next step is only taken if the value is as expected. Otherwise the process is
aborted and the node enters state 0x04 (SDO syntax error at start-up if an SDO abort message has been received or if the data length is incorrect) or state 0x05 (if there is an SDO data mismatch at start-up or the value
do not comply) and an appropriate error message is displayed in the dialog box.
If the node does not answer the SDO upload telegram, then the SDO protocol is interrupted after it has timed
out (approx. 2 seconds) and then repeated after a waiting time (of approx. 1 second) until the node answers. In
this phase, the node is in state 0x02 (node not found).
If the vendor ID, the product code, the serial no. or the revision no. have been configured to values other than
zero on the CAN Node's tab, then the corresponding values are read and compared in the node's object
0x1018. The booting process is only continued if they are as expected.
3. Set SYNC Time
If synchronous PDOs have been configured, an attempt is now made a to enter the given Sync Cycle Time into
object 0x1006 (SYNC interval). Because this object is optional, the boot up is still continued even if the node
acknowledges negatively - it is, however, necessary for the node to answer.
4. Set PDO Parameters
If the "Auto-download PDO parameters" checkbox on the CAN node's tab has been selected (which it is by
default) then the PDO parameters for all the configured PDOs are now written. These are the identifier and the
transmission type. The Inhibit Time and the Event Time are only written at this stage if they have been configured to have values other than zero.
If a node answers an SDO download of the PDO parameters with an SDO abort protocol, then the corresponding entry is then read (SDO upload) and compared with the value to be written. If they are in agreement, the
process continues. In this way it is possible for read-only PDO parameters to be tolerated, provided they agree
with the configured values.
The next step is only taken if the download, or the comparison with existing values, is successful. Otherwise the
process is aborted, and the node enters state 0x04 or 0x05, and the appropriate error message is displayed in
the dialog box.
5. Set Guarding/Heartbeat
If a value other than zero has been configured for the Guard Time, the appropriate parameters are now written
to the nodes. Because the heartbeat process generates less bus loading than guarding, an attempt is first made to start this form of node monitoring on the CANopen nodes.
Heartbeat: The guard time is entered as the producer heartbeat time (0x1017) and the product of (guard time x
life time factor) is entered as the consumer heartbeat time (0x1016). The FC510x card then transmits cyclically
40
its heartbeat telegram with the smallest configured guard time (the guard times can be set individually for each
node). If the node refuses the entry of the consumer heartbeat time, then it is assumed that the node does not
support monitoring of the master - this is tolerated. If entry of the producer heartbeat time also fails, then the
guarding protocol is configured.
Guarding: If the node does not support the heartbeat, then the guarding parameters (guard time, 0x100C and
life time factor, 0x100D) are entered.
If this attempt also fails, then the start-up process is aborted, and the node enters state 0x04, with an appropriate error message being sent to the dialog box.
The objects added manually on the SDO tab are now transmitted to the node by SDO download. Once again, if
the SDO is interrupted the value is fed back and checked for agreement, so that read-only parameters can be
tolerated. The process only continues it successful, and otherwise is aborted.
7. Start Node
After all the parameters have successfully been downloaded, the node is switched into the operational state by
means of an individual Start_Remote_Node telegram. RxPDOs are first sent to the nodes about 1 s after this
start telegram, and the guarding or heartbeat protocol begins. Node monitoring by heartbeat does not start until
the node's producer heartbeat telegram has been received for the first time.
Because CANopen does not provide explicit confirmation of the start process, it is only possible to evaluate the
first arrival of the transmit PDOs. Until all the configured TxPDOs have arrived, the state of the node remains
set to 0x17 (expected TxPDO is missing).
After all configured nodes have been found, successfully parameterised and individually started, the FC510x
card again sends a global Start_Remote_Node telegram (with node ID=0).
8. SYNC
SYNC telegrams are first sent after the linked task with the highest priority has been started. Synchronous
TxPDOs are also therefore triggered until this task is running - this can also be a reason for the node state remaining at 0x17.
In many fieldbus systems the entire process image is continuously transferred - usually in a more or less cyclic
manner. CANopen is not limited to this communication principle, since the multi-master bus access protocol
allows CAN to offer other methods. Under CANopen the process data is not transferred in a master/slave procedure, but follows instead the producer-consumer model. In this model, a bus node transmits its data, as a
producer, on its own accord. This might, for example, be triggered by an event. All the other nodes listen, and
use the identifier to decide whether they are interested in this telegram, and handle it accordingly. These are
the consumers.
The process data in CANopen is divided into segments with a maximum of 8 bytes. These segments are known
as process data objects (PDOs). The PDOs each correspond to a CAN telegram, whose specific CAN identifier
is used to allocate them and to determine their priority. Receive (Rx) PDOs and transmit (Tx) PDOs are distinguished, the name being chosen from the point of view of a device: an input/output module sends its input data
with TxPDOs and receives its output data in the RxPDOs. This naming convention is retained in the Twin-
CAT System Manager.
Communication parameters
The PDOs can be given different communication parameters according to the requirements of the application.
Like all the CANopen parameters, these are also available in the device's object directory, and can be accessed by means of the service data objects. The parameters for the receive PDOs are at index 0x1400
(RxPDO1) onwards. There can be up to 512 RxPDOs (ranging up to index 0x15FF). In the same way, the entries for the transmit PDOs are located from index 0x1800 (TxPDO1) to 0x19FF (TxPDO512).
The Bus Couplers or Fieldbus Box modules make 16 RxPDO and 16 TxPDOs available for the exchange of
process data (although the figure for Economy and LowCost BK5110 and LC5100 couplers and the Compact
Box modules is 5 PDOs each, since these devices manage a lower quantity of process data).
The FC5x10x CANopen master card supports up to 192 transmit and 192 receive PDOs for each channel although this is restricted by the size of the DPRAM. Up to 192 TxPDOs and 192 RxPDOs can also be handled
in slave mode.
For each existing process data object there is an associated communication parameter object. The TwinCAT
System Manager automatically assigns the set parameters to the relevant object directory entries. These entries and their significance for the communication of process data are explained below.
PDO Identifier
The most important communication parameter in a PDO is the CAN identifier (also know as the communication
object identifier, or COB-ID). It is used to identify the data, and determines their priority for bus access. For
each CAN data telegram there may only be one sender node (producer), although all messages sent in the
CAN broadcast procedure can be received, as described, by any number of nodes (consumers). Thus a node
can make its input information available to a number of bus devices at the same time - even without transferring
them through a logical bus master. The identifier is located in subindex 1 of the communication parameter set.
It is coded as a 32-bit value in which the least significant 11 bits (bits 0...10) contain the identifier itself. The
data width of 32 bits also allows 29-bit identifiers in accordance with CAN 2.0B to be entered, although the
default identifiers always refer to the more usual 11-bit versions. Generally speaking, CANopen is economical
in its use of the available identifiers, so that the use of the 29-bit versions remains limited to unusual applications. The highest bit (bit 31) can be used to activate the process data object or to turn it off.
A complete identifier list is provided here.
PDO Linking
In the system of default identifiers, all the nodes (here: slaves) communicate with one central station (the master), since slave nodes do not listen by default to the transmit identifier of any other slave node.
If the consumer-producer model of CANopen PDOs is to be used for direct data exchange between nodes
(without a master), the distribution of identifiers must be appropriately adapted, so that the TxPDO identifier of
the producer agrees with the RxPDO identifier of the consumer. This procedure is known as PDO linking. It
permits, for example, easy construction of electronic drives in which several slave axes simultaneously listen to
the actual value in the master axis TxPDO.
PDO Communication Types: Outline
CANopen offers a number of possible ways to transmit process data (see also: Notes on PDO Parameterisation)
The ”event” is the alteration of an input value, the data being transmitted immediately after this change. The
event-driven flow can make optimal use of the bus bandwidth, since instead of the whole process image it is
only the changes in it that are transmitted. A short reaction time is achieved at the same time, since when an
input value changes it is not necessary to wait for the next interrogation from a master.
As from CANopen Version 4 it is possible to combine the event driven type of communication with a cyclic update. Even if an event has not just occurred, event driven TxPDOs are sent after the event timer has elapsed. If
an event does occur, the event timer is reset. For RxPDOs the event timer is used as a watchdog in order to
monitor the arrival of event driven PDOs . If a PDO does not arrive within a set period of time, the bus node
adopts the error state.
Polled
The PDOs can also be polled by data request telegrams (remote frames). In this way it is possible to get the
input process image of event-driven inputs onto the bus, even when they do not change, for instance through a
monitoring or diagnostic device brought into the network while it is running. The time behaviour of remote frame
and answer telegrams depends on what CAN controller is in use (Fig. 8). Components with full integrated message filtering ("FullCAN") usually answer a data request telegram immediately, transmitting data that is waiting
in the appropriate transmit buffer - it is the responsibility of the application to see that the data there is continuously updated. CAN controllers with simple message filtering ("BasicCAN") on the other hand pass the request
on to the application which can now compose the telegram with the latest data. This does take longer, but does
mean that the data is "fresh". Beckhoff use CAN controllers following the principle of Basic CAN.
Since this device behaviour is usually not transparent to the user, and because there are CAN controllers still in
use that do not support remote frames at all, polled communication can only with reservation be recommended
for operative running.
Synchronised
It is not only for drive applications that it is worthwhile to synchronise the determination of the input information
and the setting the outputs. For this purpose CANopen provides the SYNC object, a CAN telegram of high
priority but containing no user data, whose reception is used by the synchronised nodes as a trigger for reading
the inputs or for setting the outputs.
The PDO transmission type parameter specifies how the transmission of the PDO is triggered, or how received
PDOs are handled.
Transmission type Cyclical Acyclical Synchronous Asynchronous Only RTR
0 X X
1-240 X X
241-251 - reserved -
252 X X
253 X X
254, 255 X
The type of transmission is parameterised for RxPDOs in the objects at 0x1400ff, subindex 2, and for TxPDOs
in the objects at 0x1800ff, subindex 2.
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 transmitted cyclically: after every ”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 do not generally distinguish between transmission types 0...240: a PDO that has been
received is set to valid when the next SYNC is received. 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
46
switches, for example, its outputs into the fault state.
The FC510x PC cards support cyclic synchronous transmission types completely: transmitting the SYNC telegram is coupled to the linked task, so that new input data is available every time the task begins. The card will
recognise the absence of a synchronous PDO, and will report it to the application.
Only RTR
Transmission types 252 and 253 apply to process data objects that are transmitted exclusively on request by a
remote frame. 252 is synchronous: when the SYNC is received the process data is acquired. It is only transmitted on request. 253 is asynchronous. The data here is acquired continuously, and transmitted on request. This
type of transmission is not generally recommended, because fetching input data from some CAN controllers is
only partially supported. Because, furthermore, the CAN controllers sometimes answer remote frames automatically (without first requesting up-to-date input data), there are circumstances in which it is questionable
whether the polled data is up-to-date. Transmission types 252 and 253 are for this reason not supported by the
Beckhoff PC cards.
Asynchronous
The transmission types 254 + 255 are asynchronous, but may also be event-driven. In transmission type 254,
the event is specific to the manufacturer, 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.The
asynchronous transmission type can be coupled with the event timer, thus also providing input data when no
event has just occurred.
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 inhibit time
(transmit delay time) specifies the minimum length of time that must be allowed to elapse between the transmission of two of the same telegrams. If the inhibit time is used, the maximum bus loading can be determined,
so that the worst case latency can then be found.
Although the Beckhoff FC510x PC cards can parameterise the inhibit time on slave devices, they do not themselves support it. 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.
In the case of receive PDOs, the timer is used to set a watchdog interval for the PDO: the application is informed if no corresponding PDO has been received within the set period.
The FC510x can in this way monitor each individual PDO.
PDO mapping refers to mapping of the application objects (real time data) from the object directory to the process data objects. The CANopen device profile provide a default mapping for every device type, and this is appropriate for most applications. Thus the default mapping for digital I/O simply represents the inputs and outputs in their physical sequence in the transmit and receive process data objects.
The default PDOs for drives contain 2 bytes each of a control and status word and a set or actual value for the
relevant axis.
The current mapping can be read by means of corresponding entries in the object directory. These are known
as the mapping tables. The first location in the mapping table (sub-index 0) contains the number of mapped
objects that are listed after it. The tables are located in the object directory at index 0x1600ff for the RxPDOs
and at 0x1A00ff for the TxPDOs.
Digital and analog input/output modules: Read out the I/O number
The current number of digital and analog inputs and outputs can be determined or verified by reading out the
corresponding application objects in the object directory:
Parameter Address Object directory
Number of digital input bytes Index 0x6000, Subindex 0
Number of digital output bytes Index 0x6200, Subindex 0
As a rule, the default mapping of the process data objects already satisfies the requirements. For special types
of application the mapping can nevertheless be altered: the Beckhoff CANopen Bus Couplers, for instance,
thus support variable mapping, in which the application objects (input and output data) can be freely allocated
to the PDOs. The mapping tables must be configured for this: as from Version 4 of CANopen, only the following
procedure is permitted, and must be followed precisely:
1. First delete the PDO (set 0x1400ff, or 0x1800ff, subindex 1, bit 31 to "1")
2. Set subindex 0 in the mapping parameters (0x1600ff or 0x1A00ff) to "0"
3. Change mapping entries (0x1600ff or 0x1A00ff, SI 1..8)
4. Set subindex 0 in the mapping parameters to the valid value. The device then checks the entries for consistency.
5. Create PDO by entering the identifier (0x1400ff or 0x1800ff, subindex 1).
Dummy Mapping
A further feature of CANopen is the mapping of placeholders, or dummy entries. The data type entries stored in
the object directory, which do not themselves have data, are used as placeholders. If such entries are contained in the mapping table, the corresponding data from the device is not evaluated. In this way, for instance, a
number of drives can be supplied with new set values using a single CAN telegram, or outputs on a number of
nodes can be set simultaneously, even in event-driven mode.
Even though the majority of CANopen networks operate satisfactorily with the default settings, i.e. with the minimum of configuration effort, it is wise at least to check whether the existing bus loading is reasonable: 80%
bus loading may be acceptable for a network operating purely in cyclic synchronous modes, but for a network
with event-driven traffic this value would generally be too high, as there is hardly any bandwidth available for
additional events.
Consider the Requirements of the Application
The communication of the process data must be optimised in the light of application requirements which are
likely to be to some extent in conflict. These include
· Little work on parameterisation - useable default values are optimal
· Guaranteed reaction time for specific events
· Cycle time for regulation processes over the bus
· Safety reserves for bus malfunctions (enough bandwidth for the repetition of messages)
· Maximum baud rate - depends on the maximum bus length
49
· Desired communication paths - who is speaking with whom
The determining factor often turns out to be the available bus bandwidth (bus load).
Baud rate
We generally begin by choosing the highest baud rate that the bus will permit. It should be borne in mind that
serial bus systems are always more sensitive to interference at higher baud rates, so the better rule is "just as
fast as needed". 1000 kbit/s are not usually necessary, and only to be unreservedly recommended on networks
within a control cabinet where there is no electrical isolation between the bus nodes. Experience also tends to
show that estimates of the length of bus cable laid are often over-optimistic - the length actually laid tends to be
longer.
Determine the Communication Type
Once the baud rate has been chosen it is appropriate to specify the PDO communication type(s). These have
different advantages and disadvantages:
· Cyclic synchronous communication provides an accurately predictable bus loading, and therefore a de-
fined time behaviour - you could say that the standard case is the worst case. It is easy to configure:
The SYNC rate parameter sets the bus loading globally. The process images are synchronised: Inputs
are read at the same time, output data is set valid simultaneously, although the quality of the synchronisation depends on the implementation. The Beckhoff FC510x PC cards are capable of synchronising
the CANopen bus system with the cycles of the application program (PLC or NC).
The guaranteed reaction time under cyclic synchronous communication is always at least as long as
the cycle time, and the bus bandwidth is not exploited optimally, since "old" data, i.e. data that has not
changed, is continuously transmitted. It is however possible to optimise the network through the selection of different SYNC multiples (transmission types 1...240), so that data that changes slowly is
transmitted less often than, for instance, time-critical inputs. It must, however, be borne in mind that
input states that last for a time that is shorter than the cycle time will not necessarily be communicated.
If it is necessary for such conditions to be registered, the associated PDOs for asynchronous communication should be provided.
· Event-driven asynchronous communication is optimal from the point of view of reaction time and the
exploitation of bus bandwidth - it can be described as "pure CAN". Your choice must, however, also
take account of the fact that it is not impossible for a large number of events to occur simultaneously,
leading to corresponding delays before a PDO with a relatively low priority can be sent. Proper network planning therefore necessitates a worst-case analysis. Through the use of, for instance inhibit
time it is also necessary to prevent a constantly changing input with a high PDO priority from blocking
the bus (technically known as a "babbling idiot"). It is for this reason that event driving is switched off
by default in the device profile of analog inputs, and must be turned on specifically. Time windows for
50
the transmit PDOs can be set using progress timers: the telegram is not sent again before the inhibit
time has elapsed, and not later than the time required for the progress timer to complete.
· The communication type is parameterised by means of the transmission type.
It is also possible to combine the two PDO principles. It can, for instance, be helpful to exchange the set and
actual values of an axis controller synchronously, while limit switches, or motor temperatures with limit values
are monitored with event-driven PDOs. This combines the advantages of the two principles: synchronicity for
the axis communication and short reaction times for limit switches. In spite of being event-driven, the distributed
limit value monitoring avoids a constant addition to the bus load from the analog temperature value.
In this example it can also be of value to deliberately manipulate the identifier allocation, in order to optimise
bus access by means of priority allocation: the highest priority is given to the PDO with the limit switch data,
and the lowest to that with the temperature values.
Optimisation of bus access latency time through modification of the identifier allocation is not, however, normally required. On the other hand the identifiers must be altered if "masterless" communication is to be made
possible (PDO linking). In this example it would be possible for one RxPDO for each axis to be allocated the
same identifier as the limit switch TxPDO, so that alterations of the input value can be received without delay.
Determining the Bus Loading
It is always worth determining the bus loading. But what bus loading values are "permitted", or indeed sensible?
It is first necessary to distinguish a short burst of telegrams in which a number of CAN messages follow one
another immediately - a temporary 100% bus loading. This is only a problem if the sequence of receive interrupts that it caused at the CAN nodes can not be handled. This would constitute a data overflow (or "CAN
queue overrun"). This can occur at very high baud rates (> 500 kbit/s) at nodes with software telegram filtering
and relatively slow or heavily loaded microcontrollers if, for instance, a series of remote frames (which do not
contain data bytes, and are therefore very short) follow each other closely on the bus (at 1 Mbit/s this can generate an interrupt every 40 µs; for example, an NMT master might transmit all its guarding requests in an unbroken sequence). This can be avoided through skilled implementation, and the user should be able to assume
that the device suppliers have taken the necessary trouble. A burst condition is entirely normal immediately
after the SYNC telegram, for instance: triggered by the SYNC, all the nodes that are operating synchronously
try to send their data at almost the same time. A large number of arbitration processes take place, and the telegrams are sorted in order of priority for transmission on the bus. This is not usually critical, since these telegrams do contain some data bytes, and the telegrams trigger a sequence of receive interrupts at the CAN nodes which is indeed rapid, but is nevertheless manageable.
Bus loading most often refers to the value averaged over several primary cycles, that is the mean value over
100-500 ms. CAN, and therefore CANopen, is indeed capable of managing a bus loading of close to 100% over
long periods, but this implies that no bandwidth is available for any repetitions that may be necessitated by interference, for asynchronous error messages, parameterisation and so on. Clearly, the dominant type of communication will have a large influence on the appropriate level of bus loading: a network with entirely cyclic synchronous operation is always in any case near to the "worst case" state, and can therefore be operated with
values in the 70-80% range. The figure is very hard to state for an entirely event-driven network: an estimate
must be made of how many events additional to the current state of the system might occur, and of how long
the resulting burst might last - in other words, for how long the lowest priority message will be delayed. If this
value is acceptable to the application, then the current bus loading is acceptable. As a rule of thumb it can usually be assumed that an event-driven network running with a base loading of 30-40% has enough reserve for
worst-case scenarios, but this assumption does not obviate the need for a careful analysis if delays could have
critical results for the plant.
The Beckhoff FC510x PC cards indicate the bus loading via the System Manager. This variable can also be
processed in the PLC, or can be displayed in the visualisation system.
The amount data in the process data objects is of course as relevant as the communication parameters: the
PDO mapping.
The parameters listed in the object directory are read and written by means of service data objects. These
SDOs are multiplexed domains, i.e. structures of any size that have a multiplexer (address). The multiplexer
consists of a 16-bit index and an 8-bit sub-index that address the corresponding entries in the object directory.
51
SDO protocol: access to the object directory
The CANopen bus couplers are servers for the SDO, which means that at the request of a client (e.g. of the
IPC or the PLC) they make data available (upload), or they receive data from the client (download). This involves a handshake between the client and the server.
When the size of the parameter to be transferred is not more than 4 bytes, a single handshake is sufficient (one
telegram pair): For a download, the client sends the data together with its index and sub-index, and the server
confirms reception. For an upload, the client requests the data by transmitting the index and sub-index of the
desired parameter, and the server sends the parameter (including index and sub-index) in its answer telegram.
The same pair of identifiers is used for both upload and download. The telegrams, which are always 8 bytes
long, encode the various services in the first data byte. All parameters with the exception of objects 1008h,
1009h and 100Ah (device name, hardware and software versions) are only at most 4 bytes long, so this description is restricted to transmission in expedited transfer.
Protocol
The structure of the SDO telegrams is described below.
It is optionally possible to give the number of valid parameter data bytes in the first CAN data byte
Number of parameter bytes 1 2 3 4
First CAN data byte 0x2F 0x2B 0x27 0x23
This is, however, not generally necessary, since only the less significant data bytes up to the length of the object directory entry that is to be written are evaluated. A download of data up to 4 bytes in length can therefore
always be achieved in Beckhoff bus nodes with 22h in the first CAN data byte.
CANopen SDO (Service Data Object) communication is used to read or write any parameters in the CANopen
bus node's object directory. The FC5101CANopen PCI card uses SDO communication to configure the communication parameters when starting up. Two types of application-specific SDO communication are additionally
possible:
1. Downloading Application-Specific Parameters when
Starting Up
The appropriate parameters are to be entered here in the System Manager for the corresponding node under
"SDO". The objects that result from the configuration under CAN node appear in square brackets. Any desired
number of object directory entries can then be inserted.
55
The card expects a positive acknowledgement of the parameter download from the relevant bus device. If it
was not possible to write a parameter (the bus device has aborted the SDO) the card then attempts to read the
corresponding value back and to compare it with the value that was to be written. This is because it could, for
instance, be a read-only value, and therefore already correctly configured within the bus device. If they agree
with one another, the card moves onto the next parameter entry.
2. Upload and Download at Runtime via ADS
It is possible to perform SDO accesses to the bus devices' object directories using Beckhoff's ADS communication when the system is running. This is also possible from the PLC, from the NC, from the OPC server, from
ActiveX controls or from any other ADS device.
The whole SDO protocol is handled by the card. Using the ADS Write or ADS Read functions the parameters
are transferred to the card, and the data is transferred (write) or fetched (read). The "IDXGRP" parameter here
corresponds to the 16 bit index in the CANopen object directory, while "IDXOFFS" corresponds to the 8 bit subindex in the CANopen object directory. Detailed information about the ADS function blocks may be found in the
TwinCAT documentation (TwinCAT Information System).
The ADS function block parameters are represented as follows in the SDO parameters:
NETID The NetID is a string, 23 bytes in length, and is formed by default from the IP address of
the computer with an additional two bytes. It addresses the FC5101 card and can be found
under "ADS" in the System Manager.
PORT Contains the ADS device's port number - this is the port number of the CANopen bus
device that is to be addressed.
IDXGRP
IDXOFFS
LEN The length of the parameter that is to be read or written, in bytes.
DESTADDR
(only ADSREAD)
SRCADDR (only
ADSWRITE)
READ The ADS command is triggered by a rising edge at this input.
TIMEOUT States the time before the function is cancelled.
BUSY This output remains TRUE until the block has executed a command, but at the longest for
ERR This output is switched to TRUE if an error occurs during the execution of the command.
ERRID Contains the command-specific error code of the most recently executed command. Is
Corresponds to the 16 bit index in the CANopen object directory.
Corresponds to the 8 bit sub-index in the CANopen object directory.
Contains the address of the buffer which is to receive the data that has been read. The
programmer is himself responsible for dimensioning the buffer to a size that can accept
‘LEN’ bytes. The buffer can be a single variable, an array or a structure, whose address
can be found with the ADR operator.
Contains the address of the buffer from which the data to be written is to be fetched. The
programmer is himself responsible for dimensioning the buffer to such a size that ‘LEN’
bytes can be taken from it. The buffer can be a single variable, an array or a structure,
whose address can be found with the ADR operator.
the duration supplied to the ‘Timeout’ input. While Busy = TRUE, no new command will be
accepted at the inputs. Please note that it is not the execution of the service but its acceptance whose time is monitored.
reset to 0 by the execution of an instruction at the inputs.
The ERRID contains the general ADS ERROR CODES in the low word and the SDO-specific error codes in the
high word:
Bits 0...3 contain the SDO error class
Bits 4..7 contain the SDO error code
Bits 8...14 contain the additional code for the SDO abort
Bit 15 is always 1
Example: SDO Read via ADS
In the following example program (structured text) for the use of ADS services for SDO communication, object
0x1000, sub-index 0, from the node with port number 0x1001 is read. The DeviceType is CANopen. This is
coded as UnSigned32, and is therefore 4 bytes long.
IF SDO_READ.ReadDataAvailable THEN
ReadStart := FALSE;
ReadError := SDO_READ.Error;
ReadData := SDO_READ.ReadData;
END_IF
The SDO_READ function block that has been called in turn calls the ADSREAD function a number of times. It
looks like this (starting with the variable declaration):
FUNCTION_BLOCK SDO_READ
VAR_INPUT
ADSNetID:STRING(23); (* The AMSNetID addresses the FC5101 card. Can be empty if
only one local single channel card is present*)
PortNr:WORD; (* This Port No. addresses the CANopen Node (see System
Manager) *)
CO_Index:DWORD; (* This is the Index of the CANopen Object Dictionary Entry*)
CO_SubIndex:DWORD; (* This is the Sub-Index of the CANopen Object Dictionary
Entry*)
DataLength:DWORD; (* This is the Length of the CANopen Object Dictionary Entry*)
StartReading:BOOL; (* only reset to FALSE after ReadDataAvailable=TRUE*)
END_VAR
VAR_OUTPUT
ReadData:ARRAY[0..255] OF BYTE;
ReadDataAvailable:BOOL;
Error:DWORD;
END_VAR
VAR
state:BYTE := 0;
ADSREAD:ADSREAD;
END_VAR
CASE state OF
0:
IF StartReading THEN
ReadDataAvailable := FALSE;
Error := 0;
ADSRead(
NETID:= ADSNetID,
PORT:= PortNr,
IDXGRP:= CO_Index,
IDXOFFS:= CO_SubIndex,
LEN:= DataLength,
DESTADDR:= ADR(ReadData),
READ:= TRUE,
TMOUT := T#1s
);
IF ADSRead.err THEN
state := 2;
ReadDataAvailable := TRUE;
Error := ADSRead.ErrId;
ELSE
state := 1;
END_IF
ELSE
ADSRead(
NETID:= ADSNetID,
PORT:= PortNr,
IDXGRP:= CO_Index,
IDXOFFS:= CO_SubIndex,
LEN:= DataLength,
DESTADDR:= ADR(ReadData),
READ:= FALSE,
TMOUT := T#1s
);
END_IF
1:
ADSRead(READ:= FALSE);
IF ADSRead.err THEN
state := 2;
ReadDataAvailable := TRUE;
Error := ADSRead.ErrId;
ELSE
IF NOT ADSRead.busy THEN
state := 2;
ReadDataAvailable := TRUE;
END_IF
END_IF
2:
ADSRead(READ:= FALSE);
state := 0;
END_CASE
Example: SDO Write via ADS
In the following example program (structured text) for the use of ADS services for SDO communication, object
0x6200, sub-index 3, from the node with port number 0x1001 is written. It concerns digital outputs to an I/O
node.
The SDO_WRITE function block that has been called in turn calls the ADSWRITE function a number of times. It
looks like this (starting with the variable declaration):
FUNCTION_BLOCK SDO_WRITE
VAR_INPUT
ADSNetID:STRING(23); (* The AMSNetID addresses the FC5101 card. Can be empty
if only one local single channel card is present*)
PortNr:WORD; (* The Port No. addresses the CANopen Node (see System
Manager) *)
CO_Index:DWORD; (* This is the Index of the CANopen Object Dictionary
Entry*)
CO_SubIndex:DWORD; (* This is the Sub-Index of the CANopen Object Dictionary
Entry*)
DataLength:DWORD; (* This is the Length of the CANopen Object Dictionary
Entry*)
StartWriting:BOOL; (* only reset to FALSE after WriteDataFinished=TRUE*)
WriteData:ARRAY[0..255] OF BYTE; (*This array contains the data to be written to
the CANopen Object Dictionary*)
END_VAR
VAR_OUTPUT
WriteDataFinished:BOOL;
Error:DWORD;
END_VAR
VAR
state:BYTE := 0;
ADSWRITE:ADSWRITE;
END_VAR
The following baud rates and entries in the bit-timing register are supported by the CANopen devices:
Baud rate [kbaud] BTR0 BTR1 Sampling Point
1000 0x00 0x14 75%
800 0x00 0x16 80%
500 0x00 0x1C 87%
250 0x01 0x1C 87%
125 0x03 0x1C 87%
100 0x04 0x1C 87%
50 0x09 0x1C 87%
20 0x18 0x1C 87%
10 0x31 0x1C 87%
The bit-timing register settings given (BTR0, BTR1) apply, for example, for the Philips 82C200, SJA1000, Intel
80C527, Siemens 80C167 and other CAN controllers. They are optimised for the maximum bus length.
CANopen provides default identifiers for the most important communication objects, and these are derived from
the 7-bit node address (the node ID) and a 4-bit function code in accordance with the following scheme:
For broadcast objects the node ID is set to ”0”. This gives rise to the following default identifiers:
* For historical reasons, the Beckhoff default mapping applies to PDOs 3 and 4 in Beckhoff I/O devices. In most
configurations, PDOs 3 and 4 contain data related to analog inputs and outputs, but there can also be "excess"
data from digital I/Os, or data from special terminals. Details may be found in the Bus Coupler documentation.
Up until version 3 of the CANopen specification, default identifiers were assigned to 2 PDOs at a time. The
Beckhoff Bus Couplers correspond to this issue of the specification. After version 4, default identifiers are provided for up to 4 PDOs.
The red ERROR LED and the green RUN help to quickly diagnose the status of the card:
Error LED
(red)
off off TwinCAT has been stopped
off on All configured bus nodes are error free (Box State=0), TwinCAT Task or
off blinking with
blinking with
2Hz
blinking with
2 Hz
on off TwinCAT is running, CAN Controller is "Bus OFF". Physical CAN problem.
blinking with
20Hz
blinking with
20Hz
Run LED
(green)
2 Hz
on At least one box state is unequal zero (e.g. node not found, wrong configura-
off At least one box state is unequal zero (e.g. node not found, wrong configura-
blinking with
20Hz
off card is in STOP mode
Description
Process is running.
The Task, whose process data is linked to the card, is not running.
All configured bus nodes have been found and are error free (Box State=0)
tion, node in error), TwinCAT Task is running
tion, node in error), TwinCAT Task is not running
Possible reasons: e.g. terminating resistor missing, bus too long, wrong baud
rate, node address configured twice, short circuit, wiring error.
Restart is necessary
The CANopen fieldbus card FC510x has a comprehensive range of diagnostic options for connected network
nodes.
For each CANopen fieldbus node there is a node state input variable, which signals the status of the current
slave during the runtime and can be linked, for example with the PLC.
Node State (Box-State)
63
Node
State
0 = 0x00 No error Bus node is operational, communication is running correctly
1 = 0x01 Node deactivated The node is subject to one or more of the following errors:
2 = 0x02 Node not found Node not found: no answer to SDO read access to object 0x1000 at the
4 = 0x04 SDO syntax error
5 = 0x05
Meaning Explanation
- guarding/heartbeat error (failure, toggle bit error, node has changed state)
- expected TxPDO has not been received
- TxPDO length shorter than expected
Node has been stopped, because "Manual restart" following a node failure
has been selected.
expected node address. Check the following at the node: what node address
is set, and what baud rate. Check network (terminating resistors, connectors,
bus length, crossed wiring etc.)
Error during SDO write access: SDO abort by node. See the "Diag" tab for
at StartUp
details.
or: the length of an object read by SDO does not agree with the expected
length.
match at StartUp and/or additional info do not agree with object 0x1000). Can also occur if the
progress
FC510x Bus-OFF CAN chip has entered the "Bus-OFF" state: transmit error counter is running
Pre-Operational Node has gone pre-operational (on its own account).
Severe bus fault General firmware error.
Guarding: toggle
error
TxPDO too short Received TxPDO shorter than expected.
Expected TxPDO
is missing
Node is Operational but not all
TxPDOs were
received
value to be written (e.g. PDO COB-ID) is read back due to refusal of write
access, and does not agree. See the "Diag" tab for details.
Node was found and has been started.
Guarding error: Toggle bit has not changed.
TxPDO has not been received within the expected time interval:
- sync interval with synchronous TxPDOs,
- event timer with event-driven PDOs).
Node has been started, but at least one TxPDO has not yet been received
from the node. Possible causes (examples):
- The node only sends event-driven PDOs after the first event (this is not the
intention of the CANopen specification, but is quite usual).
- Too many TxPDOs have been configured.
- A TxPDO is present at the node, but no process data has been mapped.
- The TxPDO has transmission type 1...120 (synchronous), but SYNC has
not yet been sent because the associated task has not been started.
DiagFlag:
Shows whether the box diagnostic information has changed.
Reading the Diagnostic Data via ADS
CANopen emergencies and other diagnostic data can be read out via ADS read (new data present as soon as
you see the DiagFlag). You need to enter the FC510x ADS net ID. Other ADS parameters:
If more than 26 bytes of diagnostic data have been read out the emergency memory is reset. The DiagFlag is
reset as soon as at least 108 bytes have been read starting from offset 0. Alternatively, the flag is reset after
each of read access, if IndexGroup 0xF181 (instead of 0xF180) is used for the read.
The diagnostic data have the following definitions:
Offset 0,1: Bit 1: Boot up message not received or incorrect
The FC510x CANopen fieldbus card makes extensive diagnostic facilities available for the input variables.
cycleCounter
Is incremented after each firmware cycle. The PLC task can use this to establish whether new input data is
being handled - if the cycleCounter has not been incremented since the last time the PLC task was called, the
task time is too short.
error
The number of nodes whose state is not zero.
actualCycleTime
Current cycle time of the card firmware in 4/25 µs. Depends on the quantity of data and the bus loading.
DiagFlag
Is set to 1 if new diagnostic data (such as emergency) has been placed in the card's memory.
GlobalState
Reserved for internal evaluations.
LastAdsError
Last ADS error to have occurred. See also ADS Error Codes.
CycleFailedCounter
This counter is incremented if it was not possible to complete the card's firmware cycle before the highest priority linked task accessed the DPRAM again. In this case, the task does not receive any new input data, nor are
new synchronous PDOs issued in the previous cycle. Because the CycleFailedCounter is not incremented until
after the corresponding task start, it cannot be used for diagnosis within that task. It is recommended that the
cycleCounter be used here, as it is not incremented in these cases.
The minimum and maximum bus loading are also displayed on the "General Diag" tab in addition to the current
bus loading, as are the cycle time and the failed cycle counter. In the example illustrated above, about 5000
CAN frames are handled each second, and a corresponding number of PDOs are sent. Because the firmware
sends all the pending PDOs in each cycle, the firmware cycle time in this case primarily depends on the time
required to transmit the PDOs.
The CANopen FC510x fieldbus card stores arriving emergency messages in the diagnostic area starting at
offset 26 (see below). Up to 10 emergencies can be stored for each bus node. The oldest message is replaced
if more emergencies than this arrive.
New diagnostic data (emergencies or other diagnostic data) is present as soon as the DiagFlag is set.
CANopen emergencies and other diagnostic data can be read via ADS. You need to enter the FC510x ADS net
ID. Other ADS parameters:
If more than 26 bytes of diagnostic data have been read out the emergency memory is reset. The DiagFlag is
reset as soon as at least 108 bytes have been read starting from offset 0. Alternatively, the flag is reset after
each of read access, if IndexGroup 0xF181 (instead of 0xF180) is used for the read.
A description of the diagnostic data at offset 0...23 is to be found in the corresponding Section. The diagnostic
area starting at offset 24 is organised as follows:
Offset 24-25: Number of consecutive emergencies
Offset 26 - n: Emergencies (8 bytes each)
The significance of the emergency data is to be found in the technical documentation for the particular CANopen device.
One sign of errors in the CAN wiring, the address assignment or the setting of the baud rate is an increased
number of error frames: the diagnostic LEDs then show Warning Limit exceeded or Bus-off state entered.
Warning limit exceeded, passive error or bus-off state are indicated first of all at those nodes that
have detected the most errors. These nodes are not necessarily the cause for the occurrence of
Warning
Node ID / Setting the Baud Rate
Care must be taken to ensure that node addresses are not assigned twice: there may only be one sender for
each CAN data telegram.
Test 1:
Check node addresses. If the CAN communication functions at least some of the time, and if all the devices
support the boot up message, then the address assignment can also be examined by recording the boot up
messages after the devices are switched on. This will not, however, recognise node addresses that have been
swapped.
Test 2:
Check that the same baud rate has been set everywhere. For special devices, if the bit timing parameters are
accessible, do they agree with the CANopen definitions (sampling time, SJW, oscillator).
error frames!
If, for instance, one node contributes unusually heavily to the bus traffic (perhaps because it is the
only one with analog inputs, the data for which triggers event-driven PDOs at a high rate), then
the probability of its telegrams being damaged increases. Its error counter will, correspondingly,
be the first to reach a critical level.
73
Testing the CAN wiring
Do not carry out these tests when the network is active - communication should not take place during the tests.
The following tests should be carried out in the stated sequence, because some of the tests assume that the
previous test was successful. Not all the tests are generally necessary.
Network terminator and signal leads
The nodes should be switched off or the CAN cable unplugged for this test, because the results of the measurements can otherwise be distorted by the active CAN transceiver.
Determine the resistance between CAN high and CAN low - at each device, if necessary.
If the measured value is greater than 65 Ohms, it indicates the absence of a terminating resistor or a break in a
signal lead. If the measured value is less than 50 Ohms, look for a short circuit between the CAN lines, more
than the correct number of terminating resistors, or faulty transceivers.
Test 4:
Check for a short circuit between the CAN ground and the signal leads, or between the screen and signal
leads.
Test 5:
Remove the earth connection from the CAN ground and screen. Check for a short circuit between the CAN
ground and screen.
Topology
The possible cable length in CAN networks depends heavily on the selected baud rate. CAN will tolerate short
drop lines - although this again depends on the baud rate. The maximum permitted length of drop lines should
not be exceeded. The length of cable that has been installed is often underestimated - estimates can even be a
factor of 10 less than the actual length. The following test is therefore recommended:
Test 6:
Measure the lengths of the drop lines and the total bus lengths (do not just make rough estimates!) and compare them with the topology rules for the relevant baud rate.
Screening and earthing
The power supply and the screen should be carefully earthed at the power supply unit, once only and with low
resistance. At all connecting points, branches and so forth the screen of the CAN cable (and possibly the CAN
GND) must also be connected, as well as the signal leads. In the Beckhoff IP20 Bus Couplers, the screen is
grounded for high frequencies via an R/C element.
Test 7:
Use a DC ammeter (16 amp max.) to measure the current between the power supply ground and the screen at
the end of the network most remote from the power supply unit. An equalisation current should be present. If
there is no current, then either the screen is not connected all the way through, or the power supply unit is not
properly earthed. If the power supply unit is somewhere in the middle of the network, the measurement should
be performed at both ends. When appropriate, this test can also be carried out at the ends of the drop lines.
Test 8:
Interrupt the screen at a number of locations and measure the connection current. If current is flowing, the
screen is earthed at more than one place, creating a ground loop.
Potential differences
The screen must be connected all the way through for this test, and must not be carrying any current - this has
previously been tested.
Test 9:
Measure and record the voltage between the screen and the power supply ground at each node. The maximum
potential difference between any two devices should be less than 5 volts.
Detect and localise faults
The "low-tech approach" usually works best: disconnect parts of the network, and observe when the fault disappears.
However, this does not work well for problems such as excessive potential differences, ground loops, EMC or
signal distortion, since the reduction in the size of the network often solves the problem without the "missing"
piece being the cause. The bus loading also changes as the network is reduced in size, which can mean that
external interference "hits" CAN telegrams less often.
Diagnosis with an oscilloscope is not usually successful: even when they are in good condition, CAN signals
can look really chaotic. It may be possible to trigger on error frames using a storage oscilloscope - this type of
diagnosis, however, is only possible for expert technicians.
Protocol problems
In rare cases, protocol problems (such as faulty or incomplete CANopen implementation, unfavourable timing at
boot up etc.) can be the cause of faults. In this case it is necessary to trace the bus traffic for evaluation by a
CANopen experts - the Beckhoff support team can help here.
A free channel on a Beckhoff FC5102 CANopen PCI card is appropriate for such a trace - Beckhoff make the
necessary trace software available on the internet. Alternatively, it is of course possible to use a normal commercial CAN analysis tool.
Protocol problems can be avoided if devices that have not been conformance tested are not used. The official
CANopen Conformance Test (and the appropriate certificate) can be obtained from the CAN in Automation
association.
As from firmware version 1.00 and TwinCAT 2.8 (Build 738), the FC5101 and FC5102 can be used as CANopen monitors instead of masters.
For instance, the second channel of the FC5102 can be used for this purpose, while the first channel continues
to function as a CANopen master, or vice versa. In such a case, both channels must be connected to the same
CAN network. (Data exchange within the card is not provided, since this cannot take place without interactions.)
The telegrams recorded by the FC510x are temporarily stored in a ring buffer by the task linked with the
FC510x; the stored telegrams can then be accessed by ADS. There is a CANopen monitor program (CANMON) offering filter and trigger facilities available as freeware from Beckhoff. The user's own applications may
also access the monitor data using the ADS interface described below.
Inserting the FC510x as a CANopen Monitor
In the Insert device context menu: insert CANopen monitor
After this it is necessary to select the appropriate channel (PCI memory address).
Linking the FC510x with a task
The monitor data is accessed at the start of a task from real-time TwinCAT. For this purpose it is necessary to
create an additional task in the system manager, containing at least one UINT16 input variable that is to be
linked to one of the variables in the FC510x.
The only purpose of this linking is to make it possible for the real-time system to access the FC510x in the cycle
time of the task. The cycle time of the additional task is to be set as follows, depending on the baud rate:
Baud rate Cycle time of the additional task
1 MBaud <= 10 ms
800 kbaud <= 12 ms
500 kbaud <= 20 ms
250 kbaud <= 40 ms
125 kbaud <= 80 ms
100 kbaud <= 100 ms
50 kbaud <= 200 ms
20 kbaud <= 500 ms
10 kbaud <= 1000 ms
The Autostart checkbox is also to be set (see illustration above).
PCI Slot/Irq: Indicates in which logical PCI slot the card was found.
Search...: Searches for all connected FC510x channels. Select those desired. In the case of an FC5102 both
channels A and B appear. These behave in logical terms like two FC5101 cards.
Hardware Configuration...: The hardware version number of the FC510x can be displayed here.
Firmware: Shows the current firmware version of the FC510x.
Firmware Update...: Update the FC510x card firmware version here.
Baudrate: The CAN baud rate is set here.
Ring buffer: The size of the ring buffer is set here. The recording time for the ring buffer size that has been set
when the bus is fully loaded is also given.
Autostart: If the Autostart checkbox is ticked, the monitor recording can be started when TwinCAT starts. Otherwise the monitor software must be used to start it via ADS.
Monitor Software
The monitor software fetches the trace data from the FC510x card and places it as a file in the desired mass
storage. Only the DLL (TcRouterHelper.dll) is required in addition to the monitor programme itself (CANMonitor.exe). This must be placed in the same directory as the monitor program.
After starting the monitor program, the device ID of the FC5101 channel that will be used for the monitoring
must be selected.
Device-ID: The ID that the system manager has assigned to the FC510x monitor channel must be entered
here:
Storing: The size of the ring buffer memory for the screen display (Display) and for that data output (File) can
be set here.
Display: A filter for the display output can be specified here.
Trigger: Trigger conditions that will stop the measurement can be specified here. It is possible, for instance, for
a specific otherwise unused output to be set when an error occurs, and to trigger off this bit in the output module's RxPDO.
Post Trigger: This can be used to specify how many telegrams are still to be recorded after the trigger condition has occurred. The number of telegrams recorded prior to occurrence of the trigger condition is only restricted by the specified buffer size.
Trigger and display filters function in such a way that only those bits for which the mask is set to 1
are considered when selecting the identifier (ID) or the data bytes (Data). These bits are then checked for conformity with the values specified in Value. The default setting (mask ID = 0x7FF and
mask data = 0x00) is relevant if the identifier (ID) specified in Value is to be recognised, regardless
of the data. If an identifier (ID) larger than 0x7FF (e.g. 0x800, default) is entered, the filter or trigger
is disabled.
Example:
The recording is to be stopped after 250 telegrams, after bit 0 in the second data byte of a telegram with identi-
80
fier 0x210 equal to 1 has been found. The following entries are to be made to achieve this:
TwinCAT must be started, and a variable in a cyclic task (such as the Autostart task) must be linked with the
dummy variable of the FC510x in monitoring mode. The recording can now be started by clicking the green
traffic light symbol.
If the start-up procedure associated with another CANopen channel in the system is to be recorded, then the
"Autostart" checkbox on the System Manager's FC monitor tab is to be selected. The card can then buffer up to
25,000 CAN messages. It is then only necessary to start the recording via monitor software before the CAN
card's buffer overflows.
Stopping the Recording
Click the red traffic light symbol to stop the recording. The following dialog box opens:
Two trace files are created automatically. One is an ASCII file with the ending *.mon, readable by any text editor. A file with the ending *.ASC is also created: this can be read for further processing by the CANalyzer® tool
from Vector Informatik.
Trace example:
The beginning of a CANopen boot up with two nodes (node ID 1 and node ID 50) is illustrated.
The ADS interface for the FC510x monitor is described below.
Starting the Recording
Monitor recording is started with the following ADS write command:
NET-ID: PC AMS net ID.
PORT: 300
81
IDXGRP: IndexGroup is 0x5000 + Id (on the "General" tab for the FC510x monitor) of the FC510x monitor
IDXOFFS: IndexOffset is 0xFFFF1000
LEN: Data length is 2
DATA: A word with the value 1 is to be transmitted
Stopping the Recording
Monitor recording is stopped with the following ADS write command:
NET-ID: PC AMS net ID.
PORT: 300
IDXGRP: IndexGroup is 0x5000 + Id (on the General tab for the FC510x monitor) of the FC510x monitor
IDXOFFS: IndexOffset is 0xFFFF1000
LEN: Data length is 2
DATA: A word with the value 0 is to be transmitted
Structure of the Ring Buffer
The ring buffer in which the recorded telegrams are stored is divided into 4 kbyte pages. Each page has the
following structure:
Offset Description
0x0000 - 0x0FEF Recorded telegrams (see below)
0x0FF0 - 0x0FF3 reserved
0x0FF4 - 0x0FF7 Length of the data actually read (only in the first read page)
0x0FF8 - 0x0FF9 1: Further pages are stored, 0: no further pages are stored
0x0FFA - 0x0FFB reserved
0x0FFC - 0x0FFD End of the telegrams recorded on this page (points to the first memory location following
the last telegram)
0x0FFE - 0x0FFF Page number
Reading the Recorded Telegrams
The monitor telegrams that have been recorded can be read with the following ADS read command:
82
NET-ID: PC AMS net ID.
PORT: 300
IDXGRP: IndexGroup is 0x5000 + Id (on the General tab for the FC510x monitor) of the FC510x monitor
IDXOFFS: IndexOffset is 0xFFFF0000 - 0xFFFF1FFF (bits 0-11: number of the first page to be read, bit 12 = 0:
only read full pages, bit 12 = 1: also read the last, incomplete, page if appropriate)
LEN: 0x1000 (1 page), 0x2000 (2 pages), 0x3000 (3 pages) or 0x4000 (4 pages) are permitted as the data
length
Controller Area Network. A serial bus system standardised in ISO 11898. The technology on which CANopen is
based.
CiA
CAN in Automation e.V.. An international association of manufacturers and users based in Erlangen, Germany.
COB
Communication Object. A CAN telegram with up to 8 data bytes.
COB-ID
Communication Object Identifier. Telegram address (not to be confused with the node address). CANopen uses
the 11-bit identifier according to CAN 2.0A.
NMT
Network Management. One of the service primitives of the CANopen specification. Network management is
used to initialise the network and to monitor nodes.
PDO
Process Data Object. A CAN telegram for the transfer of process data (e.g. I/O data).
RxPDO
Receive PDO. PDOs are always identified from the point of view of the device under consideration. Thus a
TxPDO with input data from an I/O module becomes an RxPDO from the controller's point of view.
SDO
Service Data Object. A CAN telegram with a protocol for communication with data in the object directory (typically parameter data).
TxPDO
Transmit PDO (named from the point of view of the CAN node).
Beckhoff and their partners around the world offer comprehensive support and service, making available fast
and competent assistance with all questions related to Beckhoff products and system solutions.
Beckhoff Support
Support offers you comprehensive technical assistance, helping you no only with the application of individual
Beckhoff products, but also with other, wide-ranging services:
· world-wide support
· design, programming and commissioning of complex automation systems
· and extensive training program for Beckhoff system components
Hotline: +49(0)5246/963-157
Fax: +49(0)5246/963-199
e-mail: support@beckhoff.com
95
Beckhoff Service
The Beckhoff Service Center supports you in all matters of after-sales service:
· on-site service
· repair service
· spare parts service
· hotline service
Hotline: +49(0)5246/963-460
Fax: +49(0)5246/963-479
e-mail: service@beckhoff.com
You will find further support and service addresses on our Internet pages under http://www.beckhoff.com. You
will also find documentation for Beckhoff components there.
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.