Поддержка Modbus UDP

[Tacio]

Пожалуйста, рассмотрите возможность добавить поддержку Modbus UDP master/slave для ПЛК и Modbus UDP slave для модулей ввода-вывода.
Всё в рамках актуальной спецификации Modbus, меняется (добавляется) только транспортный протокол - UDP.

[Евгений Кислов]

Пожалуйста, рассмотрите возможность добавить поддержку Modbus UDP master/slave для ПЛК и Modbus UDP slave для модулей ввода-вывода.
Всё в рамках актуальной спецификации Modbus, меняется (добавляется) только транспортный протокол - UDP.

Добрый день.
Приведите примеры устройств других производителей, которые поддерживают этот вариант протокола, пожалуйста (c ссылками на техническую документацию).
Особенно интересуют модули.

[imaex]

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

Да легко:
https://icp-das.ru/collections/io-mo...dbus+UDP+Slave

Единственное, что я не совсем понимаю - зачем модулю в/в нужно быть мастером?

[Евгений Кислов]

Да легко:
https://icp-das.ru/collections/io-mo...dbus+UDP+Slave

Единственное, что я не совсем понимаю - зачем модулю в/в нужно быть мастером?

Очень показательный пример - на него я и рассчитывал.
Открываем мануал на любой из модулей (например - ET-7026):
https://insat.ru/products/icpdas/PET...ET-7026_RE.pdf

Термин "UDP" в нем встречается 10 раз (1 раз - в оглавлении) и нигде не соседствует с "Modbus".
Если прочитать чуть внимательнее - то окажется, что по UDP (не Modbus UDP, а по какому-то сервисному "протоколу" поверх UDP) происходит обновление прошивки модуля:

26-03-2023 8-51-16.png

26-03-2023 8-57-01.png

Не очень-то и "легко" получилось, верно?

[imaex]

Очень показательный пример - на него я и рассчитывал.
Открываем мануал на любой из модулей (например - ET-7026):
https://insat.ru/products/icpdas/PET...ET-7026_RE.pdf

Открываем произвольно выбранный даташит и читаем:

Protocol Modbus TCP, Modbus UDP

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

[Tacio]

Добрый день.
Приведите примеры устройств других производителей, которые поддерживают этот вариант протокола, пожалуйста (c ссылками на техническую документацию).
Особенно интересуют модули.

Я предлагал рассмотреть такую возможность только для ПЛК и модулей ВВ вашего производства.
Есть ли ПЛК и модули ВВ у других производителей с поддержкой Modbus UDP меня не сильно интересует.

[Евгений Кислов]

Я предлагал рассмотреть такую возможность только для ПЛК и модулей ВВ вашего производства.
Есть ли ПЛК и модули ВВ у других производителей с поддержкой Modbus UDP меня не сильно интересует.

Тогда, пожалуйста, опишите - зачем нам рассматривать возможность поддержки протокола, несовместимого с устройствами других производителей?
В чем самоцель?

[melky]

Если честно, я не понимаю тех, кто это разработал.... Завернуть TCP в UDP не составляет особого труда для сетевого оборудования вроде.
А что происходит тут?, к Modbus TCP необходимо добавить снова CRC как в RTU чтобы проверять пакеты протокола?

перевод

В этом вся прелесть, по сути, мы ничего не изменили в спецификации прикладного уровня Modbus (и TCP), кроме способа передачи сообщений.

Это означает, что специфичный для IP заголовок (называемый MBAP в спецификации) точно такой же, как и для Modbus/TCP. Он имеет длину 7 байт и состоит из следующих полей:

идентификатор вызова (2 байта), используемый для сопряжения транзакций; ранее называвшийся идентификатором транзакции идентификатор
протокола (2 байта), по умолчанию равен 0 для Modbus; зарезервирован для будущих расширений
длина (2 байта), количество байтов всех следующих байтов
идентификатор единицы измерения (1 байт), используемый для идентификации удаленное устройство, расположенное в сети, отличной от TCP/IP
Также ничего не изменилось в отношении возможных сетевых настроек. На самом деле они не соответствуют спецификации; возможно настроить системы с несколькими ведущими или реализовать двунаправленную связь (т.е. иметь узлы, которые являются ведущими и ведомыми одновременно). Однако пользователь должен хорошо осознавать, что это влечет за собой последствия

ну и смысл велосипеда?

[imaex]

Завернуть TCP в UDP

Мсье знает толк. В извращениях.

ну и смысл велосипеда?

В Вашем изложении - никакого.

А так, в своей практике я единственный раз сталкивался с ситуацией, когда пришлось перейти с tcp на udp. Правда, тот случай никакого отношения к modbus tcp/udp не имеет. Просто китайский конвертер последовательного порта по необъяснимым для меня причинам отказался работать по tcp.

[Филоненко Владислав]

Если честно, я не понимаю тех, кто это разработал.... Завернуть TCP в UDP не составляет особого труда для сетевого оборудования вроде.
А что происходит тут?, к Modbus TCP необходимо добавить снова CRC как в RTU чтобы проверять пакеты протокола?

перевод

ну и смысл велосипеда?

По логике "Великих Автоматизаторов" основная проблема ModBus TCP - это время установления коннекта. И если его "убрать" сразу всё заколосится и полетит со сверхсветовой скоростью.
Но, если в ModBusTCP есть логичная и понятная система запрос-ответ с приходом пакетов по порядку, то в ModBusUDP кинул зёрна в поле - авось взойдут. Т.е. если мастер посылает пакет Slave для управления выходами - еще худо-бедно пакет дойдёт (пусть и не первый, но у нас же скорость, пулемёт дострелит) и выход включится. На пустой сети включится быстро.

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

Кстати эта проблема с приходом ответов не по порядку есть и у RTU модбаса - если Slave отвечает медленнее чем период ожидания ответа мастером - то есть большая вероятность что мастер спросит уже другое, а тут свежезапоздавший зомби-пакет, получите-распишитесь. И мастер никак его не отличит.

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