Почти на любом современном производстве есть ПЛК. Эту штуку нередко называют «Мозгом», но редко объясняют что конкретно она делает.
Что же такое ПЛК? Для начала это программируемый логический контроллер. Представьте оркестр из множества пускателей, двигателей, сервоприводов, конвейерных линий и так далее. Дак вот ПЛК – это дирижер того самого оркестра.
А теперь научное определение, программируемый логический контроллер – это специализированное электронное цифровое устройство, которое предназначено для автоматизации технологических процессов и работы в системах реального времени.
Откуда ПЛК знает что происходит вокруг? Этот контроллер имеет входы и выходы. Входные модули отвечают за получение цифровых и аналоговых сигналов из внешних устройств, таких как датчики температуры, давления или уровня. Выходные модули, в свою очередь, отправляют сигналы на исполнительные устройства.
Рассмотрим как ПЛК принимает решения. Помимо модулей входа и выхода программируемый логический контроллер имеет центральный процессор. ЦП является хранителем памяти, логики и коммуникаций, также это место, где находится созданное разработчиком программное обеспечение. На основе этого ПО и данных, которые были получены от датчиков, ПЛК управляет выходными сигналами, контролируя работу механизмов, устройств и оборудования.
Представьте конвейерную ленту. Оптический датчик видит, что пустая бутылка подъехала по конвейеру на место розлива. Датчик давления проверяет, есть ли углекислый газ в системе. Программа внутри ПЛК получает сигналы от датчиков и сравнивает их с заданным алгоритмом. Если бутылка на месте и давление в норме, контроллер начинает действовать. ПЛК подает сигнал на открытие электромагнитного клапана подачи воды. Включается таймер. Когда время истекает, клапан закрывается, а конвейер делает шаг вперед для подачи следующей бутылки.
ПЛК часто программируют на языке релейных схем (Ladder Diagram), делается это для того, чтобы инженеры на производстве смогли легко разобраться в логике. Для этого им не придется учить сложные языки программирования.
Список основных плюсов ПЛК: гибкость для задач разных сложностей, надежная работа в сложных условиях, простота программирования.
в тот самый момент, когда поняли (на самом деле это был долгий и по большей части безрадостный момент): готовые контроллеры не вывозят наши промышленные условия, готовые алгоритмы "деревянные" и не гнутся под технологию процессов. Тот пост неожиданно для нас попал в горячее, собрал много комментариев и вопросов из ответов на которые и собран этот пост.
Но сначала коротко о том, кто мы и зачем всё это затеяли.
Мы не про «импортозамещение», мы про «своё и лучше»
Инкрустированная "камнями" поверхность. Одна из плат расширения к контроллеру.
Мы не копировали западные образцы. Мы с ними работали и думали: "Что нам не нравится в существующих решениях? Что ломается в поле, о чём молчат производители и чего не хватает?"
И вот что мы насобирали за годы работы на реальных фермах.
1. Ограничения сред разработки. Даже в самых продвинутых универсальных средах есть жёсткие ограничения, не позволяющие полноценно реализовать сложные алгоритмы.
2. Энкодер и модули ввода-вывода. На длинных линиях при управлении пусковыми аппаратами возникают импульсы. Модули ввода-вывода, в том числе те, что должны принимать сигналы с энкодера, от этих помех сходят с ума. Или не видят сигналы с датчиков. В результате - потеря позиции, хаос, остановки, убытки.
3. Сбои. Система требует ручного перезапуска, еще хуже если настройки не сохраняются или требуется перепрошивка, а до неё ещё добежать надо. Это часы простоя, особенно ночью.
4. Закрытые протоколы. Никакой интеграции с другими системами, всё зашито намертво. Вы не можете забрать данные.
5. Разрозненность мировых решений. Существуют отличные алгоритмы - решения мировых лидеров. Но они разрозненны: одна система - для навозоудаления, другая - для микроклимата (и это отдельно шторы, отдельно вентиляторы, отдельно орошение, приточка), третья и четвертая - для КНС и Сепарации, пятая - для дезинфекции доильных аппаратов. Все от разных производителей, с закрытыми протоколами. Между собой не связаны. Не позволяют синхронизировать процессы. И их сложно, а чаще невозможно дополнить, оптимизировать или адаптировать под реконфигурацию исполнительного оборудования.
6. Отсутствие удобного человеко-машинного интерфейса. У большинства решений:
нет веб-интерфейса, где можно было бы посмотреть состояние системы, изменить уставки или перенастроить логику прямо с телефона или ноутбука;
панель оператора, если она есть - недружелюбная, с архаичным меню и/или кривым переводом, которую, к тому же, еще и отдельно надо программировать;
а если и есть ПО для ПК - оно проприетарное, требует установки, весит гигабайты, не работает без "родного" программатора.. и на немецком.
В результате любое изменение в системе — это вызов инженера или программиста, поиск программатора, установка софта и потеря времени. Вместо того чтобы открыть браузер, зайти в настройки и за пару кликов изменить параметры или тут же через встроенный Wi-Fi обновить прошивку, вы тратите часы на поиск нужного кабеля, совместимой версии ПО и человека, который умеет с этим работать и, по опыту, ему ехать до фермы километров 300.
А есть и «альтернативы»:
Мировые лидеры — калибровка выполняется по току, упором в ограничитель. Скрепер просто упирается, ток резко растёт — и система запоминает эту точку как конечную. После 4-5 таких калибровок редуктор ломается или станцию вырывает из креплений.
Потому что при первых запусках, в период приработки ответных плоскостей механизмов к свежему бетонному полу навозных аллей, упор происходит с полным усилием двигателя.
Другие "альтернативы" - вообще без энкодера. Вся логика защиты завязана на одном единственном параметре - токе двигателя. Превысил - значит, препятствие. А если датчик тока вышел из строя или дал ложный сигнал? Или настроили большой ток, чтобы не отвлекаться лишний раз на штатные инциденты? Всё...
...но рано делать поспешные выводы
Мы сделали свой контроллер не чтобы "заменить", а чтобы решить эти проблемы раз и навсегда.
Мы собрали в одном устройствевсе технические и программные функции, которые предлагают западные лидеры для каждой подсистемы (навоз, климат и т.д.) - плюс дополнительный функционал, которого у них нет. Добавили техническую устойчивость к нашим реалиям: гальваническую развязку, широкий диапазон питания, аппаратную самодиагностику, энергонезависимую память с ресурсом 14 триллионов циклов перезаписи и гибкое программное обеспечение.
Как мы чуть не поседели во время локального апокалипсиса
Самая стробоскопическая история, которая лучше любых цифр доказывает, что мы не зря старались.
Однажды летом на одной из площадок в 70 гектаров (к слову, стоимостью более 30 млрд. рбл.) случился электромагнитный ад: штормовой ветер, ливень, проблемы на линии 10 кВ. Трансформаторы заискрили, включились резервные дизель-генераторы, у некоторых оказалась перепутана очередность фаз - случилось все и сразу!
Что произошло с "чужими" контроллерами? Они дружно ушли в защиту и ждали перезапуска. Инженеры под дождём бегали бодрить системы водоподготовки, тепловые пункты, вентиляцию, попутно пробегая мимо наших систем.
А мы - те, кто еще недавно жег оборудование заказчика направо и налево бегали вместе с ними. И когда всё успокоилось, к нашему общему, с заказчиком, изумлению - 100% наших систем отработали штатно. Без ручного перезапуска. Без нашего вмешательства.
Примерно так мы выглядели, когда поняли, что всё работает
Наши "Операторы" - просто пережили всё. Те, что управляли скреперами, заметили, что двигатель крутится не в ту сторону (очередность фаз), и самостоятельно реверсировали контакторы. Там, где сработали тепловые реле (отсутствие одной из фаз), контроллер зафиксировал инцидент и терпеливо ждал сброса, там, где питание пропадало и появлялось – продолжалась работа, не потеряв ни позиции энкодера, ни текущего шага техпроцесса.
Что под капотом
Что внутри и чем это отличается от того, что есть на рынке.
Шкаф (+4 пульта) для управления четырьмя независимыми скреперными приводами навозоудаления
Энкодер и позиционирование У нас не просто "есть энкодер". На любую пару дискретных входов можно подать сигнал энкодера - до 10 кГц (можно увеличить). Этого достаточно, чтобы отслеживать положение скрепера с точностью до миллиметра (длина аллеи 120+ метров). И позиция сохраняется в Backup-регистрах, которые питаются от батарейки. Даже если питание пропадёт, контроллер помнит, где стоит скрепер, куда ехал и что делал.
Восстановление после сбоя 50 мс - загрузка ядра. 200 мс - полный старт с Wi-Fi. Без потери позиции, без ручного перезапуска. Это не просто цифры. Это оптимизированный код. Это скрепер, который не "забывает", где он остановился, и продолжает цикл с того же шага многоступенчатого динамического алгоритма.
Память - три уровня - Backup-регистры (CR2032) - для позиции энкодера и текущего состояния в алгоритме. Чтение - мгновенное. Даже если питание пропадёт, контроллер знает, где стоит скрепер и на каком этапе цикла остановился.
- FRAM - для моточасов и данных, которые перезаписываются постоянно. Ресурс - 14 триллионов циклов. Для сравнения: у обычной EEPROM - 100 тысяч. Если бы мы писали моточасы в EEPROM, он бы умер через пару месяцев. FRAM живёт десятилетиями.
- EEPROM - для настроек и калибровок. Там, где не нужна частая перезапись, EEPROM работает без проблем и не деградирует десятилетиями.
Гальваническая развязка 1500 В RS-485 с развязкой 1500 В - чтобы частотники и длинные линии не сбивали энкодер, не убивали каналы и не дотягивались до ядра. Это не опция. Это стандарт.
Ждём, пока придумают Python. И контрактное производство.
Питание 5-60 В Контроллер работает от любого источника в этом диапазоне. Терпит скачки, от которых теряют сознание платы конкурентов. Встроенная аппаратная защита - диод от переполюсовки и предохранитель. Программный контроль напряжения непрерывно отслеживает питание и при критических отклонениях отключает каналы, защищая оборудование. По значению питания в разрешении миллисекунд мы видим даже срабатывание промежуточного реле.
И ещё один важный момент: у нас на борту "жирная зона питания" с запасом по току. Даже после отключения электроснабжения и после отключения блока питания контроллер продолжает писать логи и регистрировать отказы ещё 2–3 секунды. Эти события помечаются как «отказ питания» и не смешиваются с техпроцессом. Это даёт полную картину: если что-то пошло не так, мы знаем — куда механизмы успели "доехать", посчитать импульсы энкодера, пока он их еще может отправлять.
Для нормальной работы нам не нужны дорогостоящие блоки автоматического ввода резервного питания, дополнительные аккумуляторы и остальные приборы и устройства фильтрации для качества электроснабжения, мы гарантированно "взлетаем" за 50 мс.
Дискретные выходы - 2 А на канал MOSFET с защитой от замыкания и перегрева, контроль температуры.
Аналоговые входы - 12 бит 11-12 каналов, 0-10 В / 0-20 мА, 100 кОм. С калибровочными таблицами - подключайте любые датчики с любой характеристикой.
Аппаратная самодиагностика Мы опрашиваем каждый цифровой канал каждую миллисекунду. Это не просто "подали команду и забыли". После каждой команды на включение или выключение контроллер проверяет, изменилось ли состояние на канале. Подали команду на катушку реле - проверили, есть ли напряжение на канале. Команда есть, напряжения нет - значит, обрыв провода, перегорел предохранитель или сгорела катушка. Команда отключить, а напряжение осталось - значит, контакты реле залипли или MOSFET пробит.
600+ типов событий. Обрыв цепи, короткое замыкание, перегрев MOSFET - знаем за 1 мс. И не просто знаем, а фиксируем в журнале, чтобы вы могли найти причину, а не гадать, что случилось.
Светодиоды на каждый канал, интерфейс, ядро и Wi-Fi - видно даже без интерфейса. И у них разная логика мигания. Заглянул в шкаф, посмотрел на индикацию - и уже понимаешь, что случилось, даже без ноутбука и веб-интерфейса.
REST API + веб-интерфейс Настройка и мониторинг с телефона или ноутбука по Wi-Fi. Открытая интеграция с системами верхнего уровня.
Ловим Wi-Fi через три железобетонных перекрытия
Бутлоадер и защита прошивки Обновление встроенного ПО выполняется через веб-интерфейс - без вскрытия корпуса и программаторов, даже через Wi-Fi.
Но главное - защита от "кирпича". Если по какой-то причине прошивка не загрузилась, контроллер не превращается в бесполезный кусок пластика. После настраиваемого числа неудачных попыток загрузки прошивки он автоматически переключается в бутлоадер.
И всё это - гальваническая развязка, широкий диапазон питания, три уровня памяти, 50 мс восстановления, самодиагностика, опросы каналов 1 мс, светодиоды на каждый канал и компонент, ядро и Wi-Fi, интерфейсы связи, от 66 каналов на "борту" - собрано в одном приборе, модули расширения по 72 канала или 30 ШИМ каналов, масштабирование ПЛК до 32х модулей.
По отдельности эти функции можно найти у разных производителей. Но чтобы всё это работало вместе, без компромиссов, в одном устройстве, с собственной ОСРВ, френдли web-интерфейсом и открытым API - такого на рынке нет.
И мы не просто даём "коробку". Вместе с каждой системой передаём полный комплект документации: пугающе детализированные принципиальные схемы и технически глубоко проработанные, подробные руководства по эксплуатации с пошаговыми инструкциями по настройке всех алгоритмов, чек-листами, короткими справками типа "вопрос-ответ", голоссарий, спецификации с артикулами на все компоненты. И это всё - не для галочки, а чтобы инженер на месте мог разобраться, понять, как устроена система, и быстро решить любую задачу.
Плюс - комплекты ЗИП для быстрой замены "железа" и резервное ПО для восстановления. Всё, чтобы вы не зависели от нас и могли оперативно обслуживать систему сами.
Ваш технологический суверенитет.
Где это всё работает сегодня
Большая мегаферма
Мы не продаём напрямую конечным заказчикам — мы, как производители, работаем через дилеров и интеграторов, которые сами выбирают, с кем им работать. И они выбирают нас. Потому что им удобно с нами. Потому что техподдержка и сервис работает.
Наши «Операторы» уже управляют навозоудалением, микроклиматом, КНС, сепарацией и дезинфекцией на крупнейших фермах России. Более 1000 единиц оборудования в поле.
Мы входим в технологический стек мирового лидера в поставках комплексных решений для мегаферм. Мы не имеем права разглашать название партнёра без его прямого согласия — это условие нашего сотрудничества. Но если вы работаете в отрасли, вы знаете, о ком речь
И у нас есть рекомендательные письма от Росатома. Это не про фермы. Это про уровень требований к контрагентам.
Что дальше
Было ли это божественное вмешательство?
Мы рады, что получили подобный результат и нам приятно рассказать, какие вещи можно делать самостоятельно на уровне мировых лидеров - это оказалось возможно. Нам, конечно, повезло в том, что удалось сразу тестировать системы на огромных предприятиях, хоть такая возможность и появилась не на ровном месте - в прошлом посте я рассказывал, что мы уже долго время занимаемся автоматизацией, было не просто, но обстоятельства сложились благоприятные.
Мы не останавливаемся. У нас есть собственное производство, своя механообработка и SMD-монтаж. С партнёрами мы можем выпускать до 10 000 плат за три недели, и у нас есть складской запас комплектующих, чтобы не ждать поставок.
Мы научились оперативно и эффективно внедрять наш программно-аппаратный комплекс в сложные технологические процессы.
И мы не замыкаемся на одной нише. Мы идём туда, где сложные техпроцессы либо не решаются вовсе, либо решаются через изысканно сложные и дорогие конструкции - мы приходим и делаем проще, надёжнее и эффективнее. Без фантастических бюджетов и нейросетей там, где они не нужны.
Например, в диагностике конвейерных лент на шахтах - там, где пытаются ставить машинное зрение, мы видим более простые и надёжные подходы.
Если хотите узнать, какие отрасли мы сейчас рассматриваем, что рассматриваем изменить в технических характеристиках и ПО, где видим границы применения наших ПАК — пишите в комментарии. Отвечу на всё.
Народ, никто не знает, чьи по итогу ПЛК (программируемый логический контроллер) и ПР (программируемое реле) Овен? Нашел один в один у немцев, даже предлагают свой лейбл под заказ напечатать на корпусе. И среда разработки, проекты от Овен ПР тоже кушает спокойно. Не могу понять, то ли наши так в Германии продают, то ли общий китайский “предок”.
Шестьсот тридцать восьмая история о создании российского ПЛК - аналогов, ясное дело, нет. Внутренности.
Путь в промышленную автоматизацию для нас начался с систем диспетчеризации для жилых комплексов. Это был интересный опыт, но по сути — работа с короткими линиями, слабыми сигналами и в «чистой» электромагнитной обстановке.
Когда решили перейти в настоящую промышленность — автоматизацию молочных ферм, — мы взяли проверенные модульные контроллеры, которые отлично работали в жилых комплексах, рассуждали просто: они работают, значит, справятся. Установили их на системы навозоудаления, микроклимата и насосные станции...
И сожгли 20 двигателей. Сломали 16 редукторов.
Платы не выдерживали помех от частотников. Контроллеры теряли сигналы с энкодеров, датчиков окружающей среды. Модули ввода-вывода «сходили с ума» от скачков напряжения на длиннющих линиях. Заказчики были в шоке, мы — в "лёгкой панике" (прим. ред.).
Но мы сделали выводы. И поняли: чтобы работать в промышленности, нужно делать ПЛК самим. С нуля (или с ноля). Под наши задачи, под наши условия.
К тому моменту у нас уже был серьёзный бэкграунд: мы занимались пусконаладкой оборудования мировых лидеров на крупнейших фермах страны. Мы уже конструировали ПЛК, но глубоко в тему не погружались. Однако, работая с разными системами, мы накопили опыт и имели возможность наглядно сравнивать их между собой. И чем больше мы сравнивали, тем яснее видели: готовые решения местами хромают. Мы приближались к идее сконструировать качественный ПЛК...
...с исчерпывающим функционалом...
...который сразу удалось протестировать в экстремальных условиях.
Выбрали самые лучшие компоненты, перебрали схемотехнику, нашли правильные решения по защитам, скомпоновали. И родился ПЛК «Оператор» — контроллер, который выдерживает то, что убивает импортные (да и что уж таить - отечественные) аналоги (кэмон ты выше писал что аналогов нет!? wat?).
Готовое ПО не требует программирования. Ферма получает алгоритмы мировых лидеров с апгрейдом, в веб-интерфейсе, с настройками под любой тип оборудования. А железо, как показала практика, надёжнее многих именитых брендов — аппаратная самодиагностика, 50 мс запуск ядра после сбоя питания (200 мс с полным запуском Wi‑Fi) против ручного перезапуска у DeBoer, например, мощная зона питания, защита от импульсов и помех.
Ночная смена
Сегодня наш «Оператор» управляет навозоудалением, микроклиматом, дезинфекцией доильных аппаратов, насосными станциями и сепарацией навоза на крупнейших фермах.
Сейчас мы полностью локализовали в России производство автоматизированных систем для молочных комплексов — Единая цифровая платформа управления фермой: от скреперов и сепараторов до дезинфекции, интеграции с доильными залами, системами управления стадом. И продолжаем делать ПЛК, которые не ломаются.
P.S. На днях записался на конкурс, с мечтами о логотипе от великого и ужасного таланта - @logotipper и решил, что это подходящий момент немного рассказать о себе.
Спасибо, что дочитали до сюдова 🤝
Немного интерактива:
Что вы думаете о российских ПЛК, стоит ли дальше рассказывать про схемотехнику, технические детали, реальные кейсы, битвы за реестры и реальную поддержку высокотехнологичного производства?
муу!
Пишите в комментариях, нам правда интересно, что вам откликается. Нам есть что рассказать — от пайки плат до пусконаладки на фермах, где вас могут зализать в клочья встретить коровы. 🐄
На одном из предприятий Москвы купили такой станок 2Д450 по цене металлолома, за 300к кажется. Железо вроде нечего, более или менее живое а вот электрике полный трындец. Шпиндельный мотор с приводом умерли и запустить их не удалось, приводы подач кое как ёрзали.
Сначала приобрели сервопривод от Балт-Систем на место шпиндельного мотора и простенький ПЛК DELTA для того чтобы, после того как я их интегрирую в старую схему на станке можно было хоть как-то попробовать работать.
Прошло какое-то время и руководство всё таки решило немного вложиться и полностью заменить систему управления станком ( всё это время станочник на станке работал как обезьяна из-за того что приводы подач работали не пойми как и помимо того что нельзя было поймать необходимую подачу так она ещё и могла самопроизвольно меняться во время работы хD )
Итак, я начал проект модернизации, подобрал контроллер (ПЛК), новые сервоприводы в количестве трёх штук, ручной моховичок и сенсорный экран (HMI). Заказал. Нарисовал новый пульт в CorelDRAW и заказал изготовление. Пока всё это ехало разработал принципиальную электрическую схему и дозаказал все необходимые электротехнические изделия, кабеля и провода. После того как приехал контроллер и все остальные дорогие прибамбасы приступил к написанию электроавтоматики и запуску движков с контроллера через экран, по EtherCAT с помощью MotionControl на столе. Следом собрал шкаф управления и проводку по станку.
В итоге всё получилось на отлично. Можно выбрать любую подачу, мы даже сверлили на нём сверлом диаметром 0.5мм с ооооочень медленной подачей чтобы не сломать (регулировка подач стала иметь более широкий диапазон в сравнении с оригинальной системой управления).
Подача задаётся на экране для каждой оси в мм\мин и при этом на пульте существует корректор подачи (потенциометр) для того чтобы можно было на ходу регулировать подачу в меньшею сторону. С оборотами шпинделя всё тоже самое. Также на пульте отображается нагрузка на оси и шпиндель, коэффициент корректоров, положение осей по линейкам и скорость вращения шпинделя. Также осями можно управлять в режиме ручного маховичка т.е. на каждый щелчок моховичка ось будет проезжать заданное расстояние. Также на станке реализован режим MDI в двух вариантах, абсолютном и относительном (abs и rel). При выборе заданных координат на все три оси и нажатии кнопки "кадр пуск" оси поочерёдно будут выведены в заданные позиции, сначала "Х", затем "Y", затем "Z". Так же можно по одной или двум осям, оси поедут в упомянутом выше приоритете.
Существуют меню диагностики через которые можно посмотреть состояния дискретных входов и выходов, состояние аналоговых входов и выходов, показания энкодеров и меню с настройками некоторых параметров станка.
Если это кому-то интересно, то задавайте вопросы )
Привет, Пикабу! Честно говоря, не знаю насколько тут популярна техническая тематика, но я все-таки попробую представить вам небольшую статью о моем Modbus терминале.
Я знаю, опытные инженеры не раз видели такие заголовки и, возможно, сами писали подобные приложения. Но... тогда почему я постоянно сталкиваюсь с нехваткой хорошего инженерного софта? :) Хотя с другой стороны, небольшой и весьма консервативный рынок способствует дальнейшему дефициту решений...
Где-то года четыре назад я начал замечать за собой, что пишу очень много одноразовых или временных приложений для отладки, тестирования или изучения какого-либо оборудования. Также на моем рабочем ПК стояло около пяти разных терминалов. Каждый из них был удобен в своих сценариях. И не было среди них того, который закрывает хотя бы половину потребностей.
Тогда то я принял решение написать свой велосипед костыль вариант Modbus терминала.
Внешний вид приложения. Режим "Modbus"
Итак, а что же умеет мой терминал?
Вот его основные возможности:
Три режима работы: "Без протокола", "Modbus" и "Modbus мониторинг".
«Без протокола»:
Работа с данными в строковом или байтовом формате.
Поддержка разных кодировок.
Три режима отправки: одиночная, цикличная, отправка файла.
“Modbus”:
Поддержка различных вариаций протокола Modbus: TCP, RTU, ASCII и RTU / ASCII over TCP.
Удобная работа с функциями записи.
Возможность работы с числами типа float.
Возможность работы с бинарными данными.
Modbus сканер, который осуществляет поиск устройств на линии связи.
"Modbus мониторинг":
Удобное отображение регистров.
Конвертация в числовые типы (Int16/32, float, и др.).
Преобразования по заданной формуле.
Построение графика в реальном времени.
Логгер.
Макросы:
Отдельные макросы для каждого режима работы.
Макрос состоит из неограниченного количества команд (действий).
Для Modbus макросов предусмотрена возможность выставления общего Slave ID для всего макроса.
Импорт и экспорт макросов.
Темная и светлая темы приложения.
Пресеты с пользовательскими настройками.
Руководство пользователя.
Кроссплатформенность: Windows, Linux.
Хорошо, а почему его можно назвать универсальным? Какие потребности он закрывает?
Глобально тут есть несколько режимов работы. И чтобы ответить на вопрос обсудим каждый режим по подробнее.
Режим "Без протокола"
Это по сути обычный "сырой" терминал. Работает со строками и байтами. Полезно, когда нужно вручную сформировать пакет, поработать с не Modbus протоколом, отладить какое-то внешнее устройство, воспроизвести баг и т.д.
Есть три режима отправки: одиночная, цикличная и отправка файлов.
Режим "Без протокола"
Режим "Modbus"
В этом режиме приложение значительно упрощает пользователю работу с протоколом Modbus. А также позволяет более детально рассматривать пакеты. Работает через запрос - ответ. Удобно использовать для изучения, отладки или управления подключенным устройством.
Режим "Modbus" в светлой теме
Отдельно хочу отметить возможность переключения между темной и светлой темой.
Как по мне это чуть ли не киллер-фича. Объясню почему. Лично мне удобнее работать в темной теме. Так мои глаза меньше утомляются, и чувствую я себя лучше. Но как мы знаем не все приложения поддерживают темную тему (привет, CODESYS). И поэтому когда огромное черное окно терминала из раза в раз появляется на фоне светлой IDE... глаза устают еще больше. А если еще и в помещении недостаточно света, то это просто жуть... В идеале, все приложения на экране должны быть на одном уровне яркости. И переключение тем оформления в моем терминале может помочь сохранить здоровье ваших глаз.
Но вернемся к режиму "Modbus".
Как вы видите, внизу есть четыре разных вкладки. В них удобно просматривать содержимое запроса-ответа.
Визуализация данных Modbus
Также в этом режиме есть удобный Modbus сканер, который ищет подчиненные устройства на линии связи.
"Modbus мониторинг"
Специальный режим, предназначенный для визуального контроля подключенного устройства. Удобно использовать для контроля показаний датчиков или контроля состояния внешнего устройства. В этом режиме приложение может работать и в качестве логгера.
В этом режиме отображаются регистры Modbus. Значения регистров обновляются с заданным периодом. Полученные данные можно легко преобразовать: выбрать тип, применить формулу и отобразить результат в удобном виде или на графике.
Режим "Modbus мониторинг"
Мне иногда пишут пользователи. Задают вопросы, предлагают добавить что-то новое или доработать старое. Я всегда с интересом общаюсь. И вот идею этого режима меня просили реализовать довольно давно. Формировалась эта идея по-разному. В том числе и у меня в голове. И вот в конце прошлого года я наконец-то сформировал все идеи во что-то цельное и приступил к реализации. Результат выпустил в релиз буквально на днях.
Из красивых картинок касательно этого режима могу приложить еще разве эту)
Построение графика в реальном времени в режиме "Modbus мониторинг"
Макросы
Позволяют удобно собрать несколько действий в одну команду. Можно использовать как решение для автоматизации каких-то процессов: сложной инициализации устройства, управление группой оборудования и т.д.
Рабочее поле макросов (сверху) и окно редактирования макроса (снизу)
Как видно каждый макрос состоит из неограниченного количества команд. Команда - это отправка одного сообщения. В окне редактирования, команды можно отправлять по отдельности.
Расскажу пару случаев из свой практики, когда этот режим макросов мне очень пригодился.
Случай №1
Однажды, мне доводилось писать ПО для небольшого станка. ПЛК управлял группой оборудования: клапаны, задвижки, датчики и прочее. Первым делом, я определился с внешним API (если прям по-айтишному), т.е. с определением регистров Modbus, которые торчали наружу. А затем начал писать внутреннею логику. Для тестирования всего этого дела, а также для наладки оборудования я накидал несколько макросов, чтобы железяку можно было протестировать, до того момента, пока появится полноценное клиентское приложение.
P. S. просто брать и менять значения регистров в CODESYS оказалось неудобно и муторно. Проще нажать одну кнопку в макросе.
Случай №2
Однажды у нас в цеху у одного из станков вышел из строя контроллер серводвигателя. Это было печально, т.к. продукция этого станка была очень необходима. Что делать? Может просто купить в первом доступном магазине? Может даже в "Чип и Дип"? Ха-ха, так просто ничего не бывает, даже если цена вопроса не очень большая. Поэтому пока героическими усилиями отдела закупок (или как-то так) проводилась спецоперация по покупке нового оборудования, а затем с помощью не менее героических усилий механиков проводилась интеграция этого оборудования. Наш станок на протяжении n-ого количества времени (может недели, может месяцы, кто знает...) проработал с найденным где-то в старых запасах другим похожим контроллером. Естественно, у родного и подменного контроллеров карта регистров не совпадала. И в качестве временного решения, оператор использовал макросы для управления двигателем.
Видеоролики
Иногда вместо тысячи слов, лучше посмотреть пару коротких видео с демонстрацией работы приложения.
Вот тут можно посмотреть о режиме "Modbus мониторинг":
Я надеюсь, вам понравилась моя первая публикация на Пикабу. Будет здорово, если мое приложение CoreBus окажется вам полезным. Не забывайте обращаться к встроенному руководству пользователя.
Проект развивается благодаря обратной связи от пользователей и пожертвованиям, которые вы можете сделать, перейдя по этой ссылке:
На протяжении нескольких месяцев я делюсь историей и подходами решению задач собственной разработки промышленного контроллера. Вернее - платформы для разработки ПЛК на подобии Codesys. Название моего проекта 3o|||sheet (читается как - Зошит).
Вот чтоб сразу было понятно - я не создаю физические ПЛК. Часто пишут про помехоустойчивость, Arduino/ STM32 не под 24V и прочее. Codesys - не продают ПЛК и не создают железо (насколько я знаю) это программная платформа которую устанавливают в - свое железо производители ПЛК. У меня тот же случай.
Моя разработка это: Среда IDE , с собственным графическим движком отрисовки схем. Cвой компилятор (самая сложная и умная часть). И среда выполнения на железе (самая примитивная часть - за нее все думает компилятор на этапе сборки.
Разрабатываю - программную часть, так как считаю что надежность и экосистема программной работы это 99% успешности проекта.
Работа до создания ПЛК и откуда истоки и идеи.
Лет 6 назад, когда работал инженером - системным программистом на крупном предприятии я и познакомился с большим производством. Большое количество угольных шахт раскиданных на многие километры. Десятки подземных комбайнов , тысячи гидравлических стоек, все это генерировало миллионы значений в сутки. Системным программистом я был плохим (вернее - системным администратором), другое дело - поиск и разработка алгоритмов по визуализации всех этих миллионов значений с OPC серверов на экране.
Gatherlog (Гезерлог)- моя SCADA и система диспетчеризации.
Стоит отметить, у меня два образования, это университет, инженерно-технический, приборостроения. И Художественный институт - живопись графика. Разработка графических визуализаций - моя естественная работа, которую я лучше знал со старта (минимум программного опыта), чем более опытные разработчики с десятками лет стажа. Все это и вылилось в в последствии разработку собственного графического движка для визуализации промышленности.
Мой проеккт Gatherlog (.Net Core) можно разделить на функционал:
1) набор абстракций и правил, по управлению графикой - данными с оборудования. подходит дл абсолютно любого оборудования и любой сложной анимации (кроме физики конечно). Есть примитивы движений (перемещение, вращение, моргание, изменение размера, смена кадров- ваританты), комбинируя эти примитивы (как матрешку, друг в друга) можно добиться любого сложного движения. Не только анимировать шкалу деления но и сложные манипулятор роботов с любым количество состявляющих.
2) Система отчетов по работе оборудования и общих отчетов (работа/простои / обычные графики)
3) интерпретатор работающий в SCADA позволяющий выполнять алгоритмы написанные пользователем (то есть, превращает SCADA в серверный ПЛК). В последствии эти практики я оптимизировал до уровня микроконтроллера.
4) Работа с базами данных
Если брать WEB разработку, то сам движок реализованный так же на Javascript занимает всего лишь 500 строк кода. Хотя как то встречал компанию, которая делала визуализации, применяя полноценный игровой Unity 3D ! для подобного.
В самой первой статье по разработке ПЛК я упоминал что являюсь ценителем оптимизации, всегда искал закономерности в процессах чтоб вывести общую формулу на подобии y=x+2(sqrt(Ad^2 ... А не использовать if/else на все варианты. Поэтому, что касается логики, у меня программа всегда занимаала меньше строк кода чем у других.
Все эти наработки и графическая библиотека в последствии перешла в нативную разработку среды программирования для ПЛК (LD FBD, схемы). А графический движок реализован на C# , Java, WinAPI, и подготавливаю его для Микроконтроллеров способного работать на небольших дисплеях.
В данном посте не все описано, но я периодически буду публиковать те или другие моменты по разработке.
По разработке ПЛК - в прошлых постах все описано (особенности, возможности и т.д), кому интересно.
И помни дорогой друг. Любая "поделка" становится "настоящей" если ее выпускает юридическое лицо. (с) Я.
Задавайте вопросы в комментариях и на почту: zoshytlogic@gmail.com
Будем считать, что у вас всё установлено. По установкам ПО можно найти документацию и мануалы.
Настройки в ПЛК с CODESYS 3.5
Суть следующая - нам нужно сделать ПЛК с Modbus TCP Slave. В моем случае ПЛК200 использует оба порта Ethernet. 1 опрашивает модуль - является мастером. 2 порт работает в режиме Slave. Для того чтобы работал 2 порт в режиме LAN нужто зайти в его веб-настройки и отконфигурировать.
Дальше добавляем модуль Ethernet.
Нужно связаться с ПЛК и выбрать по какому порту ему отдавать.
Выбираем преднастроенный порт.
Добавляем устройство.
Выбираем TCP Slave.
Далее залезаем в его настройки, вводим количество регистром и ставим галочку на запись, если нужно read\write.
Во вкладке соотнесение входов выходов вносим переменную. Переходим на следующий этап.
Настройки в SCADA SimpLight 5
Далее работаем со SCADA. Будем считать, что она скачана, установлена и запущена Среда разработки.
Список различных драйверов. Выбираем напрямую Modbus Драйвер, заходим в настройки.
Настраиваем Узел. В моем случае IP 192.168.1.10.
Вносим тег. У ПЛК 200 в режиме TCP Slave адресация начинается с 0.
Перетаскиваем теги в Проект.
Прежде чем запускать сервак. Нужно для него создать профиль и нажать птичку, что именно этот сервер мы используем.
После этого сохраняем проект и запускаем сервер.
Ставим маленькие галочки - чего опрашивать, зеленую стрелочку Пуск. И наблюдаем ТРИ топора, и что вообще чё то включено.
