Chip115 0 14 ноября, 2011 Опубликовано 14 ноября, 2011 · Жалоба Всем привет! Читаю доку на CANOpen (далее CO) и что то плохо пока "въезжаю" в тему. В общем интересует с чего начать то? Как я понял имеются уже готовые решения для разного рода задач... В целом имеется установка. На определенное время она запускается и что то делает... в целом идет замер тока,напряжения. в ней CAN интерфейс... что,когда и как она посылает известно. Хочу сделать девайс, который буде связан с установкой по CAN и соответственно управлять ей. Мне бы понять общий принцип... хотя бы на основе сбора данных о U и I. Как я понял надо создавать словарь объектов, где будут перечислены все параметры (в моем случа ток и напруга). Словарь объектов создается по средствам SDO. Так? или я не с того начал? Как грамотно подойти к этому вопросу ? Чтение доки сильно не помогает... так как не вижу картины в целом как эта штука работает (CO). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
garry_ 0 14 ноября, 2011 Опубликовано 14 ноября, 2011 · Жалоба Для скорости - покупаете http://can.marathon.ru/page/devices/canbus-usb (~6000руб) комплекте идет "Интерактивный CANopen Конфигуратор" подгружаете туда eds файл(это обязательное условие) от вашего девайса и там можете посмотреть все параметры устройства и его настройки, далее смотрите все эти пакеты на канальном уровне и можете подключать свой девайс и управлять, но это при условии что на вашу установку есть eds файл (или на компоненты вашей установки). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Chip115 0 15 ноября, 2011 Опубликовано 15 ноября, 2011 (изменено) · Жалоба Ну что вы такое говорите )) МЫ же в России... кто тут когда что либо покупал ) Я в целях образовательных интересуюсь этой штукой. Я тут пошарил и обнаружил что почему то нет примеров по CANOpen... везде сухая документация. Может у кого нить есть пример ... скажем мигания светодиода... тока управление через CAN. ? мне нужен какой нить простенький проект что бы поковыряться в нем. может станет более понятно Изменено 15 ноября, 2011 пользователем Chip115 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 15 ноября, 2011 Опубликовано 15 ноября, 2011 · Жалоба Вы уверены, что у Вас CanOpen, а не простая железка с CANoм? Как хоть она называется? Если это CANopenoвская железка, то на нее должен быть файл расширением eds. Возможно в инете есть, или на дисках с ней должен идти. Или это у вас есть своя железка с CANом, а вы ее под CANopen переделать хочете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
garry_ 0 15 ноября, 2011 Опубликовано 15 ноября, 2011 · Жалоба Ну что вы такое говорите )) МЫ же в России... кто тут когда что либо покупал ) Я в целях образовательных интересуюсь этой штукой. Я тут пошарил и обнаружил что почему то нет примеров по CANOpen... везде сухая документация. Может у кого нить есть пример ... скажем мигания светодиода... тока управление через CAN. ? мне нужен какой нить простенький проект что бы поковыряться в нем. может станет более понятно посмотрите тогда canfestival (http://www.canfestival.org/) это должно подойти в качестве примера Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dasg 0 20 марта, 2012 Опубликовано 20 марта, 2012 · Жалоба Можете посмотреть описание CanOpen здесь: http://robot-develop.org/archives/4110. Там же есть пример, как использовать canfestival. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 9 20 марта, 2012 Опубликовано 20 марта, 2012 · Жалоба Ну что вы такое говорите )) вам предложили дельный совет как начать работу, причем с гуманным ценником. Я бы посоветовал ixaat или port.de МЫ же в России... кто тут когда что либо покупал ) Ну раз в россии тогда колупайтесь сами, на пустом месте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 3 ноября, 2012 Опубликовано 3 ноября, 2012 · Жалоба Всем привет! Дабы не плодить темы пишу суда. Имею те же проблемы как у топик стартера)... Может кто на пальцах мне пояснить идею КанОпен? Правильно я понимаю что PDO и SDO, также как SYNC - это стандартные кан посылки, со специализированными ID сообщения? Как назначаются PDO и SDO объектам? Есть некоторое пространство допустимых ID под тип устройства, а 2 устройства одного типа имеют под индекс? Или это верно для PDO, а SDO адресуются первыми байтами тела сообщения? Вообщем мне не хватает какого то последнего шага до понимания того что происходит:)... Кто то может привести пример профиля какого нить устройства? С пояснениями о PDO и SDO Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 3 ноября, 2012 Опубликовано 3 ноября, 2012 · Жалоба Кто то может привести пример профиля какого нить устройства? С пояснениями о 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 Можно еще зайти на официальный сайт и даже зарегистрироваться там для доступа к официальным данным по актуальной документации, профилям и прочему, но кто же этим путем пользуется, разве что совсем ламеры.... (Хотя да, иногда неофициально "за углом" удается найти официально недешевые документы, есть и такое....) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 3 ноября, 2012 Опубликовано 3 ноября, 2012 · Жалоба хаха, ок. продолжим... Я не могу пока до конца ухватить концепцию протокола, потому и спросил. На сегодняшний момент я себе протокол представляю так (если я не прав пожалуйста поправьте) есть некая среда(пространство) приборов, в которой есть какие-то данные (показания приборов, состояния входов, состояния выходов и т.д....) Все эти данные собираются и отображаются какими то приборами из этой сети. Протокол задает как эти данные в среде приборов обновляются. Есть допустим блок реле, в нем есть переменное с состоянием выходов, и блок реле это состояние выставляет. Есть кан посылка с каким то идентификатором, которая несет в себе значение этой переменной, при прохождении этой посылки по сети, блок реле ее ловит, и задает значение состояния, и соотвествено выставляет нужные реле. Эта кан посылка называется PDO, а идентификатор этой посылки есть RPDO, прописанное в блоке реле. Также в блоке реле есть запись какие данные из кан посылки класть в переменную. тут вроде все верно. Теперь мне надо понять как тот кто хочет выставить значение реле узнает значение идентификатора? Очевидно его кто-то должен задать. Как тот кто задает обращается именно к блоку реле? У блока должен быть какой то адрес? Где то должно быть описание блоков входящих в сеть? SDO - как задаются номера SDO? Я как то не могу уловить концепцию, если ее кто изложит, буду очень благодарен, пусть скомкано или кратко, я уточню непонятные моменты, но хотя бы я сдвинусь с места. Пока что я вижу какие то наборы цифр, которые называют объектами, а вот как получается конкретная кан посылка я не понимаю... что значат цифры в этой таблице? http://www.softing.com/home/en/industrial-...vanchor=3010650 И да еще забыл, какой минимальный состав КанОпен сети? Может она состоять из одних слейв устройств, или из одних мастер устройств? Или всегда необходимо устройство которое проинициализирует сеть? В начальный момент все узлы не различимы? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 9 4 ноября, 2012 Опубликовано 4 ноября, 2012 · Жалоба Я не могу пока до конца ухватить концепцию протокола, потому и спросил. Да, протокол 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 (или наоборот) и настроить маппинг объектов у приемника и отправителя. И да еще забыл, какой минимальный состав КанОпен сети? Может она состоять из одних слейв устройств, или из одних мастер устройств? Или всегда необходимо устройство которое проинициализирует сеть? В начальный момент все узлы не различимы? В протоколе нет обязательного мастера сети. Сеть может состояить из одних слейвов если они сконфигурированы надлежащим образом. Как будет выполняться конфигурирование это решает разработчик. Может забить в прошивку, может запускать конфигуратор при старте а может написать полноценный мастер который будет централизовано собирать данные со всех устройств. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 4 ноября, 2012 Опубликовано 4 ноября, 2012 · Жалоба То есть в сети должен явно или не явно присутствовать конфигуратор. Не явно это когда вы взяли все элементы сети и руками настроили или провели настройку 1 раз и убрали конфигуратор. А можно его сделать навсегда и явно засунуть в сеть чтобы он сам настраивал сеть каждый раз (если она изменчива). А определяется стандартом как то алгоритм конфигурации сети?? Или это как каждый сам решит? И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Это я спрашиваю на тот счет можно ли начинать с урезанной вариации стека, и наращивать ее по функционалу в будущем? И еще что стандарт говорит о настоечных коэффициентах? Можно сделать в словаре область с коэффициентами калибровки, и иметь к ней доступ только через SDO? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 9 4 ноября, 2012 Опубликовано 4 ноября, 2012 · Жалоба А определяется стандартом как то алгоритм конфигурации сети?? Или это как каждый сам решит? И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Это я спрашиваю на тот счет можно ли начинать с урезанной вариации стека, и наращивать ее по функционалу в будущем? Методы конфигурирования я глубоко не копал. В моем случае есть постоянно функционирующий конфигуратор (фактически мастер). Сложности начнутся если захочется постороить сеть где текущая конфигурация загружается в eeprom всех устройств чтобы получить автономно работающую децентрализованную систему. Узлы не могут не поддерживать SDO, это обзательно. Вот PDO могут не поддерживать. И еще что стандарт говорит о настоечных коэффициентах? Можно сделать в словаре область с коэффициентами калибровки, и иметь к ней доступ только через SDO? Можно. Посмотрите 401-й профиль, для начала вам его должно хватить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 4 ноября, 2012 Опубликовано 4 ноября, 2012 · Жалоба Сложности начнутся если захочется постороить сеть где текущая конфигурация загружается в eeprom всех устройств чтобы получить автономно работающую децентрализованную систему. Узлы не могут не поддерживать SDO, это обзательно. Вот PDO могут не поддерживать. Можно. Посмотрите 401-й профиль, для начала вам его должно хватить. А в чем сложности? Если сеть на 10 узлов, то можно 1 раз настроить и запомнить все настройки в своих узлах. В целом я и планировал сразу словарь в FRAM пихать, чтобы после настройки каждый узел мог храниться на складе до встройки в систему, я чего то упустил 6)? SDO по стандарту нужно, но в целом я так понимаю что сеть может функционировать все время без единого SDO обмена... да я 401 запросил, надеюсь пришлют. В сети я какие то огрызки нашел, их пока читаю... А как по уму делают когда в сети несколько однотипных устройств а данные для них разные (цифровые индикаторы например)? Самое простое сделать им PDO единый для всех, с разным мапингом информации для каждого объекта, тогда посылаешь 1 кадр и они все его ловят, но это вроде как не по стандарту или нет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 4 ноября, 2012 Опубликовано 4 ноября, 2012 · Жалоба Обычно в сети CANopen все узлы имеют встроенную EEPROM для записи своих основных параметров - типа идентификатора узла, рабочих идентификаторов PDO и т.д. Тогда конфигуратор нужен только один раз для настройки этих параметров при создании сети и больше он будет не нужен. В обычном случае, кстати, конфигуратор - это лаптоп с CAN адаптером и прогой, которая умеет уонфигурировать сеть, сохранять и восстанавливать объекты словарей локально на диске. Очень удобно. В принципе конфигуратором может выступать и один из контроллеров в сети, но тогда ему надо сохранять все словари узлов, которые он будет конфигурировать, а это куча памяти. Но сам механизм возможен. И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? А определяется стандартом как то алгоритм конфигурации сети?? Или это как каждый сам решит? И означает ли это что в целом узлы могут не поддерживать SDO, и для полностью в ручную сконфигурированной сети это никогда и не вылезет? Это я спрашиваю на тот счет можно ли начинать с урезанной вариации стека, и наращивать ее по функционалу в будущем? Конечно определяется. И, насколько я знаю, именно SDO-сервер обязательно должен присутсвовать в любом узле согласно стандарту. Его надо в первую очередь реализовывать. И еще что стандарт говорит о настоечных коэффициентах? Можно сделать в словаре область с коэффициентами калибровки, и иметь к ней доступ только через SDO? Конечно можно! В протоколе нет обязательного мастера сети. Сеть может состояить из одних слейвов если они сконфигурированы надлежащим образом. Как будет выполняться конфигурирование это решает разработчик. Ну вообще-то в CANopen сети должен быть мастер - NMT. Это узел, который передает всем узлам сообщения о том, в какой режим они должны входить - preoperational, operational, stopped и.т. д. Я думаю, основная проблема понимания CANоpen у всех возникает с пониманием механизма PDO, да? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться