VsyaAvtomatica

Любая инженерная задача становится интереснее, когда заказчик в конце разговора добавляет:
- А еще хотелось бы…

Ответ в таком случае всегда один «Сделаем!». И после него начинается увлекательный процесс изобретения велосипеда, мозговых штурмов и технических изысканий.

Для нас такой задачей в свое время стала автоматическая подпитка системы отопления.
Что это и зачем это нужно?

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

В простом виде это может быть, например, клапан и электроконтактный манометр (ЭКМ. Все что можно сократить – сокращай. Закон стройки номер 1.) Схема простая до неприличия: ЭКМ фиксирует снижение давления до нижнего предела, контакт замыкается и напрягает клапан на линии подпитки. Клапан открыт до того момента, пока давление не достигнет верхнего предела на ЭКМ и контакт не разомкнется.

Но у такого решения есть БОЛЬШОЙ минус: ЭКМ и клапану совершенно до лампочки как долго они будут подпитывать систему отопления. Т.е. в случае серьезного прорыва в системе отопления, клапан откроется и будет качать воду либо пока она не закончится в водопроводе, либо пока не отработают защитные автоматы, залитые водой, и не отключат все напряжение в доме.

Действительно большой минус такой простой системы, так ведь?

Не имея желания допускать даже теоретической возможности превращения дома заказчика в аквариум (он ведь нас о таком не просил), мы пошли другим путем.
В нашей схеме так же есть ЭКМ и клапан, но вот основную логику работы контролирует ПЛК (программируемый логический контроллер).

В логику работы ПЛК были зашиты две защитных функции.
Функция 1: Таймер
Таймер следит за тем, чтобы клапан подпитки не был открыт более 2-3 минут. Если за 2-3 минуты давление не достигло нужного значения, то имеет место серьезная течь и подпитывать больше нельзя. Системы уходит в аварийный останов до ручного сброса.
Функция 2: Счетчик
Счетчик контролирует, чтобы подпитка не срабатывала чаще 3 раз за час. На четвертый раз также останов до ручного сброса. Я описывал выше, что автоподпитку имеет смысл делать только тогда, когда давление медленно и неуловимо (аки тот самый Гонсалес) стравливается, а если оно опускается до критического значение больше трех раз за час, то срочно ищите какая комната превращается в филиал ООО «Атлантида».

И приятный бонус такой автоматизации: все действия ПЛК передаются в контроллер «умного» дома и приходят владельцу посредством СМС или ПУШа. С ЭКМ+клапан мы не можем знать когда и как часто срабатывала подпитка и что вообще с давлением. С ПЛК+ЭКМ+клапан+умный дом мы в курсе как текущего состояния системы, так и количества и регулярности срабатывания подпитки.

Уф! Пока писал, сам понял, как это работает.

Что думаете о таком решении и как вы в целом относитесь к автоматической подпитке?
Если используете, то на обычном ЭКМ/редукторе или тоже добавляете какую-то защиту?
Отпишитесь в комментариях – интересно посмотреть какие есть мнения и какие решения прижились у других.

P.S.
Вывод №1
При решении любой задачи нужно думать не только о том, как всё должно работать, но и о том, что будем делать, если что-то пойдет не по плану. А не по плану обязательно рано или поздно пойдет.

Привет, мир!
Это инженерный блог компании «ВсяАвтоматика». По какой-то тактике, которая у нас есть и которой мы будем придерживаться, мы (в больше степени лично я), решили рассказать наконец-то всему миру в общем и вам в частности чем мы вообще занимаемся каждый будний день с 9:00 до 18:00 вот уже 8 лет. Или около того…
А занимаемся мы (только не удивляйтесь сильно) автоматикой. В основном автоматизацией систем отопления в частных загородных домах. Реже, к сожалению, автоматизацией и диспетчеризацией коммерческих и промышленных объектов.
Основной «продукт» - шкаф автоматики. Например, вот такой:

Или вот такой:

Разные в общем. Как по внешнему виду, так и по задачам, которые они решают.
К сути.

Шкаф автоматики – это не наше изобретение. Как сущности, им наверное уже лет 126. Но к нашим шкафам автоматики мы, не читая инструкций и мануалов, пришли своим опытом и своими руками и мозгами, путем проб и ошибок. Не смотря на то, что у многих в нашей команде есть высшее образование, у некоторых даже техническое и не одно, многие решения, утвержденные ГОСТами, ТРТСами и ПУЭ, стали нами реализовываться далеко не сразу.

С какого… или иначе говоря, почему вообще мы начали делать шкафы автоматики?

