CAN-based systems are frequently used in special purpose machinery – both in standardized protocols such as CANopen and in proprietary solutions. The advantages of CAN-based machine networking are the simple data structure in the network, inexpensive and highly flexible implementation, easy extensibility of existing networks and convenient analysis of the system in the event of a failure.
Possible Applications for 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 fulfil: 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.
Improved Data Rate
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 retransmitted 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.
In this example, configuration data totalling 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.
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.
This figure shows the CAN messages displayed in Fig. 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 behaviour 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!