Добавить настройку "Таймаут между символами" в R232 и R485

[san]

При работе по протоколу Modbus RTU, при передаче пакета, требуется чтобы пауза между символами одного пакета была не более 1.5 символа(иначе приёмник может ложно детектировать конец пакета).
В окончания R232 и R485 добиться выполнения этого условия можно с помощью настройки "Таймаут передачи", подобрав значение так, чтобы в буфере накапливался целый пакет Modbus и передавался на дальнюю сторону целиком. Однако, на практике, пакеты Modbus могут быть разной длины и есть вероятность, что будет сложно или невозможно подобрать значение таймаута передачи, для корректной передачи всех пакетов, без изменения параметров опроса.

Предлагаю добавить дополнительную настройку "Таймаут между символами"(мс.) - данные копятся в буфере до тех пор пока пауза после принятия последнего символа не превысит значение настройки, после этого накопленное в буфере отправляется одним пакетом.

[alx]

Replying to san:

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

Во-первых, нет, этим параметром добиться выполнения условия нельзя. Этот параметр отвечает за передачу данных в сеть IP. К передаче данных в интерфейс RS-232/RS-485 этот параметр не имеет отношения.

Во-вторых, ничего страшного от того, что сообщение разорвется на две части, не произойдет. "Разорванное" сообщение будет просто потеряно, так как его части будут проигнорированы получателем. Приложение (мастер-устройство), пославшее запрос, должно быть готово к возможным потерям сообщений при передаче (например повторять передачу запроса при не получении ответа на него в течение заданного времени - именно так делает, например, smartHDCd в нашем контроллере УГП).

Предлагаю добавить дополнительную настройку "Таймаут между символами"(мс.) - данные копятся в буфере до тех пор пока пауза после принятия последнего символа не превысит значение настройки, после этого накопленное в буфере отправляется одним пакетом.

Если ты по-прежнему говоришь о данных, принимаемых из RS-232/RS-485, то, как я сказал выше, это не решит заявленную проблему.

Проблема имеет место на другой стороне соединения - там, где данные принимаются из сети IP и передаются в линию RS-232/RS-485. Сторона, передающая данные в сеть IP, контролировать задержки на другой стороне соединения не может. Упомянутые канальные окончания изначально разрабатывались как protocol-agnostic (не зависящие от вышележащего протокола). В качестве транспорта они используют TCP, который гарантирует только передачу собственно байтов данных в заданной последовательности, но не гарантирует сохранения временнЫх параметров (то есть промежутков между байтами данных). В (почти) любом месте последовательности в процессе передачи может возникнуть пауза, равно как в любом месте пауза может пропасть (если она была). У протокола TCP нет средств обеспечения атомарности передачи блоков байтов (не гарантируется, что если, например, сделать write(socket, buffer, 200), эти 200 байтов будут переданы одним сегментом в одном пакете).

Если бы ставилась задача передавать конкретно сообщения modbus RTU, то тогда вся логика работы канального окончания должна была бы быть другой: оно должно сначала полностью получать сообщение в свой буфер из RS-232/RS-485, детектировать таймаут, после чего преобразовывать сообщение в формат modbus-TCP (в котором передается размер сообщения в заголовке), и передавать его в сеть. На другом конце соединения принимать из сети сообщение полностью, и после этого передавать его в шину и выдерживать паузу в конце. И, как ты понимаешь, это был бы отдельный тип канального окончания...

Но, как я написал выше, я думаю, это все не нужно, так как единичные потери сообщений при передаче не должны приводить к нарушениям работы устройств.

[san]

Но, как я написал выше, я думаю, это все не нужно, так как единичные потери сообщений при передаче не должны приводить к нарушениям работы устройств.

Короткий эксперимент Влада(Master->R232-VE-02-R485->Slave) показал, что вместо 10 переданных Modbus RTU пакетов, устройство Slave получило 22 некорректных пакета, не думаю что это можно назвать единичными потерями.

