Open search
Advertisement

CAN Newsletter magazine

Injector and scanner communication

After release of the CAN FD based CiA 1301 (CANopen FD) specification in 2017, it is time to look at the benefits, which can be offered for communication between injector and scanner as defined in CiA 425-1 and CiA 425-2 for CANopen.

Table 1: Classical CAN MAC data frame (Source: Bayer)

The complete article is published in the December issue of the CAN Newsletter magazine 2020. This is just an excerpt.

Compared with the Classical CAN (ISO 11898-1:2003), CAN FD (ISO 11898-1:2015) offers the following improvements. It supports bit-rates higher than 1 Mbit/s (up to 5 Mbit/s are currently specified). CAN FD supports payloads longer than 8 byte (up to 64 byte). CAN FD (CAN with flexible data-rate) frames can use a lower bit-rate during the arbitration phase, and switch to a pre-determined higher bit-rate during the data phase.

Compared to CANopen (CiA 301, based on Classical CAN as the data link layer), CANopen FD (CiA 1301, based on CAN FD) has the following aspects improved:

  • CiA 1301 revamps the classic SDO (service data object) services, which were limited to unicast within the local CAN network. The new SDO service is called USDO (universal SDO), which additionally supports remote services in unicast and broadcast. A remote service refers to a USDO client requesting a USDO upload or download from one USDO server (unicast) beyond the local CAN FD network or all USDO servers (broadcast) in all CAN FD networks inter-connected via CAN FD routers.
  • CiA 1301 supports PDOs of up to 64 byte in payload length.
  • CiA 1301 extends the EMCY protocol from 8 byte to 20 byte, carrying more error-relevant information (e.g. time-stamp).
Table 2: CAN FD MAC data frame (Source: Bayer)

CAN FD

A Classical CAN data frame and a CAN FD data frame of the base format (11-bit CAN-ID) at the MAC (medium access control) sub-layer of the DLL (data link layer) are shown in table 1 and table 2. The related acronyms are shown in table 3.

The RTR bit at end of the arbitration field in Classical CAN is transmitted dominant (0) in data frames, and recessive (1) in remote frames. In CAN FD, however, remote frames are no longer supported, so the RTR bit becomes reserved (r1), and CAN FD transmitters always transmit this bit dominant.

In Classical CAN, the control field takes up six bit: 1-bit IDE, 1-bit reserved (r0), and 4-bit DLC. CAN FD extends the control field to nine bits (highlighted in table 2) and uses the reserved bit for the FDF. In Classical CAN and CAN FD, a reserved bit is transmitted as a dominant bit. In CAN FD, the FDF bit is recessive. This is how a CAN FD controller can differentiate between a Classical CAN data frame and a CAN FD data frame, so that a CAN FD controller can “down- grade” into a CAN controller able to receive Classical CAN data frames. A Classical CAN controller is not able to handle CAN FD frames. It can be implemented, however, to tolerate CAN FD frames.

The three new bits are 1-bit reserved (r0), 1-bit BRS, and 1-bit ESI. If BRS is dominant, no bit-rate switch occurs for the data phase. Otherwise a higher bit-rate is used for the data phase. The ESI bit represents the error state of the transmitter, with dominant bit as error free and recessive bit as error active. In CAN FD, DLC continues to have four bits, which can normally represent a maximum value of 16. Therefore, a special encoding is required (see table 4) to represent payloads longer than 16 byte.

Table 3: Acronym description for table 1 and table 2 (Source: Bayer)

As shown in table 4, not every pay- load length can be represented. Specifically, the possible payload lengths are 0 to 8, 12, 16, 20, 24, 32, 48, and 64 byte. Any application payload that is not in one of those lengths must be padded with dominant bits to the next length.

In a Classical CAN data frame, the CRC field takes up 16 bit, with a 15-bit CRC sequence and a 1-bit delimiter (del). With payload length increased by 8 times, CAN FD extends the CRC sequence to 17 bit (for payloads of up to 16 byte), or 21 bit (for payloads between 20 and 64 byte). To further improve transmission reliability, the CRC field is bit-stuffed with a scheme called fixed bit-stuffing. The bit-stuffed CRC sequence is prepended with a stuff-bit counter (SBC), which consists of a 1-bit FSB (fixed stuff bit), 3-bit count (CNT), containing the number of stuff bits in the CRC sequence, and a 1-bit parity (PTY). The CRC sequence also starts with an FSB, followed by a 4-bit CRC segment, then another FSB and 4-bit CRC segment, and so on until all CRC bits are exhausted. The FSB code is always the oppo- site of its previous bit. This CRC bit-stuffing scheme makes the whole CRC field 28 bit or 33 bit long depending on the payload length, as shown in table 5 and table 6, respectively.

Table 4: DLC encoding in CAN FD (Source: Bayer)

CANopen FD (CiA 1301)

CiA 1301 specifies the basic communication layer on top of the CAN FD data link layer and is the basis for the CANopen FD specifications. There are some differences in comparison with the CiA 301 CANopen specification. The most significant difference in CiA 1301 is the redesigned SDO (service data object) protocols called USDO (universal SDO). According to CiA 301, up to 128 server SDOs with CAN-IDs defined by objects 1200h to 127Fh could be configured in an SDO server's OD (object dictionary). Up to 128 client SDOs (CAN-IDs defined in 1280h to 12FFh) could be configured as well. The USDO CAN-IDs are not configurable. Therefore, objects 1200h to 12FFh are reserved in CiA 1301. Instead, USDO adds the destination address field to its requests and responses. The CAN-ID for a request from a USDO client is always 600h + client's node-ID, and the CAN-ID for a response from a USDO server is always 580h + server's node-ID. In case of the USDO abort protocol the CAN-ID 600h + client node-ID is used, if the USDO client issues the USDO abort transfer. In case a USDO server issues the USDO abort transfer, the CAN-ID is 580h + server node-ID.

Table 5: Bit-stuffed CRC field (payload ≤ 16 bytes) (Source: Bayer)

SDO services (in CiA 301) are local (within the same CANopen network) and only possible in unicast (between one SDO client and one SDO server). The USDO additionally supports remote services between different CANopen FD networks. The local and remote services are possible in unicast and broadcast. The data sent in one USDO upload response (read data) or a USDO download request (data to be written) can have a size of up to 56 byte. This means a 14 times higher throughput compared to the expedited SDO transfer in CANopen. However, the redesigned USDO protocol proves that CiA 1301 is not backward compatible with CiA 301. Device OEMs (original equipment manufacturer) that plan to upgrade their CAN device to a CAN FD device will have to upgrade their CiA-301-compliant CANopen stack to a CiA-1301-compliant CANopen FD stack.

Table 6: Bit-stuffed CRC field (20 ≤ payload ≤ 64 bytes) (Source: Bayer)

A PDO (process data object) in CiA 1301 can carry up to 64 byte of payload. Since the PDO mapping parameters (0021h) already allowed up to 64 object elements to be mapped to one PDO in CiA 301, there is no change regarding the PDO mapping parameters. In CiA 1301, the object elements are interpreted as 64 object elements with one-byte length each, instead of one bit as in CiA 301. In other words, the level of granularity for PDO mapping is 8 bit in CiA 1301, and one bit in CiA 301. The PDO communication parameters (0020h) are not changed either.

If you would like to read the full article you can download it free-of-charge or you download the entire magazine.

cw

Publish date
2020-12-07
Company

Bayer US
CAN Newsletter magazine

Breadcrumb