Инспекция качества - очень большая и емкая область промышленной автоматизации. Системы, способные контролировать качество необходимы во многих производствах, ибо ситуация с изготовлением тонн дорогостоящей продукции и списанием ее на брак может за раз подкосить производство, а по затратам значительно превысить стоимость современной инспекции качества.В статье я хочу поделиться своим кейсом в контроле качества - разработке типографской системы контроля качества печати с помощью линейной камеры для ну оооочень длинных материалов.

Задача

Контролировать нанесение маркировки на типографии.

У большинства представление о типографии - это там, где книги печатают, ну еще визитки, кружки... Будучи студентом я в таких чертежи печатал)

Что же меня ждало в действительности - так это тяжелые роли со стикерами, картонной упаковкой, алюминиевой фольгой и огромные печатные машины, мотающие ее со скоростями до 300 метров в минуту. Глазом даже не видно что идет печать - скорость насколько большая, что все смазывается, увидеть печать помогают только стробоскопы.

Контроль маркировки заключался в верификации кода DataMatrix, о котором я уже писал ранее:   Верификация DataMatrix Чес...  @Хабр

Фотографии типичной типографии, производящей упаковку:

Роли с крышечками для йогуртов (платинкой) (Ист.: invest-tula.com)
Роли с крышечками для йогуртов (платинкой) (Ист.: invest-tula.com)
Печатная машина (Ист.: milkpack.ru)
Печатная машина (Ист.: milkpack.ru)

Вводные данные:

13 ручьев (линий печати вдоль полотна)

120-150 м/мин - средняя скорость печати

Расположение кодов - меняется в зависимости от дизайна (вряд, в шашку и т.д.)

360 мм - ширина полотна

10*10 мм - размер кода маркировки (20х20 точек)

Аналитика

Типовые решения

На рынке подобные задачи уверенно решали подходом "в лоб" - на каждый код - своя камера, с которой ПО уже напрямую оценивает нанесение кода.

Такое решение хорошо своей простотой. Но минусов у него кратно больше, а именно:

  1. На типографии печатали до 13 ручьев - а это аж 13 камер в ряд! Что и накладно и сложно в настройке.

  2. Необходимость Ручного перемещения камер по рядам с кодами (ручьям)

  3. Калибровка. По задаче мы должны сделать средство измерения, а значит его надо будет юстировать и калибровать. Откалибровать 13 камер можно, хоть и трудно. Но влияние оператора может в какой-то момент сбить настройку объектива и "начинай сначала: Билеты, завод, калибруй"

Выбранное решение

Мой опыт работы с линейными камерами подсказал, что они отлично подойдут для данной задачи. Одна камера сможет снимать материал во всю ширину, а далее дело за ПО - находи маркировку и проверяй ее на качество.

Что такое линейная камера и как она работает:

У линейной камеры длинный и узкий сенсор разрешением 2 х 4096 пикс. В высоту она снимает всего 2 пикс. НО она их может накапливать на встроенном FPGA и выдавать привычным прямоугольным кадром, поэтому обработка изображения с нее ничем не отличается от привычной матричной камеры.

