Мои коллеги производят принтеры для промышленной маркировки и собирают на базе них комплексы для промышленной маркировки, в пару к каждому принтеру ставим смарт-камеру Hikrobot ID3000 для верификации кодов DataMatrix. Такое решение позволяет проверять корректность печати кодов, но не закрывало вопросы по его положению, качеству, центрированию — поэтому, операторам приходилось вручную подстраивать положение печати, контролировать насыщенность и следить за дрейфом позиции кода на материале. Все это портило пользовательский опыт и усложняло работу оператора, увеличивало количество брака. Нужно было сделать программную обратную связь для ПО L2. Вместо замены оборудования я пошёл другим путём — написали собственную обвязку на Python, используя SDK смарт-камеры и OpenCV. Теперь камера не просто читает коды, а помогает принтеру печатать идеально. Рассказываю, как подружил C-библиотеку Hikrobot IDMVS SDK с Python, искал белую подложку на жёлтом фоне и научил систему корректировать печать в реальном времени.

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

В начале было слово — Обязательная маркировка строительных материалов в упаковке. И это слово значительно взбудоражило рынок промышленной маркировки. Ведь если до этого маркировка затрагивала зачастую небольшие и легкие товары (исключение, разве что, томографы) — и достаточно было стикеров, то мешки цемента - это уже пыльно, тяжело, и как правило паллетами. У нашего клиента (типография по производству мешков для строительных смесей) была очень непростая задача — нанести одинаковые коды маркировки на мешки в разных местах. Это было необходимо для удобной работы с паллетами уже готовой продукции + дублирование маркировки защищает её от повреждения одного или нескольких кодов при транспортировке.

Однако мешок строительной смеси только снаружи выглядит как простой бумажный пакет, на деле же он состоит из нескольких элементов, которые производятся отдельно. А далее, они склеиваются в единую заготовку на типографии и передаются на завод для наполнения. Поэтому, нам пришлось решить задачи по печати одинаковых кодов сначала для нанесения кода на "тело" мешка (трубку), а потом создать системы ремаркировки — которые дублируют код с тела мешка — наносят его на покровные листы.

Введение: Зачем камере дополнительная обработка, если она и так «смарт»?

Камеры необходимы для печати маркировки, это не только требование оператора маркировки, но и защита от брака (печати плохого грейда, непропечатки, дублей продукции). Печать происходит на огромных скоростях, человеческий глаз не видит что печатает принтер, да и ДМ код распознавать глазом пока не получается. Осложняется всё геометрией печати — ведь печать DataMatrix кода идёт в разных местах, асинхронно, а это значит что только камеры могут сказать всё верно ли мы печатаем или нет. Без технического зрения здесь никак, и нам с ним помогает именно смарт-камера.

Обычно используем модели Hikrobot ID3000 — это автономные устройства со встроенным процессором, подсветкой и ПО, которые умеют находить и декодировать DataMatrix, проверять качество печати по стандартам и отдавать результаты по TCP. Далее ПО L2 (единое ПО управления печатью, проверкой, отбраковкой, получением и отправкой кодов) получает данные от камер по TCP в текстовом формате (время, номер кадра, данные о коде и его оценка), обрабатывает их и сверяется с тем, что ушло в принтер. Это позволяет проследить каждый код, однако не контролирует его расположение на материале.

Как это работает в базовой комплектации системы нанесения:

• Материал с полем для кода подъезжает к принтеру, печатается код.

• Через несколько миллиметров материал подъезжает к камере, она его фотографирует.

• Камера возвращает ответ: «код прочитан, качество A» или «брак».

• Управляющее ПО принимает решение: пропустить или отбраковать, отправляя соответствующую команду на ПЛК.

Всё красиво. Но от клиентов постоянно приходили запросы на дополнение функционала, в частности: «А можно сделать, чтобы оно ещё и принтером рулило?» Причём рулило в нашем случае действительно управляло движением.

Вот что именно хотели от нас клиенты:

• Чтобы принтер сам попадал кодом в белое поле на упаковке, а оператор не крутил отступы печати каждые 15 минут, когда материал съезжал или растягивался.

• Чтобы система отслеживала дрейф позиции (когда код уезжает влево/вправо) и либо корректировала шаблон печати (так как мы разработчики принтера — наша прошивка принтера позволяет нам менять шаблон печати "в полёте", не обращаясь к механике - просто двигать код в рамках печатной головки, да это не более чем 1 см но этого достаточно, а главное код всегда квадратный), либо смещала принтер с помощью шагового двигателя.

• Чтобы контролировалась насыщенность и, если падает, система подавала сигнал оператору (для прокапывания печатной головки, смена профиля капли или контроля чернил)

• Для систем, которые печатают два и более одинаковых кодов — проверять что коды действительно синхронизированы и находятся на одном изделие, наглядно показывая это оператору.

• Для систем дублирования (ремаркировки) кодов — проверять их последовательность, убедившись чтобы каждый код корректно размещался на соответствующем мешке при процессе склейки.

Заводской функционал ID3000 этого не умеет. Можно было купить более дорогую камеру (у Hikrobot есть старшие модели с расширенными функциями), но:

1. Это деньги и замена оборудования на линиях.

2. Даже в дорогих моделях логика фиксирована — не допишешь свой алгоритм под конкретного заказчика.

Значит, будем делать из смарт камеры — полноценный комплекс технического зрения. Благо для смарт-камеры есть SDK.

Часть 1. Смарт-камера Hikrobot ID3000: плюсы, минусы и неочевидные возможности

Если есть интерес к камере — вывел в спойлер её основные характеристики, плюсы и минусы.

Коротко о железе

Hikrobot ID3000 — это серия промышленных смарт-камер для кодового чтения. У них есть:

• Встроенный процессор (ARM + FPGA)

• Монохромный сенсор (для проверки качества подходит лучше всего именно он)

• Регулируемая подсветка (красная/белая/ИК) — для наших задач нужна белая, но об этом позже

• Оптика с автофокусом на фиксированное фокусное расстояние (надо подбирать камеру по рабочему расстоянию)

• Ethernet, цифровые входы/выходы, последовательный порт

Плюсы:

• Автономность. Камера работает как самостоятельное устройство. Настроил — и она гоняет коды годами, отдавая результаты по Modbus/TCP или обычным сокетам, управляя IO выходами.

• Надёжность. Промышленное исполнение, работа от 24V, защита от пыли/влаги.

• Скорость. До 10 кодов в секунду на проверку — что для большинства случаев достаточно.

• Наличие SDK. И вот тут самое интересное. Казалось бы, зачем SDK для автономной камеры? Но Hikrobot даёт разработчикам доступ к низкоуровневой работе: можно получать изображения, управлять подсветкой, читать результаты проверки в сыром виде. Однако, никакой обработки и алгоритмов в SDK нет.

Минусы (которые мы обнаружили в процессе):

• Закрытая логика. То, что камера делает «из коробки», жёстко задано прошивкой.

• Прошивки. Не могу не сказать об этом — они не доступны публично, однако от них зависит получите ли вы желаемый функционал или нет (например, у некоторых прошивок нет проверки на стандарт GS1 - а он нужен для "честного знака").

• Нет Python API. SDK идёт на C/C++ и C#.

• Красная подсветка. Она должна была быть самой яркой и была в наличии. Но, как выяснилось, не со всеми цветами дизайна она дружит. Об этом — в рубрике «Что пошло не так».

Часть 2. Архитектура: Где мы будем обрабатывать картинку?

Для начала немного расскажу из чего у нас состоит комплекс по нанесению маркировки. У нас каждый комплекс печати состоит из:

• Принтера (печатающая головка, СНПЧ, плата управления и так далее)

• Смарт-камеры (той самой Hikrobot ID3000)

• Датчика продукта (фотодатчик метки на материале)

• Энкодера (для синхронизации с конвейером)

• Сенсорного ПК оператора (промышленный моноблок, часто средней производительности, на Windows или Linux)

• Свитча, блока питания, ПЛК, установленных в шкафу,

• Внешний сервер (локальный или облачный) для получения кодов и отправки результатов верификации маркировки

Пример оборудования для печати на линии размотки (производство основной части мешка).

Важный нюанс: интернет на линии обычно есть, но он недостаточно быстрый. Система работает локально, общаясь разве что с сервером цеха или облачным для получения кодов маркировки. Всё управление и обработка — на ПК оператора.

