PDA

Просмотр полной версии : приборы для автоматизации итп, цтп



ВладимирS
28.04.2009, 23:35
уважаемые господа!

хочется выразить вам благодарность за удачные разработки в области автоматизации технологических процессов. много лет используем ваши приборы для автоматизации тепловых пунктов г. москвы. чаще всего используем регуляторы трм32 в качестве регуляторов температуры в системах отопления, вентиляции (по независимой схеме) и горячего водоснабжения, а также сау-мп (алг.15) для управления насосным оборудованием.
приборы надежны, регуляторы очень разумно сконструированы, минимум динамических регулировок упрощает настройку регуляторов и в то же время оставляет ее достаточно гибкой для управления самыми разными системами. очень импонируют подробно и толково расписанные инструкции по эксплуатации, обилие самой разнообразной информации на сайте.
теперь о грустном. приборы ваши начали использовать около 10 лет назад. за это время в линейке приборов, которые мы используем произошли лишь незначительные изменения. а хотелось бы расширения номенклатуры ваших приборов.
в частности, занимаясь проектированием итп, цтп, столкнулись с такой проблемой: итп как правило, оборудовано 3–4 насосными группами, плюс 2-3 регулятора. в итоге на дверку шкафа автоматики приходится устанавливать 6-7 приборов с лицевой панелью 96х96 мм, туда же надо пристроить до 8 переключателей, индикаторы, иногда и кнопки управления. и получается дверка очень перегруженной. а увеличивть габариты щита часто не представляется возможным. регуляторам самое место на дверке, они отображают полезную для оператора информацию. ну а сау-мп там не место, на приборе индицикация, интересная лишь наладчику. напрашивается вывод: устанавливать сау-мп внутрь щита. но этих приборов в Din-реечном исполнении не существует. навесное исполнение тоже не очень подходит для внутришкафного монтажа. пожалуйста, выпустите прибор в Dinовском корпусе.
второе, нет подходящей модификации сау-мп для автоматизации насосов подпитки с одновременным управлением соленоидным или запорно-регулирующим клапаном подпитки. приходится изгаляться.
третье, неудобство программирования сау-мп представляется несложной проблемой, добавление возможности удобного и полноценного программирования в сам прибор наверняка не сделает его дороже в разы. можно также сконструировать отдельный блок с цифровым индикатором, с которого станет возможным программировать подключаемый к нему сау, а еще лучше сделать возможным подключение к такому блоку нескольких приборов сау-мп по отдельному интерфейсу. в таком случае потребитель сам сможет решать - какой вариант ему больше подходит, программировать ли прибор с помощью компьютера, или потратиться на приобретение программатора.
четвертое, для сау-мп тоже необходим интерфейс для ввода его в сеть с возможностью передачи данных с него (номер работающего насоса, отсутствие или наличие «аварии») в диспетчерскую. неплохо было бы иметь возможность также выводить на диспетчерскую информацию о положении «авт» переключателя «авт-0-руч» соответствующего насоса. это просто, т.к. в настоящее время сухие контакты этих переключателей, соединенные параллельно подключаются на вход «пуск» сау-мп. можно использовать еще один вход для «пуска». по любому замкнутому из них (насос№1, насос№2) прибор будет запускать программу, а в диспетчерскую уйдет сигнал о положении переключателя каждого из насосов.
пятое, часто сталкиваемся с вариантом, когда в тепловом пункте имеется две системы с регулированием температуры по наружному воздуху. соответственно устанавливаем два трм32, два датчика наружного воздуха и тянем две кабельные линии (как правило, достаточно длинные). удобней было бы иметь возможность получать данные о температуре с одного датчика по сети (разумеется, если таковая используется).
шестое, представляется очень интересным вариант, когда в одном приборе объединяются один регулятор температуры и полнофункциональное управление 2-мя циркуляционными насосами. причем регулятор такого комбинированного прибора должен быть универсальным: т.е. с возможностью использовать его как в системе отопления (вентиляции), так и в системе гвс. такой прибор наверняка будет иметь хороший спрос, т.к. будет достаточен для автоматизации любого контура в тепловом пункте (без подпитки).


с уважением.
владимир.

Gans
29.04.2009, 14:42
Решил и я сюда свои пожелания.
Вообще то для народа необходимо не только управление но и коммерческий учет. Идеальный прибор для ЦТП и ИТП и тд. необходим теплосчетчик с возможностями свободно программируемого контроллера.
Например:
На ПЛКххх похожем на ПЛК63 сделать теплосчетчик и управление насосами + управление клапанами ГВС и отопления. Само собой изменение настроек теплосчетчика только, если на плате стоит перемычка (после конфигурирования она снимается), а снять её необходимо вскрыть корпус ПЛК и нарушить пломбы. Теплосчетчик можно только конфигурировать из специальной программы конфигуратора, а программирование может только считать данные из счетчика + реализовать алгоритм управления насосами и клапанами. Также необходим Ethernet интерфейс с возможностями аналогичными ПЛК1хх и индикация как на ПЛК63 + крепление на фасадный вид щита + Din-рейка (у сименсов есть такое).
P. S. уже сейчас знакомые ищут аналогичное изделие и потребность около сотни штук. Стоимость реализации на отдельных компонентах ПЛК100+МВА8+теплосчетчик+ИП320 получается заоблачной :-) вот если это всё укомплектовать в один корпус по цене 20 т. р. (до 40 т.р.) уверен такое только в первый год выпуска приобретут не одну тысячу штук.
а по умолчанию в это изделие уже вложить алгоритм работы с двумя группами насосов (ГВС + отопление по две шт.) отопление от температуры наружного воздуха + ГВС. Многим этого будет достаточно. так же можно на СД с контроллером поставлять несколько готовых вариантов программ.

ASo
29.04.2009, 21:10
на плк63 не возможно реализовать необходимые алгоритны коммерческого учета тепла. по многим как техническим так и юридическим причинам.
да и зачем?
теплосчетчик - отдельно, контроллер итп (цтп) - отдельно. по многим причинам, юридическим и "политическим". корпус - это не самое дорогое.
вот сделать "макропрограмматор" для плк63+мр1 - указываем число теплоситем, их тип, число насосов... - на выходе программа, адреса протокола и схема подключения - это моглобы быть полезным. вопрос только в экономике.
но не факт, что нужно. можно написать библиотку стандартных кубиков - из них скомпоновать программу итп - элементарно. хотя вопрос в квалификации киповцев в теплосетях - он больной вопрос.

Юрий_Уфа
30.04.2009, 15:20
Присоединяюсь к мнению ASo. Он "копает" ,думаю, глубже. Но Gans_a тоже ценю. Чем сложнее в применении прибор (прим. ТРМ151), тем уже охватывает его поле - поле реальных КИПовцев, да и не только.
В цене интерфейс общения с прибором и док_ей + надежность.

Николаев Андрей
01.05.2009, 09:53
Господа. Очень важно мнение повопросу создания таких приборов.
Сейчас ействительно ведется проработка нового ТРМ132, в корпусе ТРМ133, с возможностью расширения с помощью МР1.
По этому все пожелания по модификациям просьба присылать на a.nikolaev@owen.ru

