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

И в чем же великая необходимость такого изврата?


Может просто не ставить "недополнительный контроллер"

PS:
Если нужен хороший ответ, потрудитесь задать хороший и полный вопрос... телепатов тут нет

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

Не будьте столь категоричными, необходимость развязки CAN-bus есть. Пример: контроллер должен связаться с несколькими внешними устройствами, земли которых соединять недопустимо.
Схема может быть такой (см. рисунок, Нажмите для просмотра прикрепленного файла). Естественно, для каждого канала схема должна повториться.

Упустил из виду - между U17 и микроконтроллером должен стоять еще один CAN-драйвер, общий для всех каналов. Он у меня на другом листе нарисован.

ИМХО: Вместо того, чтобы городить подобный огород, лучше развязать всю CAN-шину и вообще забыть про общую "землю".

Правильно! Профессионалы так и поступают.
Вместе с сигнальными линиями идут два провода питания шины, развязанные от всего через DC/DC конвертор с гальванической изоляций. Это питание применяется только для CAN-трансиверов в каждом устройстве, поэтому и мощность источника питания весьма невелика.
Если надо, могу дать примерную схемку.

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

В там случае надо знать следующее:
1. Параметры портов "черных ящиков"
2. Параметры ЭМС "черных ящиков"
3. Требования к ЭМС всей системы.

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

И, скажите честно, кто-нибудь когда-нибудь применял в одной CAN-овской сети свои устройства и неизвестно какие "черные ящики"? Ведь CAN - это не только физическое сопряжение устройств, надо еще и протокол знать.
Потом, если надо воткнуться в какую-либо существующую сеть своим, может быть, сверхдорогим и суперзащизенным устройством, которое должно вылететь в последнюю очередь после разрушения всей сети в эпицентре ядерного взрыва.... мда, занесло меня...
Так вот, если надо воткнуться - то лучше поставить недорогой CAN-овский мост, которой с одной стороны будет гальванически связан с имеющейся сетью, а с другой - полностью отвязан для подключения к нашему (вашему) устройсту, при этом организация питания сети со стороны нашего (вашего) устройства - см. мой предыдущий пост.
На роль моста подойдет любой контроллер с двумя CAN-овскими модулями (PIC, или что-то на базе ARM7, например от Atmel или Philips).

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




У Fujitsu тоже имеются такие МК

Хочу или не хочу я что-то подключать, никого особенно не интересует. Это моя работа, за которую платят деньги.
Я не совсем точно выразился, ящики не "черные", протокол и все прочее известны. Заставить производителя переделать аппаратную часть интерфейса "под себя" практически нереально.
Проблема в том, что кроме CAN из них выходят также аналоговые сигналы, и работать это будет в промышленных условиях, поэтому соединять земли крайне нежелательно.
На мой взгляд, пассивное развязывающее устройство сделать проще и дешевле - спаяли плату и все сразу работает + не надо писать и отлаживать доп. программы для хаба, там и без этого проблем хватит.
Время - деньги ©

У Analog Devices есть цифровые изоляторы iCoupler типа ADuM1400 и т.п.
Вот их сводная таблица:
http://www.analog.com/Analog_Root/static/p...alIsolators.pdf

Или запустите по сайту поиск по iCoupler. Еще где-то попадалась статья про них на русском языке.

Кстати, удовлетворите мое любопытство - нахрена с CAN-овскими сигналами пускать аналоговые? И как это выглядит?

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

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

Если вернуться к первоначальному вопросу, то он звучал так: "Как гальванически развязать шину ?".

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

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

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

А мы ставили IL711 от NVE
а теперь начинаем SI8421 от silabs они в разы дешевле, а по корпусу и ногам совместимы

Репитер, созданный по схеме, работать не будет.

Как-то делали оптическую вставку в CAN. Что-то типа оптических модемов если грубо. Думаю можно приспособить как-нить

Я так тоже дмаю

Это не репитер, это триггер (не)работающий на CAN.

Кстати имеет ли значение отдельные линии питания CAN трансиверов и контроллеров. Т.е. что лучше - вести везде четыре провода - Земля +Питание, CANH СANL, а затем с помощью DC/DC получать питание от этих линий для удаленных устройств?
Или можно вести 6 проводов Земля+питание для CANа, Земля+питание для схем и CANH и CANL. Но в таком случае я как понимаю гальванической развязки между устройствами не будет, хотя передаваться будет только питание.
Или вообще не заниматься ерундой, если расстояние менее 200м?
Может кинете ссылкой, как лучше сделать развязки?

Развязки не будет. Не забывайте о том, что по проводам питания иногда протекают токи Которые могут создавать наводки на КЭН. Поэтому, задачи объединения узлов в сети КЭН и питания узлов лучше не смешивать. Ведь не обязательно, чтобы сеть питания повторяла топологию илний связи. Короче, питайте Ваши узлы каждый посвоему (где-то 220 с 2-мя втор. обмотками - одна для схем, одна для КЭНа, гдето один блок на все схемы и при этом каждый КЭН - через свой отдельный ДСи/ДСи от питания соответствующей схемы и т.д.).


