[ipc 0]

думаю что фронты завалятся в корягу метра через два.

LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает.

CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее...

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

 

Ну не такие уж копейки, а на километр мне тянуть не нужно, всего несколько метров. Собственно я сам за использование драйверов, дабы не создавать себе же лишние проблемы. Однако, как водится, на любой дополнительный корпус смотрят косо, и его использование нужно мотивировать :)

Ну тогда неправильно выбран интерфейс.CAN это полевая шина(название говорит само за себя) и предназначен для распределения девайсов в пространстве.Тут подошел бы ethеrnet(благо он сильно подешевел и в виде XPortа нетребует вобще никакой разработки) или вобще чтонибудь децкое типа SPI,I2c или нахудой конец проверенный веками RS-485.

[=AK= 10]

CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее...

Вопрос был как дешевле реализовать, а не как быстрее. Еще DALI можно помянуть, тоже открытый коллектор. 1200 бод на 300м, зато на любом кабеле и при любой топологии, без терминаторов. C-Bus 5 кбод на 1 км, свободная топология на любой неэкранированной витой паре.

 

А эти "50 раз быстрее", небось, требуют экранированный кабель с контролируемым волновым сопротивлением, терминаторы с обоих концов и малое кол-во узлов с макс. отводами сантиметров по 10?

[ipc 0]

CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее...

Вопрос был как дешевле реализовать, а не как быстрее. Еще DALI можно помянуть, тоже открытый коллектор. 1200 бод на 300м, зато на любом кабеле и при любой топологии, без терминаторов. C-Bus 5 кбод на 1 км, свободная топология на любой неэкранированной витой паре.

 

А эти "50 раз быстрее", небось, требуют экранированный кабель с контролируемым волновым сопротивлением, терминаторы с обоих концов и малое кол-во узлов с макс. отводами сантиметров по 10?

Да действительно нужны терминаторы(120 ом) и 60 ом сопротивление линии,хотя на нескольких метрах можно себе позволить на это забить.Но вот то что короткие отводы и экранированный кабель тут уж ничего неподелаеш.Вон то же Modbus+ так вобще еще и тапы(тройники) требует на каждый узел а уж кабель скока стоит это вобще караул.

[shans 0]

думаю что фронты завалятся в корягу метра через два.

LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает.

CAN на 40 метрах может работать в полный рост - 1Мбод при родном драйвере, это в _50_ раз быстрее...

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

 

Ну не такие уж копейки, а на километр мне тянуть не нужно, всего несколько метров. Собственно я сам за использование драйверов, дабы не создавать себе же лишние проблемы. Однако, как водится, на любой дополнительный корпус смотрят косо, и его использование нужно мотивировать :)

Ну тогда неправильно выбран интерфейс.CAN это полевая шина(название говорит само за себя) и предназначен для распределения девайсов в пространстве.Тут подошел бы ethеrnet(благо он сильно подешевел и в виде XPortа нетребует вобще никакой разработки) или вобще чтонибудь децкое типа SPI,I2c или нахудой конец проверенный веками RS-485.

 

SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов. Насчет полевой шины: интерфейс был изначально разработан для автомобильных дел. Сомневаюсь, что там километры шины :)

[ipc 0]

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

[spf 0]

SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов.

Яйцо с курицей не сравнивайте :cranky:

RS485 - физический уровень.

CAN - два уровня OSI.(аппаратный арбитраж, фильтрация пакетов и т.п.)

[shans 0]

SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов.

Яйцо с курицей не сравнивайте :cranky:

RS485 - физический уровень.

CAN - два уровня OSI.(аппаратный арбитраж, фильтрация пакетов и т.п.)

 

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

[ipc 0]

SPI, I2C не катят однозначно, а вот RS-485 тоже рассматривается как один из вариантов.

Яйцо с курицей не сравнивайте :cranky:

RS485 - физический уровень.

CAN - два уровня OSI.(аппаратный арбитраж, фильтрация пакетов и т.п.)

 

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

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

Я думаю что его использование обосновано только если присутствует один или больше из нижеперечисленных факторов.

1.Нужны сравнительно большие скорости

2.Нужно тащить данные на расстояние првышающее 10 метров

3.В сети нужна мультимастерность

4.Выбранные аппаратные средства имеют его(CAN) на борту бесплатно

5.Существует проблема с помехами

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

[dormouse 0]

"Если сравнивать RS-485 c CAN" - то это на самом деле сравнения яйца с курицей. Сравнение возможно только поле того, как разберёшься в том, что такое "CAN"... После этого пункта само слово "сравнение" будет трактоваться уже иначе.

 

Важно понять, что RS-485 без использования MODBUS или чего-то подобного есть просто "три проводка", которые соединяют аппаратные UART на двух (или более) MCU. Отличие только в несравнимо больших расстояниях и помехозащищённости. Ничего нового это не добавляет в плане качества связи, гарантированности доставки или чего-либо ещё. Это только ХОРОШИЙ способ растянуть три проводка на N метров.

 

С CAN ситуация обратная всвязи с добавлением второго уровня OSI - для программы это такой же "чёрный ящик", как и UART:

1. MSG-> bbox

2. bbox->[по шине]->bbox1, bbox2...bboxN

3. у bbox2 во время приёма возникла ошибка (он засомневался) => опять на шаг 2 *Обращаем внимание, что не на шаг 1!*

4. [раз здесь, то послали, или знаем, что не послали]

UART принципиально имеет MSG=1байт, при этом у него НЕТ средств для аппаратной реализации шагов 2 и 3.

 

!! Уже писал в свой топик. Сюда же дублирую:

----------------------------------------------------------------

