Tacio за все время встречалось только одно устройство, которое не работало без заполненного поля "Идентификатор транзакции"
Tacio за все время встречалось только одно устройство, которое не работало без заполненного поля "Идентификатор транзакции"
1.Если что, там еще речь была о инициирующей отправку данных стороне.
2.А зачем нужна ненадежная форма отправки задач в промышленном оборудовании ?
Проще логика (см. в конце поста) - проще сразу выявить все ошибки. Удивляет, да ?
Можно с этого места поподробней ? Вы же разбираетесь с протоколами как я понял.А вот если какой-то пакет с телеметрией потеряется и TCP начнёт процедуру отсчёта таймаута, затем повторную передачу потерянного пакета,...
Кто и как протухнет в TCP-потоке - интересуют подробности.до данные в этом пакете уже протухнут и, по-хорошему, надо бы уже запрашивать более свежие.
И главное - как на фоне этого UDP сохраняет свежесть ?
Определимся с "приемлимостью" ? Это что ?..это приемлемо...уже неприемлемо.
Т.е. присутствуют проблемы (физические/внешние на линии/местные внутрисистемные/...) приводящие к задержкам.о восстановление TCP соединения в некоторых случаях может задержатся ещё на 5с..
А UDP приносят голуби и их это не касается ?
Для Модбас-TCP оно избыточно если что. Не ?
Так я же и просил Вас написать для вышеизложенного (с Модбас-UDP) простенький алгоритм обработки.
Вот например для Модбас-TCP:
1.Открыл коннект
2.Отправил запрос
3.Получил норм ответ - goto 2, таймаут/мусор - goto 4
4.Закрыл коннект
5.goto 1
Последний раз редактировалось Валенок; 26.03.2023 в 11:23.
может и не избыточно, как раз говорит что ответ строго на данный запрос...Для Модбас-TCP оно избыточно если что. Не ?
А как это по tcp может быть другой ответ ?
----
Вот что вы сделаете с девайсом (слейвом) с модбас-RTU которое иногда сохраняет запрос где-то в памяти и не отвечает, а после вдруг где-то между другими нормальными запросами/ответами вдруг вспоминает этот забытый/забитый запрос и внезапно отправляет ответ на него ?
Последний раз редактировалось Валенок; 26.03.2023 в 11:34.
Валенок это я не знаю, говорю же, встречал только одно устройство, которое не отвечало, если Идентификатор Транзакции был всегда 0 или он не менялся на следующем запросе.
Слейв устройство просто игнорировало запрос.
Какой-то весовой терминал Shenk, точную модель не знаю.
Последний раз редактировалось melky; 26.03.2023 в 11:40.
Это было конкретное устройство с багом. Баг - т.к. протокол не требует какого-то особенного 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) ))
Последний раз редактировалось Валенок; 26.03.2023 в 14:53.
Валенок Прочтите протокол в английском варианте, там как раз и указано что Transaction ID предусмотрен, если ответы поступают не последовательно во времени. Так что это протоколом предусмотрено. Только не первым от Modicon, а уже о последней редакции.
У меня реакции никакой, с данным устройство обратился человек на форуме RapidScada, показав реальные посылки и ответы от родного ПО данного терминала. Как раз и определили, что у него меняются Transaction Id и со значением 0 устройство не отвечает. В результате разработчик доработал драйвер Modbus. Что абсолютно не противоречит протоколу. Тем более другие устройства это значение просто игнорируют.
А можно этот непоследний оригинал привести ? И указать на фразу со смыслом "ide запросов обязательно должны отличатся [не быть 0 и т.п.]" ?
Это чему-то противоречит? Ключевое слово - "если". А много именно мастеров/клиентов готовы к этому динамическому списку текущих транзакций с индивидуальным контролем времени их жизни ? (было где-то - "другой вопрос что практически никто это не реализует в драйверах") Причем с четкими правилами-параметрами для конфигурации - ведь предполагается именно это, а не ручное руление....Transaction ID предусмотрен, если ответы поступают не последовательно во времени
Уже двоих просил показать простенькую модель работы такого клиента)).
Я как-то спорю что этого не было ?
У кого - "у него" ? У клиента ? Так он хозяин ide.
Я ж и говорю - баг устройства. Если он (баг) по каким-то причинам в устройстве вынужденный (всё может быть) - то должен быть описан в соотв.РЭ, тогда баг переходит в разряд специфицированных особенностей конкретного девайса.
Вы действовали по протоколу, а оно не отвечало:
-или Вы не читали РЭ
-или это баг который вы ловили, поймали и описали как настоящие энтомологи следующие на Суматру.
Вы всю жизнь пилотом летали на БоингеXXX, сели на БоингYYY, а заместо убрать шасси - стопкран. Прецеденты были же. Не радостные. Как вот это:
изучать в воздухе, норм ?..показав реальные посылки и ответы от родного ПО данного терминала.
Разработчик драйвера какой стороны ? Клиентской ? Запилил изменяемое и неравное нулю ide ? Так выше же - клиент хозяин ide, что хочет, то и ставит.
Я где-то спорю ? Действия клиента абсолютно не противоречат протоколу ни в 1-ом ни во 2-ом случае. Проcто во 2-ом случае клиент еще и учел баг девайса(сервера)
Другие устройства в модбас-tcp ответах пишут ide отличное от ide запроса ?
Последний раз редактировалось Валенок; 26.03.2023 в 15:11.