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

[zltigo]

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

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

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

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

[Lagman]

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

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

[demiurg_spb]

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

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

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

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

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

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

[megajohn]

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

RS422

[demiurg_spb]

Нет. Интересует именно RS485!
Наверное мне стоило создать отдельную тему. Прошу извинения у ТС, если это ему помешало.

[juvf]

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

Не нужно ни чего продувать. когда нет драйвера на линии там лог "1". Линяя RS485 должна быть подтянута (А к +V, B k GND). посмотрите осциллографом перевод из приема в передачу и через какое время начинает бит старт бит вылазить. Работает на скоростях от 9600 до 921600. По окончании ни чего мастеру дуть не надо... после передачи последнего байта я снимаю передачу и перехожу на прием. линия остается без драйвера. Подтягивающие резисторы обеспечат слейву лог "1" - это и будет тишина.
Если кто боиться, что в лини без драйвера есть шум... или может возникнуть шум.... нет там шумов. Подтяжка делает сво дело. На длинной линии можно словить наводку, электромагнитную помеху.... НО.... в рс485 длинная линия тянеться витой парой.... наведенный импульс в А+ таже будет и в B-, в итоге разность A и B сохраниться как без помехи.

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

[demiurg_spb]

Мне бы Вашу непоколебимую уверенность!
Попробуйте поработать с силовой преобразовательной техникой...

[juvf]

ps

помехи могут дать ложный старт-бит.

не всё так печально. в 485 этого вообще не будет. но такое может возникнуть в рс232.... и тем не менее.... процессор получает уже UART.... так вот... как работает UART (по крайней мере в С51 ядре, да и в остальных примерно также)... переход из лог 1 в лог 0 - это ещё не старт бит. любая помеха в UART-е не является стартбитом. Чтоб уарт начал принимать байт, нужно нулевой уровень в линии на протяжении длительности 1-го бита. в 51-ом проце после перехода 1-0 запускается таймер... чререз 1/4 длительности импульса проверяется уровень на линии.... потом ещё через 1/4, и потом ещё раз через 1/4.... если все 3 раза на входе был лог 0 - то это считается стартбит. так что какаянить иголка в линии не запустит уарт на прием.

[demiurg_spb]

Про то, что бит поллится не за один раз - я естественно в теме. Но при высоких скоростях количество поллингов за бит как правило снижается вплоть до 4. Кто сказал, что помеха не в состоянии 4 раза за бит случиться? Я на это никак не могу не рассчитывать...

[juvf]

Мне бы Вашу непоколебимую уверенность!
Попробуйте поработать с силовой преобразовательной техникой...

Работал..... обвязывали 485-ым трансформаторные подстанции, распределительные подстанции, дизельные генераторы... а также на объектах с высоким ВЧ излучением.

ps была проблема однажды.... сильное ВЧ излучение.... и оно лезло везде.... решили проблему полной опторазвязкой RS485 мастера и слейва. Но ни каких продувок не делали.

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

в воздухе нельзя её вешать.... а резисторы... растяните не слабенькими... 5 кОм... или 2.4 кОм.

Кто сказал, что помеха не в состоянии 4 раза за бит случиться? Я на это никак не могу не рассчитывать...

А реально были такие случаи? если предположить, что брошенная линия постоянно "шумит".... то получается все слейвы на линии постоянно получают мусор по уарту... т.е. постоянно срабатывает прерывание поприему, обработчик байт кудато помещает, запускает таймер на 3.5 символа (а некоторые ещё и црц налету считают).... это же сколько работы процессору - постоянно шум анализировать... а если уартов 4? Не должно быть шумов и всякого мусора в 485. если есть - нужно над линией работать.

[demiurg_spb]

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

Полная опторазвязка - это оптоволокно?

Я никогда не делаю не изолированные RS485 выходы у приборов.
Спасибо!
Ваше мнение я услышал.

[juvf]

Полная опторазвязка - это оптоволокно?

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

[zltigo]

Я обычно формирую требуемую паузу на шине с включенным передатчиком до и после передачи пакта.

Увы, для 485 пауза есть неизбежное зло.
Величина паузы зависит от способа выделения фрейма и при MODBUS самый плохой вариант c точки зрения величины пауз -
1,5 байта в начале и 3,5 байта в конце.
При байтстафинговом фреймере - 1 байт в начале, а в конце не нужно.

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

Ваши сомения несостоятельны.

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

Из дерьма конфетку не сделаешь, а как максимально соблюсти - написано выше.

[demiurg_spb]

Понятно, что изолированный - это гальванически не связанный и никаких общих земель.
Кстати, про загрузку процессора - если фильтровать по адресу слейва и коду функции то CRC считать для мусора и "не твоих запросов" фактически и не придётся.

[zltigo]

Не нужно ни чего продувать. когда нет драйвера на линии там лог "1". Линяя RS485 должна быть подтянута (А к +V, B k GND).

За такую "подтяжку" криворуким дизайнерам надо отрывать гениталии. Она КАТОСТРОФИЧЕСКИ гробит дальность передачи.
Есть более-менее приемлимые решения в виде использования Failsafe приемником со смещенным уровнем. Но на них тоже полагаться нельзя, поскольку запас для помехи по минммуму. Их использование есть хороший способ уменьшить помехи, но не исключить.

Если кто боиться, что в лини без драйвера есть шум... или может возникнуть шум.... нет там шумов. Подтяжка делает сво дело. На длинной линии можно словить наводку, электромагнитную помеху.... НО.... в рс485 длинная линия тянеться витой парой.... наведенный импульс в А+ таже будет и в B-, в итоге разность A и B сохраниться как без помехи.

Помеха в длинной линии есть уже и без всяких наведенных - просто колебательный процесс при включении и выключении передатчика.
Вот такой сюрприз для любителей растяжек НИКОГДА не работавших с длинными реальными линиями. Это раз. А два, это то, что подавление синфазных далеко не 100% и нормируется только в достаточно узком диапазоне синфазных, а синфазные помехи в десятки и сотни вольт, это тоже реальность длинных линий.
Никакие опторазвязки от помех на 100% не спасают, ибо любая развязка имеет паразитную емкость, через которую прекрасно пролезают импульсы с высокой энергией. Гальваническая развязка это прежде всего защита от выхода из стоя, защита от помех с пологими фронтами, но не защита от любых помех вообще.