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

[Alex_2015]

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

[juvf]

срезюмирую....

Как человек почти вся жизнь занимающийся всевозможными связными потоколами могу точно сказать, что Modbus RTU есть натуральное дерьмо.

после этого вообще можно было с этим человеком о Modbus-е ни о чем не говорить. Ну и далее гвоздь в дискуссию

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

no comments

juvf , Вы хотели что-то спросить, или просто еще раз подтвердить самому себе верность своего курса?

Во всех рекомендациях, которые я встречал говориться о защитном смещении. Нигде я не встречал про активную продувку. Нет, конечно я про такое слышал.... но не в рамках 485-го и модбаса, а вообще, в теории помехозащищенности линии. Но чтоб в модбасе что-то активно дули!? Может я не правильно готовлю модбас? решил это выяснить. А тут в ответ только вера в что-то святое и хамство. Конкретно, многоуважаемый zltigo заявляет, что под голый ПК, ака DOS - без проблем делает активную паузу. Например это хотел спросить. В ответ получил какую-то задачку…. И ответ “реши и поймёшь как”. Решил. И что? С неба спустилась миссия и открыла мне путь истинный как на десктопном ПК под DOS делать активную паузу?

Цену такого "решения", если не понимаете, поймете решив задачку в конце поста.

И решил…. Каково цена? Только тролить и языком молоть умеет.


Очень умиляют высказывания единомышленников

Пример хорошего протокола для RS485- тот же Модбас

vs

Modbus RTU есть натуральное дерьмо.

)))


Далее…

Ваш путь ошибочен. Лично Вам он годится, только и всего.

Возможно…. Только вот те системы с которыми мы стыкуемся… работают… но это всё равно МОЙ путь…. я понял, тут только болтуны толком ни чего не подскажут…. Только нахамят и потролят, как обычно. Ищем литературу, справочники, статьи на эту тему… кто как делает? кто каким путём ходит? Может кто короткую тропинку мне покажет?
Что находим .... пруф раз, пруф два, три, четыре…, а также five, six, семь, восемь .... Много их… и ненавистные вики, и в даташитах на драйвера и от производителей. вот конкретно

При прекращении передачи данных в сети, состоящих из множества передатчиков, подключенных к одному каналу связи, линейные драйверы переходят в «третье состояние» (т.е. отключенное состояние). В результате линейные приемники, прослушивая сеть, могут регистрировать ложные данные.
Для разрешения указанной проблемы разработчиком в приемопередающих узлах RS-485, должны быть предприняты специальные меры. Приемопередатчики узлов RS-485 должны быть оснащены цепями смещения выхода формирователя. По такому принципу построены приемопередатчики RS-485 всех приборов предприятия МИКРОЛ.

пруф Значит мой путь не ошибочный и он подходит не только мне!
Вот ещё интересный девайс… ICP DAS очевидно тоже ставит и/или предлагает ставить растяжки, по необходимости.
Но наш мистер джедай умеет направлять Силу, что даёт ему некоторые сверхъестественные способности zltigo предлагает всех, кто делает помехозащищенное смещение, кастрировать. Он от всех отличается. Может ему когда-то оторвали гениталии и он не хочет от других отличаться?


Теперь по делу…. Что могу ещё добавить…. Поделившись опытом… а не ради того, чтоб кого-то унизить или холиварить….
2demiurg_spb, я видел подобные парссеры. ..... выскажу мнение: мне не нравиться подобные парссеры. Почему.
1)Есть пакет. целостность пакета обеспечивается контрольной суммой и паузами тишины. я сначала выделяю весь пакет из потока, проверяю его целостность и только потом начинаю обрабатывать данные этого пакета. Ну я как-то изначально…. В любом протоколе сначала проверяю целостность пакета, а потом обрабатываю внутренность пакета. Вы адрес и функцию обрабатываете не проверив целостность пакета. может в поле адрес ошибка, или в поле функция.... конечно в конечном счете црц покажет, что пакет был битый....
но.... вот у вас отправили пакет 2-му устройству, один бит ложный. Слейвы получили адрес 6
и тогда 2-ой девайс НЕ отметит битый пакет, а 6-ой девайс отметит, что пакет был ему адресован, но црц плохой и 6-ой сделает mb->stat.comm_errors++;. хотя на самом деле пакет был адресован 2-му. Если црц не совпал, то ни кто не знает, кому на самом деле пакет был адресован.
2) Вы не сможете оценить зашумлённость линии. Ну если конечно это вам надо. Я всегда это делаю. Даже один ложный байт в тишине увеличит счетчик ошибок во всех слевах.

Это абсолютно правильно, ибо если адрес не ваш, то уже пофиг и пакет и его целостность - пакет уже игнорируется и становимся в ожидание следующего фрейма без лишних разбирательств.

Возможно это нашему маниакальному хирургу кому-то подходит, но это не вписывается в стандарт MODBUS. Ибо в стандарте есть функция 8 -Diagnostics (Serial Line only) . подфункция 12
The response data field returns the quantity of CRC errors encountered by the remote device since its last restart, clear counters operation, or power–up. Т.е. не нужно игнорировать чужой пакет с битым црц.

Что касается растяжек…. Все эти расчеты …. Сложные… они должны учитывать кол-во слейвов, длину кабеля, активное сопротивление/емкость/индуктивность…. Драйвера слейвов (у одних сопротивление 12 кОм, у других 24 кОм…) одни растяжки ставят в начале линии, другие на каждом слейве (например, если растяжки есть внутри драйвера)… терминатор может быть, может не быть, их может быть два….
Согласно апликэшен ноут от аналог девайс на 100 омную линию с 2 терминаторами нужно 775 Ом. Это конечно круто. По другим рекомендованным расчетам получалось около 560 Ом…. На практике мы ставим от 2.4 кОм…. Меньше не ставили. И реально эти растяжки на линии подбирали опытным путём. Также предлагают подберать опытным путём растяжки и терминаторы ICP DAS, причем растяжки только 1 кОм, 10кОм и даже 100кОм

2demiurg_spb я уже говорил, что имею опыт на линиях до 500 м. У вас линии длиннее? Интересно посмотреть на байт 0x55 в линии с растяжками и без. Какие фронты? Как это повлияет на скорость? zltigo не уподобился ответить на вопрос о длине линии…. Но потом проговорился, что ему интересны километры. Однако RS-485 вроде как до 1200 метров. Выше – это уже какой-то овердрайв и использовать там общепринятые решения наверно не целесообразно.

есть такое... но в модбас такое не прокатит... если только в 4 раза скорость понизить, вдунуть 0хфф, потом поднять скорость и слать пакет.

извиняюсь перед ТС за офтоп.

[demiurg_spb]

2demiurg_spb, я видел подобные парссеры. ..... выскажу мнение: мне не нравиться подобные парссеры. Почему.

Ваше объяснение логично, понятно и более того соответствует описанию счётчиков в документе modbus_over_serial_line.
Но лично мне совершенно не хочется напрягать контроллер расчётами CRC всего сетевого трафика...

Что касается длинны линии, то сталкивался с разными задачами вплоть до километра.
Сейчас под рукой таких линий нет - картинку снять не могу.

А линию продуваю действительно так, как вы предположили. Поясню на примере STM32.
Отключаю функцию UART на ноге ТХ (перевожу в GPIO) и отправляю один байт на заранее рассчитанной скорости чтобы получилась пауза 3,5T (при этом нога TX вообще не дёргается).
Потом в прерывании TXC перевожу ногу обратно в режим UART-TX, меняю на правильный бодрейт и отправляю пакет, потом снова продуваю прежним способом.
Т.е. у меня в драйвере UART есть возможность включить пакетный режим с суффиксом и префиксом активного состояния.
Прерывания от таймера вообще не использую.

[_Pasha]

Прерывания от таймера вообще не использую.

Кста, хороший метод. Вещь в себе. Спасибо за мысль. Раньше делал по таймеру

[zltigo]

Кста, хороший метод.

