сниффер ком порта Опции

[Alex_2015]

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

[juvf]

2ТС Тут только аппаратный снифер поможет. Можно сделать MODBUS-RS485 to MODBUS-TCP. А вот тсп-модбас уже акулой смотреть, она знает модбас и может его парсить.

2jcxz Утопия. Ни фига не сможет вин/лин по таймаутам работать. Если только на скорости 100 бод. У нас MODBUS на 921600 работает, ОСи скромно отдыхают в сторонке.

Бред какой-то вы пишите.... Теоретически лошадь, практически упала. Я эти теоретические сказки про возможность реализации чистого модбаса на ПК слышу много лет. Все они разбиваются о попытки практической реализации модбаса на ПК. Попробуйте написать консольную программку, без гуи... которая просто бы принимала и считала кол-во пакетов с правильным црц? и в студию.

ps Ну если говорить про совсем чистый модбас, то по спецификации пакет, у которого внутри между байтами больше 1,5 символьного интервала считается не годным.

pps

Я не вижу никаких причин в современной системе, не загруженной тяжёлой работой, имеющей как правило несколько процессорных ядер с ГГц-выми тактовыми частотами, которые почти всё время просто тупо простаивают, не отреагировать на событие почти мгновенно, обработав например прерывание одним ядром и тут же переключить другое ядро на выполнение высокоприоритетного thread-а драйвера сис. уровня UART, а третьим ядром выполнить пользовательский высокоприоритетный код с ReadFile.

ВНЕЗАПНО в Qt 5.6 появился класс для работы с модбасом. Покопался в дебрях документации и нашел, что этот класс не может распознавать фреймы в 3.5 символа. В документации Qt5.7 не могу это ограничение найти. В libmodbus тоже не сказано, что у них не чистый модбас.... Гдето же были оговорки по таймаутам.... не могу найти..... может и вправду эти сказки реализовали и финты с RDA и CTI запилили? Кто пользовал эти либы? Сможет QtModbus или libmodbus распознать(разделить) 2 пакета RTU, идущих подряд и разделённых 3.5 символами тишины, на скорости 921600, на каком нить стареньком одноядерном компе, на котором еле-еле гуи ворочится и процессор занят кучей увесистых задач?

[Lagman]

Сможет QtModbus или libmodbus распознать(разделить) 2 пакета RTU, идущих подряд и разделённых 3.5 символами тишины, на скорости 921600, на каком нить стареньком одноядерном компе, на котором еле-еле гуи ворочится и процессор занят кучей увесистых задач?

В рекомендациях modbus сказано (MODBUS over Serial Line Specification and Implementation Guide V1.02, стр. 13)

The implementation of RTU reception driver may imply the management of a lot of interruptions due to the t1.5 and t3.5 timers. With
high communication baud rates, this leads to a heavy CPU load. Consequently these two timers must be strictly respected when the
baud rate is equal or lower than 19200 Bps. For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is
recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).

Но наверно даже с этими значениями без ОСРВ не поймать эти моменты, и если T1.5 почти никто не проверяет, то с T3.5 главное не начинать передачу пакета (запрос или ответ) раньше этого момента и можно "терпеть" с передачей вплоть до истечения времени ожидания ответа.

[zltigo]

и если T1.5 почти никто не проверяет

Что очень зря, ибо это есть механизм отсева сбоев и быстрого восстановления фреймовой синхронизации.

то с T3.5 главное не начинать передачу пакета (запрос или ответ) раньше этого момента и можно "терпеть" с передачей вплоть до истечения времени ожидания ответа.

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

[Lagman]

В частном случае, когда конкретные реализаторы протокола "плют", "терпят" и медленно обмениваются пакетами в которых паузы между фреймами определяются не протоколом а неспешым темпом обмена и меееедлееенннооо реагирующими на запросы слейвами, софтовый снифер под WIN как-бы ваделяет фреймы без проблем. Но при полноскоростном обмене шансов под WIN никаких .

Пропускная способность, это да, пострадает, но стандарты протокола никто не нарушает.

[demiurg_spb]

Добрый день коллеги!
Захотелось обсудить вопрос "продувки шины" перед выдачей пакта в линию сразу после включения драйвера RS485 на передачу.

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

У меня есть сомнения, что если этого не делать можно наступить на грабли. Поясню.

1) Мастер хочет передать и не знает был ли шум в линии - следовательно надо "продуть" до, ну а после само-собой разумеется продувать необходимо чтобы слейв словил тишину.

2) Слейв хочет ответить на принятый запрос и тоже не знает про то, был-ли шум на линии с момента приёма пакета до переключения драйвера на передачу. Ведь по окончании паузы сформированной мастером, проходит некоторое время на обработку пакета и в это время линия висит либо в воздухе, либо растянута слабенькими резисторами и помехи могут дать ложный старт-бит. Пока писал это осознал, что если помеха в этот момент случилась, то продувка линии может уже и не спасти ситуацию, т.к. мастер может принять мусор, после которого правильный ответ слейва уже может быть и не валиден. Отсюда напрашивается вывод, что слейв должен мгновенно отвечать мастеру после приёма валидного запроса, либо сразу включать свой передатчик и заниматься подготовкой ответа.
Это несколько затруднительно, т.к. в моей текущей реализации это не реализовано (считать CRC на лету, сранивать первый байт запроса со своим адресом и даже может быть готовить ответ во время паузы, формируемой мастером). Кто-нибудь так уже сделал?

Давайте порассуждаем над этим увлекательным занятием - реализацией идеального MODBUS-RTU MASTER/SLAVE!