Просмотр полной версии : Поддержка Modbus UDP
Пожалуйста, рассмотрите возможность добавить поддержку Modbus UDP master/slave для ПЛК и Modbus UDP slave для модулей ввода-вывода.
Всё в рамках актуальной спецификации Modbus, меняется (добавляется) только транспортный протокол - UDP.
Евгений Кислов
25.03.2023, 15:39
Пожалуйста, рассмотрите возможность добавить поддержку Modbus UDP master/slave для ПЛК и Modbus UDP slave для модулей ввода-вывода.
Всё в рамках актуальной спецификации Modbus, меняется (добавляется) только транспортный протокол - UDP.
Добрый день.
Приведите примеры устройств других производителей, которые поддерживают этот вариант протокола, пожалуйста (c ссылками на техническую документацию).
Особенно интересуют модули.
Если честно, я не понимаю тех, кто это разработал.... Завернуть 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-modules?protokol=Протокол_Modbus+TCP+Slave,Протоко л_Modbus+UDP+Slave
Единственное, что я не совсем понимаю - зачем модулю в/в нужно быть мастером?
Завернуть TCP в UDP
Мсье знает толк. В извращениях. :eek:
ну и смысл велосипеда?
В Вашем изложении - никакого.
А так, в своей практике я единственный раз сталкивался с ситуацией, когда пришлось перейти с tcp на udp. Правда, тот случай никакого отношения к modbus tcp/udp не имеет. Просто китайский конвертер последовательного порта по необъяснимым для меня причинам отказался работать по tcp.
я в вейнтековской панели всегда ставлю галку передавать по UDP, когда работаю с протоколом modbusTCP
Евгений Кислов
26.03.2023, 08:55
Да легко:
https://icp-das.ru/collections/io-modules?protokol=Протокол_Modbus+TCP+Slave,Протоко л_Modbus+UDP+Slave
Единственное, что я не совсем понимаю - зачем модулю в/в нужно быть мастером?
Очень показательный пример - на него я и рассчитывал.
Открываем мануал на любой из модулей (например - ET-7026):
https://insat.ru/products/icpdas/PET-7026_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 протокола, чтобы устройство точно знало, что пакет не битый...
И тем самым все сведется на нет...
Хотя вроде какой-то базовый функционал проверки целостности есть... Вот что будет делать устройство, если получит неполный пакет?
Добрый день.
Приведите примеры устройств других производителей, которые поддерживают этот вариант протокола, пожалуйста (c ссылками на техническую документацию).
Особенно интересуют модули.
Я предлагал рассмотреть такую возможность только для ПЛК и модулей ВВ вашего производства.
Есть ли ПЛК и модули ВВ у других производителей с поддержкой Modbus UDP меня не сильно интересует.
imaex ну давайте сначала. Одно из различий Modbus TCP от RTU заключается в том, что из пакета Modbus убрали CRC, возложив это на TCP стек, то есть устройство, принимая TCP пакет уже знает, что пакет битый или не битый и уже нет необходимости проверять пакет непосредственно Modbus протокола.
в UDP нет контрольных сумм насколько помню. То есть изобретая протокол Modbus UDP потребуется вернуть обратно CRC протокола, чтобы устройство точно знало, что пакет не битый...
И тем самым все сведется на нет...
Хотя вроде какой-то базовый функционал проверки целостности есть... Вот что будет делать устройство, если получит неполный пакет?
Пожалуйста, постарайтесь разобраться с работой протокола UDP получше.
Евгений Кислов
26.03.2023, 09:14
Я предлагал рассмотреть такую возможность только для ПЛК и модулей ВВ вашего производства.
Есть ли ПЛК и модули ВВ у других производителей с поддержкой Modbus UDP меня не сильно интересует.
Тогда, пожалуйста, опишите - зачем нам рассматривать возможность поддержки протокола, несовместимого с устройствами других производителей?
В чем самоцель?
Смысл кстати есть в распределенных системах. В том числе и мульти мастера.
Например опрос устройств раз в 20 минут, но если что произошло устройство присылает необходимые данные раньше наступления запроса со стороны сервера.
Отправка одной команды выбранным или всем устройствам сразу.
Tacio ну не сетевой специалист, а так, отсутствие повторной передачи, отсутствие гарантии доставки, меньше заголовок, нет необходимости создавать коннект, просто можно плюнуть в пустоту :)
Тут больше вопрос для чего?
Очень показательный пример - на него я и рассчитывал.
Открываем мануал на любой из модулей (например - ET-7026):
https://insat.ru/products/icpdas/PET-7026_ET-7026_RE.pdf
Открываем произвольно выбранный даташит (https://cdn.shopify.com/s/files/1/0554/3149/5732/files/P_ET-7050__P_ET-7250A_datasheet_rev01_a14098d1-aa51-4ff0-aea3-d3cb250a2e02.pdf?v=1666874961) и читаем:
Protocol Modbus TCP, Modbus UDP
Был бы мне доступен один из модулей для проверки - можно было бы более аргументированно. А так - приходится верить даташитам.
Евгений Кислов
26.03.2023, 09:42
Поэтому я в своем первом посте и попросил ссылки на техническую документацию, а не 2-страничные даташиты.
Написать можно всё что угодно - и без технического контекста эту информацию часто можно интерпретировать неверно.
imaex ну давайте сначала.
Давайте.
Завернуть TCP в UDP.
Перечитайте херню, которую Вы написали. Сколько угодно раз - пока не поймёте.
Поэтому я в своем первом посте и попросил ссылки на техническую документацию, а не 2-страничные даташиты.
Написать можно всё что угодно - и без технического контекста эту информацию часто можно интерпретировать неверно.
Даташиты - это тоже техническая документация. В мануалах тоже всякого можно прочитать - а там дрова.
Вы можете хотя бы дать ссылку на то, что эти модули не поддерживают modbus udp?
Смысл кстати есть в распределенных системах. В том числе и мульти мастера.
Например опрос устройств раз в 20 минут, но если что произошло устройство присылает необходимые данные раньше наступления запроса со стороны сервера.
Отправка одной команды выбранным или всем устройствам сразу.
Почему бы и нет? Что-то подобное есть в SNMP.
Tacio ну не сетевой специалист, а так, отсутствие повторной передачи, отсутствие гарантии доставки, меньше заголовок, нет необходимости создавать коннект, просто можно плюнуть в пустоту :)
Тут больше вопрос для чего?
Предыдущим предложением вы уже описали для чего: убираем весь overhead, который есть в TCP.
Тогда, пожалуйста, опишите - зачем нам рассматривать возможность поддержки протокола, несовместимого с устройствами других производителей?
В чем самоцель?
По той же причине, по которой связь реального времени между соответствующими устройствами в IP-сетях обычно организуют на базе UDP, а не TCP.
Евгений Кислов
26.03.2023, 09:54
По той же причине, по которой связь реального времени между соответствующими устройствами в IP-сетях обычно организуют на базе UDP, а не TCP.
По моему опыту - "связь реального времени" в промышленности обычно организуют с помощью протоколов реального времени - EtherCAT, Profinet и т.д.
Вы квалифицированный специалист - поэтому наверняка сможете оценить упомянутый "overhead" в байтах, а затем - в сэкономленных милли-(или микро)секундах в случае его исчезновения при переходе с TCP на UDP.
Я не исключаю, что есть единичные задачи, где, возможно, такая экономия была бы оправданной (к сожалению, вашей реальной задачи вы за столько постов так и не описали).
Но рассматривая возможность реализации Modbus UDP для нашего оборудования - я вижу, что таких пожеланий от клиентов крайне мало (не более одного в год) и что это нетиражируемое решение (среди других производителей его поддерживают единицы и зачастую - несовместимым образом).
Если число таких пожеланий резко увеличится - мы опять вернемся к анализу этого вопроса.
За обратную связь спасибо.
В целом, ваша идея понятна; мы планируем реализовать ее в будущем в отдельной линейке оборудования и другим способом.
Вы можете хотя бы дать ссылку на то, что эти модули не поддерживают modbus udp?
Нет, конечно. Обычно в технической документации пишут о том, какой функционал поддерживается и как его настроить, а не наоборот.
В 100+ страничном мануале, ссылку на который приводил выше, я в принципе не нахожу ни одной фразы про Modbus UDP.
Почему бы и нет? Что-то подобное есть в SNMP..
Почему бы и нет это же по TCP ?
..убираем весь overhead, который есть в TCP...
Зачем, если он (overhead) упрощает (см.ниже (да и выше Е.Кислов про это же)) обработку, а значит повышает надежность (в смысле ошибок кода)
..По той же причине, по которой связь реального времени между соответствующими устройствами в IP-сетях обычно организуют на базе UDP, а не TCP.
Ну напишите сходу простой обработчик udp-модбас запросов который учитывает возможные непоследовательности и дупликаты ответов
++
..
Вы можете хотя бы дать ссылку на то, что эти модули не поддерживают modbus udp?
Открыл "Три мушкетера" - упоминаний что мушкетеры не поддерживают modbus udp не нашел. Значит поддерживают ?
Евгений, ваша позиция понятна, спасибо.
Почему бы и нет это же по TCP ?
Групповые сообщения (multicast) по TCP?
Зачем, если он (overhead) упрощает (см.ниже (да и выше Е.Кислов про это же)) обработку, а значит повышает надежность (в смысле ошибок кода)
Использование протокола TCP ну никак не спасает и не страхует от ошибок в коде :)
А вот если какой-то пакет с телеметрией потеряется и TCP начнёт процедуру отсчёта таймаута, затем повторную передачу потерянного пакета, до данные в этом пакете уже протухнут и, по-хорошему, надо бы уже запрашивать более свежие. Вот такая "надёжность" только мешает.
Или, например, оборвётся линк в кольце между ПЛК и модулями ВВ. RSTP отработает за 1-2с (допустим это приемлемо), но восстановление TCP соединения в некоторых случаях может задержатся ещё на 5с, что уже неприемлемо.
Ну напишите сходу простой обработчик udp-модбас запросов который учитывает возможные непоследовательности и дупликаты ответов
В протоколе MODBUS есть специальное поле идентификатора транзакции, которое как раз и нужно для таких случаев в том числе. И должно оно обрабатываться всегда независимо от транспортного протокола, который может и сам умеет отслеживать и дубликаты, и неверный порядок.
Tacio за все время встречалось только одно устройство, которое не работало без заполненного поля "Идентификатор транзакции"
..Групповые сообщения (multicast) по TCP?
1.Если что, там еще речь была о инициирующей отправку данных стороне.
2.А зачем нужна ненадежная форма отправки задач в промышленном оборудовании ?
Использование протокола TCP ну никак не спасает и не страхует от ошибок в коде :) к.
Проще логика (см. в конце поста) - проще сразу выявить все ошибки. Удивляет, да ?
А вот если какой-то пакет с телеметрией потеряется и TCP начнёт процедуру отсчёта таймаута, затем повторную передачу потерянного пакета,...
Можно с этого места поподробней ? Вы же разбираетесь с протоколами как я понял.
до данные в этом пакете уже протухнут и, по-хорошему, надо бы уже запрашивать более свежие.
Кто и как протухнет в TCP-потоке - интересуют подробности.
И главное - как на фоне этого UDP сохраняет свежесть ?
..это приемлемо...уже неприемлемо.
Определимся с "приемлимостью" ? Это что ?
о восстановление TCP соединения в некоторых случаях может задержатся ещё на 5с..
Т.е. присутствуют проблемы (физические/внешние на линии/местные внутрисистемные/...) приводящие к задержкам.
А UDP приносят голуби и их это не касается ?
..
В протоколе MODBUS есть специальное поле идентификатора транзакции...
Для Модбас-TCP оно избыточно если что. Не ?
..
В протоколе MODBUS есть специальное поле идентификатора транзакции, которое как раз и нужно для таких случаев в том числе. И должно оно обрабатываться всегда независимо от транспортного протокола, который может и сам умеет отслеживать и дубликаты, и неверный порядок.
Так я же и просил Вас написать для вышеизложенного (с Модбас-UDP) простенький алгоритм обработки.
Вот например для Модбас-TCP:
1.Открыл коннект
2.Отправил запрос
3.Получил норм ответ - goto 2, таймаут/мусор - goto 4
4.Закрыл коннект
5.goto 1
Для Модбас-TCP оно избыточно если что. Не ? может и не избыточно, как раз говорит что ответ строго на данный запрос...
может и не избыточно, как раз говорит что ответ строго на данный запрос...
А как это по tcp может быть другой ответ ?
----
Вот что вы сделаете с девайсом (слейвом) с модбас-RTU которое иногда сохраняет запрос где-то в памяти и не отвечает, а после вдруг где-то между другими нормальными запросами/ответами вдруг вспоминает этот забытый/забитый запрос и внезапно отправляет ответ на него ?
Валенок это я не знаю, говорю же, встречал только одно устройство, которое не отвечало, если Идентификатор Транзакции был всегда 0 или он не менялся на следующем запросе.
Слейв устройство просто игнорировало запрос.
Какой-то весовой терминал Shenk, точную модель не знаю.
Валенок это я не знаю, говорю же, встречал только одно устройство, которое не отвечало, если Идентификатор Транзакции был всегда 0 или он не менялся на следующем запросе.
Слейв устройство просто игнорировало запрос.
Какой-то весовой терминал Shenk, точную модель не знаю.
Это было конкретное устройство с багом. Баг - т.к. протокол не требует какого-то особенного ide от клиента(мастера). Только от сервера - ide ответа должен совпадать с запросом. Как обойти этот баг - вам понятно. Какие проблемы ?
Я спросили Вас про Вашу реакцию на девайс(слейв) с вышеописанным поведением по RTU
Валенок это не баг, а функционал.
Смотрите, обычно мы привыкли, что происходит запрос и мы ждем ответа. ВЫ не думали что может быть иная ситуация, запрос1, запрос2, запрос3 и просто ждем ответы в асинхронном режиме, причем ответ 3 придет первым, ответ 1 вторым, а ответ 2 третьим.
Именно Modbus TCP это позволяет, другой вопрос что практически никто это не реализует в драйверах...
Пример: например сформировать ответ на запрос №2 устройству требуется 20 секунд, а на запрос 3 всего 0,5 секунды.
.. это не баг, а функционал.
Есть протокол. Всё вне этого - баг (добавил) если оно мешает работе по протоколу.
..ВЫ не думали что может быть иная ситуация, запрос1, запрос2, запрос3 и просто ждем ответы в асинхронном режиме, причем ответ 3 придет первым, ответ 1 вторым, а ответ 2 третьим.
...
Вы так и не ответили про Вашу реакцию про вышеописанное поведение RTU-слейва.
++
Пример: например сформировать ответ на запрос №2 устройству требуется 20 секунд, а на запрос 3 всего 0,5 секунды.
Exception №5...6 - вот для такого.
"другой вопрос что практически никто это не реализует в драйверах" (C) ))
Валенок Прочтите протокол в английском варианте, там как раз и указано что Transaction ID предусмотрен, если ответы поступают не последовательно во времени. Так что это протоколом предусмотрено. Только не первым от Modicon, а уже о последней редакции.
У меня реакции никакой, с данным устройство обратился человек на форуме RapidScada, показав реальные посылки и ответы от родного ПО данного терминала. Как раз и определили, что у него меняются Transaction Id и со значением 0 устройство не отвечает. В результате разработчик доработал драйвер Modbus. Что абсолютно не противоречит протоколу. Тем более другие устройства это значение просто игнорируют.
..Прочтите протокол в английском варианте, ...Только не первым от Modicon, а уже о последней редакции.
А можно этот непоследний оригинал привести ? И указать на фразу со смыслом "ide запросов обязательно должны отличатся [не быть 0 и т.п.]" ?
...Transaction ID предусмотрен, если ответы поступают не последовательно во времени
Это чему-то противоречит? Ключевое слово - "если". А много именно мастеров/клиентов готовы к этому динамическому списку текущих транзакций с индивидуальным контролем времени их жизни ? (было где-то - "другой вопрос что практически никто это не реализует в драйверах") Причем с четкими правилами-параметрами для конфигурации - ведь предполагается именно это, а не ручное руление.
Уже двоих просил показать простенькую модель работы такого клиента)).
.. с данным устройство обратился человек на форуме RapidScada, показав реальные посылки и ответы от родного ПО данного терминала...
Я как-то спорю что этого не было ?
.Как раз и определили, что у него меняются Transaction Id ..
У кого - "у него" ? У клиента ? Так он хозяин ide.
...и со значением 0 устройство не отвечает..
Я ж и говорю - баг устройства. Если он (баг) по каким-то причинам в устройстве вынужденный (всё может быть) - то должен быть описан в соотв.РЭ, тогда баг переходит в разряд специфицированных особенностей конкретного девайса.
Вы действовали по протоколу, а оно не отвечало:
-или Вы не читали РЭ
-или это баг который вы ловили, поймали и описали как настоящие энтомологи следующие на Суматру.
Вы всю жизнь пилотом летали на БоингеXXX, сели на БоингYYY, а заместо убрать шасси - стопкран. Прецеденты были же. Не радостные. Как вот это:
..показав реальные посылки и ответы от родного ПО данного терминала.
изучать в воздухе, норм ?
..В результате разработчик доработал драйвер Modbus. ..
Разработчик драйвера какой стороны ? Клиентской ? Запилил изменяемое и неравное нулю ide ? Так выше же - клиент хозяин ide, что хочет, то и ставит.
.Что абсолютно не противоречит протоколу..
Я где-то спорю ? Действия клиента абсолютно не противоречат протоколу ни в 1-ом ни во 2-ом случае. Проcто во 2-ом случае клиент еще и учел баг девайса(сервера)
... Тем более другие устройства это значение просто игнорируют.
Другие устройства в модбас-tcp ответах пишут ide отличное от ide запроса ?
Филоненко Владислав
26.03.2023, 17:28
Если честно, я не понимаю тех, кто это разработал.... Завернуть TCP в UDP не составляет особого труда для сетевого оборудования вроде.
А что происходит тут?, к Modbus TCP необходимо добавить снова CRC как в RTU чтобы проверять пакеты протокола?
перевод
ну и смысл велосипеда?
По логике "Великих Автоматизаторов" основная проблема ModBus TCP - это время установления коннекта. И если его "убрать" сразу всё заколосится и полетит со сверхсветовой скоростью.
Но, если в ModBusTCP есть логичная и понятная система запрос-ответ с приходом пакетов по порядку, то в ModBusUDP кинул зёрна в поле - авось взойдут. Т.е. если мастер посылает пакет Slave для управления выходами - еще худо-бедно пакет дойдёт (пусть и не первый, но у нас же скорость, пулемёт дострелит) и выход включится. На пустой сети включится быстро.
А вот если мастер посмел запросить состояние входа - то тут будет ли ответ, когда, и самое главное на какой запрос - тайна великая.
Ведь у Модбаса в ответе нет номера регистра и можно лишь гадать ответ на какой запрос пришёл по UDP.
Кстати эта проблема с приходом ответов не по порядку есть и у RTU модбаса - если Slave отвечает медленнее чем период ожидания ответа мастером - то есть большая вероятность что мастер спросит уже другое, а тут свежезапоздавший зомби-пакет, получите-распишитесь. И мастер никак его не отличит.
Парни, понимая что получается лажа взяли идентификатор транзакции и типо по нему будет сортировка. Так себе решение, сильно усложняющее мастер и совсем не гарантирующее хоть какие нибудь тайминги в загруженной сети.
Newcomer
26.03.2023, 19:05
Кстати эта проблема с приходом ответов не по порядку есть и у RTU модбаса - если Slave отвечает медленнее чем период ожидания ответа мастером - то есть большая вероятность что мастер спросит уже другое, а тут свежезапоздавший зомби-пакет, получите-распишитесь. И мастер никак его не отличит.
А что мешает в настройках сделать побольше период ожидания ответа мастером ?
Валенок много писанины. Еще раз, скачайте описание протокола, я гуглом переводил. Вероятно в TCP реализации это придумали СПЕЦИАЛЬНО для возможности
1. опрашивать быстрее, чем привыкли в RTU
2. опрашивать не последовательно, постоянно ожидая ответов, например в асинхронном режиме.
Другой вопрос, что этого никто не захотел реализовать, или никто не смог. Если протоколом не запрещено, то как минимум этим возможно воспользоваться...
Кстати реализаций дополнительных функций нет практически ни у кого, а там можно массивы "отсебятинских" байт посылать легко, не привязываясь к регистрам вообще. Типа создал свою структуру на 200 байт и гоняй туда сюда...
з.ы. у меня где-то лежит английская версия, но вроде как на modbus чего-то org думаю и сами найдете... если не найдете, пишите, поищу у себя...
...много писанины. Еще раз. Еще раз, скачайте описание протокола, я гуглом переводил.
Много общего, мало конкретики. Где сказано об обязательном изменении ide ?
Вероятно в TCP реализации это придумали СПЕЦИАЛЬНО для ..
Вот вообще непарит зачем это придумали.
Другой вопрос, что этого никто не захотел реализовать,..
Видимо придумали, а после поняли что нафик ненужно т.к. мастера-клиенты немного офигеют от такого работая в подавляющем большинстве случаев в рамках идеологии модбаса : запрос-ответ.
++
И вот - обнаружил:
Парни, понимая что получается лажа взяли идентификатор транзакции и типо по нему будет сортировка. Так себе решение, сильно усложняющее мастер и совсем не гарантирующее хоть какие нибудь тайминги в загруженной сети.
И я о том же )) Просил, просил как-то описать мастера. А в ответ - таймаут.
++
. Если протоколом не запрещено, то как минимум этим возможно воспользоваться...
А кто этим воспользуется ? Сервера ? И офигительно удивят подавляющее кол-во клиентов - см. выше? ))
..опрашивать не последовательно, постоянно ожидая ответов,..
Мы о tcp же ? Не ожидайте. Отправьте несколько запросов подряд в Овен-ПЛК. И нет проблем. Только паузу между сделайте не меньше времени цикла в ПЛК если слейв - в конфигурации. А программным сервером легко обработать и без пауз.
...например в асинхронном режиме...
Ответы придут - в порядке запросов. А сумеете ли обработать поток ответов - ваши проблемы.
Кстати реализаций дополнительных функций нет практически ни у кого,.
А кто это реализует ? Сервер ? Открываем панельку с галочками в какой-нить скаде - и .... ставим себя на место наладчика. Вы хотите регулярно изучать "реальные посылки и ответы от родного ПО данного терминала" или решать задачи технологии ?
..там можно массивы "отсебятинских" байт посылать легко, не привязываясь к регистрам вообще. Типа создал свою структуру на 200 байт и гоняй туда сюда.
А что будет идентифицировать эту структуру ? Функция ? А сегодня внезапно 150 штук таких структур - и ?
Или приспичит из этой структуры получить с 24 по 48 байты - и ?
Да и непоразили - в рамках стандарта чем 250/246 не устроило ?
Или кто-то обязывает прям таки отображать регистры на живой массив ? Конкретный регистр+конкретный размер => готовый ide для чего угодно. И все - в рамках.
..
з.ы. у меня где-то лежит английская версия, но вроде как на modbus чего-то org думаю и сами найдете... если не найдете, пишите, поищу у себя...
Пишу сразу. Интересует именно обязательность изменения ide клиентом.
Добрый день.
Приведите примеры устройств других производителей, которые поддерживают этот вариант протокола, пожалуйста (c ссылками на техническую документацию).
Особенно интересуют модули.
Кто дружит с модбас UDP?
https://shopping.coolmayplchmi.com/sale-467748-coolmay-l02-series-host-module-programmable-controller-plc-monitor-rs485-ethernet-port-modbus-protocol.htm
инструкция на эту тему
https://en.coolmay.com/webdown/Coolmay%20L02%20Series%20PLC%20Progarmming%20Manua l.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?
TCP зло, у UDP преимуществ больше, например не ограничено количество соединений как у TCP, нет обслуживающего (паразитного трафика, который время у мозгов камня занимает), и скорость выше.
Ни то, ни другое не являются злом, просто выбор конкретного транспортного протокола зависит от решаемой задачи.
Кто дружит с модбас UDP?
https://shopping.coolmayplchmi.com/sale-467748-coolmay-l02-series-host-module-programmable-controller-plc-monitor-rs485-ethernet-port-modbus-protocol.htm
инструкция на эту тему
https://en.coolmay.com/webdown/Coolmay%20L02%20Series%20PLC%20Progarmming%20Manua l.pdf
строчки по настройке порта... ?
Отлично. Во всем доке ровно 4 упоминания про udp. Из них 2 - именно на том месте, которое вы и привели. В оглавление просто постеснялись вытаскивать? "его фамилия слишком известна чтоб они её приводили"?
И да. А где модель работы модбас UDP-мастера? Для tcp я привёл ранее.
Где описание параметра лимитирующего кол-во ждущих ответа запросов?
Отлично. Во всем доке ровно 4 упоминания про udp. Из них 2 - именно на том месте, которое вы и привели. В оглавление просто постеснялись вытаскивать? "его фамилия слишком известна чтоб они её приводили"?
И да. А где модель работы модбас UDP-мастера? Для tcp я привёл ранее.
Где описание параметра лимитирующего кол-во ждущих ответа запросов?
Хорош волноваться не будет ни кто ни чего делать, ОВЕН повторил в очередной раз, что мало пользователей кому это необходимо и в семнадцатом году было тоже самое. У вейнтека есть такой мастер, а слейв написать не проблема, у меня и в овеновских плк и в сименсах и на ПК всё работает и не испытываю я проблем ни с отсутствием контрольной суммы ни с очередью
Валенок да твою ж дивизию, обязаловки НЕТ, это предусмотрели просто протоколом Modbus TCP, пользоваться этим или нет на совести производителя оборудования. При этом нет никаких нарушений протокола, так как это в нем указано.
Ответы придут - в порядке запросов. А сумеете ли обработать поток ответов - ваши проблемы.
Вот с пуркуа бы?, если один из запросов будет запрос архива какой-нить 15-й функцией или что там есть по списку протокола и устройство его подготовит за большее время, чем вы поставите таймаут?
Или приспичит из этой структуры получить с 24 по 48 байты - и ?
Да и непоразили - в рамках стандарта чем 250/246 не устроило ?
Все на совести производителя прибора. Если не устраивает производителя привязка к 1-му, 2-м регистрам, он может передать то, что захочет. Протокол не нарушен, если вы не можете прочесть - ваша проблема.
Видел неоднократно приборы, причем российские, где старым добрым Modbus 3,4 функции читались текущие параметры, а другими функциями вычитываются архивы. Все описано в документации на прибор - не могете, ваши проблемы...
Ethernet/IP повторяет заголовки TCP, по этому его пропускают все коммутаторы на ура. Он просто замещает TCP, не более. UDP там не пахнет и близко.
Вот EtherCAT это другое... а Ethernet/IP сюда приплетать не надо.
)) Да я собстенно не волнуюсь. Причем и не говорю что модбас-udp не возможен/не нужен.
не испытываю я проблем .. с очередью
А за счет чего - не испытываете ? Вот заслали 10 запросов и ждете 10 ответов ?
)) Да я собстенно не волнуюсь. Причем и не говорю что модбас-udp не возможен/не нужен.
А за счет чего - не испытываете ? Вот заслали 10 запросов и ждете 10 ответов ?
во первых панель мастер, поэтому я ни чего не засылаю, пришел запрос я на него ответил, инфа обычно для отображения, даже если случится какая то помеха, вряд ли оператор заметит что показания как то отличаются. Управляющие сигналы если уж не сработали это же тоже видно сразу, нет проблем еще раз нажать кнопку, чтоб послать точно такой же запрос
инфа обычно для отображения
Так для "отображений" udp по сути и создан. Я про что-то управляющее. И не "еще раз нажать кнопку" а автоматически.
это же тоже видно сразу
Это да. В каком-нить конвейре ))
..., обязаловки НЕТ,...
Ну вот - "НЕТ".
А что если не баг было в том у устройстве которому Вы (или тот чел) слали запросы (согласно протоколу) в котором ide был 0(?) а девайс не отвечал ? Или же его РЭ не читали )) ?
При этом нет никаких нарушений протокола,
... со стороны клиента. А сервер не отвечает. И тоже нет ни каких нарушений. Ну да. Протокол такой. Хочешь отвечай, а хочешь и не. Удобный и практичный.
Валенок а кто сказал что это баг?, производитель решил промаркировать пакеты, его полное право, согласно протокола, а то, что какие-то там OPC или еще кто не умеют маркировать, их проблемы.
Послали вместо 0 1-чку, прибор ответил сразу, вот и все.
Аналогичная маркировка пакетов есть и в других протоколах, ниче, живут же...
Кстати в английском описании по Modbus так и указано, в простом варианте для Transaction Identifical сделать счетчик, а не слать все время 0 как оглашенный. :)
Но у нас же все писатели, читателей нет нихрена... (я про разработчиков)
Так для "отображений" udp по сути и создан. Я про что-то управляющее. И не "еще раз нажать кнопку" а автоматически.
Это да. В каком-нить конвейре ))
а зачем мы тогда в автоматизации работаем если у нас оператор логикой работы занимается, использовать плк в качестве модуля ввода-вывода это как то не профессионально. Проблемы потери доставки управляющего пакета, настолько же мизерны, как нудить о том что останавливающая кнопка находится на некоем экране, до которого оператор должен добраться через систему меню
И да. А где модель работы модбас UDP-мастера? Для tcp я привёл ранее.
Извините, а какая такая "модель" Вас интересует? Это нижележащий протокол, транспортный уровень. К modbus как таковому никакого отношения не имеющий вообще. Сказали, что tcp будет транспортом - будет tcp, сказали udp - будет udp. В чем вопрос? Вы сомневаетесь в самом факте реализации modbus-мастера через upd? Совершенно напрасно.
.. а кто сказал что это баг?..
Ну конечно не баг. Слейву-серверу шлют запрос согласно протоколу, а он шлет всех в сад. Согласно протоколу.
"Этот столик - не обслуживатся"
https://www.youtube.com/watch?v=hYayV7cSXVI
Ну конечно не баг. Слейву-серверу шлют запрос согласно протоколу, а он шлет всех в сад. Согласно протоколу.
так что не так то, мастер будет следовать алгоритму таймаут, в чем паника то
так что не так то, мастер будет следовать алгоритму таймаут, в чем паника то
Может вы ранее написанное пропустили. Таймаут - всегда. . Т.е. его - нет с точки зрения клиента. А он - есть )).
Ведь клиент (первично) следовал согласно протоколу. Люди стали заниматся энтомологией.
Валенок ты утомил
Several MODBUS transactions can be activated simultaneously on the same TCP
Connection.
Remark: If this is done then the MODBUS transaction identifier must be used to
uniquely identify the matching requests and responses.
The transaction identifier is used to associate the future response with the request.
So, at a time, on a TCP connection, this identifier must be unique. There are
several manners to use the transaction identifier:
- For example, it can be used as a simple "TCP sequence number" with a
counter which is incremented at each request.
- It can also be judiciously used as a smart index or pointer to identify a
transaction context in order to memorize the current remote server and the
pending MODBUS request.
Переводи пожалуйста сам, если никто не делает уникальный идентификатор, как того требует протокол как раз и есть БАГ. Удачи.
да, ссылка https://modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
Может вы ранее написанное пропустили. Таймаут - всегда. . Т.е. его - нет с точки зрения клиента. А он - есть )).
подробнее расшифруйте, я просто не про теорию говорю, а про опыт с конкретным мастером modbusTCP по UDP, локальный порт для принятия ответа всегда есть
Извините, а какая такая "модель" Вас интересует? .
Я ранее пример для tcp привел. пост#22
Вы сомневаетесь в самом факте реализации modbus-мастера через upd? Совершенно напрасно.
Из раннего "...Причем и не говорю что модбас-udp не возможен/не нужен.."
подробнее расшифруйте...
Пост#25.... и дальше
Пост#25.... и дальше
и что там, рассуждаете про MBAP, ни как не связано не совпадение счетчика с отсутствием ответа вообще
и что там, рассуждаете про MBAP, ни как не связано не совпадение счетчика с отсутствием ответа вообще
Видимо не дочитали про причины. Выявленные далее.
Ethernet/IP повторяет заголовки TCP, по этому его пропускают все коммутаторы на ура. Он просто замещает TCP, не более. UDP там не пахнет и близко.
Правда?
EtherNet/IP classifies Ethernet nodes into predefined device types with specific behaviors. Among other things, this enables:
Transfer of basic I/O data via User Datagram Protocol (UDP)-based implicit messaging
Uploading and downloading of parameters, setpoints, programs and recipes via TCP (i.e., explicit messaging.)
Polled, cyclic and change-of-state monitoring via UDP.
One-to-one (unicast), one-to-many (multicast), and one-to-all (broadcast) communication via IP.
EtherNet/IP makes use of TCP port number 44818 for explicit messaging and UDP port number 2222 for implicit messaging (https://en.wikipedia.org/wiki/EtherNet/IP)
А коммутаторы вообще на L2 работают, они ни про tcp, ни про udp, ни даже про ip знать ничего не обязаны.
ЗЫ: кстати, а вот как раз для EtherCAT стек tcp/ip вообще опционален.
EtherNet/IP использует TCP-порт с номером 44818 для явного обмена сообщениями и UDP-порт с номером 2222 для неявного обмена сообщениями
imaex дальше требуется переводить? вообще Ethernet/IP немного разномастный, но если сравнивать с Modbus TCP, то первая часть - "явный обмен сообщениями" полностью повторяет TCP в рамках заголовка и прочего. То есть его не требуется заворачивать еще дополнительно в TCP стек.
з.ы. с неявными сообщениями как-то не разбирался, когда на руках AllenBradley был. Он работал по 44818 порту, то есть использовал именно явный обмен.
imaex дальше требуется переводить?
Вам, похоже, что да. В Ethernet/IP TCP используется для передачи некритичных по времени данных. То, что критично ко времени, передаётся по UDP.
imaex прежде чем тыкать кого-то в Вики, попробуйте на контроллере прочитать и изменить переменные по UDP. Даже если вам будут эти данные критичны при обмене.
Это опять из серии, на заборе написали, а там доски... потому что по UDP вам не отдаст данные ни один контроллер.
Филоненко Владислав
27.03.2023, 16:46
А что мешает в настройках сделать побольше период ожидания ответа мастером ?
Тем что он больше. И если устройство отвалилось - дольше будет ждать. А в случае UDP - ждать дольше - похоронить саму суть "быстрого" UDP
Филоненко Владислав
27.03.2023, 17:04
В общем, попытка сделать через ModBus UDP некий "Ethercat для совсем нищих" обречена на провал (что и подтверждает отсутствие сколь нибудь заметных количеств таких устройств на рынке.
Причин несколько:
1. Для работы сети Ethernet в реальном времени нужно чтобы в ней отсутствовали паразитные асинхронные пакеты, такие как ARP и ICMP, и также любые другие кроме UDP.
2. В сети должен быть 1 мастер и N устройств отвечающих точно в заданное время, не мешая друг-другу.
П №1 делает критически неудобной всю сетевую жизнь устройств. Только заданные таблицы MAC == статические IP адреса. Никакого поиска устройств, никакого пинга.
П №2 требует от всех устройств иметь точные (и корректируемые) часы и соответствующий протокол, настраивающий и использующий таймслоты (ну совсем не модбас!)
И самое главное, если выполнить п.1 (не в смысле совсем, а в смысле убрать паразитный трафик на торренты из офисной сети, изолировав в отдельный сегмент) , то обычный мастер ModBusTCP, который умеет в мультисоединение (1 коннект на устройство) работает ничуть не хуже и не медленнее.
Обычно задержки на работу со стеком IP и передачу сервисных пакетов на порядки ниже чем явный или скрытый цикл мастера и время подготовки ответа Slave-ом. Т.е. надо ускорять сами приборы, а не протокол.
А если выполнить и п.2 - то получится обычный RT-протокол типа Профинета.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot