Переход на Modbus

weary
Offline
Зарегистрирован: 19.01.2018

Добрый день.

Дома несколько лет работает сеть из 4 ардуино, выполняя роль некоторой  автоматизации дома, которые общаются по моему собственному протоколу. Со временем стало не хватать плюшек промышленного протокола. Выбор пал на Modbus. Всё просто всё понятно, когда нужно просто таскать значения переменных, будь данные с датчиков или статусы.

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

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

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

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

На схеме один из элементов моей сети для наглядности. Буду благодарен за ваши мысли.

 

 

 

sadman41
Offline
Зарегистрирован: 19.10.2016

Не совсем понятно какие проблемы с модбасом. Но, для начала, обьясните что волшебного Вы в нем пытаетесь найти - какие плюшки?

nik182
Offline
Зарегистрирован: 04.05.2015

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

MaksVV
Offline
Зарегистрирован: 06.08.2015

weary пишет:
Основная разница в том что мо протокол работал по принципу  - отправить новое значение, только если оно изменилось. В Модбасе же регистр будет обновляться автоматически, и возникает множество вопросов с тем кто последний изменил статус, отработало ли реле по этому статусу, актуален ли еще это запрос и так далее.

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

Нужно разделить данные на статусы и команды (также можно ещё ввести отчеты о выполнении команды).

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

Если кнопка находится на той же ардуине, что и реле, то нажимаем на кнопку включения - реле включается. В модбасе сразу обновляется его состояние на "вкл".

Теперь можем послать команду "выкл" по ethernet->модбас  с другой ардуины.  Первая ардуина получает эту команду по модбасу и выключает реле, соответственно сразу опять изменив статус реле на "выкл" при очередном обмене с мастером. 

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

команда посылается, например, три раза (три сеанса со слейвом), если не получен отчёт о её выполнении. 

Вроде проблем никаких.

 

 

 

weary
Offline
Зарегистрирован: 19.01.2018

MaksVV пишет:

weary пишет:
Основная разница в том что мо протокол работал по принципу  - отправить новое значение, только если оно изменилось. В Модбасе же регистр будет обновляться автоматически, и возникает множество вопросов с тем кто последний изменил статус, отработало ли реле по этому статусу, актуален ли еще это запрос и так далее.

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

Нужно разделить данные на статусы и команды (также можно ещё ввести отчеты о выполнении команды).

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

Если кнопка находится на той же ардуине, что и реле, то нажимаем на кнопку включения - реле включается. В модбасе сразу обновляется его состояние на "вкл".

Теперь можем послать команду "выкл" по ethernet->модбас  с другой ардуины.  Первая ардуина получает эту команду по модбасу и выключает реле, соответственно сразу опять изменив статус реле на "выкл" при очередном обмене с мастером. 

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

команда посылается, например, три раза (три сеанса со слейвом), если не получен отчёт о её выполнении. 

Вроде проблем никаких.

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

Спасибо

 

weary
Offline
Зарегистрирован: 19.01.2018

sadman41 пишет:

Не совсем понятно какие проблемы с модбасом. Но, для начала, обьясните что волшебного Вы в нем пытаетесь найти - какие плюшки?

Этих плюшек масса в сравнении именно с моим собственным протоколом, п э нет смысла их обсуждать.

 

asam
asam аватар
Offline
Зарегистрирован: 12.12.2018

А может стоит в сторону MQTT посмотреть?

MaksVV
Offline
Зарегистрирован: 06.08.2015

Mqtt поверх физики rs485, имхо не очень. Может если шину на CAN переделать (сама линия подходит от rs485). Давно хотел попробовать mqtt поверх CAN построить. Может был у кого опыт?

sadman41
Offline
Зарегистрирован: 19.10.2016

weary пишет:

Этих плюшек масса в сравнении именно с моим собственным протоколом, п э нет смысла их обсуждать.

Нет, так нет. Однако на модбасе свет клином не сошёлся.

sadman41
Offline
Зарегистрирован: 19.10.2016

MaksVV пишет:
Mqtt поверх физики rs485, имхо не очень. Может если шину на CAN переделать (сама линия подходит от rs485). Давно хотел попробовать mqtt поверх CAN построить. Может был у кого опыт?

