How to organize a library of validated cutting conditions without version chaos ART-144

Why an ordinary table quickly turns into chaos

At the beginning, a cell needs only a few rows in a table. Then different steel grades, actual thicknesses, film, coatings, gas batches, nozzles, optical changes, control updates and special customer requirements appear. An operator adjusts a condition to a real batch, the technologist saves a different copy, and a service specialist restores baseline settings after repair. Within months, one material name can have five “final” files.

The main problem is not the number of parameters. The problem is that different entities are mixed together:

• a factory or supplier starting table;
• a locally validated condition;
• a temporary correction for a particular batch;
• an experimental test;
• a part program or nest;
• a historical condition that may no longer be used.

If these entities are not separated, it is impossible to tell whether a change was validated or concerned one order only. This creates repeated trials, unstable quality, unnecessary metal consumption and arguments between shifts.

What exactly is a library record

One record is not “all conditions for mild steel.” It is a specific controlled combination of conditions. A minimum card should include:

| Group | What to record | Why | |---|---|---| | Identity | stable ID, name, version, status | distinguish a current record from a copy | | Equipment | machine model/ID, source, head, software or postprocessor version | prevent transferring a condition between incompatible configurations | | Material | standard/grade, thickness, permitted actual-thickness range, surface state, film | define the boundary of use | | Process | gas and its specification, nozzle type/diameter, optical configuration, quality class | reproduce validation conditions | | Parameters | controlled-parameter set with units | avoid ambiguous figures | | Validation | test part, acceptance criteria, date, result, author and reviewer | distinguish a validated condition from a hypothesis | | Change | reason, linked request/incident, previous version | reconstruct decision logic |

In Process Material Library documentation, Autodesk explicitly links material to properties such as ID, category, thickness and density, and treats nesting parameters as controlled settings. This is a useful principle: a condition should refer not to arbitrary text such as “stainless,” but to a defined material record. SigmaNEST also describes parameters dependent on material type and thickness as well as placement rules. A library therefore needs to store context, not only speed.

A stable ID matters more than a nice name

People will edit a name. An identifier must not change. A working format can be simple, for example `CP-LSR-000184`, where CP means cutting parameter record. The ID should not encode the full hierarchy: material, thickness and machine are better held in separate fields. Otherwise a material-name change or record migration would require changing links in history.

Keep the version separately: v1, v2, v3. Create a new version when a technologically significant parameter, boundary of use, equipment or quality criterion changes. A spelling correction or an added photograph in the protocol can be an editorial update if it does not change the production decision. Define this rule once and apply it consistently.

Five statuses are enough to begin

An excessive workflow also creates chaos. For a small cell, these states are sufficient:

1. DRAFT — the record exists but is not allowed for production use. 2. TEST_PLANNED — the test, blank and criteria are defined. 3. VALIDATED — the test was executed in a recorded configuration. 4. RELEASED — the responsible person allowed production use. 5. RETIRED — the record is retained for history, but selection in new tasks is blocked.

VALIDATED and RELEASED should not be combined. A test may succeed while the condition is not yet ready for general use: for example, it needs checking on a repeat batch or lacks confirmation for protective film. RETIRED does not mean deletion. A deleted record destroys traceability for old orders.

ISO 10013 concerns documented information in a quality-management system and stresses maintaining it in light of the organization’s needs and risks. For a condition library, the practical conclusion is to define what information must be maintained as current, what must be retained as evidence, who may change it and how accidental use of an obsolete record is prevented.

Roles without bureaucracy

The operator should see the current condition, its boundary of use and a short pre-start verification instruction. They can register a deviation or propose a correction, but should not silently overwrite the reference.

The technologist creates a new version, plans a test, describes criteria and analyses the result. Another competent person — a senior technologist, cell manager or designated reviewer — releases the version. In a small enterprise this may be two people, but the roles “changed” and “approved” should preferably be separate.

The CAM administrator is responsible for technical deployment: library availability at workstations, backups, rights, postprocessor consistency and synchronization. Service records equipment-configuration changes that can require revalidation of conditions.

How to validate a new or changed condition

A safe procedure must not turn this article into a laser-setup instruction. It describes control; specific parameters come from manufacturer documentation and enterprise work instructions.

1. State the reason. New material, supplier change, edge defect, software update, component replacement or cycle reduction are different tasks. 2. Record the baseline version. Begin the experiment from a known record; do not overwrite it. 3. Define the test scope. Machine, material, thickness, surface, gas system, nozzle and control part. 4. Set criteria before the test. Cut-through, geometry, edge, burr, thermal effect, pierce stability, repeatability, time and resource consumption — only criteria actually needed. 5. Run the test under local safety rules. Authorized personnel perform the work; this article does not replace manufacturer instructions. 6. Retain the result. Photographs, measurements, material number, deviations and conclusion. 7. Release or reject the version. Retain a failed test too, so it is not repeated.

One successful cut does not prove stability. The enterprise determines repeat count according to part risk. Criteria for a decorative blank and a serial part with critical geometry are not the same.

How to distinguish a condition from a program and a nest

This is ART-144’s key boundary. A condition describes technological cutting conditions for a defined context. A CAM program contains paths, sequencing, lead-ins, micro-joints and other decisions for a particular geometry. A nest adds part positions on a sheet and order constraints.

