Диспетчеризация автоматики по Modbus

[Kenai]

Здравствуйте!

Нам необходимо собирать данные с 40 шкафов автоматики и передавать на общий пульт с какой -либо панелью.Расстояние между шкафами 10-15метров, расстояние до пульта от места расположения шкафов - 250метров. Общая протяженность сети получается около 600-800метров.
В шкафах - релейная логика и преобразователи частоты. Собираемые данные - состояние контактов реле (5 параметров) и аналоговые сигналы (3 параметра) , а так же параметры преобразователя частоты ( 5 параметров). И так для каждого шкафа.
В шкафы можно установить какие-нибудь простые модули для сбора сигналов и передачи их по Modbus RTU, например : типа ОВЕН МВ110-8А и ему подобные.
В результате имеем 120 опрашиваемых устройств : 40 преобразователей частоты, 40 модулей обработки дискретных сигналов, 40 модулей обработки аналоговых сигналов.
Уважаемые коллеги, посоветуйте пожалуйста какое-нибудь решение данной задачи? Интересует опыт применения подобного оборудования , например ОВЕН или чего-нибудь другого, какую сенсорную панель применить (для управления 3мя параметрами каждого из ПЧ и отображения всей информации) - интересует производитель и диагональ, чтобы наглядно все отобразить.

В общем буду рад любым комментариям по данной проблеме.
Спасибо!

[alex_ugrumov]

120 устройств на 485 шине - многовато. Понятно, что по для исправления ситуации по нагрузочной способности можно поставить повторители. но цикл опроса всё равно будет безрадостным. Хотя можно, если панель позволяет, опрашивать, только часть модулей (ту параметры с которых в настоящий момент на экране).... Хотя по правильному нужно разбить на отдельные шины, например по пять шкафов на шину - 8 шин. 15 модулей на шине. Но в панелях обычно 1-2 СОМ порта... Поэтому нужно взять панель с Ethernet и преобразователи modbus tcp > modbus rtu. А если найдётся преобразователь сразу на много сом поров - ещё лучше.
Что касается панели - Wientek, диагональ выбирается исходя из того, сколько информации необходимо расположить на одном экране. Получается около полутыщи параметров - понятно, что нужно много экранов, но Вам решать, что необходимо отобразить на одном.
Но Овне такое не делал, а на ICPDAS работало. длина линии была 4км (с повторителями, конечно), правда число точек поменьше было.

[Kenai]

Скорее всего панель будет Wientek, но она будет slave. Для опроса в шкафу с панелью установим ПЛК.
А вообще можете порекомендовать недорогую панель master с функциями ПЛК? Я читал про подобное у OMRON,но название сейчас не помню.Нужна панель,которая могла бы считать целиком слово состояния преобразователя частоты.
Скажите, а как часто в сети Modbus RTU следует ставить повторители? Что-то помню про 32 и 28 клиентов и не помню в каком случае что.

[san]

Скорее всего панель будет Wientek, но она будет slave. Для опроса в шкафу с панелью установим ПЛК.
А вообще можете порекомендовать недорогую панель master с функциями ПЛК? Я читал про подобное у OMRON,но название сейчас не помню.Нужна панель,которая могла бы считать целиком слово состояния преобразователя частоты.
Скажите, а как часто в сети Modbus RTU следует ставить повторители? Что-то помню про 32 и 28 клиентов и не помню в каком случае что.

Wientek не может быть Мастером? Панели быстрее Модбас слейвами могут не быть, а Мастерами как раз всегда.
Я за Ethernet, если условия позволяют. Например на несколько щитов (например 5-ть) постваить несколько шлюзов Modbus-TCP - Modbus RTU. По дороге к диспетчерской придется ставить повторители Ethernet. Ну где-то так:
Panel ModbusTCP <> Ethernet<>repiter<>Ethernet<>Ethernet Switch<>ModbusTCP to RTU on 485 Gateway<>ModbusRTU on RS485<>Device-Device-Device

[Alexander]

Ну это вообще, что-то с чем-то.... Как можно в принципе использовать панель, как слейв, в подобной системе? Ну, можно-то конечно можно, но это сколько-же изврата, и ради чего? Насчет панелей Weintek на 100% согласен с коллегой alex_ugrumov.

[Serex]

