[GetSmart 0]

Проснитесь! На дворе лето к концу идет.

Разве? У нас ещё середины не наступало. Вы с какой планеты?

Я не про Вас, кстати. У Вас всё стабильно постоянно, без обострений :)

 

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

Хорошая заява. То есть физический уровень - одинаковый, RS485. Более верхний - Modbus (RTU), который не умеет вообще исправлять ошибки, возникающие на уровне RS485. И при этом гений от электроники говорит о в сотнях раз большей помехоустойчивости, которая в его интерпретации означает продолжение нормального обмена данными между устройствами при в сотню(и) раз больших уровнях помех. Гений не знает, что если в пакете Modbus возникнет хоть одна битовая ошибка, то весь пакет улетит в мусорку

 

Обострение серьёзней, чем предполагалось.

Изменено 10 июля, 2011 пользователем GetSmart

[zltigo 1]

Разве? У нас ещё середины не наступало. Вы с какой планеты?

Планета земля. Северное полушарие. Середина лета была 22 июня. Дело к осени, длительность дня сокращается.

 

[GetSmart 0]

Середина лета была 22 июня. Дело к осени, длительность дня сокращается.

Вы ведь знаете правильный ответ, но пытаетесь обмануть. 22 июня была максимальная длительность дня. Не лета, и не среднемесячной/недельной/... температуры. Времена года, в том числе и лето, сдвинуты относительно максимума дня ПО ТЕХНИЧЕСКИМ ПРИЧИНАМ :) Официально лето с 1 июня до 31 августа. Читайте первоисточники. Вы же любите/уважаете стандарт :)

Изменено 10 июля, 2011 пользователем GetSmart

[=AK= 12]

Ну-ну. Имеем два фрейма. Один Modbus RTU, второй некий Pbus. Возможно они несколько отличаются размером, но надеюсь не в 200 раз? Оба фрейма передаются через 485 интерфейс. Имеем некую помеху, некой мощности, которая неведая (надеюсь не будете возражать, что не ведая? ) искажает один бит фрейма Modbus RTU и один бит Pbus.

Имеем некую помеху, мощность которой мы постепенно увеличиваем.

 

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

 

Modbus RTU относится к наличию этой помехи индиферентно. Согласно протоколу, передающий узел обязан включить свой передатчик заранее и удерживать RS-485 в пассивном состоянии, ничего не передавая, в течении 3.5 (если память не изменяет) байт-интервалов (это называется "преамбула"). А приемники обязаны игнорировать текущий фрейм и очистить свои буфера обмена в случае, если промежуток между соседними байтами во фрейме превышает 1.5 (опять же, по памяти) байт-интервалов. Таким образом, наведенная в промежутке между фреймами помеха вполне может вызвать начало ложного приема для всех приемников, они могут начать принимать помеху как новый фрейм. Однако в течении преамбулы все приемники Modbus RTU неизбежно обнаружат, что пауза превысила допустимую длину, очистят свои буфера и будут готовы к приему настоящего фрейма.

 

В случае Pbus, а также огромного количества самопальных протоколов, помеха, пересилившая резисторы растяжки, вызывает начало приема ложного фрейма, который протокол долгое время не в состоянии отличить от истинного фрейма. Истинный фрейм будет "приклеен" к хвосту ложного фрейма, начатого помехой. В лучшем случае ошибка приема будет обнаружена по несовпадению CRC. Однако к этому времени "поезд ушел", фрейм оказался испорчен и не может быть восстановлен. Даже если источник заново передаст фрейм (скажем, из-за отсутствия Ack-а от приемника), гарантий доставки у него никаких нет - помеха достаточного уровня может испортить и этот фрейм, и следующие.

 

Чтобы испортить фрейм Modbus RTU, помеха должна пересилить не резисторы подтяжки, а выход работающего передатчика RS-485. Для этого она должна иметь мощность в 100-200 раз больше, чем для того, чтобы пересилить резисторы растяжки.

 

будьте любезны, приведите их описание. Тогда и будет видно, невежда ли вы, или же инженер, знающий толк в интерфейсах.

так понтами повеяло, что не сдержался

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

 

А уж сколько было от вас понтов и гонора в отношении Modbus RTU... ;) Жесткие интервалы, которые вас, как программиста, так раздражают, как раз и обеспечивают его помехоустойчивость. Теперь будете знать.

[GetSmart 0]

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

 

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

Изменено 10 июля, 2011 пользователем GetSmart

[zltigo 1]