Wer
01.05.2009, 18:23
ну вот. опять начали ворошить старое. прошло наверное года два? лично мое мнение не поменялось: ни к чему объединять регуляторы. не нужно объединять управление насосами и регулирование. не нужно коммерческий учет перемешивать с технологией. система диспетчеризации должна работать параллельно коммерции и технологии и иметь свой парк датчиков. охранная сигнализация должна существовать автономно своим собственным комплектом оборудования и телеметрии.




пятое, часто сталкиваемся с вариантом, когда в тепловом пункте имеется две системы с регулированием температуры по наружному воздуху. соответственно устанавливаем два трм32, два датчика наружного воздуха и тянем две кабельные линии (как правило, достаточно длинные). удобней было бы иметь возможность получать данные о температуре с одного датчика по сети (разумеется, если таковая используется).

Cоглашусь. Но сталкиваемся не часто.

ASo
01.05.2009, 20:10
система диспетчеризации должна работать параллельно коммерции и технологии и иметь свой парк датчиков.
Почему?
Почему не снимать информацию с технологии (заодно управляя ей, при необходимости) и с коммерции?

Wer
01.05.2009, 21:49
Почему?
Почему не снимать информацию с технологии (заодно управляя ей, при необходимости) и с коммерции?

Дублирование. Это совершенно нормально. И я Вас умоляю: Только не надо ничем управлять!!
Уточню себя. Вместо слова "технологии" поставьте "системам регулирования". Тогда зазвучит правильно.

ASo
02.05.2009, 07:42
Дублирование. Это совершенно нормально.
Зачем? Если все данные есть в управляющем контроллере, то почему их оттуда и не забрать? Зачем дубль датчиков, системы измерения?

Wer
02.05.2009, 11:56
2 ASo: Давайте сначала сделаем контроллер понадежнее. Потом попробуем его продать теплосетям...... Сейчас же замена оборудования происходит понемногу, поэтапно. Цены всех устраивают, надежность.. Да бог с ней, с надежностью. Она и у ОВЕНа на втором плане.
Ну и добавлю, что некоторые коммерческие данные не имеют отношения к технологии, и некоторые данные регуляторов могут Вас просто и откровенно запутать.

ВладимирS
05.05.2009, 23:36
Зачем? Если все данные есть в управляющем контроллере, то почему их оттуда и не забрать? Зачем дубль датчиков, системы измерения?
Считаю совершенно справедливым это замечание. Грех не использовать уже имеющуюся в контроллере информацию, а вместо этого огород городить сугубо с целью диспетчеризации: дополнительные модули, дополнительные контакты переключателей, дополнительные датчики, реле и т.п., и соответственно куча проводок, клеммных соединений -а это никоим образом не служит оптимизации системы ни в техническом, ни в экономическом плане.
Понятно, что не все из имеющейся информации непременно должно отражаться у диспетчера на мониторе (например, коэффициенты ПИД-регулятора, уставки таймеров САУ), но информация (чем больше, тем лучше), отражающая реальное состояние системы в целом будет очень кстати.

Дмитрий
06.05.2009, 04:03
господа никто не говорит о неиспользовании переменных из плк, речь идет о надёжности системы в целом и для надежной информативности. создание отдельно контура показаний и контура управления вполне и очень нормальная вещь, я не говорю о одной муфельной печи, и если вы когда нибудь работали на нормальном производстве, то там всё так и сделано.

Wer
06.05.2009, 21:18
грех не использовать уже имеющуюся в контроллере информацию, а вместо этого огород городить сугубо с целью диспетчеризации...

приведу один пример. регулятор температуры гвс на базе трм12. термометр установлен в 5 Dу после точки смешения подающего и обратного трубопровода, клапан кзр установлен на подающей линии. вот точка врезки термометра получается такой (как бы это сказать) критичной что ли, но эффективной. смотришь на измеренные показания и зла не хватает. а вот дальше по трубопроводу гвс на гребенке установлен термометр гвс системы телемеханики. уже потоки смешались нормально. это и надо снимать в диспетчерскую как итоговый результат.

Wildelectric
16.05.2009, 21:34
Решил и я сюда свои пожелания.
Вообще то для народа необходимо не только управление но и коммерческий учет. Идеальный прибор для ЦТП и ИТП и тд. необходим теплосчетчик с возможностями свободно программируемого контроллера.
Например:
На ПЛКххх похожем на ПЛК63 сделать теплосчетчик и управление насосами + управление клапанами ГВС и отопления. Само собой изменение настроек теплосчетчика только, если на плате стоит перемычка (после конфигурирования она снимается), а снять её необходимо вскрыть корпус ПЛК и нарушить пломбы. Теплосчетчик можно только конфигурировать из специальной программы конфигуратора, а программирование может только считать данные из счетчика + реализовать алгоритм управления насосами и клапанами. Также необходим Ethernet интерфейс с возможностями аналогичными ПЛК1хх и индикация как на ПЛК63 + крепление на фасадный вид щита + Din-рейка (у сименсов есть такое).
P. S. уже сейчас знакомые ищут аналогичное изделие и потребность около сотни штук. Стоимость реализации на отдельных компонентах ПЛК100+МВА8+теплосчетчик+ИП320 получается заоблачной :-) вот если это всё укомплектовать в один корпус по цене 20 т. р. (до 40 т.р.) уверен такое только в первый год выпуска приобретут не одну тысячу штук.
а по умолчанию в это изделие уже вложить алгоритм работы с двумя группами насосов (ГВС + отопление по две шт.) отопление от температуры наружного воздуха + ГВС. Многим этого будет достаточно. так же можно на СД с контроллером поставлять несколько готовых вариантов программ.

А вы в курсе что в москве, например вы никогда не здадите ИТП/ЦТП если у вас не будет установлен теплосчётчик Вист. Мало того недавно из МТК пришло письмо о том что если вы дистанционно снимаете отчёты через модемы GSM !!НЕ ОБОЗНЧЕННЫЕ В ДАННОМ ПИСЬМЕ!! то у вас эти отчёты не примут! а вы говорите о учёте в ПЛК:D

Wildelectric
16.05.2009, 21:40
теперь наш специалист по учёту думает как жить дальше? обьектов - 78 разбросаны по всей москве, народу в его отделе - 2чел. вместе с ним. на всех обьектах установлены висты и сименсы. и если сименс 35 стоит 4т.р. максимум то тот хлам что в писме предложили от 5т.р

Wildelectric
16.05.2009, 21:54
по поводу розработки трм-132.
1. по возможности уменшить время опроса датчика гвс.
2. добавить функцию управления группами насосов (цо и гвс)
3. добавить функцию управления клапаном подпитки и группой насосов подпитки (возможно через мр-1)
4. добавить функцию чтения/передачи тнаружн. по сети 485
5. обязательно добавить переход в режим лето по тнар./контакту/часам.