Не обязательно шлюз ставить. Можно и виртуальные COM-порты применить, если панель позволяет такое. Соответственно выборочно в шкафах ставить СОМ-серверы и туда заводить RS-485 хвосты.

[san]

Не обязательно шлюз ставить. Можно и виртуальные COM-порты применить, если панель позволяет такое. Соответственно выборочно в шкафах ставить СОМ-серверы и туда заводить RS-485 хвосты.

Что такое СОМ-серверы? Удаленные виртуальные СОМ-порты?
Думаю что на такое количество устройств (даже если их будет 40) городить чего-то на 485-м с низкими скоростями, даже при 20кбит/с будет очень медленно. Думаю надо все-таки лепить шлюзы, так как количество шлюзов будет знаменателем в периоде опроса устройств (приблизительно).
Ну например, если на 120 девайсах поставить 2 шлюза, период опроса по таким же линиям с теми же скоростями упадет по сравнению с исходными где-то в 2-раза, з шлюза - в 3 раза и.т.д.
Можно обойтись даже без повторителей. Например поставить между щитами и диспетчерской промежуточный щиток, на расстоянии от диспетчерской около 50 м. Туда воткнуть свитч, все шлюзы, кинуть количество кабелей на 485-е линии = количеству шлюзов + питание. Можно шлюзы даже в самой диспетчерской бросить, но пойдет много кабеля (конечно всё зависит от расположения).
Кстати, в зависмости от частотника, там можно задействовать входы/выходы, если их конечно хватает. 3AI - конечно многовато, врят ли их там столько есть.

[Kenai]

Ну это вообще, что-то с чем-то.... Как можно в принципе использовать панель, как слейв, в подобной системе? Ну, можно-то конечно можно, но это сколько-же изврата, и ради чего? Насчет панелей Weintek на 100% согласен с коллегой alex_ugrumov.

Да мы тут перемудрили изрядно. Управляет всем SCADA. Панель нужна только для установки по месту, чтобы не делать более чем 500 лампочек и индикаторов. Информация выдаваемая на панель фактически никем не используется, а ее необходимость -дань традиции вывода в информации в данное место.

Кстати, в зависмости от частотника, там можно задействовать входы/выходы, если их конечно хватает. 3AI - конечно многовато, врят ли их там столько есть.

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

[san]

Думаю надо все-таки лепить шлюзы, так как количество шлюзов будет знаменателем в периоде опроса устройств (приблизительно).
Ну например, если на 120 девайсах поставить 2 шлюза, период опроса по таким же линиям с теми же скоростями упадет по сравнению с исходными где-то в 2-раза, з шлюза - в 3 раза и.т.д.
Можно обойтись даже без повторителей. Например поставить между щитами и диспетчерской промежуточный щиток, на расстоянии от диспетчерской около 50 м. Туда воткнуть свитч, все шлюзы, кинуть количество кабелей на 485-е линии = количеству шлюзов + питание. Можно шлюзы даже в самой диспетчерской бросить, но пойдет много кабеля (конечно всё зависит от расположения).

Сказал....а потом подумал что сказал....
Это ещё нужно такой шлюз найти, чтоб сам сканировал Slave и отображал на свое адресное пространство, а потом Modbus клиент считывал это одним махом. Такие есть, но думаю что денежек будут стоить не мало. Или нужно чтоб Modbus Client (например SCADA) оптимизировала запросы сразу на несколько ай-пи адресов (тесть шлюзов). А если драйвер будет опрашивать всех постепенно, скорость опроса всех устройств сравнительно с системой без шлюзов от этого не поменяется.

[alex_ugrumov]

Ну это вообще, что-то с чем-то.... Как можно в принципе использовать панель, как слейв, в подобной системе? Ну, можно-то конечно можно, но это сколько-же изврата, и ради чего? Насчет панелей Weintek на 100% согласен с коллегой alex_ugrumov.

Да мы тут перемудрили изрядно. Управляет всем SCADA. Панель нужна только для установки по месту, чтобы не делать более чем 500 лампочек и индикаторов. Информация выдаваемая на панель фактически никем не используется, а ее необходимость -дань традиции вывода в информации в данное место.

Кстати, в зависмости от частотника, там можно задействовать входы/выходы, если их конечно хватает. 3AI - конечно многовато, врят ли их там столько есть.

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

