Любая инженерная задача становится интереснее, когда заказчик в конце разговора добавляет: - А еще хотелось бы…
Ответ в таком случае всегда один «Сделаем!». И после него начинается увлекательный процесс изобретения велосипеда, мозговых штурмов и технических изысканий.
Для нас такой задачей в свое время стала автоматическая подпитка системы отопления. Что это и зачем это нужно?
В теории, давление в закрытой системе отопления должно быть стабильным. И если оно снижается, то нужно искать течь и чинить. Но на практике бывает так, что течь найти не удается. Чаще всего сопливит какое-нибудь резьбовое соединение – трубы горячие и капли высыхают до того, как соберутся в видимую лужу. По капельке в час и за неделю-полторы давление в системе опустится до критически низкого и котел просто встанет. Вот именно в этом случае устанавливается система автоматической подпитки.
В простом виде это может быть, например, клапан и электроконтактный манометр (ЭКМ. Все что можно сократить – сокращай. Закон стройки номер 1.) Схема простая до неприличия: ЭКМ фиксирует снижение давления до нижнего предела, контакт замыкается и напрягает клапан на линии подпитки. Клапан открыт до того момента, пока давление не достигнет верхнего предела на ЭКМ и контакт не разомкнется.
Картинка из тырнета. Предположительно, реле давления открывает клапан подпитки.
Но у такого решения есть БОЛЬШОЙ минус: ЭКМ и клапану совершенно до лампочки как долго они будут подпитывать систему отопления. Т.е. в случае серьезного прорыва в системе отопления, клапан откроется и будет качать воду либо пока она не закончится в водопроводе, либо пока не отработают защитные автоматы, залитые водой, и не отключат все напряжение в доме.
Действительно большой минус такой простой системы, так ведь?
Не имея желания допускать даже теоретической возможности превращения дома заказчика в аквариум (он ведь нас о таком не просил), мы пошли другим путем. В нашей схеме так же есть ЭКМ и клапан, но вот основную логику работы контролирует ПЛК (программируемый логический контроллер).
В логику работы ПЛК были зашиты две защитных функции. Функция 1: Таймер Таймер следит за тем, чтобы клапан подпитки не был открыт более 2-3 минут. Если за 2-3 минуты давление не достигло нужного значения, то имеет место серьезная течь и подпитывать больше нельзя. Системы уходит в аварийный останов до ручного сброса. Функция 2: Счетчик Счетчик контролирует, чтобы подпитка не срабатывала чаще 3 раз за час. На четвертый раз также останов до ручного сброса. Я описывал выше, что автоподпитку имеет смысл делать только тогда, когда давление медленно и неуловимо (аки тот самый Гонсалес) стравливается, а если оно опускается до критического значение больше трех раз за час, то срочно ищите какая комната превращается в филиал ООО «Атлантида».
И приятный бонус такой автоматизации: все действия ПЛК передаются в контроллер «умного» дома и приходят владельцу посредством СМС или ПУШа. С ЭКМ+клапан мы не можем знать когда и как часто срабатывала подпитка и что вообще с давлением. С ПЛК+ЭКМ+клапан+умный дом мы в курсе как текущего состояния системы, так и количества и регулярности срабатывания подпитки.
Уф! Пока писал, сам понял, как это работает.
Что думаете о таком решении и как вы в целом относитесь к автоматической подпитке? Если используете, то на обычном ЭКМ/редукторе или тоже добавляете какую-то защиту? Отпишитесь в комментариях – интересно посмотреть какие есть мнения и какие решения прижились у других.
P.S. Вывод №1 При решении любой задачи нужно думать не только о том, как всё должно работать, но и о том, что будем делать, если что-то пойдет не по плану. А не по плану обязательно рано или поздно пойдет.
Привет, мир! «ВсяАвтоматика» продолжает придерживаться какой-то тактики и рассказывать о своей работе. В прошлом посте мы коротко рассказали о том, как мы дошли до жизни такой до сборки щитов/шкафов автоматики и зачем они понадобились. В этом продолжим развивать эту же тему.
После освоения релейной логики сама собой родилась логичная идея подстелить соломинку и «изобрести» байпас. Раз в год и палка стреляет и даже супер надежная автоматика нет-нет да захандрит – контроллер потеряет связь с реальностью, катушка реле решит, что с нее хватит и т.д. А автоматика-то наша управляет не ерундой какой-нибудь – остаться без отопления в -20 ой как не приятно. И т.к. инженеры наши еще (почему-то!) не освоили навык мгновенного перемещения на объект для устранения неисправности, решено было добавить «аварийный» выключатель, который бы приводил в движение все объекты управления. Выглядела тогдашняя схема либо вот так:
Схема с байпасом через НЗ-контакты релейного блока. Катушку KL2 забыл подписать.
Роль выключателя «байпас» в данном случае выполняет авт. выключатель QF2. При его включении подается напряжение на НЗ-контакты релейного блока и катушки всех промежуточных реле подтягиваются принудительно при любом положении реле релейного блока. (реле много не бывает) Минус такой схемы очевиден – при неисправности самого релейного блока и необходимости его из шкафа изъять, автомат QF2 становится бесполезен и в любом случае требуется перекоммутация для аварийного запуска устройств.
Промежуточное решение на схеме 2:
Схема с байпасом через отдельное реле. Катушку KL2 не забыл подписать.
В этом случае автомат «байпас» уже подтягивает катушку своего реле, которое принудительно отправляет напряжение напрямую на промежуточные клеммы. Плюсы: «байпас» работает в обход релейного блока и реле. Можно пол шкафа отправить в отпуск, а все устройства продолжат работу. Минус: все контура (или насосы, или приводы, или чем бы мы не управляли) включаются одновременно. Решение пришло позже, об этом ниже.
В прошлом посте мы писали, что у первых шкафов не было схем даже в теории. Во-первых, щиты были редким явлением. Во-вторых, устройство их было до того примитивным, что схематическое их начертание казалось тратой времени.
С развитием и усложнением шкафов мы начали чертить схемы в программе DipTrace – САПР изначально для печатных плат. Под наши задачи и руки эта программа настолько хорошо подошла, что за годы работы мы отрисовали собственноручно все нужные нам компоненты и до сих пор работаем только с ней.
Вот как выглядит сегодняшняя схема щита в его естественной среде:
DipTrace - САПР для проектирование печатных плат и чего еще вашей душе угодно.
Вариант сервировки. Одна из последних схем.
Кстати, на втором скрине видно, до чего эволюционировала история с «байпасом» - аварийный переключатель ставится на каждый контур. Переключатель на три положения – «авто», «откл.», «вкл.».
С таким подходом получилось обеспечить: 1. Удобное ручное управление в «случае чего» 2. Селективность в ручном режиме 3. Высокий уровень ремонтопригодности шкафа – хоть всю автоматику из него вытащи и управляй себе с переключателей. Ничего менять по коммутации не нужно.
Чуть не забыл про индикаторы написать – их тоже теперь ставим на все контура, насосы, котлы и т.д. С точки зрения управления в них нет никакой необходимости. А вот в случае какой-либо неисправности они весьма облегчают жизнь инженеру. Что думаете?
К чему еще пришли в процессе развития: 1. В первую очередь – схема. Даже самый простой и типовой щит не собирается без схемы. Схема сохраняется, печатается, ламинируется, передается из поколения в поколение и оберегается серьезнее объектов всемирного наследия ЮНЕСКО. 2. Маркировать все, что можно промаркировать. Наборная маркировка на провода, наклейки на все реле, переключатели, блоки расширения. Все, что имеет место и номер в схеме, маркируется и в щите. 3. Сохранять все рабочие материалы – фото, видео, сметы, схемы, промежуточные варианты схем, наброски, файлы наклеек. Лет через 5, когда придет время обслуживать щит или клиент позвонит с каким-нибудь вопросом, это все очень выручит. Проверено и подтверждено собственными шишками. Самый неупорядоченный архив в сто раз надежнее человеческой памяти.
Маркировать нужно все.
Вообще все.
Так или иначе, текущий «гробик» выглядит уже вот так:
Анфас.
Внутренние органы.
«Гробиком» его ласково назвали коллеги-монтажники. Почему не понятно, но название прижилось. Кроме гробиков мы на сегодняшний день собираем автоматику в модульных навесных щитах, во встраиваемых, в двухметровых железных и вообще в чем только не собираем. Но обо всем этом расскажем на следующей неделе. Будет про современные щиты с подсветкой, в целом про возможности автоматики для частного дома и про живые объекты тоже расскажем.
На связи!
P.S. Если уж вы дочитали до сюда, то и в комментарии заглянуть не забудьте. Расскажите о ваших «ошибках» и изобретениях в процессе работы. Всегда интересно почитать, что изобрели рукастые люди.
И бонус в дополнение к первому посту – архивные фото первых шкафов:
Один из первых шкафов. Что делал - не вспомнить. Скорее всего чистая диспетчеризация. Седовласый юноша справа - Дмитрич.
Слева есть хоть какая-то маркировка. Уже хорошо) Почему справа убрали корпус контроллера - загадка. Наверное, так казалось технологичнее.
А вы как готовите спагетти? Я вот предпочитаю альденте.
Шестьсот тридцать восьмая история о создании российского ПЛК - аналогов, ясное дело, нет. Внутренности.
Путь в промышленную автоматизацию для нас начался с систем диспетчеризации для жилых комплексов. Это был интересный опыт, но по сути — работа с короткими линиями, слабыми сигналами и в «чистой» электромагнитной обстановке.
Когда решили перейти в настоящую промышленность — автоматизацию молочных ферм, — мы взяли проверенные модульные контроллеры, которые отлично работали в жилых комплексах, рассуждали просто: они работают, значит, справятся. Установили их на системы навозоудаления, микроклимата и насосные станции...
И сожгли 20 двигателей. Сломали 16 редукторов.
Платы не выдерживали помех от частотников. Контроллеры теряли сигналы с энкодеров, датчиков окружающей среды. Модули ввода-вывода «сходили с ума» от скачков напряжения на длиннющих линиях. Заказчики были в шоке, мы — в "лёгкой панике" (прим. ред.).
Но мы сделали выводы. И поняли: чтобы работать в промышленности, нужно делать ПЛК самим. С нуля (или с ноля). Под наши задачи, под наши условия.
К тому моменту у нас уже был серьёзный бэкграунд: мы занимались пусконаладкой оборудования мировых лидеров на крупнейших фермах страны. Мы уже конструировали ПЛК, но глубоко в тему не погружались. Однако, работая с разными системами, мы накопили опыт и имели возможность наглядно сравнивать их между собой. И чем больше мы сравнивали, тем яснее видели: готовые решения местами хромают. Мы приближались к идее сконструировать качественный ПЛК...
...с исчерпывающим функционалом...
...который сразу удалось протестировать в экстремальных условиях.
Выбрали самые лучшие компоненты, перебрали схемотехнику, нашли правильные решения по защитам, скомпоновали. И родился ПЛК «Оператор» — контроллер, который выдерживает то, что убивает импортные (да и что уж таить - отечественные) аналоги (кэмон ты выше писал что аналогов нет!? wat?).
Готовое ПО не требует программирования. Ферма получает алгоритмы мировых лидеров с апгрейдом, в веб-интерфейсе, с настройками под любой тип оборудования. А железо, как показала практика, надёжнее многих именитых брендов — аппаратная самодиагностика, 50 мс запуск ядра после сбоя питания (200 мс с полным запуском Wi‑Fi) против ручного перезапуска у DeBoer, например, мощная зона питания, защита от импульсов и помех.
Ночная смена
Сегодня наш «Оператор» управляет навозоудалением, микроклиматом, дезинфекцией доильных аппаратов, насосными станциями и сепарацией навоза на крупнейших фермах.
Сейчас мы полностью локализовали в России производство автоматизированных систем для молочных комплексов — Единая цифровая платформа управления фермой: от скреперов и сепараторов до дезинфекции, интеграции с доильными залами, системами управления стадом. И продолжаем делать ПЛК, которые не ломаются.
P.S. На днях записался на конкурс, с мечтами о логотипе от великого и ужасного таланта - @logotipper и решил, что это подходящий момент немного рассказать о себе.
Спасибо, что дочитали до сюдова 🤝
Немного интерактива:
Что вы думаете о российских ПЛК, стоит ли дальше рассказывать про схемотехнику, технические детали, реальные кейсы, битвы за реестры и реальную поддержку высокотехнологичного производства?
муу!
Пишите в комментариях, нам правда интересно, что вам откликается. Нам есть что рассказать — от пайки плат до пусконаладки на фермах, где вас могут зализать в клочья встретить коровы. 🐄
Водоподготовка есть, тоже на мне. С концом отопительного сезона установку отключаю, куб подготовленной воды есть. С началом отоп сезона включаю, потому что система отопления без теплообменника, и является продолжением котлового контура. Трубопровод промыт и опрессован своими силами, после промывки остаётся пустым, заполнение подготовленной водой ближе к отпительному, за пару недель заполняется - задвижка чуть приоткрыта
Привет, Пикабу! Честно говоря, не знаю насколько тут популярна техническая тематика, но я все-таки попробую представить вам небольшую статью о моем 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 окажется вам полезным. Не забывайте обращаться к встроенному руководству пользователя.
Проект развивается благодаря обратной связи от пользователей и пожертвованиям, которые вы можете сделать, перейдя по этой ссылке:
