Explainer

CNC Doc Management System: How Revision Control Works on the Floor

The software layer that decides which drawing, which G-code file and which inspection plan an operator may run right now. This page explains how that layer works, where it breaks, and how to tell whether your shop actually needs one. Written for engineers and buyers who sign off on the process, not for IT.

Get Instant Quote Talk to an Engineer

Revision controlG-code releaseTraceabilityISO 9001 / IATF 16949

CNC doc management system guide cover image

On this page

Key takeaways

It is a gate, not a folderIts job is to block the wrong revision, not to store the right one.

The unit of control is the releaseDrawing, model, program and setup sheet travel as one signed package.

Traceability is a byproductIf release and sign-off are logged, the audit trail writes itself.

Small shops still benefitEven one machine and two shifts can run two revisions by accident.

The costly failure is silentA wrong revision usually shows up as scrap, not as an error message.

Where it starts

Why a shared drive fails at the machine

A shared drive has no opinion. It will happily hold rev C and rev D in the same folder, and the operator picks whichever name looks newer. On a ±0.005 mm feature, the difference between those two files is often a changed cutter radius or a moved datum, and the first good part comes off the machine already out of tolerance.

Paper has the same problem in a different costume. A printed setup sheet is correct on the day it is printed. Three weeks later a revision lands, the printout does not update itself, and the shop is now running two processes at once. Nobody notices until inspection pulls the parts.

The point of revision control is not tidiness. It is to make the wrong file hard to reach. A folder invites a choice. A release removes the choice.

1
Datum shiftA revised drawing moves the zero and the old program cuts from the old one.
2
Tool changeNew corner radius in the model, old offsets still loaded in the control.
3
Material swapCert says 7075, the program was proven on 6061, feed rates no longer hold.

Anatomy

What a CNC doc management system actually controls

The controlled set is small and specific. CAD models from SolidWorks or CATIA, STEP files for the CAM side, G-code programs, setup sheets with work offsets and tool lists, inspection plans, and material certificates. Add the customer PO and any deviation approval. Everything else is reference material and can live wherever.

Each item carries metadata: part number, revision letter, machine group, release date, approver. The metadata is what makes search work at 2 a.m. on a night shift. An operator should be able to type a part number and get one result, not fourteen.

Release is the important verb. A file becomes usable only after someone with authority signs it off digitally. Before that it is a draft, visible to engineering and invisible at the machine. This single rule prevents most revision accidents.

The operator side should be boring. Open the terminal at the machine, see today's job list, tap the part, get the current program and setup sheet. No USB stick, no manual download, no guessing which file is live.

Boundaries

Where the system ends and engineering judgment begins

A CNC doc management system does not check whether a part is manufacturable. It stores the decision, it does not make it. If the drawing calls for a 0.5 mm internal corner on a 60 mm deep pocket, the system will release that file without complaint and the tool will still not fit.

It also cannot fix a bad CAM strategy. Feed rates, stepovers and tool engagement angles are process knowledge. Versioning them helps you repeat a proven process; it does not create one.

There is a cost side, too. Taxonomies that are too fine-grained collapse under their own weight. If every setup sheet has twelve mandatory fields, engineers start filling them with placeholder text and the data becomes noise.

The realistic boundary: control what the machine consumes, and keep the rest light. Programs, offsets, inspection criteria and certificates are the four that cause real damage when they go wrong.

Practice

How we run it at GreatLight

Drawings and models arrive, we run a DFM check, then the process is built in CAM. Before a program reaches a machine it is bound to the revision it was cut from. That binding is the whole trick. A program with no revision tag is treated as a draft.

Sixteen simultaneous 5-axis centers, twelve four-axis mills, twenty-seven three-axis machines and sixteen mill-turn centers generate a lot of files. With 127 machines across three plants and 7,600 m² of floor, the only workable rule is that the machine pulls the current release rather than the operator searching for it.

Inspection follows the same path. First article results, in-process checks and final reports attach to the release, so a ±0.005 mm callout can be traced back to the specific program and setup that produced it. We inspect 100% before shipment and issue reports on request.

