Category Archives: Communication Protocols

Every CANopen device carries an object dictionary, and the SDO is the only way to reach into it from outside. Read a serial number, change a gear ratio, remap a PDO, save the configuration to flash — all of it is SDO traffic. Unlike a PDO, an SDO frame carries its own address. The first byte says what… Read More: CANopen SDO Explained: Expedited, Segmented, Block »

A PDO is eight bytes of raw process data with no protocol overhead — no index, no sub-index, no length field, nothing that tells you what is inside. The bytes arrive and the consumer is expected to already know what they mean. That agreement is the PDO mapping. It lives in the object dictionary on both sides, it… Read More: CANopen PDO Mapping: TPDO, RPDO and Transmission Types »

Many engineers compare CANopen vs CAN bus as though they are competing technologies. In reality, they are different layers of the same communication stack. CAN provides reliable message transport, while CANopen defines how devices exchange meaningful information. Short version: they are not alternatives. CANopen runs on CAN. Asking which to choose is like asking whether to use HTTP… Read More: CANopen vs CAN Bus: What’s the Difference? (Explained) »

CAN gives you frames, arbitration, and error handling — and nothing else. It says nothing about what an identifier means, how to configure a device, or how to move more data than fits in eight bytes. CANopen fills that gap, and it does so with one idea at the centre: every device is a table. That table is… Read More: CANopen Explained: Object Dictionary, PDO, SDO, NMT »

Classic CAN gives you eight bytes per frame at up to 1 Mbit/s. That was generous in 1991 and cramped by 2010, when a single ECU firmware update over CAN could take most of an afternoon and a modern sensor’s data no longer fit in one message. CAN FD — flexible data rate — fixes both limits without… Read More: CAN FD Explained: Bigger Frames, Faster Data Phase »

DeviceNet does something the other CAN-based protocols don’t: it puts 24 V power and the data pair in the same cable, so a photoelectric sensor gets its supply and its network from one connector. That single decision shapes everything else about it — the cable types, the topology limits, the current budgets, the connector families. Understand the power-plus-data… Read More: DeviceNet Explained: CAN, CIP, Power and Wiring »

J1939 isn’t one standard. It’s a family of about a dozen, each covering a different layer, and the reason most J1939 confusion exists is that people read one of them and assume it describes the whole network. The document that ties them together is SAE J1939-1. It doesn’t specify messages or bit timings — it specifies which J1939… Read More: SAE J1939 Explained: Network Architecture and Standards »

Most CAN faults are wiring faults. Not protocol bugs, not controller settings — a missing terminator, a stub that’s too long, a shield grounded at both ends, a connector that passes a continuity test but fails under vibration. The frustrating part is that CAN degrades gracefully enough to hide these. A network with one terminator instead of two… Read More: CAN Bus Wiring and Termination: The Complete Guide »

CAN is two wires, no master, no addresses, and no collisions — despite every node being free to start talking whenever the bus is quiet. That combination is why a protocol designed for 1980s vehicles now runs machine automation, off-highway equipment, medical devices, and industrial drives. The trick is that CAN doesn’t address messages to nodes. It labels… Read More: CAN Bus Protocol Explained: Frames, Arbitration, Errors »