[ruslannd 0]

При начале работы я использовал CAN примерно так:

 

  //входим в ресет моду
  CANGCON=0;
  while(CANGSTA & (1<<ENFG))  {} ;

 

Не понимаю смысл этого куска. ENFG никогда не будет 1, если в CANGCON записать 0. Или я ошибаюсь?

[KRS 0]

При начале работы я использовал CAN примерно так:

 

  //входим в ресет моду
  CANGCON=0;
  while(CANGSTA & (1<<ENFG))  {};

 

Не понимаю смысл этого куска. ENFG никогда не будет 1, если в CANGCON записать 0. Или я ошибаюсь?

 

если кан находится в рабочем режиме ENFG=1

когда записываем 0 в CANGCON дается команда войти в ресет моде

пока кан входит в ресет моде ENFG будет 1 надо ждать пока не станет 0

[dormouse 0]

Позволю добавить от себя ;-) Я разобрался с работой CAN за неделю. Из своего непонимания почти всё было ликвидировано. Вопрос о негарантированности доставки одному из слейвов (получателей) приобрёл другой характер:

CAN шина ГАРАНТИРУЕТ, что все приёмники РАБОТАЮЩИЕ В ЭТОТ МОМЕНТ на шине успешно получили сообщение. Никакой информации о количестве узлов, получивших сообщение НЕТ! В контексте поего предыдущего вопроса из этого можно сделать вывод, что надо после этого уметь на мастер узле принять N подтверждений о доставке (узел мог просто потерять питание!). В противном случае надо принять решение о дальнейшей работе всех устройств.

 