Во-первых, нет, этим параметром добиться выполнения условия нельзя

Гарантировать нельзя, но в том-же эксперименте Влада при использовании "Таймаута передачи" устройство получило 10 пакетов из 10.

[alx]

Replying to san:

Короткий эксперимент Влада(Master->R232-VE-02-R485->Slave) показал, что вместо 10 переданных Modbus RTU пакетов, устройство Slave получило 22 некорректных пакета, не думаю что это можно назвать единичными потерями.

"Единичная" в том смысле, что потерялось одно переданное сообщение. А на сколько оно при этом частей распалось, не имеет значения...

[alx]

Replying to san:

Короткий эксперимент Влада(Master->R232-VE-02-R485->Slave) показал, что вместо 10 переданных Modbus RTU пакетов, устройство Slave получило 22 некорректных пакета, не думаю что это можно назвать единичными потерями.

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

[san]

Уточни пожалуйста, а сколько он получил корректных сообщений. Если ни одного (то есть на части распалось каждое переданное сообщение) - это, наверное, говорит о проблемах в сети IP (сеть перегружена). Ибо без причины пауза между данными на выходе тракта (которой не было на входе) не возникла бы...

Ни одного корректного. Да вроде бы с сетью было всё ок, учитывая что весь эксперимент внутри одной платы VE-02.
Вот пара осциллограмм из эксперимента:


Фиолетовый - данные которые приходят в R232
Синий - данные которые выходят из R485

Видно, что есть разрывы пакета и пауза >15 мс, что для скорости 9600 бит/с на порядок больше чем 1.5 символа.

И вообще ИМХО некорректно ссылаться на некий эксперимент, о котором собеседнику (мне) ничего не известно... :)

Теперь я рассказал всё что мне известно об этом эксперименте, теперь всё честно)

И без экспериментов можно представить, что в IP сети пользователя может быть джиттер величиной более 1.5 символа, и тогда нормально Modbus работать не будет. Это я всё спорю с твоим заключением, что ничего страшного не произойдёт.
Про правильное решение для передачи Modbus я согласен

[alx]

Replying to san:

Ни одного корректного. Да вроде бы с сетью было всё ок, учитывая что весь эксперимент внутри одной платы VE-02.
Вот пара осциллограмм из эксперимента:

По этим осциллограммам видно, что выход данных длится существенно дольше, чем приход этих данных на вход. Это наводит на мысль о том, что пропускной способности сети недостаточно для передачи данных с полной скоростью. Но если ты говоришь, что вся передача происходит локально, то это странно и непонятно...

Нет ли у Влада вывода tcpdump'а этих экспериментов? Любопытно посмотреть, что происходило в сети...

И без экспериментов можно представить, что в IP сети пользователя может быть джиттер величиной более 1.5 символа, и тогда нормально Modbus работать не будет. Это я всё спорю с твоим заключением, что ничего страшного не произойдёт.

Я исходил из предположения, что транспортная сеть имеет приемлемое качество. Я никак не предполагал, что сеть настолько плоха, что каждое переданное сообщение теряется...

Про правильное решение для передачи Modbus я согласен

На практике есть более простое решение - перейти на вариант modbus-ASCII. Он никак от пауз не зависит...

[alx]

Replying to san:

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

А, кстати, почему сложно? Максимальный размер сообщения - 256 байт. Кажется логичным установить таймаут на время передачи 256 байт данных (возможно, с маленьким запасом) - и любое сообщение будет отправляться одним пакетом (при идеальной работе сети)... Нет? В чем подвох?

[san]

В чем подвох?

Я думал, что подвох в том что после короткого сообщения в буфер может попасть следующее... но это-же не возможно, потому что протокол работает по алгоритму запрос-ответ.
Да, ты прав, настроить таймаут можно.

На практике есть более простое решение - перейти на вариант modbus-ASCII. Он никак от пауз не зависит...

Часто бывает, что аппаратура заказчика поддерживает только RTU.