Category Archives: Communication Protocols

CIP Service Codes Complete Reference: Common Services and Object-Specific Codes

Every CIP message starts with a one-byte service code. That byte tells the target device what to do — read an attribute, write an attribute, open a connection, reset, save configuration. This page is the authoritative reference for every CIP service code defined by ODVA’s CIP Networks Library Volume 1, Appendix A. If services are the verbs of… Read More: CIP Service Codes Complete Reference: Common Services and Object-Specific Codes »

CIP General Status Codes Reference: Complete List with Troubleshooting

When a CIP service fails, the device returns an error response with a one-byte General Status Code that tells you why. This page is the complete reference for every code defined by the official CIP specification — what each one means, what usually causes it, and how to fix it. The codes come straight from ODVA’s CIP Networks… Read More: CIP General Status Codes Reference: Complete List with Troubleshooting »

EtherNet/IP Encapsulation Protocol Explained: The 24-Byte Header That Carries CIP

Open Wireshark on an EtherNet/IP network and the first thing you see is not CIP. You see TCP. Then a strange 24-byte header. Then more bytes inside that look like CIP. The 24-byte header is the EtherNet/IP Encapsulation Protocol — the layer that wraps every CIP message onto a TCP/IP network. Nobody talks about it because everyone calls… Read More: EtherNet/IP Encapsulation Protocol Explained: The 24-Byte Header That Carries CIP »

MQTT 5 Session & Message Expiry Intervals Explained

Two of the most practical additions in MQTT 5 are about time: how long the broker should hold on to a client’s session, and how long it should hold on to an individual message. In MQTT 3.1.1, neither was a protocol concern. A persistent session lived indefinitely on the broker until something explicitly wiped it, and a queued… Read More: MQTT 5 Session & Message Expiry Intervals Explained »

What’s New in MQTT 5? Features, Changes & Why Upgrade

MQTT 5 is the current version of the protocol. It was ratified as an OASIS standard on 7 March 2019, succeeding MQTT 3.1.1, which had been the standard since 2014. MQTT 5 is not a rewrite. It is an evolution of MQTT 3.1.1 that keeps the core (publish/subscribe, topics, QoS, sessions, retained messages, LWT, keep alive) and adds… Read More: What’s New in MQTT 5? Features, Changes & Why Upgrade »

MQTT Over WebSockets Explained: Browsers, Ports, TLS

MQTT runs on top of TCP. That works well almost everywhere it is deployed: on embedded devices, gateways, servers, and desktop tools. There is one environment, though, where it does not work directly: the browser. A web page cannot open a raw TCP connection, which means a JavaScript MQTT client cannot connect to a broker over plain MQTT… Read More: MQTT Over WebSockets Explained: Browsers, Ports, TLS »

CIP Safety Explained: How EtherNet/IP Carries SIL3 Safety Data

Here is the question every engineer eventually asks: how can you trust an Ethernet packet to stop a hydraulic press? Standard Ethernet drops packets. Switches buffer and re-order them. Cables get unplugged mid-cycle. Yet CIP Safety lets a safety PLC monitor an emergency stop button over the same network that carries your I/O and your HMI traffic —… Read More: CIP Safety Explained: How EtherNet/IP Carries SIL3 Safety Data »

MQTT Keep Alive & Client Take-Over Explained

MQTT relies on long-lived TCP connections to push messages efficiently in both directions without polling. That design works well when connections behave the way TCP says they will, and breaks down badly when they do not. On mobile, cellular, and satellite links, a connection can quietly stop carrying data while still looking, to both sides, as if it… Read More: MQTT Keep Alive & Client Take-Over Explained »

MQTT Last Will and Testament (LWT) Explained

MQTT is built to run over networks that are not reliable, so it has to assume that clients will sometimes vanish without warning. A client can drop because its battery died, its radio lost signal, its host crashed, or anything else that prevents it from sending a normal disconnect. The rest of the system needs a way to… Read More: MQTT Last Will and Testament (LWT) Explained »

MQTT Retained Messages Explained: Last Known Value

In MQTT, a publishing client has no guarantee that a subscribing client will actually receive its message, because pub/sub decouples them. The publisher’s only guarantee is that the message arrives at the broker; from there, delivery to subscribers depends on who is currently subscribed. Similarly, a client that has just connected and subscribed has no guarantee about when… Read More: MQTT Retained Messages Explained: Last Known Value »