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 »
Paste a CAN trace. Each line becomes a decoded message: the COB-ID split into function code and node ID, then the service behind it read out field by field. It takes candump output, PCAN text, or plain identifier data lines. Several lines at once, in order, so a whole startup sequence decodes in one pass. Message input One… Read More: CANopen Message Decoder — SDO, PDO, EMCY and NMT Online »
Paste the bytes and the decoder splits them into fields: packet type, flags, remaining length, then whatever that packet type carries. Topic names, QoS, packet identifiers, MQTT 5 properties, reason codes and the payload. It reads a whole TCP stream, not one packet. Paste a capture that runs from CONNECT to DISCONNECT and you get every packet in… Read More: MQTT Packet Decoder — Decode MQTT 3.1.1 and 5.0 Hex… »
Most fieldbuses solve the problem of moving a lot of data between intelligent devices. AS-Interface solves a different one: getting a few bits to and from hundreds of dumb devices, cheaply, without a terminal strip the size of a door. A proximity switch has one bit of information. A solenoid valve needs one bit. Wiring each one back… Read More: AS-Interface (AS-i) Explained: The Yellow Cable Bus »
Drop an SCD, CID, ICD, IID, SSD or SED file on the box above. The viewer reads it in your browser and lays out what is inside: the IEDs, the logical devices, every GOOSE and sampled value publisher with its MAC address and APPID, who subscribes to what, and the data sets behind each control block. The file… Read More: IEC 61850 SCL File Viewer — Open SCD, CID, ICD… »
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) »
The 4-20 mA loop normally represents one primary process variable. It has done so since the 1950s, it is understood by every technician alive, and it will outlive most of the protocols competing to replace it. HART’s insight was not to replace it. HART puts a digital signal on top of the analog loop, so the same two… Read More: HART Protocol Explained: Digital Data on a 4-20 mA Loop »
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 »