CAN bus in industrial networks. CAN bus description

CAN interface(Controller Area Network, local network of controllers) is designed to organize highly reliable and inexpensive communication channels in distributed systems management. It allows you to build both cheap multiplex channels and high-speed networks.

Currently, the CAN interface is widely used in many areas, including industrial automation and aerospace instrumentation. CAN interface
(or CAN-Bus) is most often used as link between the main line of the control device and many auxiliary sensors, mechanisms, etc., the connection of which to the central line is not always advisable.

The CAN protocol, developed by Bosch, was originally designed for the needs of the automotive industry and turned out to be so successful that it is now widely used.

The CAN protocol is characterized by increased noise immunity, reliability and has the following capabilities:

configuration flexibility;

receiving messages by all nodes with time synchronization;

non-destructive bus access arbitration;

multimaster mode;

error detection and error reporting;

automatic transmission of fault messages when the opportunity to re-access the bus is obtained;

the difference between random errors and permanent node failures with the ability to turn off defective nodes;

works over twisted pair cable at a distance of up to 1 km.

Typical examples of the use of a CAN network are monitoring and control systems for textile equipment produced by Cezoma, Lindauer Dornier, Rieter,
Schlafhorst, Sulzer.

Other important areas of network application include industrial automation and robot control systems. ABB, Bosch, Engel and other companies are already using CAN in their equipment. Edeka uses CAN in its logistics center Building automation and life support systems cannot do without the use of CAN technologies, where they are used in air conditioning control (Colt
International), temperature maintenance (Buderus), integrated control of the condition of premises and lighting.

The CAN interface is a serial bus that supports simultaneous operation of many master devices, which means that all CAN network nodes can transmit data and request the bus to multiple nodes simultaneously.

Devices in the CAN system are connected via a bus consisting of three wires (2 signal and one common).

Data messages sent from any node over
CAN bus, can contain from 1 to 8 bytes. Each message is tagged with an identifier that is unique on the network (for example, “Heating to 240,” “Heating Failure,” “Bin Loaded,” etc.). During transmission, other nodes on the network receive the message, and each of them checks the identifier. If the message is related to this node, then it is processed, otherwise it is ignored. The CAN controller of each device can process several identifiers simultaneously (for example, Siemens controllers and Intel can handle up to 15 identifiers). Thus, in each of the devices you can easily organize several virtual channels for exchanging information with various devices, including channels for simultaneous receipt of messages.

The identifier determines the type and priority of the message. A lower numerical ID value corresponds to a higher priority value. A message with a higher priority is transmitted before a message with a lower priority. After a high priority message, a lower priority message is transmitted if the higher priority message is not remembered during transmission; then a message with an even lower priority is transmitted, etc.

CAN contains a 5-stage error detection mechanism:

cyclic redundancy check (CRC);

control of the transmitted bit field;

control of the “Reception confirmation” signal;

current control of logical bit level;

bit filling control.

If an error is detected, the node that detected the error interrupts the transmission by sending an error flag. In this case, the transmitter automatically retransmits the message, which protects all nodes from errors and guarantees the consistency of data in the network.

The physical layer of the CAN interface is defined by the ISO 11898 standard and is characterized by the following capabilities: differential switching of transceivers provides suppression of common-mode interference, while the signal level is 1/3 of the supply voltage, and the supply voltage itself is not strictly defined.

For example, typical values ​​​​at a supply voltage of +5 V are shown in Fig. 5.18, with the dominant level being the lower level, and the recessive, respectively, the upper;

maximum distance between nodes – up to 1 km;

exchange speed up to 1 Mbit/s with a line length of 60 m;

the possibility of using galvanic isolation, and galvanic isolation can be installed either between the transmit-receive buffer and the microcircuit that provides

CAN functions, or between the chip and the rest of the system (Fig. 5.19).

The CAN protocol defines the following: frame types:

a data frame moves data from the transmitter to the receiver(s);

the remote frame requests the transmission of a data frame associated with a specific identifier;

The error frame expresses which node detected the bus/network error;

The congestion frame provides a delay between frame transmissions to control data flow.

Rice. 5.18. Signal levels on the CAN bus

Rice. 5.19. Two types of galvanic isolation

Let's take a closer look at the data frame (Fig. 5.20).

Rice. 5.20. Data frame control field (end)

It consists of a SOF start field, an Arbitration Field, a Control Field, a Data Field, CRC checksum fields, ACK Field, EOF fields.

