В данной публикации я расскажу Вам о том, как, используя платформу 1С: Предприятие, мы разработали рабочее место для управления промышленным принтером на производстве газобетонных блоков, подключили к нему светодиодное табло, сканер штрихкодов, написали обмен данными с MES системой и 1С: УПП и подключили оповещения по почте! Итак, приступим!
Начало. 2019 год
Да, да, Вы не ослышались все правильно прочитали! Разработка велась в
2019-2020 годы, основная часть работ была выполнена в первые четыре месяца, а рассказать об этой истории решил только сейчас.
Началось все со старта проекта по внедрению маркировки продукции на производстве газобетонных блоков в сибирской глубинке. Цель маркировки – улучшение качества продукции на основании обратной связи от покупателей с точной идентификацией отгруженной продукции. Подразумевалось, что с помощью штрихкода, нанесенного на продукцию, можно однозначно определить дату выпуска, смену, а также найти использованную в тот момент рецептуру и так далее. Так же, как бонус, маркировка была призвана упростить процедуру учета и инвентаризации продукции. Руководителем и инициатором проекта был человек, отлично разбирающийся в железе (далее по тексту - Инженер).
К слову, вопрос по маркировке продукции поднимался не раз, и на производстве уже использовалась маркировка продукции с помощью принтера этикеток. С этой задачей частично справлялись следующим образом: в начале смены печатали этикетки на принтере этикеток (заранее на всю смену, с хорошим запасом) и клеили их на паллеты с готовой продукцией. Основная проблема использования самоклеящихся этикеток была в том, что они, мягко говоря, не очень хорошо приклеивались к свежевыпеченному газобетонному блоку. Приходилось клеить ее на специальную упаковочную пленку, закрепленную сверху паллеты (т.н. «шапка» или stretch-hood), либо на стреппинг-ленты. К сожалению, этикетки периодически отлетали, да и «шапка» была не на всей продукции.
Поиски Инженера по решению данной проблемы остановились на немецком промышленном каплеструйном принтере серии EBS-1500 (далее по тексту – маркиратор или принтер) производимым компанией EBS Ink-Jet Systems GmbH. Принтер предназначен для использования на конвейере и может печатать специальными чернилами на металле, дереве, пластике, картоне и, что немаловажно, на бетонных изделиях – в общем, очередное wunderwaffe.
В начале проекта я даже не знал, что буду в нем участвовать, но после того, как оборудование прибыло в офис, ко мне пришло легкое осознание скоропостижно надвигающихся приключений.
Проблема всех проблем
С точки зрения маркировки продукции - особенностью данного производства является то, что у нас есть план производства на смену и мы его придерживаемся знаем, какая номенклатура и в каком количестве будет выпущена в целом за смену, но не знаем, в каком порядке она будет выпущена, упакована и отправлена на склад – это зависит от многих параметров (текущая рецептура, используемое сырьё, его влажность и прочее – углубляться не буду, т.к. речь не об этом). После выезда продукции из автоклавов, марка газобетона уточняется и появляется информация о том, что в итоге выпустили.
Сам же контроллер управления EBS-1500 достаточно сложен для взаимодействия с ним неискушенному в немецких технологиях пользователем напрямую. А вот наличие поддержки русского языка несомненно радовало.
Также после сборки тестового стенда для маркиратора, его включения и печати нескольких пробных меток (штрихкод + текст) выяснилось, что, если маркиратор «думает», что метка успешно напечатана – это не всегда истина. То есть необходимо осуществлять контроль каждой напечатанной метки. Лучшим решением на тот момент было использование сканера штрихкодов, который должен был «смотреть» на проезжающие промаркированные паллеты и считывать нанесенные метки.
И вишенкой на торте стояло огромное светодиодное табло, призванное отображать информацию о текущем плане на маркировку продукции, фактические данные и текущее состояние маркиратора.
Данные требования были собраны Инженером и переданы в наш отдел. Отдел, где сидят одни 1Сники. Программисту, которому кроме типовых конфигураций 1С ничего не доводилось дорабатывать, то есть мне. Занавес.
Почему платформа 1С: Предприятие?
Ответ на данный вопрос мучает меня до сих пор. Ведь можно было выбрать любой другой инструмент для разработки, который умеет в работу с «железом». Но на тот момент были следующие доводы:
- Это быстро – что тут не говори, платформа позволяет буквально на лету «накидать» форму, кнопки, организовать хранение данных и получить MVP
- В штате не было других специалистов – вариант нанять аутсорсинг не рассматривался, т.к. нужно было дешево и быстро, а лучше – бесплатно
- Ну, со сканером штрихкодов 1С как-то же справляется =)
- Это прототип – по сути нужно было только проверить состоятельность идеи и возможность подключить все оборудование к единому рабочему месту (как же я ошибался…)
Мне было ничего не понятно, но очень интересно, и я с радостью согласился, ведь сидя на сопровождении типовых УПП, ЗУП и УАТ, для меня это был как глоток свежего воздуха!
Ничего не понятно, но очень интересно!
Итак, в качестве среды разработки – платформа 1С: Предприятие, а где будем ее запускать? Подразумевалось, что рабочее место будет максимально простым и интуитивным в использовании. Буквально должно быть две кнопки - «Старт» и «Стоп», о чем красноречиво говорило техническое задание от Инженера (на рисунке справа).
Тут как нельзя лучше подходит сенсорный экран. Поэтому качестве ПК был выбран и приобретен пыле-влагостойкий моноблок на Windows 7 с сенсорным экраном в промышленном исполнении и наличием COM порта RS-232 (именно через него как раз и планировалось «общаться» с принтером).
В качестве сканера штрихкодов изначально использовали Zebra DS3608. Это обычный проводной ручной сканер штрихкодов, но в ударопрочном корпусе. В режиме подставки он мог считывать штрихкоды без нажатия на курок, чего было достаточно.
Для того, чтобы не приходилось постоянно находиться у рабочего места с принтером, в цехе предполагалось разместить светодиодное табло, которое дублировало сменный план на маркировку продукции из местной MES системы («СУПП» - специализированное не 1Сное решение, написанное на java ребятами из Екатеринбурга специально для газобетонного производства), отображало количество фактически промаркированной продукции и дополнительную информацию, например - состояние принтера и объявления для сотрудников цеха.
В итоге общая схема интеграций и подключенного к рабочему месту управления маркировкой оборудования выглядела так:
Изначально планировалось использовать файловую базу 1С, но позже пришли к выводу, что необходимо некоторые действия (тот же обмен данными) выполнять на сервере, поэтому база плавно переместилась на клиент-сервер.
Таков путь
Итак, разработка началась и первым делом необходимо было установить контакт между 1С и маркиратором. Тут на помощь пришла библиотека MSCOMM32.OCX. С ее помощью удалось даже открыть порт с принтером! Дальше радость улетучилась, т.к. принтер мог принимать и отправлять сообщения в определенном формате и еще предстояло организовать процесс обмена этими сообщениями. Инженер любезно предоставил руководство на немецком языке описание протокола управляющих команд принтера, заботливо переведённого немцами на английский язык (со словами «На, почитай, тебе полезно будет!»).
Сами сообщения, которые принтер слушал (и отправлял обратно) по COM порту, представляли собой текстовые фреймы определенного формата:
После получения сообщения принтер отправлял ACK код (0x06) в знак того, что сообщение принято. Если мы получали сообщение от принтера, то так же необходимо было отправить ACK код обратно.
Для начала написали небольшую отладочную обработку (единственное, что осталось от обработки - фото слева), с помощью которой просто запрашивали текущий статус и получали сообщение, которое уже разбирали на кусочки согласно вышеупомянутому описанию протоколу. Параллельно с отладкой в 1С использовался простой монитор COM порта (Portmon). Рассмотрим в качестве примера одну из команд принтера - STATUS:
Ниже приведен пример разбора полученного из принтера сообщения в 1С, где в конце процедуры можно увидеть переменную fZUZATR, которая содержит уровень чернил в картридже (картридж представляет из себя специальную пластиковую бутылку с жидкими чернилами, картинка справа). Названия переменных сделал такими же, как в описании протокола, чтобы потом проще было разобраться, что происходит. Особенно позабавило, что некоторые переменные хранятся побитно, какие-то просто в десятичном виде, а некоторые в шестнадцатеричной системе.
Формирование остальных запросов происходило примерно в этом же ключе, то есть собирали в 1С строку команды в требуемом формате, отправляли ее в порт принтера, а потом ждали от него ответ и разбирали в 1С. Удалось реализовать следующие функции:
-
Получение статуса принтера (в том числе, наличие/отсутствие ошибок, уровень чернил, последняя напечатанная метка)
-
Установка параметров печати
-
Установка макета метки
-
Установка текущего штрихкода и человекочитаемого текста метки для печати
-
Запуск/Остановка печати
В принципе, этого было достаточно для оперативной работы с маркиратором.
Далее следовало получить сменный план на маркировку продукции из MES. Разработчики системы СУПП (Система управления производственным предприятием) использовали для хранения данных СУБД MS SQL, что нам было на руку, т.к. в платформе есть такой замечательный механизм как "Внешние источники данных". Получилось очень даже быстро реализовать получение текущей смены, сменного плана на маркировку и даже информационные сообщения, закрепленные в СУПП для информирования персонала завода (напоминания и объявления). 1С: УПП наоборот, забирала данные из маркиратора, поэтому для нее был создал простой web-сервис, чего было более чем достаточно.
Каких-либо проблем с подключением сканера не возникло. Не стали тащить подсистему работы со сканерами штрихкодов из БПО, просто обошлись небольшим кусочком кода (возможно, зря) с использованием внешней компоненты "1С:Сканер штрихкода". К слову, так же было упущением, проигнорировать Библиотеку стандартных подсистем от 1С - ведь большинства костылей и велосипедов можно было бы избежать. Используйте БСП в своих проектах на 1С! =)
Мальчик хочет в табло
Остался последний нерешенный вопрос - подключение китайского контроллера к 1С. Контроллер модели E63 (c Ethernet интерфейсом) производителя Huidu Technology в основном предназначался для вывода рекламы, бегущих строк на LED панелях практически любого мыслимого размера (в нашем случае было заказано и изготовлено монохромное табло с разрешением 288х128). Для вывода информации производитель предлагал использовать программу HD2018. Не совсем наш случай - нам то нужно не только вывести информацию, но и динамически обновлять её из 1С.
Инженер, через переписку с производителем контроллера (ребята из Китая), раздобыл библиотеку HDSDK.dll, но был нюанс. Библиотека не знала, что такое 1С =) Что, впрочем, не помешало нам использовать магию под названием DynamicWrapperX (ссылка на документацию). Китайская библиотека была хорошо документирована (хоть и с ошибками) и это позволило обернуть ее в DynamicWrapperX. Таким образом получился "пирог" в виде 1С - DynamicWrapperX - HDSDK - Контроллер LED панели.
После выполнения такой обертки уже можно было использовать методы самой библиотеки прямо в 1С. например, проверить, что LED панель доступна в сети:
ТаблоВключено = HDSDK.Cmd_IsCardOnline(0, IPАдрес, Null);
или например, команда обновления времени во встроенных в контроллер часах на основании времени ПК:
HDSDK.Cmd_AdjustTime(0, IPАдрес, Null);
Испытывать сразу на большой LED панели не стали (на момент разработки её еще не было в наличии), для разработки и отладки управляющего кода достаточно было одной секции 32х16. На ней выводили время, погоду с различных сервисов и даже бегущую строку с анекдотами =)
И вот, прибыла от поставщика большая LED панель (большая и тяжелая - в офис затаскивали вчетвером!). Панель 288х128 состоит из 72 панелек 32х16 и контроллером воспринимается как одна единая матрица. Прикинув макет в Excel, запрограммировали вывод информации уже из рабочего места маркиратора.
IT`S ALIVE!
Не буду томить - нарисовав минимальный интерфейс, мы запустили тестовый стенд! Естественно, использовали режим "Киоск" - он очень хорошо подошел под формат сенсорного моноблока. Как бонус - операторам меньше простора для "творчества", все всегда выведено на экране и лишних действий не сделать.
Обработку АРМа разделили на несколько страниц, между которыми можно переключаться кнопками "Назад" и "Далее". Получилось нечто вроде мастера. При запуске 1С отображался стартовый экран с инициализацией оборудования и проверки статусов подключения к внешним системам. Далее оператор переходил на следующую "страницу" (по сути это были группы с элементами формы, управление переключением между страницами сделали просто - через видимость групп), выбирал свою смену и попадал на страницу печати с долгожданными кнопками "Печать" и "Стоп". По кнопке "Завершить смену" АРМ переключался на стартовую страницу инициализации и был готов к следующей рабочей смене. На мой взгляд, получилось достаточно просто.
Даже слишком просто. Так просто, что скорость переключения страниц вызывала когнитивный диссонанс. Поэтому для более плавного переключения между страницами добавили фишечку - еще одну страницу! С gif-изображением "активного думанья системы" по центру. Таймаут на экран загрузки поставили около 1-й секунды, если загрузка происходила быстрее, чем нужно. Так казалось, что система отзывается на действия пользователя.
Дополнительно внизу рабочего окна АРМа вывели индикаторы текущего состояния оборудования и систем, с которыми выполнялась интеграция.
После отладки на тестовом стенде все оборудование отправилось на завод, где ему предстояло много работы (и нам в том числе). После установки на место выяснилось, что штрихкод со всей необходимой информацией печатался на два блока газобетона и часть штрихкода приходилось на стык между блоками, из-за чего пришлось урезать метку по длине, пожертвовав частью информации.
Так же штрихкод мог наносится неровно, т.к. лента транспортера периодически дергалась и хоть энкодер, передающий скорость ленты принтеру, старался это нивелировать, все равно имели место быть "кривые" метки со штрихкодами. В общем и целом нюансов было предостаточно и без 1С. Совместными усилиями с ребятами из производства все было запущено и работает, в чем можно убедиться в коротком ролике под спойлером:
Сбой в матрице
Конечно же не обошлось без багов или курьезных ситуаций (не могло же быть все настолько хорошо). В пример приведу ТОП-3 на мой взгляд, самых запоминающихся фэйла, обнаруженных уже после внедрения маркиратора на производстве:
Итоги. Принятие неизбежного
Наш прототип перестал быть прототипом и превратился в добротное легаси на 1С. Так же можно сказать, что проект нужно было еще доводить и доводить до ума, но по причине уникальности оборудования и его количества (второй экземпляр принтера для отладки никто не купит и не даст, а производственная линия работает 24/7) с этим есть сложности. К слову, на данном предприятии и автор публикации, то есть я, тоже уже не работает.
Что же было отправлено в тех. долг:
- Сделать более отзывчивым интерфейс АРМа
- Перевести работу с оборудованием на отдельные сервисы (сканер штрихкодов, например, был перенесен на отдельный сервис, что пошло на пользу проекту)
- Внедрить Библиотеку стандартных подсистем
- Выполнить рефакторинг кода (все программировалось "в потоке", повторы кода, неоптимальные вызовы сервера, а про паттерны можно вообще забыть - костылей и "грязного" кода столько, что страшно вспоминать) или в принципе заново нормально спроектировать всю систему - все-таки у нас был MVP для проверки жизнеспособности идеи
- Переписать работу с COM портом принтера в отдельную нативную компоненту
- Изменить интерфейс на основе обратной связи от операторов принтера
На момент написания публикации маркиратор уже пять лет исправно клеймит газобетонные блоки и не собирается останавливаться. =)
PS: Это моя первая публикация на Инфостарт и появилась она благодаря уговорам Дмитрия Котова (rpgshnik) рассказать Вам эту историю. Спасибо всем, кто потратил свое время на прочтение данного материала, надеюсь, Вам понравилось!
