What autofocus acceptance actually verifies
Autofocus is accepted not merely because the function exists, but against an agreed scenario and the exact specification of the installed head or optics. The name “autofocus” may mean different functions in different products; the measurable range, repeatability, commands, signals and error behaviour must come only from the documentation for the specific model and version.
What to agree
The report records the optics/head P/N, serial number, firmware and controller versions, active parameters, commands, measuring equipment, workpiece and acceptance criteria. The OEM specification defines exactly what can be verified and how to interpret statuses and alarms.
Acceptance scenario
The scenario includes agreed part positions and states, commands, expected response, actual-position recording and agreed handling of an alarm or indeterminate state. Retain logs, configuration versions, measurements and results on representative samples. Any departure from the OEM specification or an unexpected alarm is a reason to follow the manufacturer's procedure, not to select settings by guesswork.
Name the function being accepted first
“Autofocus” alone is not a criterion. Put the function claimed for the specific equipment into the record: for example, a position-change command, position feedback, a response to an agreed part state, or a notice that the command cannot be performed. Do not add assumptions about how the system determines position inside a head unless the manufacturer documents that behavior and it belongs to the agreed check.
For every step, state observable evidence: initial state, permitted command, expected status, measurement method and result record. Agree the acceptance criterion before the run and connect it to the specification of the installed revision. This separates verification of the delivered function from setting a cutting process or diagnosing a fault.
Control configuration changes
The trial result belongs to the recorded combination of head or optics, controller, firmware, active parameters, program and sample. Replacing one element does not necessarily mean the function has failed, but it does mean that the earlier protocol cannot be transferred automatically. Retain identifiers and versions with the measurements so the next check begins from a known point.
The record should also state what was not checked: an unagreed material, another geometry, a mode outside the documentation, or a scenario requiring OEM service. If an unexpected status or alarm occurs, record conditions and move to the manufacturer procedure. Do not turn an acceptance trial into independent repair, hidden-parameter changes or a bypass of protections.
Connect focus to the part result without mixing tasks
Focus position affects irradiance and cut form; TRUMPF also identifies power, focus, speed, gas pressure and piercing strategy as interrelated quality parameters. This does not mean autofocus acceptance should independently optimise all of them. Its narrower task is to confirm that the agreed head or optics function performs its documented action in the recorded configuration. Part quality is contextual evidence in the scenario, not proof of universal accuracy for any autofocus.
For example, where a system has a program-controlled focus-position change for material and thickness, the protocol may verify the agreed command, status, measurement and result on a representative sample. It must not become selection of unknown values or a claim that the same response applies to another head, firmware or geometry. Model-dependent facts come from its OEM documentation.
| Step | What is recorded |
|---|---|
| Initial state | P/N, serial number, software revisions, active configuration and sample |
| Scenario start | Agreed command, trigger condition and expected status |
| Observation | Permitted measurement method, actual record and control part |
| Assessment | Acceptance criterion, responsible person and conclusion boundary |
| Deviation | Time, logs, system state and OEM escalation route |
Example: accept a scenario, not a word in a specification
Suppose a commercial specification says “autofocus,” while the process engineer needs a predictable position change for an agreed part range. Before the trial, parties agree the sample, the documented function name, permitted commands, observation method and criterion. After the run, they retain versions, actual response and control-part result. If the command returns another status or an alarm appears, the result is a recorded deviation and procedural handoff, not an attempt to force the function with settings.
This scenario gives the buyer verifiable acceptance and the supplier a clear boundary. It promises neither quality for every thickness nor undocumented failure behavior, and does not replace laser safety. Changing the head, controller, firmware or important program part makes the scenario a new context for review.
Do not call height sensing proof of autofocus
Related functions can have different purposes in different systems. Focus positioning describes how optics set or change the focal-point position. Control of distance between nozzle and surface may be a separate head function, while a sheet sensor or collision-protection mechanism may be another. TRUMPF describes FocusLine as program-controlled setting of focus position by material and thickness, and ControlLine as maintaining distance between nozzle and surface. These examples show why the function description for the particular machine must be read; they do not transfer names or behavior to other equipment.
Separate the questions in the protocol: which positioning command is accepted, which signal or position is observed, and whether a distinct height-control loop is in scope. If a supplier advertises “autofocus” but the documented function only concerns nozzle height, this is not a minor terminology issue. Clarify the measurable delivery before the run, or record that the function is outside acceptance. A commercial name then cannot become an unverified technical promise.
Make the result repeatable for both parties
One successful run is insufficient when acceptance must confirm an agreed function for production use. Before testing, record the agreed repeats, initial state, sample, controller and firmware versions, active configuration, command sequence, log-retention method and assessment rule. This sets no universal repeat count: the contract, specification and actual task risk determine it. What matters is that equal conditions are reproducible and every participant knows what counts as evidence.
After each run, retain a reference to the record: sample identifier, time, revisions, actual status, measurement, part result and decision “conforms / clarification required.” Do not overwrite an unsuccessful run with a new configuration without a trace: the difference between revisions can explain why the outcome changed. Where a deviation occurs, the protocol should give the manufacturer facts, not interpret them as a diagnosis or permission to intervene.
Before closing the protocol, confirm that both parties can access every agreed record and that each open question has an owner and next step. This makes acceptance usable for later review rather than a one-time demonstration.
In the conclusion, cite the exact protocol revision so the decision remains connected to its evidence.
Scope limitations
This text does not establish a universal range, repeatability, test method or failure behaviour. It does not replace the OEM manual or guarantee process quality.
Discuss your production task
Prepare the head or optics P/N, controller and firmware versions, agreed function, sample, criteria and available OEM documentation. This supports a verifiable scenario without invented universal limits.
Discuss your task with L-SEL