FC510x - PCI cards for CANopen
Home


Foreword

Foreword
Foreword
Additional information
•
Notes on the documentation
•
Safety instructions
•
Documentation Issue Status


Notes on the documentation

Foreword [image] Notes on the documentation
Notes on the documentation
Intended audience
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 documentation and the following notes and explanations are followed when installing and commissioning these components.
It is the duty of the technical personnel to use the documentation published at the respective time of each installation and commissioning.
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.
Disclaimer
The documentation has been prepared with care. The products described are, however, constantly under development.
We reserve the right to revise and change the documentation at any time and without prior announcement.
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.
Trademarks
Beckhoff®, TwinCAT®, EtherCAT®, EtherCAT P®, Safety over EtherCAT®, TwinSAFE®, XFC® and XTS® are registered trademarks of and licensed by Beckhoff Automation GmbH.
Other designations used in this publication may be trademarks whose use by third parties for their own purposes could violate the rights of the owners.
Patent Pending
The EtherCAT Technology is covered, including but not limited to the following patent applications and patents: EP1590927, EP1789857, DE102004044764, DE102007017835 with corresponding applications or registrations in various other countries.
The TwinCAT Technology is covered, including but not limited to the following patent applications and patents: EP0851348, US6167425 with corresponding applications or registrations in various other countries.
EtherCAT® is registered trademark and patented technology, licensed by Beckhoff Automation GmbH, Germany.
Copyright
© Beckhoff Automation GmbH & Co. KG, Germany.
The reproduction, distribution and utilization of this document as well as the communication of its contents to others without express authorization are prohibited.
Offenders will be held liable for the payment of damages. All rights reserved in the event of the grant of a patent, utility model or design.


Safety instructions

Foreword [image] Safety instructions
Safety instructions
Safety regulations
Please note the following safety instructions and explanations!
Product-specific safety instructions can be found on following pages or in the areas mounting, wiring, commissioning etc.
Exclusion of liability
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 Beckhoff Automation GmbH & Co. KG.
Personnel qualification
This description is only intended for trained specialists in control, automation and drive engineering who are familiar with the applicable national standards.
Description of instructions
In this documentation the following instructions are used.
These instructions must be read carefully and followed without fail!
SmallWarningYellow DANGER
Serious risk of injury!
Failure to follow this safety instruction directly endangers the life and health of persons.
SmallWarningYellow WARNING
Risk of injury!
Failure to follow this safety instruction endangers the life and health of persons.
SmallWarningYellow CAUTION
Personal injuries!
Failure to follow this safety instruction can lead to injuries to persons.
Note
Damage to environment/equipment or data loss
Failure to follow this instruction can lead to environmental damage, equipment damage or data loss.
Tip or pointer
This symbol indicates information that contributes to better understanding.


Documentation Issue Status

Foreword [image] Documentation Issue Status
Documentation Issue Status
Version
Comment
2.0
▪
Migration
1.0
▪
completely revised
–
FC510x Monitor Software documented
–
CANopen Protocol description revised
0.9 (Pre-Release)
▪
Preliminary version, 11.03.2002
The using of the FC5101 in slave mode is described separately (FC510x Slave.chm resp. -.pdf).


Product Overview

Product Overview
Product Overview
Additional information
•
Hardware overview
•
Technical data
•
CANopen Introduction


Hardware overview

Product Overview [image] Hardware overview
Hardware overview
CAN Terminating Resistor
The card features CAN terminating resistors (120 ohm). These can be activated via a jumper (up to hardware version 3) or a slide switch (from hardware version 4) near the CAN connectors.
The Flash Disk socket is currently not in use.
FC5102
Pinout
The CAN bus line is connected via 9-pin Sub-D sockets with the following pinout.
Pin | Pinout
2 | CAN low (CAN-)
3 | CAN Ground (internally connected to pin 6)
5 | Shield
6 | CAN Ground (internally connected to pin 3)
7 | CAN high (CAN+)
The unlisted pins are not connected.
Note: an auxiliary voltage of up to 30 VDC may be connected to pin 9. Some CAN devices use this to supply the transceiver.
FC5102 panel


Technical data

Product Overview [image] Technical data
Technical data
FC510x
The FC510x is a CANopen master card with the following features:
▪
One (FC5101) or two (FC5102) CAN channels, each with its own processor, memory, etc.
▪
Optionally CANopen master or slave.
▪
All PDO communication types are supported.
▪
Process image: max. 3 kbytes input and output data in total.
▪
Each PDO can be individually monitored.
▪
Host communication may be free running, synchronized or equidistant.
▪
Equidistant mode for drive control over the bus: SYNC objects are transmitted with a mean timing having the accuracy of the quartz oscillator, while process data exchange with the application is synchronized throughout (only with TwinCAT).
▪
Emergency messages are stored by the card.
▪
Error handling can be set individually for each bus node.
▪
General CAN messages (CAN layer 2) can be sent and received.
▪
Powerful parameter and diagnostics interface.
▪
Integrated bus loading display.
▪
CAN interfaces are electrically isolated.
▪
Meets CANopen specification DS301 V4.01.
▪
Boot-up according to DS302.
▪
Drivers: TwinCAT I/O for WinNT, Win2k, WinXP;
▪
Driver Construction Kit for other operating systems by request.
See the appropriate separate documentation for details of slave functionality.


CANopen Introduction

Product Overview [image] CANopen Introduction
CANopen Introduction
CANopenLogo
CANopen is a widely used CAN application layer, developed by the CAN-in-Automation association (CiA, http://www.can-cia.org), and which has meanwhile been adopted for international standardization.
Device Model
CANopen consists of the protocol definitions (communication profile) and of the device profiles that standardize 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), synchronization, error messages and so on.
CANopen Device Model
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 process 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 previously received, and to send new input data.
▪
Requested (polled): 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 Version 1). For reasons of backwards compatibility, the default mapping was not adapted to the DS401 V2 profile version.
Data transfer rates
Nine transmission rates from 10 kbaud up to 1 Mbaud are available for different bus lengths. The effective utilization of the bus bandwidth allows CANopen to achieve short system reaction times at relatively low data rates.
Topology
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 propagation delay 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 utilizes 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 prioritized 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 arbitration phase only one bus device occupies the bus, collisions are avoided and the bandwidth is optimally exploited.
Configuration and parameterization
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 (http://www.beckhoff.de) for the parameterization 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 the CAN in Automation Association (http://www.can-cia.org).


Fitting and wiring

Fitting and wiring
Fitting and wiring
Additional information
•
Installation
•
CANopen cabling


Installation

Fitting and wiring [image] Installation
Installation
Note
Qualified installation
Fieldbus PCI cards may only be fitted by qualified personnel 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.
In may be necessary before fitting to set the jumper in order to activate the internal CAN bus terminating resistors, or to set the switches (as from hardware version 3). Jumper set or switch on [ON] means: terminating resistor connected.
DIP switch ON = terminating resistor 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. Secure the board to the PC slot housing with the mounting bolt.


CANopen cabling

Fitting and wiring [image] CANopen cabling
CANopen cabling
Notes related to checking the CAN wiring can be found in the Trouble Shooting section.
Additional information
•
CAN topology
•
Bus length
•
Drop lines
•
Star Hub (Multiport Tap)
•
CAN cable
•
Shielding
•
Cable colors
•
BK5151, FC51xx, CX with CAN interface and EL6751: D-sub, 9 pin
•
BK51x0/BX5100: 5-pin open style connector
•
LC5100: Bus connection via spring-loaded terminals
•
Fieldbus Box: M12 CAN socket


CAN topology

Fitting and wiring [image] CANopen cabling [image] CAN topology
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!
Termination of the bus with a 120 Ohm termination resistor
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.
Insensitivity to incoming interference


Bus length

Fitting and wiring [image] CANopen cabling [image] Bus length
Bus length
The maximum length of a CAN bus is primarily limited by the signal propagation delay. 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 propagation delays 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 40 m 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

Fitting and wiring [image] CANopen cabling [image] Drop lines
Drop lines
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 | < 1 m | < 5 m
500 kbit/s | < 5 m | < 25 m
250 kbit/s | < 10 m | < 50 m
125 kbit/s | < 20 m | < 100 m
50 kbit/s | < 50 m | < 250 m
Drop lines must not have terminating resistors.
Sample topology of drop lines


Star Hub (Multiport Tap)

Fitting and wiring [image] CANopen cabling [image] Star Hub (Multiport Tap)
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)
1 Mbit/s | < 0,3 m | < 25 m
500 kbit/s | < 1,2 m | < 66 m
250 kbit/s | < 2,4 m | < 120 m
125 kbit/s | < 4,8 m | < 310 m


CAN cable

Fitting and wiring [image] CANopen cabling [image] CAN cable
CAN cable
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 colors: 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, outside diameter 7.3 +/- 0.4 mm
▪
Weight: 64 kg/km.
▪
printed with "Beckhoff ZB5100 CAN-BUS 2x2x0.25" and meter marking (length data every 20cm)
Structure of CAN cable ZB5100
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, outside diameter 7.3 mm
▪
printed with "InterlinkBT DeviceNet Type 572" as well as UL and CSA ratings
▪
stranded wire colors correspond to the DeviceNet specification
▪
UL recognized AWM Type 2476 rating
▪
CSA AWM I/II A/B 80°C 300V FT1
▪
corresponds to the DeviceNet "Thin Cable" specification
Structure of CAN/DeviceNet cable ZB5200


Shielding

Fitting and wiring [image] CANopen cabling [image] Shielding
Shielding
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.
Notes related to checking the CAN wiring can be found in the Trouble Shooting section.


Cable colors

Fitting and wiring [image] CANopen cabling [image] Cable colors
Cable colors
Suggested method of using the Beckhoff CAN cable on Bus Terminal and Fieldbus Box:
BK51x0 pin PIN BX5100 (X510) | Pin BK5151 CX8050, CX8051, CXxxxx-B510/M510 | Fieldbus Box pin | Pin FC51xx | Function | ZB5100 cable color | ZB5200 cable color
1 | 3 | 3 | 3 | CAN Ground | black/ (red) | black
2 | 2 | 5 | 2 | CAN Low | black | blue
3 | 5 | 1 | 5 | Shield | Filler strand | Filler strand
4 | 7 | 4 | 7 | CAN high | white | white
5 | 9 | 2 | 9 | not used | (red) | (red)


BK5151, FC51xx, CX with CAN interface and EL6751: D-sub, 9 pin

Fitting and wiring [image] CANopen cabling [image] BK5151, FC51xx, CX with CAN interface and EL6751: D-sub, 9 pin
BK5151, FC51xx, CX with CAN interface and EL6751: D-sub, 9 pin
The CANbus cable is connected to the FC51x1, FC51x2 CANopen cards and in the case of the EL6751 CANopen master/slave terminal via 9-pin Sub-D sockets with the following pin assignment.
Pin | Assignment
2 | CAN low (CAN-)
3 | CAN ground (internally connected to pin 6)
6 | CAN ground (internally connected to pin 3)
7 | CAN high (CAN+)
The unlisted pins are not connected.
The mounting rail contact spring and the plug shield are connected together.
Note: an auxiliary voltage of up to 30 VDC may be connected to pin 9. Some CAN devices use this to supply the transceiver.
BK5151, EL6751 pin assignment
FC51x2:
FC51x2


BK51x0/BX5100: 5-pin open style connector

Fitting and wiring [image] CANopen cabling [image] BK51x0/BX5100: 5-pin open style connector
BK51x0/BX5100: 5-pin open style connector
The BK51x0/BX5100 (X510) 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.
BK51x0/BX5100 socket assignment
The left figure shows the socket in the BK51x0/BX5100 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/BX5100 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

Fitting and wiring [image] CANopen cabling [image] LC5100: Bus connection via spring-loaded terminals
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.
LC5100
Note
Risk of device damage!
On account of the lack of electrical isolation, the CAN driver can be destroyed or damaged due to incorrect cabling. Always carry out the cabling in the switched-off condition.
First connect the power supply and then the CAN. Check the cabling and only then switch on the voltage.


Fieldbus Box: M12 CAN socket

Fitting and wiring [image] CANopen cabling [image] Fieldbus Box: M12 CAN socket
Fieldbus Box: M12 CAN socket
The IPxxxx-B510, IL230x-B510 and IL230x-C510 Fieldbus Boxes are connected to the bus using 5-pin M12 plug-in connectors.
Pin assignment: M12 plug, fieldbus box
Beckhoff offer plugs for field assembly, passive distributor's, terminating resistors and a wide range of pre-assembled cables for the Fieldbus Box system. Details be found in the catalogue, or under www.beckhoff.de.


Parameterization and Commissioning

Parameterization and Commissioning
Parameterization and Commissioning
Additional information
•
Configuration: TwinCAT System Manager
•
Beckhoff Bus Coupler
•
CANopen node
•
Configuration Files


Configuration: TwinCAT System Manager

Parameterization and Commissioning [image] Configuration: TwinCAT System Manager
Configuration: TwinCAT System Manager
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 organizes the mapping of the data traffic.
TwinCAT System Manager
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
The procedure and the configuration facilities in the System Manager are described below.
Context menu
Context menu
Append Box... <Insert>
Adds CANopen slaves (boxes). The following boxes are currently supported (more detailed description of the boxes is given further down):
Supported boxes | Description
BK5100 | Bus Coupler
BK5110 | Economy Bus Coupler
BK5120 | Bus Coupler (successor of BK5100)
LC5100 | Low-cost Bus Couplers
IPxxxx-B510 | Fieldbus compact box: CANopen in/output module, protection class IP67
CANopen Node | General CANopen device or general CAN device (access via CAN layer 2)
Delete Device... <Del>
Removes the FC510x fieldbus card and all subsidiary elements from the I/O configuration.
Online Reset
Initiates an online reset on the CANopen bus.
FC510x tab
FC510x tab
PCI Bus/Slot
Indicates in which logical PCI slot the card was found.
Master-Node-ID
Node address for the FC5100. Range of values: 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 with which the CANopen SYNC telegram is generated.
The highest-priority task linked to the FC510x card handles the control of the CANopen card and is thus synchronized with the CANopen bus. All other tasks are served asynchronously via corresponding buffers. For all operation 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 a synchronous operation mode, a SYNC telegram is sent at the start of the cycle, which the slaves use to synchronize their actions with the master cycle.
Different modes can be selected, depending on the SYNC accuracy requirements. Note that individual SYNC telegrams in CAN systems inherently jitter by one telegram length if the bus is occupied at the time of the SYNC. The SYNC accuracy therefore primarily refers to the long-term stability. Bus nodes that synchronize via a PLL procedure are particularly dependent on good long-term stability.
Synchronization Mode
Slave
In slave mode, the card receives its time base from a SYNC master. The Sync Master is selected via the corresponding field.
▪
Sync Master: PC Task. This is the default setting. The PC sets the timebase based on the TwinCAT real-time. Depending on the setting, the task start (default for TwinCAT NC) or task end (default for TwinCAT PLC) triggers the SYNC telegram.
▪
Sync Master: Balanced PC Task. In this operation mode, the sync cycle is also generated with the accuracy of the PC time base on average. However, the interval between two SYNC telegrams is more accurate than with the Sync Master "PC task":
–
runtime differences (e.g. due to case-dependent program branches) are compensated,
–
the FC510x card delays pending send telegrams until after the SYNC telegram,
–
the individual SYNC distances are determined by the crystal-precise timer of the FC510x card.
If necessary, the card timer is readjusted in small steps to the PC timer if it the latter deviates from the card timer by the value set in "PLL Sync Time".
In this mode, the sync telegram is delayed by the shift time relative to the completion of the TwinCAT task. The shift time should be as small as possible in this mode, but sufficiently large to ensure that the TwinCAT task can access the process data. The function "Calculate Equi-Times", which is triggered by clicking on the corresponding button after the mappings have been created, helps to set the optimum shift time.
Synchronization Mode: Slave (sync master: balanced PC clock)
Master
In master mode the card generates its time base locally. The SNYC telegram is crystal-precise on average. The start of the TwinCAT task is specified by the card and is delayed by the shift time relative to the SYNC telegram. In this mode, the shift time should be selected as large as possible. The function "Calculate Equi-Times", which is triggered by clicking on the corresponding button after the mappings have been created, helps to set the optimum shift time.
Synchronization Mode: Master
Cycle Time
Displays the cycle time of the corresponding highest priority task. The display is updated when the mapping is generated.
Watchdog Time
Here, a watchdog can be activated, which means that the FC510x enters STOP mode in the event of a PC crash and also transfers all projected slaves to this state.
Sync-Cycle Multiplier
CANopen SYNC Cycle Time = (Task) Cycle Time x Sync-Cycle Multiplier. Event driven PDO communications and cyclical 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. If the sync cycle multiplier is set to values > 1, the TwinCAT task is called repeatedly before the SYNC telegram is sent again.
Sync-Cycle Time
The cycle time of the CANopen snyc telegram is displayed here. It results from the cycle time of the highest-priority task, whose process data are linked with the card, and from 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. This delay is set in percent of the SYNC cycle time with the parameter Sync-Tx-PDO -Delay.
Example
Task Cycle Time = 2000 µs, Sync-Cycle Multiplier = 5, Sync Tx-PDO Delay =40. The PLC task can process event-driven PDOs every 2 ms; the CANopen sync cycle is 10 ms; the FC510x sends its synchronous PDOs 4 ms (=40% of 10 ms) after the SYNC.
Search...
This is used to search all existing FC510x channels; the required channel can be selected. 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) (boxes cannot be added). 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 a comparison of the expected (entered) network configuration with the devices actually found in the network. The data from the CANopen Identify Object are read and compared. In the case of Beckhoff boxes the connected Bus Terminals or extension modules are read and compared (under preparation).
Firmware
Shows the current firmware version of the FC510x.
Firmware Update...
Update the FC510x card firmware version here. Attention: 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 (diagnostics, acyclic communication) intended for the FC510x, have to address the card via this Net-ID.
Box States tab
Box States tab
Displays an overview of all current box states.
DPRAM (Online) tab
Refer to "Online display of DPRAM" in the System Manager documentation.
Diagnostic Inputs
The FC510x automatically provides various diagnostic variables which describe the status of the card and the CANopen network:
FC510x - diagnostic variables
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 directly available as variables.)
Offset 1-127: BusStatus List, 1-127 one byte each station address which contains the station status (see BoxState for CANopen boxes)
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 few or too many termination resistors, at least one device with incorrect baud rate, short circuit, etc.) The "bus off" state can only be exited through 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 corresponding task tried to read or write the process image again. If this counter is incremented, the task cycle time has been set too low for the actual network configuration.
BusLoad: Shows the current bus load in %. The Bus Load is an important design criterion for CAN networks. The value shown is an average value over 100 ms.


Beckhoff Bus Coupler

Parameterization and Commissioning [image] Beckhoff Bus Coupler
Beckhoff Bus Coupler
The BK51x0 Bus Coupler and the IPxxx-B510 Fieldbus Box are installed in the CANopen bus. The specific properties which distinguish them from other Bus Couplers and/or Fieldbus Box modules are then described below.
Types | Description
BK5100 | Bus Coupler
BK5110 | Economy Bus Coupler
BK5120 | Bus Coupler, successor of BK5100
LC5100 | Low-cost Bus Couplers
IPxxxx-B510 | Fieldbus compact box: CANopen in/output module, protection class IP67
ILxxxx-B510 | Fieldbus Coupler Box: Expandable CANopen input/output module in protection class IP67
BK51x0/IX-B510 tab
BK51x0/IX-B510 tab
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 analog and special signals. If more than 64 digital signals are present, they also furnished with this inhibit time.
Event Time: Event timer for transmit PDOs. 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.
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 / analog input telegrams. 254 + 255 corresponds to the event-driven transmission, 1...240 are synchronous transmission 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).
SDOs tab
SDOs tab
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 "Append", "Insert", "Delete" and "Edit".
ADS tab
The node (Bus Coupler) is assigned an ADS port to enable writing and reading of SDO objects at runtime (e.g. from the PLC). It can be changed if required. The ADS IndexGroup contains the CANopen object index and the ADS IndexOffset contains the CANopen SubIndex. See chapter SDO communication for details of SDO communication via ADS.
Diag tab
Diagnostic information is displayed here. The window contents are not cyclically refreshed; select the "Refresh" button if necessary. The diagnostic information displayed can also be queried by ADS.


CANopen node

