Getting a CNC onto the network, control by control.
The planning that comes first, where each control family keeps its network settings, verification in the right order, and the five faults that cause most delays.
Getting a CNC onto the plant network is the step that delays more monitoring projects than any other, and almost never for a difficult reason. It is usually a duplicate address, a subnet mismatch, a machine on the wrong switch, or an address that changed because nobody reserved it.
This is the consolidated procedure for FANUC, Siemens, Mitsubishi, Haas and Mazak — the planning that comes first, where each control family keeps its network settings, and the verification that stops a commissioning visit being wasted.
Four decisions that prevent most of the problems.
Half an hour spent on these four decisions saves more commissioning time than anything else in this article. Write the result into a sheet — machine number, address, subnet mask, gateway, switch port, date — and keep it with the machine records.
Verify against your machine's own manual: labels vary with version.
| Control | Where to go | What you set | Notes |
|---|---|---|---|
| FANUC (0i / 30i families) | SYSTEM key, then the Ethernet or Embedded Ethernet screens via the soft keys | IP address, subnet mask, router/gateway | The embedded port and an optional Ethernet board are configured separately — confirm which one is cabled. A power cycle is generally needed. |
| Siemens SINUMERIK (840D sl / 828D) | HMI → Setup / start-up area → network or TCP/IP configuration | Address, subnet mask, gateway for the plant-network interface | These controls distinguish interfaces: a system-network port for internal drive traffic, a service port, and a company/plant-network port. Configure the plant-network one — X130 on many NCU and PPU variants. |
| Mitsubishi (M70 / M80 / M700 / M800) | Maintenance or parameter screens, Ethernet parameter area | IP address, subnet mask, gateway | Commonly held in the #1926 / #1927 / #1928 parameter group on M700 and M800 series. Confirm against your manual; a power cycle is required. |
| Haas (NGC) | Settings tab → Network page | Wired DHCP off, then IP address, subnet mask, gateway, DNS | Connection status is reported on the same page, which makes verification immediate. |
| Haas (Classic) | Numbered settings, 900 series | DHCP off, then address, mask, gateway, DNS | A control power cycle is usually required before the change takes effect. |
| Mazak (Matrix / Smooth) | The control runs on a Windows platform; network configuration is through the Windows network settings on the control | Adapter address, mask, gateway | Requires maintenance-level access. Where MTConnect is in use, confirm the agent is reachable as well as the machine. |
Every entry above is published machine operation, documented in each builder's own manual. None of it describes how MachineWise reads a control — that is configured by our engineering team and is a separate matter entirely.
Either is fine. What is not fine is an ordinary DHCP lease, because it will eventually change and monitoring will lose the machine without any obvious error — data simply stops, usually on a weekend.
A static address set on the control is simplest where you control the range and keep a written list. A DHCP reservation pins an address to the machine's hardware address at the server, which suits plants with an IT function that would rather manage addresses centrally. Both give the same outcome: an address that does not move.
For gateway-connected machines the same rule applies to the gateway rather than the machine, and the uplink may be Ethernet, Wi-Fi or 4G depending on where the machine sits.
Step 3 is the one nearly everyone skips, and duplicate addressing is the single most common cause of a monitoring connection that works intermittently. On floors with several machines of the same make commissioned years apart, defaults collide more often than anyone expects.
Duplicate address
Two machines commissioned years apart sharing a default. Symptoms are intermittent, which makes it hard to diagnose and easy to blame on software.
Subnet mask mismatch
The machine looks correctly configured and is unreachable from the server. Check the mask before checking anything else.
Wrong interface cabled
Particularly on controls with separate system, service and plant-network ports. The cable is in a port that was never meant to reach your network.
DHCP lease expiry
Worked for weeks, then stopped. Almost always an unreserved lease that moved.
Segmentation blocking the server
Reachable from the floor, not from the server. A routing question for IT, not a machine problem.
| Field | Why it is on the sheet |
|---|---|
| Machine number and make | So the row can be matched to the asset register |
| IP address | The thing you will look up most often |
| Subnet mask and gateway | Because a mismatch here is the second most common fault |
| Switch and port | So a physical trace takes a minute rather than an hour |
| Static or reservation | So the next person knows whether to look at the control or the DHCP server |
| Date and who set it | So a disputed change can be traced to a decision |
This sheet belongs with the machine records alongside the PLC backup and the mapping document. It costs ten minutes per machine and it is the difference between a connection problem taking five minutes and taking an afternoon.