Is your CNC machine tool connected to the internet?

• 1
  What happens when a CNC machine tool connected to the internet sends data
• 2
  What data is worth moving off the machine
• 3
  Where the internet boundary should sit
• 4
  When a CNC machine tool connected to the internet is the wrong choice
• 5
  What connectivity changes on the machining side
• 6
  Connectivity options by machine age and data need

A CNC controller does not speak internet. It speaks fieldbus and serial: FANUC FOCAS, Siemens 840D, Mitsubishi MELDAS, Heidenhain, or a plain RS-232 port on an older mill. The first job of any connectivity project is to translate those local protocols into something a server can read. That translation usually happens on a small industrial PC bolted to the side of the electrical cabinet, not inside the controller itself.

That box is called an edge gateway. It polls the machine every 100 ms to 1 s, reads spindle load, axis position, program number, alarm codes and cycle state, then republishes the data as MTConnect, OPC UA or MQTT. The polling interval matters. Sub-second polling gives you waveform-level detail for vibration studies, while a 1 s interval is enough for dashboards and OEE tracking.

From the gateway, data travels over Ethernet to a shop switch, then to a plant server, and only after that does it cross a router to the internet. Each hop adds a place where data can be lost or leaked. Count the hops before you draw the network diagram. Most troubleshooting calls come down to a mislabeled VLAN on one of those hops.

One practical detail: older controllers with only RS-232 output cap out near 19.2 kbaud. You cannot stream high-frequency data through that port no matter how good the gateway is. In those cases the gateway buffers a summary every few seconds instead of raw samples.

• 1
  Fieldbus firstFOCAS, PROFINET or Modbus TCP stays inside the cabinet.
• 2
  Edge translationGateway converts to MTConnect, OPC UA or MQTT.
• 3
  Serial ceilingRS-232 tops out near 19.2 kbaud, so summarize instead.
• 4
  Count the hopsController, switch, server, router, cloud.

Not every signal deserves a network cable. Divide machine data into three buckets: process data, asset data and part data. Process data covers spindle speed, feed override, axis load and coolant state. It changes every second and is only useful for live monitoring. Asset data covers runtime hours, alarm history, servo current trends and maintenance counters. It changes slowly and is what predictive maintenance models actually consume.

Part data is the third bucket, and it is the one that touches your customer. Program files, tool offsets, probe results and inspection records belong here. When a job is traceable, part data has to be versioned and tied to a serial number. That is a document-control problem more than a network problem, but the network is how the record travels.

A common mistake is to push all three buckets to the cloud at full rate. The bandwidth is rarely the limit. The limit is the human who has to read the dashboard. Teams that dump everything usually stop looking at it within a month. Pick 8 to 12 tags per machine and make those reliable.

For job shops running one to ten machines, the honest answer is that a shared network folder for programs plus a spreadsheet of run hours covers 80% of the value. Full MTConnect infrastructure starts to pay back when you have 15 or more machines, or when a customer contract requires traceable records.

• 1
  Process dataFast-changing signals for live monitoring only.
• 2
  Asset dataSlow counters that feed maintenance models.
• 3
  Part dataPrograms, offsets and inspection records tied to serials.
• 4
  Tag discipline8 to 12 reliable tags beat 200 noisy ones.

The safest architecture puts a boundary between the machine network and everything else. Machines live on their own VLAN. The gateway has one interface on that VLAN and one on the business network. Nothing on the machine VLAN can reach a browser, an email client or a USB stick. This is the same segmentation logic used for building control systems, and it costs almost nothing to set up.

Remote access is the part that gets shops in trouble. Opening an inbound port to a controller is a bad idea, and it is also unnecessary. A VPN with per-user credentials, or a reverse-tunnel agent that dials out from the gateway, gives the OEM or the integrator access without exposing the controller to port scans. Log every session. If your machine builder asks for a public IP address, ask why.

Outbound-only connections are the default we recommend. The gateway initiates the session, the cloud answers, and no inbound rule exists on the firewall. That single design choice removes most of the attack surface while keeping remote diagnostics and OTA parameter updates working.

Physical access still matters. A shop-floor USB port bypasses every firewall rule you wrote. Disable autorun, scan removable media at a kiosk, and keep a written policy for program transfer. Network security with an open USB port is decoration.

• 1
  Machine VLANNo route to business network or internet.
• 2
  Dual-homed gatewayOne leg on machine VLAN, one on plant LAN.
• 3
  Outbound onlyReverse tunnel instead of inbound port forwarding.
• 4
  USB policyMost breaches walk in through the shop door.

Some machines should stay offline, and that is a defensible engineering decision, not a lack of ambition. A legacy controller running an unsupported operating system cannot be patched. If the vendor no longer ships security fixes, adding a network card turns a stable machine into a permanent liability. Run it on a standalone PC with a USB stick and document the exception.

Safety circuits are a second boundary. Emergency stop, light curtain and door interlock logic should never depend on network state. If a packet drop can delay a stop signal, the design is wrong. Keep safety on hardwired or dedicated safety-bus paths and let the network only observe.

A third case is high-value or export-controlled work. If the part geometry itself is sensitive, the CAD file and the post-processor output are the assets worth protecting. A machine that only receives G-code from a local server and never talks outbound is easier to defend than one with a live cloud link.

The practical rule: connect for visibility, not for control. Monitoring, alarm push and program distribution are low-risk wins. Remote start, remote parameter writes and remote axis motion raise the consequence of a single credential leak by a large margin. Decide which list you are on before you buy hardware.

• 1
  Unpatchable OSKeep offline and transfer by controlled media.
• 2
  Safety logicHardwired or safety bus, never general network.
• 3
  Sensitive geometryLocal server only, no outbound path.
• 4
  Visibility vs controlRead is cheap, write is expensive when it fails.

On the production floor, the visible benefit is program distribution. Instead of walking a USB stick to each machine, the operator pulls the released revision from a server. Version control stops the classic failure where two machines run two different revisions of the same job. For shops running aluminum and stainless parts at ±0.005 mm, that alone can remove a recurring scrap source.

The second benefit is tool life tracking. Cutting 17-4PH or Inconel loads the tool differently than 6061. If spindle load and cycle count are logged, tool changes move from a fixed schedule to a condition-based one. On titanium and nickel alloys this often extends usable tool life without risking a scrapped part.

The third benefit is quoting feedback. Real cycle times from a machine running the actual program beat any estimate. After a few hundred jobs, the shop has its own cost model. That is a genuine competitive advantage, and it does not require a cloud subscription.

None of this replaces inspection. Data tells you a machine ran; it does not tell you the bore is in tolerance. Keep 100% inspection before shipment in place, and treat network data as a process signal, not a quality record.

• 1
  Program controlOne released revision, pulled by the operator.
• 2
  Tool lifeCondition-based changes on hard alloys.
• 3
  Cycle time dataReal times feed a real cost model.
• 4
  Inspection staysNetwork data is a process signal, not QC.