[Ruslan1 17]

Не хамить воспитание не позволяет?

перевожу на русский:

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

=AK= использует протоколы, которые чувствительны к этому, то есть они не имеют эффективной защиты от этого "горя".

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

Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:

1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184

2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.

3) применяют (1) + (2) вместе.

[=AK= 12]

имелось ввиду, что если выдерживать паузу с переключением на приём, после передачи полезной информации и постоянно вести обмен

на линии - то устойчивость к помехам возрастает.

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

 

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

 

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

 

Некоторые (условно назовем их "остальные") использует протоколы....

Выше я в общих чертах описал два существующих подхода к построению правильного протокола для RS-485. Других нет, так что "остальные" со своими растопыренными пальцами могут покурить в сторонке.

 

Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:

1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184

2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.

3) применяют (1) + (2) вместе.

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

[Ruslan1 17]

Хоть кол на голове теши.

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

 

Выше я в общих чертах описал два существующих подхода к построению правильного протокола для RS-485. Других нет, так что "остальные" со своими растопыренными пальцами могут покурить в сторонке.

Ваш мозг в состоянии вместить не одно, а два или три одновременно возможных условия? Из них необходимым является наличие подходящего к среде передачи протокола, а остальные условия могут выбираться по ситуации.

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

 

Upd: Хм. перечитал себя. При некотором извращизме (ну, как минимум один так уже прочитал) действительно можно подумать, что я ратую заменить соответствующий среде передачи протокол на подтяжки. Никогда! Для меня наличие нормального протокола настолько очевидно, что я как-то и не подумал, что могут найтись люди, которые этого не понимают.

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

[=AK= 12]

Какие сказки про белого бычка? Че за знаки "ты идиот"?

- а что не так с 485? -

- Объяснил первый раз

- И че делать? CAN?

- Ответил

- Изначально я спрашивал, что если не RS-485? - соврал; возможно это тролль?

- Обьяснил второй раз.

- какая связь между "резисторами подтяжки, помехоустойчивостью" и правильным протоколом? В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?

- Обьяснил третий раз.

- Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus? - вроде бы дошло, но не совсем

- Ответил

- И при чем тут "правильный протокол"? - опять двадцать пять; oбщее поведение соответствует поведению тролля.

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

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

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

 

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

Это не является достаточным условием для помехоустойчивого протокола. Вполне обеспечивается, например, хорошим CRC. Однако никакой гарантии от глюкавости в условиях сильных помех не дает. Сообщение просто никогда не дойдет до адресата. Так что все-таки "остальные" пусть постоят тихонечко где-то в сторонке, они, действительно, даже до "гурманов" не дотягивают.

[msalov 0]

То бишь RS-422 самый стойкий к помехам?

RS-485 с правильным протоколом ничуть не хуже.

А CAN bus?

Примерно такой же, как RS-485 с плохим протоколом и резисторами растяжки.

Хотел бы уточнить насчёт CAN. Да, физический уровень не фонтан (не Push-Pull, но как-то же надо разрешать коллизии), на большие расстояния не годится. Но вот на счёт плохого протокола поясните пожалуйста. Разве у CAN не жёстко задан протокол приёма с тишиной до и после пакета, подтверждением приёма, CRC, бит-стаффингом? Мне кажется стоило бы разделять тёплое и мягкое, т.е. аппаратные и программные меры, а сравнение может быть только в конкретной ситуации.

[DogPawlowa 0]

вишь как обрадовался кормежке

:)

Но может всё-таки не понимает?

 

Хотел бы уточнить насчёт CAN. ... Мне кажется стоило бы разделять тёплое и мягкое, т.е. аппаратные и программные меры....

Если Вы нашли какое-то противоречие в словах, то лучше его указать. Вон как =АК= успешно отбивается, он несомненно объяснит.

А так получилась общая фраза. Разумеется Вы правы, в случае с CAN меньше места для творчества, но "всегда есть место подвигу".

Например, при распределении идентификаторов использовать нули там, где есть избыток битов. По идее это повысит надежность связи.

[msalov 0]

Если Вы нашли какое-то противоречие в словах, то лучше его указать.

