You just downloaded a new device manual and it says “Modbus client” and “Modbus server.” Your RS-485 documentation says “master” and “slave.” Your PLC code has variables named slaveId. Which is right? Do you need to change your code? Are these different protocols? Short answer: no. The protocol is identical. The terminology depends mostly on the transport you… Read More: Modbus Client-Server vs Master-Slave Terminology »
Does anyone actually use Modbus broadcast? Some do. Most engineers go their whole careers without touching it. Broadcast is one of those Modbus features that lives in the corner of the spec, gets one or two paragraphs in most books, and shows up unexpectedly when you have to commission a large multi-drop bus at 3 AM. This article… Read More: Modbus Broadcast Function Codes: Address 0 Explained »
Every Modbus TCP packet starts with 7 bytes called the MBAP header (Modbus Application Protocol header). Those 7 bytes are what turn Modbus from a serial protocol into a network protocol. Get them right and everything works. Get them wrong, and the server may ignore the request, close the connection, or return an exception. This article decodes a… Read More: Modbus TCP MBAP Header Explained: 7 Bytes Byte by Byte »
Standard Modbus TCP has zero security. No authentication. No encryption. No integrity checks. Anyone who can reach TCP port 502 can issue Modbus requests. Depending on the device configuration, this may allow reading registers, writing coils or registers, changing operating parameters, or disrupting industrial processes. For decades, the answer was “put it behind a firewall and hope for… Read More: Modbus TCP Security Explained: TLS on Port 802 »
You read a float from a Modbus device. The value should be 25.3 degrees Celsius. You get 1.3 × 10³⁸. Or maybe -8.5 × 10⁻⁴¹. Or something that swings wildly between reasonable and absurd every time you re-read. Welcome to Modbus byte and word order. It is the single most common headache when you connect a new device.… Read More: Modbus Byte Order and Word Order: Fix Your 32-Bit Values »
MQTT was born as a publish/subscribe protocol — messages flow from many publishers to many subscribers with no expectation of a response. This model fits telemetry perfectly: sensors publish, dashboards subscribe, nobody waits for anyone. But when you need one client to ask another client a specific question and get one specific answer back, pub/sub alone falls short.… Read More: MQTT 5 Request Response Pattern Explained: RPC Over MQTT »
Every MQTT packet has a size — from a tiny 2-byte PINGREQ to a large PUBLISH carrying a firmware update. In MQTT 3.1.1, receivers had no way to tell senders what maximum packet size they could handle. A memory-constrained embedded gateway would just crash when a 10 MB PUBLISH arrived. A publisher had to guess: is this Server… Read More: MQTT 5 Maximum Packet Size Explained: Property 0x27 »
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: MQTT 5 Correlation Data Explained: Request/Response Pattern »
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: MQTT 5 Topic Aliases Explained: Per-Connection Bandwidth »
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: MQTT 5 Flow Control Explained: Receive Maximum »