для примера посмотрите на данфосс, апех10.
все просто до безобразия один мозг и несколько блоков расширения, можно собрать любую конфигурацию цтп/итп с насосами,подпитками и деспетчеризацией! даже комп не нужен достаточно кпк. но всё это стоить будет дороже чем тепломеханика в том-же цтп

Wildelectric
16.05.2009, 22:08
в принципе для этих целей вполне хватит плк63 + мр1 (цо+гвс+подпитка) и готовая програмка в кдс загружаемая через простенкий кофигуратор в которм выбирается чего куда подключать и какие параметры цо,гвс,подпитки, временных моментов и настроек коэфициентов регуляторов. насколько я понимаю цена всего этого будет не более 20т.р....

Николаев Андрей
17.05.2009, 02:14
кто бы вот рассказал как такую программу сделать :)

ASo
17.05.2009, 10:58
кто бы вот рассказал как такую программу сделать :)
Что конкретно?
Если алгоритмы, то они достаточно простые.
А если программу конфигуратора, то можете подсказать, есть ли в Codesys возможность автоматической компиляции-загрузки некоего текстового файла, подготовленного внешней программой?

Vitto
17.05.2009, 11:21
Всем Доброго дня :)
Wildelectric - не подскажите, что за GSM модемы рекомендует ставить МТК?

Wildelectric
17.05.2009, 12:05
to Vitto завтра на работу выйду, письмо посмотрю и отпишусь. если смогу отсканировать выложу.

Wildelectric
17.05.2009, 12:11
да и суть не в том какие модемы а в том что такое писмо вообще возникло в природе! это сопоставимо с тем, что если вы звоните чиновнику с телефона сименс, а он вам отвечает что перезвоните с нокиа, тогда и поговорим! бред полный!

Николаев Андрей
17.05.2009, 12:18
сами по себе алгоритмы достаточно не сложные.
но вот разбить программу на блоки, а потом правильно её собирать - вот это задача еще та.
так что на мой взгляд необходимо описание работы отдельных блоков. например калорифер. причем в зависимости от типа клапана, количества насосов и т.д.

ASo
17.05.2009, 12:32
да и суть не в том какие модемы а в том что такое писмо вообще возникло в природе! это сопоставимо с тем, что если вы звоните чиновнику с телефона сименс, а он вам отвечает что перезвоните с нокиа, тогда и поговорим! бред полный!
Да не бред, а реальность, причем всюду и во многих странах.
Как пример - те же теплосчетчики, электросчетчики - все лоббируется и согласуется. Хотя согласовываться и стандартизироваться должны только технические характеристики и точность измерения. И ставь любой ТС, хоть Вист, хоть Взлет, хоть Данфосс....
При том, что ТС на балансе потребителя и к сетям отношения (юридического) не имеет.
Просто - проще заплатить, чем долго судится, дороже выходит.

ASo
17.05.2009, 12:36
сами по себе алгоритмы достаточно не сложные.
но вот разбить программу на блоки, а потом правильно её собирать - вот это задача еще та.
так что на мой взгляд необходимо описание работы отдельных блоков. например калорифер. причем в зависимости от типа клапана, количества насосов и т.д.

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

Wildelectric
17.05.2009, 12:53
вот для этого и делается прикладной конфигуратор, который не даст совершать подобные ошибки. а не "программатор общего назначения".
т.е. инженер работает с прикладными блоками - "контур нагрева", "насосная группа"...
выбрали, соединили, параметризовали - и все.

+100! об этом и говорим!

Wildelectric
23.05.2009, 20:41
И как всегда тишина.. Заметил интересную закономерность - как только речь заходит о ПО попроще, тема быстро затихает...

ASo
23.05.2009, 20:44
Что Вы называете "ПО попроще"?

Wildelectric
23.05.2009, 21:30
Что Вы называете "ПО попроще"?

То о чём вы говорили чуть выше - "простой конфигуратор а не програмотор бщего назначения"
Лично для меня верх совершенства ПО для микро-плк это по для альфы или круозета.
В своё время кто-то на форуме высказал опасение что с выходом ПЛК в овене все кинутся развивать это направление и забудут про тысячи киповцев в небольших организациях которые являлись потребителями простых и недорогих приборов от овена. Похоже так и вышло - для ЖКХ так ничего и нет кроме САУ-МП и ТРМ32 застрявших в 90-х...
Всё внимательнее смотрим в сторону Контара с их глюками и ценами..
И если первые овены я юзал лет десять назад и они до сих пор работают, то о контаре отзывы совсем не такие...

Ельцов Андрей
24.05.2009, 02:07
..."простой конфигуратор а не програмотор общего назначения"...

Тем не менее Вы все равно пользуетесь контаром, у которого также все программируется через блоки. Наверняка большенство пользователей пользуется ограниченным количеством ФБ. Какими, например, Вы пользуетесь ФБ для решения своих задач? Если у Вас есть их (ФБ) описание будет вообще шоколадно.
А мы, в свою очередь, сможем создать набор готовых ФБ и разработать типовые схемы и алгоритмы для управления ИТП и ЦТП.
Как на Ваш взгляд, так будет удобнее?

Правда от codesys мы никуда не уйдем будет просто набор блоков.

ASo
24.05.2009, 07:18
Так человек боится КДС, см. соседнюю тему.

Wildelectric
24.05.2009, 14:26
Так человек боится КДС, см. соседнюю тему.

Всё верно! Боимся! и сколько нас таких убогих... :eek:

Wildelectric
24.05.2009, 14:42
Тем не менее Вы все равно пользуетесь контаром, у которого также все программируется через блоки. Наверняка большенство пользователей пользуется ограниченным количеством ФБ. Какими, например, Вы пользуетесь ФБ для решения своих задач? Если у Вас есть их (ФБ) описание будет вообще шоколадно.
А мы, в свою очередь, сможем создать набор готовых ФБ и разработать типовые схемы и алгоритмы для управления ИТП и ЦТП.
Как на Ваш взгляд, так будет удобнее?

Правда от codesys мы никуда не уйдем будет просто набор блоков.

Гдето об этом уже писали. Это конечно значительно упростит задачи по автоматизации теловых дел и вентиляции.
Контар поэтому и собираемся пользовать что там уже готовые блоки и примеры типа: контур ЦО с защитой по обратке, ГВС, группа насосов...
Если перефразировать, напишите ФБ с названием ТРМ32,ТРМ12,ТРМ202,САУ-МПхх... и задача по переходу от отдельных приборов к виртуальным сведётся к соединению их между собой мышкой а не отверткой! Да и освоение КДС упростится для юных дарований:cool:

Мне кажется нужно опрос устроить не тему "какаие фб народ хочет видеть в боблиотеке "ОВК""

ASo
24.05.2009, 14:44
Всё верно! Боимся! и сколько нас таких убогих... :eek:

А почему тогда не боитесь Конграфа?

Wildelectric
24.05.2009, 16:31
А почему тогда не боитесь Конграфа?

