Can-Interface en
Can-Interface en
CAN Interface
Interface for CANopen Master from Beckhoff
Table of contents
1 Foreword .................................................................................................................................................... 5
1.1 Notes on the documentation ............................................................................................................. 5
1.2 Safety instructions ............................................................................................................................. 6
1.3 Documentation Issue Status ............................................................................................................. 7
2 Introduction ............................................................................................................................................... 8
9 Appendix .................................................................................................................................................. 23
9.1 Support and Service........................................................................................................................ 23
1 Foreword
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
Patent Pending
The EtherCAT Technology is covered, including but not limited to the following patent applications and
patents: EP1590927, EP1789857, EP1456722, EP2137893, DE102015105702 with corresponding
applications or registrations in various other countries.
EtherCAT® is registered trademark and patented technology, licensed by Beckhoff Automation GmbH,
Germany.
Copyright
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
DANGER
Serious risk of injury!
Failure to follow this safety instruction directly endangers the life and health of persons.
WARNING
Risk of injury!
Failure to follow this safety instruction endangers the life and health of persons.
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.
2 Introduction
Almost all CANopen masters from Beckhoff offer the so-called CAN interface. The CAN interface is a
Layer-2 implementation of the CAN interface. It enables any desired CAN telegrams to be received and
transmitted. The higher-level protocol is not important here, i.e. all CAN-based protocols can be used;
however the protocol part must then be implemented in the PLC.
The CAN interface consists of a buffer that is processed cyclically. The buffer can contain 11 to 32 data
telegrams.
The transmit buffer (Tx) contains the data to be transmitted and the receive buffer (Rx) the data that have
been received. 11-bit or 29-bit messages can be received or transmitted, depending on the CAN master. The
buffer is processed with the cycle time of the task. With a buffer size of 10, therefore, a maximum of 10 CAN
telegrams can be transmitted or received per task cycle.
1
) not in 29-bit mode, not with Transaction Number [} 12]
2
) only in 29-bit mode and with Transaction Number [} 12]
3
) only in 29-bit mode
4
) covered by the 29-bit ID option
5)
in preparation
CCAT
What is CCAT? Which Beckhoff products is it backed by?
The CCAT interface is the Beckhoff company's current CAN implementation and is used by the
Beckhoff PCI-Express cards and the onboard interfaces of the Beckhoff Embedded PCs. These
are, for example, the following products and only available for the CANopen Master:
FC512x, C20xx-M510, CX8x50, CX9x20-M510, CX51xx-M510
3 Integration in TwinCAT
If you have created a CANopen master in TwinCAT, you can select the CAN interface instead of CANopen
slaves.
You will then be requested to select the appropriate interface that you wish to use, or the size of the buffer. If
you change the interface again later on, please note that it is usually the case that, depending on the mode,
the interface is set up again and links are thus deleted. Also, select only modes that your hardware actually
supports (see Table CAN Interface – supported functions).
The CCAT CAN master has a memory for 512 messages, the EL6751 for 150 messages (RxMessages). The
data will be lost if they are not fetched quickly enough from the memory. No indication is given, therefore the
worst case should or must be estimated, or the variable NoOfRxMessages should as far as possible be
smaller than the maximum buffer value. If this is always or in almost every cycle at the maximum value, then
this indicates that more data are being received than can be recorded per cycle. Remedy: Shorten the task
cycle time or enlarge the buffer of the CAN queue.
Example
A CAN telegram with 11-bit identifier and 8 bytes of user data needs about 260 µs at 500 Kbit/s. If one
assumes a 100% bus load in the worst case, it would be maximally 3 telegrams with 1 ms. This means that a
buffer of maximally 4 would be adequate in this case. If a task time of 5 ms is used instead of 1 ms, the
buffer should be at least 20 (5000 µs / 260 µs). It must be remembered here that in this study only the data in
one direction are considered and that the CAN data always have 8 bytes. Since a 100% bus load is not
usually assumed, one can also evaluate the variable NoOfRxMessages and see whether it lies in most
cases below the maximum number of buffers created. If NoOfRxMessages is often at the maximum value,
the task time should be shortened or the buffer enlarged.
Worst case
However, the CAN interface is designed such that, as a rule, the data can always be fetched faster than they
run into the buffer.
Example
1 MBaud data length 0 means 50 µs per CAN message. With a 1 ms task time this would be
1000 µ / 50 µs = 20
This means that even in this extreme worst case a buffer of 20 would be adequate to receive all CAN
telegrams.
1)
Data from CIA
5 Functionalities
The received messages no longer have to be confirmed. The EL6751 increments the RxCounter when new
messages are received.
In the transmission direction too, only the data dependent on the changed TxCounter and the
NoOfTxMessages are copied, so that the number of parallel messages in the queue actually have no further
influence on the runtime (only the NoOfTxMessages).
Since the EL6751 operates in 3-buffer mode (so that it always has a buffer in which it can copy the CAN
messages received), it may be the case that the unused messages contain incorrect or old data.
The object directory can be read on the CoE-Online tab. If the index 0x1C32:08 has been/is set to 1, the
local cycle time of the EL6751 is measured and stored in index 0x1C32:05 (maximum value). You can thus
see whether the EL6751 will be finished within the EtherCAT cycle.
The Fast CAN Queue may not contain further CANopen or CAN-Layer-2 nodes.
The following applies to both functions, Fast CAN Queue and Optimized CAN Queue:
Advantages
• Higher processing speed
• The Fast CAN Queue does without all attachments and is thus predestined for the fastest processing/
reaction of the data from the bus.
Disadvantages
• Both modes support only 11-bit identifiers.
• No filters may be used.
The interface consists of the communication with the interface and up to 32 CAN messages. The inputs can
only be read if the outputs are written.
Outputs.TxCounter is set to +1 if data are to be transmitted. NoOfTxMessages also indicates how many
messages are to be transmitted from the buffer. The RxCounter indicates whether there are new data in the
buffer. NoOfRxMessages indicates how many new data are in the buffer.
If you have fetched the data, then set Outputs.RxCounter:=Inputs.RxCounter. The CAN interface then knows
that it can fill the buffer again. All data must always be read out, because the CAN interface fills all message
structures again when necessary.
The message structure when using the 11-bit identifier consists of the COB ID [2 bytes] and the 8 bytes of
data. The COB ID has the following structure:
• Bit 0-3: Length of the data (0…8)
• Bit 4: RTR
• Bit 5-15: 11-bit identifier
Since COB ID, length and RTR bit are coded in one word in the 11-bit identifier, the following example is
helpful for decoding the data from the word. Select a structure here in which to store the decoded data.
IF RXCounter_Out <> RXCounter_In THEN
FOR I := 0 TO (NoOfTxMessages-1) DO
stCANInterfaceMessageValue[i].Lengh:=WORD_TO_BYTE(stCANInterfaceMessage[i].CobID) AND 16#0F;
stCANInterfaceMessageValue[i].RTR:=stCANInterfaceMessage[i].CobID.4;
stCANInterfaceMessageValue[i].CobID :=ROR(stCANInterfaceMessage[i].CobID,5) AND 16#07FF;
stCANInterfaceMessageValue[i].Data := stCANInterfaceMessage[i].Data;
CASE stCANInterfaceMessageValue[i].CobID OF
16#318: COB318:=COB318+1;
16#718: COB718:=COB718+1;
16#1CD: COB1CD:=COB1CD+1;
memcpy(ADR(TempValue),ADR(stCANInterfaceMessage[i].Data[6]),2);
16#1ED: COB1ED:=COB1ED+1;
ELSE
COBALLOther:=COBAllOther+1;
END_CASE
End_for
RXCounter_Out:=RXCounter_In;
END_IF
The message structure when using the 29-bit identifier consists of the length [2 bytes] of the COB ID [4
bytes] and the 8 bytes of data.
7 Use of a filter
If you don't wish to receive all the telegrams in the CAN interface, there is an option to set filters. This
reduces the number of CAN telegrams in the CAN interface and thus permits only those telegrams that are
actually required.
Acceptance:
The identifiers that are to be forwarded to the CAN interface are entered here.
Rejection:
The identifiers that are not to be forwarded to the CAN interface are entered here.
Acceptance mask:
Here you can specify at bit level which identifiers are to be forwarded to the CAN interface.
In the example, all the telegrams from identifier 0x0400 … 0x0700 are transmitted into the CAN interface.
This is displayed with a "+" next to Info.
"+" means that the filter lets the data through to the CAN interface (Acceptance)
"-" means that the filter does not let the data through to the CAN interface (Rejection)
The operation of this CAN interface as well as the functions Transactions-Number and Timestamp
correspond to that of the known interface (see chapter Structure of the CAN interface [} 13]).
New are the message data type of the RX and TX queue and the baud rate setting.
The baud rates for CAN FD can be set differently for the arbitration phase and the data transmission phase.
Likewise, it is still possible to set the same baud rate for both phases as with classic CAN.
The first number indicates the baud rate for the arbitration phase and the second for the data phase.
TYPE CANFDTXQUEUE :
STRUCT
transactionNumber : UINT;
dataLenght : BYTE;
EDL : BIT;
BSR : BIT;
ESI : BIT;
cobId : UDINT;
txData : CANFDMESSAGE;
END_STRUCT
END_TYPE
TYPE CANFDMESSAGE :
ARRAY [0..63] OF USINT;
END_TYPE
These structures are available for the IOs in the System Manager as well as in the PLC.
If the lengths do not correspond to these values during transmission, they are adjusted to the next higher
value by the device.
For a CAN FD frame the values 0 to 15 are valid for the DLC field. The value of the DLC field determines the
number of bytes in the data field and is interpreted in the following way:
The CAN interface does this conversion automatically, i.e. in the CAN interface you only specify the actual
number of bytes (values from 0..64 bytes are allowed).
The conversion to the DLC values is then performed by the CAN interface in the background with the next
larger DLC value.
Example: if you enter the data length 32 in the CAN interface, 36 bytes are sent with the DLC value 13.
EDL
The EDL (Enhanced Data Length) bit is used to control whether an FD or a classic frame is to be sent or
what kind of frame was received.
BSR
The BSR (Bit Rate Switched) bit specifies whether in the data phase should be switched to the higher baud
rate or how the frame was received.
ESI
The bit ESI (Error State Indicator) indicates whether there was (Rx) or is (Tx) an error with the frame.
8.3.3 InfoData
The following data can be read from the info data of the FC532x / CX-M530:
Fig. 15: InfoData
9 Appendix
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: https://www.beckhoff.com
You will also find further documentation for Beckhoff components there.
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 5246 963 157
Fax: +49 5246 963 9157
e-mail: [email protected]
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 5246 963 460
Fax: +49 5246 963 479
e-mail: [email protected]
Beckhoff Headquarters
Huelshorstweg 20
33415 Verl
Germany
Phone: +49 5246 963 0
Fax: +49 5246 963 198
e-mail: [email protected]
web: https://www.beckhoff.com