Поддержка Modbus UDP

[melky]

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

[melky]

Для Модбас-TCP оно избыточно если что. Не ?

может и не избыточно, как раз говорит что ответ строго на данный запрос...

[Валенок]

может и не избыточно, как раз говорит что ответ строго на данный запрос...

А как это по tcp может быть другой ответ ?

----
Вот что вы сделаете с девайсом (слейвом) с модбас-RTU которое иногда сохраняет запрос где-то в памяти и не отвечает, а после вдруг где-то между другими нормальными запросами/ответами вдруг вспоминает этот забытый/забитый запрос и внезапно отправляет ответ на него ?

[melky]

Валенок это я не знаю, говорю же, встречал только одно устройство, которое не отвечало, если Идентификатор Транзакции был всегда 0 или он не менялся на следующем запросе.
Слейв устройство просто игнорировало запрос.

Какой-то весовой терминал Shenk, точную модель не знаю.

[Валенок]

Валенок это я не знаю, говорю же, встречал только одно устройство, которое не отвечало, если Идентификатор Транзакции был всегда 0 или он не менялся на следующем запросе.
Слейв устройство просто игнорировало запрос.

Какой-то весовой терминал Shenk, точную модель не знаю.

Это было конкретное устройство с багом. Баг - т.к. протокол не требует какого-то особенного ide от клиента(мастера). Только от сервера - ide ответа должен совпадать с запросом. Как обойти этот баг - вам понятно. Какие проблемы ?

Я спросили Вас про Вашу реакцию на девайс(слейв) с вышеописанным поведением по RTU

[melky]

Валенок это не баг, а функционал.

Смотрите, обычно мы привыкли, что происходит запрос и мы ждем ответа. ВЫ не думали что может быть иная ситуация, запрос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) ))

[melky]

Валенок Прочтите протокол в английском варианте, там как раз и указано что 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 запроса ?