Comments 36
Добавьте еще один недостаток протокола Modbus.
При работе в последовательной сети он требует назначение уникальных Slave ID для каждого ведомого устройства. И из-за этого у него определенные сложности с динамической конфигурацией сети (сложно выявить конфликт работы двух устройств с одинаковым Slave ID на одной последовательной линии связи).
При работе в последовательной сети он требует назначение уникальных Slave ID для каждого ведомого устройства. И из-за этого у него определенные сложности с динамической конфигурацией сети (сложно выявить конфликт работы двух устройств с одинаковым Slave ID на одной последовательной линии связи).
Странно, кстати, почему не выпускают новый обратно совместимый стандарт лишенный этих проблем. Провижининг и передачу по инициативе slave можно было добавить, полагаю.
Всегда удивляла стоимость простых шлюзов для MODBUS.
Как-то раз возникла необходимость удалённо мониторить некоторые контроллеры. Цена на простейшие преобразователи RTU (RS-485) -> TCP/IP для передачи данных на сервер просто сумасшедшая. 280$ за простейшую коробочку по ссылке из статьи. Отечественные производители не отстают.
В итоге купил Orange Pi, шнурок rs485-USB и опциональный USB-модем. На github'е нашёл утилиту для преобразования RTU -> TCP. Для сбора данных, дашборда (с мобильным приложением даже) и графиками поднял сервер с OpenHAB. От силы потратил 50$ + 10$ в месяц за простейший сервер с OpenHAB и VPN.
Нет, конечно, можно порассуждать о надёжности, безопасности и прочем. Но для простейшего кейса домашней автоматизации или мониторинга на этапе пуска-наладки какого-нибудь магазина/музея/школы этого решения хватает с горой. И колоссальная экономия.
Как-то раз возникла необходимость удалённо мониторить некоторые контроллеры. Цена на простейшие преобразователи RTU (RS-485) -> TCP/IP для передачи данных на сервер просто сумасшедшая. 280$ за простейшую коробочку по ссылке из статьи. Отечественные производители не отстают.
В итоге купил Orange Pi, шнурок rs485-USB и опциональный USB-модем. На github'е нашёл утилиту для преобразования RTU -> TCP. Для сбора данных, дашборда (с мобильным приложением даже) и графиками поднял сервер с OpenHAB. От силы потратил 50$ + 10$ в месяц за простейший сервер с OpenHAB и VPN.
Нет, конечно, можно порассуждать о надёжности, безопасности и прочем. Но для простейшего кейса домашней автоматизации или мониторинга на этапе пуска-наладки какого-нибудь магазина/музея/школы этого решения хватает с горой. И колоссальная экономия.
для дома может быть, но для коммерческой эксплуатации другие требования к надежности, электроизоляции и т.д.
я бы сказал что баксов 100-130, вот например непростой преобразователь, не сочтите за рекламу пожалуйста, а можно и намного дешевле найти, особенно если не смотреть изделия предназначенные для промышленного применения.
У всяких sbc есть важное преимущество — бОльшие возможности по доступу к сети. Тот же Orange Pi или сравнимый с ним имеет и Ethernet-порт, и wi-fi, и достаточно USB-портов, чтобы воткнуть модем. Это, кстати, тоже важный момент, так как зачастую от комнаты с оборудованием до ближайшего роутера может быть не проложен кабель, или интернета нет вообще и единственный вариант — мобильный интернет.
UFO just landed and posted this here
Можно собрать свой шлюз на esp8266.
github.com/MaxKravt/WiFi-Modbus-TCPtoRTU
github.com/MaxKravt/WiFi-Modbus-TCPtoRTU
Есть еще вариант habr.com/ru/post/424791 Modbus RTU(Master), Modbus TCP(Slave), mqtt, WEB, архивирование. Разные применения тут www.youtube.com/channel/UCj4HeZMvSH5H3d_t6iDlQOQ
А можно еще один пример, на схеме условной простейшей схеме измерения температуры, от первичного преобразователя (скажем от выводов термопары) до контрол-рума — где и как появляются регистры.
Прямо сейчас собираю систему с адамами на 485. возникла надобность воткнуть в неё устройство своей разработки. Нахожусь в дилемме делать ли у себя поддержку модбаса или вставить ещё одну линию и делать все на своём протоколе (в нем вместо конца пакета по времени указывается его длина, плюс он больше заточен под задачу).
А может ваши адамы переварят наличие в сети чужого протокола, если его первый (или какой там) байт пакета не будет совпадать с их айдишниками?
переварят, главное закрывать порт после завершения операции
Shpiler
Нет никаких проблем подключить разные протоколы типа «запрос-ответ», давно и успешно используем разнородные в плане протокола подключения где это обосновано. Только убедитесь, что запросы и ответы в Вашем протоколе не будут восприняты другими устройствами как запросные (корректные или не корректные — не суть). Для ModBusRTU достаточно, чтобы первый байт Ваших запросных и ответных посылок не совпадал с адресом ModBus-устройств (первый байт посылок) и не был бы широковещательным.
Нет никаких проблем подключить разные протоколы типа «запрос-ответ», давно и успешно используем разнородные в плане протокола подключения где это обосновано. Только убедитесь, что запросы и ответы в Вашем протоколе не будут восприняты другими устройствами как запросные (корректные или не корректные — не суть). Для ModBusRTU достаточно, чтобы первый байт Ваших запросных и ответных посылок не совпадал с адресом ModBus-устройств (первый байт посылок) и не был бы широковещательным.
Для ModBusRTU достаточно, чтобы первый байт Ваших запросных и ответных посылок не совпадал с адресом ModBus-устройств (первый байт посылок) и не был бы широковещательным.Вредный совет.
В протоколе Modbus начало передачи определяется паузой на линии. И если на одной и той же линии сидят устройства с какими нибудь бинарными протоколами, то вполне вероятна ситуация, когда Modbus устройство ловит паузу в бинарном протоколе и считает это моментом передачи мастера. Ну а дальше все зависит от везения.
Лучше реализовать расширение протокола Modbus (у него есть зарезервированные коды функций, которые можно использовать как раз для таких случаев). Уж если все равно нужно писать, но тут хоть будет гарантия от различных «неждачиков».
Вредный совет.
rsashka, не совсем так. Я не стал указывать на необходимость соблюдения таймаутов по причине того, что вопрос был о другом. Человек, реализовавший протокол ModBusRTU должен знать и о таймаутах. И хотя бы открывал wiki, где сказано:
Сообщения разделяются по паузе в линии. Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов.
паузу в бинарном протоколе
А бывают такие, что предполагают паузу внутри посылки? Даже не могу представить где это может иметь смысл.
А если у них протоколы разные, то почему скорости должны быть одинаковыми? ;-)
Ну, например, потому что так было задумано :)
картинки с примером
Все подчиненные устройства сидят на одном порту, соответственно параметры порта общие для всех подключенных к нему устройств. А вот адрес и таймауты — для каждого свои (а так же некоторые специфичные для протокола параметры — тоже свои). PS: на значения таймаутов и совпадение адресов не обращайте внимания, картинки только для примера.
Конечно, можно повесить на одну физическую линию устройства с разным протоколами. И можно так задумать, что будут разными не только протоколы устройств, но и скорости работы у разных классов устройст. Точно по этой же причине, «потому что так задумано» ;-)
Ведь смена скорости порта практически мгновенная операция, и причин для этого можно найти много (например для помехозащищенности, что бы скорость передачи могла подстраиваться в зависимости от внешних помех).
Ведь смена скорости порта практически мгновенная операция, и причин для этого можно найти много (например для помехозащищенности, что бы скорость передачи могла подстраиваться в зависимости от внешних помех).
в теории, разные скорости можно использовать как расширение — по 255 устройств на каждой скорости (9600, 14400…)?
В теории можно, но лучше так не делать. Тем более при определленой разнице в скоростях, даже обычные символы низкоскоростных устройоств могут восприниматься как стартовые сигналы для высокоскоростных.
Конечно, должно сложиться много условий (определенная комбинация данных или наведенная помеха), но ведь и не заряженное ружье иногда стреляет.
Конечно, должно сложиться много условий (определенная комбинация данных или наведенная помеха), но ведь и не заряженное ружье иногда стреляет.
Если ваше устройство по своему хотению будет что-то передавать в сеть, то в Modbus это чревато непредсказуемыми коллизиями, т.к. мастер в этой сети, считает себя единственным инициатором передачи пакетов. В Profibus, например, передается маркер от мастера к мастеру на право передачи.
Лучше поддержку Modbus повесить. Для встраиваемых систем есть свободная библиотека Free Modbus. Я использую ее для своих проектов.
Лучше поддержку Modbus повесить. Для встраиваемых систем есть свободная библиотека Free Modbus. Я использую ее для своих проектов.
del
Еще есть hart прямо по токовой петле гоняет данные. Profibus где может быть куча мастеров по очереди. Да и шины типа can где все узлы могут периодически отсылать данные (для датчиков лучше чем modbus).
Странно…
По текущему, уже более 25 лет Стандарту Протокола
Discrete Inputs могут быть в Большем чем указано диапазоне.
Строго говоря начиная с 0-го регистра до 65535, с расширением диапазона, если это необходимо.
С другими типами функций также.
И ограничение регистров это Очень старый атавизм, казалось он ушел в небытие лет 30 назад.
Такие «правила» были Только в документах по протоколу До 1996 года.
Странно что Такие именитые компании ( Delta тоже этим «грешит»)
при разработке устройств на протоколе Modbus
берут за основу документ «PI_MBUS_300.pdf» от 1996 года, который помечен как «obsolete» и «FOR LEGACY APPLICATIONS ONLY».
в котором чётко указано
«Используется для разрешения проблем обратной совместимости. Рекомендуется не
использовать его при разработке новых устройств.»
И это указание, на минуточку, от 1996 года. А на дворе внезапно 2019 год.
Ну а даже про надпись в этом документе «Unless otherwise stated» лучше вообще умолчать.
Было бы интересно, если бы автор посмотрел в Спецификацию протокола от 2012 года и попытался там найти упоминания о таких диапазонах регистров для конкретных функций.
По текущему, уже более 25 лет Стандарту Протокола
Discrete Inputs могут быть в Большем чем указано диапазоне.
Строго говоря начиная с 0-го регистра до 65535, с расширением диапазона, если это необходимо.
С другими типами функций также.
И ограничение регистров это Очень старый атавизм, казалось он ушел в небытие лет 30 назад.
Такие «правила» были Только в документах по протоколу До 1996 года.
Странно что Такие именитые компании ( Delta тоже этим «грешит»)
при разработке устройств на протоколе Modbus
берут за основу документ «PI_MBUS_300.pdf» от 1996 года, который помечен как «obsolete» и «FOR LEGACY APPLICATIONS ONLY».
в котором чётко указано
«Используется для разрешения проблем обратной совместимости. Рекомендуется не
использовать его при разработке новых устройств.»
И это указание, на минуточку, от 1996 года. А на дворе внезапно 2019 год.
Ну а даже про надпись в этом документе «Unless otherwise stated» лучше вообще умолчать.
Было бы интересно, если бы автор посмотрел в Спецификацию протокола от 2012 года и попытался там найти упоминания о таких диапазонах регистров для конкретных функций.
упаковываются в обычный TCP-пакет, для передачи по IP-сетямВ TCP нет никаких пакетов, в том числе обычных.
См., например, ru.wikipedia.org/wiki/Transmission_Control_Protocol
Механизм TCP предоставляет поток данныхСоответственно Modbus-овские фреймы выделяются из входного потока на прикладном уровне и передаются в выходной поток без всякой «упаковки».
Sign up to leave a comment.
Как общаются машины: протокол Modbus