|
CANOpen, С чего начать? |
|
|
|
Nov 14 2011, 19:42
|
Частый гость
 
Группа: Свой
Сообщений: 85
Регистрация: 22-06-04
Из: Moscow
Пользователь №: 105

|
Для скорости - покупаете http://can.marathon.ru/page/devices/canbus-usb (~6000руб) комплекте идет "Интерактивный CANopen Конфигуратор" подгружаете туда eds файл(это обязательное условие) от вашего девайса и там можете посмотреть все параметры устройства и его настройки, далее смотрите все эти пакеты на канальном уровне и можете подключать свой девайс и управлять, но это при условии что на вашу установку есть eds файл (или на компоненты вашей установки).
|
|
|
|
|
Nov 15 2011, 10:28
|
Частый гость
 
Группа: Свой
Сообщений: 85
Регистрация: 22-06-04
Из: Moscow
Пользователь №: 105

|
QUOTE (Chip115 @ Nov 15 2011, 13:15)  Ну что вы такое говорите )) МЫ же в России... кто тут когда что либо покупал ) Я в целях образовательных интересуюсь этой штукой. Я тут пошарил и обнаружил что почему то нет примеров по CANOpen... везде сухая документация. Может у кого нить есть пример ... скажем мигания светодиода... тока управление через CAN. ? мне нужен какой нить простенький проект что бы поковыряться в нем. может станет более понятно посмотрите тогда canfestival (http://www.canfestival.org/) это должно подойти в качестве примера
|
|
|
|
|
Mar 20 2012, 14:28
|
Группа: Новичок
Сообщений: 1
Регистрация: 20-03-12
Пользователь №: 70 908

|
Можете посмотреть описание CanOpen здесь: http://robot-develop.org/archives/4110. Там же есть пример, как использовать canfestival.
|
|
|
|
|
Mar 20 2012, 18:56
|
Знающий
   
Группа: Участник
Сообщений: 745
Регистрация: 28-12-06
Пользователь №: 23 960

|
Цитата(Chip115 @ Nov 15 2011, 13:15)  Ну что вы такое говорите )) вам предложили дельный совет как начать работу, причем с гуманным ценником. Я бы посоветовал ixaat или port.de Цитата МЫ же в России... кто тут когда что либо покупал ) Ну раз в россии тогда колупайтесь сами, на пустом месте.
|
|
|
|
|
Nov 3 2012, 14:41
|
Гуру
     
Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454

|
Всем привет! Дабы не плодить темы пишу суда. Имею те же проблемы как у топик стартера)... Может кто на пальцах мне пояснить идею КанОпен? Правильно я понимаю что PDO и SDO, также как SYNC - это стандартные кан посылки, со специализированными ID сообщения? Как назначаются PDO и SDO объектам? Есть некоторое пространство допустимых ID под тип устройства, а 2 устройства одного типа имеют под индекс? Или это верно для PDO, а SDO адресуются первыми байтами тела сообщения? Вообщем мне не хватает какого то последнего шага до понимания того что происходит  ... Кто то может привести пример профиля какого нить устройства? С пояснениями о PDO и SDO
|
|
|
|
|
Nov 3 2012, 15:16
|
Гуру
     
Группа: Свой
Сообщений: 2 360
Регистрация: 6-03-06
Из: Кишинев
Пользователь №: 15 025

|
Цитата(Golikov A. @ Nov 3 2012, 16:41)  Кто то может привести пример профиля какого нить устройства? С пояснениями о PDO и SDO Если Вы имеете выход на google, попробуйте набрать что-то типа "CanOpen xxxx",где xxx заменяете на любимый вами вид приборов. Например, вот первые внятные описания, которые вывалились при запросе "CANopen inclinometer" http://www.turck-usa.com/illustrations/Inc...en%20Manual.pdfЕще тут красиво разрисовано http://www.softing.com/home/en/industrial-...vanchor=3010587Можно еще зайти на официальный сайт и даже зарегистрироваться там для доступа к официальным данным по актуальной документации, профилям и прочему, но кто же этим путем пользуется, разве что совсем ламеры.... (Хотя да, иногда неофициально "за углом" удается найти официально недешевые документы, есть и такое....)
|
|
|
|
|
Nov 3 2012, 17:30
|
Гуру
     
Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454

