МЕНЯ ОТВЛЕКЛИ ПО РАБОТЕ. ПРОДОЛЖУ ОПИСАНИЕ ЧУТЬ ПОЗЖЕ.
Здравствуйте друзья! в этой теме я хотел бы соорудить удобный в использовании, и подходящий большинству запросов вариант прибора, аналогичного по задачам ТРМ32, а в дальнейшем и ТРМ1032.
Группа разработчиков Овена уже представила свое видение обновленной линейки 232го - 1032, и я даже получил его на тестирование, но в виду того, что инструкцию они уже написали и переконфигурировать входы и выходы относительно инструкции они не планируют, да и ПО у них влезать перестало, то я решил написать собственное ПО.
Я думаю, что ни у кого не вызовет диссонанса выбор за основу ПР200.220.5.2.0.
24 вольтовый вариант не рассматриваю, поскольку нужен доп. блок питания на 24В, а во вторых сигналы 24VDC со временем, в условиях котельной/теплопункта имеют свойство переставать работать во внешних датчиках в следствие окисления контактов.
В итоге выношу на обозрение собственное ТЗ:
по чистому терморегулятору:
выделенные зеленым пункты я уже реализовал, выделенные красным - пока не знаю как подступиться, выделенные серым - сняты из обсуждения. исключены из ТЗ
1. управление двумя КЗР по температурному графику/постоянной уставке. (отопление+ГВС или 2 отопления)
2. реализация управления выходными реле изменением скважности выходного сигнала, а не сомнительного пересчета выхода ПИД в время движения привода с попыткой его отслеживания его положения через преломление света с марса. для медленных приводов и медленно изменяющихся процессов (как отопление) это может и будет работать. а вот для быстрых, да еще если регулятор вообще практически работает на дифференциальной составляющей, уже не прокатит. у меня так работает ТРМ32 на одном из маленьких 5-этажных домов, где ГВС шатает как я не знаю что)
3. возможность ручного переключения сезонов лето/зима
4. возможность автоматического переключения лето/зима, но тут нужно поподробнее разобраться:
Во первых есть макрос в онлайн базе - к нему нет вопросов, но есть нюансы, которые я получил при эксплуатации котельной, где нет требований к жесткому переключению сезонов, и все решают жильцы, описывать буду реальные вопросы в особенностях климата Курской области. Запускать отопление в идеале нужно не в момент, когда на улице температура падает ниже +8 (как по снипу) а где-то ниже +12 - +14, при этом такая температура возможна не только незадолго до начала отопительного периода,но и , допустим ночью летом, е запускать же отопление в этот момент? конечно нет, потому хотелось бы добавить к переключателю по температуре переключатель по месяцам, при этом продумать это так, чтобы можно было установить месяц начала возможного запуска отопления, и месяц окончания, а идеале как-то раздробить месяц на 2 куска - первая/вторая половина. точнее уже не нужно, поскольку настолько точно подобрать ежегодное изменение сезона сложно, и всегда можно скорректировать как раз температурой перехода.
5. для продления ресурса ПРки использовать для регуляторов промежуточные реле и транзисторные выходы - тут спасибо за "5" модификацию! идеально!
я всюду использую реле кипприбор RP-403DLTU и колодки PYF-044BE/3. самый прикол в том, что эти колодки полная копия с ABB, соответственно для продления срока службы транзисторов устанавливаю в них модуль защитного диода ABB CR-P/M-22 6-230B DC 1SVR405651R0000.
6. выношу вопрос о необходимости внесения в ПРку большого количества типа датчиков температуры. мое мнение - достаточно двух типов pt100 и pt1000 остальные датчики это уже редкость, ну или я в это чего-то не знаю, просто ввод в программу большого количества вариантов датчиков неистово сжирает ее память. датчики 50м это уже атавизм, тем более при 2-х проводной схеме влияние сопротивления провода уже катастрофически заметно и требует калибровки для каждого датчика при любых раскладах. NTC встречаются в профильном направлении практически никогда. датчики 100П в диапазоне ИТП/котельной практически не отличаются от pt100 и можно просто править уставки, ну или вписать в макрос выбор альфы, кстати я уже скрестил два макроса pt100/1000 в один макрос с подстановкой нужных констант через sel. это снизило затраты ресурсов прки по 1 проценту по каждому параметру с каждого макроса, по сравнению с переключением между двумя макросами.
7. насколько нужен аналоговый сигнал температуры обратки системы отопления, если не реализовывать систему контроля перегрева обратки? может этому входу найти более полезное применение?
Переходим к расширению функционала по работе с насосами.
1. в пределах "тушки" прибора должны управляться 2 группы насосов (по одной для каждого контура регулирования)
2. у насосов должен быть контроль или перепада давления на группе или 2 входа с каждого из пускателей насосов.
2. в системе должны быть независимые датчики давления для каждого контура для безаварийной приостановки работы насосов и их автоматического перезапуска после восстановления давления в контуре решено в рамках моей предыдущей темы.
3. желательна возможность управления подпиткой с контролем времени подпитки (через накопление времени открытого клапана подпитки за сутки с момента первого открытия, то есть если за сутки превышено суммарное время нахождения клапана подпитки в открытом состоянии, то авария, если не накопилось, то нет аварии. весь прикол в том, что надо с момента первого открытия клапана отсчитывать сутки, а потом, если не было возникновения аварии (время не накопилось), то сбрасывать этот таймер) но на это не хватает входов ((( но все равно мне этот функционал нужен в чистый насосный вариант. прошу помочь.
4. учитывая, что можно за одно управлять подпиткой, поднимаю вопрос о необходимости контроля раздельно каждого насоса, или одним сигналом с запараллеленных доп-контактов пускателей? в принципе это тоже рабочий вариант. тогда появляются 2 свободных входа для подключения реле подпитки и вводим функционал п.3 поразмыслил и решил, что 1 входа контроля будет вполне достаточно, тем более для переключения зима/лето нужен вход непосредственно на ПРке.
5. хотел бы уточнить у разработчиков, по каким условиям срабатывает сигнал аварии для модуля ПРМ, только при его неподключении, или еще и при его выходе из строя? надо ли выводить эту аварию на самой Прке, чтобы сообщить, что весь функционал отвалился, и как себя при этом поведет ПРМ? или не заморачиваться, просто меня пугает что можно не узнать, что отвалились насосы висящие на ПРМ. и вопрос - стоит ли ее выделять отдельно, или просто сделать выход общей аварии? просто насосы однозначно планирую делать отдельными выходами, поскольку это критическая авария и ее надо выводить отдельно.
6. на модуль ПРМ планирую выносить управление еще двумя группами насосов, управление которыми можно будет сконфигурировать по решению необходимых задач через выбор вариантов :
а) отключать группу при переключении в режим "лето"
б) отключать группу вместе с отключением 1 контура
в) отключать группу вместе с отключением 2 контура
г) независимая группа
7. планирую сделать меню с выбором названия контуров, чтобы при настройке системы можно было выбрать наименование в остальных меню, тогда будет удобно расписать конфигурацию.
Распределение I/O вижу так:
как обычно итоговый результат не буду скрывать от общественности )
Планирую соорудить собственный аналог ТРМ32 с блэкджеком и...