Так и указал. Более слабая физика RS485 (из-за отключения передачика) + хороший протокол вкупе дают хороший результат сравнимый с RS422, а вот CAN с ещё более слабой физикой но с на порядок более надёжным протоколом (уже готовым, причём) почему то сравнили с аутсайдером обсуждения - RS485 + плохой протокол, без вариантов.

[=AK= 12]

Хотел бы уточнить насчёт CAN. Да, физический уровень не фонтан (не Push-Pull, но как-то же надо разрешать коллизии), на большие расстояния не годится. Но вот на счёт плохого протокола поясните пожалуйста. Разве у CAN не жёстко задан протокол приёма с тишиной до и после пакета, подтверждением приёма, CRC, бит-стаффингом?

Я говорил, что CAN, в силу своего слабоватого физического уровня, по помехоустойчивости не может тягаться с RS-485 c качественным протоколом. Его помехоустойчивость сравнима с помехоустойчивостью интерфейса на базе RS-485, где есть резисторы растяжки, но используется плохой протокол. "Жесткость" протокола, использование CRC и т.п. отнюдь не делают протокол автоматически "хорошим", а плохой физический уровень погубит любой протокол, как бы он ни был хорош.

 

Когда-то давным-давно я лично наблюдал за мытарствами неких изобретателей самопальных протоколов, которые свято верили в силу резисторов растяжки на RS-485. Программист незнамо зачем (сам он не мог объяснить своих мотивов) переводил трансивер в 3-е состояние после каждого переданного байта, то есть, делал нечто напоминающее физический уровень CAN. На объекте система дико и регулярно глючила, надолго теряя связь, что по условиям задачи было недопустимо. Туда в командировку несколько раз посылали электронщика. Его действия сводились к уменьшению сопротивления резисторов растяжки и замене кабелей на все более дорогие экранированные витые пары. Частота глюков немного снижалась, однако оставалась заметной, система работала ненадежно.

 

В случае CAN тишина до и после пакета позволяет уменьшить количество коллизий, однако никак не спасает от помех.

[Herz 5]

Господа! Воздержитесь от наездов! Не хватает терпения объяснять спокойно - никто не принуждает участвовать. Тему частично почистил.

 

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

Один вопрос дилетанта: как приёмники знают, что данные сейчас не передаются?

[ZASADA 0]

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

[=AK= 12]

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

Буржуи в курсе, поэтому ничего "жизненно-критического" на него не возлагают и за панацею не держат. Для fly-by-wire используют более надежный MIL-SDT-1553 и иже с ним. Для drive-by-wire предназначены flex-ray и TTP, и т.п. Для таких ответственных применений CAN не прокатывает. Вот домашнюю автоматику на нем собрать - самое оно, для этого почти чего угодно сойдет.

[DogPawlowa 0]

на порядок более надёжным протоколом

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

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

 

[ZASADA 0]

Буржуи в курсе, поэтому ничего "жизненно-критического" на него не возлагают и за панацею не держат. Для fly-by-wire используют более надежный MIL-SDT-1553 и иже с ним. Для drive-by-wire предназначены flex-ray и TTP, и т.п. Для таких ответственных применений CAN не прокатывает. Вот домашнюю автоматику на нем собрать - самое оно, для этого почти чего угодно сойдет.

а какже самый надежный RS-422?

 

[AlexandrY 3]

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

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

 

CAN - сетевой интерфейс. Надо рассматривать его надежность, дальнобойность и скорострельность в контексте сети.

Насколько жизнеспособна сеть с CAN, насколько CAN загружает узлы, как быстро сеть восстанавливается после нарушения физической целостности.

RS485 оcтается где-то жить только из-за MODBUS. Но cам MODBUS морально устаревший протокол. Нигде в нем каких-то особых средств поддержания жизнеспособности сети нет.

 

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

Имею опыт применения CAN и на военных полигонах протяженностью в километры и в управлении локальными устройствами и в лифтах.

С успехом конкурировал и вытеснял решения предлагавшие RS485.

"Хороший" протокол на RS485 это такой "неуловимый Джо". А в реале съедает все силы разработчиков.

 

 

 

 

[Plain 185]

CAN - сетевой интерфейс.

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