Реализовать развязку КЭНа красиво и дёшево НЕ возможно. Например, потому, что:
-для развязки потребуется дополнительное преобразование КЭН-ТТЛ, и ТТЛ-КЭН. Это осуществляет КЭН-трансивер и делает он это достаточно медленно (даже тот, который 2МБпс) -> Вам нужно будет либо сильно увеличивать Prop_Seg, что повредить Phase_Seg* либо сильно снижать скорость (примерно в 2 раза). А это значит, что можно просто поставить активный повторитель (он решит проблему, но сам, по своей идеологии является устройством, морально мёртвым, ещё даже не родившись см. book.itep.ru, раздел про повторители Изернет). Построить пассивный быстродействующий повторитель невозможно из-за медленных трансиверов (никто их не делает, хотя могут, быстрыми т.к. "стандарт не требует");
-если забить на скорость то сразу же встаёт другая проблема: повторитель должен принемать сигнал, преобразовывать его в своё внутреннее состояние и выдавать на остальные порты. Если кабельные сегменты, подключённые к повторителю, будут разной длинны (а иначе никому и не надо), они будут обладать разной ёмкостью, и в то время, когда все сегменты передут в рецессивное состояние после доминантного, самый высокоёмкостной ещё будет в доминантном и выставит ЛОЖНЫЙ доминантный импульс в состоянии повторителя. Вот.

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


Позвольте узнать вы все таки нашли красивое и недорогое решение данной проблеммы?

Чтобы заработала развязка - логика, управляющая ей, должна знать скорость передачи и понимать CAN протокол. Иначе конфликтов не избежать. Придётся смотреть откуда SOF пришёл и кто арбитраж выиграл... Поэтому на рассыпухе это сделать невозможно. И в любом случае - будет вносится задержка. Причём не только драйверами и развязкой, но и самой логикой.
А вообще, это на каком-нибудь самом дешёвом AVR с тактовой 20 мГц можно сделать. Например, ATtiny2313 или ATmega48 подойдут. Но до скорости не более 500 кбод.

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




А вы их ставили на CAN шине? В документации про CAN ни слова

На рассыпухе все прекрасно делается. (Скорость передачи и протокол не играет роли)
Но чтобы с ней не маятся, используем PLD.
PS. Логическая схема репитера изложена в каком-то из документов Cia.
PS2.Проблемы, указанные Mos, могут наблюдаться.

Да, конечно. Я такую реализацию видел. См. в интернете сканматик. Так там используется ATtiny2313, и ничего, с J1939 нормально работает. Да и ничего особо сложного там нет. Возможно я как раз чем-то подобным и займусь в недалёком будущем...

Это гальваническая развязка, при чём здесь CAN документация?

Да, я тоже подумал, что на самом деле это гораздо проще, чем мне сначала показалось.
У меня получилось, что всего один триггер, который управляет направлением передачи, нужен, и несколько логических элементов. Когда в обоих подсетях рецессивный уровень, триггер имеет возможность переключится от любой из подсетей. Т.е. он следит за тем, в какой части доминанта первой появилась. Например, она первой появилась в части N1. Тогда триггер направление передачи на "из подсети N1 в подсеть N2" переключает, а сам, до тех пор пока в подсети N1 рецессивный уровень не появится, переключатся не может. Когда в подсети N1 рецессивный уровень появится - триггер получает возможность переключаться. И если в этот момент в подсети N2 доминанта, он переключится на направление N2 -> N1. Если в N2 рецессивный уровень, то опять будет следить за тем, где доминанта первой появилась (в это время направление передачи не имеет значения). А если подсетей больше 2, то просто переключается передача от подсети Nx ко всем остальным.

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

Весь хаб:
Нажмите для просмотра прикрепленного файла

Отдельный его элемент:
Нажмите для просмотра прикрепленного файла

P.S. На здоровье

Лично я с большим недоверием отношусь к решениям типа КЭНовского хаба, приведённого выше. Сама идеология КЭНа, равно как и TIA/EIA-485 изначально не предусматривала повторителей физического уровня (а хаб - это частный случай такого повторителя; не важно, что он служит только для развязки). Хотя маститые конторы (типа TI, MAX и т.д.) предлагают решения данных задач, всё равно возникает куча оговорок и выглядит это всё как-то слегка СР@НО.
Приведённый выше хаб - решение для КЭНа (данное решение уже не раз мелькало на форуме, но у Cia я его не встречал (но особо и не искал)).
Для 485-ого предлагается решение на основе некоторых драйверов (не помню каких). Идея такая: если драйвер хочет выставить лог. "0", то выставляет и всё. Если лог. "1", то он выставляет этот уровень и через малый промежуток времени (типа четверти битового интервала) переходит в "Z" (это можно былобы и на контроллере сделать, при программном USARTе, путём упр. ногой DE, исп. любой драйвер, а не наворочаный).
А КЭНовский хаб должен защёлкнутся (до снятия питания)!
(тынц)

