Siemens PLC and CNC Data Acquisition: How the Data Actually Moves

• 1
  Two different data sources sit inside one machine
• 2
  Reading PLC tags: scan time sets your real limit
• 3
  NC variables: request-based reads and their cost
• 4
  Getting the values off the machine with OPC UA
• 5
  Boundaries: when this architecture is the wrong fit
• 6
  When the machine parts themselves become the data
• 7
  Which acquisition path fits your requirement

A machining center running a Siemens control is not one data source. It is two, and they behave differently. The PLC side handles the machine: door interlocks, coolant, tool changer, hydraulic pressure, spindle enable. The CNC side handles the motion: axis position, feed rate, spindle speed, program number, tool offsets, alarm codes.

Engineers often treat both as one stream because both land in the same database. That works until someone asks why a cycle time reading disagrees with the part counter by two seconds. The PLC and the NC kernel are scanned at different rates and hold different definitions of when a cycle starts.

The split matters for another reason. PLC tags are usually published as a flat list you can subscribe to. NC variables live in a structured namespace that changes between control generations. You can read both, but you configure them separately and you diagnose them separately.

So the first design decision is not which protocol to use. It is which side owns each number you want. Get that wrong and no amount of gateway tuning will fix the mismatch.

• 1
  PLC sideDiscrete and analog machine states, scanned every few milliseconds
• 2
  CNC sideMotion and program data from the NC kernel, read on request or on event
• 3
  Shared clockWithout one, timestamps from the two sides drift apart

A PLC program runs in a scan cycle. It reads inputs, executes logic, writes outputs, then starts again. On a typical machine controller that cycle sits between 1 ms and 20 ms depending on program size and processor load. Any tag you read reflects the value at the last scan boundary, not the instant you asked.

This is the hard ceiling for PLC-side data. If your gateway polls a tag every 100 ms, you are already losing detail that existed in the controller. If you poll every 10 ms, you add network and CPU load without gaining much, because the scan itself only updated a few times in between.

For most production monitoring, 100 ms to 1 s is plenty. You are tracking states that last seconds or minutes: door open, cycle running, alarm active. Sub-millisecond PLC sampling belongs in motion control or safety logic, not in a reporting pipeline.

The practical rule is to poll slower than the scan and faster than the shortest event you care about. If a tool change takes 4 s and you want to see it, a 500 ms poll catches it with margin. A 5 s poll might miss it entirely.

• 1
  Scan cycle1–20 ms on most machine PLCs; sets the freshness floor
• 2
  Poll intervalKeep it above scan time to avoid wasted traffic
• 3
  Event durationPoll at least 4× faster than the shortest event you must capture

The NC kernel does not publish a tag list the way the PLC does. You request specific variables by identifier, and the control returns values. Each request costs processing time on the control, so a naive loop that asks for 200 variables every 50 ms will slow the operator panel and can trip watchdog limits.

Good practice is to group variables into a few bulk reads rather than many single reads. Ask for the block you need at the interval you need, and keep the total request rate modest. Many integrators settle on 200 ms to 1 s for NC-side data, which is fast enough for OEE and slow enough to stay invisible to the operator.

Some values are better pushed than pulled. Tool life, program end, and alarm events can be sent by the control when they change, so you do not have to poll for something that happens twice a shift. That reduces load and improves timestamp accuracy.

Accuracy of NC variables also depends on what you asked for. Commanded position and actual position are different variables. Feed override is not the same as programmed feed. Pick the wrong one and your cycle-time analysis will be consistently off.

• 1
  Bulk readsFewer, larger requests keep control load low
• 2
  Event-drivenPush tool life and alarms instead of polling them
• 3
  Commanded vs actualTwo separate variables; choose deliberately

OPC UA is the usual way to move data from a Siemens control to a higher-level system. It gives you a browsable address space, typed values, and a session model that survives brief network interruptions. On newer controls it runs natively; on older ones a gateway or communication processor sits in between.

A single OPC UA server can expose both PLC tags and NC variables, which is convenient. It is also where people get into trouble. Mixing a 20 ms PLC subscription with a 2 s NC read in the same session is fine technically, but the timestamps arrive with very different quality. Store the source and interval alongside the value.

Network design matters more than protocol choice. Keep the data link on a separate VLAN from the control network where possible. A reporting job that saturates the same switch as the machine's PROFINET traffic is a production incident waiting to happen.

For older machines with no native OPC UA, a small edge gateway that speaks the older protocol and republishes as OPC UA is the standard answer. It costs one box per machine and keeps the legacy control untouched.

• 1
  Native vs gatewayNewer controls publish OPC UA directly; older ones need an edge box
• 2
  Separate VLANNever share the control network with bulk reporting traffic
• 3
  Store the intervalA value without its sample rate is hard to interpret later

Data acquisition is not free. Every subscription costs control CPU time and network bandwidth. On a machine already running near its processor limit, adding a 50-tag, 100 ms subscription can push cycle times up and trigger alarms. Measure control load before you commit.

It is also a poor fit for high-frequency waveform capture. If you need vibration or servo current traces at kilohertz rates, the PLC and OPC UA path is the wrong tool. Use a dedicated data acquisition card or drive-level trace function and export the buffer afterward.

There is a maintenance cost too. NC variable identifiers change between control generations and sometimes between firmware versions. A pipeline built on hard-coded addresses will break at the next upgrade. Keep the mapping in a configuration table, not in code.

Finally, decide up front what the data is for. Real-time closed-loop control needs deterministic timing and belongs on the machine. Reporting, OEE, and traceability tolerate seconds of latency and belong on the server. Mixing the two goals in one pipeline usually delivers neither.

• 1
  Check CPU headroomMeasure control load before adding subscriptions
• 2
  Not for waveformskHz traces need dedicated hardware, not OPC UA
• 3
  Config, not codeKeep variable mappings outside the application

Data acquisition usually stops at the control cabinet. But the reason most teams build it is to understand what happened to a physical part. That link only works if the parts are made to tolerances tight enough that the process data means something.

GreatLight machines production parts to ±0.005 mm (±0.0002 in) on 127 high-precision CNC machines, including 16 simultaneous 5-axis machining centers and 16 mill-turn centers. Maximum processing size runs to 4,000 mm. Surface finish lands between Ra 0.2 μm and Ra 3.2 μm depending on the operation.

For teams running traceability programs, we quote and return a free DFM analysis within 12 hours, and production can start within 24 hours. Parts ship in 3–5 days. There is no minimum order quantity, so a single prototype and a 10,000-part run go through the same process.

We work in aluminium 6061 and 7075, stainless 304 and 17-4PH, titanium Ti-6Al-4V, Inconel, and engineering plastics including PEEK and POM. Inspection is 100% before shipment, with reports on request. Uploads stay confidential and an NDA is available.

• 1
  Tolerance±0.005 mm, with inspection reports on request
• 2
  ScaleOne prototype to 10,000+ parts, no MOQ
• 3
  TimingQuote in 12 hours, ship in 3–5 days