When can I use Modbus TCP for Machine Monitoring

Modbus TCP rarely gets the same attention as MTConnect or OPC UA in connectivity discussions, but it shows up constantly on real shop floors — in PLCs, energy meters, environmental sensors, and plenty of auxiliary equipment that never got a modern protocol. If you're building a monitoring setup that needs to pull data from more than just CNC controllers, understanding Modbus TCP is usually unavoidable. This article explains how it works and where it actually fits into a machine monitoring project.

Contents:

1. What Modbus TCP is
2. How it works: registers and function codes
3. Where Modbus TCP shows up in machine monitoring
4. Modbus TCP vs. Modbus RTU
5. Mapping registers to meaningful data
6. Security considerations
7. Common pitfalls
8. Frequently asked questions
9. Conclusion

What Modbus TCP is

Modbus is one of the oldest industrial communication protocols still in wide use, originally developed for PLCs in the late 1970s. Modbus TCP is the version that runs over standard Ethernet networks, wrapping the original Modbus message format in a TCP/IP packet so it can travel over the same network infrastructure as everything else in a plant. It's simple, well documented, and supported by an enormous range of industrial devices — which is exactly why it remains relevant decades after MTConnect or OPC UA came along with more modern designs.

How it works: registers and function codes

• Client/server model. A Modbus TCP client (sometimes still called a "master" in older documentation) sends requests to a server (a "slave" device, such as a PLC or a meter), which responds with the requested data.
• Registers. Data on a Modbus device is organized into numbered registers, generally split into a few standard types: coils and discrete inputs for simple on/off values, and holding registers and input registers for numeric data such as temperature, power, or counter values.
• Function codes. Requests specify a function code that determines the operation — read holding registers, write a single coil, and so on. There is no built-in vocabulary telling a client what a given register actually represents; that mapping has to come from the device's own documentation.
• Polling, not pushing. Modbus TCP is fundamentally a request-response protocol: the client asks for data on a schedule (polling) rather than the device pushing updates on its own, which affects how real-time the resulting data can be depending on polling frequency.

Where Modbus TCP shows up in machine monitoring

• PLCs. Many industrial PLCs support Modbus TCP as one of several communication options, making it a common way to read process or machine data that's already mapped into PLC memory.
• Energy and power meters. Submeters used for power consumption tracking on individual machines or areas of a plant very commonly expose their readings over Modbus TCP.
• Environmental and condition sensors. Temperature, humidity, and vibration sensors used for auxiliary monitoring frequently use Modbus as their reporting interface.
• Older or non-CNC equipment. Injection molding machines, compressors, and other production equipment that predates modern open standards often expose whatever data they have through Modbus TCP or RTU rather than anything CNC-specific.
• Bridging to CNC data. On some setups, Modbus TCP is used as a bridge protocol — an edge device reads a machine's native interface and republishes selected values as Modbus registers for simpler downstream integration.

Modbus TCP vs. Modbus RTU

Modbus originally ran over serial connections (RS-232 or RS-485), a version now referred to as Modbus RTU. Modbus TCP is functionally very similar — the same register types and function codes — but runs over Ethernet instead of serial wiring, which makes it easier to integrate into a standard plant network and to reach devices across longer distances without dedicated serial cabling. Many devices support both, with TCP typically preferred for new installations where Ethernet connectivity is available. We cover the practical differences between the two, along with how they interact with MTConnect-based monitoring, in more detail in a dedicated article on MTConnect and Modbus TCP/RTU connectivity.

Mapping registers to meaningful data

• Start with the device's Modbus register map. Every Modbus device should ship with documentation listing which register addresses correspond to which values, and in what data format (integer, float, scaled value) — without this document, register numbers alone are meaningless.
• Watch for data type and scaling differences. A value might be stored across two registers as a 32-bit float, or as a scaled integer that needs to be divided by 10 or 100 to get the real reading — getting this wrong silently produces plausible-looking but incorrect data.
• Confirm byte and word order. Different manufacturers implement multi-register values with different byte ordering conventions, which is a common source of garbled readings if assumed rather than verified.
• Set a sensible polling interval. Polling too frequently can add unnecessary network load, especially across many devices; polling too infrequently can miss short state changes relevant to availability calculations.

Security considerations

Modbus TCP has no built-in authentication or encryption — any device on the same network segment that can reach a Modbus server's IP and port can, in principle, read or write its registers. This was a reasonable assumption when Modbus was designed for isolated serial networks, but on a modern Ethernet-connected shop floor it means Modbus traffic needs to be protected at the network level: segmented VLANs, firewalls restricting which devices can reach Modbus ports, and avoiding exposing Modbus servers directly to broader corporate or internet-facing networks.

Common pitfalls

• Assuming register maps are standardized. Unlike MTConnect's fixed vocabulary, Modbus register meanings are entirely vendor-specific; a "holding register 40001" means something different on every device unless you check its documentation.
• Polling too many devices from one client without pacing. Overloading a Modbus network with too many rapid requests across many devices can cause timeouts and dropped readings, especially on older equipment with limited processing headroom.
• No write-access safeguards. Because Modbus TCP supports write function codes, a misconfigured client or an unauthorized device on the network could unintentionally alter a setpoint; access should be scoped deliberately, not left open by default.
• Treating Modbus as a full replacement for richer protocols. Modbus gives you whatever values a vendor chose to expose in their register map, which is often narrower than what a CNC-specific protocol like MTConnect or FOCAS provides on a machine that supports both.

Frequently asked questions

Is Modbus TCP still relevant compared to newer standards like MTConnect or OPC UA?

Yes, particularly for non-CNC equipment like energy meters, sensors, and older PLCs, where Modbus TCP is often the only interface a device offers. It's frequently used alongside newer standards rather than instead of them, covering the parts of a plant that modern protocols don't reach.

Can Modbus TCP be used to collect data from a CNC machine directly?

Only if the controller or an associated PLC exposes relevant data through Modbus registers, which is less common on CNC controllers than dedicated protocols like FOCAS, LSV2, or OPC UA. It's more typically used for auxiliary equipment or as a bridge protocol from an edge device.

How do I find out what a specific Modbus register represents?

The device manufacturer's Modbus register map documentation is the authoritative source; register numbers alone carry no inherent meaning, so this documentation is essential before building any integration against a specific device.

Does Modbus TCP require special hardware to implement?

No additional hardware is needed beyond standard Ethernet networking, since Modbus TCP runs over the same infrastructure as other IP-based communication. Devices simply need Modbus TCP server support built in or added through a compatible gateway.

Conclusion

Modbus TCP isn't the newest or most feature-rich protocol on the shop floor, but its simplicity and near-universal support are exactly why it keeps showing up — especially on the meters, sensors, and older equipment that never got a modern connectivity standard. Getting useful data out of it comes down to two things: having the device's real register map, and treating the network it runs on with the same security discipline as any other machine-level interface.

Related articles:

• MTConnect and Modbus TCP/RTU Connectivity
• Direct Connection: CNC-PLC Data Collection
• PLC Data Collection: Your Bridge from Tradition to Tomorrow
• Connecting Machines with No Open Protocol
• MDCplus Machine Connectivity & Integrations

About MDCplus

Our key features are real-time machine monitoring for swift issue resolution, power consumption tracking to promote sustainability, computerized maintenance management to reduce downtime, and vibration diagnostics for predictive maintenance. MDCplus's solutions are tailored for diverse industries, including aerospace, automotive, precision machining, and heavy industry. By delivering actionable insights and fostering seamless integration, we empower manufacturers to boost Overall Equipment Effectiveness (OEE), reduce operational costs, and achieve sustainable growth along with future planning.