Создание уникальных часов

Все началось, когда мое внимание привлек старый светодиодный дисплей, лежащий в ящике среди мелочевки и запасных деталей. Он сохранился еще со времен древних 386/486 ПК и мог отображать частоту до 99 МГц. Когда он был установлен на системном блоке в те времена, он показывал только две скорости, обычную и турбо, эти скорости работы центрального процессора выбирались специальной кнопкой. Фишка была в том, что сами цифры были желтыми, а надпись MHz (горящие непрерывно) светились красным. Такая комбинация цветов мне понравилась. *
*В те годы частота процессора менялась специальной кнопкой “Turbo”, и эта кнопка присутствовала на системном блоке, а частота отображалась на таком светодиодном дисплее. Прим. Переводчика.

Тогда я задумался, а можно ли собрать на основе этого циферблата часы. Оперируя всего двумя цифрами, мне пришлось бы мультиплексировать часы и минуты. Я решил, что в таком случае могу отображать 12:34 как 12H, сопровождаемое 34М.

Была и еще одна особенность, а именно то, что часть с MHz состояла из всего 7 «сегментов». М делилась на три сегмента, а именно на две боковые вертикальные палочки и центральную часть V. В H 2 вертикальные палочки также были отдельными сегментами, но центральная ее часть уже объединялась с верхушкой буквы z, чья нижняя часть < представляла последний 7-й сегмент. Это означало, что после H всегда будет отображаться «тире», т.е. 12:34 будет показываться как 12H-, а затем 34M. Пусть это будет фишка.

Каждый сегмент MHz состоял из двух последовательно соединенных красных светодиодов с прямым напряжением 3,6В. Желтые же цифры были представлены одиночными светодиодами с прямым напряжением 1,9В. Очевидно, что такой семисегментник изготавливался индивидуально для производителя ПК. Именно поэтому вы и не сможете воссоздать такие часы, если только не отыщите аналогичный экран, сохранившийся с тех времен. Тем не менее при желании вы можете изменить ПО (по большому счету исключить код, обрабатывающий мультиплексирование часов/минут) под использование с удобным 4-значным дисплеем.

Цель

Я собрал эти часы, чтобы решить следующие задачи:

  • Запрограммировать STM8, в частности STM8S103F6, в C при помощи SDCC и портированной стандартной библиотеки периферийных устройств (SPL).
  • Мультиплексировать часы и минуты на двух цифрах.

Подключение

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

Кстати, кнопки тоже от старого ПК, раньше они служили в качестве Reset’а. Для подачи питания на 7805 стабилизатор я приспособил восстановленную зарядку от телефона Nokia.
Паять пришлось довольно много соединений, что неудивительно при переделке не мультиплексированного дисплея в мультиплексированный, поэтому я даже был рад, что собирал всего одну плату. В последствии тестирование показало, что помимо нескольких коротких замыканий и непропаев, была еще пара косяков: я думал, что у транзисторных драйверов посадочное место EBC, но оказалось, что ECB. Ну это же очевидно! Пришлось переподключать провода. Причем переподключать их пришлось не только здесь, потому что еще я перепутал два контакта дисплея, поменяв местами сегменты b и g второй цифры.

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

Схема

Программное обеспечение

SDCC (Small Device C Compiler ) поддерживает архитектуру STM8, и мне понадобились только определить ресурсы процессора STM8, например такие как регистры. Было интересно, почему они не поставляются вместе с SDCC. Не буду углубляться в подробности всего этого приключения, но в итоге выяснилось, что изначально ST не предоставляли включаемые файлы и библиотеки по подходящей для открытых проектов лицензии. В конечном счете они осознали свою ошибку, но к тому времени по интернету уже гуляло много обходных путей. Тем не менее существовал вариант портирования SPL в SDCC. Вы можете прочесть инструкцию по сбору SPL под Linux, чтобы получить включаемые файлы и библиотеку, к плюсам которых можно отнести: улучшенное самодокументирование кода в случае его излишней подробности, наличие проверки ошибок использования, а также то, что SPL для STM32 аналогична, т.е. при необходимости вы уже будете знать, как ее использовать.

Кроме того, я использовал протопотоки Адама Дункельса для обработки переключения.

Прошивка для часов на базе MCU имеет несколько подсистем. Далее я указываю исходные файлы С, обрабатывающие каждую из этих подсистем. Может оказаться полезным обратиться к исходному коду.

  • код, отвечающий за хронометраж (tod.c), который считает миллисекунды, секунды, минуты и часы;
  • таймер периодичности (tick.c), обрабатывающий сканирование цифр и опрос кнопок;
  • дисплей (display.c), получающий время и преобразующий его в массив из 7-сегментных байтов для отправки на порт вывода;
  • обработчик кнопок (button.c), считывающий состояние кнопок;
  • системный модуль (mcu.c), устанавливающий начальную конфигурацию;
  • основная программа (clock.c), связывающая все модули.