|
хаха, ок. продолжим... Я не могу пока до конца ухватить концепцию протокола, потому и спросил. На сегодняшний момент я себе протокол представляю так (если я не прав пожалуйста поправьте) есть некая среда(пространство) приборов, в которой есть какие-то данные (показания приборов, состояния входов, состояния выходов и т.д....) Все эти данные собираются и отображаются какими то приборами из этой сети. Протокол задает как эти данные в среде приборов обновляются. Есть допустим блок реле, в нем есть переменное с состоянием выходов, и блок реле это состояние выставляет. Есть кан посылка с каким то идентификатором, которая несет в себе значение этой переменной, при прохождении этой посылки по сети, блок реле ее ловит, и задает значение состояния, и соотвествено выставляет нужные реле. Эта кан посылка называется PDO, а идентификатор этой посылки есть RPDO, прописанное в блоке реле. Также в блоке реле есть запись какие данные из кан посылки класть в переменную. тут вроде все верно. Теперь мне надо понять как тот кто хочет выставить значение реле узнает значение идентификатора? Очевидно его кто-то должен задать. Как тот кто задает обращается именно к блоку реле? У блока должен быть какой то адрес? Где то должно быть описание блоков входящих в сеть? SDO - как задаются номера SDO? Я как то не могу уловить концепцию, если ее кто изложит, буду очень благодарен, пусть скомкано или кратко, я уточню непонятные моменты, но хотя бы я сдвинусь с места. Пока что я вижу какие то наборы цифр, которые называют объектами, а вот как получается конкретная кан посылка я не понимаю... что значат цифры в этой таблице? http://www.softing.com/home/en/industrial-...vanchor=3010650И да еще забыл, какой минимальный состав КанОпен сети? Может она состоять из одних слейв устройств, или из одних мастер устройств? Или всегда необходимо устройство которое проинициализирует сеть? В начальный момент все узлы не различимы?
|
|
|
|
|
Nov 4 2012, 10:06
|
Знающий
   
Группа: Участник
Сообщений: 745
Регистрация: 28-12-06
Пользователь №: 23 960

|
Цитата(Golikov A. @ Nov 3 2012, 21:30)  Я не могу пока до конца ухватить концепцию протокола, потому и спросил. Да, протокол canopen надо долго вкуривать. Цитата есть некая среда(пространство) приборов, в которой есть какие-то данные (показания приборов, состояния входов, состояния выходов и т.д....) Все эти данные собираются и отображаются какими то приборами из этой сети. Протокол задает как эти данные в среде приборов обновляются. То что вы описали - объектный словрь в теминах канопен. Объектный словарь содержит все данные прибора (как физичекие так и виртуальные). Информация которой нет в объектном словаре посредством протокола канопен недоступна. Доступ к любому объекту из словаря осуществляется посредством SDO. Объекты идентифицируется по 16-разрядному Index и 8-разрядному subindex. Поскольку SDO позволяет обращатся ко всему объектному словарю он довольно тяжеловесен и как правило используется для настройки параметров. Данные рабочего процесса передаются по другому - см. ниже. Цитата Есть допустим блок реле, в нем есть переменное с состоянием выходов, и блок реле это состояние выставляет. Есть кан посылка с каким то идентификатором, которая несет в себе значение этой переменной, при прохождении этой посылки по сети, блок реле ее ловит, и задает значение состояния, и соотвествено выставляет нужные реле. Эта кан посылка называется PDO, а идентификатор этой посылки есть RPDO, прописанное в блоке реле. Также в блоке реле есть запись какие данные из кан посылки класть в переменную. Правильно. Это еще одна сущность, она называется PDO (process data object). PDO это пакеты кан с предопределенным COB-ID. Данные в пакетах содержат один или несколько объектов словаря (еще раз напомню что в канопен не существует данных не представленных в словаре). Какие именно объекты входят в PDO задается при конфигурировании устройства или предопределено в прошивке. Количество объектов ограничено размером поля данных пакета кан - 8 байт. PDO могут быть как приемные так и передающие: RPDO и TPDO. первые помещают пришедшие извне данные в объектный словарь а вторые наоборот передают. Стандарт по умолчанию предусматривает по 4 PDO для устройства: 4 RPDO и 4 TPDO, для них предопределены уникальные COD-ID которые генрируются на основе node id. Если надо больше PDO конфигуратор сети должен найти неиспользуемые в сети COB-ID и присвоить их дополнительым PDO. Цитата тут вроде все верно. Теперь мне надо понять как тот кто хочет выставить значение реле узнает значение идентификатора? Очевидно его кто-то должен задать. Как тот кто задает обращается именно к блоку реле? У блока должен быть какой то адрес? Где то должно быть описание блоков входящих в сеть? SDO - как задаются номера SDO? Если требуется соединить TPDO и RPDO нужно чтобы у них были идентичные COB-ID и состав объектов. Конфигуратор сти должен задать COB-ID для RPDO идентичным COB-ID TPDO (или наоборот) и настроить маппинг объектов у приемника и отправителя. Цитата И да еще забыл, какой минимальный состав КанОпен сети? Может она состоять из одних слейв устройств, или из одних мастер устройств? Или всегда необходимо устройство которое проинициализирует сеть? В начальный момент все узлы не различимы? В протоколе нет обязательного мастера сети. Сеть может состояить из одних слейвов если они сконфигурированы надлежащим образом. Как будет выполняться конфигурирование это решает разработчик. Может забить в прошивку, может запускать конфигуратор при старте а может написать полноценный мастер который будет централизовано собирать данные со всех устройств.
|
|
|
|
|
Nov 4 2012, 20:25
|
Знающий
   
