1. Introduction — Two Protocols, Two Completely Different Purposes
In industrial automation, Modbus and MQTT are among the most widely used communication protocols.
They are not competitors — instead, they serve different layers in a factory communication system:
- Modbus → Device-level communication (PLC, VFD, sensors)
- MQTT → Cloud-level communication (IoT platforms, dashboards, remote monitoring)
Choosing the right protocol depends on where the data is going, how fast it must be exchanged, and the network environment.
This article explains the core differences, use cases, and engineering best practices for both protocols.
2. Modbus — How It Works
Modbus is a master–slave (RTU) or client–server (TCP) protocol widely used in industrial devices.
2.1 Master–Slave or Client–Server Architecture
- One master polls multiple slaves
- Slaves cannot communicate on their own
- Works with PLCs, VFDs, meters, and sensors
2.2 Register-Based Communication
Common register types:
- Coils (0xxxx) – Digital ON/OFF
- Discrete Inputs (1xxxx) – PLC input signals
- Holding Registers (4xxxx) – Parameters, setpoints
- Input Registers (3xxxx) – Measurement values (current, voltage, speed)
2.3 Polling Mechanism
The master continuously reads/writes registers in a fixed cycle:
Master → read/write → Slave
Master → read/write → Slave
No data is sent unless requested.
3. MQTT — How It Works
MQTT is a publish/subscribe IoT protocol designed for cloud and remote communication.
3.1 Topic-Based Structure (No Registers)
Messages are organized as “topics”:
factory1/machine01/statusline2/temperaturealerts/motor_overload
Devices publish and subscribe to topics.
3.2 Publish/Subscribe Model
- Publisher sends data to broker
- Subscriber receives data
- Broker handles routing
MQTT supports lightweight communication with minimal bandwidth usage.
3.3 Broker Architecture
A central message server (Mosquitto, EMQX, HiveMQ) manages all communication.
Benefits:
- Asynchronous
- Scalable
- Secure (TLS)
- Perfect for cloud services
4. Direct Comparison of Modbus vs MQTT
| Feature | Modbus | MQTT |
|---|---|---|
| Layer | Device layer | Cloud/IoT layer |
| Real-time capability | Strong | Medium |
| Network dependency | Low | High (needs stable network) |
| Data flow | Master polls slaves | Devices publish data |
| Direction | Mostly one-way | Two-way messaging |
| Use case | PLC, VFD, instruments | IoT cloud, dashboards, alerts |
5. Real Industrial Application Scenarios
5.1 Modbus Applications
Used for:
- VFD control
- Sensor reading
- Energy meter data
- PLC-to-PLC communication
- Temperature controller interfaces
Modbus is ideal for local factory devices.
5.2 MQTT Applications
Used for:
- Remote monitoring
- Alarm push notifications
- Cloud dashboards
- Multi-site data aggregation
- Real-time production visualization
MQTT is perfect for cross-site or cloud applications.
6. Engineering Problems and Causes
6.1 Modbus Delay
Caused by:
- Too many slaves being polled
- Low baud rate (9600)
- Long wiring distances
- High noise environments
6.2 MQTT Broker Instability
Causes include:
- Weak network
- Cellular signal loss
- Incorrect TLS certificates
- Server overload
6.3 Topic Conflict in MQTT
Occurs when:
- Multiple devices publish to the same topic
- Topic naming not standardized
- Duplicate Client IDs
7. Best Practices
Modbus Best Practices
- Keep wiring short
- Use shielded cables
- Avoid 485 A/B reversal
- Use higher baud rates
- Minimize the number of slaves per master
MQTT Best Practices
- Use structured topic conventions
- Avoid duplicate client IDs
- Enable TLS encryption
- Use QoS1 or QoS2 for critical data
- Use persistent sessions
Combined Use Recommendation
The practical approach in most factories:
Use Modbus locally
PLC / VFD / sensors / meters → Modbus
Use MQTT for cloud upload
Gateway → MQTT → Cloud
This hybrid model provides:
- Reliable local control
- Stable cloud monitoring
- Scalable architecture
Tambah komentar
Anda harus masuk untuk berkomentar.