Умный дом на Modbus, Получится ли дешево, сердито, но функционально? Опции

[kosmos440o]

Освещение по KNX? А то на модбасе возможно запаздывание.

[kosmos440o]

Освещение по KNX? А то на модбасе возможно запаздывание.

[Alexander_I]

И что же ужасного в этом *запаздывании*? Кто-то заметит запаздывание в 200 миллисекунд, например?

[manjey73]

Alexander_I - 200 мс заметно, до 50-ти нормально

[kosmos440o]

Всё зависит от СКАДы. Можно и за 10 мсек включить. Отклик на экране можно долго ждать, а это в доме напрягает.

[Qwerty88]

Себе в дом делаю систему управления климатом и освещением. Для включения освещения использую импульсные реле, установленные в щитке. Выключатели в помещениях типа "кнопки". Нажал - свет включился, еще раз нажал - выключился. В щитке паралелльно кнопкам контроллер Pixel. Таким образом можно включть/выключать как по месту так и удаленно. Состояние импульсных реле подключаю на дискретные входы контроллера - таким образом в пульте видно состояние освещения в комнатах.

[Demus]

Освещение по KNX? А то на модбасе возможно запаздывание.

Освещение управляет контролер с модбас TCP. запаздывания нет совсем.

[sergeba]

У меня контроллер ОВЕН 304. На него завязал управление отоплением и контурами тёплого пола, свет, жалюзи, управление телевизорами, кондиционерами, вентиляцией, вытащил кабель на улицу - подключил приводы к теплицам (двери с форточками для проветривания открываются), контролирую в теплицах температуру/влажность, в перспективе буду подключать принудительную вентиляцию и полив. Модули Insyte и китайщина.
Для управления использую тач-панель и ИК-пульты.
Задержки присутствуют. Включение света терпимо, управление телевизором не очень...
Использую в качестве тач-панели iPad. Для него нашёл встраиваемый короб в стену. На iPad "крутится" MySCADA. Её же можно установить и на смартфоны с Андроидом.

[Сергей А. Ефремо...]

Круто! А как iPаd коннектите с контроллером?

[manjey73]

Сергей А. Ефремов - вероятно по TCP, а тут уже не важно на чем Scada работает...

[kosmos440o]

Я недавно сделал один iдевайс с Ethernet, управляемый по модбасу из UDP, прилепил туда парочку входов - выходов, время включения из OPC сервера около 30 мсек, из Мастерскады 1-2 секунды. То есть действуют задержки передачи из одного ПО в другое, там постановка в очередь. Наверно можно быстрее, просто у меня цикл опроса 1 сек стоял.

Сообщение отредактировал kosmos440o - 11.9.2018, 9:52

[Demus]

Я недавно сделал один iдевайс с Ethernet, управляемый по модбасу из UDP, прилепил туда парочку входов - выходов, время включения из OPC сервера около 30 мсек, из Мастерскады 1-2 секунды. То есть действуют задержки передачи из одного ПО в другое, там постановка в очередь. Наверно можно быстрее, просто у меня цикл опроса 1 сек стоял.

Почти везде во всех скадах управляющее воздействие по модбасу передается вне очереди опроса. Т.е. нажал кнопку включить - сразу ушел сигнал. ТО, что лампочка загорелась в скаду придет после цикла опроса.
В модбас TCP задержки управления не видно от слова совсем. В РТУ ее тоже не видно.
При чем у меня сигнал сначала идет по KNX потом в сервер потом в модбас и потом на реле).

Сообщение отредактировал Demus - 12.9.2018, 9:06

[manjey73]

Demus после отправки команды выполните опрос устройства для контроля и все. Ну это если Scada позволяет такое...

[kosmos440o]

Почти везде во всех скадах управляющее воздействие по модбасу передается вне очереди опроса. Т.е. нажал кнопку включить - сразу ушел сигнал. ТО, что лампочка загорелась в скаду придет после цикла опроса.
В модбас TCP задержки управления не видно от слова совсем. В РТУ ее тоже не видно.
При чем у меня сигнал сначала идет по KNX потом в сервер потом в модбас и потом на реле).

как я понимаю, в скаде в цикле идёт опрос изменений, потом эти изменения передаются OPC-серверу, и только потом он включает передачу (естественно, что без очереди). Лампочка-то у меня на столе лежит, я вижу, через сколько она включается.

[Demus]

как я понимаю, в скаде в цикле идёт опрос изменений, потом эти изменения передаются OPC-серверу, и только потом он включает передачу (естественно, что без очереди). Лампочка-то у меня на столе лежит, я вижу, через сколько она включается.

1. в этом умном доме совсем не скада.
2. работал с трейсмод на протяжении 10 лет. + контроллеры дельта. задержек не замечал больше 1 с. wincc с сименсом - тоже самое. хотя там встроенные драйверы. как таковой opc отдельный не используется.

Сообщение отредактировал Demus - 12.9.2018, 18:24

[sergeba]

А как iPаd коннектите с контроллером?

Scada крутится на iPad, через TCP по Wi-Fi

[Rapid]

2. работал с трейсмод на протяжении 10 лет. + контроллеры дельта. задержек не замечал больше 1 с.

