[zltigo 1]

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

Однако, с резким падением пропускной способности канала в качестве "бонуса" за простоту :(. Кроме того, контроль доставки это не единственная работа отсутствующих 4x уровней. Естественно стека в котором были-бы реализованы а не только декларированы все 7 уровней я что-то на вскидку не припомню.

 

 

[=AK= 12]

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

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

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

 

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

 

[aaarrr 69]

Соответственно, протокол с избыточным кодированием будет иметь такую же помехоустойчивость, как Модбас RTU.

На специальной "гнусной" помехе, которая портит весь фрейм, ага. Можно еще провода вырвать - тогда помехоустойчивость в вашем понимании сравнится для всех протоколов. Не устали бредить?

[GetSmart 0]

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

...

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

Я догадываюсь, это были вы :)

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

[=AK= 12]

Требование протокола распространяется только на наличие silent interval.

Вот что написано про Modbus RTU в самом стандарте:

 

 

Промежуток между фреймами, действительно, разделен интервалами молчания длительностью 3.5T. Однако не о них речь, речь идет о самом фрейме, который состоит из стартовой паузы 3.5Т, Модбас сообщения и завершающей паузы 3.5Т.

 

Черным по белому написано, что весь фрейм обязан передаваться непрерывно, как единый поток. Соответственно, согласно этому протоколу, передающей узел обязан включить свой передатчик заранее, не менее чем за 3.5Т до начала передачи сообщения, и держать его включенным еще не менее 3.5Т после передачи последнего символа сообщения.

 

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

 

 

про в 200 раз повышающий оставим на Вашей совести

Я объясню, откуда взялись цифры. Это будет полезно знать не только вам, но и другим начинающим.

 

Линия RS485 с двух сторон должна быть терминирована резисторами, равными волновому сопротивлению кабеля. Типично волновое сопротивление кабеля (витой пары) находится в диапазоне 100...150 Ом, наиболее часто встречается 120 Ом. Таким образом, два параллельно включенных терминирующих резистора имеют сопротивление 50...75 Ом.

 

Резисторы растяжки на линии RS485 обычно подвешиваются к земле и к питанию приемопередатчика RS485, т.е к +5В. Величина этих резисторов выбирается как компромисс между двумя противоречивыми требованиями. С одной стороны, чем меньше сопротивление резисторов растяжки, тем выше помехоустойчивость "висящей в воздухе" линии. Поскольку это именно тот уровень помехоустойчивости, который только и достижим с самопальными протоколами (а также в изделиях, где недотепы превратно понимают правильные протоколы), то, как правило, резисторы подтяжки стараются сделать как можно более низкоомными. С другой стороны, низкоомные резисторы подтяжки вносят неоднородность в линию, а также дополнительно нагружают передатчики, поэтому беспредельно их уменьшать нельзя. Чаще всего используют резисторы в диапазоне 470R...680R.

 

Замечу, что правильному протоколу для RS-485 вообще не нужны резисторы растяжки. Никакие. И это является хорошей проверкой "на вшивость" для протокола: убери резисторы растяжки или, еще лучше, загони через них в линию помеху от генератора - и тогда воочию увидишь, хорош ли протокол и правильно ли он реализован.

 

Итак, резисторы растяжки по 470R создадут на терминаторах 120R||120R смещение 300 мВ. Типичный RS485 приемник имеет входной гистерезис всего 50 мВ, а его дифф. порог срабатывания находится в диапазоне от +200мВ до -200мВ. Соответственно, не вдаваясь в ненужные мелочи, можно принять, что для получения ложного сигнала на входе приемника помехе достаточно преодолеть смещение в 300 мВ. Ток через резисторы растяжки равен 5 мА, напряжение 0.3В, а мощность помехи, которая их пересилит, соответственно, должна составить 1.5 мВт.

 

Когда в линии RS485 есть включенный передатчик, он обеспечивает на линии типично 2.5 В дифф напряжения. Выход драйвера обеспечивает ток не менее 60 мА. Таким образом, для преодоления включенного выхода помеха должна развить мощность 150 мВт. Учитывая, что ток короткого замыкания у драйвера существенно больше (порядка 150 мА), от помехи может потребоваться еще большая мощность.

 

Вот это и дает мне основания утверждать, что правильный (и правильно реализованный) протокол, такой как Modbus RTU, обеспечит в 100-200 раз большую помехоустойчивость, чем типичный самопал.

 

На специальной "гнусной" помехе, которая портит весь фрейм, ага.

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

 

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

Вы не понимаете. Никакая помеха, наведенная на свободную линию перед началом фрейма (т.е. до того, как будет включен передатчик) в Modbus RTU и не способна вызвать потерю фрейма. В течении стартового интервала фрейма, который длится 3.5Т, все помехи, наведенные ранее, будут отброшены приемниками. К началу прихода сообщения все UARTs будут готовы к приему, приемные буфера пусты. Фрейм будет принят без искажений.

 

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

 

Правда, Modbus ASCII можно легко улучшить, сделать помехоустойчивым. Для этого достаточно, например, чтобы в начале фрейма передатчик выдавал символ ":" не один раз, а дважды. Первый символ может быть испорчен помехой, однако второй - очистит буфера приемников и весь фрейм будет принят правильно. Такой улучшенный вариант Modbus ASCII дает пример помехоустойчивого интерфейса, которому не нужны тайм-ауты. Учитесь, GetSmart, авось и правда поумнеете. :)

 

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

Пример "улучшенного Modbus ASCII" дает общую идею: среди всех возможных символов выделяется несколько, при помощи которых организуется управление потоком. Более изящная реализация этой идеи может быть обеспечена несколькими способами.

 

Простое решение получается при помощи байт-стаффинга. Выделяем, например, два символа специального назначения. Один называем "START", второй - "ESC". Если во входном потоке встречается "START", то все приемники обязаны выбросить текущий фрейм и очистить буфера приема. Если в потоке встречается "ESC", то следующий за ним символ интерпретируется особым образом, как команда. Команды могут быть такие:

- добавить в приемный буфер символ, код которого соответствует символу "START"

- добавить в приемный буфер символ, код которого соответствует символу "ESC"

- завершить прием фрейма

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

 

Несколько более трудное в реализации решение получается если использовать, например, кодирование 6b8b, зато сообщение раздуется всего на четверть, а заодно обеспечивается проверка на четность для каждого байта.

[DogPawlowa 0]

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

 

"Некоторые вопросы реализации интерфейса служат почвой для холивара у эмбеддеров." http://eewiki.ru/wiki/RS-485 ;)

 

 

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

 

Правда, Modbus ASCII можно легко улучшить, сделать помехоустойчивым. Для этого достаточно, например, чтобы в начале фрейма передатчик выдавал символ ":" не один раз, а дважды. Первый символ может быть испорчен помехой, однако второй - очистит буфера приемников и весь фрейм будет принят правильно.

 

Остановитесь, дружище! В пылу полемики наговорите фигни, потом будет неловко. Если первый символ ':' (код 0x3A ) искажен, то ничто не помешает исказиться и второму символу, они же передаются со стандартным стопом.

 

 

[=AK= 12]

Остановитесь, дружище! В пылу полемики наговорите фигни, потом будет неловко. Если первый символ ':' (код 0x3A ) искажен, то ничто не помешает исказиться и второму символу, они же передаются со стандартным стопом.

Вы правы, совсем запамятовал. Когда в начале фрейма передаются два старт-байта, то для того, чтобы гарантировать, что второй стартовый символ не будет искажен, желательно, чтобы MSB биты символа "старт", которые передаются последними, были равны единице. В своих протоколах в качестве "старта" я использую символ 0xF0. Четырех бит-интервалов достаточно, чтобы успеть обработать искалеченный символ (если он искалечен) и приготовиться к приему нового.

 

Спросите, почему именно 0xF0, а не 0xFF? Потому что 0xF0 самый подходящий для этого из всех символов кодовой таблицы 6b8b :)

 

А для "улучшенного Modbus ASCII", конечно, лучше сначала передать 0xFF, а потом 0x3A.

 

"Некоторые вопросы реализации интерфейса служат почвой для холивара у эмбеддеров."

RS-485 в некотором смысле является "детской песочницей". Он сильно напоминает радиоканал, но гораздо проще в реализации. :)

[aaarrr 69]

Условие "худшего из возможных" воздействий - вполне правомерное для серьезных изделий.

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

Глупость остается глупостью.

 

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

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

[zltigo 1]

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

В документе нет ни слова передатчик ни тем более фазы его включения. Все это отдано на реализацию протокола. И мне уже честно совсем надоело говорить, что включение передатчика может быть реализовано для любого пртокола. Это никак не заслуга Modbus.

А неправильный вариант, который отстаивают местные воинствующие невежды

Это кто? Я здесь не встретил пока ни одного кто-бы протестовал против пришпиливанию к протоколу Modbus такого костыля. Хуже не будет.

Я объясню, откуда взялись цифры. Это будет полезно знать не только вам, но и другим начинающим.

Это даже не от фонаря :(

Вы не понимаете. Никакая помеха, наведенная на свободную линию перед началом фрейма (т.е. до того, как будет включен передатчик)

Вы даже НЕ читаете или не хотите читать, что речь идет не о времени до включения столь полюбившегося Вам передатчика, а исключительно после. С задоооолго до нет пробоем ни у кого.

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

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

Правда, Modbus ASCII можно легко улучшить, сделать помехоустойчивым. Для этого достаточно, например, чтобы в начале фрейма передатчик выдавал символ ":" не один раз, а дважды. Первый символ может быть испорчен помехой, однако второй - очистит буфера приемников и весь фрейм будет принят правильно. Такой улучшенный вариант Modbus ASCII дает пример помехоустойчивого интерфейса, которому не нужны тайм-ауты. Учитесь, GetSmart, авось и правда поумнеете. :)