The SOF (Start of Frame) field is located at the beginning of the data frame and remote frame and contains one dominant bit.

The Arbitration Field contains an 11-bit identifier and an RTR bit indicating whether the frame is a data frame or a remote frame. The identifier is intended for addressing messages and is used by the arbitration mechanism.

The Control Field (see Fig. 5.20) contains
6 bits, of which 4 bits (DLC0-DLC4) constitute the Data Length Code field, indicating the number of data bytes that will be transmitted in the data field; the other two bits are reserved for future protocol revisions.

The Data Field contains the transmitted data, and the number of transmitted bytes is indicated in the Control Field and cannot exceed 8.

The CRC field provides a redundant parity mechanism for transmitted data.

The ACK Field confirmation field (see Fig. 5.21) contains the ACK Slot and ACK Delimiter sections and performs next function: The transmitting node sends one recessive bit in each section, and the receiver, if it received the message without failure, sets the dominant bit in the ACK Slot field on the line. When the recessive and dominant levels overlap, the dominant one is established on the line, and this event signals to the transmitting node that the transmission was normal and no repetition is required.

The EOF field is contained in the data frame and the remote frame and consists of seven recessive bits.

Rice. 5.21. Data frame confirmation field

The remote frame is similar in structure to the data frame, but does not have a data field, and the error frame and overload frame each contain two fields: the first contains error flags and service information, and the second is the Delimiter field and contains eight recessive bits.

The transmitting node in the CAN protocol identifies all other nodes in the network and confirms this. Whenever the bus is clear of transmission, the node can begin transmitting. If a node transmits, that transmission must be completed before another node can attempt to transmit. If two or more nodes start transmitting at the same time, the conflict is resolved using a non-destructive bitwise arbitration algorithm using an arbitration field.

The arbitration field included in all data frames consists of: an 11-bit identifier field; RTR bit.

The RTR bit indicates whether the frame is a data frame or a remote frame.

The 11-bit identifier field is passed from most significant to least significant bit. The dominant level is logic 0. Simultaneously transmitting a bit with a dominant level (logical 0) and a bit with a recessive level (logical 1) results in a logic 0 level.

During arbitration field transmission, each transmitter monitors the current level on the bus and compares this with the bit it should transmit. If the values ​​are equal, the node is then able to continue transmitting. If a passive bit (logical 1) has been transmitted and an active bit (logical 0) is detected on the bus, then that node loses the right to transmit and must stop transmitting subsequent data (Figure 5.12). A node that has lost its bus can attempt transmission again when the current transmission is completed.

The important thing is that the ID with the lowest value wins the arbitration.

CAN is a protocol designed for use in noisy environments. Various messages transmitted over the network have an identifier, and each station decides, based on this identifier, whether to receive that message or not. This identifier is defined in the CAN frame identifier field.

In this case, the receiver address is set in the receiver itself by adjusting the input filters of the corresponding microcircuits.

Input filters are sieves, or identification screens. Any message that passes through the input filters must be processed by the CAN controller service processor. The more units that can be filtered, the less load on the processor.

Chips that support the CAN protocol may have a single filter or multiple filters, depending on the specific implementation. There are the following two types of input filters:

fixed – filters that require the bits to match exactly one-for-one;

Mask-and-Match - filters that apply a mask to the identifier field before it is compared with the receiving code register.

Currently, the CAN protocol is actively used in industrial networks. Well-known companies such as Hoheywell and Allan_Bradley have developed and support network protocols top level SDS and DeviceNet, the latter being open and on at the moment More than 200 companies produce and develop their products in this standard. In addition, the top-level network standards CanOpen, CAL (Germany) and CanKingdom (Sweden) are quite well known in Europe. All these networks use the CAN protocol at the physical and transport levels. A number of domestic companies also produce products with the CAN protocol, including in the popular MicroPC format.

The CAN interface was developed in the late 80s by Bosch for connecting electronic devices used in cars.

General description of CAN. The network is designed for communication of so-called nodes, which can be receivers or transmitters. Each node consists of two components: a CAN controller and a transceiver. The controller implements the exchange protocol over the CAN network, and the transceiver ensures interaction with the network (signal transmission and reception).

In practice, according to the standard, the CAN bus is usually a twisted pair cable through which signals are transmitted using a differential method.