Для хронометража используется Timer1, поскольку имеет больше возможностей и дополнительных опций, которые мне еще пригодятся. Частота CPU в 16 MHz поделена до значения в 64 Hz, которое затем пошагово увеличивает время дня, структуру которую содержат счетчики.

Timer4 используется для работающего на 500 Hz генератора тактов, который служит для динамического отображения цифр и опроса кнопок.

Техника отображения для мультиплексированных циферблатов достаточно проста. Есть массив байт, представляющий сегменты каждой цифры. Код обращается к цифрам и соответствующим сегментам по порядку. Таблица шрифтов переводит двоичные числа из счетчиков часов и минут в нужные шаблоны из 7 сегментов. Обратите внимание, что эти массивы должны обновляться только, когда изменяется видимая цифра, т.е. не каждую секунду, а каждую минуту, в том числе при установке самих часов.

Имейте в виду, что в отличие от более простых микроконтроллеров, контакты сегментов берутся из комбинации портов, так как ни один из них не предоставляет все 8 бит в корпусе TSSOP-20. Это значит я не могу использовать байтовые операции для одновременной обработки всех сегментов, но вынужден циклически обрабатывать по одному сегменту за раз. Однако этот микроконтроллер остаточно быстр, поэтому в сравнении с периодом тактов излишняя нагрузка ничтожна.

Обработчик этого таймера также занимается сканированием кнопок при каждом проходе цикла и обновляет конечный автомат протопотоков для действий кнопок. Одиночное нажатие приводит к однократному увеличению. Если же кнопку зажать, то спустя небольшую задержку начнется автоматическое увеличение со скоростью 4 раза в секунду.

Системный модуль инициализирует нужную конфигурацию микроконтроллера. В частности, я использую встроенный RC-генератор на 16MHz.

Основная программа вызывает процедуру инициализации каждого из перечисленных модулей, а затем входит в цикл тактов.

Модификации для мультиплексирования часов и минут

Для обработки мультиплексирования часов и минут я создал 2 массива вместо одного. Первый содержит две 7-сегментные цифры для часов плюс постоянный третий байт, представляющий сегменты H-. Второй массив содержит две 7-сегментные цифры для минут плюс постоянный байт, представляющий сегменты M.

В тактовом цикле при каждом изменении счетчика секунд, он проверяется. Если его модуль после деления на 5 будет от 0 до 2, то указатель циферблата переключается на массив минут, в случае же 3 и 4 он переключается на массив часов. В результате получается, что для, например, 12:34 он в течение 2 секунд показывает 12 H-, а затем в течение трех секунд 34M.

Это мультиплексирование понадобилось остановить при установке времени. В итоге при удержании кнопки прибавления часов циферблат показывает их до тех пор, пока она не будет отпущена. То же самое с кнопкой для минут. Небольшое замечание – при прибавлении минуты счетчик секунд сбрасывается до 0. Это позволяет синхронизировать часы с другими часами, установив одно и то же время в минутах, а затем увеличив их значение резким одновременным нажатием во время смены секунд.

Я реализовал еще одну особенность, а именно выделил красным цифрам удвоенный цифровой период, компенсировав тем самым пониженное напряжение светодиода. В итоге рабочий цикл желтых цифр составляет 25%, а красных 50%.

Доработки для стандартного 4-значного дисплея

Здесь я описал свои непроверенные предположения о том, что нужно сделать тем, кто задумает модифицировать мой код для управления стандартным 4-значным дисплеем.

Из оборудования вам понадобится дополнительный вывод порта для управления 4-й цифрой. Первым логичным кандидатом для этого является D1, но нужно помнить, что на использованной мной коммутационной плате – это также порт SWIM для прошивки исполняемого образа. Так что вам понадобится перемычка, которую можно будет снять при перепрошивке и установить обратно для работы. Еще один вариант – не использовать двоеточие и задействовать A3 для 4-й цифры.

Имейте в виду, что B4 и B5 задействовать нельзя, так как это контакты с открытым стоком для l2C, которые для включения катодного транзистора потребуют добавления подтягивающего резистора. Еще одна проблема в том, что B5 запускает мигающий светодиод. Думаю, вы могли бы приспособить его для 4-й цифры, тогда этот светодиод будет обеспечивать ток транзисторных драйверов для светодиодов. В этом случае свечение B5 будет означать, что часы работают.

В отношении ПО вы можете заменить один 4-байтовый массив на два раздельных 3-байтовых, тогда не потребуется переключения указателя между массивами. Естественно, число цифр увеличиться до 4, но это будет обрабатываться хэш-функцией, использующей оператор sizeof при добавлении вами еще одного элемента в объявления цифровых контактов порта. Кстати, при этом вы также избавитесь от необходимости определения для красных цифр дополнительного времени сканирования, так как в вашем случае все цифры будут одинаковы.

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

Тестирование

Мне потребуется некоторое время для определения смещения времени, после чего я смогу применить необходимый фактор коррекции.

Настройка отсчета времени

Для настройки тактовой скорости часов использовался генератор с числовым программным управлением. Этот способ я подсмотрел у K. C. Lee, который использовал его в своих часах, собранных на микроконтроллере семейства STM8.

Давайте конкретизируем пример, взглянув на изменения в tod.c. Вы можете увидеть, что Timer1 по-прежнему настроен на генерацию 64 прерываний в секунду. Однако теперь счетчик миллисекунд вместо отсчитывания до 64 считает до 32. Мы создаем аккумулятор, назвав его DDS_Accum, который увеличивается на (2^23 + корректировка) при каждом прерывании таймера. Когда DDS_Accum превышает 2^24, на что почти всегда уходит 2 прерывания, счетчик миллисекунд увеличивается, а 2^24 вычитается из DDS_Accum. Я выбрал возведение в степень 2 для переполнения и последующее вычитание, потому что так мы можем выполнить первое путем проверки битов, а второе побитовым маскированием, сделав код более эффективным.

Теперь рассмотрим, какой эффект корректировка оказывает на накопление. Если она нулевая, то схема действует просто как деление на два. Если корректировка отрицательна, то иногда накопление не будет превышать лимит, и увеличение миллисекунд счетчиком происходить тоже не будет, т.е. такт будет утрачиваться. И наоборот, если корректировка будет положительной, иногда накопление будет превышать лимит два раза подряд, порождая лишний такт. Проще говоря, отрицательная корректировка замедляет часы, а положительная ускоряет. Дробная корректировка определяется как корректировка/2^23. Так как это происходит до срабатывания счетчика секунд, мы не замечаем этих мелких колебаний, тем более что минимально отображаемый отсчет ведется в минутах.

Все это можно обобщить до множителей (прерывание таймера/скорость миллисекунд), которые не равны 2, но в более крупных множителей необходимости нет.

Результат

Результат можно увидеть на видео.

Видимо придется залепить красный светодиод черной изолентой, так как иначе из-за своей дикой яркости он будет засвечивать остальные цифры в темное время суток.

Файлы к статье: 4digittest.ino

Ссылки:

Breakout Boards
Instructions for building SPL on Linux
Репозиторий проекта irreproducible-clock

ссылка на оригинал статьи https://habr.com/ru/company/ruvds/blog/525690/

Замена UI авторизации на API для автотестов

Один из важнейших вызовов в автоматизированном тестировании, по моему мнению, – это обеспечить его высокую надёжность. В решении проблемы улучшения показателей надёжности тестирования, хорошо себя зарекомендовал подход использования API интерфейса вместо UI. В данной статье мы подробно разберём простой механизм замены UI авторизации на API.

Существует большое количество видов аутентификации – Basic, Digest, Form, OAuth 1 и OAuth 2. В качестве примера я предлагаю рассмотреть одну из простейших, а именно – Form. Основная задача статьи – это показать подход внедрения API авторизации для UI тестов. Тесты и имплементацию будем писать на Java. Из инструментов будем использовать Chrome DevTools.

В качестве объектов тестирования используем Kanboard та DVWA. Это open source продукты с открытой лицензией, которые достаточно легко развернуть локально. По ссылкам можно прочитать больше про данные продукты и при необходимости ознакомиться с инструкциями из развёртки.

Проект создадим с помощью maven и добавим testng, selenide, rest-assured, json-path, jsoup, maven-compiler-plugin та maven-surefire-plugin.

Логинимся в Kanboard с открытой вкладкой Network Chrome DevTools.

image

image

Проанализировав DevTools, мы можем узнать алгоритм авторизации. В данном случае, для авторизации выполняются два запроса: GET с двумя query параметрами и POST з парой логин/пароль и csrf токеном. Первый запрос необходим для того, чтобы получить KB_SID cookie. Второй – для KB_RM cookie. Установив оба этих значения в WebDriver, мы получаем доступ к главной странице.

Первый запрос в RestAssured будет выглядеть следующим образом

