-
Notifications
You must be signed in to change notification settings - Fork 1
CAN BUS
Is a serial communication protocol that's gained popularity due to it's robustnest against interference and data lost. Broadly used in the industry. Or at least, that's what CAN Bus is, but CAN can be easily undertood from a ISO model.

Implementation:

See how the CANOpen device (node), implements PDO and SDO to transmit data with the network. The bits are "reinterpreted" to the Object Dictionary and then finally controlled by application Code.
CANBus is composed for two cables, CAN Dominant and CAN Recessive, usually refered as CAN_H (High) and CAN_L (low). Along with a common reference between devices.

Can Bus uses differential signaling, and the difference in voltage across CAN_H and CAN_L is what determines a logical value. The bus is terminated at each end with the CAN resistor, it has a value of 120 Ohm.
The role of the transceiver is simply to drive and detect data to and from the bus. It converts the single-ended logic used by the controller to the differential signal transmitted over the bus. It also determines the bus logic state from the differential voltage, rejects the common-mode noise, and outputs a single-ended logic signal to the controller. Additionally, many transceivers provide features to isolate the controller from bus conditions such as electrostatic discharge (ESD) or electrical over-stress (EOS) damage, so that a node would be protected if an extreme bus condition were to destroy the transceiver. The transceiver distinguishes between two bus logic states, dominant and recessive. A recessive bit is defined as CAN_H being less than CAN_L+.5V. A dominant bit is defined as CAN_H being more than CAN_L+.9V. Figure 4-1 illustrates the nominal case. Since dominant bits overwrite recessive bits, CAN manages message collision through the process of bit-wise arbitration as described earlier.
Note: The source above says CAN should not be connected as a ring network, but from experience, I've seen it work that way.
Message send on a CAN Network, the differences between generations are ID length, data bytes, just to name a few.
It can have different purposes, and such different service indicators. Every service has allocated different word aranges, and purposes, so, be careful when choosing.
- NMT: Network Management. Control the node state.
- SYNC: Synchronization. Synchronize inputs and outputs between the network and the master.
- EMCY: Emergency. Communicate to all the network a node is failing, along with failure info.
- PDO: Process Data Object. Transmit real-time data, along with timestamps
- SDO: Service Data Object. Transmit non real-time data
- SDO receive (request)
- PDO transmit (response)
- Monitoring: periodically check if all the nodes are fine.

COB-ID: Communication Object Identifier, a combatin of the Node ID and the function mode.
Function code: Established the intent of the CAN frame. Each function code has several CAN Nodes IDs
Object Dictionaries.
A unique attribute for a CAN node (device). It contains entries with device configuration as a standardized structure. I can be accessed by SDO.
Components:
- Index (node ID)
- Object node
- Object code
- Datatype
- Access
- Category
Electronic Data Sheet. Standardized file format for ODS. Like a human readable ODS. Template for the OD file. Contains device objects. And service tools to update devices.
Note: The network tool will not connect to a device unless all four identity object parameters match.
Device Configuration File. Like a more complete EDS, with more than generic parameters
CAFOpen & CANFD interoperability
J1939 protocol
IoT CAN Loggers
Tools: