MQTT was designed for publish/subscribe — fire-and-forget messaging from many publishers to many subscribers. For two decades, that’s what MQTT did. If you wanted classic request/response (“send a query, get back exactly one answer for that query”), you had to use HTTP, AMQP, or roll your own correlation scheme on top of MQTT topics. MQTT 5 added native… Read More »
A factory floor PLC publishes temperature data to the topic factory/site-A/line-3/station-5/conveyor-7/motor/temperature every 100 milliseconds. That’s a 65-byte topic name sent 10 times per second, every second of every day. Over 24 hours, the topic name alone consumes 56 megabytes of bandwidth — not the payload, just the topic string. Multiply by hundreds of similar sensors and you have… Read More »
In MQTT 3.1.1, the question “how many QoS 1 messages can I have in flight at once?” had no clear answer. The spec didn’t say. Implementations varied — some Servers accepted thousands of pipelined PUBLISH packets; others would only process one in-flight message per client. Clients that wanted predictable behavior had to assume the worst (one in-flight message… Read More »
For two decades MQTT 3.1.1 gave you one of two answers to every operation: it worked, or it didn’t. When a PUBLISH failed, you got nothing actionable back — just silence or a disconnect. When a SUBSCRIBE half-failed (one topic accepted, one rejected), you couldn’t tell which was which. When the Server kicked you off the network, you… Read More »
For two decades, MQTT clients authenticated to the Server the same way: send a username, send a password, hope the Server accepts. That worked for the IoT prototypes of the 2000s. It does not work for modern industrial systems where credentials rotate, identities federate, and a plain-text password traveling over the wire is a security incident waiting to… Read More »
If you have used MQTT 3.1.1 for a few years and are wondering what MQTT 5 actually changes, or if you are starting a new deployment and need to decide between the two, this is the article that gets you there directly. The two versions share the same core protocol — publish/subscribe over TCP, three QoS levels, retained… Read More »
Two protocols dominate industrial Ethernet networks worldwide. Modbus TCP is the most-deployed industrial Ethernet protocol globally — running on millions of devices, embraced for its simplicity and openness. EtherNet/IP dominates the North American market and is everywhere Rockwell Automation has presence — running on the same ControlLogix PLCs that drive most US manufacturing. They both run over standard… Read More »
Ten years ago, OT cybersecurity meant “air gap the control network.” That model failed. Modern industrial systems need controllers talking to MES systems, drives reporting to cloud analytics, engineering tools accessing devices remotely. The air gap is gone — and with it, the security model that depended on physical isolation. CIP Security is the ODVA-defined answer for CIP… Read More »
You buy an EtherNet/IP AC drive from Rockwell Automation. It works with your ControlLogix PLC. You later buy a different AC drive from a different manufacturer — say, Yaskawa or ABB — and it works with the same PLC too. Why? Because both drives implement the CIP AC Drive Device Profile (Device Type 0x02). They expose the same… Read More »
Twenty years ago, synchronized motion across multiple servo drives required a dedicated motion bus — SERCOS, MACRO, FireWire, or a proprietary fieldbus. The motion network ran separately from the control network because standard Ethernet couldn’t deliver the deterministic microsecond timing motion needs. Today, with CIP Motion running over standard EtherNet/IP, the motion bus and the control network are… Read More »