Геморройно. В MQTT основа - это строка, а не 8 байт, как в CAN. Есть промышленные реализации протоколов на CAN-шине (позволяют байтстримы передавать), но они частично закрытые, частично замороченные. См. Canopen, DeviceNet. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

да не особо, я думаю. Можно ведь серию CAN кадров делать. И функцию, которая это все граммотно упаковывает. Либо брать от CAN только физику (CAN трансиверы) , но предётся мучиться с ручным арбитражем на шине. Что проще решает каждый сам. По мне дак легче мультрифреймы организовать. 

т.е. сделать открытый и не замороченный протокол, чтобы ниче лишнего. Велосипед будет правда однако, скорее всего

sadman41
Offline
Зарегистрирован: 19.10.2016

Упаковывать - мало. Надо будет на верхнем уровне изобретать адресацию типа IP, следить за целостностью frame chain (ты же помнишь о приоритете и уничтожении кадра с меньшим приоритетом в случае коллизии?), придумывать, как залепить ACK и т.д. и т.п. 

В point-to-point сценарии всё, конечно, выглядит волшебно и без этих штук, но зачем в таком случае CAN?

MaksVV
Offline
Зарегистрирован: 06.08.2015

в принципе согласен. Но на простых схемах, где шина не загружена,  можно и без этого обойтись. У меня пока очень стабильно работает CAN шина на трех узлах без озвученных тобой фич. Другое дело что и MQTT там нет, а попроще все. Вернее к MQTT  у меня подключен один узел, а дальше на CAN все переводит. Шлюз типа 

sadman41
Offline
Зарегистрирован: 19.10.2016

Гейтование - проще на порядки. Но накручивать на конечные ноды какой-то усложнённый протокол с байтстримом... Не стоит овчинка выделки, как по мне.

Logik
Offline
Зарегистрирован: 05.08.2014

weary пишет:

 но она казалась  мне громоздкой.

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

weary
Offline
Зарегистрирован: 19.01.2018

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

Немного вник в MQTT  и стало ясно, что не что не мешает цеплять MQTT ethernet arduino.

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

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

Учитывая, что вы не хотите менять физическую линию, читай 1 витую пару, и хотите надежности и быстродействия , имхо остаётся вариант только с CAN шиной.

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

ModBus позволяет передавать и строки. Чего вы так к кану пристали. Если у вас уровень помех соответствует цеху, а не электричке, например, то кан в этом случае, с любой стороны ущербнее, сложнее в реализации. Чего такого вы хотите получить от кана, чего вам не может дать модбас ?!?! Читаю это и охреневаю.... Умора, еще и MQTT поверх этого стелите , ЗАЧЕМ ? 

И при этом почему то никто не вспомнил про эзернет, UDP, ТСР.... Чем вам сокеты ТСР не подходят ? 

MaksVV
Offline
Зарегистрирован: 06.08.2015

Быстродействие, не?

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

Да, а давайте сравним. Вы на какую скорость и расстояние рассчитываете ? Как по вашему кан отыгрывает скорость у модбаса ?

MaksVV
Offline
Зарегистрирован: 06.08.2015

Наиболее вероятно у тс домашнее применение, т.е. до 100м. У меня именно так. Скорость поставил 125к. Но в модбасе время также теряется на опрос всех слейвов, поэтому быстродействие еще зависит от количества узлов

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

Сколько у вас байт служебной информации в кане на пакет получится ?

И еще, по вашему модбас на 125к не работает ?

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

Вы ошибаетесь. В модбасе никто ничего не ждет, в отличии от кана, где узел с наименьшим приоритетом может так и не передать свою инфу мастеру, вообще никогда. ОСОБЕННО В СЛУЧАЕ СТЕМЛЕНИЯ ПЕРЕДАТЬ БОЛЬШО ТРАФИК ОДНИМ ИЗ УЗЛОВ, В модбасе, слейвы только отвечают на запрос мастера, причем мастер спрашивает тогда, когда ему нужно, а не когда слейву клюнет передать что то, может это чтото и не нужно нахрен или в кане мастер все же спрашивает ? ;)

В кане служебной информации столько же сколько полезной. В МодБасе зависит от размера пакета и может быть 1% !!!!! Так что полезная скорость кана 50% от канальной. В мод басе от 99% до 50%.

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

Посмотрите по сторонам, где , ГДЕ, в домострое применяется кан, в лифтах, эскалаторах, турнитетах.... Пожарка, охранка, кондиционирование - МОДБАС ! 