Группа: Участник
Сообщений: 745
Регистрация: 28-12-06
Пользователь №: 23 960

|
Цитата(Golikov A. @ Nov 4 2012, 15:31)  А определяется стандартом как то алгоритм конфигурации сети?? Или это как каждый сам решит? И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Это я спрашиваю на тот счет можно ли начинать с урезанной вариации стека, и наращивать ее по функционалу в будущем? Методы конфигурирования я глубоко не копал. В моем случае есть постоянно функционирующий конфигуратор (фактически мастер). Сложности начнутся если захочется постороить сеть где текущая конфигурация загружается в eeprom всех устройств чтобы получить автономно работающую децентрализованную систему. Узлы не могут не поддерживать SDO, это обзательно. Вот PDO могут не поддерживать. Цитата И еще что стандарт говорит о настоечных коэффициентах? Можно сделать в словаре область с коэффициентами калибровки, и иметь к ней доступ только через SDO? Можно. Посмотрите 401-й профиль, для начала вам его должно хватить.
|
|
|
|
|
Nov 4 2012, 21:01
|
Гуру
     
Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454

|
Цитата(_3m @ Nov 5 2012, 00:25)  Сложности начнутся если захочется постороить сеть где текущая конфигурация загружается в eeprom всех устройств чтобы получить автономно работающую децентрализованную систему.
Узлы не могут не поддерживать SDO, это обзательно. Вот PDO могут не поддерживать.
Можно. Посмотрите 401-й профиль, для начала вам его должно хватить. А в чем сложности? Если сеть на 10 узлов, то можно 1 раз настроить и запомнить все настройки в своих узлах. В целом я и планировал сразу словарь в FRAM пихать, чтобы после настройки каждый узел мог храниться на складе до встройки в систему, я чего то упустил 6)? SDO по стандарту нужно, но в целом я так понимаю что сеть может функционировать все время без единого SDO обмена... да я 401 запросил, надеюсь пришлют. В сети я какие то огрызки нашел, их пока читаю... А как по уму делают когда в сети несколько однотипных устройств а данные для них разные (цифровые индикаторы например)? Самое простое сделать им PDO единый для всех, с разным мапингом информации для каждого объекта, тогда посылаешь 1 кадр и они все его ловят, но это вроде как не по стандарту или нет?
|
|
|
|
|
Nov 4 2012, 21:16
|
Профессионал
    
Группа: Свой
Сообщений: 1 817
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368

|
Обычно в сети CANopen все узлы имеют встроенную EEPROM для записи своих основных параметров - типа идентификатора узла, рабочих идентификаторов PDO и т.д. Тогда конфигуратор нужен только один раз для настройки этих параметров при создании сети и больше он будет не нужен. В обычном случае, кстати, конфигуратор - это лаптоп с CAN адаптером и прогой, которая умеет уонфигурировать сеть, сохранять и восстанавливать объекты словарей локально на диске. Очень удобно. В принципе конфигуратором может выступать и один из контроллеров в сети, но тогда ему надо сохранять все словари узлов, которые он будет конфигурировать, а это куча памяти. Но сам механизм возможен. И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Цитата А определяется стандартом как то алгоритм конфигурации сети?? Или это как каждый сам решит? И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Это я спрашиваю на тот счет можно ли начинать с урезанной вариации стека, и наращивать ее по функционалу в будущем? Конечно определяется. И, насколько я знаю, именно SDO-сервер обязательно должен присутсвовать в любом узле согласно стандарту. Его надо в первую очередь реализовывать. Цитата И еще что стандарт говорит о настоечных коэффициентах? Можно сделать в словаре область с коэффициентами калибровки, и иметь к ней доступ только через SDO? Конечно можно! Цитата В протоколе нет обязательного мастера сети. Сеть может состояить из одних слейвов если они сконфигурированы надлежащим образом. Как будет выполняться конфигурирование это решает разработчик. Ну вообще-то в CANopen сети должен быть мастер - NMT. Это узел, который передает всем узлам сообщения о том, в какой режим они должны входить - preoperational, operational, stopped и.т. д. Я думаю, основная проблема понимания CANоpen у всех возникает с пониманием механизма PDO, да?
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|