Разумеется, задержка зависит от количества устройств и числа считываемых регистров. Её, собственно, легко посчитать - описание RTU открыто и доступно. Если у вас одно устройство и с десяток регистров, нормальная скорость, то и задержки не будет заметно.
А если устройств 5-6 и в каждом по паре сотен регистров, то заметно будет, и сильно заметно. Для умного дома это будет катастрофа. Особенно, если одно из устройств перестанет отвечать.
Вообще модбас, и любой другой протокол, в котором опрос циклический - это зло для умного дома. Только мультимастер, только телеграммы.

TCP выглядит лучше за счёт того, что это всё-таки PtP и клиенты не ждут друг друга, да и скорость обмена по сравнению с RTU просто космическая.
Но если ваш контроллер сидит на RTU и вы общаетесь с клиентами по TCP через шлюз - скорее всего все проблемы вернутся, тут всё зависит от возможностей шлюза.

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

[Demus]

Разумеется, задержка зависит от количества устройств и числа считываемых регистров. Её, собственно, легко посчитать - описание RTU открыто и доступно. Если у вас одно устройство и с десяток регистров, нормальная скорость, то и задержки не будет заметно.
А если устройств 5-6 и в каждом по паре сотен регистров, то заметно будет, и сильно заметно. Для умного дома это будет катастрофа. Особенно, если одно из устройств перестанет отвечать.
Вообще модбас, и любой другой протокол, в котором опрос циклический - это зло для умного дома. Только мультимастер, только телеграммы.

TCP выглядит лучше за счёт того, что это всё-таки PtP и клиенты не ждут друг друга, да и скорость обмена по сравнению с RTU просто космическая.
Но если ваш контроллер сидит на RTU и вы общаетесь с клиентами по TCP через шлюз - скорее всего все проблемы вернутся, тут всё зависит от возможностей шлюза.

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

Так он живет уже год в квартире и пользуется)
По RTU с десяток датчиков , три ПЛК с примерно сотней регитстров в каждом. ПО TCP один ПЛК тоже наверное сотня регистров. На KNX только сенсорные панели в каждой комнате и коридорах.
Недавно вот еще поставили шлюз из РТУ в TCP потому, что порт РТУ главного контроллера выгорел, утащив с собой несколько устройств)
Заказчик технически подкован, лапшу на уши, что так и должно быть, не повесить. Сам может и плату спаять и выключатель китайский с вай фаем установить.
Я ж говорю, спасает, только, то что команды управления без очереди уходят. Сколько бы опроса не было.

[manjey73]

можно и Modbus использовать с умом. А для скорости.
1. команды должны уходить вне очереди, и главное опрос для обратной связи на команду так же должен выполниться следом
2. разделять интерфейсы
3. поднять скорость, а не использовать 9600
4. читать пачками (групповой запрос)
5. разделить интерфейсы

з.ы. меня 300 мс уже бесит

[Ashihara]

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

Я на триме сегнетиковом делаю, проблем с быстродействием нет, там все порты параллельно работают. Я даже пока не парюсь с балансировкой трафика. Правда выключатели света на сеть и не думаю вешать)

[Demus]

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

Я на триме сегнетиковом делаю, проблем с быстродействием нет, там все порты параллельно работают. Я даже пока не парюсь с балансировкой трафика. Правда выключатели света на сеть и не думаю вешать)

толково, спасибо за совет)

[LordN]

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

Я на триме сегнетиковом делаю, проблем с быстродействием нет, там все порты параллельно работают. Я даже пока не парюсь с балансировкой трафика. Правда выключатели света на сеть и не думаю вешать)

непонятно, в чем именно плюс?

[Ashihara]

непонятно, в чем именно плюс?

Плюс двух сетей?

[LordN]

Плюс двух сетей?

да

[yozik]

да

Данные необходимые для управления (команды) проходят без задержек.
Т.к. сеть "ненагруженна".

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

[manjey73]

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

[yozik]

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

Для этого надо иметь очередь.
А не все протоколы и не все устройства (ПО) такое позволяют.

[manjey73]

yozik устройства нет, речь то о Modbus, а ПО да, должно позволять отправлять команду и выполнять опрос устройства на которое послали команду сразу после отправки команды для обратной связи.

Собственно очередь формируется и так программно, один интерфейс, мы указываем программе запросы 10-ти устройств. В какой последовательности указали, в такой и будет происходить опрос.

Сообщение отредактировал manjey73 - 19.2.2019, 9:08

[Ashihara]

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

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

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

Кабели для RS485 есть и двупарные. Вот так и тащишь две сети рядом одним кабелем. Реально хорошая альтернатива CAN/LON, которые хоть и имеют приоритеты посылок/абонентов, но валовая полоса пропускания у нех не ахти даже на мегабите.

[yozik]

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

На этот счет тоже мысли были, но подумал "тапками закидают"
Тапки
А как же подтверждение что команда дошла?
Так что дважды это мало.

yozik устройства нет, речь то о Modbus,

Так у Modbus как раз и нет никаких приоритетов.
И две сети Modbus и позволяют избавится от многих недостатков протокола.

еально хорошая альтернатива CAN/LON, которые хоть и имеют приоритеты посылок/абонентов

[Ashihara]

На этот счет тоже мысли были, но подумал "тапками закидают"
Тапки
А как же подтверждение что команда дошла?
Так что дважды это мало.

Это уже как пожелаете) Я лишь указал возможность, а подтверждение можно получить и по каналу данных, если оно не очень важно по времени. Ну типа, сказали всем включиться, а потом за 2-3-4 секунды все это подтвердили при штатном обмене.

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