Поддержка Modbus UDP

[Newcomer]

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

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

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

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

Тем что он больше. И если устройство отвалилось - дольше будет ждать. А в случае UDP - ждать дольше - похоронить саму суть "быстрого" UDP

[capzap]

я в вейнтековской панели всегда ставлю галку передавать по UDP, когда работаю с протоколом modbusTCP

[melky]

imaex ну давайте сначала. Одно из различий Modbus TCP от RTU заключается в том, что из пакета Modbus убрали CRC, возложив это на TCP стек, то есть устройство, принимая TCP пакет уже знает, что пакет битый или не битый и уже нет необходимости проверять пакет непосредственно Modbus протокола.

в UDP нет контрольных сумм насколько помню. То есть изобретая протокол Modbus UDP потребуется вернуть обратно CRC протокола, чтобы устройство точно знало, что пакет не битый...
И тем самым все сведется на нет...

Хотя вроде какой-то базовый функционал проверки целостности есть... Вот что будет делать устройство, если получит неполный пакет?

[Tacio]

imaex ну давайте сначала. Одно из различий Modbus TCP от RTU заключается в том, что из пакета Modbus убрали CRC, возложив это на TCP стек, то есть устройство, принимая TCP пакет уже знает, что пакет битый или не битый и уже нет необходимости проверять пакет непосредственно Modbus протокола.

в UDP нет контрольных сумм насколько помню. То есть изобретая протокол Modbus UDP потребуется вернуть обратно CRC протокола, чтобы устройство точно знало, что пакет не битый...
И тем самым все сведется на нет...

Хотя вроде какой-то базовый функционал проверки целостности есть... Вот что будет делать устройство, если получит неполный пакет?

Пожалуйста, постарайтесь разобраться с работой протокола UDP получше.

[imaex]

imaex ну давайте сначала.

Давайте.

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

Перечитайте херню, которую Вы написали. Сколько угодно раз - пока не поймёте.

[melky]

Смысл кстати есть в распределенных системах. В том числе и мульти мастера.
Например опрос устройств раз в 20 минут, но если что произошло устройство присылает необходимые данные раньше наступления запроса со стороны сервера.
Отправка одной команды выбранным или всем устройствам сразу.

Tacio ну не сетевой специалист, а так, отсутствие повторной передачи, отсутствие гарантии доставки, меньше заголовок, нет необходимости создавать коннект, просто можно плюнуть в пустоту

Тут больше вопрос для чего?

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

Поэтому я в своем первом посте и попросил ссылки на техническую документацию, а не 2-страничные даташиты.
Написать можно всё что угодно - и без технического контекста эту информацию часто можно интерпретировать неверно.

[imaex]

Поэтому я в своем первом посте и попросил ссылки на техническую документацию, а не 2-страничные даташиты.
Написать можно всё что угодно - и без технического контекста эту информацию часто можно интерпретировать неверно.

Даташиты - это тоже техническая документация. В мануалах тоже всякого можно прочитать - а там дрова.

Вы можете хотя бы дать ссылку на то, что эти модули не поддерживают modbus udp?

[Tacio]

Смысл кстати есть в распределенных системах. В том числе и мульти мастера.
Например опрос устройств раз в 20 минут, но если что произошло устройство присылает необходимые данные раньше наступления запроса со стороны сервера.
Отправка одной команды выбранным или всем устройствам сразу.

Почему бы и нет? Что-то подобное есть в SNMP.

Tacio ну не сетевой специалист, а так, отсутствие повторной передачи, отсутствие гарантии доставки, меньше заголовок, нет необходимости создавать коннект, просто можно плюнуть в пустоту

Тут больше вопрос для чего?

Предыдущим предложением вы уже описали для чего: убираем весь overhead, который есть в TCP.

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

По той же причине, по которой связь реального времени между соответствующими устройствами в IP-сетях обычно организуют на базе UDP, а не TCP.