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


Если Вы нашли какое-то противоречие в словах, то лучше его указать. Вон как =АК= успешно отбивается, он несомненно объяснит.
А так получилась общая фраза. Разумеется Вы правы, в случае с CAN меньше места для творчества, но "всегда есть место подвигу".
Например, при распределении идентификаторов использовать нули там, где есть избыток битов. По идее это повысит надежность связи.

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

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

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

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

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


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

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

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

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

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

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

В условиях тяжелейших помех, отказа узлов , наличии приоритетных критических задач и сообщений CAN явный лидер.
Имею опыт применения CAN и на военных полигонах протяженностью в километры и в управлении локальными устройствами и в лифтах.
С успехом конкурировал и вытеснял решения предлагавшие RS485.
"Хороший" протокол на RS485 это такой "неуловимый Джо". А в реале съедает все силы разработчиков.

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

Хорошая тема для нового флейма - "отвественная задача". Странно, но википедия такого термина не знает.

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

И я разрешаю воспроизведенние данного высказывания в упомянутой базе.

Безопасность управления стеклоподъемниками обеспечивается на уровне драйвера, интерфейс связи (любой) в эту цепочку не входит вообще.
Я даже слышал байку о том, что ставят DSP, чтобы распознать коллизии наиболее достоверно.

CAN не мог быть создан для стеклоподъемников и даже для тысячи стеклоподъемников.
Он был создан для сети исключительно разнородных устройств разных по важности выполняемых функций.
И в этом его сила.
В современной машине применяют что-то около 200 микроконтроллерных узлов, если память не изменяет.
Даже если на всех одинаково "хороший протокол", то все равно у них не одинаково хорошие приложения.
И вот CAN с таким зверинцем идеально справляется. Забивает флудеров, приоретизирует сообщения, не требует квитанций, мапирует прямые передачи и проч.

По поводу помехоустойчивости. Диф.линия очень хорошо давит синфозную помеху. А в этом плане у CAN допустмо аж 80В на входе, вместо 12В для RS485. Хотелось бы увидеть макет, где в диф.линии появляется значительная по масштабу помеха (ну, вольт 10 хотя бы). И поместится ли такой макет
в квартире/доме?

С точки зрения приемника данными является принятое нечто, что соответствует ряду обязательных условий.
Более узко: это есть последовательность байтов, которая соответствует принятым в данном протоколе правилам, например: преамбула, префикс-суфикс, контрольная сумма, количество байт, предопределенные некоторыми полями параметры (например, принятая длина равна длине, указанной в пакете), предыстория (принятые до этого данные), и прочее.
То есть если последовательность принятых сигналов не соответствует хоть одному из обязательных в применяемом протоколе критерию- то это не данные.

В инверторе сварочного аппарата на электродах порядка 70 Вольт полный размах наблюдал. В момент включения сотен Ампер, наверное,
десятки вольт наводки возможны.
Мне тоже кажется, что в Bosch не дураки сидят. Столько авто на CANe и нет проблем.

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

вариантов два:
1) в процесс ремонта имеет смысл заложить провода
2) если ремонт уже есть и чтобы его не ломать - имеет смысл посмотреть в сторону радио. например, я себе делал подобное на NRF24L01/LE1.

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

Трансилами срезать.


Глушится на раз.

Целенаправленно - да, как и вообще любое радио. А от всяких WiFi, BT и что там еще у нас на этой частоте вполне можно и отстроиться.

но

На современном этапе вытесняется еще более помехоустойчивым интерфейсом точка-точка - оптоволокном.

Ну, микроволновки созданы специально для вайфая
Почему-то все дружно забыли про PLC... да не тот, что ПЛК!!- Power Line Communications

А про него все забыли. Поигрались и забыли. Ущемленный всякими ЭМС стандартами до полной убогости, и в результате дорогой, медленный, глюкавый. Всеобщий бардак в электропроводке делает результаты его применения плохо предсказуемыми: в одном доме работает, в другом нет, а в третьем работает, пока юзер не воткнет в розетку какую-то новую приблуду. Он вытеснен всякими RF, основные из которых я перечислил в начале треда.

Тогда налицо противоречие: чтобы понять, что данные не передаются, приёмники всё равно должны "слушать линию", обрабатывать получаемые сигналы и принимать решение о том, данные ли это. Так это в любой асинхронный протокол в той или иной степени должен проделывать. Говорить в этом случае, что "ему всё равно, что в это время творится на линии" - явное преувеличение.