Потому что просто и понятно - слева входы, справа выходы, посередине фбд с подробнейшим описанием в хелпе все доступные библиотеки под рукой и не надо лазить через менеджер и искать нечто на англицком сокращённом..
Не самый лучший вариант помоему, но лучше чем КДС :mad:

ASo
27.05.2009, 17:17
2. Идея с универсальным конфигуратором для итп/цтп/приточек в принципе понятна. Есть универсальная программа на контроллере, в неё при помощи конфигуратора с ПК загружается итоговая схема.
.........
Единственным недостатком такого решения будет отсутствие общей для прибора машины состояний. Именно о таком приборе идёт речь?
Не совсем так, я бы сказал, совсем не так.
Это былобы замечательно, только боюсь, памяти ПЛК63 на это не хватит.
Я имел в виду следующее.
Пишем отдельный конфигуратор, по типу ФБД редактора, только с малым количеством макроблоков. А дальше инженер КИП (ближе к теплотехнику) набирает скажем для ИТП - Один погодонезависимый контур (ГВС) + насосная группа из одного касоса (ГВС) + 1 погодозависимый контур с контролем обратки (отопление) + насосная группа из 2-х насосов (основной + резервыный) + группа подпитки. Далее подключает входы-выходы. Конфигуратор генерит файлы импорта для КДС, включая экраны!. А вот далее - как можно незаметнее КДС заливает это в контроллер.
Такое возможно в принципе?

Wildelectric
27.05.2009, 22:20
1. сейчас ведётся предварительная проработка трм132м-01. схему подключения прилагаю. будут пожелания и предложения -- пишите!

наконец-то!! надеюсь внешность у него будет как у трм133? и конфигурирование с компа?
пожелания:
1. обязательно предусмотреть переход в режим "лето"!! либо по внешнему контакту либо по уличной температуре (идеально и то и другое) при котором будет закрываться кзр цо и останавливаться насосы цо. иначе приходится бегать по всем объектам где трм32 и через хитрое меню выключать кзр цо, насосы и задвижки любой сантехник выключит/перекроет а в трм не полезут! а релюшки клац-клац кзр ё-ё жалко однако, ресурс у них есть. мне кажется можно использовать вход с3 а ревун отключать выключателем в шкафу либо какой либо из кнопок на мордашке.
2. ревун. хотелось-бы вывести на этот выход (через конфигуратор) аварии не только насосов но и рмин цо, рмин гвс, перегрев/недогрев гвс и некий аварийный график по отоплению. то есть соединить все возможные аварии на этот выход, а расшифровку можно и на экранчик вывести.
3. раз уж меряем давление в контуре цо и гвс неплохо бы было вырубать соответствующие насосы по уставкам рмин цо и рмин гвс. и главное при восстановлении давления автоматом запускать насосы! защиту от сх в виде дем-102 и так поставим, обычно им рвём питание контакторов независимо от того, чего там надумал контроллер.
3. раз уж меряем давление в контуре цо логично было бы и клапан подпитки задействовать наример на 8выход мр-1
4. для котеджно-дачных применений может пригодится возможность сконфигурировать выход "открыть кзр гвс" для работы с насосом загрузки бойлера. выход "открыть кзр цо" для вкл/выкл котла соот ветственно иметь возможностьтоб использовать как комнатный датчик а через тпрям ограничивать температуру котла в зависимости от тулич. при этом может понадобиться функция отключения насоса отопления во время приготовления гвс.

пока такие мысли..

Wildelectric
27.05.2009, 22:37
2. идея с универсальным конфигуратором для итп/цтп/приточек в принципе понятна. есть универсальная программа на контроллере, в неё при помощи конфигуратора с пк загружается итоговая схема. на схеме в конфигураторе указывается набор блоков (калориферов, вентиляторов, клапанов и т.п.). у каждого блока есть свои свойства (например, для электрокалорифера -- количество ступеней, тип управления, номера подключённых выходов и т.д.). у каждого блока есть условия включения и выключения (например, срабатыванеи дискретного датчика, сравнение сигнала с аналогового датчика с заданной велииной и т.д.). есть общие свойства прибора (например, индикация экранов). единственным недостатком такого решения будет отсутствие общей для прибора машины состояний. именно о таком приборе идёт речь?

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

ASo
28.05.2009, 15:56
1. так напишите макроблоки! могу дать работающие, но не в кдс. а потом компилите из них. кто может - будет пользоваться ими. кто ботсят кдс (и я их понимаю) - внешним конфигуратором. только как скрыть (упростить) настройку/установку кдс/таргетов/библиотек???
5. я традиционно делаю по пьезодатчику - цена сравнима с механическим 2-х позиционным, а для диспетчеризации и работы (настройке уставок) - проще. при пренижении нижней уставки - пуск насоса подпитки, при отсутствии аварии через несколько секунд - открытие клапана.
6. для гвс всегда полностью закрывается рег. клапан. опасности заморозки нет - трубы ниже уровня промерзания. вода хвс ведь не замерзает?
8. в т.ч. при аварии датчика, аварии насосов - переход на график обратки.

ASo
28.05.2009, 17:45
летом отопление не работает. какой тут график обратки???

Wildelectric
28.05.2009, 21:36
но гвс то работет! а питаются они от общего контура. или что-то не так? то есть речь о том, когда летом питаем гвс от общего контура, и все пользователи закрыли свои краны горячей воды. что делать? и нам закрыть все кзр? или сливать через контур отопления дополнительную воду, чтобы поддержать температуру обратки?