In Fig. The structure of the CAN network is shown. Typically, a microcontroller with a CAN module is used as a controller, which has a TxD serial code transmitter output and an RxD code receiver input. The transceiver converts logical signals, that is, logic 0 and 1, into a differential voltage applied to two bus wires designated CAN_H and CAN_L.

According to the standard, the line must have a characteristic impedance in the range of 108-132 Ohms. To reduce signal reflections, 120 ohm RC terminating resistors should be connected at each end of the bus. To increase transmission reliability and increase noise immunity, a third wire is sometimes used - common, designated as GND. The supply voltage UCC (or UDD) according to the standard is +5 V relative to GND.

To abstract from the physical transmission medium, the CAN specification defines two logical states (that is, logic 0 and 1) as recessive and dominant. It is assumed that when one network node transmits a recessive bit and another transmits a dominant one, the dominant bit will be received.

In the recessive state (that is, logic 1 at the TxD input of the transceiver), the differential voltage UDIFF =UCANH – UCANL is less than the minimum threshold (0.5 V at the receiver input or 0.05 V at the transmitter output).

In the dominant state (that is, logic 0 at the TxD input of the transceiver), the differential voltage UDIFF is greater than the minimum threshold (0.9 V at the receiver input or 1.5 V at the transmitter output).

Messages in CAN. The interface uses short messages: the maximum size is 94 bits. The data content in a CAN message implicitly determines the address of the source of this message and the addresses of receivers who need this information.

For example. one CAN node outputs the message “Engine oil temperature 80” to the bus. All other nodes receive this message, but only those nodes that need it use this information.

Messages transmitted over the CAN bus are called frames or frames. Depending on the initiator of the transmission and its purpose, there are 4 types of frames:

1) data frame, used for data transmission;

2) data request frame, used to remotely request data from a remote node;

3) error frame when errors are detected on the bus;

4) overload frame, transmitted to delay the transmission of packets, a data frame and a request frame, for example, when the receiver is not ready.

The standard data frame message format is shown in Fig. It consists of seven different bit fields:

The start of frame field consists of one dominant bit, which also serves to synchronize the receiver and transmitter generators.

The arbitration field contains an 11-bit ID and an RTR (data transfer request) bit. For a data frame, this bit must be at the dominant level.

The control field consists of six bits. The two most significant bits are currently unused. The four-bit data length code indicates the number of bytes in the data field.

The data field contains zero to eight bytes of data.

The checksum field includes checksum messages (15 bits) and a recessive level delimiter bit.

The acknowledgment field consists of two bits. The most significant bit named Slot sets the transmitting node to the recessive level. If the transmission was successful, the receiving node signals this by setting this bit to the dominant level. The second bit in this field is the recessive level delimiter bit.

The end of frame field consists of seven recessive level bits.

Following the end of frame (EOF) is a gap field consisting of three recessive level bits. After this interval the tire is considered free.

The CAN controller included in the STM32 MK is a full-featured CAN node that meets the requirements for active and passive CAB 2.0A and 2.0B devices and supports data transfer at a speed of no more than 1 Mbit/s. The CAN controller is also equipped with additional capabilities for organizing deterministic data transmission using a special CAN real-time transmission protocol TTCAN. After activating the TTCAN function, automatic retransmission of messages and automatic insertion of two additional bytes into the CAN packet with a fixed moment in time of message transmission will be supported. All these capabilities are required in real-time CAN control systems.

The full name of the CAN controller is the bxCAN module, where bx indicates the module supports additional capabilities. A regular CAN module uses one receive and transmit buffer, while an advanced CAN module uses multiple receive and transmit buffers. The bxCAN module is a hybrid of two CAN module architectures. It has three mailboxes for transmitted messages and two mailboxes for received messages. Each of the hosts mailboxes has a FIFO buffer to hold three messages. This architecture is a compromise in terms of data transfer performance and occupied space on the IC chip.

The CAN module is equipped with three mailboxes for transmitting messages and has the ability automatic insertion into a current time message via the TTCAN protocol

Next important function CAN controller - filtering of received messages. Since CAN is a broadcast bus, every message transmitted is received by all nodes on the bus. A CAN bus of any reasonable degree of complexity carries a fairly large number of messages. The task of each CPU connected to a CAN node is to respond to CAN messages. Thus, in order to save the CAN controller from the problem of receiving unwanted messages into the buffer, their filtering is necessary. The STM32 MCU CAN controller has 14 filter banks that can be used to block all CAN messages except selected messages or groups of messages.