Certifications shape the retention rules. ISO 9001:2015 and IATF 16949:2016 push us to keep revision history for the life of the part program plus the required retention window. ISO 13485:2016 adds device traceability. ISO 27001:2022 governs who may read a customer file at all.

1
One live revision per partOlder revisions go to archive, not to a subfolder at the machine.
2
No USB at the controlPrograms are pulled from the release, never carried in by hand.
3
Change needs an approverA revised G-code file cannot go live without a second signature.

Implementation

A rollout that does not stop production

1
Inventory the real document setList what each machine actually consumes: program, setup sheet, offset table, inspection plan, cert. Ignore everything else for now.
2
Define one naming rulePart number, revision letter, operation number. Keep it under 30 characters so it fits on a terminal screen without truncation.
3
Add a release stepDraft becomes released only with a named approver. Start with two approvers, not seven.
4
Pilot on one cellPick a machine group with frequent revisions. Run it for four to six weeks before touching the next cell.
5
Move the terminal to the machineIf the operator has to walk to an office PC to see the current revision, the old habit comes back within a week.
6
Archive on a scheduleSuperseded revisions move out on release of the new one. Keep them retrievable for audits, not visible at the machine.
7
Measure one thingCount scrap events caused by wrong revision. That number should go to zero, and it is the only metric worth watching at first.

Decision aid

Choosing the right level of control

Match the mechanism to the failure you are actually trying to prevent.

Method	Blocks wrong revision	Effort to run	Best fit
Shared drive + naming rules	No	Low	Single engineer, one machine, one customer
Paper traveler + locked PDFs	Partly	Medium	Low mix, long cycle times, few revisions
Lightweight DMS with release step	Yes	Medium	Job shops with 5–30 machines and frequent revs
Full PLM with CAD and CAM integration	Yes	High	Aerospace, medical, regulated revision history
Manual override allowed	No	Low	Prototype work only, never production

The straight answer

If your parts are prototypes with one engineer and one machine, naming rules on a shared drive are enough. If revisions arrive weekly and more than one shift touches the same part number, you need a release step, because the failure you are preventing is silent and expensive.

Get Instant Quote Talk to an Engineer

FAQs

Questions engineers ask next

Can we keep using our existing file names?

You can, but the system needs one field it can enforce. A revision letter embedded in the file name is the cheapest option because it survives export, email and CAM import.

If names vary by customer, add a mapping table instead of renaming files. Renaming historical files breaks every hyperlink and inspection record that points at them.

How long should superseded revisions stay available?

Long enough to cover your longest warranty and audit window. For automotive that usually means the production life of the part plus the retention period your customer contract states.

Practically, archive them rather than delete them. Retrieval during an audit takes minutes if the archive is searchable and hours if it is a pile of ZIP files.

Do we need PLM, or is a lighter system enough?

PLM earns its cost when CAD structure changes drive BOM changes and you need that link maintained automatically. That is common in aerospace and medical device programs.

For a job shop cutting to a drawing, a lighter release-based system covers the same risk at a fraction of the setup effort. Start light and upgrade if the BOM link becomes the bottleneck.

What about programs edited at the machine?

Allow it, but log it. A proven program that an operator speed-edits is now an unverified program, and the next shift inherits it without knowing.

The usual rule: edits are permitted for proving, then the change must be pushed back and re-released before the job runs again. Otherwise the file at the machine and the file in the system drift apart.

How does this connect to material certificates?

Certificates should attach to the release, not to the job folder. When a customer asks which heat of 17-4PH went into a lot, the answer should come from one search.

That link also catches substitution errors. If the certificate says 6061 and the program was proven on 7075, the mismatch is visible before the first cut.

Does confidentiality change the architecture?

It can. Customer files often carry access restrictions that a general shop network does not respect. Role-based access, encrypted storage and audit logging are the baseline.

We work under NDA on request, and uploads are handled as secure and confidential. If your program requires ITAR-level segregation, say so at the quoting stage rather than after the files arrive.