Перейти к содержанию
    

Всем привет!

Читаю доку на CANOpen (далее CO) и что то плохо пока "въезжаю" в тему.

В общем интересует с чего начать то?

Как я понял имеются уже готовые решения для разного рода задач...

В целом имеется установка. На определенное время она запускается и что то делает... в целом идет замер тока,напряжения.

в ней CAN интерфейс... что,когда и как она посылает известно.

Хочу сделать девайс, который буде связан с установкой по CAN и соответственно управлять ей. Мне бы понять общий принцип... хотя бы на основе сбора данных о U и I.

 

Как я понял надо создавать словарь объектов, где будут перечислены все параметры (в моем случа ток и напруга).

Словарь объектов создается по средствам SDO. Так?

 

или я не с того начал? Как грамотно подойти к этому вопросу ? Чтение доки сильно не помогает... так как не вижу картины в целом как эта штука работает (CO).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для скорости - покупаете http://can.marathon.ru/page/devices/canbus-usb (~6000руб) комплекте идет "Интерактивный CANopen Конфигуратор" подгружаете туда eds файл(это обязательное условие) от вашего девайса и там можете посмотреть все параметры устройства и его настройки, далее смотрите все эти пакеты на канальном уровне и можете подключать свой девайс и управлять, но это при условии что на вашу установку есть eds файл (или на компоненты вашей установки).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну что вы такое говорите )) МЫ же в России... кто тут когда что либо покупал ) Я в целях образовательных интересуюсь этой штукой.

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

Изменено пользователем Chip115

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы уверены, что у Вас CanOpen, а не простая железка с CANoм? Как хоть она называется? Если это CANopenoвская железка, то на нее должен быть файл расширением eds. Возможно в инете есть, или на дисках с ней должен идти.

Или это у вас есть своя железка с CANом, а вы ее под CANopen переделать хочете?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну что вы такое говорите )) МЫ же в России... кто тут когда что либо покупал ) Я в целях образовательных интересуюсь этой штукой.

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

 

посмотрите тогда canfestival (http://www.canfestival.org/) это должно подойти в качестве примера

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можете посмотреть описание CanOpen здесь: http://robot-develop.org/archives/4110. Там же есть пример, как использовать canfestival.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну что вы такое говорите ))

вам предложили дельный совет как начать работу, причем с гуманным ценником. Я бы посоветовал ixaat или port.de

МЫ же в России... кто тут когда что либо покупал )

Ну раз в россии тогда колупайтесь сами, на пустом месте.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Всем привет!

 

Дабы не плодить темы пишу суда.

Имею те же проблемы как у топик стартера)...

 

Может кто на пальцах мне пояснить идею КанОпен?

Правильно я понимаю что

PDO и SDO, также как SYNC - это стандартные кан посылки, со специализированными ID сообщения?

 

Как назначаются PDO и SDO объектам? Есть некоторое пространство допустимых ID под тип устройства, а 2 устройства одного типа имеют под индекс? Или это верно для PDO, а SDO адресуются первыми байтами тела сообщения?

 

Вообщем мне не хватает какого то последнего шага до понимания того что происходит:)...

 

Кто то может привести пример профиля какого нить устройства? С пояснениями о PDO и SDO

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кто то может привести пример профиля какого нить устройства? С пояснениями о 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

 

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

(Хотя да, иногда неофициально "за углом" удается найти официально недешевые документы, есть и такое....)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

хаха, ок. продолжим...

 

Я не могу пока до конца ухватить концепцию протокола, потому и спросил.

На сегодняшний момент я себе протокол представляю так (если я не прав пожалуйста поправьте)

 

есть некая среда(пространство) приборов, в которой есть какие-то данные (показания приборов, состояния входов, состояния выходов и т.д....) Все эти данные собираются и отображаются какими то приборами из этой сети. Протокол задает как эти данные в среде приборов обновляются.

 

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

 

Эта кан посылка называется PDO, а идентификатор этой посылки есть RPDO, прописанное в блоке реле. Также в блоке реле есть запись какие данные из кан посылки класть в переменную.

 

тут вроде все верно. Теперь мне надо понять как тот кто хочет выставить значение реле узнает значение идентификатора? Очевидно его кто-то должен задать. Как тот кто задает обращается именно к блоку реле? У блока должен быть какой то адрес? Где то должно быть описание блоков входящих в сеть? SDO - как задаются номера SDO?

 

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

 

что значат цифры в этой таблице?