Response response01 = given()                 .queryParam("controller", "AuthController")                 .queryParam("action", "login")                 .when()                 .get(BASE_URL); 

Из него мы получаем KB_SID cookie

String cookieKBSID = response01.getCookie("KB_SID");

CSRF токен находится в доме HTML страницы, которую мы можем увидеть в теле респонса.

image

Получить его нам поможет библиотека jsoup, которая позволяет разделять документ на элементы. Поиск производится подобным же образом, как и Web елементи.

String cSRFToken = Jsoup.parseBodyFragment(response01.body().asString())        .getElementsByAttributeValue("name", "csrf_token").attr("value");

Второй запрос в RestAssured будет выглядеть следующим образом:

Response response02 = RestAssured        .given()        .config(RestAssured.config()        .encoderConfig(EncoderConfig.encoderConfig()        .encodeContentTypeAs("x-www-form-urlencoded", ContentType.URLENC)))        .contentType("application/x-www-form-urlencoded; charset=UTF-8")        .formParam("remember_me", "1")        .formParam("username", "admin")        .formParam("password", "admin")        .formParam("csrf_token", cSRFToken)        .queryParam("controller", "AuthController")        .queryParam("action", "check")        .cookie("KB_SID", cookieKBSID)        .when()        .post(BASE_URL);

На этом этапе стоит обратить внимание на то, что запрос необходимо правильно заенкодить (encoderConfig, encodeContentTypeAs).

Из него мы получаем KB_RM cookie.

String setCookieHeaderValue = response02.header("Set-Cookie");

Теперь, когда мы получили все необходимые элементы, нам остаётся только открыть нужную страницу з заполненными полями cookie.

WebDriverRunner.getWebDriver()        .manage().addCookie(new Cookie("KB_SID", cookieKBSID)); WebDriverRunner.getWebDriver()        .manage().addCookie(new Cookie("KB_RM", cookieKBRM)); Selenide.open(url);

Для DVWA все происходит аналогично, только токен будет иметь другое имя.

Безусловно, для других видов аутентификации количество запросов и их сложность будет отличаться. Однако, базовый принцип остаётся неизменным – проанализировать полученный алгоритм и воспроизвести его с помощью RestAssured.

Благодарю за внимание и надеюсь, что эта статья была полезной для Вас.

ссылка на оригинал статьи https://habr.com/ru/post/525936/

Робототехнические лаборатории, фаблаб и победы молодежных команд на профильных олимпиадах — дайджест Университета ИТМО

У нас под катом — три фотоэкскурсии, два подкаста, отчеты о дне мейкера и статьи проектах-победителях крупнейших международных соревнований по молодежной робототехнике.

«Механизированные руки и манипуляторы». Показываем, как выглядит лаборатория робототехники Университета ИТМО. Внутри фотоэкскурсии — с промышленными установками, устройствами захвата и другой техникой — есть и развернутый рассказ о том, чем занимаются специалисты лаборатории, развернутой на базе нашей старейшей кафедры: от экспериментов с робототехнической платформой Стюарта и разработки алгоритмов адаптивного управления для KUKA youBot до работы с FESTO Robot Vision Cell и моделирования поведения надводного судна.

Знакомство с лабораторией киберфизических систем. Еще одна компактная фотоэкскурсия у нас на Хабре — делимся подробностями об инфраструктуре нового многофункционального пространства. Здесь есть: полигон для роботов, indoor-квадрокоптер, камеры с системой захвата движения, раздвижная стена для дополнительного зонирования помещения, закрытая рабочая зона, огромные стены для визуализации алгоритмов и бизнес-процессов, а еще — свой кофе-рум. Помимо материальной базы обсуждаем проекты и разработки лаборатории.

«Мы работаем с неструктурированным окружением». Спикер этого выпуска ITMO Research — Сергей Колюбин. Он руководит лабораториями, которые мы показали выше, и работает заместителем директора мегафакультета компьютерных технологий и управления. В интервью Сергей рассказывает о подходе к образовательному процессу, возможностях для студентов и аспирантов, плюс — балансе личных и общих интересов рабочих групп профильных лабораторий.

«Это возможность попробовать и понять, твое это или нет». День мейкера становится традиционным мероприятием для тех, кто хотел бы познакомиться с микрокомпьютерами и робототехическими DIY-компонентами. Эвент ориентирован не только на первокурсников профильных специальностей, но и учащихся на смежных дисциплинах с разным уровнем подготовки. По словам организаторов, число резидентов Фаблаба перевалило за 800 человек.

