[Седой 0]

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

[Denisvak 0]

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

 

CAN        modem      оптика        modem      CAN
====<>|         |-------RX--------|          |<>=====
      |         |-------TX--------|          |

Изменено 5 июля, 2007 пользователем Denisvak

[Mos 0]

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

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

[Kilio 0]

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

[syoma 1]

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

Или можно вести 6 проводов Земля+питание для CANа, Земля+питание для схем и CANH и CANL. Но в таком случае я как понимаю гальванической развязки между устройствами не будет, хотя передаваться будет только питание.

Или вообще не заниматься ерундой, если расстояние менее 200м?

Может кинете ссылкой, как лучше сделать развязки?

[Mos 0]

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

...вести 6 проводов Земля+питание для CANа, Земля+питание для схем и CANH и CANL. Но в таком случае я как понимаю гальванической развязки между устройствами не будет, хотя передаваться будет только питание.

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

 

Может кинете ссылкой, как лучше сделать развязки?

Реализовать развязку КЭНа красиво и дёшево НЕ возможно. Например, потому, что:

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

-если забить на скорость то сразу же встаёт другая проблема: повторитель должен принемать сигнал, преобразовывать его в своё внутреннее состояние и выдавать на остальные порты. Если кабельные сегменты, подключённые к повторителю, будут разной длинны (а иначе никому и не надо), они будут обладать разной ёмкостью, и в то время, когда все сегменты передут в рецессивное состояние после доминантного, самый высокоёмкостной ещё будет в доминантном и выставит ЛОЖНЫЙ доминантный импульс в состоянии повторителя. Вот.

[Sergey Makarov 0]

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

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

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

 

Всем добрый день!

Возникла такая задача - нужно гальванически развязать CAN шину (т.е не между контроллером и трансивером, а между трансиверами).

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

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

[galjoen 0]

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

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

А вообще, это на каком-нибудь самом дешёвом AVR с тактовой 20 мГц можно сделать. Например, ATtiny2313 или ATmega48 подойдут. Но до скорости не более 500 кбод.

[Sergey Makarov 0]

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

А вообще, это на каком-нибудь самом дешёвом AVR с тактовой 20 мГц можно сделать. Например, ATtiny2313 или ATmega48 подойдут. Но до скорости не более 500 кбод.

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

 

 

 

А мы ставили IL711 от NVE

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

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

Изменено 13 ноября, 2009 пользователем Sergey Makarov

[Седой 0]

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

А вообще, это на каком-нибудь самом дешёвом AVR с тактовой 20 мГц можно сделать. Например, ATtiny2313 или ATmega48 подойдут. Но до скорости не более 500 кбод.

На рассыпухе все прекрасно делается. (Скорость передачи и протокол не играет роли)

Но чтобы с ней не маятся, используем PLD.

PS. Логическая схема репитера изложена в каком-то из документов Cia.

PS2.Проблемы, указанные Mos, могут наблюдаться.

[galjoen 0]

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

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

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

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

На рассыпухе все прекрасно делается. (Скорость передачи и протокол не играет роли)

Но чтобы с ней не маятся, используем PLD.

PS. Логическая схема репитера изложена в каком-то из документов Cia.

PS2.Проблемы, указанные Mos, могут наблюдаться.

Да, я тоже подумал, что на самом деле это гораздо проще, чем мне сначала показалось.

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

 

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

[Itch 0]

Весь хаб:

 

Отдельный его элемент:

 

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

[Mos 0]

Лично я с большим недоверием отношусь к решениям типа КЭНовского хаба, приведённого выше. Сама идеология КЭНа, равно как и TIA/EIA-485 изначально не предусматривала повторителей физического уровня (а хаб - это частный случай такого повторителя; не важно, что он служит только для развязки). Хотя маститые конторы (типа TI, MAX и т.д.) предлагают решения данных задач, всё равно возникает куча оговорок и выглядит это всё как-то слегка СР@НО.

Приведённый выше хаб - решение для КЭНа (данное решение уже не раз мелькало на форуме, но у Cia я его не встречал (но особо и не искал)).

Для 485-ого предлагается решение на основе некоторых драйверов (не помню каких). Идея такая: если драйвер хочет выставить лог. "0", то выставляет и всё. Если лог. "1", то он выставляет этот уровень и через малый промежуток времени (типа четверти битового интервала) переходит в "Z" (это можно былобы и на контроллере сделать, при программном USARTе, путём упр. ногой DE, исп. любой драйвер, а не наворочаный).

А КЭНовский хаб должен защёлкнутся (до снятия питания)!

(тынц)

 

2 Shandy:

насчёт необходимости развязки CAN-bus:

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

 

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

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

 

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

CAN_In_Avionics__comp_a_99_A93_.pdf

[Itch 0]

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

[Aner 3]

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