Поддержка Modbus UDP

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

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

перевод

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

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

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

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

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

[Newcomer]

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

А что мешает в настройках сделать побольше период ожидания ответа мастером ?

[melky]

Валенок много писанины. Еще раз, скачайте описание протокола, я гуглом переводил. Вероятно в TCP реализации это придумали СПЕЦИАЛЬНО для возможности
1. опрашивать быстрее, чем привыкли в RTU
2. опрашивать не последовательно, постоянно ожидая ответов, например в асинхронном режиме.

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

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

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

[Валенок]

...много писанины. Еще раз. Еще раз, скачайте описание протокола, я гуглом переводил.

Много общего, мало конкретики. Где сказано об обязательном изменении ide ?

Вероятно в TCP реализации это придумали СПЕЦИАЛЬНО для ..

Вот вообще непарит зачем это придумали.

Другой вопрос, что этого никто не захотел реализовать,..

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


++
И вот - обнаружил:

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

И я о том же )) Просил, просил как-то описать мастера. А в ответ - таймаут.
++

. Если протоколом не запрещено, то как минимум этим возможно воспользоваться...

А кто этим воспользуется ? Сервера ? И офигительно удивят подавляющее кол-во клиентов - см. выше? ))

..опрашивать не последовательно, постоянно ожидая ответов,..

Мы о tcp же ? Не ожидайте. Отправьте несколько запросов подряд в Овен-ПЛК. И нет проблем. Только паузу между сделайте не меньше времени цикла в ПЛК если слейв - в конфигурации. А программным сервером легко обработать и без пауз.

...например в асинхронном режиме...

Ответы придут - в порядке запросов. А сумеете ли обработать поток ответов - ваши проблемы.

Кстати реализаций дополнительных функций нет практически ни у кого,.

А кто это реализует ? Сервер ? Открываем панельку с галочками в какой-нить скаде - и .... ставим себя на место наладчика. Вы хотите регулярно изучать "реальные посылки и ответы от родного ПО данного терминала" или решать задачи технологии ?

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

А что будет идентифицировать эту структуру ? Функция ? А сегодня внезапно 150 штук таких структур - и ?
Или приспичит из этой структуры получить с 24 по 48 байты - и ?
Да и непоразили - в рамках стандарта чем 250/246 не устроило ?
Или кто-то обязывает прям таки отображать регистры на живой массив ? Конкретный регистр+конкретный размер => готовый ide для чего угодно. И все - в рамках.

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

Пишу сразу. Интересует именно обязательность изменения ide клиентом.

[BETEP]

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

Кто дружит с модбас UDP?
https://shopping.coolmayplchmi.com/s...s-protocol.htm
инструкция на эту тему
https://en.coolmay.com/webdown/Coolm...g%20Manual.pdf
строчки по настройке порта

D8395： EtherNet/IP and MODBUS_TCP switch;
D8395=0: EtherNet/IP master station (with 4 slave stations at most)
D8395=1： MODBUS_UDP Slaves
D8395=2： MODBUS_UDP Masters
D8395=3： MODBUS_TCP Slaves（ Server）
D8395=4： MODBUS_TCP Masters（ Client, with up to 4 slaves）
D8395=5： EtherNet/IP Slaves（ Server）

Вроде я нарушил правила форума? или Супер Модератор нарушает?
TCP зло, у UDP преимуществ больше, например не ограничено количество соединений как у TCP, нет обслуживающего (паразитного трафика, который время у мозгов камня занимает), и скорость выше.
Есть вероятность перепутать пакеты? А нафига тогда заголовок в пакете?
Ethernet/IP разве не UDP?
CC-Link разве не UDP?

[Tacio]

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

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

[Валенок]

Кто дружит с модбас UDP?
https://shopping.coolmayplchmi.com/s...s-protocol.htm
инструкция на эту тему
https://en.coolmay.com/webdown/Coolm...g%20Manual.pdf
строчки по настройке порта... ?

Отлично. Во всем доке ровно 4 упоминания про udp. Из них 2 - именно на том месте, которое вы и привели. В оглавление просто постеснялись вытаскивать? "его фамилия слишком известна чтоб они её приводили"?

И да. А где модель работы модбас UDP-мастера? Для tcp я привёл ранее.
Где описание параметра лимитирующего кол-во ждущих ответа запросов?

[capzap]

Отлично. Во всем доке ровно 4 упоминания про udp. Из них 2 - именно на том месте, которое вы и привели. В оглавление просто постеснялись вытаскивать? "его фамилия слишком известна чтоб они её приводили"?

И да. А где модель работы модбас UDP-мастера? Для tcp я привёл ранее.
Где описание параметра лимитирующего кол-во ждущих ответа запросов?

Хорош волноваться не будет ни кто ни чего делать, ОВЕН повторил в очередной раз, что мало пользователей кому это необходимо и в семнадцатом году было тоже самое. У вейнтека есть такой мастер, а слейв написать не проблема, у меня и в овеновских плк и в сименсах и на ПК всё работает и не испытываю я проблем ни с отсутствием контрольной суммы ни с очередью

[melky]

Валенок да твою ж дивизию, обязаловки НЕТ, это предусмотрели просто протоколом Modbus TCP, пользоваться этим или нет на совести производителя оборудования. При этом нет никаких нарушений протокола, так как это в нем указано.

Ответы придут - в порядке запросов. А сумеете ли обработать поток ответов - ваши проблемы.

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

Или приспичит из этой структуры получить с 24 по 48 байты - и ?
Да и непоразили - в рамках стандарта чем 250/246 не устроило ?

Все на совести производителя прибора. Если не устраивает производителя привязка к 1-му, 2-м регистрам, он может передать то, что захочет. Протокол не нарушен, если вы не можете прочесть - ваша проблема.
Видел неоднократно приборы, причем российские, где старым добрым Modbus 3,4 функции читались текущие параметры, а другими функциями вычитываются архивы. Все описано в документации на прибор - не могете, ваши проблемы...

Ethernet/IP повторяет заголовки TCP, по этому его пропускают все коммутаторы на ура. Он просто замещает TCP, не более. UDP там не пахнет и близко.
Вот EtherCAT это другое... а Ethernet/IP сюда приплетать не надо.

[Валенок]

)) Да я собстенно не волнуюсь. Причем и не говорю что модбас-udp не возможен/не нужен.

не испытываю я проблем .. с очередью

А за счет чего - не испытываете ? Вот заслали 10 запросов и ждете 10 ответов ?