Ну не могу я более читать бесконечные споры что лучше половник или ложка.... У вас цель по тарелкам разлить или пожрать ? У каждого инструмента свое назначение. У кана и модбаса они четко озвучены стандартами... Или вы считаете, что те кто их описывают недоумки ? Ну хватит спорить на пустом месте....

MaksVV
Offline
Зарегистрирован: 06.08.2015

brokly пишет:
Вы ошибаетесь. В модбасе никто ничего не ждет, в отличии от кана, где узел с наименьшим приоритетом может так и не передать свою инфу мастеру, вообще никогда. ОСОБЕННО В СЛУЧАЕ СТЕМЛЕНИЯ ПЕРЕДАТЬ БОЛЬШО ТРАФИК ОДНИМ ИЗ УЗЛОВ

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

weary
Offline
Зарегистрирован: 19.01.2018

Прямо, не осталось сомнений в модбас, продолжаю работаь))

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

[вероятность такого развития событий стремится к нулю, особенно в домашнем применении, где шина будет вообще не загружена. 

Ну а тогда НАХРЕНА нужна скорость ?!

MaksVV
Offline
Зарегистрирован: 06.08.2015

в кане 21 бит служебной информации для шины с 11 битными идентификаторами. Если взять фрейм с 8 байтами, то получается служебной инфы 30% .

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

weary пишет:

Прямо, не осталось сомнений в модбас, продолжаю работаь))

Ну слава богу....

MaksVV
Offline
Зарегистрирован: 06.08.2015

brokly пишет:
Ну а тогда НАХРЕНА нужна скорость ?!

в кане не нужна особо, т.к. отклик будет в любом случае быстрый, а вот в модбасе нужна, чтобы мастер побыстрому опрашивал все слевы, иначе будут задержки. 

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

в кане 21 бит служебной информации для шины с 11 битными идентификаторами. Если взять фрейм с 8 байтами, то получается служебной инфы 30% .

Да что вы говорите... Надо же.... Википедию опять какой то неуч написал....  https://ru.wikipedia.org/wiki/Controller_Area_Network , у меня на 0-8байт получилось 64 бита служебки. А значит кпд от 12% до 50%. Сами посчитайте.

MaksVV
Offline
Зарегистрирован: 06.08.2015

вот, например, 10 цифровых выключателей света и один узел с всеми реле света. Неужели можно добиться комфортного (до 200мс) реагирования (управление светом) на выключатель при помощи модбас? какая должная быть скорость шины и периодичность опроса слейвов? 

MaksVV
Offline
Зарегистрирован: 06.08.2015

я в идентификатор закладываю полезную инфу, поэтому это не считаю служебной. 

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

в кане не нужна особо, т.к. отклик будет в любом случае быстрый, а вот в модбасе нужна, чтобы мастер побыстрому опрашивал все слевы, иначе будут задержки. 

Ну опять же ерунду говорите... С какого перепуга он будет быстрый... Спросил мастер у устройства с низшим приоритетом какую то инфу и... ждет, когда этому тухлому узлу дадут окно ... И НИЧЕГО СДЕЛАТЬ НЕ МОЖЕТ, тупо ждет. Потому что есть узлы которые плюют данными бесконечно, нужны они мастеру или нет.

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

я в идентификатор закладываю полезную инфу, поэтому это не считаю служебной. 

А в чем ее полезность то ? 

MaksVV
Offline
Зарегистрирован: 06.08.2015

у меня в ID заложено от кого, кому, и смысл данных (команда, статус, отчёт и т.д.)

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

вот, например, 10 цифровых выключателей света и один узел с всеми реле света. Неужели можно добиться комфортного (до 200мс) реагирования (управление светом) на выключатель при помощи модбас? какая должная быть скорость шины и периодичность опроса слейвов? 

C выключателя вы получаете ОДИН байт данных. При опросе 10 выключателей вы получите поток 180 байт. При модбасе - 110 байт. Что быстрее ?

MaksVV
Offline
Зарегистрирован: 06.08.2015

brokly пишет:

MaksVV пишет:

в кане не нужна особо, т.к. отклик будет в любом случае быстрый, а вот в модбасе нужна, чтобы мастер побыстрому опрашивал все слевы, иначе будут задержки. 

