Пожалуйста, рассмотрите возможность добавить поддержку Modbus UDP master/slave для ПЛК и Modbus UDP slave для модулей ввода-вывода.
Всё в рамках актуальной спецификации Modbus, меняется (добавляется) только транспортный протокол - UDP.
Вид для печати
Пожалуйста, рассмотрите возможность добавить поддержку Modbus UDP master/slave для ПЛК и Modbus UDP slave для модулей ввода-вывода.
Всё в рамках актуальной спецификации Modbus, меняется (добавляется) только транспортный протокол - UDP.
Если честно, я не понимаю тех, кто это разработал.... Завернуть TCP в UDP не составляет особого труда для сетевого оборудования вроде.
А что происходит тут?, к Modbus TCP необходимо добавить снова CRC как в RTU чтобы проверять пакеты протокола?
перевод
ну и смысл велосипеда?Цитата:
В этом вся прелесть, по сути, мы ничего не изменили в спецификации прикладного уровня Modbus (и TCP), кроме способа передачи сообщений.
Это означает, что специфичный для IP заголовок (называемый MBAP в спецификации) точно такой же, как и для Modbus/TCP. Он имеет длину 7 байт и состоит из следующих полей:
идентификатор вызова (2 байта), используемый для сопряжения транзакций; ранее называвшийся идентификатором транзакции идентификатор
протокола (2 байта), по умолчанию равен 0 для Modbus; зарезервирован для будущих расширений
длина (2 байта), количество байтов всех следующих байтов
идентификатор единицы измерения (1 байт), используемый для идентификации удаленное устройство, расположенное в сети, отличной от TCP/IP
Также ничего не изменилось в отношении возможных сетевых настроек. На самом деле они не соответствуют спецификации; возможно настроить системы с несколькими ведущими или реализовать двунаправленную связь (т.е. иметь узлы, которые являются ведущими и ведомыми одновременно). Однако пользователь должен хорошо осознавать, что это влечет за собой последствия
Да легко:
https://icp-das.ru/collections/io-mo...dbus+UDP+Slave
Единственное, что я не совсем понимаю - зачем модулю в/в нужно быть мастером?
Мсье знает толк. В извращениях. :eek:
В Вашем изложении - никакого.
А так, в своей практике я единственный раз сталкивался с ситуацией, когда пришлось перейти с tcp на udp. Правда, тот случай никакого отношения к modbus tcp/udp не имеет. Просто китайский конвертер последовательного порта по необъяснимым для меня причинам отказался работать по tcp.
я в вейнтековской панели всегда ставлю галку передавать по UDP, когда работаю с протоколом modbusTCP
Очень показательный пример - на него я и рассчитывал.
Открываем мануал на любой из модулей (например - ET-7026):
https://insat.ru/products/icpdas/PET...ET-7026_RE.pdf
Термин "UDP" в нем встречается 10 раз (1 раз - в оглавлении) и нигде не соседствует с "Modbus".
Если прочитать чуть внимательнее - то окажется, что по UDP (не Modbus UDP, а по какому-то сервисному "протоколу" поверх UDP) происходит обновление прошивки модуля:
Вложение 66751
Вложение 66752
Не очень-то и "легко" получилось, верно?
imaex ну давайте сначала. Одно из различий Modbus TCP от RTU заключается в том, что из пакета Modbus убрали CRC, возложив это на TCP стек, то есть устройство, принимая TCP пакет уже знает, что пакет битый или не битый и уже нет необходимости проверять пакет непосредственно Modbus протокола.
в UDP нет контрольных сумм насколько помню. То есть изобретая протокол Modbus UDP потребуется вернуть обратно CRC протокола, чтобы устройство точно знало, что пакет не битый...
И тем самым все сведется на нет...
Хотя вроде какой-то базовый функционал проверки целостности есть... Вот что будет делать устройство, если получит неполный пакет?
Смысл кстати есть в распределенных системах. В том числе и мульти мастера.
Например опрос устройств раз в 20 минут, но если что произошло устройство присылает необходимые данные раньше наступления запроса со стороны сервера.
Отправка одной команды выбранным или всем устройствам сразу.
Tacio ну не сетевой специалист, а так, отсутствие повторной передачи, отсутствие гарантии доставки, меньше заголовок, нет необходимости создавать коннект, просто можно плюнуть в пустоту :)
Тут больше вопрос для чего?
Открываем произвольно выбранный даташит и читаем:
Был бы мне доступен один из модулей для проверки - можно было бы более аргументированно. А так - приходится верить даташитам.Цитата:
Protocol Modbus TCP, Modbus UDP
Поэтому я в своем первом посте и попросил ссылки на техническую документацию, а не 2-страничные даташиты.
Написать можно всё что угодно - и без технического контекста эту информацию часто можно интерпретировать неверно.
Почему бы и нет? Что-то подобное есть в SNMP.
Предыдущим предложением вы уже описали для чего: убираем весь overhead, который есть в TCP.Цитата:
Tacio ну не сетевой специалист, а так, отсутствие повторной передачи, отсутствие гарантии доставки, меньше заголовок, нет необходимости создавать коннект, просто можно плюнуть в пустоту :)
Тут больше вопрос для чего?
По той же причине, по которой связь реального времени между соответствующими устройствами в IP-сетях обычно организуют на базе UDP, а не TCP.
По моему опыту - "связь реального времени" в промышленности обычно организуют с помощью протоколов реального времени - EtherCAT, Profinet и т.д.Цитата:
По той же причине, по которой связь реального времени между соответствующими устройствами в IP-сетях обычно организуют на базе UDP, а не TCP.
Вы квалифицированный специалист - поэтому наверняка сможете оценить упомянутый "overhead" в байтах, а затем - в сэкономленных милли-(или микро)секундах в случае его исчезновения при переходе с TCP на UDP.
Я не исключаю, что есть единичные задачи, где, возможно, такая экономия была бы оправданной (к сожалению, вашей реальной задачи вы за столько постов так и не описали).
Но рассматривая возможность реализации Modbus UDP для нашего оборудования - я вижу, что таких пожеланий от клиентов крайне мало (не более одного в год) и что это нетиражируемое решение (среди других производителей его поддерживают единицы и зачастую - несовместимым образом).
Если число таких пожеланий резко увеличится - мы опять вернемся к анализу этого вопроса.
За обратную связь спасибо.
В целом, ваша идея понятна; мы планируем реализовать ее в будущем в отдельной линейке оборудования и другим способом.
Нет, конечно. Обычно в технической документации пишут о том, какой функционал поддерживается и как его настроить, а не наоборот.Цитата:
Вы можете хотя бы дать ссылку на то, что эти модули не поддерживают modbus udp?
В 100+ страничном мануале, ссылку на который приводил выше, я в принципе не нахожу ни одной фразы про Modbus UDP.
Почему бы и нет это же по TCP ?
Зачем, если он (overhead) упрощает (см.ниже (да и выше Е.Кислов про это же)) обработку, а значит повышает надежность (в смысле ошибок кода)
Ну напишите сходу простой обработчик udp-модбас запросов который учитывает возможные непоследовательности и дупликаты ответов
++
Открыл "Три мушкетера" - упоминаний что мушкетеры не поддерживают modbus udp не нашел. Значит поддерживают ?
Евгений, ваша позиция понятна, спасибо.
Групповые сообщения (multicast) по TCP?
Использование протокола TCP ну никак не спасает и не страхует от ошибок в коде :)Цитата:
Зачем, если он (overhead) упрощает (см.ниже (да и выше Е.Кислов про это же)) обработку, а значит повышает надежность (в смысле ошибок кода)
А вот если какой-то пакет с телеметрией потеряется и TCP начнёт процедуру отсчёта таймаута, затем повторную передачу потерянного пакета, до данные в этом пакете уже протухнут и, по-хорошему, надо бы уже запрашивать более свежие. Вот такая "надёжность" только мешает.
Или, например, оборвётся линк в кольце между ПЛК и модулями ВВ. RSTP отработает за 1-2с (допустим это приемлемо), но восстановление TCP соединения в некоторых случаях может задержатся ещё на 5с, что уже неприемлемо.
В протоколе MODBUS есть специальное поле идентификатора транзакции, которое как раз и нужно для таких случаев в том числе. И должно оно обрабатываться всегда независимо от транспортного протокола, который может и сам умеет отслеживать и дубликаты, и неверный порядок.Цитата:
Ну напишите сходу простой обработчик udp-модбас запросов который учитывает возможные непоследовательности и дупликаты ответов
Tacio за все время встречалось только одно устройство, которое не работало без заполненного поля "Идентификатор транзакции"
1.Если что, там еще речь была о инициирующей отправку данных стороне.
2.А зачем нужна ненадежная форма отправки задач в промышленном оборудовании ?
Проще логика (см. в конце поста) - проще сразу выявить все ошибки. Удивляет, да ?
Можно с этого места поподробней ? Вы же разбираетесь с протоколами как я понял.Цитата:
А вот если какой-то пакет с телеметрией потеряется и TCP начнёт процедуру отсчёта таймаута, затем повторную передачу потерянного пакета,...
Кто и как протухнет в TCP-потоке - интересуют подробности.Цитата:
до данные в этом пакете уже протухнут и, по-хорошему, надо бы уже запрашивать более свежие.
И главное - как на фоне этого UDP сохраняет свежесть ?
Определимся с "приемлимостью" ? Это что ?Цитата:
..это приемлемо...уже неприемлемо.
Т.е. присутствуют проблемы (физические/внешние на линии/местные внутрисистемные/...) приводящие к задержкам.Цитата:
о восстановление TCP соединения в некоторых случаях может задержатся ещё на 5с..
А UDP приносят голуби и их это не касается ?
Для Модбас-TCP оно избыточно если что. Не ?
Так я же и просил Вас написать для вышеизложенного (с Модбас-UDP) простенький алгоритм обработки.
Вот например для Модбас-TCP:
1.Открыл коннект
2.Отправил запрос
3.Получил норм ответ - goto 2, таймаут/мусор - goto 4
4.Закрыл коннект
5.goto 1
может и не избыточно, как раз говорит что ответ строго на данный запрос...Цитата:
Для Модбас-TCP оно избыточно если что. Не ?
А как это по tcp может быть другой ответ ?
----
Вот что вы сделаете с девайсом (слейвом) с модбас-RTU которое иногда сохраняет запрос где-то в памяти и не отвечает, а после вдруг где-то между другими нормальными запросами/ответами вдруг вспоминает этот забытый/забитый запрос и внезапно отправляет ответ на него ?
Валенок это я не знаю, говорю же, встречал только одно устройство, которое не отвечало, если Идентификатор Транзакции был всегда 0 или он не менялся на следующем запросе.
Слейв устройство просто игнорировало запрос.
Какой-то весовой терминал Shenk, точную модель не знаю.
Это было конкретное устройство с багом. Баг - т.к. протокол не требует какого-то особенного ide от клиента(мастера). Только от сервера - ide ответа должен совпадать с запросом. Как обойти этот баг - вам понятно. Какие проблемы ?
Я спросили Вас про Вашу реакцию на девайс(слейв) с вышеописанным поведением по RTU
Валенок это не баг, а функционал.
Смотрите, обычно мы привыкли, что происходит запрос и мы ждем ответа. ВЫ не думали что может быть иная ситуация, запрос1, запрос2, запрос3 и просто ждем ответы в асинхронном режиме, причем ответ 3 придет первым, ответ 1 вторым, а ответ 2 третьим.
Именно Modbus TCP это позволяет, другой вопрос что практически никто это не реализует в драйверах...
Пример: например сформировать ответ на запрос №2 устройству требуется 20 секунд, а на запрос 3 всего 0,5 секунды.
Есть протокол. Всё вне этого - баг (добавил) если оно мешает работе по протоколу.
Вы так и не ответили про Вашу реакцию про вышеописанное поведение RTU-слейва.
++
Exception №5...6 - вот для такого.Цитата:
Пример: например сформировать ответ на запрос №2 устройству требуется 20 секунд, а на запрос 3 всего 0,5 секунды.
"другой вопрос что практически никто это не реализует в драйверах" (C) ))
Валенок Прочтите протокол в английском варианте, там как раз и указано что Transaction ID предусмотрен, если ответы поступают не последовательно во времени. Так что это протоколом предусмотрено. Только не первым от Modicon, а уже о последней редакции.
У меня реакции никакой, с данным устройство обратился человек на форуме RapidScada, показав реальные посылки и ответы от родного ПО данного терминала. Как раз и определили, что у него меняются Transaction Id и со значением 0 устройство не отвечает. В результате разработчик доработал драйвер Modbus. Что абсолютно не противоречит протоколу. Тем более другие устройства это значение просто игнорируют.
А можно этот непоследний оригинал привести ? И указать на фразу со смыслом "ide запросов обязательно должны отличатся [не быть 0 и т.п.]" ?
Это чему-то противоречит? Ключевое слово - "если". А много именно мастеров/клиентов готовы к этому динамическому списку текущих транзакций с индивидуальным контролем времени их жизни ? (было где-то - "другой вопрос что практически никто это не реализует в драйверах") Причем с четкими правилами-параметрами для конфигурации - ведь предполагается именно это, а не ручное руление.Цитата:
...Transaction ID предусмотрен, если ответы поступают не последовательно во времени
Уже двоих просил показать простенькую модель работы такого клиента)).
Я как-то спорю что этого не было ?
У кого - "у него" ? У клиента ? Так он хозяин ide.
Я ж и говорю - баг устройства. Если он (баг) по каким-то причинам в устройстве вынужденный (всё может быть) - то должен быть описан в соотв.РЭ, тогда баг переходит в разряд специфицированных особенностей конкретного девайса.
Вы действовали по протоколу, а оно не отвечало:
-или Вы не читали РЭ
-или это баг который вы ловили, поймали и описали как настоящие энтомологи следующие на Суматру.
Вы всю жизнь пилотом летали на БоингеXXX, сели на БоингYYY, а заместо убрать шасси - стопкран. Прецеденты были же. Не радостные. Как вот это:
изучать в воздухе, норм ?Цитата:
..показав реальные посылки и ответы от родного ПО данного терминала.
Разработчик драйвера какой стороны ? Клиентской ? Запилил изменяемое и неравное нулю ide ? Так выше же - клиент хозяин ide, что хочет, то и ставит.
Я где-то спорю ? Действия клиента абсолютно не противоречат протоколу ни в 1-ом ни во 2-ом случае. Проcто во 2-ом случае клиент еще и учел баг девайса(сервера)
Другие устройства в модбас-tcp ответах пишут ide отличное от ide запроса ?
По логике "Великих Автоматизаторов" основная проблема ModBus TCP - это время установления коннекта. И если его "убрать" сразу всё заколосится и полетит со сверхсветовой скоростью.
Но, если в ModBusTCP есть логичная и понятная система запрос-ответ с приходом пакетов по порядку, то в ModBusUDP кинул зёрна в поле - авось взойдут. Т.е. если мастер посылает пакет Slave для управления выходами - еще худо-бедно пакет дойдёт (пусть и не первый, но у нас же скорость, пулемёт дострелит) и выход включится. На пустой сети включится быстро.
А вот если мастер посмел запросить состояние входа - то тут будет ли ответ, когда, и самое главное на какой запрос - тайна великая.
Ведь у Модбаса в ответе нет номера регистра и можно лишь гадать ответ на какой запрос пришёл по UDP.
Кстати эта проблема с приходом ответов не по порядку есть и у RTU модбаса - если Slave отвечает медленнее чем период ожидания ответа мастером - то есть большая вероятность что мастер спросит уже другое, а тут свежезапоздавший зомби-пакет, получите-распишитесь. И мастер никак его не отличит.
Парни, понимая что получается лажа взяли идентификатор транзакции и типо по нему будет сортировка. Так себе решение, сильно усложняющее мастер и совсем не гарантирующее хоть какие нибудь тайминги в загруженной сети.
Валенок много писанины. Еще раз, скачайте описание протокола, я гуглом переводил. Вероятно в TCP реализации это придумали СПЕЦИАЛЬНО для возможности
1. опрашивать быстрее, чем привыкли в RTU
2. опрашивать не последовательно, постоянно ожидая ответов, например в асинхронном режиме.
Другой вопрос, что этого никто не захотел реализовать, или никто не смог. Если протоколом не запрещено, то как минимум этим возможно воспользоваться...
Кстати реализаций дополнительных функций нет практически ни у кого, а там можно массивы "отсебятинских" байт посылать легко, не привязываясь к регистрам вообще. Типа создал свою структуру на 200 байт и гоняй туда сюда...
з.ы. у меня где-то лежит английская версия, но вроде как на modbus чего-то org думаю и сами найдете... если не найдете, пишите, поищу у себя...
Много общего, мало конкретики. Где сказано об обязательном изменении ide ?
Вот вообще непарит зачем это придумали.
Видимо придумали, а после поняли что нафик ненужно т.к. мастера-клиенты немного офигеют от такого работая в подавляющем большинстве случаев в рамках идеологии модбаса : запрос-ответ.Цитата:
Другой вопрос, что этого никто не захотел реализовать,..
++
И вот - обнаружил:
И я о том же )) Просил, просил как-то описать мастера. А в ответ - таймаут.
++
А кто этим воспользуется ? Сервера ? И офигительно удивят подавляющее кол-во клиентов - см. выше? ))Цитата:
. Если протоколом не запрещено, то как минимум этим возможно воспользоваться...
Мы о tcp же ? Не ожидайте. Отправьте несколько запросов подряд в Овен-ПЛК. И нет проблем. Только паузу между сделайте не меньше времени цикла в ПЛК если слейв - в конфигурации. А программным сервером легко обработать и без пауз.
Ответы придут - в порядке запросов. А сумеете ли обработать поток ответов - ваши проблемы.
А кто это реализует ? Сервер ? Открываем панельку с галочками в какой-нить скаде - и .... ставим себя на место наладчика. Вы хотите регулярно изучать "реальные посылки и ответы от родного ПО данного терминала" или решать задачи технологии ?
А что будет идентифицировать эту структуру ? Функция ? А сегодня внезапно 150 штук таких структур - и ?
Или приспичит из этой структуры получить с 24 по 48 байты - и ?
Да и непоразили - в рамках стандарта чем 250/246 не устроило ?
Или кто-то обязывает прям таки отображать регистры на живой массив ? Конкретный регистр+конкретный размер => готовый ide для чего угодно. И все - в рамках.
Пишу сразу. Интересует именно обязательность изменения ide клиентом.
Кто дружит с модбас 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?
Отлично. Во всем доке ровно 4 упоминания про udp. Из них 2 - именно на том месте, которое вы и привели. В оглавление просто постеснялись вытаскивать? "его фамилия слишком известна чтоб они её приводили"?
И да. А где модель работы модбас UDP-мастера? Для tcp я привёл ранее.
Где описание параметра лимитирующего кол-во ждущих ответа запросов?
Хорош волноваться не будет ни кто ни чего делать, ОВЕН повторил в очередной раз, что мало пользователей кому это необходимо и в семнадцатом году было тоже самое. У вейнтека есть такой мастер, а слейв написать не проблема, у меня и в овеновских плк и в сименсах и на ПК всё работает и не испытываю я проблем ни с отсутствием контрольной суммы ни с очередью
Валенок да твою ж дивизию, обязаловки НЕТ, это предусмотрели просто протоколом Modbus TCP, пользоваться этим или нет на совести производителя оборудования. При этом нет никаких нарушений протокола, так как это в нем указано.
Вот с пуркуа бы?, если один из запросов будет запрос архива какой-нить 15-й функцией или что там есть по списку протокола и устройство его подготовит за большее время, чем вы поставите таймаут?Цитата:
Ответы придут - в порядке запросов. А сумеете ли обработать поток ответов - ваши проблемы.
Все на совести производителя прибора. Если не устраивает производителя привязка к 1-му, 2-м регистрам, он может передать то, что захочет. Протокол не нарушен, если вы не можете прочесть - ваша проблема.Цитата:
Или приспичит из этой структуры получить с 24 по 48 байты - и ?
Да и непоразили - в рамках стандарта чем 250/246 не устроило ?
Видел неоднократно приборы, причем российские, где старым добрым Modbus 3,4 функции читались текущие параметры, а другими функциями вычитываются архивы. Все описано в документации на прибор - не могете, ваши проблемы...
Ethernet/IP повторяет заголовки TCP, по этому его пропускают все коммутаторы на ура. Он просто замещает TCP, не более. UDP там не пахнет и близко.
Вот EtherCAT это другое... а Ethernet/IP сюда приплетать не надо.
)) Да я собстенно не волнуюсь. Причем и не говорю что модбас-udp не возможен/не нужен.
А за счет чего - не испытываете ? Вот заслали 10 запросов и ждете 10 ответов ?Цитата:
не испытываю я проблем .. с очередью