Hello everyone,

I’ve been trying to learn more about communication systems used in industrial automation, particularly between PLCs, HMIs, and other field devices.

From what I understand, protocols like Modbus and Ethernet/IP are commonly used, but I’m curious about real-world experiences when it comes to reliability and troubleshooting.

What are some best practices you follow to ensure stable communication in your systems? For example, things related to network setup, wiring, or common mistakes to avoid.

I’d really appreciate any insights or lessons learned from actual projects.

Thank you.

 

Modbus is definitely the easiest of the bunch to use. Both Modbus RTU and Modbus TCP. It is a old protocol and does not support some of the new security requirements (which themselves are a big issue for automation professionals to setup).

Ethernet/IP and Profinet has its quirks. Generally devices and softwares are supposed to work with each other seamless when they have passed conformance testing but in our experience that is not the case. There is at times some tuning required to get a device to work with a different PLC. Still it is not bad for simple integration.

Overall when devices are setup, then they work well - we have seen high reliability operation with field devices. Setup is where it takes time. PLC are well documented so generally finding online help is easier. Instrument providers are scattered, some have very extensive helps, tutorials - most others (smaller ones in particular) lack in published online support pages. A lot of smaller instrument providers do not even support fieldbuses - I guess the cost of integrating the stack in their firmware is too high.

 

This is a very interesting subject, and the answer really depends on the exact application.

For example, EtherNet/IP uses UDP instead of TCP which means it is super fast, and is a good fit for factory automation and/or M2M synchronization. As more companies begin to combine their factory and process automation systems, EtherNet/IP is a solid choice for bridging both systems.

For installation, each EtherNet/IP device has a CIP which allows the Scanner (PLC) to identify everything about the device which makes it very "plug and play".

HOWEVER....

Modbus is free, open-source, and exists practically EVERYWHERE.

But there is 0 built-in security since Modbus RTU is just a basic serial comms protocol. The industry is moving more towards Modbus TCP since it uses the existing Modbus packet structure, but encapsulates it in a TCP layer which has security.

Modbus (RTU or TCP) is EVERYWHERE and there are protocol converters for practically any other protocol.


I absolutely love instruments and would be more than happy to continue a discussion!

 

So to answer your question, in my personal opinion, stick with Modbus TCP and just find converters if/when needed.

Also, if someone asks for a protocol that is not Modbus, ask them why. Sometimes people just like the "cool new thing" - but Modbus is still pretty damn cool!

 

Great question. A few things that consistently matter in real projects:


Network setup: Keep the control network physically separate from office/IT traffic — dedicated VLANs at minimum, ideally dedicated switches. Avoid daisy-chaining devices; use a proper ring or star topology with managed switches so a single cable failure doesn't take down the line. Reserve static IPs and document everything.


Wiring and grounding: Separate power and communication cabling, cross at 90° if unavoidable, and use shielded cable with the shield grounded at one end only. Ground loops cause more "mystery" dropouts than most people expect. Watch the 32-device limit on RS-485 segments and add repeaters where needed.


Common mistakes: Underestimating scan-time and traffic load (a broadcast storm from one misbehaving device can stall a whole segment); mixing firmware versions across devices on the same protocol; and skipping RFI checks near VFDs and welders — reroute or shield around those.


Troubleshooting: Build in visibility from day one — managed switches with port mirroring, protocol analyzers (Wireshark with the right dissector, or vendor tools), and logging of comm errors, not just link status.


Nothing exotic — mostly disciplined basics. Happy to elaborate on any specific protocol.