ГВС работает и весь гимор с обраткой начинается именно летом! Если все закрыли краны надо очень быстро!! закрыть кзр гвс! отсюда моё давнеее пожелание максимально уменьшить время опроса датчика гвс!! Буквально сегодня на ул.авиамоторной в здании общаги пытался выловить баланс между 52-54 гвс и 28 обратки что требуют теплосети:confused: при том что хвс уже 22 градуса! Максимум что удалось выжать из ТРМ32 47-51 гвс и 35 обратку:( :( . Поэтому почти везде поджаты 5 задвижки чтобы уменьшить перепад. Если попытаться через контур отопления летом слить воду, через сутки вы будете в прокуратуре!! это не шутка. А там где отопление идёт по независимой схеме, соответственно нагрев теплообменник вы на обратке получите тоже что и в подаче теплосети!

Wildelectric
28.05.2009, 21:47
по поводу насоса загрузки бойлера. большинство бюджетных котеджных схем отопления делается по т.н. насосной схеме когда на выходе из котла стоят два насоса один на контур отопления, другой на греющий змеевик бойлера гвс (накопительного). работает по двухпозиционному закону вкл-выкл, часто для этого используют термостат. но возникает проблема - при нагреве бойлера необходимо держать температуру котла 65-70гр. чтобы получить гвс 50-55гр. чего весной-осенью многовато для контура отопления, поэтому необходимо отключать насос отопления.

Wildelectric
28.05.2009, 22:02
авиамоторная -- как раз место нашей дислокации. так делать то что? как реализовать летний режим?

да рядом.
1. ни при каких условиях летом не включать котур отопления (кзр и насосы)
2. максимально уменьшить время опроса датчика гвс (из практики 0,2-0,5 сек.) дальше пид регулятор как в трм32 справится на ура!
с гвс геморой летом именно из-за болшого времени опроса тгвс в трм32 часто можно наблюдать при малом расходе как показания меняются 49,5-51,0-54,5 регулятор судорожно посылает импульсы на закрытие но поздно!! после полного закрытия тампература (по прибору) всё еще растёт а по факту уже выросла. вот и приходится мирится с тем что гвс на многих объектах плавает ниже уставки но при этом обратка более-менее..

Wildelectric
28.05.2009, 22:19
по поводу летнего режима в отоплении. автоматический переход по температуре наружного воздуха -- само собой. а вот ручной -- нужен ли он? ведь летом отключаются насосы и закрывается кзр. одно случайное нажатие кнопки зимой -- и возможно замораживание отопления. может, сделать дополнительный ручной переход через меню по паролю?


главный смысл именно в кнопке(переключателе) потому как местные сантехники точно не будут заходить в меню и набирать пароли. им это не надо! отвлекает ото сна! а нам каждое 30 апреля бегай по всей москве выключай.... на тех щитах где есть такой переключатель без проблем, где нет приезжайте, нажимайте, настраивайте! а дуракозащиту можно организовать в приборе, типа если на улице ниже +3 плевать на кнопку! запускаем насосы и приоткрываем кзр цо.

Wildelectric
28.05.2009, 22:23
5. клапан подпитки. это 2-позиционный регулятор, который включает выход 8 мр1 при сигнале на 8 аналоговом входе (датчике давления) ниже уставки? тогда этот датчик нужно перекинуть на цо?


именно так!

Wildelectric
28.05.2009, 22:31
0.2...0.5 сек -- это новое железо. сейчас 0.8 сек на вход. общее время опроса = 0.8* количество задействованных входов.

то есть 6,4 сек? это очень много!! а возможно ли зделать так что опрос тпод и тулич зделать как можно реже, да и остальные раз в 10-20 сек вполне достаточно, а тгвс за счёт этого уложить хотябы в 1сек? или мультиплексор работает только по кругу?

Wildelectric
28.05.2009, 22:43
6. в контуре гвс при аварии датчика температуры гвс, что делать? могу или оставить клапан в том же положении, в котором он был, тогда есть риск перегрева воды в контуре гвс (кипяток из-под крана), либо полностью закрыть кзр, тогда есть риск замораживания контура гвс, да и пользователи остануться без горячей воды.


закрыть кзр немедленно! если недогрев - это заявка в жек до следующего дня терпит. а если перегрев а (зимой и пар получить недолго) это ожог причём сильный! а если какой дебил ребёнка сначала в ванну посадит а потом воду откроет? в любом случае уголовное дело!

ASo
29.05.2009, 07:50
то есть 6,4 сек? это очень много!! а возможно ли зделать так что опрос тпод и тулич зделать как можно реже, да и остальные раз в 10-20 сек вполне достаточно, а тгвс за счёт этого уложить хотябы в 1сек? или мультиплексор работает только по кругу?
6,4 сек - это конечно очень много. Но 1 сек? А у Вас какое время хода КЗР. Чтото я крайне редко встречал реально установленные КЗР со временем хода менее 60с. А Вы же понимаете, что основная проблема ГВС в этом.

Wildelectric
29.05.2009, 18:03
6,4 сек - это конечно очень много. Но 1 сек? А у Вас какое время хода КЗР. Чтото я крайне редко встречал реально установленные КЗР со временем хода менее 60с. А Вы же понимаете, что основная проблема ГВС в этом.

AMV33/AME33 от Danfoss полный ход штока 30с. реально клапан редко открывается больше половыны соответственно имеем 15с И чтобы регулятор успел закрыть его вовремя ему нужно успеть как минимум 2 раза опросить датчик чтобы принять решение о направлении движения и при 6.4 сек это будет 12.8 сек только на опрос датчика! А чтобы импульс на закрытие был каким нужно датчик желательно опросить не 2раза а поболее...
В прошлом году специально закупили быстрые клапана и меняли всё лето...

ASo
29.05.2009, 19:11
AMV33/AME33 от Danfoss полный ход штока 30с. реально клапан редко открывается больше половыны соответственно имеем 15с И чтобы регулятор успел закрыть его вовремя ему нужно успеть как минимум 2 раза опросить датчик чтобы принять решение о направлении движения и при 6.4 сек это будет 12.8 сек только на опрос датчика! А чтобы импульс на закрытие был каким нужно датчик желательно опросить не 2раза а поболее...
На самом деле, первый импульс дается по П составляющей, а это 1 опрос, особенно, если отключить фильтр (или выставить приемлемую для ГВС постоянную времени).
Но все равно, 6,4с - это очень много для общих и отдельных применений.

ASo
30.05.2009, 09:46
2. как обычно, не понятно. теплосети ведут себя... хамски, и ничего сделать нельзя. вот и крутятся люди.
4. положительно.

Wildelectric
31.05.2009, 22:18
1. отлично!!
2. см. п.1 с таким быстрым опросом и быстрым клапаном на 95% объектов проблем не возникнет в принципе! про завышке (именно завышке!!) предлагаю семафорить выходом "авария гвс" а мы на него потихому повесим клапан на 1/2 и в канализацию. в критические моменты лучше слить пару кубов воды в сутки чем сидеть без гвс всё лето!

Nik
13.07.2009, 20:18
Не надо ни каких ТРМ132! Всё и так хорошо! Есть ПЛК, модули расширения....

Николаев Андрей
16.07.2009, 10:34
Не надо ни каких ТРМ132! Всё и так хорошо! Есть ПЛК, модули расширения....

Не согласен.
Есть локалка и есть ПЛК. И если задачу можно решить локалкой - зачем ставить туда контроллер?
Пожелания к работе локалки мы всегда рады услышать.

Nik
16.07.2009, 17:44
Не согласен.
Есть локалка и есть ПЛК. И если задачу можно решить локалкой - зачем ставить туда контроллер?

Да всё дело в "хлебушке"!

Николаев Андрей
17.07.2009, 09:24
Да всё дело в "хлебушке"!

Согласен, это существенная поправка:) :) :)

ОООСА
21.07.2009, 15:38
Почитал ветку, вроде всё верно кроме того что вы называете ФБД. ФБД - это Функциональные Блоки. А то что вы тут обсуждаете правильнее обзывать Макро Блоки, или Макросы.;)
Идея заключается в том что нужно создавать КОНСТРУКТОР ТЕХНОЛОГА, более удобоваримый чем язык Диаграммы SFC в CoDeSys. Для примера можно посмотреть реализацию Конструктора у Сегнетикса, возможно он даст пищу для ума программёрам...:D
Принцип имхо такой - конструктор с двухуровневым конструированием, простой выбор типовых вариантов, и поблочная (модульная) сборка проекта из элементов - "теплообменник ГВС, Отопления...", "насос", "группа насосов из 2,3,4 насосов", и т.д. Каждый элемент представляет "обвязанный узел". Все узлы соединяются в контур - отопления, ГВС, ХВС,...
Но енто не для меня, я предпочитаю всё писать сам в FBD и изредка при необходимости в IL. Надеюсь еще ST попользовать.