14 message filters support two configurations that can be used to filter individual messages

Each filter bank consists of two 32-bit registers and can operate in one of four modes. When using the basic method, a message ID is written to each filter bank register. After a message arrives, its identifier is checked and, based on this, a decision is made to accept or reject the message. This mode supports two configurations. In the first configuration, the filter bank registers are 3-bit and can be used to filter 11- and 29-bit message ID fields, as well as the RTR and IDE bits in 16-bit mode.

In the second configuration, the message identifier is written to the first 32-bit register, and the message mask is written to the second. The mask register marks the bits of the identifier register as "important" or "not important". Thanks to this, it becomes possible to receive a group of messages using one filter bank. If the receiving filters pass the message, a pointer to the filter that determined the match will be written along with it in the receiving FIFO. This will allow the application to speed up message identification without having to read and decrypt the message packet identifier.

All CAN controllers support two operating modes: normal mode for receiving and transmitting message packets and initialization mode for setting communication parameters. As already mentioned, STM32 MCUs can operate in energy-saving SLEEP mode. In this mode, bxCAN module synchronization is disabled, but access to mailbox registers remains possible. The bxCAN module has the ability to activate when activity is detected on the CAN bus. Its operation can also be reactivated application program. When operating in normal mode, two additional submodes are supported. The first sub-mode is SILENT mode. In it, the CAN controller can receive messages, but cannot transmit and does not generate an error bit in sending and acknowledging the message. This mode is designed for CAN buses with passive monitoring. The second submode is LOOPBACK mode. In this mode, transmitted messages are immediately received in the receive buffer. It is necessary for the implementation of diagnostic functions and is also useful during the debugging phase of the program code. Both modes discussed can be combined. They are ideal for performing self-test functions when connected to a live bus.

Store currency is rubles.

CAN bus. Part 1.

1. Local network controllers (CAN)

Areas of application.

Electronic distributors, Automobiles, Marine vessels, Hydraulic equipment, Textile industry, Process industry, Medical equipment, Railway, Construction automation, Aviation radio electronics, Household appliances, Armed Forces, Materials Processing, Agriculture, Telecommunications, Trucks, Construction Machinery and Vehicles, Industrial Automation.

General information

Controller Area Network (CAN) is a serial bus standard developed in the 80s by Robert Bosch GmbH for connecting electronic control units. CAN was specifically designed to operate robustly in noise-rich environments using a multi-balanced line such as RS-485. The connection may be more resistant to interference when using twisted pair. Originally created for automotive purposes, but is currently used in a variety of control systems, incl. industrial workers working in noise-rich environments.
Data exchange speeds of up to 1Mbit/s are possible in networks with a length of no more than 40m. Reducing the exchange rate allows you to increase the length of the network, for example - 250 Kbit/s at 250m.
CAN protocol communication is standardized according to ISO 11898-1 (2003). This standard primarily describes the communication layer consisting of the logical control (LLC) subclause and the access control (MAC) subclause, and some aspects of the physical layer of the ISO/OSI model. The remaining protocol layers are left to the discretion of the network developer.

CAN networks and their varieties

There are various CAN networks. For example, in automobiles, CAN networks are divided into two categories based on the principle of data transmission over the network.
Control networks for comfort and convenience systems, with a large number information identifiers that are transmitted without a particular order or frequency.
And powertrain control networks manage information related to the engine and transmission. They contain less information, but the information is transmitted in an organized and fast manner.

General characteristics

Integrated serial communication bus for real-time applications.
. The network is operational at a data exchange rate of up to 1Mbit/s.
. Has excellent error and malfunction detection and testing capabilities.
. CAN bus was originally designed for use in automobiles.
. Used in various automatic systems and control systems.
. International standard: ISO 11898

Definition of CAN

CAN is a serial bus system adapted for organizing a network of intelligent devices, as well as sensors and actuators in a system or subsystem.

CAN properties