Ну опять же ерунду говорите... С какого перепуга он будет быстрый... Спросил мастер у устройства с низшим приоритетом какую то инфу и... ждет, когда этому тухлому узлу дадут окно ... И НИЧЕГО СДЕЛАТЬ НЕ МОЖЕТ, тупо ждет. Потому что есть узлы которые плюют данными бесконечно, нужны они мастеру или нет.

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

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

Это соответствует стандарту ? Может у вас не кан ? :)

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

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

Правда !? А наши то не знают... Синхра там откуда ? Дальше спорить смысла нет. Сами подумайте, у вас есть отправитель и есть получатель. В системах автоматизации обязан быть мозг, центр. Распределенная сеть плохо подходит для управления светом, в этом случае свет будет включаться слишком долго. Подходите к вопросу с точки зрения целессообразности. Если ваша цель построить надежную и не дорогую домашнюю автоматизацию, анализируйте каждое слово в целеуказании. Если вам принципиально кан, это ваш выбор, он идет вразрез со здравым смыслом - дорогие транссиверы, лишняя служебная информация, ненужная "мифическая" скорость передачи. "В чем сила брат ?". Вот тут https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B5%D1%82%D1%8C прямо сказано, кан - дискретная автоматизация, по сути внутри отдельных устройств.

sadman41
Offline
Зарегистрирован: 19.10.2016

Брукли, шо ты нервничаешь. ТС не желает выдавать чего он вообще ищет в промышленных протоколах - может просто название ))

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

sadman41
Offline
Зарегистрирован: 19.10.2016

Макс, какие там номера узлов? Всё закодированно в ID фрейма. 

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

sadman41 пишет:

Брукли, шо ты нервничаешь. ТС не желает выдавать чего он вообще ищет в промышленных протоколах - может просто название ))

Да не могу я это читать... Ну они всегда об одном и том же спорят... Причем так, как будто это основа мироздания. Уже порвало, просто жесть. Ну должен же быть здравый смысл, эдак мы по I2C будем HTML гонять с умным видом гениев....

MaksVV
Offline
Зарегистрирован: 06.08.2015

brokly пишет:

MaksVV пишет:

в кане 21 бит служебной информации для шины с 11 битными идентификаторами. Если взять фрейм с 8 байтами, то получается служебной инфы 30% .

Да что вы говорите... Надо же.... Википедию опять какой то неуч написал....  https://ru.wikipedia.org/wiki/Controller_Area_Network , у меня на 0-8байт получилось 64 бита служебки. А значит кпд от 12% до 50%. Сами посчитайте.

да просчитался немного, не учёл End of frame. Но в итого всё равно получается 32% 

Весь кадр 111 бит. Служебных 36. (пометил их фиолетовой линией)

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

sadman41 пишет:

Макс, какие там номера узлов? Всё закодированно в ID фрейма. 

это как захочется юзеру-создателю конкретной сети. нет стандарта. В ID не всегда содержится инфа о номере узла. 

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

А чего не длинный ID ? Зеленое тоже мусор, вы там данные передать не можете, куда-кому - СЛУЖЕБНАЯ информация.

brokly
brokly аватар
Offline
Зарегистрирован: 08.02.2014

MaksVV пишет:

это как захочется юзеру-создателю конкретной сети. нет стандарта. В ID не всегда содержится инфа о номере узла. 

Это не кан.

MaksVV
Offline
Зарегистрирован: 06.08.2015

brokly пишет:

MaksVV пишет:

это как захочется юзеру-создателю конкретной сети. нет стандарта. В ID не всегда содержится инфа о номере узла. 

Это не кан.

Брукли, тут ты точно не прав

sadman41
Offline
Зарегистрирован: 19.10.2016

MaksVV пишет:

sadman41 пишет:

Макс, какие там номера узлов? Всё закодированно в ID фрейма. 

это как захочется юзеру-создателю конкретной сети. нет стандарта. В ID не всегда содержится инфа о номере узла. 

Это уровень абстракции в голове архитектора. Номера узла в протоколе всё равно нет и нулевой ID (по-моему) побивает все остальные. Тут брукли прав - сеть можно заддосить))

MaksVV
Offline
Зарегистрирован: 06.08.2015

brokly пишет:

А чего не длинный ID ? Зеленое тоже мусор, вы там данные передать не можете, куда-кому - СЛУЖЕБНАЯ информация.

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