Как одна линейная камера заменит несколько матричных (обычных) (  https://www.cameraiq.ru/faq/kak-rabotaet-i-gde-primeniaetsia-lineinaia-kamera/)
Как одна линейная камера заменит несколько матричных (обычных) (  https://www.cameraiq.ru/faq/kak-rabotaet-i-gde-primeniaetsia-lineinaia-kamera/)

Расчёты

Перед разработкой промышленного оборудования необходимо все просчитать и убедиться, что мы сможем. Этого также хотел от нас и заказчик.

Что мы считали:

  1. Требуемое разрешение на код маркировки. Для оценки качества маркировки нужно разрешение на модуль кода не менее 4х пикселей. Модуль у нас 0,5 мм.

    Итог: Разрешение на поверхности материала с кодом должно быть 8 пикс/мм. Доступная нам камера имела сенсор 4096 пикс, с разрешением 8 пикс/мм снимет 512 мм, что более чем достаточно (ширина рулона по ТЗ = 360 мм).

  2. Скорость камеры. По даташиту наша камера снимает 24 кГц или 24 000 линий (пикселей по вертикали) в сек. Переводим в скорость: 24 000 / 8 = 3 м/сек или 180 м/мин. Чего тоже достаточно (скорость печатной машины до 150 м/мин)

  3. Оптика. Тут все достаточно просто, общаемся с поставщиком оборудования, нам все подбирают под габариты задачи. Имхо - у них опыта большое.

  4. Свет. Аналогично, как и с оптикой. Свет для технического зрения вообще штука сложная, а в случае линейной камеры к нему еще и много требований: Нулевое мерцание, равномерная засветка, компактность, долговечность.

  5. Энкодер. Самый главный датчик во всей системе. Он позволяет синхронизировать съемку камеры и материала. Таким образом печатают на 60 м/мин - камера присылает кадры реже, так как медленнее снимает ее строка пикселей (реже приходит "тригер") К нему требования 3: Надежность, разрешение более 8 имп/мм (из п.1) и подходящее напряжение.

  6. Скорость распознавания. Максимальная нагрузка в кодах в минуту: 13 000 кодов в минуту.

  7. Железо. Не мелочились - взяли сразу 2х процессорный сервер с 64 ГБ ОЗУ и сетевыми картами от Intel. Бюджет позволяет, а обычных ПК хватает на год работы под такой нагрузкой.

Собираем прототип

В лаборатории из алюминиевого профиля создаем простую раму, размещаем оборудование, подключаем перемотчик этикеток. И закидываем сразу ленту с огромным количеством этикеток.

Наш первый лабораторный стенд.
Наш первый лабораторный стенд.

А теперь начинается самое интересное - Распознавание и оптимизация.

ПО начинали писать на C#, так как под рукой был хороший пример из библиотеки MVTec Halcon, которую мы используем для распознавания.

Имеем: Бесконечно прилетающие друг за другом кадры. Мы подобрали для себя их высоту в 240 пикс, тем самым на максимальной скорости в наше ПО прилетает 100 кадров в секунду (или 1 ГБит/с снимков) Создаем для них буфер и наслаждаемся мерцающими картинками с кодами.

Далее подключается распознавание маркировки. В используемой нами библиотеке уже есть различные ухищрения по оптимизации скорости распознавания. Но лучшее, что удалось из них выжать - это распознавание 100 кодов/с (6000 К/мин). Достаточно много для обычных задач, но мало для нашей задачи.

Первый интерфейс нашего прототипа ПО. Обозвали VeriTyps (verification on typography)
Первый интерфейс нашего прототипа ПО. Обозвали VeriTyps (verification on typography)

Что внедрили для оптимизации:

  1. Обучение по ручью. Коды занимают от 5 до 30% всей поверхности материала. Соответственно - удаляем не интересные области (используем ROI) программно. Это значительно облегчило кадр + появилась возможность бит распознавание на потоки, чем естественно мы воспользовались

  2. Используем все возможности библиотеки по оптимизации. Задаем очень точно все параметры распознавания кодов (коих в ней 20+). Естественно выносим их во внешний конфиг файл - мало ли что надо подкрутить.

  3. Дробление на потоки. Раз уж мы порезали снимок на ручьи - то идем дальше. Режем поток распознавания и цепляем новый поток к каждому ручью. Благо обработкой всего действа занимается сервер на 20 ядер, он с относительной легкостью вытягивает такое количество потоков. Дробление на потоки реализовали через "конвейеры" - заранее созданные экземпляры классов распознавания, в которые отправлялись уже нарезанные на ручьи коды.

  4. Не забываем про буферы. Так как система не реального времени, и даже не мягкого реального - любой процесс может подвиснуть на доли секунды и все сломать. ОЗУ на сервере с запасом, смело делаем буферы на прием кадров в 1000 кадров и вешаем его отдельным потоком. Синхронизация всего чуда - стала для нас отдельным квестом, но справились и работает безупречно.

    Итого: на выходе имеем серверное приложение, готовое к нагрузкам до 140 000 кодов/мин. Что полностью закрывает ТЗ клиента. Данные о кодах отправляются по TCP, а работает оно полностью в автоматическом режиме с двух кнопок на панели оператора.

    Тестирование на датасете (имитация скорости печати в 60 км/час)
    Тестирование на датасете (имитация скорости печати в 60 км/час)

Боевое крещение

Заказываем красивый корпус. Все жестко крепим, так как вибрации очень серьезные. И едем на типографию тестироваться на реальную печатную машину

Внешний вид нашего комплекса типографской верификации.
Внешний вид нашего комплекса типографской верификации.

Итог: С помощью линейной камеры получилось создать решение, которое оказалось значительно надежнее и проще в эксплуатации. Да, с ПО под нее пришлось "повозиться" - но в этом даже есть и плюс - 99% редких проблем это программные, а решать их из офиса/коворкинга куда приятнее, чем на производстве.

Спасибо, что дочитали до конца! Желаю успехов в ваших разработках и буду рад, если данный материал оказался вам полезным. По вопросам можете писать мне в ЛС.

Комментарии (12)


  1. Genapoliss
    06.09.2022 19:12

    А как отбраковываете нераспознанный код?


    1. avsolovyev Автор
      06.09.2022 19:17

      Пока есть два подхода: по дизайну (с поиском шаблона, работает в паре с оценкой качества самой печати) и второй - проверка чередования кодов. Система запоминает расстояние между кодами и когда оно больше обычного - выдает ошибку в отчёт оператору на HMI.


      1. Genapoliss
        06.09.2022 19:26

        А как это реализовано механически? Или типография отгружает в составе бобины и коды с грейдом D и F, а заказчик разбирается с ними уже у себя? И еще вопрос по производительности: на высокой скорости оценка грейда начинает сыпаться? На скриншоте огромный процент брака: D - 8612шт., F - 59141. Получается более 95% отбраковки по грейду.


        1. avsolovyev Автор
          06.09.2022 19:55

          В основном вырезаются участки брака вручную оператором или автоматически навысечках по метражу материала с привязкой к коду. Чаще первое...

          В случае скриншота - там коды действительно D и F, специально в лаборатории портили их чтобы корректно отлавливать возможный брак


  1. Dogel
    06.09.2022 19:17

    День добрый! >Насчёт рынка: 1 код =1 камера, Вы, конечно, погорячились. Скажите, а рассматривали готовые программные продукты от Хикробота или от Delta Electronics для чтения кодов? По Дельте могу сказать, что на очень скромном железе (Corei5 8 Гб ) выдаёт 1-2 мс на распознавание кода. Хик ещё в бою не тестировал, но потенциально - даже быстрее и требует меньше пикселей на 1 точку кода.


    1. avsolovyev Автор
      06.09.2022 19:23

      Неоднократно видел лично системы на 13-16 камер))

      Дельту тестировали, но ее надо каждый раз настраивать + с оценкой качества было 5-6 СС на код, может конечно улучшили... А по ТЗ нужна "Зелёная и красная кнопки" и ничего более из интерфейса у оператора быть не должно.

      Меньше пикселей на точку требовать просто не возможно, есть ГОСТ 15415, которому система долгая соответствовать. А в нем прописаны ограничения на свет, разрешение... Иначе грейды будут попугаям


      1. Dogel
        07.09.2022 16:07

        значит кого то очень хороший (нет) продавец. )

        ГОСТ говорит о том что надо аж 10 пикселей на 1 модуль. С примечанием о том, что можно меньше, если поворот не вносит искажений. Если продукт выдаёт грейд кода стабильно то пусть хоть 2 пикселя на модуль.


        1. avsolovyev Автор
          07.09.2022 16:50

          Евгений, тогда давайте протестируем, контакты те же - 79991130512@ya.ru


  1. DSRussell
    07.09.2022 08:46

    Как контролируются дубликаты кодов?


    1. avsolovyev Автор
      07.09.2022 08:49

      Достаточно просто - в с# есть список, в который добавляются данные кода. И каждый новый код ищется в списке, если есть - значит дубль, если новый - просто добавляется в список.


      1. DSRussell
        07.09.2022 09:41

        1)На этапе считывания камерой, каждый считанный код сверяется со списком?

        2)Что происходит когда под камерой проезжают дубликаты кодов? Происходит отбраковка, по типу как было описано вами выше ?


        1. avsolovyev Автор
          07.09.2022 09:46

          Да, каждый код сверяется.

          2 - дубликат это критическая ошибка, зачастую из-за ошибки задания на печать принтеру. Поэтому останавливается машина и выдаётся предупреждение оператору. Он уже принимает решения об отбраковке. Зачастую так, но бывают и исключения, все от заказчика зависит