A CAN system on a serial bus with multifunctional capabilities, all CAN nodes are capable of transmitting data and some CAN nodes can request the bus at the same time. The transmitter transmits the message to all CAN nodes. Each node, based on the received identifier, determines whether it should process the message or not. The identifier also determines the priority that a message has when accessing the bus. Simplicity determines the cost of equipment and the cost of personnel training. CAN chips can be programmed relatively easily. Introductory courses, functional libraries, starter kits, various interfaces, I/O modules and tools are presented in a wide variety open sale at affordable prices. Since 1989, CAN chips can be freely and simply connected to microcontrollers. Currently there are about 50 CAN chips for microcontrollers from more than 15 manufacturers.
CAN is used in most European passenger cars, as well as the decision of truck and SUV manufacturers to further use CAN, determined the development for more than 10 years. Other application areas such as the consumer and industrial sectors have seen growth in sales of CAN equipment and will continue to do so in the future. By the spring of 1997, there were already more than 50 million installed CAN nodes. One of the outstanding features of the CAN protocol is the high reliability of data exchange. The CAN controller records errors and processes them statistically to make appropriate measurements; the CAN node that is the source of the fault will be removed from the connection as a result.
Each CAN message can contain from 0 to 8 bits of user information. Of course, it is possible to transmit longer data using fragmentation. The maximum specified exchange rate is 1 Mbit/s. This is possible with a network length of no more than 40m. For longer communications, the exchange rate must be reduced. For a distance of up to 500 m, the speed is 125Kbit/s, and for transmission over 1 km, a speed of 50 Kbit/s is allowed.

CAN applications

CAN networks can be used as embedded communication systems for microcontrollers as well as open communication systems for smart devices. The CAN serial bus system, developed for automotive applications, will be widely used in industrial communication systems and in many ways they will be similar. In both cases, the main requirements are: low cost, ability to function in difficult conditions, long-term performance and ease of use.
Some users, for example in the field of medical engineering, prefer CAN because stringent safety requirements must be met. Similar conditions Some other devices and equipment (i.e. robots, lifting and transport systems) are also subject to increased requirements for reliability and safety.

CAN license

The CAN protocol was developed by Robert Bosch GmbH and is protected by patents.

Basic CAN standards

The following are some international CAN standards
. CAN standards:
o ISO 11898-1 - CAN protocol
o ISO 11898-2 - CAN high speed physical structure
o ISO 11898-3 - CAN low speed fault compatible physical structure
o ISO 11898-4 - CAN start
o ISO 11898-5 - High speed low voltage device (in development).
o ISO 11519-2 - replaced by 11898-3.
. ISO 14230 - "Keyword Protocol 2000" - diagnostic protocol using serial line, not CAN
. ISO 15765 - Diagnostic protocol on CAN bus - Keyword 2000 on CAN bus.
. J1939 - Basic CAN protocol for trucks and buses defined by SAE
. ISO 11783 - J1939 and supplement for agricultural machinery
. ISO 11992 - defines the interface of tractors and trailers
. NMEA 2000 - A protocol based on J1939 for ships, defined by NMEA.

The CAN protocol is an ISO standard (ISO 11898) for serial data transmission. The protocol is designed for automotive applications. Currently, CAN systems are widespread and are used in industrial automation, various transport, special machines and cars.

Advantages of CAN:

- Availability for the consumer.
The CAN protocol has been successfully used for more than 15 years, since 1986. There is a wide selection of CAN products and devices available for sale.

- Implementation of the protocol at the hardware level
The protocol is based on the hardware level. This makes it possible to combine the ability to recognize and control errors with the ability high speed transmission data.

- Primitive transmission line
The data line, in most cases, twisted pair. But communication via the CAN protocol can also be carried out over one wire. IN various cases it is possible to use the most suitable communication channels, optical or radio channel.

- Excellent error and failure detection and fault localization ability.
The ability to detect errors and failures is a significant advantage of the CAN protocol. The error detection mechanism is built on an extensive principle, and the system for checking and confirming errors and failures is also reliable and well developed.
The fault detection system and data retransmission are performed automatically at the hardware level.

- Fault detection and testing system
A faulty source in the system can disorganize the entire system, i.e. occupy all communication channels. The CAN protocol has a built-in capability that protects the system from the source of the malfunction. The source of the error is removed from receiving and transmitting data via the CAN bus.

2. CAN bus

Introduction

The CAN protocol is an ISO standard (ISO 11898) for serial data transmission. The protocol is designed for automotive applications. Currently, CAN systems are widespread and used in industrial automation, various transport, special machines and cars.
The CAN standard describes the signal parameters at the physical level and the order of data transmission, which is determined by two various types messages, bus access arbitration rules, and a method for identifying and testing faults.

CAN protocol