2 Shandy:
насчёт необходимости развязки CAN-bus:
может быть следует уточнить, действительно ли нужно отвязывать КЭН ТРАНСИВЕР одного сегмента сети от ТРАНСИВЕРА другого сегмента сети? или нужно отвязать ТРАНСИВЕР от остальной схемы, а трансиверы между собой пусть будут соединены?

если первый случай, то както очень смутно могу себе представить, чтобы разработчики этих девайсов изначально планировали, что их девайсы будут работать в таком режиме - очень врядли! В этом случае - применение КЭНа было бы ошибочным.
если второй - всё просто - ставится опторазвязка (типовое решение). А ставится она либо между формирователем КЭН протокола и ДРАЙВЕРОМ ФИЗ. УРОВНЯ либо между контроллером и объектом управления (ведь не просто же контроллер в сетке висит) (можно и так и так, но дорого по питанию

Совсем крайний случай описан в литературе: "CAN application in avionics" (см. прил, рис. 17 - схема с трансом)

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

если на MCU то имейте ввиду проблему зависания ( причин много), логика все же не виснет.

Если тема еще актуальна, могу подкинуть еще одну схему развязки CAN (реально применяемую):
Нажмите для просмотра прикрепленного файла
(источник: презентация "Аппаратные решения и разработки для шины CAN". Чепурнов А.С. http://www.can-expo.ru/files/apparat.pdf )

Конечно, этот вариант, наверное, еще с изобретения CANа появился. (Ну, или немножечко позже)

Неужто и вправду кто-то такое реально городит? Тем более что давно уже есть драйверы со встроенной оптоизоляцией и защитой.

Хотелось бы узнать названия.... чтоб "реально не городить"

Например, этот: ISO1050
http://www.ti.com/ww/ru/analog/iso1050/index.shtml
http://www.compeljournal.ru/enews/2010/8/3

Вы не путайте оптическую развязку с защитой самого драйвера. Элементы L1, D1, D2 D3 - служат только для защиты при работе CAN драйвера на длинных линиях. Пока вы работаете в условиях, где нет помех, вам ничего такого не потребуется, поэтому многие и думают, что это не нужно. Но на длинных линиях - это необходисость. И пока ничего такого в одном корпусе я не встречал. Единственное, вместо D1,D2,D3 ставят что-то типа NUP2105L или PSM712. А тот самый ISO1050 защиты никакой не имеет и выгорит на длинной линии при помехе только так.
По цене он дороже обычного драйвера + пара оптронов. Все равно к нему DC/DC преобразователь нужен.

Менее года даташиту - это давно? Да он еще не продается толком.

PS Но все равно он будет интересен тем, у кого места на плате мало - например для меня. Спасибо - самплы заказал.

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

Смысла нет в применении всего этого в одном корпусе - паразитная ёмкость будет больше, чем в нескольких. И разводкой её не уменьшишь и резисторы, для её уменьшения, внутрь добавить невозможно.
В схеме, кстати, такие резисторы включены правильно. Только они должны выводными быть - проходная ёмкость меньше. И ещё нужно поставить выводной резистор номиналом в районе 1 кОм между RX_CAN и 6-й ногой U1. Иначе прямо на ногу проца помеха попадает.

1.9пФ - это разве большая проходная емкость?

Небольшая, но у обычных smd резисторов, вместе с печатными дорожками, получается около 5 пФ.
Но самое главное не в величине ёмкости, а в том, что при использовании smd невозможно защитные земли как следует развести - места не хватает.
Ну и ещё у выводных металлоплёночных резисторов номиналом более 500 ом, как правило, спиралькой резистивный слой нарезан. А это увеличивает паразитную индуктивность. Но она, в этом случае, полезна.
Да и вообще, ИМХО на защите от помех экономить не стоит.

Вот еще в семействе изолированных CAN драйверов прибавилось - ADM3053 уже с DC/DC конвертером внутри. И корпус еще меньше - SOIC20 13x17мм.

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

на скоростях CAN она вряд-ли помешает.

А что у Максима есть изолированое для CANа?

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

Подниму тему
Кто что думает про оптоволокно в КЭНе?
Вот думаю HFBR-0400 применить. На вскидку, управлять ими прямо с КЭН ножек контроллера, только пока не соображу как их подключить, если в цепи больше 2х устройств.

На Avago вроде были примеры применения ихних оптокомпонентов для CANа. Но я не сильно разбирался.

На Avago не чего не нашел

http://www.avagotech.com/docs/AV02-0784EN
Они предлагают использовать оптические пассивные сплиттеры - недешевое удовольствие, насколько я знаю.

Этот ADM3053 стоит 710р в рознице.

дискретное решение:
изолятор Si8421 240p
DC/DC ROE-0505S 320p
CAN драйвер MCP2551 80p
итого 640р (+ место на PCB, + обвязка керамика)

примерно тож на тож.

есть какие-либо альтернативы оптимизации стоимости? может чего-то пропустил?

PS: есть еще ISO1050 (CAN+изолятор) за 290р + DC/DC = 610p

Я пока ставлю ISO1050 и не парюсь. Единственное по обвязке к нему надо еще дроссель + TVS на шину типа NUP2105L или аналогичное, бо по защите он хуже MCP2551, насколько я помню даташит.