Ну Скада, так проблемы то те же. Вы со скада будете все 120 устройств по одной шине опрашивать? Или СОМ портов натыкаете в АРМ? Или контроллер поставите, который будет собирать инфу со всех шкафов и отдавать АРМу, скажем по etnernet?
В общем задача такая: есть десять шкафов и есть АРМ со скадой для штатного управления. Плюс по традиции местное управление, которое на хочется делать на лампах и кнопках. Плюс есть момент с частотниками - а именно настройка некоторых параметров. Основная задача управления по месту - сохранять контроль в случае выхода из строя АРМ.
Дальше много непоняток.
Не очень понятна функция АРМ. Изначально говорилось, что в шкафах релейная логика, что, как я понимаю, подразумевает управление по месту теме же лампами/кнопками (должен же быть грибок, и банально кнопка "поехали"?). Потом говориться, что у Вас будет "всем управлять Скада". А управлять как? сигналы на релюшки откуда будут браться? То есть будут какие-то модули УСО. А если УСО сдохнет? или АРМ? то управлять всё равно по месту лампами / кнопками? то есть лампы/кнопки всё равно по месту в каждом шкафу будут. Есть выход - ставиться в каждый шкаф контроллер с панелькой. Тогда релейная логика не нужна.
не ясно что такое управление по месту? Если доступ к каждому шкафу (тогда логичнее делать управление по месту в каждом шкафу отдельно)? Или нужно сделать отдельный пульт / шкаф в который вывести 500 ламп?

Я вижу следующие варианта:
1) 10 шкафов с релейной логикой и лампами / кнопками в каждом шкафу. Параметры частотника задаются с пульта самого частотника. Скада - для управления из диспетчерской и задания параметров в частонике удалённо, в каждый шкаф ставятся УСО для удалённого запуска / останова и мониторига. В случае выхода из строя АРМ или УСО - управление по месту лампами и кнопками. Централизованного управления с панели по мету нет, так как есть локальное управление в каждом шкафу
2) 10 шкафов, в каждом релейная логика заменена контроллером. В каждом шкафу - маленькая панелька для управления по месту (Или контроллер с экранчиком, например, Сигнетик). Дальше АРМ, который даёт команды контроллерам из диспетчерской. Связь диспетчерская - контроллер по Ethernet или COM в зависимости от возможностей контроллера. В принципе можно и централизованную панель поставить по месту. Тогда если используется Ethrenet и контроллер поддерживает более одного соединения по Ethernet, можно пользоваться им и для АРМ и для центральной панели. Если По СОМ, то нужен отдельные СОМ на контроллере для АРМ и для центральной панели, Плюс скорее всего по СОМ будут связаны местная панель и контроллер. И ещё один СОМ для частотника. Контроллер с 4-мя СОМ портами.... Только что-то типа ICP-DAS - тут вопрос программирования (С или СофтЛоджик портированный). Контроллеры типа PLC (не придирайтесь к терминологии, я для себя по крайне мере чёткого определения не вывел, ну, пример - Митсубиси или Омрон - те, что с 61131 и своими средами разработки) с 4 СОМ портами на малое число входов выходов - не попадалось. Кстати, если ткнёте меня в такие, а ещё лучше 8 СОМ портов и свободно программируемые, буду благодарен. по программированию - хороший вариант. если шкафы абсолютно одинаковые - на одном отладились - дальше копипаст.
3) То же самое, что п. 2 но без панелей в каждом шкафу. но с центральной панелью. Минус такого решения - поломка сети, панели, АРМ - полное отсутствие управления (конечно защиты контроллер будет отрабатывать, но передать команду на него не получиться).
4) релейная логика в шкафах. один центральный контроллер с панелью, УСО в каждом шкафу. Панель и АРМ работают с контроллером. Контроллер с УСО и частотниками. Понадобиться или контроллер на много СОМ портов, или Ethernet со шлюзами Модбас ТСР - Модбас РТУ или Ethernet УСО. Выход из стоя сети или центрального контроллера - полное отсутствие управления. Вообще решение кривое.

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

Что касается нагрузочной способности по 485 - по факту зависит от конкретных поставщиков. Что касается времени цикла опроса - зависит от скорости ответа конкретных УСО, дальше посчитать на разных скоростях не проблема: длина пакетов Модбас известна.