CAN is defined by ISO 11898-1 and includes the following basic information.
. At the physical level, the signal is transmitted using twisted pair cables.
. Arbitration rules are applied to control bus access.
. Data blocks are small in size (in most cases 8 bytes) and are protected by a checksum.
. Data blocks do not have addressing; instead, each block contains a numeric value that determines the priority of transmission on the bus, and may also carry an identifier for the content of the data block.
. a complex error handling scheme that results in retransmission of data that is not properly received.
. Effective fault isolation actions and disconnecting the fault source from the bus.

Higher Order Protocols (HLP)

The CAN protocol defines the secure transmission of small data packets from point A to point B using a common communication line. The protocol does not contain flow control, addressing, does not provide message transmission of more than 8 bits, does not establish a connection, etc. The listed properties are defined by HLP (Higher layer protocol) or Higher Order Protocol. The HLP conditions are derived and consist of seven orders of the OSI model.

Purpose of HLP
. Standardize startup procedures and set baud rates
. Distribution of device addressing and types of messages.
. Determining the order of messages
. provides a system-level fault detection mechanism

CAN products

There are two kinds of CAN products, CAN chips and CAN enablers and development tools.
On top level two other product types, CAN modules and CAN development tools. A wide variety of similar products are available for public sale.

CAN Patents

Patents for CAN applications can be of various types and directions. Below are several types:
. Synchronization and implementation of transmission frequency
. Transmission of large blocks of data (CAN protocol uses frames no longer than 8 bits)
Distribution control systems
The CAN protocol is a productive basis for creating distribution control systems. The arbitration method allows each CAN device to interact with messages regarding that device.
A distribution control system can be stated as a system in which the capabilities of the processor are distributed among the devices of the system, or, conversely, as a system with central processor and local I/O devices.
When developing a CAN network, various compatible hardware devices can be used that have the necessary properties and satisfy the specified or calculated parameters of the network, such as processor frequency, data transfer rate, etc.

Higher Order Protocols (HLP) in effect

The CAN protocol defines the secure transmission of small data packets from point A to point B using a common communication line. The protocol does not contain flow control, addressing, does not provide message transmission of more than 8 bits, does not establish a connection, etc. The listed properties are determined by HLP, higher layer protocol. The HLP conditions are obtained and consist of seven orders

OSI model (Open Systems Interconnect Model)
CanKingdom
CANopen/CAL
DeviceNet
J1939
OSEK
SDS
HLP usually defines
. Launch options
. Message ID distribution among various devices in the system
. Interpretation of the contents of data blocks
. Status of interaction in the system

Characteristics of SDS, DeviceNet and CAN Kingdom.

And the differences between CAN Kingdom and CANopen. There are currently more than 50 HLPs. The use of HLP is mandatory, otherwise you will have to invent your own HLP.

CAnKingdom

CanKingdom is supported by CanKingdom International; the full specification is available on the organization's website.
CanKingdom is commonly referred to as a CAN (Controller Area Network) higher order protocol. In reality, the most orderly protocol. The modules in the system are connected by a network, in which one of the modules is the main one (King). For example: for plug & organization play systems, the main module determines which device can be added and under what circumstances, only specified devices can be added. CanKingdom provides simple unique identification of devices in the system, for this purpose the EAN/UPC identification standard is used, the individual device identifier is determined serial number devices.
CanKingdom provides the developer with all the potential capabilities of CAN.
The designer is not limited by the CSMA/AMP multimaster protocol and can create virtual bus control systems of various varieties and topologies. Provides the ability to create general modules without taking into account circumstances such as dependence on HLP and system properties. The designer can specify the use of only specific modules, thereby combining the values ​​of an open system with the advantages of a restricted and secure system.

Because the identifier in CAN messages not only identifies the message, but also controls access to the bus, message numbering is key. Another important factor is the identity of the data structure in the data field in both the sending and receiving modules. By introducing small, simple rules, these factors are completely controlled and communications are optimized for any system. This is performed during a short installation phase during system initialization. It is also possible to include devices that do not follow CanKingdom rules into the CanKingdom system.
CanKingdom is accompanied by relevant documentation for modules and systems.

CAL and CANopen

CAL is short for "CAN Application Layer" CAN application layer or order, protocol supported by CiA. CAL is divided into several components:
. CMS (CAN-based Message Specification) defines data transfer protocols between CAN devices
. NMT (Network Management Service) defines startup and shutdown protocols, fault detection, etc.
. DBT (Distributor Service) defines a protocol for distributing identifiers of various devices in the system
- CAL protocol is different from the OSI model (Open Systems Interconnect (OSI) Model)
- CANopen is a subsection of CAL, and is organized as a set of profiles that are not finalized.
- CAL/CANopen is one of the existing HLP protocols supported by CiA.
- CAL and CANopen specifications are fully available and supported by CiA