вам осталось только назвать автомобиль с очень надежным RS-422 и без очень ненадежного CANа.

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

При том, что CAN не очень помехоустойчив, он довольно надежен. Кроме того, он дешев в реализации. Построение аналогичной системы на RS-422 или оптоволокне обойдется дороже. А в автомобилестроении каждая копейка на счету, вот его и применяют.

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

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

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

И вряд ли опровержение этого банального факта может лечь в основу Вашей диссертации по философии

ОК, я бы назвал это просто: помехоустойчивым алгоритмом. Приёмник по определению не может быть безразличен к тому, что происходит на линии. Он вынужден реагировать на все изменения и анализировать их. Центральный контроллер, которому, в конечном итоге, предназначены данные, может не заниматься этой рутиной: функции распознавания и фильтрации помех просто выносятся на периферию. Но никаких чудес, конечно, не происходит: шина остаётся шиной со всеми её проблемами. И объём вычислений остаётся тем же.
Определяемый протоколом. Так?

Я не вижу что тут опровергать и зачем. Вы ни коим образом не опровергаете мои слова.
То что Вы написали, в случае практически любого протокола будет определено как не-данные: отсев будет либо по неправильному байту (не принят STOP), либо по неправильному адресу, либо по CRC, либо по содержимому пакета принятых байтов, либо по длине этого принятого пакета.

А философии действительно не хватает в приборостроении. Может, замутить новое течение... Философия переходов... Полупроводниковая диалектика.... Хм. Надо подумать.....

P.S.
топикстартеру, по существу: не бойтесь Вы CAN или RS485.
CAN сильно серьезней и лучше в подобных задачах с разношерстной аппаратурой . больше уровней ISO включает прямо в спецификацию и больше чего решает аппаратно внутри, до доставки дейтаграммы на программый уровень. CAN любит хорошие провода и правильное терминирование. Ну и меньше придумывать нужно, все уже придумано и стандартизировано, от Heartbeat до LSS (CANopen).

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

если CAN- то CANopen (все основное открыто или открывают после звонка/письма в головной офис, что закрыто- то доставабельно в интернете). Но CAN-приборы обычно дороже чем RS-485.
если RS485- то MODBUS RTU или ASCII (все открыто). Я только RTU пользую, но уже лет пять как к ASCII приглядываюсь- при приеме в компьютер с ним сильно проще.

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


Так. Объем "вычислений" определяется физической шиной и применяемым протоколом. Примеры "вычислителей":
1) Компаратор с гистерезисом, определяющий переход больше 120 мВ
2)логический автомат приема бита, работающий по принципу совпадения 3 из 5
3) CAN: прием дейтаграммы ведется контроллером CAN, и какая его часть сделана аппаратной логикой а какая вшитой микропрограммой- это внутреннее дело разработчика МК.
4) уже пользовательское: разборка содержимого, счет CRC(тоже бывает вшитая микропрограмма), реакция.

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

http://www.kernelchip.ru/Laurent.php
на сколько потенциально могло бы подойти найденное решение посредствам Ethernet?
п.с. если есть аналоги более дешевые предлагайте
данный протокол кажется удобным за счет разных возможностей коммутации, либо витой парой, либо дешевыми вайфай роутерами, на худой конец
какое-то устройство с разработкой и дебагом плат, даже для собственного применения трудоемкое, потому и хочу то, что под силу будет, не вникая в низкоуровневые протоклы смастерить.

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

Мне кажется, что это очевидно. Что именно Вас смущает?

Кстати, лет 17 назад сталкивался с таким: стояла в одной организации система сбора данных (ЦТ-5000), по республике у них было расставлено полтора десятка точек сбора. Там сложная каналообразующая аппаратура, передача по ЛЭП с переприемами, что-то поменять в канале связи практически невозможно. Так у них была одна точка, которая за много лет работы ни разу не смогла нормально завершить обмен данными с сервером. НИ РАЗУ. Ну, такой разработчики протокол применили, им же виднее было. Там помеха валила примерно каждый 15й байт (скорость выделенного канала была 100 бод). Мы в своем нижнем уровне тогда применили доморощенный протокол с длиной 11 байт, проработало много лет успешно.


Если "не мастерить и быстро-стандартно" - то Ethernet это идеальный вариант. В сочетании с технологией PoE вообще крастота. но проводами, wifi применим только как временное решение и для некоторых узлов.