1) Абсолютно бесполезный, ибо на приеме таймауты 1,5 и 3,5 по любому придется иметь, так зачем еще плодить лишние сущности.
2) На многих чипах нереализуемый, ибо прерывания окончания передачи просто нет, а есть только освобождение буферного регистра.
3) Ошибочный, поскольку в начале модбасовского фрейма 3,5 пауза избыточна и только снижает темп обмена.

возникает вопрос смысл продувки?
если помехи не было - то и продувать то особенно нечего - бит синхронизация и так есть
если же была помеха то продувай не продувай будет принят битый пакет
в чем смысл?

В том, что Ваше утверждение "будет принят битый пакет" ошибочное. Это из мусора будет сформирован битый пакет, а передаваемый пакет пойдет очищенным от мусора.

[_Pasha]

1) Абсолютно бесполезный, ибо на приеме таймауты 1,5 и 3,5 по любому придется иметь, так зачем еще плодить лишние сущности.
2) На многих чипах нереализуемый, ибо прерывания окончания передачи просто нет, а есть только освобождение буферного регистра.
3) Ошибочный, поскольку в начале модбасовского фрейма 3,5 пауза избыточна и только снижает темп обмена.

1. Нет. Речь шла о продувке физ. канала. Совершенно закономерно, что мысль дошла до того, чтобы сделать продувку равную Т35 или Т15, но делать ее по максимуму, ессно, необязательно.
2. Нет! "на многих чипах" -это х51?
3. Да )) но не совсем. при Т15 остальной парк девайсов примет все что идет вплоть до Т35. Т.е. после продувки Т15 можно запросто потерять пакет. А после Т35 - нет.
Так что все правильно оказывается.

Сообщение отредактировал _Pasha - Sep 28 2016, 06:58

[zltigo]

1. Нет. Речь шла о продувке физ. канала. Совершенно закономерно, что мысль дошла до того, чтобы сделать продувку равную Т35 или Т15, но делать ее по максимуму, ессно, необязательно.

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

2. Нет! "на многих чипах" -это х51?

Абсолютно на всех, котрые ведут совместимость от 8250 чипа. Среди микроконтроллеров это, например все NXP включая ARМ. Ну и само собой все IBM-PC.

3. Да )) но не совсем. при Т15 остальной парк девайсов примет все что идет вплоть до Т35. Т.е. после продувки Т15 можно запросто потерять пакет. А после Т35 - нет.

Понятие правильности оно абсолютное и не надо называть "правильными" нарушения пртокола под устройства сделанные кем то с нарушением.
Иметь настройки под уродов, это да, жизненная необходимость, но это не делает нарушения легальными.

2) легко реализуемо путем пердачи лишнего байта - и как только лишний байт уйдет из регистра значит передача нужного байта выполнена

Не реализуемо. Прерывание отработает с задержкой, да и само прерывение будет выдано с задержкой на один бит в большинстве случаев. Так что получите, как минимум, лишний стартовый бит до того, как отключите передатчик.

[AHTOXA]

Не реализуемо. Прерывание отработает с задержкой, да и само прерывение будет выдано с задержкой на один бит в большинстве случаев. Так что получите, как минимум, лишний стартовый бит до того, как отключите передатчик.

Стартового бита не будет, потому что ножка передатчика отключена. Так что нормуль.

[zltigo]

Стартового бита не будет, потому что ножка передатчика отключена. Так что нормуль.

Если НЕ понимаете о чем речь, не плодите "мусор на шинефоруме". Передатчик НЕ отключен, поскольку передатеся валидный "предпоследний" байт.

реализуемо
и кого волнует мусор на шине?

Меня волнует мусор, которого могло-бы и не быть. Не люблю грязную работу и сам НЕ делаю свою работу грязно.

[net]

Меня волнует мусор, которого могло-бы и не быть. Не люблю грязную работу и сам НЕ делаю свою работу грязно.

ну тогда считаем что этого мусора нет - посколькку после него будет пауза и этот сигнал никому не помешают,
и он строго детерменирован и не представляет никакой опасности и совершенно чист перед протоколом

и в от личии от вашего невозможно - это все решает без проблем