Parameterization and Commissioning [image] CANopen node
CANopen node
CANopen devices which are not recognized 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 / EL6751, 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 / EL6751.
CAN Node tab
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).
The set/actual configuration comparison only takes place if Profile No. or Add. Info (i.e. object directory entry 0x1000) is set to a value that is not 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.
Guard Time
The Guard Time determines the interval at which the node is monitored (node guarding). 0 means no monitoring. The value entered is rounded up to the next multiple of 10 ms.
Life Time Factor
Guard Time x Life Time 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.
The FC 510x / EL6751 also support the Heartbeat protocol and initially attempt to start this form of node monitoring on the CANopen node (write access to the objects 0x1016 and 0x1017 in the object dictionary). 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. In this case a Heartbeat telegram is transmitted with the smallest configurable guard time (the guard times can be individually set for each node).
Emcy COB Id / Guard COB ID
Identifier for emergency messages or guarding protocol. They result from the node address.
Use Heartbeat
Heartbeat is used for monitoring of the node. If this is deactivated, the guarding is used for monitoring.
Auto-adjust PDO...
Specifies whether TwinCAT should download the PDO communications parameters to the node at the system start.
If the download of the PDOs Parameter Identifier and Transmission Type fails, the card attempts to read these parameters and compare 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.
Vendor ID, Product Code, Serial No., Revision No.
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 reaction
Stop Node
After a recognized 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 state via the network status machine - SDO addressing is not possible in this mode.
No Reaction
No NMT stop remote node command after node error
Node Restart
Automatic Restart
After a recognized 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 state and is not restarted automatically. You can actuate a restart via "I/O-Reset".
Network Reaction
No Reaction
The failure of a node has no effect on the other bus devices
Stop All Nodes
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
If you have selected this checkbox, the entire CANopen network management for this device is deactivated. It is not started, monitored etc. The PDO entries are regarded as pure CAN telegrams (layer 2) and made available to the controller on an event-driven basis.
CANopen terminology
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 / EL6751 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 TwinCAT, TxPDOs are received by TwinCAT.
PDO tab
PDO tab
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 behavior 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 and EL6751 only)
Enter the value for the Event Timer in ms. For Send PDOs (here: RxPDOs, see above) an additional sending of the PDO is triggered, 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 behavior is not required, you can deactivate "Auto Download of PDO Parameters" by selecting the checkbox at the CAN node tab.
Deactivate checking of the PDO size
Checkbox for deactivation of the length check of the PDO size.
Tree Representation
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.
Object dictionary entries in TwinCAT
TwinCAT places the PDOs in the displayed order according to the object dictionary entries in the node. This way, for example, the PDO communication parameters of the third listed TxPDO are always written to index 0x1802 – independent of the designation of the PDO in the System Manager. Thus, if only PDO1 and PDO3 are to be used, a PDO2 must also be entered – in this case without assigning variables. PDOs without variables are not transmitted and also not expected.
Context menu
Context menu
The menu above is obtained by right clicking on the general CANopen node. Here you can insert further Tx PDOs and/or Rx PDOs.
SDOs tab
SDOs tab
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 "Append", "Insert", "Delete" and "Edit".
ADS tab
In order to be able to read and write SDO objects during the runtime (e.g. from the PLC), the node (Bus Coupler) can be allocated an ADS port (CIFx0-CAN). The FC510x / EL6751 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.


Configuration Files

Parameterization and Commissioning [image] Configuration Files
Configuration Files
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.
eds files for the Beckhoff CANopen slave devices are available for download from the Beckhoff website.
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 Communication

CANopen Communication
CANopen Communication
Additional information
•
Network Management
•
BootUp of the FC510x
•
Process Data Objects (PDO)
•
PDO Parameterization
•
Service Data Objects (SDO)
•
SDO communication with FC510x
•
Baud rate and bit timing
•
Identifier distribution


Network Management

CANopen Communication [image] Network Management
Network Management
Simple Boot-Up
CANopen allows the distributed network to boot in a very simple way. After initialization, 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:
CANopen bootup state diagram
Pre-Operational
After initialization 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 K-Bus 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 error 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.
State Transitions
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 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 | Command Specifier cs | Explanation
(1) | - | The initialization state is reached automatically at power-up
(2) | - | After initialization the pre-operational state is reached automatically - this involves sending the boot-up message.
(3), (6) | cs = 1 = 0x01 | Start_Remote_Node. Starts the module, enables outputs, starts transmission of PDOs.
(4), (7) | cs = 128 = 0x80 | Enter_Pre-Operational. Stops PDO transmission, SDO still active.
(5), (8) | cs = 2 = 0x02 | Stop_Remote_Node. Outputs go into the fault state, SDO and PDO switched off.
(9), (10), (11) | cs = 129 = 0x81 | Reset_Node. Carries out a reset. All objects are reset to their power-on defaults.
(12), (13), (14) | cs = 130 = 0x82 | Reset_Communication. Carries out a reset of the communication functions. Objects 0x1000 - 0x1FFF are reset to their power-on defaults.
Sample 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
Sample 2
The following telegram resets node 17:
11 bit identifier | 2 byte of user data
0x00 | 0x81 | 0x11
Boot-up message
After the initialization phase and the self-test the Bus Coupler sends the boot-up message, which is a CAN message with a data byte (0) on 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 drop), 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 allocation).
It is also possible, with the aid of the boot-up message, to recognize the nodes present in the network at start-up 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 initialization phase; the Bus Coupler signals that it can now be configured or started.
Firmware version BA
Up to firmware version BA the emergency identifier was used for the boot up message.
Format of the Boot-up message
11 bit identifier | 1 byte of user data
0x700 (=1792)+ node ID | 0x00
Node Monitoring
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
Schematic diagram: "Guarding procedure"
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 (previously: Prepared)
5 = 0x05 | Operational
127 = 0x7F | Pre-Operational
Sample
The guarding message for node 27 (0x1B) must be requested by a remote frame having identifier 0x71B (1819dec). If the node is Operational, the first data byte of the answer message alternates between 0x05 and 0x85, whereas in the Pre-Operational state it alternates between 0x7F and 0xFF.
Guard time and life time factor
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
Schematic diagram: "Heartbeat procedure"
Protocol
The toggle bit is not used in the heart beat procedure. The nodes send their status cyclically (s). See Guarding.


BootUp of the FC510x

CANopen Communication [image] BootUp of the FC510x
BootUp of the FC510x
Introduction
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 parameterized and started, independently of the others. The starting behavior 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.
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 a timeout (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 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 Parameter
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 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.
6. Download User Parameter
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 if 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 parameterized 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.
Example of a boot up sequence:
Node with node ID1, identifier in hex code.
Time ID DLC DATA Description
0.1244 00 2 82 00 Reset communication all nodes
 All nodes are moved into source state
0.1252 601 8 40 00 10 00 00 00 00 00 [1000,00] Initiate Upload Rq.
First attempt to find knot 1 - node is still in Reset
2.1316 601 8 80 00 00 00 00 00 04 05 05040000 [0000,00] Abort: SDO protocol timed out
Node has not answered within SDO Time-out (2 sec), SDO is broken off
2.7875 701 1 00 Boot-up
 Node has carried out reset and contacts with Boot-Up message
4.1391 601 8 40 00 10 00 00 00 00 00 [1000,00] Initiate Upload Rq.
 Second attempt to find node 1. Reading access to object 0x1000
4.1411 581 8 43 00 10 00 91 01 07 00 91 01 07 00 [1000,00] Initiate Upload Rsp. expedited
Node 1 answers with Profile No. 0x191 (401dez) and Add. Info 0x07
4.1418 601 8 40 18 10 01 00 00 00 00 [1018,01] Initiate Upload Rq.
The Vendor ID is read
4.1434 581 8 43 18 10 01 02 00 00 00 02 00 00 00 [1018,01] Initiate Upload Rsp. expedited
 Node 1 answers with Vendor ID 0x02 (= Beckhoff)
4.1442 601 8 23 00 18 01 81 01 00 00 81 01 00 00 [1800,01] Initiate Download Rq. expedited
 Now the Identifier for of TxPDO1 is written: 0x181
4.1831 581 8 60 00 18 01 00 00 00 00 [1800,01] Initiate Download Rsp
 Node 1 confirms the download
4.1840 601 8 23 01 18 01 81 02 00 00 81 02 00 00 [1801,01] Initiate Download Rq. expedited
 Identifier for TxPDO2 is 0x281
4.2223 581 8 60 01 18 01 00 00 00 00 [1801,01] Initiate Download Rsp
4.2230 601 8 23 00 14 01 01 02 00 00 01 02 00 00 [1400,01] Initiate Download Rq. expedited
 Identifier for RxPDO1 is 0x201
4.2347 581 8 60 00 14 01 00 00 00 00 [1400,01] Initiate Download Rsp
4.2356 601 8 2f 00 18 02 ff 00 00 00 ff [1800,02] Initiate Download Rq. expedited
 Transmission type for TxPRO1 is 0xFF=255
4.2737 581 8 60 00 18 02 00 00 00 00 [1800,02] Initiate Download Rsp
4.2744 601 8 2f 01 18 02 ff 00 00 00 ff [1801,02] Initiate Download Rq. expedited
 Transmission type for TxPRO2 is 0xFF=255
4.3133 581 8 60 01 18 02 00 00 00 00 [1801,02] Initiate Download Rsp
4.3141 601 8 2f 00 14 02 ff 00 00 00 ff [1400,02] Initiate Download Rq. expedited
 Transmission type for RxPRO1 is 0xFF=255
4.3252 581 8 60 00 14 02 00 00 00 00 [1400,02] Initiate Download Rsp
4.3264 601 8 2b 17 10 00 64 00 00 00 64 00 [1017,00] Initiate Download Rq. expedited
 Heartbeat Producer Time is 0x64=100ms
4.3279 581 8 60 17 10 00 00 00 00 00 [1017,00] Initiate Download Rsp
4.3287 601 8 23 16 10 01 2c 01 7f 00 2c 01 7f 00 [1016,01] Initiate Download Rq. expedited
 Heartbeat Consumer Time ist 0x012C=300ms, Node ID des Heartbeat Producers (hier: FC5101) ist 0x7F
4.3304 581 8 60 16 10 01 00 00 00 00 [1016,01] Initiate Download Rsp
4.3312 601 8 23 00 55 00 00 00 ff ff 00 00 ff ff [5500,00] Initiate Download Rq. expedited
 User Parameter: Index 0x5500, SI 0, Wert 0x00 00 FF FF
4.3321 701 1 7f T0 Preoperational
 Node 1 sends first heartbeat telegram, FC5101 starts controlling
4.4679 581 8 60 00 55 00 00 00 00 00 [5500,00] Initiate Download Rsp
4.4686 601 8 2f 23 64 00 01 00 00 00 01 [6423,00] Initiate Download Rq. expedited
 User Parameter: Index 0x6423, SI 0, Wert 0x01
4.4700 581 8 60 23 64 00 00 00 00 00 [6423,00] Initiate Download Rsp
4.4707 00 2 01 01 Start Node
 Node 1 is transferred individually in operational
4.4717 701 1 7f T0 Preoperational
 The next heartbeat telegram is sent before the status crossing is concluded
4.4986 181 1 00 00
 Node 1 is operational and sends his TxPDO1 and TxPDO2
4.4989 281 4 00 00 00 00 00 00 00 00
4.5786 701 1 05 T0 Operational
4.6390 281 4 00 00 08 00 00 00 08 00
4.6411 281 4 00 00 00 00 00 00 00 00
4.6891 701 1 05 T0 Operational
4.7951 701 1 05 T0 Operational
4.9032 701 1 05 T0 Operational
5.0048 281 4 00 00 08 00 00 00 08 00
5.0070 281 4 00 00 00 00 00 00 00 00
5.0094 701 1 05 T0 Operational
5.0153 281 4 00 00 08 00 00 00 08 00
5.0174 281 4 00 00 00 00 00 00 00 00
5.1129 701 1 05 T0 Operational
....
5.4755 00 2 01 00 Start all nodes
 Now all nodes are started
5.4847 201 1 00 00
 approx. 1 sec after start of node 1 the RxPDO1 is sent for the first time


Process Data Objects (PDO)

CANopen Communication [image] Process Data Objects (PDO)
Process Data Objects (PDO)
Introduction
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 PDOs (RxPDOs) and transmit PDOs (TxPDOs) are distinguished, the name being chosen from the point of view of the 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 TwinCAT 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 Beckhoff Bus Couplers or Fieldbus Coupler Box modules make 16 RxPDO and TxPDOs available for the exchange of process data (although the figure for Economy and LowCost BK5110 and LC5100 Couplers and the Fieldbus Boxes is 5 PDOs each, since these devices manage a lower quantity of process data). The FC510x 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. The EL6751 CANopen terminal dynamically organizes the process image; i.e. the process data are written in succession, enabling a higher data transmission rate. Up to 32 TxPDOs and 32 RxPDOs can 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 known 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 sub-index 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 the object 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 it its use of the available identifiers, so that the use of the 29-bit versions remains limited to unusual applications. It is therefore also not supported by a Beckhoff's CANopen devices. 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 in the appendix.
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.
Default identifier allocation: Master/Slave
PDO linking: Peer to Peer
If the consumer-producer model of CANopen PDOs is to be used for direct data exchange between nodes (without a master), the identifier allocation 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 sample, easy construction of electronic drives in which several slave axes simultaneously listen to the actual value in the master axis TxPDO.
PDO Communication Types: Overview
CANopen offers a number of possible ways to transmit process data (see also: Notes on PDO Parameterization).
Diagram: CAN process data transmission
Event driven
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 behavior of remote frame and response telegrams depends on what CAN controller is in use. 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 up-to-date. Beckhoff use CAN controllers following the principle of Basic CAN.
Since this device behavior 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.
Synchronized
It is not only for drive applications that it is worthwhile to synchronize 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 synchronized nodes as a trigger for reading the inputs or for setting the outputs.
Diagram: CAN "SYNC" telegram
PDO transmission types: Parameterization
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 parameterized for RxPDOs in the objects at 0x1400ff, sub-index 2, and for TxPDOs in the objects at 0x1800ff, sub-index 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 switches, for sample, its outputs into the error state.
The FC510x card / EL6751 terminal fully support the synchronous communication method: transmitting the SYNC telegram is coupled to the linked task, so that new input data is available every time the task begins. If a synchronous PDO does not arrive, this is detected and reported 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 / terminals.
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.
Inhibit time
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.
Timing diagram: "Inhibit time"
Although the Beckhoff FC510x PC cards / EL6751 terminal can parameterize 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 sub-index 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.
Time representation of the event timer
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 / EL6751 can in this way monitor each individual PDO.
Notes on PDO Parameterization
PDO Mapping
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.
Mapping representation
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 | Object directory address
Number of digital input bytes | Index 0x6000, sub-index 0
Number of digital output bytes | Index 0x6200, sub-index 0
Number of analog inputs | Index 0x6401, sub-index 0
Number of analog outputs | Index 0x6411, sub-index 0
Variable mapping
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, sub-index 1, bit 31 to "1")
2.
Set sub-index 0 in the mapping parameters (0x1600ff or 0x1A00ff) to "0"
3.
Change mapping entries (0x1600ff or 0x1A00ff, SI 1..8)
4.
Set sub-index 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, sub-index 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.


PDO Parameterization

CANopen Communication [image] PDO Parameterization
PDO Parameterization
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 optimized in the light of application requirements which are likely to be to some extent in conflict. These include
▪
Little work on parameterization - 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
▪
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 fundamentally more sensitive to interference as the baud rate is increased. The following rule therefore applies: just as fast as necessary. 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 defined time behavior - 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 synchronized: Inputs are read at the same time, output data is set valid simultaneously, although the quality of the synchronization depends on the implementation. The BECKHOFF FC510x PC cards / EL6751 CANopen terminal are capable of synchronizing 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 optimize 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 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 parameterized 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 sample it can also be of value to deliberately manipulate the identifier allocation, in order to optimize 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.
Optimization 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 sample 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 cannot 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, parameterization 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 CANopen master cards / EL6751 CANopen master terminal display the bus load via the System Manager. This variable can also be processed in the PLC, or can be displayed in the visualization system.
The amount data in the process data objects is of course as relevant as the communication parameters: the PDO mapping.


Service Data Objects (SDO)

CANopen Communication [image] Service Data Objects (SDO)
Service Data Objects (SDO)
The parameters listed in the object directory are read and written by means of service data objects. These SDOs are Multiplexed Domains, i.e. data 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.
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.
Client -> Server, Upload Request
11 bit identifier | 8 byte user data
0x600 (=1536dec) + node ID | 0x40 | Index0 | Index1 | SubIdx | 0x00 | 0x00 | 0x00 | 0x00
Parameter | Explanation
Index0 | Index low byte (Unsigned16, LSB)
Index1 | Index high byte (Unsigned16, MSB)
SubIdx | Sub-index (Unsigned8)
Client -> Server, Upload Response
11 bit identifier | 8 byte user data
0x580 (=1408dec) + node ID | 0x4x | Index0 | Index1 | SubIdx | Data0 | Data1 | Data2 | Data3
Parameter | Explanation
Index0 | Index low byte (Unsigned16, LSB)
Index1 | Index high byte (Unsigned16, MSB)
SubIdx | Sub-index (Unsigned8)
Data0 | Data low low byte (LLSB)
Data3 | Data high high byte (MMSB)
Parameters whose data type is Unsigned8 are transmitted in byte D0, parameters whose type is Unsigned16 use D0 and D1.
The number of valid data bytes is coded as follows in the first CAN data byte (0x4x):
Number of parameter bytes | 1 | 2 | 3 | 4
First CAN data byte | 0x4F | 0x4B | 0x47 | 0x43
Client -> Server, Download Request
11 bit identifier | 8 byte user data
0x600 (=1536dec) + node ID | 0x22 | Index0 | Index1 | SubIdx | Data0 | Data1 | Data2 | Data3
Parameter | Explanation
Index0 | Index low byte (Unsigned16, LSB)
Index1 | Index high byte (Unsigned16, MSB)
SubIdx | Sub-index (Unsigned8)
Data0 | Data low low byte (LLSB)
Data3 | Data high high byte (MMSB)
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 22 h in the first CAN data byte.
Client -> Server, Download Response
11 bit identifier | 8 byte user data
0x580 (=1408dec) + node ID | 0x60 | Index0 | Index1 | SubIdx | 0x00 | 0x00 | 0x00 | 0x00
Parameter | Explanation
Index0 | Index low byte (Unsigned16, LSB)
Index1 | Index high byte (Unsigned16, MSB)
SubIdx | Sub-index (Unsigned8)
Breakdown of Parameter Communication
Parameter communication is interrupted if it is faulty. The client or server send an SDO telegram with the following structure for this purpose:
11 bit identifier | 8 byte user data
0x580 (client) or 0x600(server) + node ID | 0x80 | Index0 | Index1 | SubIdx | Error0 | Error1 | Error2 | Error3
Parameter | Explanation
Index0 | Index low byte (Unsigned16, LSB)
Index1 | Index high byte (Unsigned16, MSB)
SubIdx | Sub-index (Unsigned8)
Error0 | SDO error code low low byte (LLSB)
Error3 | SDO error code high high byte (MMSB)
List of SDO error codes (reason for abortion of the SDO transfer):
SDO error code | Explanation
0x05 03 00 00 | Toggle bit not changed
0x05 04 00 01 | SDO command specifier invalid or unknown
0x06 01 00 00 | Access to this object is not supported
0x06 01 00 02 | Attempt to write to a Read_Only parameter
0x06 02 00 00 | The object is not found in the object directory
0x06 04 00 41 | The object cannot be mapped into the PDO
0x06 04 00 42 | The number and/or length of mapped objects would exceed the PDO length
0x06 04 00 43 | General parameter incompatibility
0x06 04 00 47 | General internal error in device
0x06 06 00 00 | Access interrupted due to hardware error
0x06 07 00 10 | Data type or parameter length do not agree or are unknown
0x06 07 00 12 | Data type does not agree, parameter length too great
0x06 07 00 13 | Data type does not agree, parameter length too short
0x06 09 00 11 | Sub-index not present
0x06 09 00 30 | General value range error
0x06 09 00 31 | Value range error: parameter value too great
0x06 09 00 32 | Value range error: parameter value too small
0x06 0A 00 23 | Resource not available
0x08 00 00 21 | Access not possible due to local application
0x08 00 00 22 | Access not possible due to current device status
Further, manufacturer-specific error codes have been introduced for register communication (index 0x4500, 0x4501):
SDO error code | Explanation
0x06 02 00 11 | Invalid table: Table or channel not present
0x06 02 00 10 | Invalid register: table not present
0x06 01 00 22 | Write protection still set
0x06 07 00 43 | Incorrect number of function arguments
0x06 01 00 21 | Function still active, try again later
0x05 04 00 40 | General routing error
0x06 06 00 21 | Error accessing BC table
0x06 09 00 10 | General error communicating with terminal
0x05 04 00 47 | Time-out communicating with terminal


SDO communication with FC510x

CANopen Communication [image] SDO communication with FC510x
SDO communication with FC510x
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 added.
Edit SDO entry
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. Details about the ADS function blocks can be found in the TwinCAT documentation (Beckhoff Information System).
The ADS function block parameters are represented as follows in the SDO parameters:
ADSREAD / ADSWRITE
Parameter | Description
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 | Corresponds to the 16 bit index in the CANopen object directory.
IDXOFFS | Corresponds to the 8 bit subindex in the CANopen object directory.
LEN | The length of the parameter that is to be read or written, in bytes.
DESTADDR (only ADSREAD) | 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.
SRCADDR (only ADSWRITE) | 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.
READ | The ADS command is triggered by a rising edge at this input
TIMEOUT | States the time before the function is canceled
BUSY | This output remains TRUE until the function block has executed a command, but at the longest for 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.
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 reset to 0 by the execution of a command at the inputs.
The ERRID is a 32 bit value. The Low word (bits 0...15) contains the general ADS ERROR CODES, while the High word (bits 16...31) returns SDO-specific error codes:
MSB |  |  |  | LSB
Bit 31 | Bits 30...24 | Bits 23...20 | Bits 19...16 | Bit 15...0
1 | Bits 6..0 of the SDO error code | Bits 19...16 of the SDO error code | Bits 27...24 of the SDO error code | ADS ERROR code, see chapter Error handling and diagnostics for meaning
If one of the values SDO Additional Code, SDO Error Code or SDO Error Class is larger than the available data width (hidden bits set), then the value 0x2115 is returned in the High word (bits 16...31).
Example: SDO Read via ADS
In the following sample program (structured text) for the use of ADS services for SDO communication, object 0x1000, subindex 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.
SDO Read via ADS
SDO_READ(
StartReading :=ReadStart,
CO_Index :=16#1000,
CO_SubIndex :=16#0,
DataLength := 4,
PortNr := 16#1001,
ADSNetID:='192.168.10.11.2.1'
);
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
Sample: SDO Write via ADS
In the following sample program (structured text) for the use of ADS services for SDO communication, object 0x6200, Subindex3, from the node with port number 0x1001 is written. It concerns digital outputs to an I/O node.
(* Data to be written *)
WriteData[0] := 16#55;

