Connecting to any PLC, whatever the badge on the front
Every brand ships its own programming tool, its own discovery mechanism and its own idea of what a default IP address is. The underlying job never changes: reach the controller on a network it already believes it is on, speak the transport its firmware exposes, and prove the link before you touch the program. This module walks the seven platforms you meet most, then the harder question — how you make two different brands exchange data on the same line, and which method to pick when three of them would technically work.
What "connecting" actually means
Three separate things get called "connecting to the PLC" and confusing them wastes most of the time people lose on site. The first is the engineering connection: your laptop talking to the controller through the vendor's tool so you can download, monitor and force. The second is the runtime data connection: another device — an HMI, a SCADA server, a second PLC — reading and writing process values while the machine runs. The third is the device connection: the fieldbus that owns the controller's I/O, which is usually not the path you want for either of the first two.
They use different ports, different permissions and often different physical interfaces. A Siemens S7-1500 answers the engineering tool on TCP 102 while its PROFINET I/O runs cyclic real-time frames on the same cable; an Allen-Bradley ControlLogix answers Studio 5000 over CIP on TCP 44818 while its remote racks run implicit I/O on UDP 2222. Firewall a plant network without knowing that split and you will block programming while I/O keeps running — the classic "the machine is fine, I just cannot get online" ticket.
Before touching any tool, get three facts: the controller's IP address and mask, which physical port on the CPU or rack that address belongs to, and whether an engineering connection is even permitted (many controllers hold a protection level that blocks download or forces read-only access until a password is entered).
- Engineering: your laptop plus the vendor IDE, usually over TCP.
- Runtime data: HMI, SCADA and PLC-to-PLC traffic, often a different protocol entirely.
- Device level: the fieldbus that owns I/O — do not borrow it for data exchange unless the vendor says you may.
Siemens — S7-1200, S7-1500, S7-300/400
Modern Siemens controllers are reached with TIA Portal over Ethernet. The engineering protocol is ISO-on-TCP on port 102. In TIA Portal you set the PG/PC interface to your laptop's network adapter, then use Online → Accessible devices: the tool sends PROFINET DCP broadcasts, which find CPUs even when their IP address is on a different subnet than your laptop. That is the single most useful trick on Siemens hardware — a controller with 192.168.0.1 still shows up while your laptop sits on 10.0.0.5, and you can assign a temporary address from that dialog.
Legacy S7-300 and S7-400 are the same story with more options: Ethernet if the CPU or a CP card has a port, otherwise MPI or PROFIBUS through a USB adapter. Older projects were written in STEP 7 Classic, and TIA Portal only opens them through its migration tool — check which software the site actually owns before promising a download.
For runtime data, S7 controllers expose several routes. PUT/GET with S7 communication is the native PLC-to-PLC method between Siemens CPUs; open user communication (TCON/TSEND/TRCV) gives you raw TCP or ISO-on-TCP to anything; the integrated OPC UA server on S7-1500 (firmware 2.0 and later, licensed) is the cleanest way to publish tags to non-Siemens systems; and Modbus TCP is available through the MB_CLIENT and MB_SERVER blocks in the standard library.
Two things trip people up. S7-1200/1500 refuse external symbolic access to a data block until "Optimized block access" is turned off or the tag is explicitly published, and the CPU's protection level must allow full access, or your tool connects and then refuses to write.
- Tool: TIA Portal (STEP 7 Classic for older S7-300/400 projects).
- Engineering port: TCP 102 (ISO-on-TCP); discovery via PROFINET DCP broadcast.
- Data out: OPC UA server, S7 PUT/GET, open user communication, Modbus TCP blocks.
Rockwell Allen-Bradley — ControlLogix, CompactLogix, Micro800
Rockwell splits the work between two pieces of software. RSLinx (or FactoryTalk Linx) owns the communication driver, and Studio 5000 talks to controllers through it. Set up an EtherNet/IP driver in RSLinx, browse the network, and every CIP device on the subnet appears with its identity — module type, firmware revision, slot. Studio 5000 then selects that path when you go online.
The protocol is CIP over EtherNet/IP: explicit messaging on TCP 44818 for programming and unconnected requests, implicit I/O on UDP 2222 for the cyclic data that runs remote racks and drives. Unlike Siemens there is no broadcast discovery that crosses subnets — your laptop must be on the same subnet as the controller. A factory-new module has no address at all and waits for BOOTP/DHCP, so the Rockwell BOOTP-DHCP tool is the standard way to give a new 1756-EN2T or 1769-L33ER its first IP.
Older platforms behave differently enough to matter. SLC 500 and PLC-5 use DF1 over serial or Data Highway Plus and need RSLogix 500 or RSLogix 5, not Studio 5000. Micro800 uses Connected Components Workbench and USB for a first connection. None of these open a Logix project, and Logix versions are not backward compatible: a project saved in v32 cannot be opened in v31, which is why sites keep several Studio 5000 versions installed.
For runtime data, CIP tag reads (class 3 explicit messaging) are how HMIs and third-party gateways get at controller tags by name. Produced/consumed tags handle Logix-to-Logix exchange, and MSG instructions cover everything else, including Modbus through a ProSoft or similar module.
- Tool: Studio 5000 + RSLinx/FactoryTalk Linx (RSLogix 500 for SLC, CCW for Micro800).
- Ports: TCP 44818 explicit, UDP 2222 implicit I/O.
- New hardware has no IP — assign it with the BOOTP-DHCP tool.
- Same-subnet rule: no cross-subnet discovery like Siemens DCP.
Schneider Electric — Modicon M221, M241, M251, M580
Schneider is the friendliest brand for third-party data because Modbus is native everywhere. The Modicon range answers Modbus TCP on port 502 out of the box, and the same registers you read from an HMI are the ones you read from Python. Programming happens in EcoStruxure Machine Expert (formerly SoMachine) for the machine controllers M221/M241/M251, and Control Expert (formerly Unity Pro) for the process controllers M340/M580.
For a first connection, the small controllers accept USB and the larger ones Ethernet. Machine Expert's Communication Settings screen scans the network and lists controllers by node name; that scan uses NetManage broadcasts, so a controller with a mismatched IP still appears and can be given a new address. M580 CPUs default to an address derived from their rotary switches, which is worth checking before assuming DHCP.
Two site-specific habits cause trouble. Schneider's %MW register area maps directly to Modbus holding registers, which makes data exchange trivial but also means anyone with network access can write process values unless you enable the controller's IP filtering and disable unused services. And a controller that has been "locked" with an application password will accept a connection but refuse to show program logic, which looks like a corrupted project if you do not know to ask for the password.
- Tool: EcoStruxure Machine Expert (M221/M241/M251), Control Expert (M340/M580).
- Data: Modbus TCP on 502, no extra configuration, %MW maps straight to holding registers.
- Lock down IP filtering — native Modbus means native write access.
Omron — NJ/NX with Sysmac Studio, CJ/CP with CX-Programmer
Omron has two generations that share almost nothing. The NJ and NX machine controllers are programmed in Sysmac Studio, use IEC 61131-3 languages and EtherCAT for I/O, and expose data through EtherNet/IP tag links and an OPC UA server on the higher NX models. The older CJ, CS and CP families are programmed in CX-Programmer, are addressed by memory area (CIO, DM, HR) rather than symbols, and speak FINS.
FINS is worth knowing even on a modern site, because it is how most existing Omron integrations were built: FINS/UDP on port 9600 by default, FINS/TCP on 9600 as well, addressed by network/node/unit rather than pure IP. Many SCADA drivers still ask for those three numbers, and getting the node number wrong is the usual reason a driver connects but reads zeros.
For a first connection to an NJ/NX, Sysmac Studio over USB is the reliable path; the controller's built-in port then gives you Ethernet once you know its address. Sysmac Studio also insists that the project's controller model and firmware revision match the hardware — a mismatch blocks the download with a message that reads like a licence error but is not.
- Tool: Sysmac Studio (NJ/NX), CX-Programmer (CJ/CS/CP).
- Data: EtherNet/IP tag links, OPC UA on higher NX, FINS on UDP/TCP 9600 for older gear.
- FINS needs network/node/unit numbers, not just an IP.
Mitsubishi — MELSEC iQ-R, iQ-F, Q and FX
Mitsubishi controllers are programmed in GX Works3 (iQ-R, iQ-F) or GX Works2 (Q, L, FX). A first connection uses USB on the FX and iQ-F families or Ethernet on the rest, and the tool's Transfer Setup dialog is where the connection route is defined — direct, via a network module, or through a routed path across CC-Link IE.
For data exchange, MELSEC controllers expose MC protocol (also called MELSEC communication protocol) on a TCP or UDP port you configure yourself — 5007 and 5562 are common defaults, but there is no universal number, which surprises people used to Modbus. SLMP is the newer, better-documented variant of the same idea. Both address data by device code and number: D100 for a data register, M20 for an internal relay. A driver that asks for "device" and "head number" wants exactly those.
The trap here is the built-in Ethernet port's open-connection table. MC protocol only answers if a connection slot has been configured in the CPU parameters with the right protocol and port and then downloaded. A brand-new controller with a valid IP address will still refuse every MC protocol request until that table exists, and nothing in the error message says so.
- Tool: GX Works3 (iQ-R/iQ-F), GX Works2 (Q/L/FX).
- Data: MC protocol / SLMP on a port you configure; addressed by device code (D, M, W).
- Configure an open-connection slot in CPU parameters or MC protocol never answers.
Beckhoff — TwinCAT, ADS and AMS routes
Beckhoff does not connect the way the others do, and knowing why saves an afternoon. TwinCAT communicates over ADS, and every ADS participant is identified by an AMS NetID — six numbers that usually look like the IP address with .1.1 appended. Before your laptop can talk to a target, the two must exchange a static route: in the TwinCAT XAE system manager you add the route, supply the target's Windows or TwinCAT/BSD credentials, and the target records your machine as trusted. Without that route the target is reachable by ping and invisible to TwinCAT.
ADS uses TCP 48898 (plus 48899 for broadcast search), and the broadcast search is how you find targets whose IP you do not know. Because the target is often a Windows or BSD industrial PC rather than a sealed controller, its own firewall is part of the picture — the TwinCAT installer adds the rules, a hardened corporate image often removes them again.
For data out, ADS is also the runtime API: there are official and community ADS clients for C#, Python and others, so you can read a structured variable by symbol name without configuring a register map at all. Where a plant needs a neutral protocol, TwinCAT adds Modbus TCP, OPC UA and EtherNet/IP as supplements, each a licensed function.
- Tool: TwinCAT XAE (Visual Studio shell) — and a static ADS route before anything works.
- Identity: AMS NetID, not just an IP. Ports 48898 / 48899.
- Data: ADS by symbol name, or licensed Modbus TCP / OPC UA / EtherNet/IP supplements.
Delta, LS, Fatek, Wecon and the rest
Below the big six sits a long tail of controllers built around Modbus. Delta DVP and AS series (ISPSoft/WPLSoft), LS XGB (XG5000), Fatek FBs (WinProladder), Wecon, Kinco and dozens of OEM boards all answer Modbus RTU on their serial port and Modbus TCP on their Ethernet port, and their register maps are published in the manual as plain address tables.
That makes them easy to integrate and easy to get wrong in the same way every time: the manual numbers registers in documentation form (for example D0 = 40001) while the wire is zero-based, and the tools frequently expose a "station number" that must match the master's unit ID. When a link reads plausible-looking rubbish, the cause is almost always an off-by-one on address or a word-order assumption, not a broken device.
For a first connection these controllers use USB or a vendor serial cable, and their IDEs are small, free downloads. If a machine on your line uses one, download the tool and the register table before the day you need them — several vendors host them behind regional portals that are slow to grant accounts.
- Almost always Modbus RTU and Modbus TCP with a published register table.
- Watch the 1-based documentation versus 0-based wire address.
- Match the station/unit number, not just the IP.
Making two different brands talk
Once each controller is reachable, the real question arrives: a Siemens line controller must exchange twenty values with an Allen-Bradley cell, or an Omron packer must report counts to a Mitsubishi supervisor. There are five practical routes and they are not equally good.
Modbus TCP is the lowest common denominator. Every brand can be a client, a server, or both, either natively or with a library block, and the data is just registers. It costs you type safety and symbolic names — you maintain a shared spreadsheet mapping register 40012 to "infeed count" — and it is unauthenticated, so it belongs on a segmented machine network, never on a routed plant LAN.
OPC UA is the right answer when both ends support it and the data is supervisory rather than cyclic. It carries names, data types, timestamps and quality, and it authenticates and encrypts. It is heavier than Modbus, usually licensed (Siemens charges for the S7-1500 server, Beckhoff for TF6100), and it is not intended for millisecond machine interlocks.
Native protocol on the foreign device is often overlooked: a Siemens CPU can be a PROFINET controller for a drive from another vendor if the vendor ships a GSDML file, and a ControlLogix can own a third-party device that ships an EDS file. This gives you real cyclic I/O with diagnostics, at the price of committing to one brand's fieldbus.
A protocol gateway — Anybus Communicator, HMS, ProSoft, Moxa MGate — converts one fieldbus to another in hardware. It is the standard answer when the two systems must exchange cyclic I/O and neither will speak the other's bus: PROFINET on one side, EtherNet/IP on the other, a mapping table in the middle. Budget commissioning time for that table; it is where the project's hidden work lives.
MQTT with Sparkplug B is the choice when the destination is a historian, a cloud service or a dashboard rather than a machine. It is publish/subscribe, firewall-friendly because the device dials out, and self-describing. It is not for interlocks: there is no determinism and no guaranteed round-trip time.
- Modbus TCP — universal, cheap, no type safety, keep it on a segmented network.
- OPC UA — named and typed, authenticated, supervisory rather than cyclic, usually licensed.
- Native bus with GSDML/EDS — real cyclic I/O and diagnostics, one brand owns the bus.
- Protocol gateway — hardware translation for cyclic I/O between two incompatible buses.
- MQTT / Sparkplug B — outbound reporting to historians and cloud, never for interlocks.
Choosing the right connection — and the traps
Work down four questions in order and the choice makes itself. First, is the data an interlock or a report? Interlocks need a deterministic path: native fieldbus or a gateway, never MQTT. Second, how fast? Anything under about 50 ms belongs on the device level; a one-second supervisory read is comfortable on Modbus TCP or OPC UA. Third, who owns each end? If one vendor owns both controllers, their native method (S7 PUT/GET, Logix produced/consumed tags) is less work and better diagnosed than anything neutral. Fourth, where does the traffic cross a network boundary? Anything leaving the machine network must be authenticated, which in practice means OPC UA or MQTT with TLS.
The traps repeat across every brand. Subnet mismatch is first: a laptop on 192.168.1.x will not reach a controller on 192.168.0.x, and only Siemens DCP and a few vendor scans see past that. Duplicate IP addresses come next, usually after cloning a machine — two identical panels on one line, both at the factory default. Then firewalls and VPN clients: corporate endpoint software silently blocks ports 102, 44818 and 48898, and "it worked on the other laptop" is the tell.
On the data side, byte and word order is the recurring cost. A 32-bit value crossing two Modbus registers can be sent four ways and no standard picks one, so always confirm with a known value — send 0x12345678 or a float of 10.0 and read what arrives. Finally, licences and versions: Studio 5000 projects are version-locked, TIA Portal will not open a STEP 7 Classic project without migration, and an OPC UA server you assumed was included may be a paid option. Confirm all three before the shutdown window, not during it.
- Interlock or report? Determinism decides the protocol before anything else does.
- Same subnet, unique IP, and a laptop whose firewall lets 102 / 44818 / 48898 through.
- Prove byte order with a known value on every 32-bit mapping.
- Check tool versions and protocol licences before the shutdown, not during it.
Practice set
You arrive at a line with an S7-1500, a CompactLogix and an M241. Write down, for each, the tool you need, the port you must have open, and how you would find it if nobody knows its IP address.
S7-1500: TIA Portal, TCP 102, PROFINET DCP scan via Accessible devices. CompactLogix: Studio 5000 + RSLinx, TCP 44818, must be on the same subnet — use the BOOTP-DHCP tool or read the address from the CPU display. M241: EcoStruxure Machine Expert, USB for the first connection or TCP 502/Machine Expert network scan.
A Siemens line controller must send 20 process values to an Allen-Bradley cell once per second, and receive 4 command bits back. Choose a method and justify it in three sentences.
Modbus TCP with the S7 as MB_CLIENT and a gateway or the AB side as server is workable, but the cleanest is a protocol gateway (PROFINET slave to the S7, EtherNet/IP adapter to the Logix) if the 4 command bits are machine-critical. One second is not cyclic-critical, so OPC UA is also valid if both ends are licensed and the traffic crosses a network boundary. Decide on determinism first: command bits that stop motion belong on the deterministic path.
A cloned packaging machine was added to a line and both machines now behave erratically on the network. Name the most likely cause and the two commands you would use to prove it.
Duplicate IP addresses on the cloned panel. Prove it with `arp -a` after pinging the address (two MAC addresses answering for one IP), and with a switch port MAC table lookup, or unplug one machine and see whether the address still answers.
You must read data register D100 to D199 from a MELSEC iQ-F using a Python script. List everything you must configure on the PLC first.
A built-in-Ethernet open-connection slot with protocol (MC protocol/SLMP), a fixed local port, open method, and the IP parameters — then download the parameters. On the script side you address by device code D and head number 100 with a length of 100 words.
A plant wants every PLC's production counters in a cloud dashboard, across five brands. Propose an architecture and state one thing you will not do.
An edge gateway or IPC per line reading each controller by its native or Modbus path, republishing as MQTT Sparkplug B over TLS outbound to the broker. What not to do: expose the controllers' own protocols (502, 44818, 102) through the plant firewall to reach them directly from outside.
Module quiz
Your laptop is on 10.0.0.5/24 and a Siemens S7-1500 is on 192.168.0.1/24. Can you find it?
- No — different subnets
- Yes — PROFINET DCP discovery is not IP-bound
- Only with a serial cable
TIA Portal's Accessible devices scan uses PROFINET DCP broadcasts at layer 2, so the CPU appears regardless of IP, and you can assign a working address from that dialog.
Which port does Studio 5000 use to reach a ControlLogix controller?
- TCP 102
- TCP 502
- TCP 44818
- TCP 48898
CIP explicit messaging runs on TCP 44818. UDP 2222 carries the implicit cyclic I/O; 102 is Siemens, 502 Modbus, 48898 Beckhoff ADS.
A brand-new 1769-L33ER has no IP address. What is the standard way to give it one?
- The Rockwell BOOTP-DHCP tool
- A DCP broadcast from Studio 5000
- Rotary switches on the CPU
Rockwell Ethernet modules ship expecting BOOTP/DHCP. The BOOTP-DHCP tool sees the request, hands out an address, and can then disable BOOTP so the address is static.
TwinCAT can ping a target but refuses to go online. Most likely cause?
- Wrong PLC firmware
- No ADS route between the two AMS NetIDs
- EtherCAT cable in the wrong port
ADS needs a static route with credentials on both sides. Until that exists, the target answers ICMP and ignores TwinCAT entirely.
A Mitsubishi iQ-R has a valid IP but ignores every MC protocol request. What is missing?
- An open-connection slot configured in the CPU parameters
- A CC-Link IE module
- GX Works3 running on the client
MELSEC controllers only answer MC protocol on connections that have been declared in the built-in Ethernet parameters and downloaded — protocol, port and open method included.
A SCADA driver connects to an Omron CJ over FINS and reads only zeros. What do you check first?
- The network / node / unit numbers
- The Ethernet cable category
- The CPU battery
FINS addresses by network, node and unit as well as IP. A wrong node number produces a connection that works and data that is meaningless or empty.
Two controllers from different vendors must exchange a safety-relevant interlock every 20 ms. Which route is wrong by design?
- A PROFINET/EtherNet-IP protocol gateway
- MQTT with Sparkplug B
- Native fieldbus with the vendor's GSDML file
MQTT is publish/subscribe with no determinism and no guaranteed round trip. Interlocks belong on a deterministic device-level path — and safety interlocks belong on a safety protocol, not a data one.
You publish twenty values from a Schneider M241 to a third-party HMI. What is the zero-configuration option?
- OPC UA
- Modbus TCP on port 502
- EtherNet/IP tag links
Modicon controllers serve Modbus TCP out of the box and map %MW straight onto holding registers. That convenience is also a risk: enable IP filtering, because anyone on the network can write those registers.
A 32-bit float read over Modbus shows 2.3e-41 instead of 10.0. What is wrong?
- The device is scaling the value
- The two registers are in the wrong word order
- The wrong function code
0x41200000 is 10.0; word-swapped to 0x00004120 it decodes as 2.3e-41. Prove word order with a known value on every 32-bit mapping.
Which single check prevents the most "cannot get online" tickets across all brands?
- Confirm laptop and controller are on the same subnet with a unique IP
- Reboot the controller
- Replace the patch cable
Subnet mismatch and duplicate addresses — usually from a cloned machine — account for most failures. Only Siemens DCP and a few vendor scans see past a mismatched subnet.