DeviceNet

The protocol is being developed by “Rockwell Automation nowadays”, defined by the ODVA (Open DeviceNet Vendor Association). DeviceNet is one of four protocols that CiA supports.

SAE J1939

J 1939 is a high-speed Class C network communication designed to support real-time control functions between controllers that are physically located in different locations in the vehicle.
Jl708/Jl587 is the previous, widespread type of class B network with the ability to exchange simple information, including diagnostic data, between controllers. J1939 has all the properties of J1708/J1587.
J1939 uses the CAN protocol to allow any device to transmit a message over the network when the bus is not loaded. Each message includes an identifier that determines the priority of the message, information about the sender of the data, and information contained in the message. Conflicts are avoided thanks to an arbitration mechanism that is activated with the transmission of the identifier (a secure arbitration scheme is used). This allows messages with the highest priority to be transmitted with the least delay, due to equal access to the bus by any of the devices on the network.
J1939 is organized from several parts based on the (Open Systems Interconnect (OSI) Model). The OSI model defines seven communication orders (layers), each representing various functions. While there is a J1939 document allocated to each layer, not all of them are explicitly defined within J1939. Other layers perform secondary functions described elsewhere. The Physical Layer describes the electrical communications interface (a twisted shielded pair of wires that can also be referred to as a bus). The Communication Channel layer describes the protocol or controls the message structure, accessing the bus, and detecting transmission errors. The application layer defines the specific data contained in each message sent over the network.
A complete set of specifications can be purchased from SAE, below is a list of documents
J1939 is supplemented by the following documents:
J1939 Practice Guidelines for Serial Transmission Control and communication network vehicle
J1939/11 Physical order (layer) - 250k bits/s, shielded twisted pair
J1939/13 Diagnostic connectors
J1939/21 Communication Layer Data
J1939/31 Network Layer
J1939/71 Application Layer
J1939/73 Diagnostics
J1939/81 Network Management

OSEK/VDX

OSEK/VDX is a joint project in the automotive industry. Created as an industry standard for open end architecture for distributed vehicle controllers. The real-time operating system, software interfaces, and network management tasks are jointly specified. OSEK" (Open systems and the corresponding interfaces for automotive electronics.) Open systems and information interfaces for automotive electronics. VDX “Whicule Distributed eXecutive" Distributed vehicle executors.
Companies jointly participating in the development: Opel, BMW, DaimlerChrysler, IIIT - University of Karlsruhe, PSA, Renault, Bosch, Siemens, Volkswagen.
Official website: www.osek-vdx.org

Smart Distributed System (SDS)

The SDS system, based on a bus for intelligent sensors and actuators, with a simplified installation process, provides extensive I/O control capabilities. Using a single four-wire SDS cable, the system can be equipped with up to 126 individually addressable devices. Additional information and specifications for SDS are available on the Honeywell developer website. SDS is one of the current four protocols supported by CiA.

Comparative characteristics of the main HLP protocols
General information

DeviceNet, SDS and CAN Kingdom are based on the ISO 11898 CAN communication protocol and operate according to the requirements of the CAN specification. Each CAN module following a specific protocol can be connected to a CAN bus following the same protocol. In any case, when connecting modules that operate using different protocols, in most cases problems arise due to a conflict in the interpretation of messages at the application level. CAN Kingdom differs from SDS and DeviceNet in a basic principle: CAN Kingdom is organized by the main communication node (“King”) at startup, unlike SDS and DeviceNet. This organization simplifies the development of a complex of real-time systems and reduces the required number of modules coordinating specifications, often referred to as profiles.
SDS is effective in connecting I/O devices, various switches and sensors to the PLC, in fact it represents the connection between the main module and remote I/O devices.
DeviceNet open system, in which all modules have equal rights to use the bus, and the order of using the bus is determined by a small set of instructions. The designer of system modules can delegate communication control authority to other modules, such as the main module in a predefined Master/Slave mode, but DeviceNet does not have the ability to delegate authority to other modules. The characteristics of SDS using I/O devices and DeviceNet in Master/Slave mode are similar.
Can Kingdom protocol is focused on production, connection and control systems and does not support profiles for digital and analog devices. The main feature of the protocol is that the module connected to the system only awaits instructions from the host device. All CAN priorities and identifiers are owned and provided by the host. During startup, each module is configured by the main device, the priorities and identifiers of producing and consuming objects are determined. The primary device is the master, but only during system configuration. The master device cannot be installed during a communication session between running applications of different modules. The main device can be removed after configuration and verification of completeness, while each module stores the received instructions in memory.