[Serex]

Что такое СОМ-серверы? Удаленные виртуальные СОМ-порты?

Именно так. Любая нормальная SCADA или ОРС будут читать с этих портов одновременно сразу со всех. Я сам такую прогу (для работы с несколькими портами) писал в универе, все работает.
В качестве СОМ серверов рекомендую МОХА.

[alex_ugrumov]

Что такое СОМ-серверы? Удаленные виртуальные СОМ-порты?

Именно так. Любая нормальная SCADA или ОРС будут читать с этих портов одновременно сразу со всех. Я сам такую прогу (для работы с несколькими портами) писал в универе, все работает.
В качестве СОМ серверов рекомендую МОХА.

Если про ту же МОХА, то панель должна быть с СЕ или ХР эмбедит, чтобы поднять Real COM Driver. Но не факт, что ПО для разработки проекта для этой панели позволит указать номер СОМ порта отличный от штатно установленных . Другой вариант работать в режиме TCP server, но тут нужно объяснить панели, что нужно работать по TCP, но по протоколу Modbus RTU.

[Степа]

цикл опроса всё равно будет безрадостным

Думаю что на такое количество устройств (даже если их будет 40) городить чего-то на 485-м с низкими скоростями, даже при 20кбит/с будет очень медленно.

Для повышения образованности: а из каких соображений сделаны такие выводы? Вроде как автор не озвучивал требования по времени цикла. Его, может, устраивает, обновление данных раз в минуту - для диспетчера вполне себе нормальное время обновления информации?

Скажите, а как часто в сети Modbus RTU следует ставить повторители? Что-то помню про 32 и 28 клиентов и не помню в каком случае что.

По стандарту в одном сегменте не может быть больше 32 устройств, сегмент не может быть длиннее 1200 метров. Хотя все сильно зависит от используемого оборудования. Скажем, уже упомянутые тут преобразователи Ethernet-RS485 от MOXA /MOXA NPort 5430i, если быть точным/ на линию 800 метров работать не смогли, а вот ADAM 4520 ту же линию "пробил" без шуму и пыли, несколько лет без замечаний отработал.

[san]

Для повышения образованности: а из каких соображений сделаны такие выводы? Вроде как автор не озвучивал требования по времени цикла. Его, может, устраивает, обновление данных раз в минуту - для диспетчера вполне себе нормальное время обновления информации?

Может и хватит. Проблема даже не в самой скорости, а во времени ответа. Это ж не в буфер залезть, вынять всё и послать. Реализация Модбас, прошита в каком то чипе или в ОСе нужно принять кадр, разобрать че от него хотят, залезть в память (возможно не свою) и сформировать ответный кадр. Вобщем всй зависит от реализации. Если это совмещается еще с какими то задачами (в частотнике), то всё это наверняка делается в цикле, вначале или в конце.

[alex_ugrumov]

цикл опроса всё равно будет безрадостным

Думаю что на такое количество устройств (даже если их будет 40) городить чего-то на 485-м с низкими скоростями, даже при 20кбит/с будет очень медленно.

Для повышения образованности: а из каких соображений сделаны такие выводы? Вроде как автор не озвучивал требования по времени цикла. Его, может, устраивает, обновление данных раз в минуту - для диспетчера вполне себе нормальное время обновления информации?.

Из опыта - локальная система мониторинга / диспетчеризации / оперативного контроля - да пусть она пошустрее показывает. не GSM же какой-то. Понятно. что есть процессы, в которых минута - не время, но аппетит приходит во время еды и заказчик при cдаче удивиться, почему там уже не работает, а тут всё ещё показывает, что работает. Ещё больше удивиться, увидев подписанное собственноручно ТЗ. Но что касается панели - то она скорее всего будет опрашивать только те параметры, которые её нужно показать сейчас на экране (опять же с оговорками. что нужно смотреть на конкретные панели), так что показывать будет оперативно. Так как не было озвучено требований по циклу. как и многих других, заостряем внимание на возможных проблемах.

Скажите, а как часто в сети Modbus RTU следует ставить повторители? Что-то помню про 32 и 28 клиентов и не помню в каком случае что.