Modbus RTU относится к наличию этой помехи индиферентно. Согласно протоколу, передающий узел обязан включить свой передатчик заранее и удерживать RS-485 в пассивном состоянии, ничего не передавая

Этот волшебный "200 кратного :) уменьшения влияния помех" механизм де факто реализуется во всех примитивных протоколах типа Master/Slave запрос/ответ, ибо по другому еще надо постараться сделать. Master вообще может держать свой передатчик сколь угодно долго. Даже страшно подумать во во сколько возрастет "помехащищенность" :). При этом вот это Ваше утверждение:

Согласно протоколу, передающий узел обязан включить свой передатчик заранее и...

не есть требование протокола. Требование протокола распространяется только на наличие silent interval. Что там должно быть с физикой и как это обеспечивавается это дело десятое. Вы его можете включать заранее, Вы его можете вообще не выключать, и АБСОЛЮТНО также могут поступать реализаторы в любого подобного протокола в том числе и Pbus.

Самое жуткое для борца с помехами состоит в том, что в нормальных протоколах (а это не Modbus RTU :) ) началом/концом фрейма является не одиночный (один, совсем один) стартовый бит а определенная последовательность битов. Причем к нормальным протоколам относится и тот самый Modbus ASCII (последовательность из 10 bit), который как Вы экспертно оценили, цитирую "Он непригоден для RS-485, поскольку в этом случае обеспечивает крайне низкую помехоустойчивость". Фраза "Modbus ASCII предназначен для интерфейсов "точка-точка" (RS-232, RS-422, и т.п), о чем прямо написано в стандарте" тоже хороша, если, конечно, не знать что а в спецификации (а не стандарте, которого нет) Modbus over Serial такой глупости, естественно не написано. К этому можно добавить, что за счет избыточности в том-же Modbus ASCII можно пробовать восстанавливать битую информацию. Вот такой вот странный протокол с "крайне низкой помехоустойчивостью". Нет, наверное все-таки не протокол странный, а "эксперт" очень странный :(.

Мне искренне жаль тех заказчиков, для которых вы "протоколов всех уровней реализовывали своими руками". :(

Главное, что им не жаль :).

 

Официально лето с 1 июня до 31 августа. Читайте первоисточники. Вы же любите/уважаете стандарт :)

Не знаю, что Вы называете первоисточником, я ориентируюсь по РЕАЛЬНОМУ первоисточнику - Солнцу. Возражения по поводу его прав считаться первоисточником есть?

Ну а чего-уж там кто что думает... Я вот знаю дюжину человек, так они вообще, чудаки, все, как один думают, что у них сейчас совсем даже не лето - +10, дождь. Зима говорят у нас в Сиднее.

[GetSmart 0]

Не знаю, что Вы называете первоисточником, я ориентируюсь по РЕАЛЬНОМУ первоисточнику - Солнцу.

Первоисточник - календарь. Документ, между прочим.

А когда по Солнцу Новый год? Тоже отмечаете по Солнцу

[=AK= 12]

Вообще-то любой не совсем уже бездарный протокол обмена, приняв байт и видя, что за ним не идут далее байты (в течении сколько-то символов) должен или обработать принятый "пакет" или его отбросить и подготовиться к приёму нового пакета.

Нет, не любой. Это я вам просто про другие варианты не рассказал, а самому дотумкать у вас, очевидно, не получается. Существуют помехоустойчивые протоколы, которым не требуется контролировать тайм-ауты. :)

 

 

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

Это вы глупость сказали, по невежеству своему. Более помехоустойчивый, чем Modbus RTU, протокол поверх RS-485 сделать нельзя (определение помехоустойчивости я давал ранее). Modbus RTU обеспечивает максимально возможную для RS-485 помехоустойчивость. Другие протоколы могут с ним сравняться, но не могут превзойти.

 

Если же вы считаете иначе - будьте любезны, приведите пример "в разы более помехоустойчивого" с необходимым обоснованием . :)

 

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

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

 

Так что зря тужитесь. ;)

[DogPawlowa 0]

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

Так что я скорее на стороне =AK=, хотя он и допустил пару экстремистских высказываний :)

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

 

Что касается стартовой последовательности бит... Как использовать это с помощью стандартного UARTа во всем диапазоне параметров передачи?

[sonycman 0]

Более помехоустойчивый, чем Modbus RTU, протокол поверх RS-485 сделать нельзя (определение помехоустойчивости я давал ранее). Modbus RTU обеспечивает максимально возможную для RS-485 помехоустойчивость. Другие протоколы могут с ним сравняться, но не могут превзойти.