Ну точно одна извилина в голове :(. Хотите улучшать - "улучшайте" так-же как "улучшаете" RTU - включите Ваш любимый передатчик -за один символ до. Может не маяться с таймерами и передать каокой-нибудь space символ. Но передавать ложное начало фрейма верх идиотизма.

Пример "улучшенного Modbus ASCII" дает общую идею...

Наш "эксперт" познал идею SLIP протокола и теперь несет ее в массы. Ура!

Несколько более трудное в реализации решение получается если использовать, например, кодирование

Ура! А это рождено знакомством "эксперта" c UUE и подобными.

 

 

Главное оказалось, что есть и БЫЛИ УЖЕ ДО Modbus RTU вменяемые протоколы.

[GetSmart 0]

Кажется я всё понял. =AK= изобретатель.

До знакомства с Modbus он успел изобрести 100 дерьмовых протоколов и при знакомстве осознал, что это всё было такое дерьмо, которое Modbus-у и в подмётки не годится. Другого объяснения, с учётом последних изобретений в этой ветке, пока не видно.

 

 

А вообще, модбас тут совсем ни при чём. Паузу после захвата шины 485 не будет делать только дерьмовый протокол. Это к модбасу отношения не имеет. Это связано с самим 485-ым. Это же элементарно, Ватсон!

 

Кроме того, в модбасе, когда мастер отослал фрейм слейву, мастер переключается на приём и ждёт ответа. При этом линия 485 уходит в болтающееся состояние. Слейв может довольно долго думать (100 и более мс) перед тем, как захватит шину и начнёт передавать данные. Именно в это время любимые =AK= и слабые помехи могут создавать глюки на приёме у мастера. Modbus RTU никак не способен отличить глюки от начала фрейма от слейва. =AK= нервно курит в сторонке :)

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

[=AK= 12]

В дебильнейшем даже с этой точки оценки Modbus RTU помеха в 1+1,5 символьном интервале перед началом фрейма вызывает облом со всем фреймом.

Бред. Никакая помеха в любой момент времени до начала фрейма не способна вызвать "облом фрейма", поскольку принятая грязь будет вычищена в течении старт-интервала 3.5T, являющего частью фрейма.

 

В документе нет ни слова передатчик ни тем более фазы его включения. Все это отдано на реализацию протокола. И мне уже честно совсем надоело говорить, что включение передатчика может быть реализовано для любого пртокола. Это никак не заслуга Modbus.

Может быть реализовано, а может и не быть реализовано. На практике в самопальных протоколах часто не реализуется. Modbus RTU - известный популярный протокол, который эту правильную реализацию явственно требует, поэтому я на него сослался.

 

Я понимаю вашу c GetSmart нынешнюю позицию "это же очевидно", после того, как я подробно объяснил на примерах, как сделать протокол помехоустойчивым. До этого вы только слюной брызгали, однако были не в состоянии сформулировать, как обеспечить помехоустойчивость протокола, работающего на RS-485. Более того, не понимали, как это вообще возможно, чтобы от протокола зависела помехоустойчивость.

 

 

Может не маяться с таймерами и передать каокой-нибудь space символ.

"Какой-нибудь" не годится, мы это с ув. Dog Pawlowa обсудили, а до вас опять не дошло

 

Но передавать ложное начало фрейма верх идиотизма.

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

 

Кроме того, в модбасе, когда мастер отослал фрейм слейву, мастер переключается на приём и ждёт ответа. При этом линия 485 уходит в болтающееся состояние. Слейв может довольно долго думать (100 и более мс) перед тем, как захватит шину и начнёт передавать данные. Именно в это время любимые =AK= и слабые помехи могут создавать глюки на приёме у мастера. Modbus RTU никак не способен отличить глюки от начала фрейма от слейва.

Modbus RTU в этой части не делает отличий между мастером и слейвами. Все узлы передают фреймы одинаково, соответственно, помехоустойчивость одинакова при передаче в любом направлении. Независимо от того, кто является передатчком, он обязан выдержать стартовый интервал 3.5T в начале фрейма, в результате чего фрейм будет принят правильно.

 

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

[GetSmart 0]

Modbus RTU в этой части не делает отличий между мастером и слейвами. Все узлы передают фреймы одинаково, соответственно, помехоустойчивость одинакова при передаче в любом направлении. Независимо от того, кто является передатчком, он обязан выдержать стартовый интервал 3.5T в начале фрейма, в результате чего фрейм будет принят правильно.

Гы :)

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

 

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

У меня сотни приборов идеально работают и на 485 и на 232 и на 3.3 TTL через модбас. Ешьте чей-то ещё моск своими открытиями :)

[=AK= 12]

У меня сотни приборов идеально работают и на 485 и на 232 и на 3.3 TTL через модбас.

 

В сочетании с вашей фразой "Modbus RTU никак не способен отличить глюки от начала фрейма от слейва" звучит очень хорошо. "Это пять!" (с) :)

 

На столе в лаборатории - почему бы им не работать-то. ;)

 

[zltigo 1]

"Какой-нибудь" не годится, вы это с ув. Dog Pawlowa обсудили, а до вас опять не дошло

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

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

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

 

 

 

[DogPawlowa 0]

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

 

А для "улучшенного Modbus ASCII", конечно, лучше сначала передать 0xFF...

 

Предлагаю остановиться.

Или есть возражения? ;)