http://www.softing.com/home/en/industrial-...vanchor=3010650

 

И да еще забыл, какой минимальный состав КанОпен сети? Может она состоять из одних слейв устройств, или из одних мастер устройств? Или всегда необходимо устройство которое проинициализирует сеть? В начальный момент все узлы не различимы?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не могу пока до конца ухватить концепцию протокола, потому и спросил.

Да, протокол 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 (или наоборот) и настроить маппинг объектов у приемника и отправителя.

 

И да еще забыл, какой минимальный состав КанОпен сети? Может она состоять из одних слейв устройств, или из одних мастер устройств? Или всегда необходимо устройство которое проинициализирует сеть? В начальный момент все узлы не различимы?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

То есть в сети должен явно или не явно присутствовать конфигуратор. Не явно это когда вы взяли все элементы сети и руками настроили или провели настройку 1 раз и убрали конфигуратор. А можно его сделать навсегда и явно засунуть в сеть чтобы он сам настраивал сеть каждый раз (если она изменчива).

 

А определяется стандартом как то алгоритм конфигурации сети?? Или это как каждый сам решит? И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Это я спрашиваю на тот счет можно ли начинать с урезанной вариации стека, и наращивать ее по функционалу в будущем?

 

И еще что стандарт говорит о настоечных коэффициентах? Можно сделать в словаре область с коэффициентами калибровки, и иметь к ней доступ только через SDO?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А определяется стандартом как то алгоритм конфигурации сети?? Или это как каждый сам решит? И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Это я спрашиваю на тот счет можно ли начинать с урезанной вариации стека, и наращивать ее по функционалу в будущем?

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

Узлы не могут не поддерживать SDO, это обзательно. Вот PDO могут не поддерживать.

 

И еще что стандарт говорит о настоечных коэффициентах? Можно сделать в словаре область с коэффициентами калибровки, и иметь к ней доступ только через SDO?

Можно.

Посмотрите 401-й профиль, для начала вам его должно хватить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Узлы не могут не поддерживать SDO, это обзательно. Вот PDO могут не поддерживать.

 

 

Можно.

Посмотрите 401-й профиль, для начала вам его должно хватить.

 

А в чем сложности? Если сеть на 10 узлов, то можно 1 раз настроить и запомнить все настройки в своих узлах. В целом я и планировал сразу словарь в FRAM пихать, чтобы после настройки каждый узел мог храниться на складе до встройки в систему, я чего то упустил 6)?

 

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

 

да я 401 запросил, надеюсь пришлют. В сети я какие то огрызки нашел, их пока читаю...

 

А как по уму делают когда в сети несколько однотипных устройств а данные для них разные (цифровые индикаторы например)? Самое простое сделать им PDO единый для всех, с разным мапингом информации для каждого объекта, тогда посылаешь 1 кадр и они все его ловят, но это вроде как не по стандарту или нет?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Обычно в сети CANopen все узлы имеют встроенную EEPROM для записи своих основных параметров - типа идентификатора узла, рабочих идентификаторов PDO и т.д. Тогда конфигуратор нужен только один раз для настройки этих параметров при создании сети и больше он будет не нужен. В обычном случае, кстати, конфигуратор - это лаптоп с CAN адаптером и прогой, которая умеет уонфигурировать сеть, сохранять и восстанавливать объекты словарей локально на диске. Очень удобно. В принципе конфигуратором может выступать и один из контроллеров в сети, но тогда ему надо сохранять все словари узлов, которые он будет конфигурировать, а это куча памяти. Но сам механизм возможен.

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

А определяется стандартом как то алгоритм конфигурации сети?? Или это как каждый сам решит? И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Это я спрашиваю на тот счет можно ли начинать с урезанной вариации стека, и наращивать ее по функционалу в будущем?

Конечно определяется. И, насколько я знаю, именно SDO-сервер обязательно должен присутсвовать в любом узле согласно стандарту. Его надо в первую очередь реализовывать.

И еще что стандарт говорит о настоечных коэффициентах? Можно сделать в словаре область с коэффициентами калибровки, и иметь к ней доступ только через SDO?

Конечно можно!

 

 

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

Ну вообще-то в CANopen сети должен быть мастер - NMT. Это узел, который передает всем узлам сообщения о том, в какой режим они должны входить - preoperational, operational, stopped и.т. д.

 

Я думаю, основная проблема понимания CANоpen у всех возникает с пониманием механизма PDO, да?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...