(* write Object *)
SDO_WRITE(
StartWriting := WriteStart,
CO_Index := 16#6200,
CO_SubIndex := 3,
DataLength := 1,
PortNr := 16#1001,
WriteData := WriteData,
ADSNetID:='192.168.10.11.2.1'
);
IF SDO_WRITE.WriteDataFinished THEN
WriteStart := FALSE;
WriteError := SDO_WRITE.Error;
END_IF
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
CASE
state OF
0:
IF StartWriting THEN
WriteDataFinished := FALSE;
Error := 0;
ADSWrite(
NETID:= ADSNetID,
PORT:= PortNr,
IDXGRP:= CO_Index,
IDXOFFS:= CO_SubIndex,
LEN:= DataLength,
SRCADDR:= ADR(WriteData),
WRITE:= TRUE,
TMOUT := T#1s
);
IF ADSWrite.err THEN
state := 2;
WriteDataFinished := TRUE;
Error := ADSWrite.ErrId;
ELSE
state := 1;
END_IF
ELSE
ADSWrite(
NETID:= '',
PORT:= PortNr,
IDXGRP:= CO_Index,
IDXOFFS:= CO_SubIndex,
LEN:= DataLength,
SRCADDR:= ADR(WriteData),
WRITE:= FALSE,
TMOUT := T#1s
);
END_IF
1:
ADSWrite(WRITE:=FALSE);
IF ADSWrite.err THEN
state := 2;
WriteDataFinished := TRUE;
Error := ADSWrite.ErrId;
ELSE
IF NOT ADSWrite.busy THEN
state := 2;
WriteDataFinished := TRUE;
END_IF
END_IF
2:
ADSWrite(WRITE:=FALSE);
state := 0;
END_CASE


Baud rate and bit timing

CANopen Communication [image] Baud rate and bit timing
Baud rate and bit timing
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 optimized for the maximum bus length.


Identifier distribution

CANopen Communication [image] Identifier distribution
Identifier distribution
Default identifier
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:
Structure of the default identifier
For broadcast objects the node ID is set to 0. This gives rise to the following default identifiers:
Broadcast objects
Object | Function | Function code | resulting COB ID hex / dec | Object for comm. Parameter / mapping
NMT | Boot-Up | 0 | 0x00 / 0 | - / -
SYNC | Synchronization | 1 | 0x80 / 128 | 0x1005 + 0x1006 / -
Peer-to-peer objects
Object | Function with I/O devices | Function code | resulting COB ID hex / dec | Object for comm. Parameter / mapping
Emergency | Status / error | 1 | 0x81 - 0xFF/ 129 - 255 | - / -
PDO1 (tx) | dig. inputs | 11 | 0x181 - 0x1FF / 385 - 511 | 0x1800 / 0x1A00
PDO1 (rx) | digital outputs | 100 | 0x201 - 0x27F/ 513-639 | 0x1400 / 0x1600
PDO2 (tx) | analog inputs | 101 | 0x281 - 0x2FF/ 641-767 | 0x1801 / 0x1A01
PDO2 (rx) | analog outputs | 110 | 0x301 - 0x37F/ 769-895 | 0x1401 / 0x1601
PDO3 (tx) | analog inputs* | 111 | 0x381 - 0x3FF / 897 - 1023 | 0x1802 / 0x1A02
PDO3 (rx) | analog outputs* | 1000 | 0x401 - 0x47F/ 1025 - 1151 | 0x1402 / 0x1602
PDO4 (tx) | analog inputs* | 1001 | 0x481 - 0x4FF/ 1153 - 1279 | 0x1803 / 0x1A03
PDO4 (rx) | analog outputs* | 1010 | 0x501 - 0x57F/ 1281 - 1407 | 0x1403 / 0x1603
SDO (tx) | Parameter | 1011 | 0x581 - 0x5FF/ 1409-1535 | - / -
SDO (rx) | Parameter | 1100 | 0x601 - 0x67F/ 1537-1663 | - / -
Guarding | Life/node guarding, Heartbeat, Boot-up message | 1110 | 0x701 - 0x77F/ 1793-1919 | (0x100C, 0x100D, 0x100E, 0x1016, 0x1017)
* For historical reasons, the Beckhoff default mapping applies to PDOs 3 and 4 in Beckhoff I/O devices. In most configurations, PDOs 3+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 up to firmware status BA correspond to this issue of the specification. After firmware version C0 (CANopen version 4), default identifiers are provided for up to 4 PDOs.


Error handling and diagnostics

Error handling and diagnostics
Error handling and diagnostics
Additional information
•
LEDs
•
Bus Node Diagnostics
•
FC510x Diagnostics
•
Error telegrams: Emergency
•
ADS error codes
•
CANopen Trouble Shooting


LEDs

Error handling and diagnostics [image] LEDs
LEDs
FC510x - LEDs
LED behavior
The main card states can be quickly diagnosed by means of the red Error LED and the green Run LED:
Error LED (red) | Run LED (green) | Meaning
off | off | TwinCAT is stopped
off | on | All configured bus devices are error-free (box state = 0); TwinCAT task or process is running.
off | flashes at 2 Hz | The task whose process data are linked to the card is not running. All configured bus devices found and error-free (box state = 0)
flashes at 2 Hz | on | At least one box state is not zero (e.g. device not found, wrong configuration, device fault), TwinCAT task is running
flashes at 2 Hz | off | At least one box state is not zero (e.g. device not found, wrong configuration, device fault), TwinCAT task is not running.
on | off | TwinCAT is running, CAN controller is Bus OFF. Physical CAN problem. Possible causes: e.g. missing termination resistor, bus line too long, wrong baud rate, node address assigned twice, wiring fault, short circuit. Restart required
flashes at 20 Hz | flashes at 20 Hz | Configuration upload being carried out
flashes at 20 Hz | off | Card is in STOP mode


Bus Node Diagnostics

Error handling and diagnostics [image] Bus Node Diagnostics
Bus Node Diagnostics
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.
Input variable Node State
Node State (Box-State)
Node State
Meaning
Explanation
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:
▪
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.
2 = 0x02
Node not found
Node not found: no answer to SDO read access to object 0x1000 at the 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.)
4 = 0x04
SDO syntax error at StartUp
Error during SDO write access: SDO abort by node. See the "Diag" tab for details.
or: the length of an object read by SDO does not agree with the expected length.
5 = 0x05
SDO data mismatch at StartUp
Expected data do not match the data read via SDO (e.g. Device Profile and/or Add. Info does not match object 0x1000). Can also occur if the 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.
8 = 0x08
Node StartUp in progress
Node was found and has been started.
11 = 0x0B
FC510x Bus-OFF
CAN chip has entered the "Bus-OFF" state: transmit error counter is running
12 = 0x0C
Pre-Operational
Node has gone pre-operational (on its own account).
13 = 0x0D
Severe bus fault
General firmware error.
14 = 0x0E
Guarding: toggle error
Guarding error: Toggle bit has not changed.
20 = 0x14
TxPDO too short
Received TxPDO shorter than expected.
22 = 0x16
Expected TxPDO is missing
TxPDO has not been received within the expected time interval:
▪
sync interval with synchronous TxPDOs,
▪
event timer with event-driven PDOs.
23 = 0x17
Node is Operational but not all TxPDOs were received
Node has been started, but at least one TxPDO has not yet been received from the node. Possible causes (e.g.):
▪
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. Further ADS parameters:
Port: 200
IndexGroup: Lo-Word = 0xF180, Hi-Word = Node-Number.
IndexOffset: See below
Length: See below
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 read access, if IndexGroup 0xF181 (instead of 0xF180) is used for reading.
The diagnostic data have the following definitions:
Offset 0,1:
Bit 1:
Boot up message not received or incorrect
Bit 2:
Emergency-Overflow
Bit 0, Bits 3-15:
reserved
Offset 2,3:
Bits 0-14:
TX-PDO (i+1) received
Bit 15:
All TX PDOs 16-n received
Offset 4,5:
Bits 0-4:
1.
Incorrect TX PDO length
2.
Synchronous TX PDO absent
3.
Node signaling PRE-OPERATIONAL
4.
Event timer timed out for one TX PDO
5.
No response during guarding
6.
Toggling missed several times during guarding
Bits 5-15:
Associated COB ID
Offset 6:
Bits 0-7:
1.
Incorrect value during SDO upload
2.
Incorrect length during SDO upload
3.
Abort during SDO up/download
4.
Incorrect date during a boot-up message
5.
Timeout while waiting for a boot-up message
Offset 7:
Bits 0-7:
2: Incorrect SDO command specifier
3: SDO toggle bit has not changed
4: SDO length too great
5: SDO-Abort
6: SDO-Timeout
Offset 8,9
Bits 0-7:
SDO up/download index
Offset 10:
Bits 0-7:
SDO up/download subindex
Offset 11:
Bits 0-7:
reserved
Offset 12:
Bits 0-7:
Abort errorClass
Offset 13:
Bits 0-7:
Abort errorCode
Offset 14,15:
Bits 0-15:
Abort additionalCode
Offset 16-19:
Read value (if offset 6 = 1)
Offset 20-23:
Expected value (if offset 6 = 1)
Offset 24-25:
Number of consecutive emergencies
Offset 26 - n:
Emergencies (8 bytes each)


FC510x Diagnostics

Error handling and diagnostics [image] FC510x Diagnostics
FC510x Diagnostics
The FC510x CANopen fieldbus card makes extensive diagnostic facilities available for the input variables.
FC510x - diagnostic inputs
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 diagnostics within that task. It is recommended that the cycleCounter be used here, as it is not incremented in these cases.
Busload
Indicates the current bus loading in %.
General Diag
"General Diag" tab
The minimum and maximum bus load are also displayed on the General Diag tab in addition to the current bus load, 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.


Error telegrams: Emergency

Error handling and diagnostics [image] Error telegrams: Emergency
Error telegrams: Emergency
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.
Node State
CANopen emergencies and other diagnostic data can be read via ADS. You need to enter the FC510x ADS Net-ID. Further ADS parameters:
Port: 200
IndexGroup: Lo-Word = 0xF180, Hi-Word = Node-Number.
IndexOffset: See below
Length: See below
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 read access, if IndexGroup 0xF181 (instead of 0xF180) is used for reading.
A description of the diagnostic data at offset 0...23 is to be found in the corresponding Chapter. The diagnostic area starting at offset 24 is organized 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.


ADS error codes

Error handling and diagnostics [image] ADS error codes
ADS error codes
The ADS error codes have the following meaning:
Error | Description
0x1001 | Insufficient memory for AMS command
0x1101 | Incorrect data length at StartFieldbus
0x1102 | Incorrect DeviceState at StartFieldbus
0x1103 | Device cannot change from INIT to RUN
0x1104 | Incorrect AdsState in INIT state
0x1105 | Incorrect DeviceState at StopFieldbus
0x1106 | Device cannot change from STOP to RUN if a CDL is not defined
0x1107 | Device cannot change from STOP to RUN if a box is not defined
0x1108 | Incorrect data length at StartDataTransfer
0x1109 | Incorrect DeviceState at StartDataTransfer
0x110A | Incorrect AdsState in STOP state
0x110B | Device cannot change from RUN to INIT
0x110C | Incorrect data length at StopDataTransfer
0x110D | Incorrect DeviceState at StopDataTransfer
0x1110 | Incorrect AdsState in RUN state
0x1111 | Loading the device parameters is only permitted in the INIT state
0x1112 | Incorrect data length at SetDeviceState
0x1113 | AddBox not allowed in INIT state
0x1114 | Incorrect data length at AddBox
0x1115 | DeleteBox not allowed in INIT state
0x1116 | Incorrect IndexOffset at DeleteBox
0x1117 | Incorrect data length at DeleteBox
0x1118 | ReadBox only with AdsRead
0x1119 | AddCdl not allowed in INIT state
0x111A | Incorrect data length at AddCdl
0x111B | DeleteCdl not allowed in INIT state
0x111C | Incorrect IndexOffset at DeleteCdl
0x111D | Incorrect data length at DeleteCdl
0x111E | Incorrect IndexGroup at AdsWrite
0x111F | Device parameters cannot be read
Error | Description
0x1120 | Box parameters cannot be read
0x1121 | Cdl parameters cannot be read
0x1122 | DeleteBox or DeleteCdl only with AdsWrite
0x1123 | ReadBox only possible in STOP state
0x1124 | Incorrect IndexOffset at ReadBox
0x1125 | Incorrect data length at ReadBox
0x1126 | Incorrect IndexGroup at AdsRead
0x1127 | AddDeviceNotification not allowed in INIT state
0x1128 | DelDeviceNotification not allowed in INIT state
0x1129 | IndexOffset too large during reading of the device diagnostic data
0x112B | IndexOffset too large during reading of the box diagnostic data
0x112F | Insufficient memory for ReadBox response
0x113E | FC card is in a status in which the status state cannot be changed
0x1201 | AddCdl: CDL no. is too large
0x1202 | DeleteCdl only possible when CDL is stopped
0x1203 | DeleteCdl not possible as no CDL defined
0x1204 | Cycle could not be completed within the internal watchdog time
0x1301 | AddCdl: I/O access multiplier is too large
0x1302 | AddCdl: Start cycle must be smaller than I/O access multiplier
0x1303 | AddCdl: Incorrect data length for output area
0x1304 | AddCdl: Incorrect data offset for output area
0x1305 | AddCdl: Output area is already defined
0x1306 | AddCdl: Incorrect data length for input area
0x1307 | AddCdl: Incorrect data offset for input area
0x1308 | AddCdl: Input area is already defined
0x1309 | AddCdl: Incorrect area type
0x130A | AddCdl: BoxNo has not been defined with AddBox
0x130B | AddCdl: Incorrect action type
0x130C | AddCdl: Insufficient memory for poll list
0x130D | AddCdl: Insufficient memory for poll list array
0x130E | AddCdl: Insufficient memory for actions
0x130F | AddCdl: CdlNo already exists
0x1310 | DeleteCdl: CDL is not stopped
0x1311 | AddCdl: Insufficient memory for asynchronous transmit list
0x1312 | AddCdl: Insufficient memory for synchronous receive list
0x1313 | AddCdl: Insufficient memory for asynchronous receive list
0x1316 | AddCdl: Insufficient memory for synchronous receive list
0x1318 | AddCdl: Only slave action allowed
0x1319 | AddCdl: Insufficient memory for slave list
Error | Description
0x1601 | AddBox: BoxNo is too large
0x1602 | AddBox: Insufficient memory for ADS StartUp telegram
0x1604 | DeleteBox: Box is not stopped
0x1605 | AddBox: Insufficient memory for CDL telegram
0x1606 | AddBox: Number of CDL telegrams is too large
0x1607 | BoxRestart: Box is not stopped
0x1608 | BoxRestart: AdsWriteControl syntax error
0x1609 | BoxRestart: Incorrect AdsState
0x160A | Syntax error in AdsWrite to box port
0x160B | AMS CmdId is not supported by box port
0x160E | AdsReadState is not supported by box port
0x160F | AddBox: Insufficient memory for the ADS interface
0x1610 | AddBox: AMS channel is invalid
0x1611 | Error communicating with an AMS box
0x1613 | Error communicating with an AMS box: Incorrect offset
0x1614 | Error communicating with an AMS box: Data packet is too large
0x1615 | Error communicating with an AMS box: AMS command is too large
0x1616 | Error communicating with an AMS box: First data packet is too large
0x1617 | Error communicating with an AMS box: First offset is incorrect
0x1701 | AddDeviceNotification: Length of device diagnostic data to small
0x1702 | AddDeviceNotification: Length of device diagnostic data to large
0x1703 | AddDeviceNotification: Length of box diagnostic data to small
0x1704 | AddDeviceNotification: Length of box diagnostic data to large
0x1705 | AddDeviceNotification: Box is not defined
0x1706 | AddDeviceNotification: Incorrect IndexGroup
0x1707 | AddDeviceNotification: No more resources for client
0x1708 | DelDeviceNotification: Incorrect handle
0x1801 | StartFieldbus: In equidistant operation, shift time + safety time + 2*PLL sync. time must be greater than the cycle time
0x1802 | StartFieldbus: Cycle time is too large
0x1803 | StartFieldbus: Cycle time is too large
0x1804 | StartFieldbus: Shift time is too large
0x1805 | StartFieldbus: PLL sync time is too large
0x1806 | StartFieldbus: Safety time is too large
0x1807 | StartFieldbus: Cycle times shorter than 1 ms must be integral divisors of 1 ms
Error | Description
0x1A01 | Memory could not be allocated from the huge heap, because it is larger than 0x8000 bytes
0x1A02 | Memory could not be allocated from the near heap, because it is larger than 0x1000 bytes
0x1A03 | Memory could not be allocated from the huge heap, because it is 0 byte
0x1A04 | Memory could not be allocated from the near heap, because it is 0 byte
0x2001 | StartFieldbus: Initialization of the CAN controller failed
0x2002 | AddBox: Incorrect box parameter length
0x2003 | AddBox: Incorrect box number
0x2004 | AddBox: Syntax error in ADS StartUp parameters
0x2005 | AddBox: Syntax errors in PDO parameters
0x2006 | AddBox: Syntax error in data length
0x2007 | AddBox: Insufficient memory
0x2008 | AddCdl: Incorrect receive data length
0x2009 | AddCdl: Incorrect transmit data length
0x200A | AddCdl: PDO is not defined
0x200B | AddCdl: PDO Id is already defined
0x200C | AddBox: Syntax error in ADS StartUp parameters
0x200D | AddBox: Syntax error in ADS StartUp parameters
0x200E | AddBox: Emergency Id is already defined
0x200F | AddBox: Too many PDOs defined
0x2010 | AddCdl: Incorrect telegram index
0x2011 | AddBox: Too many Rx or Tx PDOs
0x2012 | AdsRead: Incorrect IndexGroup
0x2013 | AdsRead: Incorrect IndexOffset
0x2014 | AdsRead: Incorrect length
0x2015 | AdsWrite: Incorrect IndexGroup
0x2016 | AdsWrite: Incorrect IndexOffset
0x2017 | AdsWrite: Incorrect length
0x2018 | AddBox: Guarding time smaller than 10 is not possible
0x2019 | AddBox: Incorrect transmission type in CAN Layer 2 node
0x201A | AdsRead: not possible at CAN Layer 2 node
0x201B | AdsWrite: not possible at CAN Layer 2 node
0x201C | AddBox: BootUp Id is already defined
0x201D | AddBox: BoxNo 0 is not possible
0x201E | StartFieldbus: Loading the device parameters is only possible in the OFFLINE state
0x201F | StartDataTransfer: No memory for copy queue
0x2020 | ReadBox: no more memory
0x2021 | ReadBox: SDO error or timeout
0x2022 | ReadBox: SDO cannot be initialized
0x2023 | StartFieldbus: reserved device parameter not equal to 0
Error | Description
0x2101 | Insufficient memory for low-priority queues
0x2102 | Insufficient memory for low-priority queues
0x2103 | Insufficient memory at node boot-up
0x2104 | Insufficient memory at node boot-up
0x2105 | Insufficient memory at node boot-up
0x2106 | Insufficient memory at node boot-up
0x2107 | Insufficient memory at node boot-up
0x2108 | Insufficient memory at node boot-up
0x2109 | Insufficient memory at node boot-up
0x210A | Insufficient memory at node boot-up
0x210B | Insufficient memory at node boot-up
0x210C | Insufficient memory at node boot-up
0x210D | Insufficient memory at node boot-up
0x210E | Insufficient memory at node boot-up
0x210F | Insufficient memory at node boot-up
0x2110 | Insufficient memory at node boot-up
0x2111 | Insufficient memory at node boot-up
0x2112 | Insufficient memory at node boot-up
0x2113 | Insufficient memory at node boot-up
0x2114 | Insufficient memory at node boot-up
0x2301 | Insufficient memory for low-priority queues
0x2302 | Insufficient memory for low-priority queues


CANopen Trouble Shooting

