How to Configure CNC Machine Tool Data to Heidenhain Controls

• 1
  Key takeaways
• 2
  What you need before you configure CNC machine tool data
• 3
  LSV2, OPC UA and other ways to reach the control
• 4
  Choosing the tags and polling rates that matter
• 5
  Where to normalize and store the data
• 6
  Testing, security and handover on the shop floor
• 7
  5 steps to configure CNC machine tool data to Heidenhain
• 8
  Which Heidenhain interface fits your machine

Data acquisition on a Heidenhain control is not a network job you can finish in an afternoon. The control exposes machine states, axis positions, program numbers, tool data and messages, but only through specific interfaces. Before you touch a cable, write down which signals the plant actually needs. A cycle-time dashboard needs different tags from a predictive-maintenance model, and the difference changes the whole acquisition architecture.

Start with the control model and software level. TNC 640, TNC 7, iTNC 530 and older TNC 4xx/3xx units do not all speak the same protocol. Check the NC software number in the control's machine information screen. That number decides whether you can use the OPC UA NC Server, whether you need software option 18 for the LSV2 interface, and whether remote access is possible at all.

Then confirm the physical path. Most shops run a separate network segment for machine tools, isolated from the office LAN. A small industrial gateway or edge PC sits on that segment, talks to the control, and forwards normalized data northbound. Keep the gateway close to the machine cabinet so cable runs stay short and electrical noise stays low.

Finally, agree on a time source. Two machines with unsynchronized clocks will produce a shift report that nobody trusts. Point every device at the same NTP server, or accept a small offset and record it in the tag map. This single decision saves more debugging time than any protocol tuning.

• 1
  Control model and NC software levelDecides which interface is available.
• 2
  Signal listMachine state, program, tool, alarm, position.
• 3
  Network segmentKeep controls off the office LAN.
• 4
  Time sourceOne NTP server for all devices.

Heidenhain controls offer several data paths, and the right one depends on age and license. LSV2 is the classic binary protocol over TCP, historically used by TNCremo and DNC software. On many controls it needs software option 18 to be active. It gives access to files, tool tables, PLC data and some status information, but the tag names are control-specific and change between software versions.

OPC UA is the cleaner option on newer controls. The OPC UA NC Server exposes a structured address space with machine states, program information, tool data and axis values. Because the namespace follows a documented model, mapping into a SCADA or MES is straightforward. The trade-off is that OPC UA support is limited to newer NC software levels, and older iTNC 530 units usually cannot run it.

A third route is the PLC or machine-data interface, sometimes called the M-interface or a vendor gateway. This reads internal PLC words and maps them to custom tags. It is powerful because you can expose signals the standard interfaces hide, but it requires control-side configuration and a solid understanding of the machine builder's PLC program.

Serial and fieldbus options exist on legacy machines. If the control predates Ethernet, an RS-232 or fieldbus adapter may be the only way in. Expect slower polling, fewer tags and more manual mapping. For machines older than roughly 2005, weigh the integration cost against simply reading a digital I/O block for run/stop and cycle counts.

• 1
  LSV2Broad support, needs option 18 on many units.
• 2
  OPC UA NC ServerClean model, newer NC software only.
• 3
  PLC / M-interfaceDeep access, control-side work required.
• 4
  Serial or fieldbusLast resort for pre-Ethernet machines.

Most plants ask for everything in the first meeting. That request produces a system that is expensive to build and slow to maintain. A better approach is to split tags into three tiers. Tier one is machine state: run, stop, alarm, setup, program number. Tier two is production data: cycle time, part count, spindle load. Tier three is condition data: axis following error, drive current, tool life remaining.

Tier one can be polled every 1 s to 5 s without stress. Tier two usually works at 5 s to 30 s. Tier three is where polling rates matter, because condition monitoring needs a stable sample interval to detect a trend. If you sample drive current every 30 s and then every 2 s during a test, the trend line is meaningless. Fix the interval and document it in the tag map.

Tag naming should follow a plant convention, not the control's internal naming. Use something like LINE1_TNC640_SPINDLE_LOAD, so a historian query does not depend on knowing which control generated the value. Keep units in the name or in a separate units column. A tag called spindle_load with no unit will be misread by someone within a month.

Tool data deserves special care. Tool number, tool life remaining and tool status change at different moments. If you poll them together at 30 s, a tool change can be missed between samples. For tool-break detection, either poll faster or read the tool-change event from the PLC interface rather than polling the tool table.

• 1
  Tier 1: machine statePoll every 1 s to 5 s.
• 2
  Tier 2: production dataPoll every 5 s to 30 s.
• 3
  Tier 3: condition dataFixed sample interval, not variable.

Collecting raw control values into MES is a common mistake. The control reports states in its own encoding, and those codes are not stable across software versions. Put a normalization layer between the gateway and the plant system. That layer translates control codes into a plant-standard state model, adds timestamps, and handles missing values.

The gateway or edge PC is the right place for this work. It can buffer data during network outages, apply deadband filtering so a stable signal does not flood the historian, and expose a single OPC UA or MQTT endpoint northbound. A 2% to 5% deadband on analog values like spindle load cuts storage volume with almost no loss of information.

Choose the storage layer by use case. A time-series database suits condition monitoring and cycle-time trends. A relational database suits work-order and tool-life records. Many plants run both, with the historian holding raw samples and the relational side holding aggregated shift results.

Keep raw and normalized streams separate. When a mapping bug appears, you can replay the raw stream through the fixed mapping without asking the machine to reproduce a shift. This is the single most useful design choice for troubleshooting later.

• 1
  Normalize at the edgeDo not push raw control codes into MES.
• 2
  Buffer during outagesPrevents gaps in shift reports.
• 3
  Keep raw samplesAllows replay after mapping fixes.

Commission one machine first. Connect the gateway, load the tag map, and compare every value against the control screen for at least one full shift. Cycle time is the best check, because it is easy to verify by hand. If the collected cycle time drifts from the control's own counter, the timestamp or the trigger logic is wrong.

Watch the network. A gateway that polls 200 tags every second on a shared segment can slow file transfers or remote diagnostics. Measure switch port utilization during a busy shift. If it climbs above roughly 40%, increase the interval or split the polling groups.

Security matters even on an isolated segment. Change default credentials on the gateway, disable unused services, and log every configuration change. If the plant allows remote access for diagnostics, route it through a jump host rather than exposing the control directly. Uploads and configuration files should be treated as confidential plant data.

Plan the handover before the pilot ends. Document the control model, NC software level, interface used, tag map, polling intervals and known limitations. A short document that says which tags are unreliable on which machine saves the next engineer days of guesswork.

• 1
  Verify one shiftCompare collected values against the control screen.
• 2
  Measure port loadKeep utilization below about 40%.
• 3
  Document limitationsNote which tags are unreliable and why.