PLC Protocol Compatibility: What to Check Before a Connectivity Project

Does the same protocol name mean the PLC will connect?

A protocol name on a PLC nameplate is a family label, not a connection guarantee. Two controllers that both say Modbus may still differ in RTU versus TCP, function codes, register origin and word order. Two that both say S7 may differ in CPU family and whether PUT/GET is enabled. Treating the family name as a driver selection is how commissioning loses its first week.

Shanghai Chengxuan Intelligent covers the full Mitsubishi MELSEC range at engineering depth and maintains PLC communication compatibility across more than 20 brands, including Siemens S7, Rockwell EtherNet/IP, Inovance, Omron, Keyence, Panasonic, Beckhoff, Delta, Yokogawa, Yaskawa, LS, Fatek, Vigor, Fuji, Xinje, Megmeet and Toyota. Protocols proven in service include CC-Link/CC-Link IE, MC, S7, Modbus, PROFINET, EtherNet/IP, OPC UA/DA, BACnet, CAN/LIN, SECS/GEM and MQTT/WebSocket/HTTP. That list describes a technical stack that can be attempted; it is not a claim that every CPU on a mixed floor will connect without a check. Legacy and non-standard equipment are verified for interface and compatibility conditions before a method is fixed.

• Mitsubishi MELSEC: FX, Q, L, iQ-F and iQ-R share the MELSEC name; MC format (3E versus 4E, ASCII versus binary) and whether Ethernet sits on the CPU or a dedicated module still have to be confirmed
• Siemens S7: ISO-on-TCP to an S7-300/400 is not the same path as an S7-1200/1500; PUT/GET may be switched off, and PROFINET IO is not a substitute for reading data blocks
• Rockwell EtherNet/IP: implicit I/O and explicit messaging use different CIP paths; existing scanners may already occupy the controller's connection slots
• Modbus: RTU versus TCP, holding versus input registers, 0-based versus 1-based addressing, and word order differ between vendors even when the nameplate text is identical
• OPC UA and CC-Link: OPC UA splits by security policy, authentication and node model; CC-Link, CC-Link IE Field and CC-Link IE Control use different station models and cannot be swapped by name

Read the nameplate as a family, then confirm the revision, the port and the role. Until those three are known, the CPU is unverified — the same rule that applies to legacy equipment.

What should you verify before a connectivity proposal is written?

Before anyone names a driver or a conversion path, the five items below have to be answered CPU by CPU. Missing any one of them is how a supported protocol family still fails on the first day of commissioning. Write the answers on a one-page sheet per CPU; that sheet is the input to the proposal, not an appendix after the fact.

• Version and CPU series: firmware, CPU model and communications-module model — not only the brand. An MC client written for Q-series frames will not talk to every iQ-R CPU in the same way
• Ports: physical port (built-in Ethernet, serial, or intelligent module), TCP or UDP port numbers, whether an HMI or another collector already occupies the port, and whether the path is open through the plant firewall
• Master/slave or client/server: who is already the master on that bus. Modbus RTU and many fieldbuses allow a single master; adding a second collector without checking collides with the existing HMI
• Load: spare CPU communication capacity, effect on scan time, and the upper bound on concurrent clients. Compact CPUs often accept only a small number of simultaneous sessions
• Documentation: address table or tag list, data type, scaling, byte order, and whether the running program may be read. If the address table is missing, treat that CPU as unverified until a survey fills the gap — the same gate used for legacy equipment

A proposal that lists protocol families without these five answers per CPU is a catalogue, not a connectivity plan. The sheet also tells you which units can be read in phase one and which wait for a survey.

Protocol family, questions for the equipment side, and common site pitfalls

The table below is a conversation guide for the OEM, the integrator who owns the PLC program, or the plant electrical team. Ask the middle column before locking a driver. The right-hand column is what typically surfaces only after someone is already on site.

Legacy and non-standard equipment are verified for interface and compatibility conditions before a method is fixed. A protocol name on a nameplate is not itself a connection condition.

How do you set priority when several PLC brands share one network?

Mixed-brand floors are the normal case in general manufacturing: a Mitsubishi cell beside a Siemens line, a Rockwell skid, plus Omron or Keyence machines from later expansions. Trying to connect every CPU in the first week spreads the survey thin and puts load on a shared switch before anyone knows which conversations are cheap. Priority here is a commissioning order, not a ranking of brands.

• First: CPUs with a published address table, an open Ethernet protocol, and a spare client slot — these produce usable tags with the least interruption
• Second: the same protocol family in a batch (all MC, all Modbus TCP, all EtherNet/IP) so one driver configuration and one poller setting cover a group
• Third: process-critical tags — alarms, interlocks, energy, traceability keys — even if the brand is mixed, once the five checklist items are already answered
• Fourth: serial-only and single-master buses, after confirming the existing master will not be disturbed
• Last: undocumented, discontinued or legacy CPUs — survey first, then decide granularity; do not put them on the critical path of phase one

Sequence the pollers so high-frequency reads stay on CPUs that have spare communication capacity, and keep slow or chatty vendor telegrams off the same cycle as alarm scans. Phase one should finish with a verified tag list, not with a promise that the remaining brands will follow the same driver.