Error handling and diagnostics [image] CANopen Trouble Shooting
CANopen Trouble Shooting
Error Frames
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.
Error Frames
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 error frames!
If, for instance, one node contributes unusually heavily to the bus traffic (e.g. 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.
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, recognize 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).
Testing the CAN wiring
These tests should not be carried out if the network is active: No communication should 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.
Wiring diagram for test setup
Test 3
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 drop line length 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 shield at the end of the network most remote from the power supply unit. An equalization 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 line.
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 localize 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 load 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 (e.g. faulty or incomplete CANopen implementation, unfavorable 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 (http://www.can-cia.de).


Bus Trace function

Bus Trace function
Bus Trace function
Additional information
•
FC510x as bus monitor


FC510x as bus monitor

Bus Trace function [image] FC510x as bus monitor
FC510x as bus monitor
From firmware version 1.00 and TwinCAT 2.8 (build 740), the FC5101 or FC5102 can also be used as CANopen monitor instead of master or slave.
For example, the second channel of the FC5102 can be used for this purpose, in which case the first channel continues to function as CANopen master or slave, 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 in a non-reactive manner).
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. Beckhoff offers a CANopen monitoring program (CANMON) with filter and trigger options as freeware (see Download section at http://www.beckhoff.com).
Inserting the FC510x as a CANopen Monitor
In the Append Device context menu: insert CANopen monitor
Inserting the FC510x as a 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.
Linking the FC510x with a task
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).
FCxxxx Monitor tab
FCxxxx Monitor tab
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.
Baud rate: 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 program itself (CAN-Monitor.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.
CAN Monitor - calling the options
The following window opens:
CAN Monitor - options
Device-ID: The ID that the System Manager has assigned to the FC510x monitor channel must be entered here:
Entering the device ID
Storing: The size of the ring buffer memory for the screen display (Display) and for that file 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 recognized, regardless of the data. If an identifier (ID) greater than 0x7FF (e.g. 0x800, default) is entered under Value, the filter or trigger is disabled.
Example:
The measurement is to be stopped after 250 telegrams, after bit 0 in the second data byte of a telegram with identifier 0x210 equal to 1 has been found. The following entries are to be made to achieve this:
Entering 250 telegrams
Starting the Recording
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.
Starting the recording
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:
Stopping the recording
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.
Number Time (100 µs) telegram
0 0.0638 ID: 000 Len: 2 Data: 82 00
1 0.0649 ID: 632 Len: 8 Data: 40 00 10 00 00 00 00 00
2 0.0653 ID: 601 Len: 8 Data: 40 00 10 00 00 00 00 00
3 2.0722 ID: 632 Len: 8 Data: 80 00 00 00 00 00 04 05
4 2.0725 ID: 601 Len: 8 Data: 80 00 00 00 00 00 04 05
5 2.2686 ID: 732 Len: 1 Data: 00
6 2.7440 ID: 701 Len: 1 Data: 00
7 4.0802 ID: 632 Len: 8 Data: 40 00 10 00 00 00 00 00
8 4.0806 ID: 601 Len: 8 Data: 40 00 10 00 00 00 00 00
9 4.0813 ID: 5b2 Len: 8 Data: 43 00 10 00 91 01 02 00
10 4.0823 ID: 632 Len: 8 Data: 40 18 10 01 00 00 00 00
11 4.0826 ID: 581 Len: 8 Data: 43 00 10 00 91 01 07 00
12 4.0835 ID: 601 Len: 8 Data: 40 18 10 01 00 00 00 00
13 4.0838 ID: 5b2 Len: 8 Data: 43 18 10 01 02 00 00 00
14 4.0848 ID: 632 Len: 8 Data: 23 00 14 01 32 02 00 00
15 4.0853 ID: 581 Len: 8 Data: 43 18 10 01 02 00 00 00
16 4.0863 ID: 601 Len: 8 Data: 23 00 18 01 81 01 00 00


Appendix

Appendix
Appendix
Additional information
•
CAN Identifier List
•
Approvals
•
Bibliography
•
List of Abbreviations
•
Support and Service


CAN Identifier List

Appendix [image] CAN Identifier List
CAN Identifier List
The list provided here should assist in identifying and assigning CANopen messages. All the identifiers allocated by the CANopen default identifier allocation are listed, as well as the manufacturer-specific default identifiers issued by BECKHOFF via object 0x5500 (only to be used in networks with node addresses less than 64).
The following values can be used as search aids and "entry points" in the extensive identifier table in the *chm edition of the documentation:
Decimal: 400, 500, 600, 700, 800, 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, 1900
Hexadecimal: 0x181, 0x1C1, 0x201, 0x301, 0x401, 0x501, 0x601, 0x701
The identifier distribution via object 0x5500 follows this pattern:
Object | Resulting COB ID (dec) | Resulting COB ID (hex)
Emergency | 129 to 191 [255] | 0x81 to 0xBF [0xFF]
TxPDO1 | 385 to 447 [511] | 0x181 to 0x1BF [0x1FF]
RxPDO1 | 513 to 575 [639] | 0x201 to 0x23F [0x27F]
TxPDO2 | 641 to 676 [767] | 0x281 to 0x2BF [0x2FF]
RxPDO2 | 769 to 831 [895] | 0x301 to 0x33F [0x37F]
TxDPO3 | 897 to 959 [1023] | 0x381 to 0x3BF [0x3FF]
RxPDO3 | 1025 to 1087 [1151] | 0x401 to 0x43F [0x47F]
TxPDO4 | 1153 to 1215 [1279] | 0x481 to 0x4BF [0x4FF]
RxPDO4 | 1281 to 1343 [1407] | 0x501 to 0x53F [0x57F]
TxPDO5 | 1665 to 1727 | 0x681 to 0x6BF
RxPDO5 | 1921 to 1983 | 0x781 to 0x7BF
TxPDO6 | 449 to 511 | 0x1C1 to 0x1FF
RxPDO6 | 577 to 639 | 0x241 to 0x27F
TxDPO7 | 705 to 767 | 0x2C1 to 0x2FF
RxPDO7 | 833 to 895 | 0x341 to 0x37F
TxPDO8 | 961 to 1023 | 0x3C1 to 0x3FF
RxPDO8 | 1089 to 1151 | 0x441 to 0x47F
TxPDO9 | 1217 to 1279 | 0x4C1 to 0x4FF
RxPDO9 | 1345 to 1407 | 0x541 to 0x57F
TxDPO10 | 1473 to 1535 | 0x5C1 to 0x5FF
RxPDO10 | 1601 to 1663 | 0x641 to 0x67F
TxPDO11 | 1729 to 1791 | 0x6C1 to 0x6FF
RxPDO11 | 1857 to 1919 | 0x741 to 0x77F
SDO (Tx) | 1409 to 1471 [1535] | 0x581 to 0x5BF [0x5FF]
SDO (Rx) | 1537 to 1599 [1663] | 0x601 to 0x63F [0x67F]
Guarding / Heartbeat/ Bootup | 1793 to 1855 [1919] | 0x701 to 0x73F [0x77F]
Identifier List
Identifiers marked with * are given manufacturer-specific assignments on the Bus Couplers after writing index 0x5500
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
0 | 0x00 | NMT | 149 | 0x95 | EMCY Nd.21 | 171 | 0xAB | EMCY Nd.43
128 | 0x80 | SYNC | 150 | 0x96 | EMCY Nd.22 | 172 | 0xAC | EMCY Nd.44
129 | 0x81 | EMCY Nd.1 | 151 | 0x97 | EMCY Nd.23 | 173 | 0xAD | EMCY Nd.45
130 | 0x82 | EMCY Nd.2 | 152 | 0x98 | EMCY Nd.24 | 174 | 0xAE | EMCY Nd.46
131 | 0x83 | EMCY Nd.3 | 153 | 0x99 | EMCY Nd.25 | 175 | 0xAF | EMCY Nd.47
132 | 0x84 | EMCY Nd.4 | 154 | 0x9A | EMCY Nd.26 | 176 | 0xB0 | EMCY Nd.48
133 | 0x85 | EMCY Nd.5 | 155 | 0x9B | EMCY Nd.27 | 177 | 0xB1 | EMCY Nd.49
134 | 0x86 | EMCY Nd.6 | 156 | 0x9C | EMCY Nd.28 | 178 | 0xB2 | EMCY Nd.50
135 | 0x87 | EMCY Nd.7 | 157 | 0x9D | EMCY Nd.29 | 179 | 0xB3 | EMCY Nd.51
136 | 0x88 | EMCY Nd.8 | 158 | 0x9E | EMCY Nd.30 | 180 | 0xB4 | EMCY Nd.52
137 | 0x89 | EMCY Nd.9 | 159 | 0x9F | EMCY Nd.31 | 181 | 0xB5 | EMCY Nd.53
138 | 0x8A | EMCY Nd.10 | 160 | 0xA0 | EMCY Nd.32 | 182 | 0xB6 | EMCY Nd.54
139 | 0x8B | EMCY Nd.11 | 161 | 0xA1 | EMCY Nd.33 | 183 | 0xB7 | EMCY Nd.55
140 | 0x8C | EMCY Nd.12 | 162 | 0xA2 | EMCY Nd.34 | 184 | 0xB8 | EMCY Nd.56
141 | 0x8D | EMCY Nd.13 | 163 | 0xA3 | EMCY Nd.35 | 185 | 0xB9 | EMCY Nd.57
142 | 0x8E | EMCY Nd.14 | 164 | 0xA4 | EMCY Nd.36 | 186 | 0xBA | EMCY Nd.58
143 | 0x8F | EMCY Nd.15 | 165 | 0xA5 | EMCY Nd.37 | 187 | 0xBB | EMCY Nd.59
144 | 0x90 | EMCY Nd.16 | 166 | 0xA6 | EMCY Nd.38 | 188 | 0xBC | EMCY Nd.60
145 | 0x91 | EMCY Nd.17 | 167 | 0xA7 | EMCY Nd.39 | 189 | 0xBD | EMCY Nd.61
146 | 0x92 | EMCY Nd.18 | 168 | 0xA8 | EMCY Nd.40 | 190 | 0xBE | EMCY Nd.62
147 | 0x93 | EMCY Nd.19 | 169 | 0xA9 | EMCY Nd.41 | 191 | 0xBF | EMCY Nd.63
148 | 0x94 | EMCY Nd.20 | 170 | 0xAA | EMCY Nd.42 |  |  |
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
385 | 0x181 | TxPDO1, DI, Nd.1 | 406 | 0x196 | TxPDO1, DI, Nd.22 | 427 | 0x1AB | TxPDO1, DI, Nd.43
386 | 0x182 | TxPDO1, DI, Nd.2 | 407 | 0x197 | TxPDO1, DI, Nd.23 | 428 | 0x1AC | TxPDO1, DI, Nd.44
387 | 0x183 | TxPDO1, DI, Nd.3 | 408 | 0x198 | TxPDO1, DI, Nd.24 | 429 | 0x1AD | TxPDO1, DI, Nd.45
388 | 0x184 | TxPDO1, DI, Nd.4 | 409 | 0x199 | TxPDO1, DI, Nd.25 | 430 | 0x1AE | TxPDO1, DI, Nd.46
389 | 0x185 | TxPDO1, DI, Nd.5 | 410 | 0x19A | TxPDO1, DI, Nd.26 | 431 | 0x1AF | TxPDO1, DI, Nd.47
390 | 0x186 | TxPDO1, DI, Nd.6 | 411 | 0x19B | TxPDO1, DI, Nd.27 | 432 | 0x1B0 | TxPDO1, DI, Nd.48
391 | 0x187 | TxPDO1, DI, Nd.7 | 412 | 0x19C | TxPDO1, DI, Nd.28 | 433 | 0x1B1 | TxPDO1, DI, Nd.49
392 | 0x188 | TxPDO1, DI, Nd.8 | 413 | 0x19D | TxPDO1, DI, Nd.29 | 434 | 0x1B2 | TxPDO1, DI, Nd.50
393 | 0x189 | TxPDO1, DI, Nd.9 | 414 | 0x19E | TxPDO1, DI, Nd.30 | 435 | 0x1B3 | TxPDO1, DI, Nd.51
394 | 0x18A | TxPDO1, DI, Nd.10 | 415 | 0x19F | TxPDO1, DI, Nd.31 | 436 | 0x1B4 | TxPDO1, DI, Nd.52
395 | 0x18B | TxPDO1, DI, Nd.11 | 416 | 0x1A0 | TxPDO1, DI, Nd.32 | 437 | 0x1B5 | TxPDO1, DI, Nd.53
396 | 0x18C | TxPDO1, DI, Nd.12 | 417 | 0x1A1 | TxPDO1, DI, Nd.33 | 438 | 0x1B6 | TxPDO1, DI, Nd.54
397 | 0x18D | TxPDO1, DI, Nd.13 | 418 | 0x1A2 | TxPDO1, DI, Nd.34 | 439 | 0x1B7 | TxPDO1, DI, Nd.55
398 | 0x18E | TxPDO1, DI, Nd.14 | 419 | 0x1A3 | TxPDO1, DI, Nd.35 | 440 | 0x1B8 | TxPDO1, DI, Nd.56
399 | 0x18F | TxPDO1, DI, Nd.15 | 420 | 0x1A4 | TxPDO1, DI, Nd.36 | 441 | 0x1B9 | TxPDO1, DI, Nd.57
400 | 0x190 | TxPDO1, DI, Nd.16 | 421 | 0x1A5 | TxPDO1, DI, Nd.37 | 442 | 0x1BA | TxPDO1, DI, Nd.58
401 | 0x191 | TxPDO1, DI, Nd.17 | 422 | 0x1A6 | TxPDO1, DI, Nd.38 | 443 | 0x1BB | TxPDO1, DI, Nd.59
402 | 0x192 | TxPDO1, DI, Nd.18 | 423 | 0x1A7 | TxPDO1, DI, Nd.39 | 444 | 0x1BC | TxPDO1, DI, Nd.60
403 | 0x193 | TxPDO1, DI, Nd.19 | 424 | 0x1A8 | TxPDO1, DI, Nd.40 | 445 | 0x1BD | TxPDO1, DI, Nd.61
404 | 0x194 | TxPDO1, DI, Nd.20 | 425 | 0x1A9 | TxPDO1, DI, Nd.41 | 446 | 0x1BE | TxPDO1, DI, Nd.62
405 | 0x195 | TxPDO1, DI, Nd.21 | 426 | 0x1AA | TxPDO1, DI, Nd.42 | 447 | 0x1BF | TxPDO1, DI, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
513 | 0x201 | RxPDO1, DO, Nd.1 | 534 | 0x216 | RxPDO1, DO, Nd.22 | 555 | 0x22B | RxPDO1, DO, Nd.43
514 | 0x202 | RxPDO1, DO, Nd.2 | 535 | 0x217 | RxPDO1, DO, Nd.23 | 556 | 0x22C | RxPDO1, DO, Nd.44
515 | 0x203 | RxPDO1, DO, Nd.3 | 536 | 0x218 | RxPDO1, DO, Nd.24 | 557 | 0x22D | RxPDO1, DO, Nd.45
516 | 0x204 | RxPDO1, DO, Nd.4 | 537 | 0x219 | RxPDO1, DO, Nd.25 | 558 | 0x22E | RxPDO1, DO, Nd.46
517 | 0x205 | RxPDO1, DO, Nd.5 | 538 | 0x21A | RxPDO1, DO, Nd.26 | 559 | 0x22F | RxPDO1, DO, Nd.47
518 | 0x206 | RxPDO1, DO, Nd.6 | 539 | 0x21B | RxPDO1, DO, Nd.27 | 560 | 0x230 | RxPDO1, DO, Nd.48
519 | 0x207 | RxPDO1, DO, Nd.7 | 540 | 0x21C | RxPDO1, DO, Nd.28 | 561 | 0x231 | RxPDO1, DO, Nd.49
520 | 0x208 | RxPDO1, DO, Nd.8 | 541 | 0x21D | RxPDO1, DO, Nd.29 | 562 | 0x232 | RxPDO1, DO, Nd.50
521 | 0x209 | RxPDO1, DO, Nd.9 | 542 | 0x21E | RxPDO1, DO, Nd.30 | 563 | 0x233 | RxPDO1, DO, Nd.51
522 | 0x20A | RxPDO1, DO, Nd.10 | 543 | 0x21F | RxPDO1, DO, Nd.31 | 564 | 0x234 | RxPDO1, DO, Nd.52
523 | 0x20B | RxPDO1, DO, Nd.11 | 544 | 0x220 | RxPDO1, DO, Nd.32 | 565 | 0x235 | RxPDO1, DO, Nd.53
524 | 0x20C | RxPDO1, DO, Nd.12 | 545 | 0x221 | RxPDO1, DO, Nd.33 | 566 | 0x236 | RxPDO1, DO, Nd.54
525 | 0x20D | RxPDO1, DO, Nd.13 | 546 | 0x222 | RxPDO1, DO, Nd.34 | 567 | 0x237 | RxPDO1, DO, Nd.55
526 | 0x20E | RxPDO1, DO, Nd.14 | 547 | 0x223 | RxPDO1, DO, Nd.35 | 568 | 0x238 | RxPDO1, DO, Nd.56
527 | 0x20F | RxPDO1, DO, Nd.15 | 548 | 0x224 | RxPDO1, DO, Nd.36 | 569 | 0x239 | RxPDO1, DO, Nd.57
528 | 0x210 | RxPDO1, DO, Nd.16 | 549 | 0x225 | RxPDO1, DO, Nd.37 | 570 | 0x23A | RxPDO1, DO, Nd.58
529 | 0x211 | RxPDO1, DO, Nd.17 | 550 | 0x226 | RxPDO1, DO, Nd.38 | 571 | 0x23B | RxPDO1, DO, Nd.59
530 | 0x212 | RxPDO1, DO, Nd.18 | 551 | 0x227 | RxPDO1, DO, Nd.39 | 572 | 0x23C | RxPDO1, DO, Nd.60
531 | 0x213 | RxPDO1, DO, Nd.19 | 552 | 0x228 | RxPDO1, DO, Nd.40 | 573 | 0x23D | RxPDO1, DO, Nd.61
532 | 0x214 | RxPDO1, DO, Nd.20 | 553 | 0x229 | RxPDO1, DO, Nd.41 | 574 | 0x23E | RxPDO1, DO, Nd.62
533 | 0x215 | RxPDO1, DO, Nd.21 | 554 | 0x22A | RxPDO1, DO, Nd.42 | 575 | 0x23F | RxPDO1, DO, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
641 | 0x281 | TxPDO2, AI, Nd.1 | 662 | 0x296 | TxPDO2, AI, Nd.22 | 683 | 0x2AB | TxPDO2, AI, Nd.43
642 | 0x282 | TxPDO2, AI, Nd.2 | 663 | 0x297 | TxPDO2, AI, Nd.23 | 684 | 0x2AC | TxPDO2, AI, Nd.44
643 | 0x283 | TxPDO2, AI, Nd.3 | 664 | 0x298 | TxPDO2, AI, Nd.24 | 685 | 0x2AD | TxPDO2, AI, Nd.45
644 | 0x284 | TxPDO2, AI, Nd.4 | 665 | 0x299 | TxPDO2, AI, Nd.25 | 686 | 0x2AE | TxPDO2, AI, Nd.46
645 | 0x285 | TxPDO2, AI, Nd.5 | 666 | 0x29A | TxPDO2, AI, Nd.26 | 687 | 0x2AF | TxPDO2, AI, Nd.47
646 | 0x286 | TxPDO2, AI, Nd.6 | 667 | 0x29B | TxPDO2, AI, Nd.27 | 688 | 0x2B0 | TxPDO2, AI, Nd.48
647 | 0x287 | TxPDO2, AI, Nd.7 | 668 | 0x29C | TxPDO2, AI, Nd.28 | 689 | 0x2B1 | TxPDO2, AI, Nd.49
648 | 0x288 | TxPDO2, AI, Nd.8 | 669 | 0x29D | TxPDO2, AI, Nd.29 | 690 | 0x2B2 | TxPDO2, AI, Nd.50
649 | 0x289 | TxPDO2, AI, Nd.9 | 670 | 0x29E | TxPDO2, AI, Nd.30 | 691 | 0x2B3 | TxPDO2, AI, Nd.51
650 | 0x28A | TxPDO2, AI, Nd.10 | 671 | 0x29F | TxPDO2, AI, Nd.31 | 692 | 0x2B4 | TxPDO2, AI, Nd.52
651 | 0x28B | TxPDO2, AI, Nd.11 | 672 | 0x2A0 | TxPDO2, AI, Nd.32 | 693 | 0x2B5 | TxPDO2, AI, Nd.53
652 | 0x28C | TxPDO2, AI, Nd.12 | 673 | 0x2A1 | TxPDO2, AI, Nd.33 | 694 | 0x2B6 | TxPDO2, AI, Nd.54
653 | 0x28D | TxPDO2, AI, Nd.13 | 674 | 0x2A2 | TxPDO2, AI, Nd.34 | 695 | 0x2B7 | TxPDO2, AI, Nd.55
654 | 0x28E | TxPDO2, AI, Nd.14 | 675 | 0x2A3 | TxPDO2, AI, Nd.35 | 696 | 0x2B8 | TxPDO2, AI, Nd.56
655 | 0x28F | TxPDO2, AI, Nd.15 | 676 | 0x2A4 | TxPDO2, AI, Nd.36 | 697 | 0x2B9 | TxPDO2, AI, Nd.57
656 | 0x290 | TxPDO2, AI, Nd.16 | 677 | 0x2A5 | TxPDO2, AI, Nd.37 | 698 | 0x2BA | TxPDO2, AI, Nd.58
657 | 0x291 | TxPDO2, AI, Nd.17 | 678 | 0x2A6 | TxPDO2, AI, Nd.38 | 699 | 0x2BB | TxPDO2, AI, Nd.59
658 | 0x292 | TxPDO2, AI, Nd.18 | 679 | 0x2A7 | TxPDO2, AI, Nd.39 | 700 | 0x2BC | TxPDO2, AI, Nd.60
659 | 0x293 | TxPDO2, AI, Nd.19 | 680 | 0x2A8 | TxPDO2, AI, Nd.40 | 701 | 0x2BD | TxPDO2, AI, Nd.61
660 | 0x294 | TxPDO2, AI, Nd.20 | 681 | 0x2A9 | TxPDO2, AI, Nd.41 | 702 | 0x2BE | TxPDO2, AI, Nd.62
661 | 0x295 | TxPDO2, AI, Nd.21 | 682 | 0x2AA | TxPDO2, AI, Nd.42 | 703 | 0x2BF | TxPDO2, AI, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
769 | 0x301 | RxPDO2, AO, Nd.1 | 790 | 0x316 | RxPDO2, AO, Nd.22 | 811 | 0x32B | RxPDO2, AO, Nd.43
770 | 0x302 | RxPDO2, AO, Nd.2 | 791 | 0x317 | RxPDO2, AO, Nd.23 | 812 | 0x32C | RxPDO2, AO, Nd.44
771 | 0x303 | RxPDO2, AO, Nd.3 | 792 | 0x318 | RxPDO2, AO, Nd.24 | 813 | 0x32D | RxPDO2, AO, Nd.45
772 | 0x304 | RxPDO2, AO, Nd.4 | 793 | 0x319 | RxPDO2, AO, Nd.25 | 814 | 0x32E | RxPDO2, AO, Nd.46
773 | 0x305 | RxPDO2, AO, Nd.5 | 794 | 0x31A | RxPDO2, AO, Nd.26 | 815 | 0x32F | RxPDO2, AO, Nd.47
774 | 0x306 | RxPDO2, AO, Nd.6 | 795 | 0x31B | RxPDO2, AO, Nd.27 | 816 | 0x330 | RxPDO2, AO, Nd.48
775 | 0x307 | RxPDO2, AO, Nd.7 | 796 | 0x31C | RxPDO2, AO, Nd.28 | 817 | 0x331 | RxPDO2, AO, Nd.49
776 | 0x308 | RxPDO2, AO, Nd.8 | 797 | 0x31D | RxPDO2, AO, Nd.29 | 818 | 0x332 | RxPDO2, AO, Nd.50
777 | 0x309 | RxPDO2, AO, Nd.9 | 798 | 0x31E | RxPDO2, AO, Nd.30 | 819 | 0x333 | RxPDO2, AO, Nd.51
778 | 0x30A | RxPDO2, AO, Nd.10 | 799 | 0x31F | RxPDO2, AO, Nd.31 | 820 | 0x334 | RxPDO2, AO, Nd.52
779 | 0x30B | RxPDO2, AO, Nd.11 | 800 | 0x320 | RxPDO2, AO, Nd.32 | 821 | 0x335 | RxPDO2, AO, Nd.53
780 | 0x30C | RxPDO2, AO, Nd.12 | 801 | 0x321 | RxPDO2, AO, Nd.33 | 822 | 0x336 | RxPDO2, AO, Nd.54
781 | 0x30D | RxPDO2, AO, Nd.13 | 802 | 0x322 | RxPDO2, AO, Nd.34 | 823 | 0x337 | RxPDO2, AO, Nd.55
782 | 0x30E | RxPDO2, AO, Nd.14 | 803 | 0x323 | RxPDO2, AO, Nd.35 | 824 | 0x338 | RxPDO2, AO, Nd.56
783 | 0x30F | RxPDO2, AO, Nd.15 | 804 | 0x324 | RxPDO2, AO, Nd.36 | 825 | 0x339 | RxPDO2, AO, Nd.57
784 | 0x310 | RxPDO2, AO, Nd.16 | 805 | 0x325 | RxPDO2, AO, Nd.37 | 826 | 0x33A | RxPDO2, AO, Nd.58
785 | 0x311 | RxPDO2, AO, Nd.17 | 806 | 0x326 | RxPDO2, AO, Nd.38 | 827 | 0x33B | RxPDO2, AO, Nd.59
786 | 0x312 | RxPDO2, AO, Nd.18 | 807 | 0x327 | RxPDO2, AO, Nd.39 | 828 | 0x33C | RxPDO2, AO, Nd.60
787 | 0x313 | RxPDO2, AO, Nd.19 | 808 | 0x328 | RxPDO2, AO, Nd.40 | 829 | 0x33D | RxPDO2, AO, Nd.61
788 | 0x314 | RxPDO2, AO, Nd.20 | 809 | 0x329 | RxPDO2, AO, Nd.41 | 830 | 0x33E | RxPDO2, AO, Nd.62
789 | 0x315 | RxPDO2, AO, Nd.21 | 810 | 0x32A | RxPDO2, AO, Nd.42 | 831 | 0x33F | RxPDO2, AO, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
897 | 0x381 | TxPDO3*, Nd.1 | 918 | 0x396 | TxPDO3*, Nd.22 | 939 | 0x3AB | TxPDO3*, Nd.43
898 | 0x382 | TxPDO3*, Nd.2 | 919 | 0x397 | TxPDO3*, Nd.23 | 940 | 0x3AC | TxPDO3*, Nd.44
899 | 0x383 | TxPDO3*, Nd.3 | 920 | 0x398 | TxPDO3*, Nd.24 | 941 | 0x3AD | TxPDO3*, Nd.45
900 | 0x384 | TxPDO3*, Nd.4 | 921 | 0x399 | TxPDO3*, Nd.25 | 942 | 0x3AE | TxPDO3*, Nd.46
901 | 0x385 | TxPDO3*, Nd.5 | 922 | 0x39A | TxPDO3*, Nd.26 | 943 | 0x3AF | TxPDO3*, Nd.47
902 | 0x386 | TxPDO3*, Nd.6 | 923 | 0x39B | TxPDO3*, Nd.27 | 944 | 0x3B0 | TxPDO3*, Nd.48
903 | 0x387 | TxPDO3*, Nd.7 | 924 | 0x39C | TxPDO3*, Nd.28 | 945 | 0x3B1 | TxPDO3*, Nd.49
904 | 0x388 | TxPDO3*, Nd.8 | 925 | 0x39D | TxPDO3*, Nd.29 | 946 | 0x3B2 | TxPDO3*, Nd.50
905 | 0x389 | TxPDO3*, Nd.9 | 926 | 0x39E | TxPDO3*, Nd.30 | 947 | 0x3B3 | TxPDO3*, Nd.51
906 | 0x38A | TxPDO3*, Nd.10 | 927 | 0x39F | TxPDO3*, Nd.31 | 948 | 0x3B4 | TxPDO3*, Nd.52
907 | 0x38B | TxPDO3*, Nd.11 | 928 | 0x3A0 | TxPDO3*, Nd.32 | 949 | 0x3B5 | TxPDO3*, Nd.53
908 | 0x38C | TxPDO3*, Nd.12 | 929 | 0x3A1 | TxPDO3*, Nd.33 | 950 | 0x3B6 | TxPDO3*, Nd.54
909 | 0x38D | TxPDO3*, Nd.13 | 930 | 0x3A2 | TxPDO3*, Nd.34 | 951 | 0x3B7 | TxPDO3*, Nd.55
910 | 0x38E | TxPDO3*, Nd.14 | 931 | 0x3A3 | TxPDO3*, Nd.35 | 952 | 0x3B8 | TxPDO3*, Nd.56
911 | 0x38F | TxPDO3*, Nd.15 | 932 | 0x3A4 | TxPDO3*, Nd.36 | 953 | 0x3B9 | TxPDO3*, Nd.57
912 | 0x390 | TxPDO3*, Nd.16 | 933 | 0x3A5 | TxPDO3*, Nd.37 | 954 | 0x3BA | TxPDO3*, Nd.58
913 | 0x391 | TxPDO3*, Nd.17 | 934 | 0x3A6 | TxPDO3*, Nd.38 | 955 | 0x3BB | TxPDO3*, Nd.59
914 | 0x392 | TxPDO3*, Nd.18 | 935 | 0x3A7 | TxPDO3*, Nd.39 | 956 | 0x3BC | TxPDO3*, Nd.60
915 | 0x393 | TxPDO3*, Nd.19 | 936 | 0x3A8 | TxPDO3*, Nd.40 | 957 | 0x3BD | TxPDO3*, Nd.61
916 | 0x394 | TxPDO3*, Nd.20 | 937 | 0x3A9 | TxPDO3*, Nd.41 | 958 | 0x3BE | TxPDO3*, Nd.62
917 | 0x395 | TxPDO3*, Nd.21 | 938 | 0x3AA | TxPDO3*, Nd.42 | 959 | 0x3BF | TxPDO3*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1025 | 0x401 | RxPDO3*, Nd.1 | 1046 | 0x416 | RxPDO3*, Nd.22 | 1067 | 0x42B | RxPDO3*, Nd.43
1026 | 0x402 | RxPDO3*, Nd.2 | 1047 | 0x417 | RxPDO3*, Nd.23 | 1068 | 0x42C | RxPDO3*, Nd.44
1027 | 0x403 | RxPDO3*, Nd.3 | 1048 | 0x418 | RxPDO3*, Nd.24 | 1069 | 0x42D | RxPDO3*, Nd.45
1028 | 0x404 | RxPDO3*, Nd.4 | 1049 | 0x419 | RxPDO3*, Nd.25 | 1070 | 0x42E | RxPDO3*, Nd.46
1029 | 0x405 | RxPDO3*, Nd.5 | 1050 | 0x41A | RxPDO3*, Nd.26 | 1071 | 0x42F | RxPDO3*, Nd.47
1030 | 0x406 | RxPDO3*, Nd.6 | 1051 | 0x41B | RxPDO3*, Nd.27 | 1072 | 0x430 | RxPDO3*, Nd.48
1031 | 0x407 | RxPDO3*, Nd.7 | 1052 | 0x41C | RxPDO3*, Nd.28 | 1073 | 0x431 | RxPDO3*, Nd.49
1032 | 0x408 | RxPDO3*, Nd.8 | 1053 | 0x41D | RxPDO3*, Nd.29 | 1074 | 0x432 | RxPDO3*, Nd.50
1033 | 0x409 | RxPDO3*, Nd.9 | 1054 | 0x41E | RxPDO3*, Nd.30 | 1075 | 0x433 | RxPDO3*, Nd.51
1034 | 0x40A | RxPDO3*, Nd.10 | 1055 | 0x41F | RxPDO3*, Nd.31 | 1076 | 0x434 | RxPDO3*, Nd.52
1035 | 0x40B | RxPDO3*, Nd.11 | 1056 | 0x420 | RxPDO3*, Nd.32 | 1077 | 0x435 | RxPDO3*, Nd.53
1036 | 0x40C | RxPDO3*, Nd.12 | 1057 | 0x421 | RxPDO3*, Nd.33 | 1078 | 0x436 | RxPDO3*, Nd.54
1037 | 0x40D | RxPDO3*, Nd.13 | 1058 | 0x422 | RxPDO3*, Nd.34 | 1079 | 0x437 | RxPDO3*, Nd.55
1038 | 0x40E | RxPDO3*, Nd.14 | 1059 | 0x423 | RxPDO3*, Nd.35 | 1080 | 0x438 | RxPDO3*, Nd.56
1039 | 0x40F | RxPDO3*, Nd.15 | 1060 | 0x424 | RxPDO3*, Nd.36 | 1081 | 0x439 | RxPDO3*, Nd.57
1040 | 0x410 | RxPDO3*, Nd.16 | 1061 | 0x425 | RxPDO3*, Nd.37 | 1082 | 0x43A | RxPDO3*, Nd.58
1041 | 0x411 | RxPDO3*, Nd.17 | 1062 | 0x426 | RxPDO3*, Nd.38 | 1083 | 0x43B | RxPDO3*, Nd.59
1042 | 0x412 | RxPDO3*, Nd.18 | 1063 | 0x427 | RxPDO3*, Nd.39 | 1084 | 0x43C | RxPDO3*, Nd.60
1043 | 0x413 | RxPDO3*, Nd.19 | 1064 | 0x428 | RxPDO3*, Nd.40 | 1085 | 0x43D | RxPDO3*, Nd.61
1044 | 0x414 | RxPDO3*, Nd.20 | 1065 | 0x429 | RxPDO3*, Nd.41 | 1086 | 0x43E | RxPDO3*, Nd.62
1045 | 0x415 | RxPDO3*, Nd.21 | 1066 | 0x42A | RxPDO3*, Nd.42 | 1087 | 0x43F | RxPDO3*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1153 | 0x481 | TxPDO4*, Nd.1 | 1174 | 0x496 | TxPDO4*, Nd.22 | 1195 | 0x4AB | TxPDO4*, Nd.43
1154 | 0x482 | TxPDO4*, Nd.2 | 1175 | 0x497 | TxPDO4*, Nd.23 | 1196 | 0x4AC | TxPDO4*, Nd.44
1155 | 0x483 | TxPDO4*, Nd.3 | 1176 | 0x498 | TxPDO4*, Nd.24 | 1197 | 0x4AD | TxPDO4*, Nd.45
1156 | 0x484 | TxPDO4*, Nd.4 | 1177 | 0x499 | TxPDO4*, Nd.25 | 1198 | 0x4AE | TxPDO4*, Nd.46
1157 | 0x485 | TxPDO4*, Nd.5 | 1178 | 0x49A | TxPDO4*, Nd.26 | 1199 | 0x4AF | TxPDO4*, Nd.47
1158 | 0x486 | TxPDO4*, Nd.6 | 1179 | 0x49B | TxPDO4*, Nd.27 | 1200 | 0x4B0 | TxPDO4*, Nd.48
1159 | 0x487 | TxPDO4*, Nd.7 | 1180 | 0x49C | TxPDO4*, Nd.28 | 1201 | 0x4B1 | TxPDO4*, Nd.49
1160 | 0x488 | TxPDO4*, Nd.8 | 1181 | 0x49D | TxPDO4*, Nd.29 | 1202 | 0x4B2 | TxPDO4*, Nd.50
1161 | 0x489 | TxPDO4*, Nd.9 | 1182 | 0x49E | TxPDO4*, Nd.30 | 1203 | 0x4B3 | TxPDO4*, Nd.51
1162 | 0x48A | TxPDO4*, Nd.10 | 1183 | 0x49F | TxPDO4*, Nd.31 | 1204 | 0x4B4 | TxPDO4*, Nd.52
1163 | 0x48B | TxPDO4*, Nd.11 | 1184 | 0x4A0 | TxPDO4*, Nd.32 | 1205 | 0x4B5 | TxPDO4*, Nd.53
1164 | 0x48C | TxPDO4*, Nd.12 | 1185 | 0x4A1 | TxPDO4*, Nd.33 | 1206 | 0x4B6 | TxPDO4*, Nd.54
1165 | 0x48D | TxPDO4*, Nd.13 | 1186 | 0x4A2 | TxPDO4*, Nd.34 | 1207 | 0x4B7 | TxPDO4*, Nd.55
1166 | 0x48E | TxPDO4*, Nd.14 | 1187 | 0x4A3 | TxPDO4*, Nd.35 | 1208 | 0x4B8 | TxPDO4*, Nd.56
1167 | 0x48F | TxPDO4*, Nd.15 | 1188 | 0x4A4 | TxPDO4*, Nd.36 | 1209 | 0x4B9 | TxPDO4*, Nd.57
1168 | 0x490 | TxPDO4*, Nd.16 | 1189 | 0x4A5 | TxPDO4*, Nd.37 | 1210 | 0x4BA | TxPDO4*, Nd.58
1169 | 0x491 | TxPDO4*, Nd.17 | 1190 | 0x4A6 | TxPDO4*, Nd.48 | 1211 | 0x4BB | TxPDO4*, Nd.59
1170 | 0x492 | TxPDO4*, Nd.18 | 1191 | 0x4A7 | TxPDO4*, Nd.49 | 1212 | 0x4BC | TxPDO4*, Nd.60
1171 | 0x493 | TxPDO4*, Nd.19 | 1192 | 0x4A8 | TxPDO4*, Nd.40 | 1213 | 0x4BD | TxPDO4*, Nd.61
1172 | 0x494 | TxPDO4*, Nd.20 | 1193 | 0x4A9 | TxPDO4*, Nd.41 | 1214 | 0x4BE | TxPDO4*, Nd.62
1173 | 0x495 | TxPDO4*, Nd.21 | 1194 | 0x4AA | TxPDO4*, Nd.42 | 1215 | 0x4BF | TxPDO4*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1281 | 0x501 | RxPDO4*, Nd.1 | 1302 | 0x516 | RxPDO4*, Nd.22 | 1323 | 0x52B | RxPDO4*, Nd.43
1282 | 0x502 | RxPDO4*, Nd.2 | 1303 | 0x517 | RxPDO4*, Nd.23 | 1324 | 0x52C | RxPDO4*, Nd.44
1283 | 0x503 | RxPDO4*, Nd.3 | 1304 | 0x518 | RxPDO4*, Nd.24 | 1325 | 0x52D | RxPDO4*, Nd.45
1284 | 0x504 | RxPDO4*, Nd.4 | 1305 | 0x519 | RxPDO4*, Nd.25 | 1326 | 0x52E | RxPDO4*, Nd.46
1285 | 0x505 | RxPDO4*, Nd.5 | 1306 | 0x51A | RxPDO4*, Nd.26 | 1327 | 0x52F | RxPDO4*, Nd.47
1286 | 0x506 | RxPDO4*, Nd.6 | 1307 | 0x51B | RxPDO4*, Nd.27 | 1328 | 0x530 | RxPDO4*, Nd.48
1287 | 0x507 | RxPDO4*, Nd.7 | 1308 | 0x51C | RxPDO4*, Nd.28 | 1329 | 0x531 | RxPDO4*, Nd.49
1288 | 0x508 | RxPDO4*, Nd.8 | 1309 | 0x51D | RxPDO4*, Nd.29 | 1330 | 0x532 | RxPDO4*, Nd.50
1289 | 0x509 | RxPDO4*, Nd.9 | 1310 | 0x51E | RxPDO4*, Nd.30 | 1331 | 0x533 | RxPDO4*, Nd.51
1290 | 0x50A | RxPDO4*, Nd.10 | 1311 | 0x51F | RxPDO4*, Nd.31 | 1332 | 0x534 | RxPDO4*, Nd.52
1291 | 0x50B | RxPDO4*, Nd.11 | 1312 | 0x520 | RxPDO4*, Nd.32 | 1333 | 0x535 | RxPDO4*, Nd.53
1292 | 0x50C | RxPDO4*, Nd.12 | 1313 | 0x521 | RxPDO4*, Nd.33 | 1334 | 0x536 | RxPDO4*, Nd.54
1293 | 0x50D | RxPDO4*, Nd.13 | 1314 | 0x522 | RxPDO4*, Nd.34 | 1335 | 0x537 | RxPDO4*, Nd.55
1294 | 0x50E | RxPDO4*, Nd.14 | 1315 | 0x523 | RxPDO4*, Nd.35 | 1336 | 0x538 | RxPDO4*, Nd.56
1295 | 0x50F | RxPDO4*, Nd.15 | 1316 | 0x524 | RxPDO4*, Nd.36 | 1337 | 0x539 | RxPDO4*, Nd.57
1296 | 0x510 | RxPDO4*, Nd.16 | 1317 | 0x525 | RxPDO4*, Nd.37 | 1338 | 0x53A | RxPDO4*, Nd.58
1297 | 0x511 | RxPDO4*, Nd.17 | 1318 | 0x526 | RxPDO4*, Nd.38 | 1339 | 0x53B | RxPDO4*, Nd.59
1298 | 0x512 | RxPDO4*, Nd.18 | 1319 | 0x527 | RxPDO4*, Nd.39 | 1340 | 0x53C | RxPDO4*, Nd.60
1299 | 0x513 | RxPDO4*, Nd.19 | 1320 | 0x528 | RxPDO4*, Nd.40 | 1341 | 0x53D | RxPDO4*, Nd.61
1300 | 0x514 | RxPDO4*, Nd.20 | 1321 | 0x529 | RxPDO4*, Nd.41 | 1342 | 0x53E | RxPDO4*, Nd.62
1301 | 0x515 | RxPDO4*, Nd.21 | 1322 | 0x52A | RxPDO4*, Nd.42 | 1343 | 0x53F | RxPDO4*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1665 | 0x681 | TxPDO5*, Nd.1 | 1686 | 0x696 | TxPDO5*, Nd.22 | 1707 | 0x6AB | TxPDO5*, Nd.43
1666 | 0x682 | TxPDO5*, Nd.2 | 1687 | 0x697 | TxPDO5*, Nd.23 | 1708 | 0x6AC | TxPDO5*, Nd.44
1667 | 0x683 | TxPDO5*, Nd.3 | 1688 | 0x698 | TxPDO5*, Nd.24 | 1709 | 0x6AD | TxPDO5*, Nd.45
1668 | 0x684 | TxPDO5*, Nd.4 | 1689 | 0x699 | TxPDO5*, Nd.25 | 1710 | 0x6AE | TxPDO5*, Nd.46
1669 | 0x685 | TxPDO5*, Nd.5 | 1690 | 0x69A | TxPDO5*, Nd.26 | 1711 | 0x6AF | TxPDO5*, Nd.47
1670 | 0x686 | TxPDO5*, Nd.6 | 1691 | 0x69B | TxPDO5*, Nd.27 | 1712 | 0x6B0 | TxPDO5*, Nd.48
1671 | 0x687 | TxPDO5*, Nd.7 | 1692 | 0x69C | TxPDO5*, Nd.28 | 1713 | 0x6B1 | TxPDO5*, Nd.49
1672 | 0x688 | TxPDO5*, Nd.8 | 1693 | 0x69D | TxPDO5*, Nd.29 | 1714 | 0x6B2 | TxPDO5*, Nd.50
1673 | 0x689 | TxPDO5*, Nd.9 | 1694 | 0x69E | TxPDO5*, Nd.30 | 1715 | 0x6B3 | TxPDO5*, Nd.51
1674 | 0x68A | TxPDO5*, Nd.10 | 1695 | 0x69F | TxPDO5*, Nd.31 | 1716 | 0x6B4 | TxPDO5*, Nd.52
1675 | 0x68B | TxPDO5*, Nd.11 | 1696 | 0x6A0 | TxPDO5*, Nd.32 | 1717 | 0x6B5 | TxPDO5*, Nd.53
1676 | 0x68C | TxPDO5*, Nd.12 | 1697 | 0x6A1 | TxPDO5*, Nd.33 | 1718 | 0x6B6 | TxPDO5*, Nd.54
1677 | 0x68D | TxPDO5*, Nd.13 | 1698 | 0x6A2 | TxPDO5*, Nd.34 | 1719 | 0x6B7 | TxPDO5*, Nd.55
1678 | 0x68E | TxPDO5*, Nd.14 | 1699 | 0x6A3 | TxPDO5*, Nd.35 | 1720 | 0x6B8 | TxPDO5*, Nd.56
1679 | 0x68F | TxPDO5*, Nd.15 | 1700 | 0x6A4 | TxPDO5*, Nd.36 | 1721 | 0x6B9 | TxPDO5*, Nd.57
1680 | 0x690 | TxPDO5*, Nd.16 | 1701 | 0x6A5 | TxPDO5*, Nd.37 | 1722 | 0x6BA | TxPDO5*, Nd.58
1681 | 0x691 | TxPDO5*, Nd.17 | 1702 | 0x6A6 | TxPDO5*, Nd.38 | 1723 | 0x6BB | TxPDO5*, Nd.59
1682 | 0x692 | TxPDO5*, Nd.18 | 1703 | 0x6A7 | TxPDO5*, Nd.39 | 1724 | 0x6BC | TxPDO5*, Nd.60
1683 | 0x693 | TxPDO5*, Nd.19 | 1704 | 0x6A8 | TxPDO5*, Nd.40 | 1725 | 0x6BD | TxPDO5*, Nd.61
1684 | 0x694 | TxPDO5*, Nd.20 | 1705 | 0x6A9 | TxPDO5*, Nd.41 | 1726 | 0x6BE | TxPDO5*, Nd.62
1685 | 0x695 | TxPDO5*, Nd.21 | 1706 | 0x6AA | TxPDO5*, Nd.42 | 1727 | 0x6BF | TxPDO5*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1921 | 0x781 | RxPDO5*, Nd.1 | 1942 | 0x796 | RxPDO5*, Nd.22 | 1963 | 0x7AB | RxPDO5*, Nd.43
1922 | 0x782 | RxPDO5*, Nd.2 | 1943 | 0x797 | RxPDO5*, Nd.23 | 1964 | 0x7AC | RxPDO5*, Nd.44
1923 | 0x783 | RxPDO5*, Nd.3 | 1944 | 0x798 | RxPDO5*, Nd.24 | 1965 | 0x7AD | RxPDO5*, Nd.45
1924 | 0x784 | RxPDO5*, Nd.4 | 1945 | 0x799 | RxPDO5*, Nd.25 | 1966 | 0x7AE | RxPDO5*, Nd.46
1925 | 0x785 | RxPDO5*, Nd.5 | 1946 | 0x79A | RxPDO5*, Nd.26 | 1967 | 0x7AF | RxPDO5*, Nd.47
1926 | 0x786 | RxPDO5*, Nd.6 | 1947 | 0x79B | RxPDO5*, Nd.27 | 1968 | 0x7B0 | RxPDO5*, Nd.48
1927 | 0x787 | RxPDO5*, Nd.7 | 1948 | 0x79C | RxPDO5*, Nd.28 | 1969 | 0x7B1 | RxPDO5*, Nd.49
1928 | 0x788 | RxPDO5*, Nd.8 | 1949 | 0x79D | RxPDO5*, Nd.29 | 1970 | 0x7B2 | RxPDO5*, Nd.50
1929 | 0x789 | RxPDO5*, Nd.9 | 1950 | 0x79E | RxPDO5*, Nd.30 | 1971 | 0x7B3 | RxPDO5*, Nd.51
1930 | 0x78A | RxPDO5*, Nd.10 | 1951 | 0x79F | RxPDO5*, Nd.31 | 1972 | 0x7B4 | RxPDO5*, Nd.52
1931 | 0x78B | RxPDO5*, Nd.11 | 1952 | 0x7A0 | RxPDO5*, Nd.32 | 1973 | 0x7B5 | RxPDO5*, Nd.53
1932 | 0x78C | RxPDO5*, Nd.12 | 1953 | 0x7A1 | RxPDO5*, Nd.33 | 1974 | 0x7B6 | RxPDO5*, Nd.54
1933 | 0x78D | RxPDO5*, Nd.13 | 1954 | 0x7A2 | RxPDO5*, Nd.34 | 1975 | 0x7B7 | RxPDO5*, Nd.55
1934 | 0x78E | RxPDO5*, Nd.14 | 1955 | 0x7A3 | RxPDO5*, Nd.35 | 1976 | 0x7B8 | RxPDO5*, Nd.56
1935 | 0x78F | RxPDO5*, Nd.15 | 1956 | 0x7A4 | RxPDO5*, Nd.36 | 1977 | 0x7B9 | RxPDO5*, Nd.57
1936 | 0x790 | RxPDO5*, Nd.16 | 1957 | 0x7A5 | RxPDO5*, Nd.37 | 1978 | 0x7BA | RxPDO5*, Nd.58
1937 | 0x791 | RxPDO5*, Nd.17 | 1958 | 0x7A6 | RxPDO5*, Nd.38 | 1979 | 0x7BB | RxPDO5*, Nd.59
1938 | 0x792 | RxPDO5*, Nd.18 | 1959 | 0x7A7 | RxPDO5*, Nd.39 | 1980 | 0x7BC | RxPDO5*, Nd.60
1939 | 0x793 | RxPDO5*, Nd.19 | 1960 | 0x7A8 | RxPDO5*, Nd.40 | 1981 | 0x7BD | RxPDO5*, Nd.61
1940 | 0x794 | RxPDO5*, Nd.20 | 1961 | 0x7A9 | RxPDO5*, Nd.41 | 1982 | 0x7BE | RxPDO5*, Nd.62
1941 | 0x795 | RxPDO5*, Nd.21 | 1962 | 0x7AA | RxPDO5*, Nd.42 | 1983 | 0x7BF | RxPDO5*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
449 | 0x1C1 | TxPDO6*, Nd.1 | 470 | 0x1D6 | TxPDO6*, Nd.22 | 491 | 0x1EB | TxPDO6*, Nd.43
450 | 0x1C2 | TxPDO6*, Nd.2 | 471 | 0x1D7 | TxPDO6*, Nd.23 | 492 | 0x1EC | TxPDO6*, Nd.44
451 | 0x1C3 | TxPDO6*, Nd.3 | 472 | 0x1D8 | TxPDO6*, Nd.24 | 493 | 0x1ED | TxPDO6*, Nd.45
452 | 0x1C4 | TxPDO6*, Nd.4 | 473 | 0x1D9 | TxPDO6*, Nd.25 | 494 | 0x1EE | TxPDO6*, Nd.46
453 | 0x1C5 | TxPDO6*, Nd.5 | 474 | 0x1DA | TxPDO6*, Nd.26 | 495 | 0x1EF | TxPDO6*, Nd.47
454 | 0x1C6 | TxPDO6*, Nd.6 | 475 | 0x1DB | TxPDO6*, Nd.27 | 496 | 0x1F0 | TxPDO6*, Nd.48
455 | 0x1C7 | TxPDO6*, Nd.7 | 476 | 0x1DC | TxPDO6*, Nd.28 | 497 | 0x1F1 | TxPDO6*, Nd.49
456 | 0x1C8 | TxPDO6*, Nd.8 | 477 | 0x1DD | TxPDO6*, Nd.29 | 498 | 0x1F2 | TxPDO6*, Nd.50
457 | 0x1C9 | TxPDO6*, Nd.9 | 478 | 0x1DE | TxPDO6*, Nd.30 | 499 | 0x1F3 | TxPDO6*, Nd.51
458 | 0x1CA | TxPDO6*, Nd.10 | 479 | 0x1DF | TxPDO6*, Nd.31 | 500 | 0x1F4 | TxPDO6*, Nd.52
459 | 0x1CB | TxPDO6*, Nd.11 | 480 | 0x1E0 | TxPDO6*, Nd.32 | 501 | 0x1F5 | TxPDO6*, Nd.53
460 | 0x1CC | TxPDO6*, Nd.12 | 481 | 0x1E1 | TxPDO6*, Nd.33 | 502 | 0x1F6 | TxPDO6*, Nd.54
461 | 0x1CD | TxPDO6*, Nd.13 | 482 | 0x1E2 | TxPDO6*, Nd.34 | 503 | 0x1F7 | TxPDO6*, Nd.55
462 | 0x1CE | TxPDO6*, Nd.14 | 483 | 0x1E3 | TxPDO6*, Nd.35 | 504 | 0x1F8 | TxPDO6*, Nd.56
463 | 0x1CF | TxPDO6*, Nd.15 | 484 | 0x1E4 | TxPDO6*, Nd.36 | 505 | 0x1F9 | TxPDO6*, Nd.57
464 | 0x1D0 | TxPDO6*, Nd.16 | 485 | 0x1E5 | TxPDO6*, Nd.37 | 506 | 0x1FA | TxPDO6*, Nd.58
465 | 0x1D1 | TxPDO6*, Nd.17 | 486 | 0x1E6 | TxPDO6*, Nd.38 | 507 | 0x1FB | TxPDO6*, Nd.59
466 | 0x1D2 | TxPDO6*, Nd.18 | 487 | 0x1E7 | TxPDO6*, Nd.39 | 508 | 0x1FC | TxPDO6*, Nd.60
467 | 0x1D3 | TxPDO6*, Nd.19 | 488 | 0x1E8 | TxPDO6*, Nd.40 | 509 | 0x1FD | TxPDO6*, Nd.61
468 | 0x1D4 | TxPDO6*, Nd.20 | 489 | 0x1E9 | TxPDO6*, Nd.41 | 510 | 0x1FE | TxPDO6*, Nd.62
469 | 0x1D5 | TxPDO6*, Nd.21 | 490 | 0x1EA | TxPDO6*, Nd.42 | 511 | 0x1FF | TxPDO6*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
577 | 0x241 | RxPDO6*, Nd.1 | 598 | 0x256 | RxPDO6*, Nd.22 | 619 | 0x26B | RxPDO6* Nd.43
578 | 0x242 | RxPDO6*, Nd.2 | 599 | 0x257 | RxPDO6*, Nd.23 | 620 | 0x26C | RxPDO6, Nd.44
579 | 0x243 | RxPDO6*, Nd.3 | 600 | 0x258 | RxPDO6*, Nd.24 | 621 | 0x26D | RxPDO6*, Nd.45
580 | 0x244 | RxPDO6*, Nd.4 | 601 | 0x259 | RxPDO6*, Nd.25 | 622 | 0x26E | RxPDO6*, Nd.46
581 | 0x245 | RxPDO6*, Nd.5 | 602 | 0x25A | RxPDO6*, Nd.26 | 623 | 0x26F | RxPDO6*, Nd.47
582 | 0x246 | RxPDO6*, Nd.6 | 603 | 0x25B | RxPDO6*, Nd.27 | 624 | 0x270 | RxPDO6*, Nd.48
583 | 0x247 | RxPDO6*, Nd.7 | 604 | 0x25C | RxPDO6*, Nd.28 | 625 | 0x271 | RxPDO6*, Nd.49
584 | 0x248 | RxPDO6*, Nd.8 | 605 | 0x25D | RxPDO6*, Nd.29 | 626 | 0x272 | RxPDO6*, Nd.50
585 | 0x249 | RxPDO6*, Nd.9 | 606 | 0x25E | RxPDO6*, Nd.30 | 627 | 0x273 | RxPDO6*, Nd.51
586 | 0x24A | RxPDO6*, Nd.10 | 607 | 0x25F | RxPDO6*, Nd.31 | 628 | 0x274 | RxPDO6*, Nd.52
587 | 0x24B | RxPDO6*, Nd.11 | 608 | 0x260 | RxPDO6*, Nd.32 | 629 | 0x275 | RxPDO6*, Nd.53
588 | 0x24C | RxPDO6*, Nd.12 | 609 | 0x261 | RxPDO6*, Nd.33 | 630 | 0x276 | RxPDO6*, Nd.54
589 | 0x24D | RxPDO6*, Nd.13 | 610 | 0x262 | RxPDO6*, Nd.34 | 631 | 0x277 | RxPDO6*, Nd.55
590 | 0x24E | RxPDO6*, Nd.14 | 611 | 0x263 | RxPDO6*, Nd.35 | 632 | 0x278 | RxPDO6*, Nd.56
591 | 0x24F | RxPDO6*, Nd.15 | 612 | 0x264 | RxPDO6*, Nd.36 | 633 | 0x279 | RxPDO6*, Nd.57
592 | 0x250 | RxPDO6*, Nd.16 | 613 | 0x265 | RxPDO6*, Nd.3 | 634 | 0x27A | RxPDO6*, Nd.58
593 | 0x251 | RxPDO6*, Nd.17 | 614 | 0x266 | RxPDO6*, Nd.8 | 635 | 0x27B | RxPDO6*, Nd.59
594 | 0x252 | RxPDO6*, Nd.18 | 615 | 0x267 | RxPDO6*, Nd39 | 636 | 0x27C | RxPDO6*, Nd.60
595 | 0x253 | RxPDO6*, Nd.19 | 616 | 0x268 | RxPDO6*, N.40 | 637 | 0x27D | RxPDO6*, Nd.61
596 | 0x254 | RxPDO6*, Nd.20 | 617 | 0x269 | RxPDO6*, d.41 | 638 | 0x27E | RxPDO6*, Nd.62
597 | 0x255 | RxPDO6*, Nd.21 | 618 | 0x26A | RxPDO6*,Nd.42 | 639 | 0x27F | RxPDO6*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
705 | 0x2C1 | TxPDO7*, Nd.1 | 726 | 0x2D6 | TxPDO7*, Nd.22 | 747 | 0x2EB | TxPDO7*, Nd.43
706 | 0x2C2 | TxPDO7*, Nd.2 | 727 | 0x2D7 | TxPDO7*, Nd.23 | 748 | 0x2EC | TxPDO7*, Nd.44
707 | 0x2C3 | TxPDO7*, Nd.3 | 728 | 0x2D8 | TxPDO7*, Nd.24 | 749 | 0x2ED | TxPDO7*, Nd.45
708 | 0x2C4 | TxPDO7*, Nd.4 | 729 | 0x2D9 | TxPDO7*, Nd.25 | 750 | 0x2EE | TxPDO7*, Nd.46
709 | 0x2C5 | TxPDO7*, Nd.5 | 730 | 0x2DA | TxPDO7*, Nd.26 | 751 | 0x2EF | TxPDO7*, Nd.47
710 | 0x2C6 | TxPDO7*, Nd.6 | 731 | 0x2DB | TxPDO7*, Nd.27 | 752 | 0x2F0 | TxPDO7*, Nd.48
711 | 0x2C7 | TxPDO7*, Nd.7 | 732 | 0x2DC | TxPDO7*, Nd.28 | 753 | 0x2F1 | TxPDO7*, Nd.49
712 | 0x2C8 | TxPDO7*, Nd.8 | 733 | 0x2DD | TxPDO7*, Nd.29 | 754 | 0x2F2 | TxPDO7*, Nd.50
713 | 0x2C9 | TxPDO7*, Nd.9 | 734 | 0x2DE | TxPDO7*, Nd.30 | 755 | 0x2F3 | TxPDO7*, Nd.51
714 | 0x2CA | TxPDO7*, Nd.10 | 735 | 0x2DF | TxPDO7*, Nd.31 | 756 | 0x2F4 | TxPDO7*, Nd.52
715 | 0x2CB | TxPDO7*, Nd.11 | 736 | 0x2E0 | TxPDO7*, Nd.32 | 757 | 0x2F5 | TxPDO7*, Nd.53
716 | 0x2CC | TxPDO7*, Nd.12 | 737 | 0x2E1 | TxPDO7*, Nd.33 | 758 | 0x2F6 | TxPDO7*, Nd.54
717 | 0x2CD | TxPDO7*, Nd.13 | 738 | 0x2E2 | TxPDO7*, Nd.34 | 759 | 0x2F7 | TxPDO7*, Nd.55
718 | 0x2CE | TxPDO7*, Nd.14 | 739 | 0x2E3 | TxPDO7*, Nd.35 | 760 | 0x2F8 | TxPDO7*, Nd.56
719 | 0x2CF | TxPDO7*, Nd.15 | 740 | 0x2E4 | TxPDO7*, Nd.36 | 761 | 0x2F9 | TxPDO7*, Nd.57
720 | 0x2D0 | TxPDO7*, Nd.16 | 741 | 0x2E5 | TxPDO7*, Nd.37 | 762 | 0x2FA | TxPDO7*, Nd.58
721 | 0x2D1 | TxPDO7*, Nd.17 | 742 | 0x2E6 | TxPDO7*, Nd.38 | 763 | 0x2FB | TxPDO7*, Nd.59
722 | 0x2D2 | TxPDO7*, Nd.18 | 743 | 0x2E7 | TxPDO7*, Nd.39 | 764 | 0x2FC | TxPDO7*, Nd.60
723 | 0x2D3 | TxPDO7*, Nd.19 | 744 | 0x2E8 | TxPDO7*, Nd.40 | 765 | 0x2FD | TxPDO7*, Nd.61
724 | 0x2D4 | TxPDO7*, Nd.20 | 745 | 0x2E9 | TxPDO7*, Nd.41 | 766 | 0x2FE | TxPDO7*, Nd.62
725 | 0x2D5 | TxPDO7*, Nd.21 | 746 | 0x2EA | TxPDO7*, Nd.42 | 767 | 0x2FF | TxPDO7*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
833 | 0x341 | RxPDO7*, Nd.1 | 854 | 0x356 | RxPDO7*, Nd.22 | 875 | 0x36B | RxPDO7*, Nd.43
834 | 0x342 | RxPDO7*, Nd.2 | 855 | 0x357 | RxPDO7*, Nd.23 | 876 | 0x36C | RxPDO7*, Nd.44
835 | 0x343 | RxPDO7*, Nd.3 | 856 | 0x358 | RxPDO7*, Nd.24 | 877 | 0x36D | RxPDO7*, Nd.45
836 | 0x344 | RxPDO7*, Nd.4 | 857 | 0x359 | RxPDO7*, Nd.25 | 878 | 0x36E | RxPDO7*, Nd.46
837 | 0x345 | RxPDO7*, Nd.5 | 858 | 0x35A | RxPDO7*, Nd.26 | 879 | 0x36F | RxPDO7*, Nd.47
838 | 0x346 | RxPDO7*, Nd.6 | 859 | 0x35B | RxPDO7*, Nd.27 | 880 | 0x370 | RxPDO7*, Nd.48
839 | 0x347 | RxPDO7*, Nd.7 | 860 | 0x35C | RxPDO7*, Nd.28 | 881 | 0x371 | RxPDO7*, Nd.49
840 | 0x348 | RxPDO7*, Nd.8 | 861 | 0x35D | RxPDO7*, Nd.29 | 882 | 0x372 | RxPDO7*, Nd.50
841 | 0x349 | RxPDO7*, Nd.9 | 862 | 0x35E | RxPDO7*, Nd.30 | 883 | 0x373 | RxPDO7*, Nd.51
842 | 0x34A | RxPDO7*, Nd.10 | 863 | 0x35F | RxPDO7*, Nd.31 | 884 | 0x374 | RxPDO7*, Nd.52
843 | 0x34B | RxPDO7*, Nd.11 | 864 | 0x360 | RxPDO7*, Nd.32 | 885 | 0x375 | RxPDO7*, Nd.53
844 | 0x34C | RxPDO7*, Nd.12 | 865 | 0x361 | RxPDO7*, Nd.33 | 886 | 0x376 | RxPDO7*, Nd.54
845 | 0x34D | RxPDO7*, Nd.13 | 866 | 0x362 | RxPDO7*, Nd.34 | 887 | 0x377 | RxPDO7*, Nd.55
846 | 0x34E | RxPDO7*, Nd.14 | 867 | 0x363 | RxPDO7*, Nd.35 | 888 | 0x378 | RxPDO7*, Nd.56
847 | 0x34F | RxPDO7*, Nd.15 | 868 | 0x364 | RxPDO7*, Nd.36 | 889 | 0x379 | RxPDO7*, Nd.57
848 | 0x350 | RxPDO7*, Nd.16 | 869 | 0x365 | RxPDO7*, Nd.37 | 890 | 0x37A | RxPDO7*, Nd.58
849 | 0x351 | RxPDO7*, Nd.17 | 870 | 0x366 | RxPDO7*, Nd.38 | 891 | 0x37B | RxPDO7*, Nd.59
850 | 0x352 | RxPDO7*, Nd.18 | 871 | 0x367 | RxPDO7*, Nd.39 | 892 | 0x37C | RxPDO7*, Nd.60
851 | 0x353 | RxPDO7*, Nd.19 | 872 | 0x368 | RxPDO7*, Nd.40 | 893 | 0x37D | RxPDO7*, Nd.61
852 | 0x354 | RxPDO7*, Nd.20 | 873 | 0x369 | RxPDO7*, Nd.41 | 894 | 0x37E | RxPDO7*, Nd.62
853 | 0x355 | RxPDO7*, Nd.21 | 874 | 0x36A | RxPDO7*, Nd.42 | 895 | 0x37F | RxPDO7*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
961 | 0x3C1 | TxPDO8*, Nd.1 | 982 | 0x3D6 | TxPDO8*, Nd.22 | 1003 | 0x3EB | TxPDO8*, Nd.43
962 | 0x3C2 | TxPDO8*, Nd.2 | 983 | 0x3D7 | TxPDO8*, Nd.23 | 1004 | 0x3EC | TxPDO8*, Nd.44
963 | 0x3C3 | TxPDO8*, Nd.3 | 984 | 0x3D8 | TxPDO8*, Nd.24 | 1005 | 0x3ED | TxPDO8*, Nd.45
964 | 0x3C4 | TxPDO8*, Nd.4 | 985 | 0x3D9 | TxPDO8*, Nd.25 | 1006 | 0x3EE | TxPDO8*, Nd.46
965 | 0x3C5 | TxPDO8*, Nd.5 | 986 | 0x3DA | TxPDO8*, Nd.26 | 1007 | 0x3EF | TxPDO8*, Nd.47
966 | 0x3C6 | TxPDO8*, Nd.6 | 987 | 0x3DB | TxPDO8*, Nd.27 | 1008 | 0x3F0 | TxPDO8*, Nd.48
967 | 0x3C7 | TxPDO8*, Nd.7 | 988 | 0x3DC | TxPDO8*, Nd.28 | 1009 | 0x3F1 | TxPDO8*, Nd.49
968 | 0x3C8 | TxPDO8*, Nd.8 | 989 | 0x3DD | TxPDO8*, Nd.29 | 1010 | 0x3F2 | TxPDO8*, Nd.50
969 | 0x3C9 | TxPDO8*, Nd.9 | 990 | 0x3DE | TxPDO8*, Nd.30 | 1011 | 0x3F3 | TxPDO8*, Nd.51
970 | 0x3CA | TxPDO8*, Nd.10 | 991 | 0x3DF | TxPDO8*, Nd.31 | 1012 | 0x3F4 | TxPDO8*, Nd.52
971 | 0x3CB | TxPDO8*, Nd.11 | 992 | 0x3E0 | TxPDO8*, Nd.32 | 1013 | 0x3F5 | TxPDO8*, Nd.53
972 | 0x3CC | TxPDO8*, Nd.12 | 993 | 0x3E1 | TxPDO8*, Nd.33 | 1014 | 0x3F6 | TxPDO8*, Nd.54
973 | 0x3CD | TxPDO8*, Nd.13 | 994 | 0x3E2 | TxPDO8*, Nd.34 | 1015 | 0x3F7 | TxPDO8*, Nd.55
974 | 0x3CE | TxPDO8*, Nd.14 | 995 | 0x3E3 | TxPDO8*, Nd.35 | 1016 | 0x3F8 | TxPDO8*, Nd.56
975 | 0x3CF | TxPDO8*, Nd.15 | 996 | 0x3E4 | TxPDO8*, Nd.36 | 1017 | 0x3F9 | TxPDO8*, Nd.57
976 | 0x3D0 | TxPDO8*, Nd.16 | 997 | 0x3E5 | TxPDO8*, Nd.37 | 1018 | 0x3FA | TxPDO8*, Nd.58
977 | 0x3D1 | TxPDO8*, Nd.17 | 998 | 0x3E6 | TxPDO8*, Nd.38 | 1019 | 0x3FB | TxPDO8*, Nd.59
978 | 0x3D2 | TxPDO8*, Nd.18 | 999 | 0x3E7 | TxPDO8*, Nd.39 | 1020 | 0x3FC | TxPDO8*, Nd.60
979 | 0x3D3 | TxPDO8*, Nd.19 | 1000 | 0x3E8 | TxPDO8*, Nd.40 | 1021 | 0x3FD | TxPDO8*, Nd.61
980 | 0x3D4 | TxPDO8*, Nd.20 | 1001 | 0x3E9 | TxPDO8*, Nd.41 | 1022 | 0x3FE | TxPDO8*, Nd.62
981 | 0x3D5 | TxPDO8*, Nd.21 | 1002 | 0x3EA | TxPDO8*, Nd.42 | 1023 | 0x3FF | TxPDO8*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1089 | 0x441 | RxPDO8*, Nd.1 | 1110 | 0x456 | RxPDO8*, Nd.22 | 1131 | 0x46B | RxPDO8*, Nd.43
1090 | 0x442 | RxPDO8*, Nd.2 | 1111 | 0x457 | RxPDO8*, Nd.23 | 1132 | 0x46C | RxPDO8*, Nd.44
1091 | 0x443 | RxPDO8*, Nd.3 | 1112 | 0x458 | RxPDO8*, Nd.24 | 1133 | 0x46D | RxPDO8*, Nd.45
1092 | 0x444 | RxPDO8*, Nd.4 | 1113 | 0x459 | RxPDO8*, Nd.25 | 1134 | 0x46E | RxPDO8*, Nd.46
1093 | 0x445 | RxPDO8*, Nd.5 | 1114 | 0x45A | RxPDO8*, Nd.26 | 1135 | 0x46F | RxPDO8*, Nd.47
1094 | 0x446 | RxPDO8*, Nd.6 | 1115 | 0x45B | RxPDO8*, Nd.27 | 1136 | 0x470 | RxPDO8*, Nd.48
1095 | 0x447 | RxPDO8*, Nd.7 | 1116 | 0x45C | RxPDO8*, Nd.28 | 1137 | 0x471 | RxPDO8*, Nd.49
1096 | 0x448 | RxPDO8*, Nd.8 | 1117 | 0x45D | RxPDO8*, Nd.29 | 1138 | 0x472 | RxPDO8*, Nd.50
1097 | 0x449 | RxPDO8*, Nd.9 | 1118 | 0x45E | RxPDO8*, Nd.30 | 1139 | 0x473 | RxPDO8*, Nd.51
1098 | 0x44A | RxPDO8*, Nd.10 | 1119 | 0x45F | RxPDO8*, Nd.31 | 1140 | 0x474 | RxPDO8*, Nd.52
1099 | 0x44B | RxPDO8*, Nd.11 | 1120 | 0x460 | RxPDO8*, Nd.32 | 1141 | 0x475 | RxPDO8*, Nd.53
1100 | 0x44C | RxPDO8*, Nd.12 | 1121 | 0x461 | RxPDO8*, Nd.33 | 1142 | 0x476 | RxPDO8*, Nd.54
1101 | 0x44D | RxPDO8*, Nd.13 | 1122 | 0x462 | RxPDO8*, Nd.34 | 1143 | 0x477 | RxPDO8*, Nd.55
1102 | 0x44E | RxPDO8*, Nd.14 | 1123 | 0x463 | RxPDO8*, Nd.35 | 1144 | 0x478 | RxPDO8*, Nd.56
1103 | 0x44F | RxPDO8*, Nd.15 | 1124 | 0x464 | RxPDO8*, Nd.36 | 1145 | 0x479 | RxPDO8*, Nd.57
1104 | 0x450 | RxPDO8*, Nd.16 | 1125 | 0x465 | RxPDO8*, Nd.37 | 1146 | 0x47A | RxPDO8*, Nd.58
1105 | 0x451 | RxPDO8*, Nd.17 | 1126 | 0x466 | RxPDO8*, Nd.38 | 1147 | 0x47B | RxPDO8*, Nd.59
1106 | 0x452 | RxPDO8*, Nd.18 | 1127 | 0x467 | RxPDO8*, Nd.39 | 1148 | 0x47C | RxPDO8*, Nd.60
1107 | 0x453 | RxPDO8*, Nd.19 | 1128 | 0x468 | RxPDO8*, Nd.40 | 1149 | 0x47D | RxPDO8*, Nd.61
1108 | 0x454 | RxPDO8*, Nd.20 | 1129 | 0x469 | RxPDO8*, Nd.41 | 1150 | 0x47E | RxPDO8*, Nd.62
1109 | 0x455 | RxPDO8*, Nd.21 | 1130 | 0x46A | RxPDO8*, Nd.42 | 1151 | 0x47F | RxPDO8*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1217 | 0x4C1 | TxPDO9*, Nd.1 | 1238 | 0x4D6 | TxPDO9*, Nd.22 | 1259 | 0x4EB | TxPDO9*, Nd.43
1218 | 0x4C2 | TxPDO9*, Nd.2 | 1239 | 0x4D7 | TxPDO9*, Nd.23 | 1260 | 0x4EC | TxPDO9*, Nd.44
1219 | 0x4C3 | TxPDO9*, Nd.3 | 1240 | 0x4D8 | TxPDO9*, Nd.24 | 1261 | 0x4ED | TxPDO9*, Nd.45
1220 | 0x4C4 | TxPDO9*, Nd.4 | 1241 | 0x4D9 | TxPDO9*, Nd.25 | 1262 | 0x4EE | TxPDO9*, Nd.46
1221 | 0x4C5 | TxPDO9*, Nd.5 | 1242 | 0x4DA | TxPDO9*, Nd.26 | 1263 | 0x4EF | TxPDO9*, Nd.47
1222 | 0x4C6 | TxPDO9*, Nd.6 | 1243 | 0x4DB | TxPDO9*, Nd.27 | 1264 | 0x4F0 | TxPDO9*, Nd.48
1223 | 0x4C7 | TxPDO9*, Nd.7 | 1244 | 0x4DC | TxPDO9*, Nd.28 | 1265 | 0x4F1 | TxPDO9*, Nd.49
1224 | 0x4C8 | TxPDO9*, Nd.8 | 1245 | 0x4DD | TxPDO9*, Nd.29 | 1266 | 0x4F2 | TxPDO9*, Nd.50
1225 | 0x4C9 | TxPDO9*, Nd.9 | 1246 | 0x4DE | TxPDO9*, Nd.30 | 1267 | 0x4F3 | TxPDO9*, Nd.51
1226 | 0x4CA | TxPDO9*, Nd.10 | 1247 | 0x4DF | TxPDO9*, Nd.31 | 1268 | 0x4F4 | TxPDO9*, Nd.52
1227 | 0x4CB | TxPDO9*, Nd.11 | 1248 | 0x4E0 | TxPDO9*, Nd.32 | 1269 | 0x4F5 | TxPDO9*, Nd.53
1228 | 0x4CC | TxPDO9*, Nd.12 | 1249 | 0x4E1 | TxPDO9*, Nd.33 | 1270 | 0x4F6 | TxPDO9*, Nd.54
1229 | 0x4CD | TxPDO9*, Nd.13 | 1250 | 0x4E2 | TxPDO9*, Nd.34 | 1271 | 0x4F7 | TxPDO9*, Nd.55
1230 | 0x4CE | TxPDO9*, Nd.14 | 1251 | 0x4E3 | TxPDO9*, Nd.35 | 1272 | 0x4F8 | TxPDO9*, Nd.56
1231 | 0x4CF | TxPDO9*, Nd.15 | 1252 | 0x4E4 | TxPDO9*, Nd.36 | 1273 | 0x4F9 | TxPDO9*, Nd.57
1232 | 0x4D0 | TxPDO9*, Nd.16 | 1253 | 0x4E5 | TxPDO9*, Nd.37 | 1274 | 0x4FA | TxPDO9*, Nd.58
1233 | 0x4D1 | TxPDO9*, Nd.17 | 1254 | 0x4E6 | TxPDO9*, Nd.38 | 1275 | 0x4FB | TxPDO9*, Nd.59
1234 | 0x4D2 | TxPDO9*, Nd.18 | 1255 | 0x4E7 | TxPDO9*, Nd.39 | 1276 | 0x4FC | TxPDO9*, Nd.60
1235 | 0x4D3 | TxPDO9*, Nd.19 | 1256 | 0x4E8 | TxPDO9*, Nd.40 | 1277 | 0x4FD | TxPDO9*, Nd.61
1236 | 0x4D4 | TxPDO9*, Nd.20 | 1257 | 0x4E9 | TxPDO9*, Nd.41 | 1278 | 0x4FE | TxPDO9*, Nd.62
1237 | 0x4D5 | TxPDO9*, Nd.21 | 1258 | 0x4EA | TxPDO9*, Nd.42 | 1279 | 0x4FF | TxPDO9*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1345 | 0x541 | RxPDO9*, Nd.1 | 1366 | 0x556 | RxPDO9*, Nd.22 | 1387 | 0x56B | RxPDO9*, Nd.43
1346 | 0x542 | RxPDO9*, Nd.2 | 1367 | 0x557 | RxPDO9*, Nd.23 | 1388 | 0x56C | RxPDO9*, Nd.44
1347 | 0x543 | RxPDO9*, Nd.3 | 1368 | 0x558 | RxPDO9*, Nd.24 | 1389 | 0x56D | RxPDO9*, Nd.45
1348 | 0x544 | RxPDO9*, Nd.4 | 1369 | 0x559 | RxPDO9*, Nd.25 | 1390 | 0x56E | RxPDO9*, Nd.46
1349 | 0x545 | RxPDO9*, Nd.5 | 1370 | 0x55A | RxPDO9*, Nd.26 | 1391 | 0x56F | RxPDO9*, Nd.47
1350 | 0x546 | RxPDO9*, Nd.6 | 1371 | 0x55B | RxPDO9*, Nd.27 | 1392 | 0x570 | RxPDO9*, Nd.48
1351 | 0x547 | RxPDO9*, Nd.7 | 1372 | 0x55C | RxPDO9*, Nd.28 | 1393 | 0x571 | RxPDO9*, Nd.49
1352 | 0x548 | RxPDO9*, Nd.8 | 1373 | 0x55D | RxPDO9*, Nd.29 | 1394 | 0x572 | RxPDO9*, Nd.50
1353 | 0x549 | RxPDO9*, Nd.9 | 1374 | 0x55E | RxPDO9*, Nd.30 | 1395 | 0x573 | RxPDO9*, Nd.51
1354 | 0x54A | RxPDO9*, Nd.10 | 1375 | 0x55F | RxPDO9*, Nd.31 | 1396 | 0x574 | RxPDO9*, Nd.52
1355 | 0x54B | RxPDO9*, Nd.11 | 1376 | 0x560 | RxPDO9*, Nd.32 | 1397 | 0x575 | RxPDO9*, Nd.53
1356 | 0x54C | RxPDO9*, Nd.12 | 1377 | 0x561 | RxPDO9*, Nd.33 | 1398 | 0x576 | RxPDO9*, Nd.54
1357 | 0x54D | RxPDO9*, Nd.13 | 1378 | 0x562 | RxPDO9*, Nd.34 | 1399 | 0x577 | RxPDO9*, Nd.55
1358 | 0x54E | RxPDO9*, Nd.14 | 1379 | 0x563 | RxPDO9*, Nd.35 | 1400 | 0x578 | RxPDO9*, Nd.56
1359 | 0x54F | RxPDO9*, Nd.15 | 1380 | 0x564 | RxPDO9*, Nd.36 | 1401 | 0x579 | RxPDO9*, Nd.57
1360 | 0x550 | RxPDO9*, Nd.16 | 1381 | 0x565 | RxPDO9*, Nd.37 | 1402 | 0x57A | RxPDO9*, Nd.58
1361 | 0x551 | RxPDO9*, Nd.17 | 1382 | 0x566 | RxPDO9*, Nd.38 | 1403 | 0x57B | RxPDO9*, Nd.59
1362 | 0x552 | RxPDO9*, Nd.18 | 1383 | 0x567 | RxPDO9*, Nd.39 | 1404 | 0x57C | RxPDO9*, Nd.60
1363 | 0x553 | RxPDO9*, Nd.19 | 1384 | 0x568 | RxPDO9*, Nd.40 | 1405 | 0x57D | RxPDO9*, Nd.61
1364 | 0x554 | RxPDO9*, Nd.20 | 1385 | 0x569 | RxPDO9*, Nd.41 | 1406 | 0x57E | RxPDO9*, Nd.62
1365 | 0x555 | RxPDO9*, Nd.21 | 1386 | 0x56A | RxPDO9*, Nd.42 | 1407 | 0x57F | RxPDO9*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1473 | 0x5C1 | TxPDO10*, Nd.1 | 1494 | 0x5D6 | TxPDO10*, Nd.22 | 1515 | 0x5EB | TxPDO10*, Nd.43
1474 | 0x5C2 | TxPDO10*, Nd.2 | 1495 | 0x5D7 | TxPDO10*, Nd.23 | 1516 | 0x5EC | TxPDO10*, Nd.44
1475 | 0x5C3 | TxPDO10*, Nd.3 | 1496 | 0x5D8 | TxPDO10*, Nd.24 | 1517 | 0x5ED | TxPDO10*, Nd.45
1476 | 0x5C4 | TxPDO10*, Nd.4 | 1497 | 0x5D9 | TxPDO10*, Nd.25 | 1518 | 0x5EE | TxPDO10*, Nd.46
1477 | 0x5C5 | TxPDO10*, Nd.5 | 1498 | 0x5DA | TxPDO10*, Nd.26 | 1519 | 0x5EF | TxPDO10*, Nd.47
1478 | 0x5C6 | TxPDO10*, Nd.6 | 1499 | 0x5DB | TxPDO10*, Nd.27 | 1520 | 0x5F0 | TxPDO10*, Nd.48
1479 | 0x5C7 | TxPDO10*, Nd.7 | 1500 | 0x5DC | TxPDO10*, Nd.28 | 1521 | 0x5F1 | TxPDO10*, Nd.49
1480 | 0x5C8 | TxPDO10*, Nd.8 | 1501 | 0xDE | TxPDO10*, Nd.29 | 1522 | 0x5F2 | TxPDO10*, Nd.50
1481 | 0x5C9 | TxPDO10*, Nd.9 | 1502 | 0x5DE | TxPDO10*, Nd.30 | 1523 | 0x5F3 | TxPDO10*, Nd.51
1482 | 0x5CA | TxPDO10*, Nd.10 | 1503 | 0x5DF | TxPDO10*, Nd.31 | 1524 | 0x5F4 | TxPDO10*, Nd.52
1483 | 0x5CB | TxPDO10*, Nd.11 | 1504 | 0x5E0 | TxPDO10*, Nd.32 | 1525 | 0x5F5 | TxPDO10*, Nd.53
1484 | 0x5CC | TxPDO10*, Nd.12 | 1505 | 0x5E1 | TxPDO10*, Nd.33 | 1526 | 0x5F6 | TxPDO10*, Nd.54
1485 | 0x5CD | TxPDO10*, Nd.13 | 1506 | 0x5E2 | TxPDO10*, Nd.34 | 1527 | 0x5F7 | TxPDO10*, Nd.55
1486 | 0x5CE | TxPDO10*, Nd.14 | 1507 | 0x5E3 | TxPDO10*, Nd.35 | 1528 | 0x5F8 | TxPDO10*, Nd.56
1487 | 0x5CF | TxPDO10*, Nd.15 | 1508 | 0x5E4 | TxPDO10*, Nd.36 | 1529 | 0x5F9 | TxPDO10*, Nd.57
1488 | 0x5D0 | TxPDO10*, Nd.16 | 1509 | 0x5E5 | TxPDO10*, Nd.37 | 1530 | 0x5FA | TxPDO10*, Nd.58
1489 | 0x5D1 | TxPDO10*, Nd.17 | 1510 | 0x5E6 | TxPDO10*, Nd.38 | 1531 | 0x5FB | TxPDO10*, Nd.59
1490 | 0x5D2 | TxPDO10*, Nd.18 | 1511 | 0x5E7 | TxPDO10*, Nd.39 | 1532 | 0x5FC | TxPDO10*, Nd.60
1491 | 0x5D3 | TxPDO10*, Nd.19 | 1512 | 0x5E8 | TxPDO10*, Nd.40 | 1533 | 0x5FD | TxPDO10*, Nd.61
1492 | 0x5D4 | TxPDO10*, Nd.20 | 1513 | 0x5E9 | TxPDO10*, Nd.41 | 1534 | 0x5FE | TxPDO10*, Nd.62
1493 | 0x5D5 | TxPDO10*, Nd.21 | 1514 | 0x5EA | TxPDO10*, Nd.42 | 1535 | 0x5FF | TxPDO10*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1601 | 0x641 | RxPDO10*, Nd.1 | 1622 | 0x656 | RxPDO10*, Nd.22 | 1643 | 0x66B | RxPDO10*, Nd.43
1602 | 0x642 | RxPDO10*, Nd.2 | 1623 | 0x657 | RxPDO10*, Nd.23 | 1644 | 0x66C | RxPDO10*, Nd.44
1603 | 0x643 | RxPDO10*, Nd.3 | 1624 | 0x658 | RxPDO10*, Nd.24 | 1645 | 0x66D | RxPDO10*, Nd.45
1604 | 0x644 | RxPDO10*, Nd.4 | 1625 | 0x659 | RxPDO10*, Nd.25 | 1646 | 0x66E | RxPDO10*, Nd.46
1605 | 0x645 | RxPDO10*, Nd.5 | 1626 | 0x65A | RxPDO10*, Nd.26 | 1647 | 0x66F | RxPDO10*, Nd.47
1606 | 0x646 | RxPDO10*, Nd.6 | 1627 | 0x65B | RxPDO10*, Nd.27 | 1648 | 0x670 | RxPDO10*, Nd.48
1607 | 0x647 | RxPDO10*, Nd.7 | 1628 | 0x65C | RxPDO10*, Nd.28 | 1649 | 0x671 | RxPDO10*, Nd.49
1608 | 0x648 | RxPDO10*, Nd.8 | 1629 | 0x65D | RxPDO10*, Nd.29 | 1650 | 0x672 | RxPDO10*, Nd.50
1609 | 0x649 | RxPDO10*, Nd.9 | 1630 | 0x65E | RxPDO10*, Nd.30 | 1651 | 0x673 | RxPDO10*, Nd.51
1610 | 0x64A | RxPDO10*, Nd.10 | 1631 | 0x65F | RxPDO10*, Nd.31 | 1652 | 0x674 | RxPDO10*, Nd.52
1611 | 0x64B | RxPDO10*, Nd.11 | 1632 | 0x660 | RxPDO10*, Nd.32 | 1653 | 0x675 | RxPDO10*, Nd.53
1612 | 0x64C | RxPDO10*, Nd.12 | 1633 | 0x661 | RxPDO10*, Nd.33 | 1654 | 0x676 | RxPDO10*, Nd.54
1613 | 0x64D | RxPDO10*, Nd.13 | 1634 | 0x662 | RxPDO10*, Nd.34 | 1655 | 0x677 | RxPDO10*, Nd.55
1614 | 0x64E | RxPDO10*, Nd.14 | 1635 | 0x663 | RxPDO10*, Nd.35 | 1656 | 0x678 | RxPDO10*, Nd.56
1615 | 0x64F | RxPDO10*, Nd.15 | 1636 | 0x664 | RxPDO10*, Nd.36 | 1657 | 0x679 | RxPDO10*, Nd.57
1616 | 0x650 | RxPDO10*, Nd.16 | 1637 | 0x665 | RxPDO10*, Nd.37 | 1658 | 0x67A | RxPDO10*, Nd.58
1617 | 0x651 | RxPDO10*, Nd.17 | 1638 | 0x666 | RxPDO10*, Nd.38 | 1659 | 0x67B | RxPDO10*, Nd.59
1618 | 0x652 | RxPDO10*, Nd.18 | 1639 | 0x667 | RxPDO10*, Nd.39 | 1660 | 0x67C | RxPDO10*, Nd.60
1619 | 0x653 | RxPDO10*, Nd.19 | 1640 | 0x668 | RxPDO10*, Nd.40 | 1661 | 0x67D | RxPDO10*, Nd.61
1620 | 0x654 | RxPDO10*, Nd.20 | 1641 | 0x669 | RxPDO10*, Nd.41 | 1662 | 0x67E | RxPDO10*, Nd.62
1621 | 0x655 | RxPDO10*, Nd.21 | 1642 | 0x66A | RxPDO10*, Nd.42 | 1663 | 0x67F | RxPDO10*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1729 | 0x6C1 | TxPDO11*, Nd.1 | 1750 | 0x6D6 | TxPDO11*, Nd.22 | 1771 | 0x6EB | TxPDO11*, Nd.43
1730 | 0x6C2 | TxPDO11*, Nd.2 | 1751 | 0x6D7 | TxPDO11*, Nd.23 | 1772 | 0x6EC | TxPDO11*, Nd.44
1731 | 0x6C3 | TxPDO11*, Nd.3 | 1752 | 0x6D8 | TxPDO11*, Nd.24 | 1773 | 0x6ED | TxPDO11*, Nd.45
1732 | 0x6C4 | TxPDO11*, Nd.4 | 1753 | 0x6D9 | TxPDO11*, Nd.25 | 1774 | 0x6EE | TxPDO11*, Nd.46
1733 | 0x6C5 | TxPDO11*, Nd.5 | 1754 | 0x6DA | TxPDO11*, Nd.26 | 1775 | 0x6EF | TxPDO11*, Nd.47
1734 | 0x6C6 | TxPDO11*, Nd.6 | 1755 | 0x6DB | TxPDO11*, Nd.27 | 1776 | 0x6F0 | TxPDO11*, Nd.48
1735 | 0x6C7 | TxPDO11*, Nd.7 | 1756 | 0x6DC | TxPDO11*, Nd.28 | 1777 | 0x6F1 | TxPDO11*, Nd.49
1736 | 0x6C8 | TxPDO11*, Nd.8 | 1757 | 0x6DD | TxPDO11*, Nd.29 | 1778 | 0x6F2 | TxPDO11*, Nd.50
1737 | 0x6C9 | TxPDO11*, Nd.9 | 1758 | 0x6DE | TxPDO11*, Nd.30 | 1779 | 0x6F3 | TxPDO11*, Nd.51
1738 | 0x6CA | TxPDO11*, Nd.10 | 1759 | 0x6DF | TxPDO11*, Nd.31 | 1780 | 0x6F4 | TxPDO11*, Nd.52
1739 | 0x6CB | TxPDO11*, Nd.11 | 1760 | 0x6E0 | TxPDO11*, Nd.32 | 1781 | 0x6F5 | TxPDO11*, Nd.53
1740 | 0x6CC | TxPDO11*, Nd.12 | 1761 | 0x6E1 | TxPDO11*, Nd.33 | 1782 | 0x6F6 | TxPDO11*, Nd.54
1741 | 0x6CD | TxPDO11*, Nd.13 | 1762 | 0x6E2 | TxPDO11*, Nd.34 | 1783 | 0x6F7 | TxPDO11*, Nd.55
1742 | 0x6CE | TxPDO11*, Nd.14 | 1763 | 0x6E3 | TxPDO11*, Nd.35 | 1784 | 0x6F8 | TxPDO11*, Nd.56
1743 | 0x6CF | TxPDO11*, Nd.15 | 1764 | 0x6E4 | TxPDO11*, Nd.36 | 1785 | 0x6F9 | TxPDO11*, Nd.57
1744 | 0x6D0 | TxPDO11*, Nd.16 | 1765 | 0x6E5 | TxPDO11*, Nd.37 | 1786 | 0x6FA | TxPDO11*, Nd.58
1745 | 0x6D1 | TxPDO11*, Nd.17 | 1766 | 0x6E6 | TxPDO11*, Nd.38 | 1787 | 0x6FB | TxPDO11*, Nd.59
1746 | 0x6D2 | TxPDO11*, Nd.18 | 1767 | 0x6E7 | TxPDO11*, Nd.39 | 1788 | 0x6FC | TxPDO11*, Nd.60
1747 | 0x6D3 | TxPDO11*, Nd.19 | 1768 | 0x6E8 | TxPDO11*, Nd.40 | 1789 | 0x6FD | TxPDO11*, Nd.61
1748 | 0x6D4 | TxPDO11*, Nd.20 | 1769 | 0x6E9 | TxPDO11*, Nd.41 | 1790 | 0x6FE | TxPDO11*, Nd.62
1749 | 0x6D5 | TxPDO11*, Nd.21 | 1770 | 0x6EA | TxPDO11*, Nd.42 | 1791 | 0x6FF | TxPDO11*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1857 | 0x741 | RxPDO11*, Nd.1 | 1878 | 0x756 | RxPDO11*, Nd.22 | 1899 | 0x76B | RxPDO11*, Nd.43
1858 | 0x742 | RxPDO11*, Nd.2 | 1879 | 0x757 | RxPDO11*, Nd.23 | 1900 | 0x76C | RxPDO11*, Nd.44
1859 | 0x743 | RxPDO11*, Nd.3 | 1880 | 0x758 | RxPDO11*, Nd.24 | 1901 | 0x76D | RxPDO11*, Nd.45
1860 | 0x744 | RxPDO11*, Nd.4 | 1881 | 0x759 | RxPDO11*, Nd.25 | 1902 | 0x76E | RxPDO11*, Nd.46
1861 | 0x745 | RxPDO11*, Nd.5 | 1882 | 0x75A | RxPDO11*, Nd.26 | 1903 | 0x76F | RxPDO11*, Nd.47
1862 | 0x746 | RxPDO11*, Nd.6 | 1883 | 0x75B | RxPDO11*, Nd.27 | 1904 | 0x770 | RxPDO11*, Nd.48
1863 | 0x747 | RxPDO11*, Nd.7 | 1884 | 0x75C | RxPDO11*, Nd.28 | 1905 | 0x771 | RxPDO11*, Nd.49
1864 | 0x748 | RxPDO11*, Nd.8 | 1885 | 0x75D | RxPDO11*, Nd.29 | 1906 | 0x772 | RxPDO11*, Nd.50
1865 | 0x749 | RxPDO11*, Nd.9 | 1886 | 0x75E | RxPDO11*, Nd.30 | 1907 | 0x773 | RxPDO11*, Nd.51
1866 | 0x74A | RxPDO11*, Nd.10 | 1887 | 0x75F | RxPDO11*, Nd.31 | 1908 | 0x774 | RxPDO11*, Nd.52
1867 | 0x74B | RxPDO11*, Nd.11 | 1888 | 0x760 | RxPDO11*, Nd.32 | 1909 | 0x775 | RxPDO11*, Nd.53
1868 | 0x74C | RxPDO11*, Nd.12 | 1889 | 0x761 | RxPDO11*, Nd.33 | 1910 | 0x776 | RxPDO11*, Nd.54
1869 | 0x74D | RxPDO11*, Nd.13 | 1890 | 0x762 | RxPDO11*, Nd.34 | 1911 | 0x777 | RxPDO11*, Nd.55
1870 | 0x74E | RxPDO11*, Nd.14 | 1891 | 0x763 | RxPDO11*, Nd.35 | 1912 | 0x778 | RxPDO11*, Nd.56
1871 | 0x74F | RxPDO11*, Nd.15 | 1892 | 0x764 | RxPDO11*, Nd.36 | 1913 | 0x779 | RxPDO11*, Nd.57
1872 | 0x750 | RxPDO11*, Nd.16 | 1893 | 0x765 | RxPDO11*, Nd.37 | 1914 | 0x77A | RxPDO11*, Nd.58
1873 | 0x751 | RxPDO11*, Nd.17 | 1894 | 0x766 | RxPDO11*, Nd.38 | 1915 | 0x77B | RxPDO11*, Nd.59
1874 | 0x752 | RxPDO11*, Nd.18 | 1895 | 0x767 | RxPDO11*, Nd.39 | 1916 | 0x77C | RxPDO11*, Nd.60
1875 | 0x753 | RxPDO11*, Nd.19 | 1896 | 0x768 | RxPDO11*, Nd.40 | 1917 | 0x77D | RxPDO11*, Nd.61
1876 | 0x754 | RxPDO11*, Nd.20 | 1897 | 0x769 | RxPDO11*, Nd.41 | 1918 | 0x77E | RxPDO11*, Nd.62
1877 | 0x755 | RxPDO11*, Nd.21 | 1898 | 0x76A | RxPDO11*, Nd.42 | 1919 | 0x77F | RxPDO11*, Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1409 | 0x581 | SDO Tx Nd.1 | 1430 | 0x596 | SDO Tx Nd.22 | 1451 | 0x5AB | SDO Tx Nd.43
1410 | 0x582 | SDO Tx Nd.2 | 1431 | 0x597 | SDO Tx Nd.23 | 1452 | 0x5AC | SDO Tx Nd.44
1411 | 0x583 | SDO Tx Nd.3 | 1432 | 0x598 | SDO Tx Nd.24 | 1453 | 0x5AD | SDO Tx Nd.45
1412 | 0x584 | SDO Tx Nd.4 | 1433 | 0x599 | SDO Tx Nd.25 | 1454 | 0x5AE | SDO Tx Nd.46
1413 | 0x585 | SDO Tx Nd.5 | 1434 | 0x59A | SDO Tx Nd.26 | 1455 | 0x5AF | SDO Tx Nd.47
1414 | 0x586 | SDO Tx Nd.6 | 1435 | 0x59B | SDO Tx Nd.27 | 1456 | 0x5B0 | SDO Tx Nd.48
1415 | 0x587 | SDO Tx Nd.7 | 1436 | 0x59C | SDO Tx Nd.28 | 1457 | 0x5B1 | SDO Tx Nd.49
1416 | 0x588 | SDO Tx Nd.8 | 1437 | 0x59D | SDO Tx Nd.29 | 1458 | 0x5B2 | SDO Tx Nd.50
1417 | 0x589 | SDO Tx Nd.9 | 1438 | 0x59E | SDO Tx Nd.30 | 1459 | 0x5B3 | SDO Tx Nd.51
1418 | 0x58A | SDO Tx Nd.10 | 1439 | 0x59F | SDO Tx Nd.31 | 1460 | 0x5B4 | SDO Tx Nd.52
1419 | 0x58B | SDO Tx Nd.11 | 1440 | 0x5A0 | SDO Tx Nd.32 | 1461 | 0x5B5 | SDO Tx Nd.53
1420 | 0x58C | SDO Tx Nd.12 | 1441 | 0x5A1 | SDO Tx Nd.33 | 1462 | 0x5B6 | SDO Tx Nd.54
1421 | 0x58D | SDO Tx Nd.13 | 1442 | 0x5A2 | SDO Tx Nd.34 | 1463 | 0x5B7 | SDO Tx Nd.55
1422 | 0x58E | SDO Tx Nd.14 | 1443 | 0x5A3 | SDO Tx Nd.35 | 1464 | 0x5B8 | SDO Tx Nd.56
1423 | 0x58F | SDO Tx Nd.15 | 1444 | 0x5A4 | SDO Tx Nd.36 | 1465 | 0x5B9 | SDO Tx Nd.57
1424 | 0x590 | SDO Tx Nd.16 | 1445 | 0x5A5 | SDO Tx Nd.37 | 1466 | 0x5BA | SDO Tx Nd.58
1425 | 0x591 | SDO Tx Nd.17 | 1446 | 0x5A6 | SDO Tx Nd.38 | 1467 | 0x5BB | SDO Tx Nd.59
1426 | 0x592 | SDO Tx Nd.18 | 1447 | 0x5A7 | SDO Tx Nd.39 | 1468 | 0x5BC | SDO Tx Nd.60
1427 | 0x593 | SDO Tx Nd.19 | 1448 | 0x5A8 | SDO Tx Nd.40 | 1469 | 0x5BD | SDO Tx Nd.61
1428 | 0x594 | SDO Tx Nd.20 | 1449 | 0x5A9 | SDO Tx Nd.41 | 1470 | 0x5BE | SDO Tx Nd.62
1429 | 0x595 | SDO Tx Nd.21 | 1450 | 0x5AA | SDO Tx Nd.42 | 1471 | 0x5BF | SDO Tx Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1537 | 0x601 | SDO Rx Nd.1 | 1558 | 0x616 | SDO Rx Nd.22 | 1579 | 0x62B | SDO Rx Nd.43
1538 | 0x602 | SDO Rx Nd.2 | 1559 | 0x617 | SDO Rx Nd.23 | 1580 | 0x62C | SDO Rx Nd.44
1539 | 0x603 | SDO Rx Nd.3 | 1560 | 0x618 | SDO Rx Nd.24 | 1581 | 0x62D | SDO Rx Nd.45
1540 | 0x604 | SDO Rx Nd.4 | 1561 | 0x619 | SDO Rx Nd.25 | 1582 | 0x62E | SDO Rx Nd.46
1541 | 0x605 | SDO Rx Nd.5 | 1562 | 0x61A | SDO Rx Nd.26 | 1583 | 0x62F | SDO Rx Nd.47
1542 | 0x606 | SDO Rx Nd.6 | 1563 | 0x61B | SDO Rx Nd.27 | 1584 | 0x630 | SDO Rx Nd.48
1543 | 0x607 | SDO Rx Nd.7 | 1564 | 0x61C | SDO Rx Nd.28 | 1585 | 0x631 | SDO Rx Nd.49
1544 | 0x608 | SDO Rx Nd.8 | 1565 | 0x61D | SDO Rx Nd.29 | 1586 | 0x632 | SDO Rx Nd.50
1545 | 0x609 | SDO Rx Nd.9 | 1566 | 0x61E | SDO Rx Nd.30 | 1587 | 0x633 | SDO Rx Nd.51
1546 | 0x60A | SDO Rx Nd.10 | 1567 | 0x61F | SDO Rx Nd.31 | 1588 | 0x634 | SDO Rx Nd.52
1547 | 0x60B | SDO Rx Nd.11 | 1568 | 0x620 | SDO Rx Nd.32 | 1589 | 0x635 | SDO Rx Nd.53
1548 | 0x60C | SDO Rx Nd.12 | 1569 | 0x621 | SDO Rx Nd.33 | 1590 | 0x636 | SDO Rx Nd.54
1549 | 0x60D | SDO Rx Nd.13 | 1570 | 0x622 | SDO Rx Nd.34 | 1591 | 0x637 | SDO Rx Nd.55
1550 | 0x60E | SDO Rx Nd.14 | 1571 | 0x623 | SDO Rx Nd.35 | 1592 | 0x638 | SDO Rx Nd.56
1551 | 0x60F | SDO Rx Nd.15 | 1572 | 0x624 | SDO Rx Nd.36 | 1593 | 0x639 | SDO Rx Nd.57
1552 | 0x610 | SDO Rx Nd.16 | 1573 | 0x625 | SDO Rx Nd.37 | 1594 | 0x63A | SDO Rx Nd.58
1553 | 0x611 | SDO Rx Nd.17 | 1574 | 0x626 | SDO Rx Nd.38 | 1595 | 0x63B | SDO Rx Nd.59
1554 | 0x612 | SDO Rx Nd.18 | 1575 | 0x627 | SDO Rx Nd.39 | 1596 | 0x63C | SDO Rx Nd.60
1555 | 0x613 | SDO Rx Nd.19 | 1576 | 0x628 | SDO Rx Nd.40 | 1597 | 0x63D | SDO Rx Nd.61
1556 | 0x614 | SDO Rx Nd.20 | 1577 | 0x629 | SDO Rx Nd.41 | 1598 | 0x63E | SDO Rx Nd.62
1557 | 0x615 | SDO Rx Nd.21 | 1578 | 0x62A | SDO Rx Nd.42 | 1599 | 0x63F | SDO Rx Nd.63
dec | hex | Telegram type | dec | hex | Telegram type | dec | hex | Telegram type
1793 | 0x701 | Guarding Nd.1 | 1814 | 0x716 | Guarding Nd.22 | 1835 | 0x72B | Guarding Nd.43
1794 | 0x702 | Guarding Nd.2 | 1815 | 0x717 | Guarding Nd.23 | 1836 | 0x72C | Guarding Nd.44
1795 | 0x703 | Guarding Nd.3 | 1816 | 0x718 | Guarding Nd.24 | 1837 | 0x72D | Guarding Nd.45
1796 | 0x704 | Guarding Nd.4 | 1817 | 0x719 | Guarding Nd.25 | 1838 | 0x72E | Guarding Nd.46
1797 | 0x705 | Guarding Nd.5 | 1818 | 0x71A | Guarding Nd.26 | 1839 | 0x72F | Guarding Nd.47
1798 | 0x706 | Guarding Nd.6 | 1819 | 0x71B | Guarding Nd.27 | 1840 | 0x730 | Guarding Nd.48
1799 | 0x707 | Guarding Nd.7 | 1820 | 0x71C | Guarding Nd.28 | 1841 | 0x731 | Guarding Nd.49
1800 | 0x708 | Guarding Nd.8 | 1821 | 0x71D | Guarding Nd.29 | 1842 | 0x732 | Guarding Nd.50
1801 | 0x709 | Guarding Nd.9 | 1822 | 0x71E | Guarding Nd.30 | 1843 | 0x733 | Guarding Nd.51
1802 | 0x70A | Guarding Nd.10 | 1823 | 0x71F | Guarding Nd.31 | 1844 | 0x734 | Guarding Nd.52
1803 | 0x70B | Guarding Nd.11 | 1824 | 0x720 | Guarding Nd.32 | 1845 | 0x735 | Guarding Nd.53
1804 | 0x70C | Guarding Nd.12 | 1825 | 0x721 | Guarding Nd.33 | 1846 | 0x736 | Guarding Nd.54
1805 | 0x70D | Guarding Nd.13 | 1826 | 0x722 | Guarding Nd.34 | 1847 | 0x737 | Guarding Nd.55
1806 | 0x70E | Guarding Nd.14 | 1827 | 0x723 | Guarding Nd.35 | 1848 | 0x738 | Guarding Nd.56
1807 | 0x70F | Guarding Nd.15 | 1828 | 0x724 | Guarding Nd.36 | 1849 | 0x739 | Guarding Nd.57
1808 | 0x710 | Guarding Nd.16 | 1829 | 0x725 | Guarding Nd.37 | 1850 | 0x73A | Guarding Nd.58
1809 | 0x711 | Guarding Nd.17 | 1830 | 0x726 | Guarding Nd.38 | 1851 | 0x73B | Guarding Nd.59
1810 | 0x712 | Guarding Nd.18 | 1831 | 0x727 | Guarding Nd.39 | 1852 | 0x73C | Guarding Nd.60
1811 | 0x713 | Guarding Nd.19 | 1832 | 0x728 | Guarding Nd.40 | 1853 | 0x73D | Guarding Nd.61
1812 | 0x714 | Guarding Nd.20 | 1833 | 0x729 | Guarding Nd.41 | 1854 | 0x73E | Guarding Nd.62
1813 | 0x715 | Guarding Nd.21 | 1834 | 0x72A | Guarding Nd.42 | 1855 | 0x73F | Guarding Nd.63


Approvals

Appendix [image] Approvals
Approvals
(in preparation)


Bibliography

Appendix [image] Bibliography
Bibliography
German books
▪
Holger Zeltwander (Pub.):
CANopen,
VDE Verlag, 2001. 197 pages,
ISBN 3-800-72448-0
CANopen
▪
Konrad Etschberger:
Controller Area Network, Grundlagen, Protokolle, Bausteine, Anwendungen. (Principles, protocols, components, applications.)
Hanser Verlag, 2000. 431 pages.
ISBN 3-446-19431-2
General fieldbus technology
▪
Gerhard Gruhler (Pub.):
Feldbusse und Geräte-Kommunikationssysteme, Praktisches Know-How mit Vergleichsmöglichkeiten. (Fieldbus and Device Communication Systems, Practical Know-how with Comparative Resources).
Franzis Verlag, 2001. 244 pages.
ISBN 3-7723-5745-8
English books
▪
Konrad Etschberger:
Controller Area Network,
Ixxat Press, 2001. 440 pages.
ISBN 3-00-007376-0
▪
M. Farsi, M. Barbosa:
CANopen Implementation,
RSP 2000. 210 pages.
ISBN 00-86380-247-8
Controller Area Network,
Standards
▪
ISO 11898:
Road Vehicles - Interchange of digital information - Controller Area Network (CAN) for high speed communication.
▪
CiA DS 301:
CANopen Application Layer and Communication Profile.
Available from the CAN in Automation Association.
▪
CiA DS 401:
CANopen Device Profile for Generic I/O Modules.
Available from the CAN in Automation Association.


List of Abbreviations

Appendix [image] List of Abbreviations
List of Abbreviations
CAN
Controller Area Network. Serial bus system standardized in ISO 11898 that is used as the basic technology for CANopen.
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 initialize 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).


Support and Service

Appendix [image] Support and Service
Support and Service
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's branch offices and representatives
Please contact your Beckhoff branch office or representative for local support and service on Beckhoff products!
The addresses of Beckhoff's branch offices and representatives round the world can be found on her internet pages:
http://www.beckhoff.com
You will also find further documentation for Beckhoff components there.
Beckhoff Headquarters
Beckhoff Automation GmbH & Co. KG
Huelshorstweg 20
33415 Verl
Germany
Phone: | +49(0)5246/963-0
Fax: | +49(0)5246/963-198
e-mail: | info@beckhoff.com
Beckhoff Support
Support offers you comprehensive technical assistance, helping you not only with the application of individual Beckhoff products, but also with other, wide-ranging services:
▪
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-9157
e-mail: | support@beckhoff.com
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