Хм, тут вроде говорили, что Modbus RTU отбраковывает сразу целый фрейм при ошибке всего лишь в одном бите.

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

[GetSmart 0]

Хм, тут вроде говорили, что Modbus RTU отбраковывает сразу целый фрейм при ошибке всего лишь в одном бите.

Да да да. В представлении =AK= это может происходить только при взрыве атомной бомбы. Ну и соответственно определение помехоустойчивости в военное время будет совсем другим :)

 

[zltigo 1]

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

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

Что касается стартовой последовательности бит... Как использовать это с помощью стандартного UARTа во всем диапазоне параметров передачи?

Не понял. Ecли о 10 битах Modbus ASCII, это start-7bit_data_parity_stop. Естественно, они штатно обрабатываются UART.

 

 

Это вы глупость сказали, по невежеству своему. Более помехоустойчивый, чем Modbus RTU, протокол поверх RS-485 сделать нельзя (определение помехоустойчивости я давал ранее). Modbus RTU обеспечивает максимально возможную для RS-485 помехоустойчивость. Другие протоколы могут с ним сравняться, но не могут превзойти.

В случае Pbus, а также огромного количества самопальных протоколов, помеха, пересилившая резисторы растяжки, вызывает начало приема ложного фрейма, который протокол долгое время не в состоянии отличить от истинного фрейма.

В любом вменяемом базирующимся на ассинхронной передачи байтов протоколе это "долгое время" менее ОДНОГО байта. Один байт, который будучи принятым с ошибкой (paryty или frame) и/или НЕ будет соответствовать комбинации начала фрейма будет отброшен. Опасное, так сказать время (почему всю "помехоустойчивось" Вы сводите только к нему оставим на Вашей совести) за время которого помеха способна вызвать потерю всего фрейма это время менее передачи одного символа. В дебильнейшем даже с этой точки оценки Modbus RTU помеха в 1+1,5 символьном интервале перед началом фрейма вызывает облом со всем фреймом. Вот такой он оказывается "обеспечивающий максимально возможную для RS-485 помехоустойчивость" протокол. Абыдно, да....

Так что зря тужитесь. ;)

Наверное зря - трудно разгововаривать с Вами, который собственно и Modbus толком не знает (приписывание требования включения передатчика на slient inteval, приписывание требования использования Modbus ASCII только для дуплекс и point to point, обвинение ASCII в пресловутой непомехоустойчивости, приписывание почему-то только Modbus исключительной возможности подержать передатчик включенным перед началом фрейма). Так-что расслабьтесь - лично для Вашей персоны никто не тужится. Просто пресекаем дезинформацию.

[=AK= 12]

Этот волшебный "200 кратного :) уменьшения влияния помех" механизм де факто реализуется во всех примитивных протоколах типа Master/Slave запрос/ответ, ибо по другому еще надо постараться сделать. Master вообще может держать свой передатчик сколь угодно долго.

Я уже говорил, что обмен не сводится к поведению одного только мастера. Ну, а самое главное: может держать, а может и не держать, как уж заблагорассудится программисту. Однако среди программистов, как мы выяснили на ваших с подельником :) примерах, полно тех, кто не понимает, что незначительные (с их точки зрения) нюансы реализации могут изменить помехоустойчивость в сотни раз.

 

Однажды я встретил самопальный протокол, в котором недоумок-программист переводил передатчик RS-485 на прием после отсылки каждого байта во фрейме. А изделие стояло на портальном кране и, соответственно, дико глючило.

 

АБСОЛЮТНО также могут поступать реализаторы в любого подобного протокола в том числе и Pbus.

В описании Pbus сказано, что слэйв должен игнорировать принятые символы, если зазор между ними превышает 200 мкс. Но при этом обмен идет на скорости 2400, т.е. битовый интервал равен 416 мкс. Так что этому невменяемому бреду, который вы защищаете, место в топке. :)

 

 

Самое жуткое для борца с помехами состоит в том, что в нормальных протоколах (а это не Modbus RTU :) ) началом/концом фрейма является не одиночный (один, совсем один) стартовый бит а определенная последовательность битов. Причем к нормальным протоколам относится и тот самый Modbus ASCII (последовательность из 10 bit), который как Вы экспертно оценили, цитирую "Он непригоден для RS-485, поскольку в этом случае обеспечивает крайне низкую помехоустойчивость".