Atmel сделала шаг вперёд к gcc и CAN. Конкретно: только что выложили новую версию библиотеки для At90CANxxx для gcc! Качаем, разбираемся.

Похоже, что внутри уже имеются примеры работчего "скелета" программ hello world для работы с шиной.

 

 

http://www.atmel.com/dyn/products/product_...sp?part_id=3780

-----------------------------------------------------------------

!!

[ipc 0]

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

[dormouse 0]

Все-таки решительно надо иметь земляной провод в идеологии RS-485. Это не вполне очевидно, поскольку есть много примеров дифф. линий, в которых нет "земляного" провода. В 4-х проводном варианте земля тоже одна.

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

 

to: spf. Прочёл внимательно первый пост в этой теме. Еёсли речь идёт о CAN 2.0A, то получается интересная арифметика: "Разделим CANID(11бит) на 3 секции : 5+4+4" =13 в сумме, как я понимаю?

.

Пока не довёл до конца изучение CiA 301, но уже подчерпнул много полезного. Раздел с определением полей внутри CANID пока не смотрел, поэтому не могу говорить на тему реализованного количества поддерживаемых устройств. Спасибо за указание на стандарт.

[spf 0]

to: spf. Прочёл внимательно первый пост в этой теме. Еёсли речь идёт о CAN 2.0A, то получается интересная арифметика: "Разделим CANID(11бит) на 3 секции : 5+4+4" =13 в сумме, как я понимаю?

Правильно подмечено, просчитался, так сказать на ходу сочинял вариант попроще, пользую только 2.0B.

 

PS:

Дуплексные оптоволоконные элементы слишком дороги, чаще недоступны. Поэтому CAN практически реализуется на двух волокнах -- "два проводка" ;) .

[dormouse 0]

Продолжаю разбираться с CiA 301. Меня смутил порядок следования полей. Основные варианты:

либо A:

1. P бит - ID посылающего => уже работает арбитраж

2. дальше уже неважно, поскольку один может "за раз" послать только 1 сообщение

либо B:

1. Код сообщения => первичный арбитраж по "важности" сообщения

2. ID посылающего => вторичный арбитраж по приоритету источника

3. ID приёмника - уже только для фильтрации на стороне приёмника, не участвует в арбитраже, как и п. А.2.

 

либо С: (для неравновесной системы [в смысле 3 мастера, 10 слейвов])

1. Указание мастер/слейв (или большее число групп)

2. Код

3. Оставшаяся часть ID посылающего

4. ID приёмника

 

Похоже, что реализован вариант B, поскольку предполагается, что сами по себе функциональные коды делятся на коды, возможные для 1 мастера и на коды, общие для группы слейвов (B = C при 1 мастере).

 

Я правильно понял суть?

 

Если действовать в рамках стандарта CANOpen, фактически надо реализовать часть обязательных функций от CANOpen slave, а работу на PC в качестве мастера исполняет купленная за деньги .dll на их аппаратной платформе?

[spf 0]

либо B:

1. Код сообщения => первичный арбитраж по "важности" сообщения

2. ID посылающего => вторичный арбитраж по приоритету источника

3. ID приёмника - уже только для фильтрации на стороне приёмника, не участвует в арбитраже, как и п. А.2.

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

Похоже, что реализован вариант B, поскольку предполагается, что сами по себе функциональные коды делятся на коды, возможные для 1 мастера и на коды, общие для группы слейвов (B = C при 1 мастере).

Я правильно понял суть?

Речь про мой набросок? Если да, то суть верна.

Если действовать в рамках стандарта CANOpen, фактически надо реализовать часть обязательных функций от CANOpen slave, а работу на PC в качестве мастера исполняет купленная за деньги .dll на их аппаратной платформе?

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

[ipc 0]

Все-таки решительно надо иметь земляной провод в идеологии RS-485. Это не вполне очевидно, поскольку есть много примеров дифф. линий, в которых нет "земляного" провода. В 4-х проводном варианте земля тоже одна.

 

Ну незнаю.Сколько раз делал системы на RS-485 никогда с землей особо незаморачивался.Может быть в устройствах без опторазвязки это и критично но теже айсипиконы имеют развязаное питание и драйвер запитывается через преобразователь посему про землю поданую снаружи ничего незнает.

Пока не довёл до конца изучение CiA 301, но уже подчерпнул много полезного. Раздел с определением полей внутри CANID пока не смотрел, поэтому не могу говорить на тему реализованного количества поддерживаемых устройств. Спасибо за указание на стандарт.

Там все просто но непутайте NID(node ID) и COBID.Все поле идентификатора в соответствии со стандартом можно делить как угодно.Допустим обычно в CANOpen сети может быть до 127 устройств те под NID нужно выделить 7 бит.Остается 4 бита.Т.е прибор сможет иметь 16 разных видов пакетов с уникальными COBID.

Если сократить количество устройств до 63 то типов пакетов будет в 2 раза больше итд.

Правильно подмечено, просчитался, так сказать на ходу сочинял вариант попроще, пользую только 2.0B.

К сожалению 2.0в пока нельзя использовать в CANOpen.Но организация которая занимается его стандартизацией(CIA) что то бубнила по поводу того что работы над новыми стандартами ведутся.

 

Надо помнить что аппаратный приоритет оперирует со всем полем идентификатора.И COBID выбираются таким образом чтообы более важные сообщения передавались лучше независимо от источника и получателя.Хотя конечно к примеру пакет EMERGENCY имеющий код 0x80 отправленный прибором с NID=1(COBID получится 0x80+1=0x81) будет более приоритетным чем у устройства с NID=2(COBID=0x82).Потому как в сети нет двух одинаковых приоритетов на самом деле их 2^11 штук.