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 »
On an Allen-Bradley controller, “CIP” and “EtherNet/IP” are the same conversation. CIP is the protocol — the object model, the services, the way data is named. EtherNet/IP is CIP running on top of standard Ethernet. When you configure a Rockwell PLC to talk to a drive, a remote I/O block, a camera, or another controller, you’re configuring EtherNet/IP,… Read More »
Every FTP client on this list is free. Not free trial. Not free with locked features. Free. So the question is not “which one costs nothing.” It’s “which one fits the work you do.” A tech pulling event records from relays needs a different tool than someone running nightly backup scripts. This guide sorts the clients by job,… Read More »
FTP is the oldest protocol you will still find running in a substation. It moves files between two machines over TCP. That is the whole job. But the way it does the job — two separate connections, plain-text commands, a server that calls you back — trips up more engineers than any other legacy protocol. This article walks… Read More »
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 »
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 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 »