Archiving SINUMERIK 840D NC Programs with Version Control

Problem Scope

A shop runs lathes on SINUMERIK 840D controls at differing software and MMC versions and mills on Fagor controls. NC programs are hand-written in a plain text editor and dumped into one directory per machine; setup sheets, tool lists and drawings live in parallel directory trees. There is no link between a part number, its revision, the machine it was proven on, and the documents that belong to it, and no version history at all.

As parts grow more complex the programs get longer, manual DIN/ISO edits get riskier, and the cost of a bad transfer moves from a scrapped part to a crashed spindle. The engineering task is therefore two separate problems that are often bundled into one purchase:

1. Program and document management - identity, revision, approval state, and the machine/part linkage.
2. Verification - DIN-code simulation of turning and milling before the file reaches the control.

Constraints Imposed by a Mixed 840D / Fagor Fleet

Any archive design has to survive the following, because they are properties of the machines, not of the software you buy:

The last row is the usual elimination criterion. A lightweight NC program archiver that only understands ASCII program files forces workarounds for DWG drawings and XLS/ODS setup sheets, and workarounds are exactly where revision control fails.

Repository Structure and Naming Convention

Before buying anything, fix the identity scheme. This is portable across every tool you might later adopt and is the part that actually prevents errors.

Use a composite key of part number - operation - machine - revision:

<PARTNO>_<OPNO>_<MACHINE>_R<nn>.MPF

Example:  144207_OP10_DMG04_R03.MPF
          144207_OP10_DMG04_R03.XLS   (setup sheet + tool list)
          144207_R00.DWG              (drawing, revision independent of NC)

Rules that make this work:

1. Revision is immutable. Never edit R03 in place. Copy to R04, edit, then archive R03 read-only. This gives you version history even on a bare file server.
2. One released revision per machine. Keep a RELEASED folder containing only the current proven revision per part/machine and a WIP folder for everything else. Only RELEASED is allowed to feed the DNC transfer.
3. Header block in every program. Put the identity into the NC text itself so it is visible on the control:

; PART   : 144207 REV C
; OP     : 10  TURN + DRILL
; MACHINE: DMG04  840D
; NC REV : R03   2026-08-20  ED
; TOOLS  : T1 D1 ROUGH, T3 D1 FINISH, T7 D1 DRILL 8.5
; ZERO   : G54 = CHUCK FACE

4. Checksum the released file. Store a hash (or at minimum file size and byte count) with the release record so a corrupted or silently edited transfer is detectable.
5. Subprograms are versioned as dependencies. If 144207_OP10 calls a shared SPF, the release record must name the SPF revision it was proven against.

Tooling Options and How to Evaluate Them

Three functional layers exist; you can mix vendors per layer.

Commercial NC editors with integrated backplot are sold in the low hundreds of euros per seat, with the database/DNC layer licensed separately as a server plus per-client model. Indicative figures seen in vendor quotations for this class of product:

Free CNC simulators for turning and milling exist and are worth trialling for backplot verification, but validate them against a known-good program first: run a part you have already cut, confirm the plotted path matches the actual result, and confirm the simulator handles your cycle calls rather than skipping them silently. A simulator that ignores unrecognised blocks is worse than no simulator.

If a five-axis or mill-turn machine is on the horizon, budget separately for full machine-model verification with collision checking against the kinematic model - a 2D/3D backplotter does not cover tool holder, turret and tailstock collisions.

Implementation Sequence

1. Freeze the current state. Take a full read-only copy of every existing machine directory before touching anything. This is your fallback.
2. Build the part-number index. For each existing program, record part number, operation, machine, date last run, and whether it is proven. Anything unproven or unidentifiable goes to a quarantine folder, not into the release tree.
3. Rename into the convention and insert the header block. Do this machine by machine, starting with the lathe that produces the most repeat work.
4. Attach documents. Link setup sheet and drawing to the part/operation record. If your chosen tool cannot hold DWG/XLS attachments natively, store them alongside in the same folder with the same key - never in a parallel tree with a different naming scheme.
5. Pull a fresh archive from each control and diff it against the file server copy. Undocumented edits made at the control are the normal case; the diff tells you where the file server is already wrong.
6. Establish the release gate: edit in WIP -> simulate/backplot -> transfer -> prove out at the machine -> pull the as-run program back from the control -> diff against WIP -> promote to RELEASED with a new revision number.
7. Lock down write access to the RELEASED tree so only the release step can write to it.
8. Back up the whole repository on the normal IT schedule and test a restore.

Verification and Ongoing Checks

The economic argument for spending on the DNC layer is straightforward: one avoided crash on a mid-size turning centre typically exceeds the cost of a server plus a handful of clients. Size the spend against crash exposure and lost spindle hours, not against the sticker price of a text editor.

FAQ