Сложность реализации оказалась незначительной, но до конца я пока не разобрался ( скажем, как надо распределить MOB'ы если посылающий RDF должен принять ответ на него и прочие мелочи), поскольку в данный момент после успешного испытания простейшего решения на базе "один сообщил => другой принял" работы ведутся над другими частями.

 

PS Отдельное спасибо НПП Славна (http://www.slavna.ru). Успешно получено купленное у них USB->CAN устройство. Пока не испытано.

[ipc 0]

Позволю добавить от себя ;-) Я разобрался с работой CAN за неделю. Из своего непонимания почти всё было ликвидировано. Вопрос о негарантированности доставки одному из слейвов (получателей) приобрёл другой характер:

CAN шина ГАРАНТИРУЕТ, что все приёмники РАБОТАЮЩИЕ В ЭТОТ МОМЕНТ на шине успешно получили сообщение. Никакой информации о количестве узлов, получивших сообщение НЕТ! В контексте поего предыдущего вопроса из этого можно сделать вывод, что надо после этого уметь на мастер узле принять N подтверждений о доставке (узел мог просто потерять питание!). В противном случае надо принять решение о дальнейшей работе всех устройств.

 

Сложность реализации оказалась незначительной, но до конца я пока не разобрался ( скажем, как надо распределить MOB'ы если посылающий RDF должен принять ответ на него и прочие мелочи), поскольку в данный момент после успешного испытания простейшего решения на базе "один сообщил => другой принял" работы ведутся над другими частями.

 

PS Отдельное спасибо НПП Славна (http://www.slavna.ru). Успешно получено купленное у них USB->CAN устройство. Пока не испытано.

 

Мне кажется что в данном случае имеет место попытка использовать CAN как обычный RS-485 с технологией запрос-ответ.Прелесть CANа как раз в том что проблемы целостности сети и работоспособности узлов решаются на более высоком уровне(на уровне протокола).Физическая линия гарантирует и так все на свете.Допустим в протоколе CANOpen существует по крайне мере 2 способа слежения за работой узлов это Nodeguarding и Heartbert.Первый заключается в периодичном опросе всех узлов мастером и получении их текущего статуса(режима работы) а второй заставляет slave-ы постоянно отправлять свой статус самостоятельно(из названия понятно что это как серцибиение).Кроме того в случае перезагрузки прибора он обязан отослать пакет BootUp который можно отлавливать.

В крайнем случае можно использовать RTR но это уже в чистом виде RS-485.

 

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

[kanzler 0]

Привет всем! Идейные соображения по поводу CAN меня не интересуют, такой я вот Пацак :-)

Авот в материальном плане чем смогу тем и помогу. Работал когда то я в команде которая разрабатывала Банковскую Автоматизированную Распознающую Систему. Так вот в ней все устройсва были подключены к хосту через CAN. Я уже давно там не работаю но исходники как ниского так и высого уровня есть. Может поработаем вместе. Прошу не судить строго но у меня есть свои интерсы в этом вопросе.

[ipc 0]

Привет всем! Идейные соображения по поводу CAN меня не интересуют, такой я вот Пацак :-)

Авот в материальном плане чем смогу тем и помогу. Работал когда то я в команде которая разрабатывала Банковскую Автоматизированную Распознающую Систему. Так вот в ней все устройсва были подключены к хосту через CAN. Я уже давно там не работаю но исходники как ниского так и высого уровня есть. Может поработаем вместе. Прошу не судить строго но у меня есть свои интерсы в этом вопросе.

Несовсем в тему но всетаки вопрос.А незавалялось ли с тех времен какого нибудь фирменного софта например IXXAT CANAnalizer или Vector CANErator а может быть CANOpen Conformance Test.

[dormouse 0]

Совершенно верное суждение насчёт протоколов высокого уровня. В CANOpen, DEVICENET это всё есть. Единственная сложность в том, что нет готового OpenSource верианта, если я правильно понимаю суть проблемы. Иными словами если надо использовать MODBUS/485 - пожалуйста. За час работы в сети я нашей 4 независимые реализации. Полностью все спецификации выложены на сайте и т.д. С CAN ситуация иная. Пути:

1. Иметь МНОГО времени и реализовать либо свой CANOpen

2. Иметь МНОГО денег и купить уже реализованный (как я понял, минимум $850 за библиотеку без исходников)

3. Иметь большой умный мозг и МНОГО времени - придумать некое "подмножество" протокола CANOpen и реализовать его.

4. Ограничиться самым примитивным решением - взять только DataFrame от физической части CAN и сделать только HeartBeat для гарантированности работы всего "в целом".

 

Можно даже BootUP не использовать - в некотором смысле при фиксированном наборе устройств, при отсутствии одного по HeartBeat, работа всей остальной совокупности уже невозможна. В этом смысле BootUP заменяется просто "push'ингом" HeartBeat'ов от слейвов к мастеру. Даже не требуется RDF использовать для этого, шина и так рассчитана на большую пропускную способность.

[ipc 0]

Совершенно верное суждение насчёт протоколов высокого уровня. В CANOpen, DEVICENET это всё есть. Единственная сложность в том, что нет готового OpenSource верианта, если я правильно понимаю суть проблемы. Иными словами если надо использовать MODBUS/485 - пожалуйста. За час работы в сети я нашей 4 независимые реализации. Полностью все спецификации выложены на сайте и т.д. С CAN ситуация иная. Пути:

1. Иметь МНОГО времени и реализовать либо свой CANOpen

2. Иметь МНОГО денег и купить уже реализованный (как я понял, минимум $850 за библиотеку без исходников)

3. Иметь большой умный мозг и МНОГО времени - придумать некое "подмножество" протокола CANOpen и реализовать его.

4. Ограничиться самым примитивным решением - взять только DataFrame от физической части CAN и сделать только HeartBeat для гарантированности работы всего "в целом".

 

Можно даже BootUP не использовать - в некотором смысле при фиксированном наборе устройств, при отсутствии одного по HeartBeat, работа всей остальной совокупности уже невозможна. В этом смысле BootUP заменяется просто "push'ингом" HeartBeat'ов от слейвов к мастеру. Даже не требуется RDF использовать для этого, шина и так рассчитана на большую пропускную способность.

 

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

1.Купить готовую или собрать из покупных модулей

2.Купить исходники или библиотеки для убыстрения разработки

3.Создать свою с нуля определившись с технологией,интерфейсами и протоколами

 

В результате

1.Был произведен маркетинг и сравнение существующих систем и решений

В силу ряда причин готовое решение найти неудалось и было принято решение создавать свое

2.Была выбрана распределенная технология измерения(в силу конструктивных особеностей контролируемого обьекта)

3.Было проведено сравнение полевых шин и сделан выбор(CAN по соотношению цена качество оказался на коне)

4.Было проведено сравнение протоколов и по характеристикам и количеству/качеству существующего готового(само собой платного софта) а также ареалу рапространения был выбран CANOpen

5.Был проведен анализ функциональности(по пригодности для наших задач) готовых библиотек и их стоимость а также сроков выделенных на реализацию проекта после чего было принято решение писать протокол самостоятельно.

6.Была закуплена документация(спецификации CIA),интерфейсные платы для верхнего уровня и фирменная прога(Ixxat CANOpen Studio) для первоначально проверки реализации своего протокола.

 

Для чего все это и столько заморочек.А для того чтобы система была модульной и позволяла использовать приборы нашего изготовления совместно с покупными потомучто был выбран стандартный и очень рапространенный протокол.

Решение оказалось правильным и в данное время система находится в серийном производстве.

[dormouse 0]

Тогда можно попросить указать цены на вами закупленное решение:

1. Цена на плату, на библиотеку, на документацию (примерно до +- 50$). Сайт datamicro оказался очень сложен в использовании :-)

 

