email@example.com +46 35 17 29 56
HMS products and services enable you to...
IXXAT PC CAN interfaces support both, classic CAN and the new CAN FD standard. Using the VCI Windows driver PC based applications can be easily developed.
PC CAN Interfaces for CAN FD
For the interconnection of CAN and CAN FD based systems HMS offers a large product portfolio
We offer a wide range of tools for your development, system commissioning and for trouble-shooting.
canAnalyser for CAN and CAN FD
The growing demands in the number of nodes, transfer rates and cycle times lead to bottlenecks that the limitations of classic CAN (8 data bytes and 1 Mbit/s data rate) cannot fulfill: The data rate that depends on the network expansion and the short data length for service and analogue data play a particular role here.
In daily use, these limitations are often circumvented by means of compromises: The division of the system into different network segments in various applications – or even into parallel networks – means that the existing technology is constantly being exhausted, which has often led to solutions that are complex and expensive in terms of configuration, setup and maintenance. In principle, a switch to high-performance industrial Ethernet technologies would be possible. The increased level of investment usually necessary and the change in the data structures and mode of thinking for the configuration, in particular for time-controlled systems, often represent a considerable challenge in extensive networks. In addition, a switch in tools for development, commissioning and service is necessary, which often deters many users from a complete conversion.
At the same time, there is a desire to continue to use existing know-how in a useful manner.
This is where CAN FD plays a role: CAN FD (CAN with flexible data rate) is an extended version of the well-known "classic" CAN introduced by Bosch in 2012 and that significantly extends the usable data rate and usable data length. On the other hand, tried-and-tested CAN concepts have been retained: arbitration based on message IDs, event-driven dispatch of messages and acknowledgement of messages received by means of the acknowledgement bit.
Message acknowledgement by receivers, which is used in classic CAN, offers a wide range of advantages by means of confirming the success of the transmission within the transmitted message – potential transmission errors are quickly detected and the data can be re-transmitted extremely quickly.
Arbitration of the messages based on the CAN identifier also offers advantages for control applications by avoiding collisions during data transmission and providing short latency times for high-priority messages even at higher bus loads.
The disadvantage of the methods used is that at sampling time the same bus level must exist at all nodes to avoid faults. Accordingly, a bit interval must make sufficient signal propagation time available between the two most remote nodes in a network, including their bus activation. The bit interval and consequently also the data rate are thus directly dependent on the network extension; at an expansion of 40 m up to 1 Mbit/s is possible, but at 250 m extension this drops to as low as 250 kBit/s.
To significantly increase the data rate without changing the existing communications technology, CAN FD works with two different bit rates. The "arbitration rate" for the control commands (including arbitration, message type, end detection and acknowledgement) is dependent on the propagation speed and thereby on the network extension. By contrast, a second "data bit rate" is optionally also used – for the data content and data security. At this point in time, only the message transmitter occupies the bus, which means that direct feedback within the bit time is unnecessary. The maximum achievable data rate is therefore only dependent on the transmission characteristic of the transmission medium, and not the signal propagation. CAN FD networks currently enable productive use with 8 MBit/s, whereby the CAN FD standard permits up to 15 Mbit/s. This bit rate has also been successfully used in various test systems.
Picture 1: In this example, configuration data totaling 42 bytes is transmitted. To do this in classic CAN, a transport protocol must be implemented to be able to transmit the entire data quantity in 8-byte messages. The example is based on a model transport protocol that only uses the first data byte for controlling the data stream. This means that up to 7 bytes are still available for each CAN message. Depending on the transport protocol implemented, additional data fields can be necessary for control.
Below this, by comparison, a single CAN FD message with 48 bytes of user data, which can replace the 6 classic CAN messages required. As the data is also transmitted at a higher bit rate in the CAN FD message shown above, this CAN FD message needs significantly less bus time than the classic CAN messages. In addition, the use of a single CAN FD message here significantly simplifies the administration of the data stream.
The two data rates are set independently of one another in the CAN FD controller using two bit timing registers. Switching between the two data rates is performed using two control bits in the protocol. The first bit reserved up till now is used as the "Extended Data Length" bit (EDL), and defines a CAN FD message due to its recessive level. The actual bit rate switch is performed by a newly added bit, the "Bit Rate Switch" bit (BRS), in which a switch to the higher bit rate is made at sampling time. Switching back is performed at the time that the CRC restriction bit is sampled.
The control data is still transmitted using the well-known lower bit rates, thereby limiting the achievable data rates. By increasing the user data area to up to 64 bytes, more data can be sent in fast transfer mode, thereby effectively increasing the data rate.
Classic CAN provides only 8 data bytes, which is no longer sufficient for many data applications, e.g. for transmitting high-precision analogue values or for controlling a multi-axle robot with its diverse encoding values and drive commands. To this, service data must also be added, which up to now has significantly reduced the effectiveness due to the transport protocols required for transmission of more than 8 bytes.
CAN FD now provides the option to use up to 64 data bytes. In so doing, larger data blocks can be transmitted in a single message – particularly in the case of process data, more complex devices can now be completely controlled using only a single process message. For service data, the necessity for transport protocols is reduced, as a single CAN FD message is often only required for configuration data and similar.
Picture 2: This figure shows the CAN messages displayed in picture 1 in a single timeline: for classic CAN a data rate of 250 kBit/s is assumed here. For messages with 8 bytes of user data (1 byte for the transport protocol and 7 bytes of user data in the example) and the maximum possible number of stuff bits, a classic CAN message requires around 500 µs bus time. If the transmitting node is able to send all six messages consecutively without delay, the bus will be completely blocked for three milliseconds for transmitting the 42 bytes of user data.
By comparison, a CAN FD message with 48 bytes of user data, 250 kBit/s arbitration rate and 2 MBit/s data bit rate occupies the bus for only approx. 365 µs – also with the maximum number of stuff bits.
The significantly quicker data transmission also improves the real-time behavior of CAN systems due to the markedly shorter response times, and at the same time increases the data rate and reduces the complexity of data administration!
To prevent extending the control data unnecessarily, CAN FD also uses only 4 bits for the data length code – the values 0 to 8 are taken directly from classic CAN. The values that were up to now undefined (9 to 15, i.e. 1001 to 1111) are used for the new, extended data lengths: besides 0 to 8 bytes, 12, 16, 20, 24, 32, 48 and 64 bytes are now also available for the user data. Data lengths that differ form these are not possible, that is, unused areas must be padded with "filler values".
Besides the fast transmission of the data area, the effectively usable data rate can be significantly increased using CAN FD, and the cycle time can be considerably reduced. In this manner, a CAN FD network with 500 kBit arbitration, 4 MBit data transmission and 64 data bytes can achieve an effective data rate of over 5 MBit/s.
The combining of multiple independent data packets into a single message means that data administration is made considerably simpler, as the individual messages no longer need to be synchronized with one another at great cost. The fast transmission of larger data packets by comparison to classic CAN enables transfer of 8 times the data volume (64 bytes) in roughly the same time that would be required for a classic 8-byte CAN message. In this way, high-priority messages can be transmitted much more quickly and the real-time capability improved.
Data security is an important topic: Despite the increased data packet size in comparison to classic CAN, CAN FD fulfills the same requirements in respect of data security. This is achieved by using longer CRC check keys with adapted algorithms, for example. Depending on the number of data bytes transmitted, one of three different CRC algorithms is used: the previous CRC formula for messages with up to 8 data bytes, as well as two enhanced algorithms with up to 16 data bytes or more than 16 data bytes for messages. The algorithm to be used by the CAN controller is determined by the data length code.
For improved data security, additional suggestions have been implemented. As a result, the CRC in CAN FD messages always starts with a stuff bit; after another 5 bits an additional stuff bit is included – contrary to the CAN stuff bit rule, this is independent of the bit values of the previous bits. Each stuff bit has the complementary value of the previous bit.
One disadvantage of switching from CAN to faster communications systems is the frequent requirement for a complete conversion: All CAN participants must be adapted to the new system, e.g. EtherCAT. Alternatively the machine controller can be extended to use multiple heterogeneous networks. Both procedures offer advantages and disadvantages. Using CAN FD, an additional "gentler" option is now also available: As CAN FD controllers can be used as classic CAN nodes as well, all network nodes can be gradually replaced by CAN FD-capable devices. As soon as the entire network is CAN FD-capable, the advantages of CAN FD can be used to the fullest extent. This is of particular interest for special purpose machinery, as network participants that cannot be replaced by freely available nodes are often also used here – in particular customer-specific devices or internally developed devices.
Customized OEM solutions
and development services