Today I want to introduce you to an interesting microcontroller platform CANNY. This is an overview article in which you will learn about the technology, and in subsequent articles I will tell you about working with CAN messages, integrating CANNY with Arduino Mega Server and the opportunities that this combination provides.

Why CANNY? From the name of the CAN bus, which is widely used in transport and, in particular, in all modern cars as an on-board network. So, what can you do with a specialized controller connected to the CAN bus of your car?

CAN bus

Physically, the CAN bus consists of two intertwined wires and is very easy to install and connect. Despite its simplicity, due to its differential nature, it is well protected from various interference and interference. High reliability and a large permissible network length, up to 1000 meters, helped CAN gain wide popularity among manufacturers of various, not only automotive equipment.

CANNY controllers

The flagship of the line is the CANNY 7 controller, the most powerful and has the maximum capabilities. Large quantity memory, powerful outputs that allow direct control of vehicle relays, intelligent anti-fault protection system short circuits, protection against surges of current and voltage in the vehicle's on-board network - all this makes this controller an excellent solution for implementing any of your ideas and projects.

In addition to CANNY 7, there are several more models in the line of controllers; we will conduct our experiments with the simpler built-in model CANNY 5 Nano. It also supports working with the CAN bus, but at the same time it is similar to the Arduino Nano we are already familiar with.

Visual programming

Developed support for the CAN bus is not the only feature of these controllers; in addition, CANNY have their own own environment programming, CannyLab, but not “ordinary”, but visual, where the entire process of writing programs comes down to manipulating ready-made structural blocks, setting their parameters and connecting the inputs and outputs of these blocks in a certain sequence, in accordance with the algorithm of the problem being solved.

Not a single line of code!

Is this good or bad? In my opinion, this is a matter of habit. As a person accustomed to “traditional” programming, it was unusual for me to manipulate blocks instead of writing lines of code. On the other hand, there are many adherents of this particular approach to compiling algorithms and it is believed that for engineers and “non-programmers” this is the simplest and most available method microcontroller programming.

At the very least, it was “fun” for me to write programs this way, and after a while I even began to like it. It is possible that if you continue to do this, then after a while writing code will seem inconvenient.

CannyLab is a free development environment and you can freely download it from the developers site, it also does not require special procedure installation - just unpack the archive file - and you can start working.

Connection

Practical examples

In the CANNY 5 controller, there is a test LED at pin C4 (Channel 4) (analogous to the LED located at pin 13 in Arduino). And it can also be used for display and experiments, which is what we will use.

What is needed to blink the LED in the CANNY controller? You only need to do two things - configure the pin of the fourth channel as an output and apply a signal from the PWM generator to this output. We have already done all these actions more than once in the Arduino IDE, let's see how it looks in CannyLab.

So, let's configure the fourth channel pin as an output

Setting up a PWM generator. We set the period to 500 milliseconds, the filling to 250 milliseconds (that is, 50%) and 1 (true) at the “Start” generator input and... that’s it! There is nothing else you need to do - the program is ready, all that remains is to upload it to the controller.

Simulation mode

The CannyLab development environment allows you to run and debug a program without writing it to the controller memory. In simulation mode, you can see the result of the program in real time and even interfere with its operation.

Filling into the controller

Once the program has been written and debugged, it can be loaded into your controller. This is done simply - in the menu, select the “Device / Diagram / Write” item and after a few seconds the program is written to the controller.

Analog inputs

We will monitor the voltage level on pin 10 of the controller and if it is in the range of 2.5 V ± 20%, we will light the LED built into the board.

As in the previous example, we configure the 4th pin as an output in order to be able to control the operation of the LED.

We turn on the ADC on channel 10.

The “Logical AND” block completes the work and, from its output, controls the operation of the LED on the board.

That's it. What we usually did on Arduino, we easily did in CannyLab. All you have to do is get comfortable in this programming environment and you can easily and naturally create your projects on this platform.

These simple programming examples are provided so that you can understand the principle of visual programming of CANNY microcontrollers. IN further work Excellent help documentation and developer support on the system website and forum will help you.