В нашем случае вроде нет необходимости делать стыковку с приборами не своего изготовления, поскольку они "по сути" не применимы в данном случае. Скорее всего это будет сделано при переходе на "следующий" виток развития, если вообще будет сделано. На данном этапе скорее всего будет доделана работа с CAN на основе At90CAN128 (примерно шесть экземпляров на одну систему), сбор данных температуры и прочего осуществляется по Dallas 1-wire, а самый дешёвый датчик с CANOpen стоил почти 800euro, что пока излишне ;-)

В качестве USB-PC будет устройство от slavna.ru - они предоставляют "каркас" программы на VC, так что можно очень быстро начать его использовать, поскольку код на C портируется с MCU без изменений, только интерфейсная часть будет другой.

[ipc 0]

Плата IXXAT USBtoCAN(2 канала с опторазвязкой) ~250 евро

Плата IXXAT USBtoCAN compact (1 канал с опторазвязкой) ~200 евро

Плата Adlink 7841 (два канал с опторазвякой) ~150 евро

CANOpen Configuration Studio ~1000 баксов(точно непомню)

СANOpen CIA Standart 200 евро + годовая подписка

 

Столько плат было нужно для разных целей,USB для использования с командировочными ноутбуками(и фирменным софтом) а PCI для рабочих станций на которых ведется калибровка и настройка приборов.

 

Средняя стоимость прибора(1-2ух канальных) получилась 200 баксов.

При выпуске около 2000 штук.

[dormouse 0]

Цена действительно оказалась более чем приемлемой. Я полагал примерно 2x-4x диапазон. При этом раскладе это <$1500 для начала работы, что приемлимо даже для личной разработки.

 

Осталось разобраться в следующем: физически CANOpen - это только data frame, которые ходят по шине. Никакая конкретика непосредственной физической реализации аппаратного уровня его не интересуют. Из этого можно сделать вывод, что и код на C должен быть одинаковым как для PC карты, так и для MCU. У них же (если я правильно понимаю) предлагается отдельно "стандарт" и отдельно "он же реализованный под Win32 с закрытым кодом", отдельно "софт мониторирования пакетов и проверки соответствия работы устройства стандарту", ну и платы, разумееется.

 

Если внимательно посмотреть на это, то вместо их библиотеки можно было бы использовать C версию кода, но они его не предоставляю. Я правильно понимаю ситуацию, что фактически надо реализовать 80% их библиотеки, являющейся кросс-платформенной, в каждом проекте?

 