ОООСА
21.07.2009, 15:49
Николаев Андрей
А что, действительно ПЛК 63 такой тормозной на аналоговые измерения???:(
Мне интересно иметь "чистые" (без аппаратно программной фильтрации) аналоговые сигналы с входов производительностью железки в 10 итераций в секунду. А как и чем потом фильтровать и усреднять это ужо мои проблемы...:D

Николаев Андрей
21.07.2009, 17:13
К сожалению да - плата за универсальность и цену...

Kirill
28.07.2009, 17:26
Николаев Андрей
А что, действительно ПЛК 63 такой тормозной на аналоговые измерения???:(
Мне интересно иметь "чистые" (без аппаратно программной фильтрации) аналоговые сигналы с входов производительностью железки в 10 итераций в секунду. А как и чем потом фильтровать и усреднять это ужо мои проблемы...:D

Возможно, вас заинтересует МВ110-8АС в качестве альтернативы универсальным входам ПЛК. Там срокость измерений будет порядка 100-200 гц.

ОООСА
28.07.2009, 17:47
К сожалению да - плата за универсальность и цену...
А какова реальная частота опроса дискретных входов, аналоговых входов, время реакции дискретный вход/выход при программе размером в 300-500 ФБД.

Kirill
28.07.2009, 17:53
А какова реальная частота опроса дискретных входов, аналоговых входов, время реакции дискретный вход/выход при программе размером в 300-500 ФБД.

ФБД другому ФБД рознь.
Пока у вас не будет конкретной программы на 300 ФБД, не получится узнать.

Филоненко Владислав
29.07.2009, 09:40
С точки зрения производительности самой программы проблем нет. Для средней программы цикл 1-2 мс.
Дискретные входа - до 500Гц.
Аналоговые входа опрашиваются раз в 0,36 сек для 2-х проводных датчиков и раз в 0,72 сек для 3-х проводных по очереди.
Время реакции 1-2 мс. Но это смотря как программу написать. Можно и 10 секунд наваять.

ОООСА
29.07.2009, 14:52
С точки зрения производительности самой программы проблем нет. Для средней программы цикл 1-2 мс.
Дискретные входа - до 500Гц.
Аналоговые входа опрашиваются раз в 0,36 сек для 2-х проводных датчиков и раз в 0,72 сек для 3-х проводных по очереди.
Время реакции 1-2 мс. Но это смотря как программу написать. Можно и 10 секунд наваять.
Ну вполне нормально, единственно что аналоговые входа были-бы чуток пошустрее, ежели бы гарантированно укладывались в 0,1сек на все AI по токовому сигналу (двухпроводке) то было-бы саавсем чудненько. Это время может быть критично для измерения давления и расхода. Для измерения температуры это конечно пофиг, но желательно конечно иметь три итерации в секунду (время измерения 0,3с.) для малоинерционных датчиков. Это позволит реализовать адекватный анализ скорости изменения процесса.
Это вааще возможно "подправить" в ПЛК63, например в последующих версиях?:rolleyes:
Щас мне для пары приточек и завесы вполне и такие ТТХ сойдут, но вдруг придётся чего нить пошустрее делать...

ОООСА
29.07.2009, 15:00
И еще, чего там пишут про глюки с некоторыми аналоговыми входами?
Имхо мне нужен безглючный ПЛК, а то тады Заказчик затолкает его мне в одно место и глючить начну я...:(

Николаев Андрей
29.07.2009, 17:11
К сожалению на нескольких контроллерах у клиентов было замечено странное поведение - на пустом проекте период опроса - порядка 20сек...
Ни на одном ПЛК у себя мы это не смогли повторить. Ждем прибор от клиента...
Других нареканий нет.

ОООСА
29.07.2009, 17:14
1. Максимальная частота по дискретному входу при скважности 0.5 составляет 100 Гц в соответствии с РЭ на ПЛК63.
2. Аналоговые входы. 0.1 сек не реально на этом железе. Под ТРМ132М-01 (то есть начиная с прошивки 1.94) сделали возможность установить один вход быстрее чем остальные. Удалось добиться 0.8 сек по этому входу при задействованных 8-ми (соответственно, остальные 7 при этом опрашиваются раз в 10 сек).

А с чем связано такое ограничение по частоте опроса аналоговых входов?

Я как-то ради любопытства на Миллениум3 на несколько аналоговых входов подавал меандры заданной частоты и напряжения. До 12Гц включительно контроллер хавал всё один в один, а дальше пропорционально увеличению частоты уменьшалось измеренное напряжение, после 25Гц вааще входы прекращали видеть меандр. Т.е. простенькая Атмега128 гарантированно справляется по всем аналоговым входам с итерацией 10 раз в секунду что имхо очень хорошо для нано-ПЛК, и достаточно для большинства КИПовских приложений.:D

Николаев Андрей
29.07.2009, 17:19
Связано это с:
1. АЦП должно быть не дорогим
2. Обеспечивать заданную точность - 0,25\0,5
3. Работать с датчиками ТС (вбито 10 градулировок), ТП(несколько типов), тока, напряжения, сопротивления...

Отсюда время опроса...

ОООСА
30.07.2009, 11:01
Связано это с:
1. АЦП должно быть не дорогим
2. Обеспечивать заданную точность - 0,25\0,5
3. Работать с датчиками ТС (вбито 10 градулировок), ТП(несколько типов), тока, напряжения, сопротивления...

Отсюда время опроса...
А если рассмотреть вариант модификации контроллера с "быстрыми" токовыми входами? А для входов где меряется температура использовать НП (нормирующие преобразователи)? Это как-бы "классическая" схема ПЛК. Я её использую почти 6 лет. В свете того что вы собираетесь выпускать НП вроде как вписывается в концепцию. Сделать "быстрый" 1-2 канальный НП, "среднего" быстродействия 4-х канальник и "медленный" 6-8 канальный НП. Тогда интегратор может комбинировать вариации с аналоговыми входами - побыстрее и подороже (например "быстрые" 2+2+2+2), медленнее но дешевле (например один 8-канальный "медленный" НП).:D До кучи можно съэкономить на экранированном кабеле, для токового сигнала 4-20мА достаточно проложить обычный многожильный ПВС к распределительной коробке, где располагается НП и остальные токовые сигналы, а к датчикам температуры нужно тянуть МКЭШ.;) Так что при определенных условиях такой вариант ПЛК + НП может оказаться предпочтительнее. Итого можно выпускать пару модификаций ПЛК - с универсальными "медленными" входами, и с "быстрыми" токовыми. А вааще конечно лучше всего в будущем сделать просто линейку ПЛК110, начиная с "малыша" 8DI+4AI/6DO (или 10DI+4AI/6DO) с внешним дешевым дисплейчиком и с двумя вариантами AI.:D
Как говорится шоб единообразно от минимума 18-20-ПЛК110 до максимума 60-ПЛК110 и + модули расширения. Ограничением будет приемлемое время рабочего цикла всей этой "батареи".

Николаев Андрей
31.07.2009, 15:04
Все нижешедшие посты удалил - так как они никак не соотносится с темой, уж не обессудьте.
Если есть желание обсудить методы и средства создания измерительных трактов - милости просим в курилку.
Все пожелания по линейке ПЛК110 - мы с удовольствием читаем в соответствующей ветке. За них спасибо - какие то из них мы обязательно реализуем.
Все пожелания к интеллектуальным реле - в соответствующей ветке. По реле принимаются все пожелания - так как проект на данный момент в разработке.

ОООСА
31.07.2009, 15:38
Аналогичного класса - См наши ПР110. В серии и дисплейчики и АI/AO надеюсь появятся.
Ну так я о чём талдычу, у вас есть нижний ПР110, есть верхний ПЛК110 30 и 60 физических точек. Нужно еще половинку от 30-ПЛК110 сделать. Тады будет "закрыта" вся линейка.
Проблема конечно с ПО, старшие дорогие ПЛК сидят на КоДеСис, а вот для двух младших - чисто дискретного ПЛК (ПР110) и с аналоговыми входами/выходами нужно конечно что-то придумывать. Нынешний конфигуратор имхо абсолютно не юзабелен. И уж если делать ПО, то одно на два младших ПЛК.
Я лично первым куплю такое чудо, если вы конечно его сбацаете...
И кстати это по теме - 8DI+4AI/6DO хватает на контур отопления, если подстегнуть модуль расширения то и на ГВС. Но это от жадности, Имхо лучше поставить 2 ПЛК "малышки" на разные контуры. И для приточной вентиляции этого хватает с лихвой.
Так что бум ждать...:D

Николаев Андрей
31.07.2009, 16:37
Еще раз. Последний.
Под описанную Вами задачу 8DI, 4AI, 6DO - это ПЛК63. Это если говорить о контроллерах.
Если говорить про реле (то во первых это в другой ветке) - не думаю что стоит лепить в релюшку логику ПИД регуляторов, и иже с ними.
Про новую линейку контроллеров (это опять же в другой ветке) - Ваше предложение очень нас заинтересовало, и скорее всего мы постараемся сделать подобный контроллер на базе ПЛК32.

Но это обсуждение НЕ ЛЕЖИТ В ОБЛАСТИ ТЕМЫ. Хоть ради интереса посмотрите первые 2 страницы обсуждения.

Дмитрий
03.08.2009, 16:18
поставить 2 ПЛК "малышки" на разные контуры.
вообщето использование ПЛК на одном контуре, это "шикарно", например у нас на производстве ПЛК управляет минимум 16 контурами плюс прибомбасы типа погоды (ветер, дождь, светло, темно и т.д.) правда всё на ISPIDAS, но если идти по принципу контур_PLC то зачем? уже всё есть трм-...........всяких модификаций, лобай нехочу. Другое дело что нам хочется всё таки реализовать все идеи наработанные на производстве а жесткий регулятор не даёт?... Но зачем разбивать plc на мелкие функции и создавать целую линейку. Если "пациент" хочет пускай платит за проект, пуск, пргаммирование, обслуживание после установки и дальше и в итоге купит какой нибудь омрон или ещё что, но жесткий и будет хаять ОВЕН, хотя линейка готовых регуляторов, идеально подходящих для требований заказчика, просто не была использованна.

Дмитрий
03.08.2009, 16:27
поставить 2 ПЛК "малышки" на разные контуры.
вообщето использование ПЛК на одном контуре, это "шикарно", например у нас на производстве ПЛК управляет минимум 16 контурами плюс прибомбасы типа погоды (ветер, дождь, светло, темно и т.д.) правда всё на ISPIDAS, но если идти по принципу контур_PLC то зачем? уже всё есть трм-...........всяких модификаций, лобай нехочу. Другое дело что нам хочется всё таки реализовать все идеи наработанные на производстве а жесткий регулятор не даёт?... Но зачем разбивать plc на мелкие функции и создавать целую линейку. Если "пациент" хочет пускай платит за проект, пуск, пргаммирование, обслуживание после установки и дальше и в итоге купит какой нибудь омрон или ещё что, но жесткий и будет хаять ОВЕН, хотя линейка готовых регуляторов, идеально подходящих для требований заказчика, просто не была использованна.

да и ещё, последнее время упёрнутость в продвижении PLC, соовсем не здоровая, пихают везде. А живучесть системы никто не воспринимает, согласен если время отклика параметр - управление нужно менее 1 секунды, тут не поспоришь, ну а дальше, меняй задание по условию на верхнем уровне и когда у тебя сыпется один регулятор или контроль, ты сооовсем не помер.

ОООСА
05.08.2009, 13:45
да и ещё, последнее время упёрнутость в продвижении PLC, соовсем не здоровая, пихают везде. А живучесть системы никто не воспринимает, согласен если время отклика параметр - управление нужно менее 1 секунды, тут не поспоришь, ну а дальше, меняй задание по условию на верхнем уровне и когда у тебя сыпется один регулятор или контроль, ты сооовсем не помер.
Для повышения живучести я делаю просто - 1 система=1 ПЛК. Для реализации такого варианта нужны дешевые нано-ПЛК, много но мелких. Каждая система самодостаточна. По поводу Регулятор vs ПЛК. У ПЛК есть неоспоримый плюс - возможность создания виртуальных сложных связей Регулятор-Блок управления системы, что гораздо сложнее и муторнее реализовать на Регулятор - дискретный ПЛК, тем более что у большинства регуляторов очень скудный набор функций внешнего управления, в лучшем случае Старт-Стоп, а то и этого нет.
По поводу ТРМов, сделаны добротно, но алгоритм управления 3-х ходовым клапаном (а их большинство) далёк отсовершенства, в убогом и ненадежном по исполнению МИНИТЕРМе алгоритм ПДД' гораздо качественнее (пусть ОВЕН не обижается).
Вот и весь сказ в пользу нано-ПЛК как оптимального решения управления и регулирования контурами ЦТП и вентиляцией, а так-же всей остальной мелочёвкой типа освещением, воротами, канализацией, и т.д.

Дмитрий
06.08.2009, 04:56
Алгоритм управления задвижками действительно хромает здесь ребятам нужно поработать

Maximus
07.08.2009, 13:47
Для повышения живучести я делаю просто - 1 система=1 ПЛК. Для реализации такого варианта нужны дешевые нано-ПЛК, много но мелких. Каждая система самодостаточна. По поводу Регулятор vs ПЛК. У ПЛК есть неоспоримый плюс - возможность создания виртуальных сложных связей Регулятор-Блок управления системы, что гораздо сложнее и муторнее реализовать на Регулятор - дискретный ПЛК, тем более что у большинства регуляторов очень скудный набор функций внешнего управления, в лучшем случае Старт-Стоп, а то и этого нет.
По поводу ТРМов, сделаны добротно, но алгоритм управления 3-х ходовым клапаном (а их большинство) далёк отсовершенства, в убогом и ненадежном по исполнению МИНИТЕРМе алгоритм ПДД' гораздо качественнее (пусть ОВЕН не обижается).
Вот и весь сказ в пользу нано-ПЛК как оптимального решения управления и регулирования контурами ЦТП и вентиляцией, а так-же всей остальной мелочёвкой типа освещением, воротами, канализацией, и т.д.


Какой из МИНИТЕРМов Вы нахидите ниболее удачным в плане качества управления задвижкой?

ОООСА
08.08.2009, 13:16
Какой из МИНИТЕРМов Вы нахидите ниболее удачным в плане качества управления задвижкой?
У всех МИНИТЕРМов один и тот-же алгоритм, они отлечаются только сервисными функциями, напряжением питания и корпусами.
Если интересно то могу нарисовать функциональную схему алгоритма ПИ-регулятора с выходом для 3-х позиционного управления с краткими пояснениями. Всё довольно просто, только используется не ШИМ, а несколько иной подход преобразования аналогового сигнала с ПИ-регулятора (изодромного регулятора) в импульсы.;)
Буду рад помочь.:D

olc
11.08.2009, 11:02
Возможно, вас заинтересует МВ110-8АС в качестве альтернативы универсальным входам ПЛК. Там срокость измерений будет порядка 100-200 гц.

Заинтересует безусловно. А когда они появятся в продаже?

Kirill
12.08.2009, 13:27
Заинтересует безусловно. А когда они появятся в продаже?

Продажи начнутся на этой неделе. Т.е. прием заявок.
Реально первая партия ляжет на склад не ранее 2 половины сентября.

Maximus
13.08.2009, 11:11
Заинтересует безусловно. А когда они появятся в продаже?

Так то оно так, но в описаниях МИНИТЕРМов вообще нет упоминаний о ПДД законе управления...

ОООСА
13.08.2009, 17:56
Так то оно так, но в описаниях МИНИТЕРМов вообще нет упоминаний о ПДД законе управления...

Инструкция к 300.01 стр.12
Блок формирования закона регулирования (ПДД')реализует
ПИД-закон совместно с исполнительным механизмом (при использовании импульсного выхода) или совместно с интегратором И(при использовании аналогового выхода).
Так-же смотрите функциональную схему регулятора на стр.38, там всё нарисовано.

Но я на ПЛК реализую всё это несколько иначе, а результат тот-же. Я именно и начинал "ваять" свой первый виртуальный регулятор на ALPHA XL сделав стенд с ПЛК и МИНИТЕРМОМ, добиваясь сходства реакции регуляторов на возмущение.

Brettos
10.02.2021, 17:38
уважаемые господа!

хочется выразить вам благодарность за удачные разработки в области автоматизации технологических процессов. много лет используем ваши приборы для автоматизации тепловых пунктов г. москвы. чаще всего используем регуляторы трм32 в качестве регуляторов температуры в системах отопления, вентиляции (по независимой схеме) и горячего водоснабжения, а также сау-мп (алг.15) для управления насосным оборудованием.
приборы надежны, регуляторы очень разумно сконструированы, минимум динамических регулировок упрощает настройку регуляторов и в то же время оставляет ее достаточно гибкой для управления самыми разными системами. очень импонируют подробно и толково расписанные инструкции по эксплуатации, обилие самой разнообразной информации на сайте. Я хочу рекомендовать заказать такое оборудование, как автоматика итп (http://www.teplocom.msk.ru/catalog/bitp/itp/) от Теплоком-Сервис Москва. теперь о грустном. приборы ваши начали использовать около 10 лет назад. за это время в линейке приборов, которые мы используем произошли лишь незначительные изменения. а хотелось бы расширения номенклатуры ваших приборов. в частности, занимаясь проектированием итп, цтп, столкнулись с такой проблемой: итп как правило, оборудовано 3–4 насосными группами, плюс 2-3 регулятора. в итоге на дверку шкафа автоматики приходится устанавливать 6-7 приборов с лицевой панелью 96х96 мм, туда же надо пристроить до 8 переключателей, индикаторы, иногда и кнопки управления. и получается дверка очень перегруженной. а увеличивть габариты щита часто не представляется возможным. регуляторам самое место на дверке, они отображают полезную для оператора информацию. ну а сау-мп там не место, на приборе индицикация, интересная лишь наладчику. напрашивается вывод: устанавливать сау-мп внутрь щита. но этих приборов в Din-реечном исполнении не существует. навесное исполнение тоже не очень подходит для внутришкафного монтажа. пожалуйста, выпустите прибор в Dinовском корпусе.
второе, нет подходящей модификации сау-мп для автоматизации насосов подпитки с одновременным управлением соленоидным или запорно-регулирующим клапаном подпитки. приходится изгаляться.
третье, неудобство программирования сау-мп представляется несложной проблемой, добавление возможности удобного и полноценного программирования в сам прибор наверняка не сделает его дороже в разы. можно также сконструировать отдельный блок с цифровым индикатором, с которого станет возможным программировать подключаемый к нему сау, а еще лучше сделать возможным подключение к такому блоку нескольких приборов сау-мп по отдельному интерфейсу. в таком случае потребитель сам сможет решать - какой вариант ему больше подходит, программировать ли прибор с помощью компьютера, или потратиться на приобретение программатора.
четвертое, для сау-мп тоже необходим интерфейс для ввода его в сеть с возможностью передачи данных с него (номер работающего насоса, отсутствие или наличие «аварии») в диспетчерскую. неплохо было бы иметь возможность также выводить на диспетчерскую информацию о положении «авт» переключателя «авт-0-руч» соответствующего насоса. это просто, т.к. в настоящее время сухие контакты этих переключателей, соединенные параллельно подключаются на вход «пуск» сау-мп. можно использовать еще один вход для «пуска». по любому замкнутому из них (насос№1, насос№2) прибор будет запускать программу, а в диспетчерскую уйдет сигнал о положении переключателя каждого из насосов.
пятое, часто сталкиваемся с вариантом, когда в тепловом пункте имеется две системы с регулированием температуры по наружному воздуху. соответственно устанавливаем два трм32, два датчика наружного воздуха и тянем две кабельные линии (как правило, достаточно длинные). удобней было бы иметь возможность получать данные о температуре с одного датчика по сети (разумеется, если таковая используется).
шестое, представляется очень интересным вариант, когда в одном приборе объединяются один регулятор температуры и полнофункциональное управление 2-мя циркуляционными насосами. причем регулятор такого комбинированного прибора должен быть универсальным: т.е. с возможностью использовать его как в системе отопления (вентиляции), так и в системе гвс. такой прибор наверняка будет иметь хороший спрос, т.к. будет достаточен для автоматизации любого контура в тепловом пункте (без подпитки).


с уважением.
владимир.


разумный подход.