DIY-коворкинг для творческих людей. Третья фотоэкскурсия в этой подборке, но вновь по технической тематике. Рассказываем, что находится внутри Фаблаба Университета ИТМО — показываем оборудование для мейкеров и начинающих робототехников: 3D-принтеры, лазерные граверы и фрезерные станки с ЧПУ. Плюс — студенческие прототипы (VR/AR-робот SMARR).

«Хочу, чтобы когда-нибудь в крупных компаниях нас встречали бывшие ученики». Основатель компании-резидента акселератора Университета ИТМО рассказывает, как запустил проект клубов по робототехнике «GoROBO». Он предоставляет образовательные программы и помогает с подготовкой к молодежным робототехническим соревнованиям.

Победители Russian Robot Olympiad о роботах будущего. Журналисты HighTech’а обсудили с ребятами, как они познакомились с робототехникой, разрабатывали проекты вместе с Игорем Лосицким (руководителем нашей лаборатории молодежной робототехники) и готовились к соревнованиям. Важный элемент интервью — личные планы на профессиональное развитие.

Чуть более подробный рассказ о проекте-победителе («умный» стол с лампой, который убирает себя сам с помощью мягкого захвата и классификации предметов) — на нашем новостном портале. Кстати, эта команда первокурсников взяла и серебряные медали WRO-2019.

Победа на Балтийском научно-инженерном конкурсе. Проект команды творческой лаборатории робототехники Университета ИТМО под названием Strawberry fields, представленный учениками 11 класса под руководством Игоря Лосицкого и Евгения Заварина, стал лучшим на этом конкурсе. Разработчики продемонстрировали модель «умной» грядки, которая позволяет собирать клубнику с помощью квандрокоптера и технологии «мягкого захвата». Стоит отметить, что проект признали лучшим и на олимпиаде WRO-2018.

Лучшие на международной конференции робототехники ICRA2019. Пятеро из девяти участников команды-победителя представляют наш факультет систем управления и робототехники. Рассказываем, кто поддержал этот коллектив, как проходила подготовка к «дистанционной» секции AI Driving Olympics и как выглядели задачи на этой олимпиаде.

«Предприниматель года — наш человек». Илья Чех, выпускник нашего бакалавриата и магистратуры, получил это звание по версии «Ernst & Young». Его «Моторика» помогла сотням клиентов из разных стран и продолжает ставить перед собой самые амбициозные цели на стыке медицины и робототехники. Кстати, вот корпоративный блог этой компании Хабре.


Что еще у нас есть на Хабре:


ссылка на оригинал статьи https://habr.com/ru/company/spbifmo/blog/524272/

Zabbix + Wirenboard: мониторинг производства

Введение

В этой статье я расскажу о том, как мы используем Zabbix и Wirenboard для мониторинга производственного оборудования, каким образом мы смогли получить данные с линий и источников основных ресурсов. Статья описывает концепцию и основные моменты организации мониторинга средствами свободно распространяемого ПО, но в ней не будут обсуждаться серьезные системы класса SCADA. Моя задача была быстро развернуть мониторинг без капитальных вложений и начать получать данные как можно скорее с того что уже есть.

Задача

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

Сложности интеграции

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

Все менять – долго, дорого и сложно, а данные нужно получить уже сейчас, вывод: нужно встраиваться.

Контроллер

В качестве контроллера мы выбрали Wirenboard . На его борту работает полностью открытый linux, можно устанавливать любые дополнительные пакеты, есть свой движок правил и web интерфейс. Производитель контроллера выпускает всю необходимую линейку датчиков и счетчиков, которые общаются между собой по открытому протоколу Modbus RTU. Все данные собираются в MQTT. На мой взгляд MQTT — самый подходящий способ сбора и доставки данных телеметрии, протокол открытый и максимально простой в работе.

Zabbix-mqtt-Wirenboard

Zabbix не работает напрямую c MQTT, но есть возможность использовать внешние модули, вот два варианта, которые я применял.

Первый и самый простой — установить Zabbix агента на контроллер, он будет опрашивать топики через MQTT клиент mosquitto_sub. В настройках агента потребуется указывается параметр: «UserParameter=mqtt.value[*],mosquitto_sub -t ‘$1’ -C 1», а на стороне Zabbix сервера, в item key прописать mqtt.value[путь к топику].  

Это заработало достаточно быстро, но у этого подхода есть проблема – MQTT хранит данные в топике без привязки ко времени. Если датчик умер, и не присылает новые данные, в топике все равно хранится последнее значение и на графике в Zabbix мы получим прямую линию. Можно использовать ключ «retain», который позволяет доставлять данные метрики только активным подписчикам на соответствующий топик, но тогда Zabbix данные не получит вообще, так как он опрашивает последнее значение, а не подписывается на топик. Еще одна неприятность – на каждый топик свой запрос, опрашивать нужно много и часто. Это приводит к расхождению реального состояния на производственной линии и полученных данных, потому что опрос производился в разное время и с интервалами.

