Интерфейс CAN, Принципы обмена по протоколу CAN Опции

[denwill]

Здравствуйте уважаемые разработчики!

Прочитал много информации по данной теме:
-http://www.microchip.ru/files/d-sheets-rus/an713.pdf
-http://www.gaw.ru/html.cgi/txt/interface/can/start.htm
-Спецификации CAN 2.0 A и CAN 2.0 B
-Документация на AT90CAN128
-http://electronix.ru/forum/index.php?showtopic=12898&hl=CAN
-и др.
Но к сожалению так и не смог понять логику работы интерфейса!
Как например, раздать идентификаторы устройствам (приоритеты данных от этих устройств одинаковые)?
Как передать данные конкретному устройству (нужен ли для этого remote frame, и если да, то какой идентификатор передается в этом фрейме)?

Расчитываю на Ваш совет! Спасибо.

[ipc]

Все-таки решительно надо иметь земляной провод в идеологии 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 штук.

[ДДН]

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

А можно по-подробнее? Почему нельзя? Я не могу разве, имея контроллер с 2.0B, реализовать нужные функции CANopen программно? Сетевой уровень разве не единый?

[ipc]

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

А можно по-подробнее? Почему нельзя? Я не могу разве, имея контроллер с 2.0B, реализовать нужные функции CANopen программно? Сетевой уровень разве не единый?

Сейчас проблематично найти контроллер который неподдерживает 2.0в но я консультировался с представителями CAN-CIA и мне было ясно сказано что выпущеные на сегодняшний день спецификации касающиеся формата идентификатора(COBID) рассматривают только его 11 битное представление.
Конечно можно сделать свою 29 битную реализацию CANOpen но она непройдет сертификацию(CANOpen Conformance Test) и небудет совместима с современными программно-аппаратными средствами.Если это небеспокоит то можно делать все что угодно только называть это CANopen будет нельзя.

[Andrew2000]

К сожалению 2.0в пока нельзя использовать в CANOpen....

А можно по-подробнее? Почему нельзя? Я не могу разве, имея контроллер с 2.0B, реализовать нужные функции CANopen программно? Сетевой уровень разве не единый?

Сейчас проблематично найти контроллер который неподдерживает 2.0в но я консультировался с представителями CAN-CIA и мне было ясно сказано что выпущеные на сегодняшний день спецификации касающиеся формата идентификатора(COBID) рассматривают только его 11 битное представление.
Конечно можно сделать свою 29 битную реализацию CANOpen но она непройдет сертификацию(CANOpen Conformance Test) и небудет совместима с современными программно-аппаратными средствами.

А это не Вы писали:
"
Все поле идентификатора в соответствии со стандартом можно делить как угодно.Допустим обычно в CANOpen сети может быть до 127 устройств те под NID нужно выделить 7 бит.Остается 4 бита.Т.е прибор сможет иметь 16 разных видов пакетов с уникальными COBID.
Если сократить количество устройств до 63 то типов пакетов будет в 2 раза больше итд.
"

А вот если это "итд." растянуть на 29 бит? И что, это уже не CanOpen?
Я не говорю про профиль I/O, и то - младшие входы/выходы я буду передавать со стандартными ID, а если мое устройство поддерживает много больше входов/выходов?
Я что, не могу присвоить им (например, динамически) ID с применением 29-бит идентификаторов?
А если я создам свой собственный профиль?

А если у меня "Programmable CANopen Devices", т.е. смотрим DSP302.
Да во всех COB-ID бит 29 говорит: 0 == 11-bit ID (CAN 2.0A), 1 == 29-bit ID (CAN 2.0B)

Я, конечно, ничего не сертифицировал...
Или под сертификацие имеется ввиду только соответствие одному из профилей, которыз раз, два, и ...

[ipc]

К сожалению 2.0в пока нельзя использовать в CANOpen....

А можно по-подробнее? Почему нельзя? Я не могу разве, имея контроллер с 2.0B, реализовать нужные функции CANopen программно? Сетевой уровень разве не единый?

Сейчас проблематично найти контроллер который неподдерживает 2.0в но я консультировался с представителями CAN-CIA и мне было ясно сказано что выпущеные на сегодняшний день спецификации касающиеся формата идентификатора(COBID) рассматривают только его 11 битное представление.
Конечно можно сделать свою 29 битную реализацию CANOpen но она непройдет сертификацию(CANOpen Conformance Test) и небудет совместима с современными программно-аппаратными средствами.

А это не Вы писали:
"
Все поле идентификатора в соответствии со стандартом можно делить как угодно.Допустим обычно в CANOpen сети может быть до 127 устройств те под NID нужно выделить 7 бит.Остается 4 бита.Т.е прибор сможет иметь 16 разных видов пакетов с уникальными COBID.
Если сократить количество устройств до 63 то типов пакетов будет в 2 раза больше итд.
"

А вот если это "итд." растянуть на 29 бит? И что, это уже не CanOpen?
Я не говорю про профиль I/O, и то - младшие входы/выходы я буду передавать со стандартными ID, а если мое устройство поддерживает много больше входов/выходов?
Я что, не могу присвоить им (например, динамически) ID с применением 29-бит идентификаторов?
А если я создам свой собственный профиль?

А если у меня "Programmable CANopen Devices", т.е. смотрим DSP302.
Да во всех COB-ID бит 29 говорит: 0 == 11-bit ID (CAN 2.0A), 1 == 29-bit ID (CAN 2.0B)

Я, конечно, ничего не сертифицировал...
Или под сертификацие имеется ввиду только соответствие одному из профилей, которыз раз, два, и ...

Под стандартом CANOpen в первую очередь подразумевается соответствие профилю DS301 а под сертификацией прохождение теста устройства прогой CANOpen Conformance Test в сертификационной организации CAN-CIA и получения уникального Vendor ID(который кстати используется в LSS).Оба этих критерия и определяют можно ли на фронт панели своего девайса поставить логотип CANOpen и гордица этим до пенсии.