Насчет конкретного линка- тут от метода покупки зависит, я бы начал с ебея-алиэкспресса,
Например, у этого болгарина целый склад вкусностей на эту тему (галантерейщики и кардинал, тьфу, телемеханика и езернет)
http://stores.ebay.com/DAEStore?_trksid=p2047675.l2563

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

Не все так очевидно, как вам кажется.


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

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

Судя по этой реплике, вам померещилось будто бы кто-то предлагает RS-422 как панацею для любых применений, включая "умный дом"? Раз с первого раза до вас не дошло, повторяю: для "умного дома" подходит почти что угодно, в том числе и CAN. Коммерческие EIB и С-Bus используют простейшие передатчики с открытым коллектором, и ничего, успешно работают в тысячах зданий.

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


Например:

http://www.ebay.com/sch/i.html?_sacat=0&am...+spi&_frs=1

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

http://www.leviton.com/OA_HTML/SectionDisp...;minisite=10251



Во первых дорого. Во вторых, если надо чтото сложнее чем кликнуть реле придется более мощный контроллер брать, да и граблей там может быть больше.
Гладко только на бумаге. Проще всего RS-485 и не болит голова у дятла.
Ну или CAN, но уже думать придется.

A. Fig Lee, это у Вас всё разные розетки, а подрозетник — это коробка в стене, и соответствующая дыра под неё.

Плата, которыми автор собирается набить все стены, имеет размеры 100х135 — накиньте ещё 20% и больше, и ищите соответствующих размеров установочную коробку.

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

Я уже много раз ссылался на Modbus RTU. Если вы не понимаете, как он работает в условиях частых помех, поясню:
- в начале фрейма, еще до начала пакета данных, передатчик включает свой трансивер на передачу и выдерживает паузу в 3.5 байт-интервала, не передавая никаких байтов
- поскольку максимально допустимая пауза между байтами внутри пакета данных не может превышать 1.5 байт-интервала, все приемники успевают закончить прием ложных байтов, после чего, обнаружив длинную паузу на линии, очищают свои буфера приема от мусора, нанесенного помехами во время пассивного периода между фреймами
- после этого все приемники, без какой-либо коррекции ошибок, благополучно принимают неиспорченный пакет данных (передатчик, конечно же, гонит весь фрейм как одно целое, ни в коем случае не переводя трансивер в третье состояние во время фрейма).

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

Хорошее уточнение. По сути означающее то, что к хорошему протоколу нужна и хорошая линия связи. Ибо источник помех - это не только наводки на низкоомную цепь ЭМ излучения, но и плохие контакты, например. Нет?

Вы издеваетесь? Сначала написали одно, потом "уточнением" изменили свою точку зрения на противоположную.

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


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


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

А помеха, которая глушается активным передатчиком- это классика, MODBUS RTU на это заточен. Это "хороший" протокол для линий, в которых помеха заглушается активным передатчиком. Если Вы попробуете необдуманно применить MBRTU на линиях, в которых помехи сильнее передатчика- он не справится, и, соответственно, перейдет в разряд "плохих" протоколов.

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


Слив засчитан. Однако в вашем положении обтекать более пристало молча.


Не переливайте из пустого в порожнее, речь все время шла о RS-485, для которого это всегда имеет место.

Вот здесь вы несли глупости на тему RS-485, a вот это объяснение - проигнорировали, очевидно, вcледствие непонимания. В этом диалоге o RS-485: 1 - 2 - 3 - вас практически прямым текстом спросили, как обеспечить помехоустойчивость, когда незадолго до начала пакета помеха навела ла линию ложный символ; из диалога видно, что в тот момент ответа вы не знали. И вот теперь, когда вам разжевали и в рот положили, и до вас, наконец-то, дошло, вы делаете поворот оверкиль и вместo "это невозможно" начинаете говорить "это очевидно" и обвиняете меня в "непоследовательности". Смешно.

Если возвращаться к теме, то я бы делал или на Ethernet или на Lonworks.
Для себя выбрал Ethernet, т.к. более универсальный, уже развел по 1-2 кабеля в каждое помещение, получилось как раз 16 - свич занят полностью.
Пока подключены интернет и прочее телевидение.
Единственно, что непонятно - нужен ли вообще "умный дом". Термоголовка надежнее привода клапана.
В планах только автоматический полив.

Ethernet хорошо, но пока дороже прочих решений и зачастую избыточен.

Да, это как дорогое бухло - дорого и избыточно

Ну как сюда не предложить такой вариант:Основная идея, И еще ссылочка:Ссыль

еще немного и убийцо MODBUS будет готов...