Самое жуткое для людей с атрофированными мозгами состоит в том, что помеха в момент, непосредственно предшествующий этой вашей "определенной последовательности битов" будет воспринята как старт-бит, в результате чего принятая последовательность будет искажена. В Modbus ASCII вместо двоеточия ":" из UARTа будет прочитан другой символ. В результате весь фрейм пропадет - связи не будет. ;)

[zltigo 1]

Я уже говорил, что обмен не сводится к поведению одного только мастера. Ну, а самое главное: может держать, а может и не держать, как уж заблагорассудится программисту. Однако среди программистов, как мы выяснили на ваших с подельником :) примерах, полно тех, кто не понимает, что незначительные (с их точки зрения) нюансы реализации могут изменить помехоустойчивость в сотни раз.

Я рад, что Вы тем не менее поняли, что "потрясающая помехоустойчивость" протокола Modbus RTU совершенно не является его особенностью. И в никаком "стандарте" соответственно как особенность Modbus RTU этот банальный трюк (про в 200 раз повышающий оставим на Вашей совести) не описан и более того применим к началу фрейма абсолютно любого протокола использующего асинхронный физический уровень.

В описании Pbus сказано, что слэйв должен игнорировать принятые символы, если зазор между ними превышает 200 мкс. Но при этом обмен идет на скорости 2400, т.е. битовый интервал равен 416 мкс. Так что этому невменяемому бреду, который вы защищаете, место в топке. :)

Мне наплевать,что там Вам там не травится в Pbus - я с ним не знаком и не собираюсь знакомится, не разу его не защищал. По той простой причине, что утверждал и утверждаю - любой протокол включая Modbus RTU, который на физическом уровне использует асинхронные приемопередатчики, а на канальном уровне для выделения таймауты есть дерьмо изначально. Борьба, победы,поражения реализаторов Modbus RTU с изначально заложенном в нем дерьмом меня в принципе не интересуют. Дерьмо остается дерьмом. Я понимаю,что это Ваше любимое (точнее единственно знакомое ) дерьмо и что предела дерьмовости почти нет, и что Вы видели дерьмо по сравнеию с которым дерьмо Modbus RTU благоухает розами. Только это не изменит того факта, что канальный уровень Modbus RTU изначально дерьмов.

Самое жуткое для людей с атрофированными мозгами состоит в том, что помеха в момент, непосредственно предшествующий этой вашей "определенной последовательности битов" будет воспринята как старт-бит, в результате чего принятая последовательность будет искажена. В Modbus ASCII вместо двоеточия ":" из UARTа будет прочитан другой символ. В результате весь фрейм пропадет - связи не будет. ;)

Для тех, кто мозгов вообще не имел изначально, повторять очевидно бесполезно :(. Да будет, да, так у меня и написано. Но время этого "опасного" интервала указано. И для дерьмового протокола Modbus RTU это время указано. И сравнение двух этих времен сделано. Повторю, еще раз - хреновато у Modbus RTU даже супротив Modbus ASCII, даже при сравнении по этому одному из многих ИСКУССТВЕННО взятому Вами для сравнения критерию оценки "помехоустойчивости".

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

Таки да :(. Modbus в неполноте описания среди распространенных протоколов рекордсмен :(. Это в общем-то и понятно - этот изначально не продуманный протокол на официальную стандартизацию никак не тянул. Слепили как умели, описали как могли, реализовали, как получилось и каждый сам. На самом деле проблемы Modbus RTU канальном уровне. Дальше проблемы в ПОЛНОМ отсутствии верхних уровней с 3 по 6. Собственно сейчас в разумных разработках только Application уровень Modbus и используется. Все остальные уже используются от ЛЮБЫХ чужих стеков. Само описание железно разделено на два документа, осталось только документ описывающий канальный уровень объявить устаревшим и все :). Да вообще-то и не надо, ведь это даже по названию не описание протокола, а некий Implementation Guide - какой спрос :).

[DogPawlowa 0]

Дальше проблемы в ПОЛНОМ отсутствии верхних уровней с 3 по 6.

Ну, для простых последовательных протоколов объединение уровней - обычное решение, в результате получаем контроль доставки на уровне приложения. Сам такие протоколы "клёпал" :)

Хотелось бы напомнить, что в мире существуют стандарты, имеющие прямое отношение к передаче инфрмации.

Например, DIN 66348, в результате имеем обмен типа такого (с экрана симулятора в режиме подмены управляющих кодов).

 

 ENQ          STX 3D11011012021202030300040400050500060600 ETB 60          STX 3D11070070080080099009000000000000000000 ETX 7D          EOT              
      DLE  0                                                       DLE  1                                                       DLE  0