Второй способ получения данных стал возможен благодаря переходу на Zabbix 4.2 и интеграции модуля zbx_mqtt. Скрипт опроса устанавливается на Zabbix сервер, с его помощью можно запросить всю ветку топиков устройств, получить данные в формате JSON и затем разобрать их по соответствующим метрикам. Так мы смогли забирать данные одновременно с нескольких датчиков и получить «снимок» состояния всей линии. Проблема с устареванием данных решается через обработку данных в Preprocessing: если данные не менялись – не записывать их.  

Мониторинг

Счетчик импульсов

Импульсный выход – самый распространённый интерфейс для подсчета чего-либо. С его помощью можно:

  • посчитать потребление с расходомеров или сколько продукции прошло через оптические датчики

  • определять состояние дверей или положение подвижных элементов при помощи герконов

  • снимать данные с энкодеров двигателей и получить угол поворота или количество оборотов

  • определять статусы вкл/выкл через реле или аналоговые выводы.  

Например, у нас есть счетчик WB-MCM8 c modbus адресом 32, мы его используем для подсчета банок оптическим датчиком на выходе конвейера, он передает данные в топики MQTT на Wirenboard.

/devices/wb-mcm8_32/controls/Input 1 counter /devices/wb-mcm8_32/controls/Input 2 counter … /devices/wb-mcm8_32/controls/Input 8 counter

Для сбора данных мы создаем в Zabbix элемент MasterItem_WB-MCM8_32 с типом External check. Он будет забирать состояние всех счетчиков.

Пример Master item для MQTT метрик
Пример Master item для MQTT метрик

