Cross-Network NAT Communication System for PLC, CNC and Other Equipment
This page explains how a cross-network NAT communication system moves data between PLCs, CNC controls and other equipment that sit on different subnets. It is written for controls engineers and maintenance teams who have to decide whether to translate addresses, bridge two networks, or change the addressing plan. After reading it you can pick a layout, size the gateway, and judge when NAT is the wrong tool.
In this article
- 1
- 2
- 3
- 4
- 5
- 6
Why PLC and CNC devices end up on separate networks
Walk the floor of most machine shops and you find the same pattern. A CNC control from one builder sits on 192.168.1.x. A PLC rack from another vendor sits on 192.168.0.x. The vision system, the robot, and the cell PC each brought their own default subnet, because nobody changes factory settings during commissioning.
Those subnets are not a design choice. They are defaults baked into controllers years ago, and every integrator who touched the line added one more. A cross-network NAT communication system exists to make those islands talk without re-addressing every node.
The cost of doing nothing is not dramatic failure. It is slow failure. Operators walk data across the plant on a USB stick. Production counts get typed twice. A change on one machine never reaches the MES layer because the route does not exist.
- 1Duplicate addressesTwo devices using 192.168.1.10 on the same wire is the classic fault.
- 2Vendor lockEach builder ships tools that assume its own subnet.
- 3No routeA router without translation will not forward a duplicated prefix.
How a cross-network NAT communication system translates addresses
NAT rewrites the source or destination address in a packet header as it crosses a boundary. A gateway keeps a translation table. When a PLC on 192.168.1.20 polls an HMI on 192.168.0.30, the gateway swaps addresses on the way through and swaps them back on the reply, so both sides believe they are talking to a local peer.
Two flavors matter on a shop floor. Static one-to-one mapping ties each real address to a fixed alias, which is what you want for PLC and CNC traffic because connections are long-lived. Dynamic mapping reuses a pool of addresses and breaks when a controller holds a socket open for days.
Port translation adds a second lever. If two CNC controls both answer on port 502, you can publish one as 192.168.1.50:5020 and the other as 192.168.1.50:5021. The controller never knows it was moved. This is the usual fix when you cannot edit addresses at all.
The gateway must understand the protocol well enough to keep the mapping alive. Modbus TCP, EtherNet/IP and PROFINET all carry embedded addressing that a plain IP-layer rewrite does not touch. That is where cheap routers fail and industrial gateways earn their price.
Where NAT fits and where it breaks
NAT is the right answer when you cannot touch the endpoints. Legacy CNC controls, sealed PLC projects and warranty-covered machines often fall into that group. It is also right when two networks must stay logically separate for security or ownership reasons, for example a machine builder's remote-support subnet next to your plant network.
NAT is the wrong answer for time-critical motion traffic. Address translation adds latency that varies with table lookups, and a servo drive chain that expects jitter under 1 ms will not tolerate a gateway in the path. Keep motion buses on one physical segment with a switch, not a router.
It also breaks down when protocols embed IP addresses in the payload and expect end-to-end visibility. Some diagnostics, broadcast discovery, and device-name resolution stop working through a translating gateway. Budget time for commissioning tests before you promise a cutover date.
A third boundary is scale. Every translated flow consumes a table entry and a timer. A cell with five devices is trivial. A plant with 400 nodes needs a gateway with a published session limit, plus documentation of which alias maps to which real device.
Sizing the gateway and planning the address map
Start from a device inventory. List every node with its current IP, subnet mask, gateway, protocol, and whether you are allowed to change any of it. That last column decides how much translation you need. Write the list down before you buy hardware, because the mapping sheet becomes the maintenance document later.
Size for concurrent sessions, not for total devices. A CNC control that polls a tool-data server every 200 ms holds a session permanently. Multiply by the number of talkers, add 30 percent headroom, and compare that number to the gateway's published limit. Most mid-range units handle a few hundred concurrent sessions.
Plan the alias ranges so a technician can decode them at a glance. If the real device is 192.168.1.20, publish it as 10.20.0.20 on the plant side. Keeping the last octet identical removes a whole class of support calls, and it costs nothing to do.
Give the gateway a fixed management address on both sides, and record it on the panel drawing. A translating device that nobody can reach is harder to debug than the original routing problem.
For the enclosure itself, the mechanical side is ordinary. DIN-rail chassis, mounting plates, and connector panels are milled or formed from aluminum or stainless, with cutouts held to ±0.1 mm so connectors seat without stress on the PCB.
What to test before you hand the line back
Test with the real protocols, not with ping. ICMP can pass while Modbus TCP times out, because the payload addressing is what breaks. Open an actual client for each protocol in the cell and read a real tag or register.
Watch the translation table under load. Run the normal production cycle and check that session count stays flat instead of climbing. A slowly growing table usually means connections are not closing, and the gateway will eventually refuse new flows.
Pull the power on the gateway mid-cycle and see what happens. Controllers with reconnect logic recover in seconds. Controllers without it need a restart, and that is a fact the production team should hear before the first shift, not during it.
Keep a printed mapping sheet inside the panel door. When a controller is replaced, the alias may need to change, and the person doing the swap at 02:00 should not have to open a laptop to find out.
Choosing between NAT, routing and re-addressing
Match the option to what you are allowed to change.
| Option | When it fits | What it costs you |
|---|---|---|
| Static NAT | Legacy PLC or CNC you cannot re-address | Gateway hardware and a mapping sheet |
| Port NAT | Two devices answer on the same port number | Reading logs becomes harder |
| Plain routing | Subnets are unique and can be planned | You must edit every endpoint |
| VLAN plus routing | You own the switch configuration | Switch and firewall skills |
| Direct switch | Motion bus with tight jitter limits | No segmentation between cells |
| Protocol gateway | Different fieldbus on each side | Payload mapping per tag |
The practical rule
If you cannot change addresses on the equipment, use a cross-network NAT communication system with static one-to-one mapping and a written alias sheet. If you own the addressing plan and the traffic is motion-critical, re-address the endpoints and use a plain managed switch instead of a translating gateway.
Common questions
Does NAT change the data inside the packet?
A standard NAT gateway rewrites IP and, with port translation, TCP or UDP headers. It does not normally touch the application payload.
That matters because some industrial protocols carry addresses inside the payload. Those need a protocol-aware gateway, not a plain router. Check the protocol documentation before you assume a simple rewrite is enough.
Can two devices with the same IP be used at once?
Yes, if they are on physically separate segments and each is published through a distinct alias or port on the gateway.
They must not share a segment before translation. Two nodes with the same address on one wire will collide, and no gateway can fix that after the fact.
How much latency does a translating gateway add?
Expect a small but variable addition, typically well under a millisecond per hop for ordinary control traffic. The variation matters more than the average.
Keep motion buses off the translated path. If a drive chain needs tightly bounded jitter, put those nodes on one switch and translate only the supervisory traffic.
What happens when the gateway fails?
Communication between the two networks stops. Each side keeps running its own local logic, so a CNC continues cutting and a PLC continues scanning its local I/O.
Cross-network data such as production counts or job downloads is lost until the gateway returns. Decide in advance whether that is acceptable for the cell, and write it into the risk assessment.
Do we need a managed switch as well?
Often yes. A managed switch lets you separate VLANs, set port security, and mirror traffic for troubleshooting. The gateway handles translation, not segmentation.
On small cells a single gateway with two ports may be enough. Above roughly ten nodes, separate the functions.
How do we document the installation?
Keep three items: a device inventory with real addresses, an alias mapping table, and a network drawing showing both sides of the gateway.
Update the alias table whenever a controller is replaced. Most cross-network faults we see trace back to a stale mapping sheet, not to the hardware.
Send us your network panel and chassis drawings
We machine and form the enclosures, mounting plates and connector panels that hold this equipment, from one prototype to 10,000+ part runs. Upload your files and we return a quotation with a free DFM analysis within 12 hours.
12-hour quoteNo minimum order quantity100% inspection before shipmentNDA on request
Follow GreatLight
We publish setup notes, tooling trials and inspection data from the factory floor.