One condition can be used in many programs. One program can refer to several conditions if it has different contours or operations. Therefore the program file must not be the sole storage place for technological knowledge. TRUMPF Praxis and Autodesk describe part, material and template libraries and programming as related but distinct elements of the digital process. Such separation makes reuse easier and reduces hidden copies.

Naming rules that actually help

A human-readable name can take the form “material — thickness — gas — quality/purpose — machine.” But a name is not proof of compatibility. Structured fields are required in addition. Take abbreviations from one directory. St3, S235, “mild,” and “steel 3” must not automatically be treated as the same material. If the enterprise accepts them as equivalent for a particular process, that must be a separate controlled rule.

Do not put words such as final, new, best or the operator’s name in a title. Status determines validity, version number and date determine recency, and responsibility belongs in a separate author field.

When to create a new record and when a new version

A new version is appropriate when the same boundary of use and comparable result remain, but a controlled parameter changes or the boundary is refined. A new record is needed when the condition actually answers a different task: another machine, material, technological gas, fundamentally different quality class or a configuration that cannot safely inherit earlier validation.

A useful test is: can a user accidentally select the new option instead of the old one for the same order? If yes, it is likely a new version. If both options must remain current for different conditions, they are separate records with clear selection rules.

Events that require review

The library is not static. Review can be triggered by:

• a change of source, head, optics, nozzle system or control;
• a new postprocessor or CAM version;
• a change of material or gas supplier;
• recurring defect or service incident;
• a new quality requirement;
• a long period without use;
• mismatch between estimated and actual cycle;
• discovery that operators regularly use manual corrections.

Review does not always require repeating the full test. Determine the level of checking by the change impact. But the decision that “validation remains valid” must also be recorded.

A controlled condition-change scenario

Consider a practical situation without technological figures. A cell already has a released record for a certain grade and thickness on a particular machine. An operator notices that a new sheet batch gives a different edge and applies a temporary correction permitted by the local instruction. This is not grounds to overwrite the `RELEASED` version immediately.

The correct route has five separate events:

1. the operator records the observation, material batch, program and current condition ID; 2. the technologist creates a new draft linked to the baseline version, while the old record remains unchanged; 3. scope of use and acceptance criteria are defined before the test; 4. a reviewer verifies the result without substituting their own assumption for the test fact; 5. after the decision, the new version is released or rejected with evidence retained.

If the difference is confirmed only for one batch, the correction can remain a limited exception with an end date. If it repeats across several batches and passes acceptance, create a new version or separate record depending on whether the boundary of use remains. This enables reconstruction of why a particular order was performed differently from the earlier reference, without turning every operator observation into a new “final” condition.

For control, an audit trail of four event types is enough: creation, test, approval and retirement. Each event must record time, user, previous state and reason. If a system allows parameter changes without such an event, versioning is only formal.

Minimum implementation without expensive MES

For a start, a centralized table or database with controlled rights, an evidence folder and a rule for export to CAM are sufficient. System names do not matter; the controls do:

• one source of truth;
• only released versions are available for normal production selection;
• drafts are separated;
• every change has an author, date and reason;
• old versions are not deleted;
• backup is tested through restoration;
• the program link points to an exact ID and version;
• export after a change is confirmed.

A shared folder without rights and a log is not a library. Likewise, an ERP form without a real connection to CAM does not remove risk: an operator can see the correct record in the system while the machine actually uses a local old copy. A controlled synchronization procedure is needed.

Typical mistakes

First, treating a factory table as validated for every metal. It is a starting basis within the documentation of particular equipment, not a result guarantee for every batch.

Second, allowing a current record to be edited without a new version. Then an old order cannot be reproduced.

Third, retaining only parameters without quality criteria. It is then unknown why the condition was accepted.

Fourth, creating a separate condition after every manual correction. This produces hundreds of unverified records. First record the correction as an observation; create a new version after analysis.

Fifth, transferring a record to another machine because power is the same. Compatibility depends on the entire configuration and must be verified.

Library audit checklist

• [ ] Every record has a stable ID and separate version number.
• [ ] Only one current released version is visible for a specific scope.
• [ ] Material, thickness, gas and equipment are recorded structurally.
• [ ] Units of measure are not left “by default.”
• [ ] Validation criteria and evidence exist.
• [ ] A change author cannot silently replace a historical record.
• [ ] Drafts do not enter production selection.
• [ ] The program refers to the exact condition version.
• [ ] Equipment changes trigger review.
• [ ] It is possible to find orders where a retired condition was used.
• [ ] Backup restoration has been tested.
• [ ] Operators know how to report a deviation.

Practical result

A good library does not prohibit a technologist from experimenting. It separates an experiment from an authorized production decision. Begin not by moving all old files, but with the 10–20 most frequent combinations: clean up names, assign IDs, confirm scope, attach evidence and release one current version. Add the rest during real work.

The success criterion is simple: another trained operator on another shift can find the same condition, understand its limits and use the approved version without calling the file author. If this is impossible, the table has not yet become a controlled library.

Safe boundaries

• Does not contain working numerical cutting parameters.
• Does not permit transferring a condition between machines without verification.
• Does not replace manufacturer instructions, risk assessment or personnel authorization.
• Does not claim L-SEL compatibility with a specific CAM or MES without separate technical verification.

Need service advice?