Приймання автофокусу: перевірка погодженого сценарію за специфікацією конкретної оптики ART-056

Що саме перевіряють під час приймання автофокусу

Автофокус приймають не за самим фактом наявності функції, а за погодженим сценарієм і точною специфікацією встановленої головки або оптики. Назва «автофокус» може означати різні функції в різних продуктах; вимірюваний діапазон, повторюваність, команди, сигнали й поведінка при помилці беруть лише з документації конкретної моделі та версії.

Що узгодити

У протоколі фіксують P/N оптики/головки, серійний номер, версію firmware та контролера, активні параметри, команди, вимірювальне обладнання, заготовку й критерії прийняття. OEM-специфікація визначає, що саме можна перевіряти та як інтерпретувати статуси й аварії.

Сценарій приймання

Сценарій включає погоджені положення й стани деталі, команди, очікувану реакцію, реєстрацію фактичного положення та узгоджене поводження для аварійного або невизначеного стану. Зберігають журнали, версії конфігурації, вимірювання та результати на представницьких зразках. Будь-який вихід за межі OEM-специфікації або непередбачена аварія є приводом діяти за процедурою виробника, а не підбирати налаштування навмання.

Спочатку назвіть функцію, яку приймають

Термін «автофокус» сам по собі не є критерієм. До протоколу внесіть функцію, яку заявлено для конкретного обладнання: наприклад, команду зміни положення, контроль положення, реакцію на погоджений стан деталі або повідомлення про неможливість виконання команди. Не додавайте до сценарію здогадки про те, як система визначає положення всередині головки, якщо це не описано виробником і не належить до погодженої перевірки.

Для кожного кроку сформулюйте спостережуваний доказ: початковий стан, дозволена команда, очікуваний статус, спосіб вимірювання та запис результату. Критерій приймання має бути погоджений до запуску й пов’язаний зі специфікацією саме встановленої ревізії. Це відокремлює перевірку поставленої функції від налаштування процесу різання або пошуку причин несправності.

Контролюйте зміни конфігурації

Результат проби належить зафіксованій комбінації головки або оптики, контролера, firmware, активних параметрів, програми й зразка. Заміна одного елемента не обов’язково означає відмову функції, але означає, що старий протокол не можна автоматично переносити. Збережіть ідентифікатори та версії разом з вимірюваннями, щоб наступна перевірка починалася з відомої точки.

У протоколі корисно окремо вказати, що не перевірялось: непогоджений матеріал, інша геометрія, режим поза документацією або сценарій, який потребує OEM-сервісу. Якщо виникає неочікуваний статус чи аварія, зафіксуйте умови й перейдіть до процедури виробника. Не перетворюйте приймальну пробу на самостійний ремонт, зміну прихованих параметрів чи обхід захистів.

Зв’яжіть фокус із результатом деталі, але не змішуйте задачі

Позиція фокуса впливає на густину випромінювання і форму різу; TRUMPF також прямо називає потужність, фокус, швидкість, тиск газу та стратегію пробивання взаємопов’язаними параметрами якості. Звідси не випливає, що приймання автофокусу має самостійно оптимізувати всі ці параметри. Його завдання вужче: підтвердити, що погоджена функція головки або оптики виконує задокументовану дію в зафіксованій конфігурації. Якість деталі слугує контекстним результатом сценарію, але не доказом універсальної точності будь-якого автофокуса.

Наприклад, якщо система має програмно керовану зміну положення фокуса для матеріалу й товщини, протокол може перевіряти погоджену команду, статус, вимірювання та результат на представницькому зразку. Він не має перетворюватися на підбір невідомих значень або твердження, що та сама реакція буде для іншої головки, прошивки чи геометрії. Усе, що залежить від конкретної моделі, беруть з її OEM-документації.

Приклад: приймайте сценарій, а не слово в специфікації

Уявімо, що в комерційній специфікації є «autofocus», а технологу потрібна передбачувана зміна положення під час узгодженої номенклатури. До проби сторони погоджують конкретний зразок, назву функції з документації, допустимі команди, спосіб спостереження й критерій. Після запуску зберігають версії, фактичну реакцію та результат контрольної деталі. Якщо команда повертає інший статус або з’являється аварія, результатом є зафіксоване відхилення та передача за процедурою, не спроба «дотиснути» функцію налаштуваннями.

Такий сценарій дає покупцеві перевірюване приймання, а постачальнику — чітко описану межу перевірки. Він не обіцяє якість для усіх товщин, не замінює лазерну безпеку й не доводить поведінку при відмові, якої немає в документації. Після зміни головки, контролера, firmware або важливої частини програми сценарій переглядають як новий контекст.

Не називайте вимірювання висоти доказом автофокуса

У різних системах суміжні функції можуть мати різні призначення. Позиціонування фокуса описує, як оптика встановлює або змінює положення фокусної точки. Контроль відстані між соплом і поверхнею може бути окремою функцією головки, а датчик листа чи механізм захисту від зіткнення — ще іншою. TRUMPF, наприклад, описує FocusLine як програмно кероване встановлення положення фокуса залежно від матеріалу й товщини, а ControlLine — як підтримання відстані між соплом і поверхнею. Ці приклади пояснюють потребу читати саме опис функції конкретної машини; вони не переносять назви або поведінку на інше обладнання.

У протоколі розділіть запитання: яку команду позиціонування приймають, який сигнал або положення спостерігають, і чи є окремий погоджений контур контролю висоти. Якщо постачальник рекламує «autofocus», а документована функція насправді стосується лише висоти сопла, це не дрібниця в термінах. Потрібно або уточнити вимірювану поставку до запуску, або зафіксувати, що ця функція не входить до приймання. Так комерційна назва не стає неперевіреною технічною обіцянкою.

Зробіть результат повторюваним для обох сторін

Один вдалий запуск не достатній, якщо приймання має підтвердити погоджену функцію для виробничого застосування. До тесту запишіть кількість погоджених повторів, початковий стан, зразок, версії контролера й firmware, активну конфігурацію, послідовність команд, спосіб зберігання журналів і правило оцінки. Це не встановлює універсальну кількість повторів: її визначають контракт, специфікація та реальний ризик задачі. Важливо, щоб однакові умови були відтворюваними і щоб усі учасники знали, що саме вважатиметься доказом.

Після кожного запуску зберігайте посилання на запис: ідентифікатор зразка, час, ревізії, фактичний статус, вимірювання, результат деталі та рішення «відповідає / потрібне уточнення». Не перезаписуйте невдалий запуск новою конфігурацією без сліду: саме відмінність між ревізіями може пояснити, чому результат змінився. Якщо з’являється відхилення, протокол повинен передати виробнику факти, а не інтерпретувати їх як діагноз або дозвіл на втручання.

Перед закриттям протоколу звірте, що всі погоджені записи доступні обом сторонам і що відкриті питання мають власника та наступний крок. Це робить приймання придатним для подальшої ревізії, а не одноразовою демонстрацією.

У підсумку посилайтеся на конкретну ревізію протоколу, щоб рішення не відокремлювалося від доказів.

Межі матеріалу

Текст не встановлює універсальний діапазон, повторюваність, метод тесту або поведінку при відмові. Він не замінює інструкцію OEM і не дає гарантії якості процесу.

Обговорити виробниче завдання