В поле key мы указываем запрос: mqtt[«-t=/devices/wb-mcm8_32/#»,»—mqtt-host={HOST.CONN}»] где:

  • mqtt[] – вызов скрипта для опроса с параметрами

  • -t=/devices/wb-mcm8_32/# — запросить все данные внутри топика устройства wb-mcm832

  • —mqtt-host={HOST.CONN} — адрес контроллера Wirenboard. Адрес указан как переменная {HOST.CONN}

В результате такого запроса, в Zabbix возвращаются данные в формате JSON, вот пример фрагмента:

{…"/devices/wb-mcm8_32/controls/Input 7 counter": "3129705", "/devices/wb-mcm8_32/controls/Input 3 counter": "1885652", "/devices/wb-mcm8_32/controls/Input 1 counter/meta/type": "value", "/devices/wb-mcm8_32/controls/Input 5/meta/order": "13", "/devices/wb-mcm8_32/controls/Input 8/meta/order": "16"…}

Вторым шагом мы создаем dependent item, который будет забирать конкретную метрику из мастера.

Параметр key тут значения не играет, но в нем я указываю полный путь к топику mqtt для удобства поиска. Выборка данных указывается во вкладке Preprocessing.

  • JSONPath указывает на нужный нам топик с метрикой

  • Check for error in JSON — у устройства wb-mcm8 есть специальный служебный топик с ошибками и можно сделать проверку: если он не пустой, значит проблема с устройством, значение не будет сохраняться и элемент данных в Zabbix перейдет в состояние ошибки.

  • Simple change так как нам нужно не само значение счетчика, а его изменение (дельта) – мы используем функцию Simple change.

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

Счетчик электроэнергии

Мы использовали WB-MAP3H. Для его установки не требуется отключения линий и потребителей, устройство получает данные о расходе через внешние трансформаторы тока, которые крепятся на кабель без его демонтажа. Важно соблюсти соответствие подключаемых фаз (контролируется по фазовым углам) и указать коэффициенты трансформаторов (в новой версии они указаны на корпусе, в старой – делалась калибровка у производителя). Устройство не только измеряет основные характеристики (мощность, энергия, расход), но умеет измерять много дополнительных характеристик вплоть до определения доли гармоники и амплитуд всплесков (полный список измеряемых параметров можно посмотреть тут).

WB-MAP3H
WB-MAP3H

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

Получение данных от Delta по Modbus TCP и RTU

У нас часть промышленных линий управляется контроллерами Delta, на которых есть сетевой интерфейс и реализован протокол Modbus TCP. Переменные на контроллере сохраняются в регистры Modbus и их можно забрать в Zabbix при помощи модуля libzbxmodbus. Модуль оказался очень функциональным и удобным, он умеет работать не только по сети с TCP, но и через com порт с RTU реализацией Modbus. Подробное описание и параметры можно посмотреть на гите разработчика, а я покажу свой пример использования.

На Zabbix создан Master item, он забирает с контроллера 17 регистров по Modbus TCP, в которых хранятся данные от датчиков веса, температуры и уровня продукта в емкости.

modbus_read[{$MODBUS_ADDRESS},1,4110,3,17*s]
master item для опроса контроллера Delta
master item для опроса контроллера Delta
  • $MODBUS_ADDRESS – локальная переменная в Zabbix, в ней хранится ip адрес контроллера к которому обращаемся, у меня это «tcp://192.168.0.2»

  • 1 – адрес устройства на шине Modbus. Как правило это «1», разные адреса могут быть при работе с RTU версией протокола, когда несколько устройств работают на одной шине

  •  4110 – адрес начального регистра, который мы читаем первым

  • 3 – функция протокола Modbus. В моем случае указана 3 – функция чтения регистра

  • 17*s – модуль умеет читать несколько регистров подряд, в моем примере он берет 17 регистров и считает, что тип данных в них int16 (s=int16, f=float, b=bit это подробно описано в документации к модулю)

В 5й версии Zabbix появилась возможность сразу тестировать работу запроса и посмотреть возвращаемое значение – кнопка Test, нажав ее мы получим JSON объект со значениями 17 регистров (с 4110 по 4126).

{"4110":967,"4111":960,"4112":395,"4113":0,"4114":0,"4115":0,"4116":665,"4117":803,"4118":2500,"4119":2500,"4120":447,"4121":999,"4122":1224,"4123":2154,"4124":1493,"4125":1254,"4126":418}

Теперь мы можем создать зависимый элемент данных, указать в Preprocessing steps параметр JSONPath = $.4110 и получить в него значение метрики от 4110 регистра. Дополнительно можно указывать проверки полученного значения, например: параметр In range проверяет попадает ли значение в промежуток от 0 до 1500, если нет – значение отбрасывается. При помощи параметра Discard unchanged можно отбрасывать значения, если они не меняются.

Настройка метрики из регистра контроллера
Настройка метрики из регистра контроллера

Интеграция с Siemens

Контроллеры Siemens S7 используют свой протокол profinet / profibus, для работы с ним есть открытая библиотека Snap7. Для интеграции был создан скрипт zbx_s7_get на питоне, который умеет опрашивать контроллеры.

Пример запроса данных
Пример запроса данных

Скрипту s7_get.py передаются параметры:

s7_get.py[{HOST.CONN},{$S7.RACK},{$S7.SLOT},{$S7.DB},6,bool,--json]
  • {HOST.CONN} – встроенная локальная переменная, которая содержит ip адрес узла сети (указан в host interface)

  • {$S7.RACK} – переменная, в которой указан rack id контроллера

  • {$S7.SLOT} – переменная, в которой указан слот

  • {$S7.DB} – переменная , в которой указан id базы

  • 6 — offset

  • Bool – тип возвращаемых данных, в моем случае мне нужны именно true / false. Может быть int или float.

  • —json – формат данных. В моем случае выбран json, так как это master item и на его основе я создаю зависимые элементы с нужными метриками.

При тестировании этого элемента мы получим данные в JSON, которые можно будет разобрать по метрикам (в моем случае это статусы с датчиков на контроллере).

{"6": ["True", "False", "False", "True", "False", "True", "True", "False"]}

Получение данных с принтеров Linx 5900

Промышленный принтер Linx 5900 используется для маркировки продукции на конвейере (дата производства, номер партии). Маркировка очень важный процесс, за которым нужно следить, так как если принтер остановится или будет печатать некорректные данные — можно получить отзыв продукции со склада или претензию от клиентов.

Для подключения Zabbix к принтеру я использовал конвертер moxa NPORT 5150. Он позволяет прокинуть через tcp физический порт rs232 с принтера на виртуальный serial порт /dev/ttyr01 linux машины, где установлен Zabbix агент. Само общение с принтером происходит по Linx Remote Communications Interface (RSI). Протокол обмена основан на отправке команды в двоичном виде, вот пример заброса счетчика отпечатков (используется мной для подсчета продукции).

Запрос: 1b 02 08 1b 03   Ответ: 1b 06 00 00 08 da bc b9 01 1b 03  Протокол:  1b 06 - начало  00 00   08 – ответ на команду 8 (получить счетчик)  da bc b9 01 -  полезные данные  1b 03 конец  Пример данных UINT32 - Little Endian (DCBA)  01 B9 BC 8F       28949647  01 B9 BC DA       28949722  01 B9 BD 25       28949797

Протокол обмена использует контрольные суммы в запросе и ответе, последовательность подробно описана в инструкции, но мне не удалось с ними разобраться и пришлось эту функцию отключить.

В Zabbix я использовал плагин serial.get. Item key для получения текущего состояния счетчика выглядит так:

serial.get[/dev/ttyr01,5,1b02081b03,uint32]

Заключение

Zabbix прекрасен своей гибкостью и функциональность, на его основе нам удалось быстро создать мониторинг основных параметров производственных линий без остановки и переоснащения.

С помощью мониторинга удалось:

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

  • начать считать OEE и оперативно реагировать на снижение производительности отдельных участков

  • сравнивать производительность дневных и ночных смен в онлайн режиме

  • оптимизировать логику управления производственной линии и поднять ее производительность (за счет перенастройки таймингов насосов и приводов)

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

При внедрении мониторинга важно понимать, что просто получить данные недостаточно, ими нужно активно пользоваться – анализировать и визуализировать, предоставлять легкий доступ всем заинтересованным. Про визуализацию в Grafana я написал другую статью, прочитать ее можно тут.

В планах:

  • Подключить к мониторингу удаленные площадки, куда не протянуть провода. Вероятно это будет через радо по lorawan

  • Разработать весовой контроль подаваемого сырья при помощи интеграции с весовыми терминалами CAS

  • Разработать мониторинг состояния двигателей за счет контроля потребления энергии и вибродиагностики

  • Расширить покрытие мониторинга по всему заводу

P.S.  

Статья написана до выхода Zabbix 5.2.  Новая версия ориентирована на работу с iot и в ней уже есть возможность получать данные из MQTT и Modbus без дополнительных модулей, за что огромное спасибо разработчикам Zabbix. Отдельное спасибо @wabbit за модули на git https://github.com/v-zhuravlev, именно они дали основной толчок к развитию мониторинга.

ссылка на оригинал статьи https://habr.com/ru/post/525852/

Для начинающих: как выбрать файл в 1С?

Добавим новую форму с кнопкой, нажав на которую будет открываться окно выбора файла. Дальнейшая обработка файла в данном примере не рассматривается. Рекомендуется тренироваться на копии базы или пустой конфигурации. Пример создан на конфигурации 1С:CRM 3.0.

Сначала подготовим конфигуратор.

Заходим в конфигуратор 1С. Если конфигурация не открыта, открываем ее и снимаем с поддержки. В меню «Конфигурация» нажимаем «Открыть конфигурацию». Далее в меню «Конфигурация» нажимаем «Поддержка» и выбираем «Настройка поддержки». В окне нажимаем кнопку «Включить возможность изменения» и устанавливаем переключатели как на картинке. Нажимаем «Ок».

Теперь создадим простую обработку.

Находим в левой таблице объектов объект «Обработки», нажимаем на ней правой кнопкой мыши и выбираем «Добавить». Далее потребуется заполнить Имя обработки, указать, в какой подсистеме 1С хотите вызвать обработку, и добавить новую форму в разделе «Формы».

После создания формы появится окно как представлено ниже.

Теперь создадим команду формы «Загрузить» нажав на плюс в верхнем правом окне. Обязательно укажите свойство «Действие». Это будет название процедуры 1С.

Далее добавляем на форму кнопку «Загрузить», нажав на плюс в левом верхнем окне. Обязательно укажите свойство «ИмяКоманды». Здесь укажем название команды, которую создали на предыдущем шаге «Загрузить». В результате на форме появится кнопка «Загрузить».

Далее напишем небольшой код.

Внизу окна нажимаем на закладку «Модуль». У нас здесь уже есть пустая процедура. Добавляем в нее код.

//выбор файла

ДиалогВыбора = новый ДиалогВыбораФайла(РежимДиалогаВыбораФайла.Открытие); ДиалогВыбора.Заголовок = «Выберите файл»;

ДиалогВыбора.Фильтр = «Excel документ, .xls|.xls»;

ДиалогВыбора.МножественныйВыбор=Ложь;

Если ДиалогВыбора.Выбрать() Тогда

ИмяФайла = ДиалогВыбора.ПолноеИмяФайла;

КонецЕсли;

В результате получится так как на рисунке ниже.

И в конце остается проверить в пользовательском режиме. Для этого нажимаем «Начать отладку» или F5. Конфигуратор спросит обновить ли конфигурацию базы данных. Отвечаем «Да» и у нас открывается 1С (режим пользователя). Далее находим подсистему, куда добавили обработку (в нашем случае это «Маркетинг») и проверяем.

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

Спасибо за внимание!

ссылка на оригинал статьи https://habr.com/ru/post/525942/