По стандарту в одном сегменте не может быть больше 32 устройств, сегмент не может быть длиннее 1200 метров. Хотя все сильно зависит от используемого оборудования. Скажем, уже упомянутые тут преобразователи Ethernet-RS485 от MOXA /MOXA NPort 5430i, если быть точным/ на линию 800 метров работать не смогли, а вот ADAM 4520 ту же линию "пробил" без шуму и пыли, несколько лет без замечаний отработал.

Да, столкнулся с тем же: разочаровала МОХА свой нагрузочной способностью (как нам говорили - у них очень большое сопротивление в подтяжках линий). Ставим теперь повторители ICP-DAS, сразу за СОМ портами МОХА-контроллеров, если нужно протащить шину от 500м и больше.

[Степа]

Проблема даже не в самой скорости, а во времени ответа.

Время ответа зависит от конструкции конкретных приборов. Сейчас вот посмотрел, у меня тут приборчик по Modbus опрашивается /порядка 200-300 16-битных регистров/, так полный цикл опроса в 0.5 секунды укладывается не напрягаясь: судя по индикаторам половину этого времени канал просто простаивает. Т.е. 120 устройств вполне могут быть опрошены хотя бы раз за минуту, а то и дважды. Особенно если взять во внимание, что обычно дискретные и аналоговые модули не имеют огромного набора регистров и опрашиваться будут побыстрее.
А дальше от заказчика зависит. Если его устроит такое положение вещей, то и реализовывать.

Из опыта - локальная система мониторинга / диспетчеризации / оперативного контроля - да пусть она пошустрее показывает.

Тут масса тонкостей... Мониторинг\диспетчеризация - это, как правило, издалека на процесс смотрят и не всегда имеют возможность сравнивать видимую информацию на экране и в реале, и им минута-другая на обновление особой роли не играет. Оперативный контроль - тут уже есть возможность смотреть на процесс еще и глазами и тогда многое зависит от собственно процесса: если процессы быстрые, то и информацию побыстрее обновлять. Скорость - сообразуясь с самыми быстрыми процессами: никто не поймет, скажем, ситуацию "заслонка открыта реально 10 секунд, а на экране показывается открытой - две минуты". Если еще и управление задействовано, то раза три-четыре в секунду.
Как-то так, в общем.
И все времена надо бы обсуждать с заказчиком, чтобы при сдаче в эксплуатацию вдруг не выяснилось, что для заказчика понятие "реальное время" означает обновление десять-пятнадцать раз в секунду минимум.

[san]

Время ответа зависит от конструкции конкретных приборов. Сейчас вот посмотрел, у меня тут приборчик по Modbus опрашивается /порядка 200-300 16-битных регистров/, так полный цикл опроса в 0.5 секунды укладывается не напрягаясь: судя по индикаторам половину этого времени канал просто простаивает. Т.е. 120 устройств вполне могут быть опрошены хотя бы раз за минуту, а то и дважды. Особенно если взять во внимание, что обычно дискретные и аналоговые модули не имеют огромного набора регистров и опрашиваться будут побыстрее.

Время ответа зависит от прибора - согласен. Но дело не в количестве регистров/битов а в том, когда это прибор примет с буфера посылку и когда отправит ответ. Если скажем Слейвом является устройтсво типа ПЛК, и работа с сетевым буфером происходит тогда же, когда опрос входов и запись выходов, то цикл этого же ПЛК и будет самым большим торомзом. Сколько там у частотников - я не знаю. Паузы между обменом ком. сопроцесором или платой и главным процом могут быть большими, а если этим нагружен основной процесор - то ещё большим. А как влияет количество регистров - это как раз расчетная величина.

[Serex]

работа с сетевым буфером происходит тогда же, когда опрос входов и запись выходов, то цикл этого же ПЛК и будет самым большим торомзом.

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

[Василий Иванович]

Это ещё большой вопрос, кто быстрее сработает, CP или CPU. Опросить-то можно и сто раз за цикл, а вот дождаться ответа в том же цикле - далеко не факт. Впрочем, если речь идёт о Modbus RTU, то про времена цикла контроллеров я бы не задумывался.

Мне нравится подход, высказанный san. Шлюзы Anybus делают примерно то, что он описывал, и стоят пару-тройку сотен евро каждый. Не бог весть какие деньги.