В далеком уже 2017-18 году наш спецотряд по автоматизации занимался установкой систем, как говорят, «умного» дома. В 99,9…% случаев тогда мы использовали ectoControl. Выглядело это чудо устройство в тогдашней ревизии вот так:

Этот «модем», представляющий из себя центральный хаб всей системы, имел на своем борту три встроенных реле с возможностью подключения дополнительных блоков по 10 реле и различных датчиков, типа температуры, протечки, газа и т.д.
В целом встроенных трех реле вполне хватало для управления примитивными котельными в «бабушкатниках». Монтировать устройство можно было (да и сейчас можно) прямо на стену, не заморачиваясь с щитком или боксом.
Если трех встроенных реле было недостаточно, устанавливался блок расширения на дополнительных 10 реле. Тогда вот такой:

Собственно, отсутствующие тогда вкус к технической эстетике и насмотренность, давали право также монтировать это устройство прямо на стену. Но где же тогда порылась собака и откуда появилась шальная идея собирать какие-то «шкафы» автоматики?
А весь вопрос был в программных ограничениях самого контроллера. Его программы управления были, как это называется в терминологии самого ectoControl, одноконтурными. Т.е. каждое реле, управляемое своей программой, никак не было, не могло быть и более того на тот момент (как считалось) не хотело быть связано с другими реле и программами. Нам это не нравилось, так как приводило к серьезным ограничениям и допущениям. А так же ограничивало нашу зону работы – фактически, мы могли работать только в «бабушатниках» с простыми системами отопления. Пусть на более интересные объекты с хотя бы тремя контурами отопления был нам заказан.  
Допустим, в котельной частного дома было четыре объекта управления: котел, насос контура отопления 1 этажа, насос контура отопления 2 этажа и насос загрузки бойлера косвенного нагрева (далее БКН). Учитывая интровертность программ управления, все эти четыре объекта управлялись и работали по своим датчикам, никак не учитывая желания друг друга. Иначе говоря, котле грел теплоноситель не потому, что этого хотели контура отопления или контур загрузки БКН, а потому что ему сказали греть теплоноситель. Или, например, контура отопления 1 и 2 этажа и знать не знали, что в момент включения контура загрузки БКН, им вообще-то следует выключиться, повинуясь принципу «приоритета БКН», а не продолжать молотить, будучи ведомыми запросами лукавых датчиков температуры воздуха.
Пободное функционирование автоматики отопления не-пра-виль-но-е. Да, пром. контроллеры решили бы данную задачу на раз-два-три, но, напомню, мы работали в сегменте ИЖС. Там такие контроллеры не проходили (да и сейчас не проходят) ни по цене, ни по юзерфрендливости, ни по функционалу, который у пром.автоматики избыточен для ИЖС. А в 2018 н один доступный на рынке РФ «бытовой» контроллер умного дома с подобными задачами нормально справится не мог. По крайней мере мы так думали.
И вот для решения подобных задач и была привнесена в нашу работу великая релейная логика. Тоже, если что, не наше изобретение. Тут руку приложили славные предки, коим в отсутствии микропроцессоров, приходилось на этой релейной логике собирать и запускать вообще все.
Собственно вот пример одного из первых шкафов автоматики в нашем исполнении:

Количество шакалов на фото превышает все мыслимые пределы – прошу не серчать. Архивные фото по уважительной причине лени не нашел. Использовал скрины из архивного видео.

Чего удалось добиться?
С применением релейной логики мы обошли программные ограничения контроллера и заставили котел работать только тогда, когда работал один из контуров. Как это работало?

QF – автомат
W1.х – реле ectoControl
KL – промежуточное реле
xt – клеммы

Кстати, первые несколько лет шкафы мы собирали без схем и без маркировки кабеля, ибо зачем? Шкафы примитивные, однотипные и вряд ли придется что-то когда-то в них переделывать. Так мы думали тогда. Спойлер: мы ошибались. Но об этом в другой раз.

Что видно (я надеюсь, что видно) из схемы.

Реле W1.1-1.3 используются в программах ectoControl и в нужный момент подтягивают катушки промежуточных реле KL1-3. Те, в свою очередь, одной группой контактов подают напряжение на клеммы, а второй группой контактов замыкают «сухой» контакт котла.
Таким образом, котел греет теплоноситель только тогда, когда есть «запрос» от какого-то контура.

Кроме того, KL3, отвечающее за насос загрузки БКН, снимает напряжение с KL1-2, когда этот самый БКН «загружается». Вот и «приоритет БКН» подъехал.

На тот момент для нас это был настоящий прорыв. Мы не знали, что изобретенная нами релейная схема известна всем и каждому и считали себя молодцами. В общем-то, на своем уровне развития мы ими и были.

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

А пока все. И так длиннопост получился.

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

На связи.