Нешёл очень интересный сайт с большим чилом БЕСПЛАТНОГО софта (ограниченного на 125к/бит и временем работы), называется port.de. http://www.port.de/engl/canprod/content/software.html

Пока не ясно, но возможно, что предлагают недорогую кросс-платформенную реализацию на С.

Изменено 5 апреля, 2006 пользователем dormouse

[ipc 0]

Цена действительно оказалась более чем приемлемой. Я полагал примерно 2x-4x диапазон. При этом раскладе это <$1500 для начала работы, что приемлимо даже для личной разработки.

 

Осталось разобраться в следующем: физически CANOpen - это только data frame, которые ходят по шине. Никакая конкретика непосредственной физической реализации аппаратного уровня его не интересуют. Из этого можно сделать вывод, что и код на C должен быть одинаковым как для PC карты, так и для MCU. У них же (если я правильно понимаю) предлагается отдельно "стандарт" и отдельно "он же реализованный под Win32 с закрытым кодом", отдельно "софт мониторирования пакетов и проверки соответствия работы устройства стандарту", ну и платы, разумееется.

 

Если внимательно посмотреть на это, то вместо их библиотеки можно было бы использовать C версию кода, но они его не предоставляю. Я правильно понимаю ситуацию, что фактически надо реализовать 80% их библиотеки, являющейся кросс-платформенной, в каждом проекте?

 

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

Но есть небольшой нюанс.Обычно в приборах реализуют CANOpen Slave а на PC CANOpenSlave+CANOpenMaster.Мастер как таковой очень громоздок и реализовать его в полном обьеме внутри микроконтроллера из среднего ценового дивапазона проблематично.То же касается готовых библиотек и патентованых кроссплатформенных исходников.Сами продавцы пишут что только CANOpen практически на любой платформе займет не менее 64K(это плата за универсальность).В моем случае узкоспециализированный и конкретно заточеный CANOpen(с приличной функциональностью) около 10Кслов(вместе со словарем).

Вобще CANOpen неоднородная вещь.Это набор подпротоколов(те вариантов обмена) которые используются для разных целей.Например.

SDO-протокол для конфигурационного обмена

PDO-протокол для обмена данными

NMT-протокол для управлению сетью и состоянием узлов

LSS и LMT -протоколы для раздачи идентификаторов(NID Node ID) и смены скорости сети.

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

 

Что действительно ненравица так это алчность рапростаранителей стандартов,библиотек и ПО для настройки и проверки,они все как сговорились,цена на исходники доходит до 10 килотугриков.

Кстати я где то видел аппаратное(кстати недорогое) решение CANOpen в микросхеме(можно порыть в интеренте).

 

Вот кароче бесплатная дока по CANOpen кому интересно можете почитать

 

Что касается ресурсов.

Фирма Port предлагает много но вот купить это у нас проблематично.

Лучше смотреть на http://www.vector-cantech.com/ и www.ixxat.com

DS301.pdf

[ruslannd 0]

При начале работы я использовал CAN примерно так:

 

  //входим в ресет моду
  CANGCON=0;
  while(CANGSTA & (1<<ENFG))  {};

 

Не понимаю смысл этого куска. ENFG никогда не будет 1, если в CANGCON записать 0. Или я ошибаюсь?

 

если кан находится в рабочем режиме ENFG=1

когда записываем 0 в CANGCON дается команда войти в ресет моде

пока кан входит в ресет моде ENFG будет 1 надо ждать пока не станет 0

 

Сорри. Облажался. С CAN контроллером разобрался. Все работает, только у Atmel'a даташит не достаточно детальный.

[dormouse 0]

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

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

 

 

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

[zltigo 0]

PS Отдельное спасибо НПП Славна (http://www.slavna.ru). Успешно получено купленное у них USB->CAN устройство. Пока не испытано.

Присоединяюсь, получены и испытаны два экземпляра. Проблем не обнаружено.

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