.png)
Reading about CANbus, one definitely comes across the term" CANopen." It is just a CAN-based communication system.
CANopen, in fundamental terms, can be defined as the communication language where CAN-Bus is used as a transmission medium. As for the general understanding of the information, both the sender and the receiver need to agree on the same language standard.
Like CAN Bus, a lower-level protocol system involving the Physical layer and the Data link layer, CANopen is a higher-level protocol system that defines the upper five layers of the protocol model. Involving Network, Transport, Session Presentation and Application Layers. All the layers perform a discrete function on the CAN Bus.
(as described by https://www.can-cia.org/canopen/ )
CANbus succeeded in finding applications in most industries, but to enable CANbus application to more fields, CANopen was designed. Initially designed for motion-oriented machine control systems, CANopen today finds application in various fields, such as:
Robotics
Medical equipment
Automation
Off-road vehicles
Marine electronics
Railway application
Stepper and servo motors
Food processing
Building automation
Mechanical manufacturing
Industrial machinery
Security monitoring
The CANopen enables the designers to perform various functions which make CAN Bus more capable—practically designed for embedded network applications such as in-vehicle networks. It offers highly flexible configuration capabilities. Using CAN open, one could:
Implement desired network behaviour into the device.
Influence and control network behaviour.
Communicate and process data.
Indicate the device's internal error.
Enables the device to participate in point to point communication.
Defines the internal device structure.
Allows the adjustment of data rates from 10kbps to 1000kbps.
There are three major logical parts in CANopen's internal device structure:
CANopen message frame format:
The CANopen message format is similar to that of the CAN bus. It consists of COB-Id consists of the CAN-id and control bits. To avoid any conflict with the bus, all COB-Ids should be different.
CANopen Protocols:
A CANopen protocol stack implements several CANopen COBs that are communicated with one of the CANopen bit-rates. The CANopen protocol is comprised of:-
Service Data Objects Protocol(SDO)
The SDO service enables a CANopen node to read, edit, change or access the values of another node's object dictionary over the CAN network.
This is a confirmed communication service that consists of two CAN data frames with different CAN-Identifiers.
Peer-to-peer, "client-server" communication between two CANopen devices can be established on the broadcast medium CAN.
Server: The owner of the accessed object dictionary. Client: The device that accesses the object dictionary and initiates the communication with one dedicated SDO "server".
Although SDOs are very flexible, the presence of overhead makes them less ideal for real-time operational data. To overcome such an issue, Process Data Object Protocol is used.
Process Data Object Protocol (PDO):
The PDO is often seen as an essential CANopen protocol as it carries the bulk of information.
Process data objects (PDOs) are used in CANopen for broadcasting high-priority control and status information in real-time operational data across CANopen nodes.
A PDO consists of a single CAN frame and communicates up to 8 bytes of pure application data containing multiple object parameter values within a single frame.
Producer: It produces data to be transmitted to a master. Consumer: the Master here is the consumer. It receives the data from the producer.
Network Management Protocol(NMT)
The NMT service defines the communication behaviour of a CANopen device. On the reception of the NMT protocol, the CANopen device is forced to transit to the commanded NMT state. NMT state machine consists of:-
Initialisation state (the device enters the Initialisation state after power-on or reset)
Pre-operational state
Operational state
Stopped state
The NMT protocol sends a single CAN frame with a data length of 2 bytes with CAN id 0. It contains the command specifier/function code (first bit), this includes the request state, and for NMT, if it is set to a dominant 0, all nodes have to perform the command. The Node-id, as the name specifies, contains the module's ID that needs to obey the state transition command. In NMT, the modules need to operate using SDO protocol as PDO is only possible during the operational state.
Special Function Protocols
For generating a specific network behaviour, CANopen offers three specific protocols:-
1. Synchronization Protocol:
This protocol allows to synchronise several devices. The SYNC producer or the application master transmits the SYNC protocol periodically. According to the predefined connection set, the SYNC message is mapped to a single CAN frame with COB-id 80h. (it carriers no data (DLC = 0))
2. Emergency Protocol:
Any internal device errors trigger the Emergency protocol. In such a case, an emergency message is transmitted by the Emergency producer. It is transmitted only once per error event. The Emergency producer functionality assigns the CAN-Identifier COB-id 80h + (node-ID) to the Emergency message. If there are no new errors in any device on the CAN bus, no such messages are transmitted further.
3. Time-stamp protocol:
Enables the user of CANopen systems to adjust a unique network time, this Time-stamp is mapped to one single CAN frame, which has a 6 bytes data length code. These six data bytes provide the information "Time of Day" (initial 4 data bytes) given as milliseconds after midnight and days since January 1, 1984 (next 2 bytes). The associated CAN frame has by default the CAN-Identifier 100h.
Error Control Protocols
Enables the monitoring of a CANopen network.
Heartbeat Protocol:
The Heartbeat protocol verifies the availability and the NMT Finite State Automation (FSA). For all the networks in the CANopen. The heartbeat signal is transmitted cyclically to confirm the availability of the heartbeat producer.
Boot up protocol:
This signifies a unique type of error control protocol. Before entering the NMT FSA state pre-operational, it is transmitted as the final action in NMT FSA state Initialisation. This message on reception indicates.
A new device has been registered to the CANopen network.
Change in the network setup (when any new device is added to the CANopen).
It can be considered a sign of an error condition in the CANopen network.
To know more about Influx CAN Bus data logging solutions, click here.
Comentarios