Задача: получить с камеры изображение, обработать его на промышленном ПК, вычислить смещение и отправить команду принтеру на коррекцию.

Часть 3. Строим свой API для камеры

Шаг 1. Изучаем SDK

SDK от Hikrobot для ID3000 называется IDMVS (Industrial Code Reader SDK). В нём есть:

• Библиотеки для Windows (C#, C++) и Linux (C++).

• Примеры на C++ и C#.

• Документация (на английском, но читаемо).

• ПО для первичной настройки и просмотра камер

Своё родное API под Python отсутствует. Варианты:

• Обернуть C++ библиотеку через Cython или pybind11.

• Использовать ctypes для прямого вызова функций из .dll/.so.

Выбрали ctypes. Почему?

• Меньше телодвижений для сборки.

• Работает и на Windows, и на Linux из коробки.

• Код получается прозрачным: видно, какие функции SDK вызываются и с какими параметрами.

Шаг 2. Подключаемся к камере

Типовой сценарий работы с SDK:

1. Инициализация библиотеки. Для работы с нашей камерой это MvCodeReaderCtrl.h

2. Поиск устройств в сети по серийному номеру.

3. Подключение к камере.

4. Настройка параметров захвата (в моём случае, это параметры, которые зависят от цвета бумаги — экспозиция, гейн, режим подсветки).

5. Подписка на события/получение кадров.

6. Опционально — отправка сигнала на триггер (для проверки работоспособности камер)

Пример кода поиска и загрузки нужной нам библиотек для работы с камерой

# Загрузка библиотеки MvCodeReaderSDK
def load_sdk():
    """
    Загружает библиотеку MvCodeReaderSDK, используя следующие стратегии:
    1. Переменная окружения MV_CODEREADER_SDK_PATH (полный путь к библиотеке)
    2. ctypes.util.find_library для поиска по стандартным путям
    3. Предопределённые пути для Windows и Linux
    """
    lib_name = 'MvCodeReaderSDK'
    # Проверка переменной окружения
    env_path = os.environ.get('MV_CODEREADER_SDK_PATH')
    if env_path and os.path.isfile(env_path):
        lib_path = env_path
    else:
        # Поиск библиотеки через find_library
        lib_path = ctypes.util.find_library(lib_name)
        if not lib_path:
            # Предопределённые пути
            if os.name == 'nt':
                # Windows
                possible_paths = [
                    r'C:\Program Files (x86)\IDMVSSTD\Development\Modules\MvCodeReaderSDK\SDK\win64\MvCodeReaderCtrl.dll',
                    r'C:\Program Files\IDMVSSTD\Development\Modules\MvCodeReaderSDK\SDK\win64\MvCodeReaderCtrl.dll',
                    r'C:\Program Files (x86)\Hikrobot\MvCodeReaderSDK\bin\MvCodeReaderCtrl.dll'
                ]
            else:
                # Linux
                possible_paths = [
                    '/usr/lib/libMvCodeReaderSDK.so',
                    '/usr/local/lib/libMvCodeReaderSDK.so',
                    'libMvCodeReaderSDK.so',
                ]
            for path in possible_paths:
                if os.path.isfile(path):
                    lib_path = path
                    break
            else:
                raise FileNotFoundError(
                    f"Библиотека {lib_name} не найдена. "
                    "Установите SDK или укажите путь через переменную окружения MV_CODEREADER_SDK_PATH."
                )
    # Загрузка библиотеки
    if os.name == 'nt':
        return ctypes.WinDLL(lib_path)
    else:
        return ctypes.CDLL(lib_path)

sdk = load_sdk()

Поиск устройства и подключение к нему

def enumerate_devices(self):
try:
    dev_list = MV_CODEREADER_DEVICE_INFO_LIST()
    ret = sdk.MV_CODEREADER_EnumDevices(ctypes.byref(dev_list), MV_CODEREADER_GIGE_DEVICE)
    if ret != MV_CODEREADER_OK:
        raise RuntimeError(f"Enumeration failed: {ret:#x}")
    print(f"Found {dev_list.nDeviceNum} device(s)")
    # Здесь можно вывести информацию об устройствах
    return dev_list
except:
    return []

def connect(self):
dev_list = self.enumerate_devices()
if dev_list.nDeviceNum <= self.device_index:
    raise IndexError("Device index out of range")

# Получаем указатель на выбранное устройство
device_info = dev_list.pDeviceInfo[self.device_index].contents

# Создаём handle
self.handle = ctypes.c_void_p()
ret = sdk.MV_CODEREADER_CreateHandle(ctypes.byref(self.handle), ctypes.byref(device_info))
if ret != MV_CODEREADER_OK:
    raise RuntimeError(f"CreateHandle failed: {ret:#x}")

ret = sdk.MV_CODEREADER_OpenDevice(self.handle)
if ret != MV_CODEREADER_OK:
    self.close()
    raise RuntimeError(f"OpenDevice failed: {ret:#x}")

# Определяем максимальный размер изображения для буфера (аналогично InitResource)
payload_param = MV_CODEREADER_INTVALUE_EX()
ret = sdk.MV_CODEREADER_GetIntValue(self.handle, b"PayloadSize", ctypes.byref(payload_param))
if ret == MV_CODEREADER_OK:
    self.max_image_size = payload_param.nCurValue + 4096
else:
    # Если нет PayloadSize, берём WidthMax * HeightMax
    width_param = MV_CODEREADER_INTVALUE_EX()
    height_param = MV_CODEREADER_INTVALUE_EX()
    sdk.MV_CODEREADER_GetIntValue(self.handle, b"WidthMax", ctypes.byref(width_param))
    sdk.MV_CODEREADER_GetIntValue(self.handle, b"HeightMax", ctypes.byref(height_param))
    self.max_image_size = width_param.nCurValue * height_param.nCurValue + 4096

# Выделяем буфер для изображения
self.image_buffer = (ctypes.c_ubyte * self.max_image_size)()

Шаг 3. Получаем кадр

Примечание — я опущу все описания структур для работы с данными от данного SDK. Кому будет интересно — могу прислать ссылку на Гит с кодом. Для его запуска достаточно будет установить IDMVS с офф. сайта, запустить эмулятор камеры и подключится к нему из проекта.

Ключевая функция, которую мы используем — MV_CODEREADER_GetOneFrameTimeoutEx2. Она позволяет синхронно получить один кадр с камеры.

def get_frame(self, timeout_ms=1000, include_barcodes=False):
"""
Получает один кадр и возвращает (данные, информация) или (данные, информация, штрих-коды)
при include_barcodes=True.
В случае ошибки/таймаута возвращает (None, None) или (None, None, []).
"""
p_data = ctypes.POINTER(ctypes.c_ubyte)()
info = MV_CODEREADER_IMAGE_OUT_INFO_EX2()
ret = sdk.MV_CODEREADER_GetOneFrameTimeoutEx2(self.handle, ctypes.byref(p_data), ctypes.byref(info), timeout_ms)
if ret != MV_CODEREADER_OK:
    if include_barcodes:
        return None, None, []
    else:
        return None, None
# Копируем данные в локальный буфер
ctypes.memmove(self.image_buffer, p_data, info.nFrameLen)
if include_barcodes:
    barcodes = self._parse_barcode_results(info.pstCodeListEx)
    return self.image_buffer, info, barcodes
else:
    return self.image_buffer, info

Важный нюанс: камера не гарантирует, что каждый кадр будет содержать код. Она может пропускать кадры по NoRead на большой скорости, может выдавать изображения не в реальном времени в случае проблем с сетью либо вовсе пропускать кадры. Поэтому мы контролируем номера кадров (info.nFrameNum) и проверяем, что камера действительно увидела код в этом кадре.

Второй важный нюанс: SDK камеры потребляет в работе почти 1 Гб ОЗУ (при работе двух и более камер) и значительно нагружает сеть. Очень рекомендую на камеры делать свою сетку с пропускной способностью в 1 Гбит/с.

Часть 4. Алгоритм: Как найти белую подложку и измерить смещение

Что мы имеем на входе:

• Изображение с камеры в градациях серого.

• Координаты кода DataMatrix (их камера нам отдаёт отдельно, в месте с результатом проверки кода).

• Примерное расположение подложки для кода — в центре кадра, занимает не менее 30% площади.

Задача: найти на изображении белую область, в которую должен быть вписан код. Это может быть квадрат или круг — зависит от дизайна упаковки.

Нюансы имеются, а куда же без них:

• Дизайнов под код множество (от белого поля с рамкой, до какого-нибудь мастерка-кельмы в который надо попасть кодом)

• Освещение меняется в соответствии с калибровкой на материал.

• Упаковка может быть глянцевой, давать блики (но это решается применением светофильтов).

• Цвет подложки (белый) может сливаться с фоном.

Решение: используем классические методы OpenCV, без машинного обучения, но с выносным конфигом под нужды производства.

Алгоритм:

1. Бинаризация. Превращаем серое изображение в чёрно-белое по порогу. Порог подбираем адаптивно, потому что яркость плывёт.

2. Поиск контуров. Находим все замкнутые контуры.

3. Далее алгоритм разветвляется на сценарии. Первый — это поиск подложки: Фильтрация по площади и форме. Оставляем только те, что:

   • Занимают не менее 30% кадра (по условию).

   • Имеют форму, близкую к прямоугольнику (для квадратной подложки) или кругу.

   • Близки по положению к коду маркировки (обусловимся, что оператор хоть немного попал кодом в нужное место)

   Однако есть и второй: Запоминание контура и положения кода относительно него. Он используется реже, однако позволяет "привязать" код к текущему дизайну (на момент приладки) и динамически контролировать положение кода относительно паттерна печати. Всё как на взрослых комплексах по инспекции печати, только в рамках простой задачи.

4. Поиск центра. Для каждого подходящего контура вычисляем центр масс.

5. Выбор ближайшего. Берём контур, центр которого ближе всего к центру кадра (помним, что камера смотрит в нужное место. Надеясь что оператор её настроил корректно).

Вот как это выглядит в коде (примитвно):

import cv2
import numpy as np

def find_target_area(image):
    """
    Находит белую подложку на изображении.
    Возвращает (center_x, center_y, w, h) или None
    """
    # Адаптивная бинаризация
    binary = cv2.adaptiveThreshold(
        image, 255, 
        cv2.ADAPTIVE_THRESH_GAUSSIAN_C,
        cv2.THRESH_BINARY, 11, 2
    )
    
    # Поиск контуров
    contours, _ = cv2.findContours(
        binary, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE
    )
    
    h, w = image.shape
    min_area = 0.3 * w * h  # не менее 30% кадра
    
    best_contour = None
    best_score = 0
    
    for cnt in contours:
        area = cv2.contourArea(cnt)
        if area < min_area:
            continue
            
        # Аппроксимируем контур
        peri = cv2.arcLength(cnt, True)
        approx = cv2.approxPolyDP(cnt, 0.04 * peri, True)
        
        # Проверяем, что это прямоугольник (4 вершины) или круг (много вершин)
        # Для упрощения считаем, что если вершин много, это эллипс/круг
        if len(approx) < 4:
            continue
            
        # Находим ограничивающий прямоугольник
        x, y, box_w, box_h = cv2.boundingRect(cnt)
        center_x = x + box_w//2
        center_y = y + box_h//2
        
        # Чем ближе центр к центру кадра, тем лучше
        center_dist = np.sqrt((center_x - w//2)**2 + (center_y - h//2)**2)
        score = area / (center_dist + 1)  # +1 чтобы избежать деления на 0
        
        if score > best_score:
            best_score = score
            best_contour = (center_x, center_y, box_w, box_h)
    
    return best_contour

Результат: мы получаем координаты центра подложки (X_target, Y_target).

Координаты кода (X_code, Y_code) камера отдаёт нам отдельно (или мы тоже ищем через OpenCV).

Смещение: dx = X_code - X_target, dy = Y_code - Y_target.

Часть 5. Логика принятия решений

Мы не корректируем печать по каждому срабатыванию — это приведёт к дёрганью и дребезгу, тем более если используем шаговый привод принтера, а не коррекцию шаблона принтера. Вместо этого мы используем накопление статистики.

Условия запуска анализа:

• Раз в N кодов (например, 100).

• Или раз в минуту.

• Собираем 3 последовательных кадра подряд.

Почему 3 подряд?
Бывает, что энкодер даёт сбой или продукт проскальзывает, дизайн не пропечатался и так далее. Если проверять по одному кадру, можно среагировать на случайный выброс. Три подряд стабильных измерения — уже статистика.

Что проверяем:

1. Стабильность смещения. Если dx и dy прыгают от кадра к кадру больше порога — значит проблема не в позиции печати, а в датчике продукта или энкодере. Шлём предупреждение оператору.

2. Систематическое смещение. Если среднее смещение за 3 кадра превышает порог (например, 2 мм), отправляем команду на принтер:

   • По оси Y — корректировка отступа от фотометки.

   • По оси X — смещение шаблона печати либо перемещение принтера приводом между тактами печати (у принтера есть GPIO, с которого мы берем сигнал на разрешение по перемещению, это позволяет нам перемещать ПГ в момент простоя между кодами, не деформируя печать кода).

3. Качество изображения. Если контрастность падает — возможно, заканчиваются чернила или засыхают дюзы. Тоже сигнал оператору.

Интерфейс оператора:

У нас в комплексе два монитора, второй целиком отвечает за работу с камерами. Интерфейс старался сделать минималистично-информативным под работу с сенсорным экраном. Его функции:

• Отобразить картинки с камер с возможностью приближения. На экранах камер дополнительно рисую рамки: вокруг найденной подложки и вокруг кода, прицел

• Между камерами разместил таблицу с данными проверки кодов, счётчики — это наглядно показывает синхронны ли сейчас коды, какая камера "отстаёт" — а техпроцесс подразумевает и такое.

• Вывел численные значения по текущим настройкам камеры (скорее для контроля) и счётчики брака

• Кнопки для управления положением кода и камеры относительно фотометки на материале

• Журнал событий, кнопки управления ПО, журналы с фото-архивом, CSV логом и т.д.

Часть 6. Что пошло не так: Красная подсветка и жёлтый дизайн

Под предыдущими статьями часто просили рассказать об ошибках, ну чтож… пришло их время:

У большинства наших камер Hikrobot ID3000 — красная подсветка. Это нормально для чтения DataMatrix, и даже ГОСТ одобряет: красный свет хорошо контрастирует с чёрными модулями ДМ кода на белой подложке. Однако в алгоритме по центровке ищем белую подложку! И тут физика сыграла с нами злую шутку, подбросив желтый мешок.

Цветовая палитра и подсветка:

• Красный свет максимально отражается от объектов красного цвета и минимально — от зелёных/синих.

• Жёлтый цвет в RGB-модели — это комбинация красного и зелёного. Соответственно при зеленой или красной подсветке он становится неразличимым с белым.

Получается: если дизайн упаковки имеет жёлтый фон, а подложка под код — белая, то при красной подсветке:

• Белый отражает все длины волн (и красный в том числе).

• Жёлтый тоже отражает красную компоненту.

  

Итог: контраст между белой подложкой и жёлтым фоном резко падает. На изображении они сливаются, границы не видны. OpenCV не может найти контур.

Решение: В данном случае только аппаратное: пришлось дооснащать камеры дополнительной белой подсветкой.

Итоги:

1. Смарт-камера стала умнее. Мы добавили ей функционал, которого нет в заводской прошивке, и теперь она не просто читает коды, а помогает принтеру печатать в нужном месте и более качественно.

2. Экономия на оборудовании. Не пришлось менять камеры на более дорогие модели. Всё сделано софтом.

3. Гибкость. Есть конфигурационный файл, с помощью которого можно подстроить работу системы, а написанный на Python код можно дорабатывать под конкретного заказчика за часы.

4. Надёжность. Система работает на средних промышленных ПК, не требует интернета и справляется с тысячами проверок в смену.

5. Полезность. С операторов ушла нагрузка по контролю за положением кодов, производство снизило количество брака, время на запуск новой партии снизилось (так как ПО попадает кодом в квадрат быстрее человека).

6. Реальные грабли. Красная подсветка и жёлтый дизайн — теперь мы знаем об этой проблеме и учитываем её на этапе проектирования.

P.S. Если у вас есть опыт доработки промышленных камер под нестандартные задачи или вы сталкивались с похожими проблемами — делитесь в комментариях. Интересно обсудить, кто и как решал подобные задачи.