Всем привет!
Читаю доку на CANOpen (далее CO) и что то плохо пока "въезжаю" в тему.
В общем интересует с чего начать то?
Как я понял имеются уже готовые решения для разного рода задач...
В целом имеется установка. На определенное время она запускается и что то делает... в целом идет замер тока,напряжения.
в ней CAN интерфейс... что,когда и как она посылает известно.
Хочу сделать девайс, который буде связан с установкой по CAN и соответственно управлять ей. Мне бы понять общий принцип... хотя бы на основе сбора данных о U и I.

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

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

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

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

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

посмотрите тогда 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

Если Вы имеете выход на 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 (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.



Если требуется соединить TPDO и RPDO нужно чтобы у них были идентичные COB-ID и состав объектов. Конфигуратор сти должен задать COB-ID для RPDO идентичным COB-ID TPDO (или наоборот) и настроить маппинг объектов у приемника и отправителя.


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

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

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

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

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


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

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

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

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

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

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

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

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



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

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

Ну да SDO реализовать просто, проще чем сразу продумывать какие PDO куда...

А кто в сети переводи устройства из режима преоператед, в оператед? Стандарты официальные придут не скоро(

Кстати стандарт CANopen есть на местном FTP. Правда с тех пор уже куча стандартов доступна для свободного доступа. Не бойтесь на CAN-CIA спрашивать. Они в течении пары дней свободные стандарты высылают, если данные правдивые написали.

Написал в предыдущем сообщении.

Любой узел способный выдать NMT команды (там всего 2 байта). На самом деле поностью отказаться от конфигуратора проблематично. Кто то все равно должен следить за всеми устройствами как минимум для реакциии на внезапный "отвал" какого либо из узлов. Все пакеты в кан широковещательные и посылающий узел не узнает что тот кому адресован пакет его уже не слышит.
В этом отношении запросы к SDO серверу лучше поскольку они идут с подтверждением. Т.е выдавать команду на подрыв лучше через SDO.
DS301 в сети находится без проблем, а это один из основных документов.

Угу я запросил доки, поглядим...

Да у меня есть один опасный момент где хорошо бы знать что все кто надо все что надо сделали. Думал делать его через запросы PDO, вроде бы есть такая возможность, или же вообще на SYNC всем опасным устройствам повесить выдачу реального состояния выводов, и просто послать синк посылку чтобы они все выдали в каком они реально состоянии или лучше такое через SDO делать?

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

Значит придется еще NMT устройство назначить....

ой сдублировалось

Тут надо думать о вашей конктерной задаче.
Вы получаете опасные данные или посылаете их?
Если данные по SYNC только получаются то факт прихода всех ожидаемых PDO можно проконтролировать. Если какое-то не пришло - реагировать, впрочем реакция на отсутствие PDO протоколом не регламентирована. Если читать через SDO то неответ сервера на запрос это штатная ошибка для SDO в canopen. Но SDO работает медленнее чем PDO, нужно учитывать ваш темп получения данных.
Если вы данные передаете то для TPDO отправитель никак не может узнать дошли они или нет. Если посылающий узел должен быть уверен что полчатель данные принял - только SDO.
Про Remote frame сразу забудьте. CiA в рекомендациях настоятельно советует избегать применения Remote frame.

Странно, ремот фрейм есть, и вроде бы даже я в стандарте видел что есть ремот PDO, а просят избегать, ну да ладно, просят будем избегать

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

Хотя и по SDO там тоже не много данных собрать надо... подумаем...

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

Вообще-то для этого и реализован в CANopen механизм Heartbeat - узел который принимает PDO должен быть настроен на прием Heartbeatов от соответствующих узлов. При его "отваливании", или "отваливании" одного из этих узлов, он должен переходить в безопасное состояние. Таким образом здесь мастер не нужен.

Без проблем. Настройте узел, который это должен знать на прием Heartbeatов от тех узлов, которые должны выполнять команду. При отпадании одного из узлов - получите ошибку. Но это уже перестраховка, так как смотри выше.


ИМХО если я правильно понимаю CANopen - SDO механизм не предназначен для обмена процессными данными. Не стоит его здесь мутить. В CANopen такие задачи предусмотрены и решаются стандартными механизмами.

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

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

SDO служит для связи точка - точка, где то я даже читал что сервер может инициировать обмен 2 узлов сети, сообщив им их пары SDO (изначально этот обмен возможен только через сервер, что увеличивает в 2 раза трафик), но у меня пока много оборванных кусков стандарта, потому не могу утверждать что это точная цитата и верная информация...

Я тоже когда изучал CANopen этого боялся. Но реально, чтобы сообщение не дошло в CANе, оно должно не дойти именно до этого узла и именно полностью, иначе этот узел создаст панику на шине, и оно пересылается. То есть получается, что PDO данный узел должен полностью не заметить, а Heartbeat - полностью принять. При настройке Heartbeatа на частое повторение - ситуация ИМХО очень маловероятная. Также не забываем - Heartbeat имеет самый низкий идентификатор и следовательно самый высокий приоритет, то есть он не может быть задавлен PDOшками. В CANopen все продумано


Не то же самое. Механизм генерации и приема сообщений Heartbeat должен иметься в каждом CANopen узле. И настраивается он независимо от того NMT мастер это или слейв.
NMT мастер же отличается от слейва только тем, что мастер посылает а слейв принимает сообщения о запуске сети или узла,т.е перевода его в различные состояния.


В SDO-обмене - сервер - это тот узел к которому залазят в его объектный словарь за данными или запихивают что-то туда.
Клиент - это узел, который инициирует обмен, т.е. посылает сообщения серверу и залазит в его словарь. Вообще-то SDO - клиенту даже не нужно быть участником сети - он может залезть в словарь сервера, просто зная его идентификаторы TSDO и RSDO.

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

Кстати не кто не мешает сделать подтверждение приема на PDO. К примеру в блоке реле можно сделать переменные "задача" и "состояние". Принимаются PDO с тем какие реле надо выставить (задача), а после выставления асинхронно шлется другое PDO с тем что выставилось (состояние), фактически - это подтверждение приема PDO.

А для важных узлов можно сделать PDO эхо, хотя это здорово загрузить сеть всяким мусорным трафиком


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

А вот у меня вопрос про переменные словаря, правильно я понимаю что одна и та же переменная может быть использована во многих устройствах? И следовательно все они могут иметь едины приемный PDO который эту переменную настраивает, или такое в стандарте не разрешается? Правильно я понимаю что устройство хранит только ему нужную часть словаря?

Могут ли 2 разных объекта слать одинаковые идентификаторы PDO (вроде бы нет, иначе они могут одновременно их послать, и будет коллапс)? Есть ли ограничение на количество обрабатываемых PDO на приеме? На что выделены 2 входных PDO, чтобы гарантировать возможность как минимум 2 другим устройствам задавать переменные? А если надо чтобы это могли сделать 3 или больше устройств, занимать PDO у других что их не используют?
А мастера на шине имеют огромный список исходящих PDO?

Опять упираемся в понимание PDO - я Вам советую - забудьте вы этот Predefined Connection Set - это просто пример, и в реальной сети конфигурация может быть совсем другая.


Спокойно можно сделать. Главное, чтобы переменная "Состояние" могла меппиться в соответсвующее TPDO.

А вообще советую почитать соседнюю тему, где мы обсуждали сокраментальный смысл PDO http://electronix.ru/forum/index.php?s=&am...st&p=886979


Да правильно.

Нет. Каждое устройство имеет свой локальный словарь.

Короче, вот пример использования PDO:
Допустим у нас есть узлы 1,2 и 3, связанные по CANopen. Узел 1 стоит на улице и измеряет температруру воздуха. Узлы 2 и 3 должны знать эту температуру, чтобы регулировать обороты вентилятора в ванной и на кухне.
Чтобы это реализовать в узле 1 в его объектном словаре есть переменная "Температура воздуха", куда с АЦП записывается температура, непосредственно им измеряемая.
В узлах же 2 и 3 в ихних локальных объектных словарях есть переменная "Температура уличного воздуха" - которую считывает алгоритм управления вентилятором в этих узлах.
Чтобы все как-то заработало необходимо, чтобы переменная "Температура уличного воздуха" отображала значение переменной "Температура воздуха".
Для этого нужно сделать дальнейшие действия только один раз при настройке сети:
Узел 1 настраивает TPDO с адресом XXX, в которое маппится переменная "Температура воздуха", и настраивает это TPDO на передачу по изменению значения переменной. Таким образом при изменении температуры воздуха в сети появится сообщение с идентификатором XXX и значением температуры. Чтобы узлы 2 и 3 принимали это сообщение, мы настраиваем в них RPDO с адресом XXX и маппим туда переменную "Температура уличного воздуха". Таким образом если узлы 2 и 3 принимают PDO с таким адресом, они автоматически достают из сообщения нашу температуру и записывают ее в локальный словарь.
После проделывания данных процедур сеть начнет работать, и узлы 2 и 3 смогут узнать температуру воздуха просто посмотрев в свой локальный словарь и прочитав переменную "Температура уличного воздуха". И неважно, что она измеряется совершенно другим узлом за тридевать километров - всю работу, связанную с обновлением локальной переменной возъмет на себя CANopen.

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

Начальные TPDO и RPDO - это настройка для простоты, то есть можно брать узлы и встраивать их в систему с адресом, и всегда знать как к нему обратиться чтобы что-то записать, и понимать какое сообщение придет от него с данными, и не более того... Так?

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

Примерно так, но только с SDO. PDO всегда надо настраивать ручками. В принципе в CANopen всегда есть возможность просканировать сеть - каждый узел хотя-бы один раз при включении выплевывает в сеть одно сообщение с идентификатором равным номеру узла - это т.н. Bootup message. Зная этот идентификатор автоматически определяются идентификаторы для обмена SDO сообщениями с этим узлом. Они равны 580h+Node_ID и соответственно 600h+Node_ID. Таким образом с помощью SDO клиента можно всегда получить доступ к любому узлу в сети, даже если сеть еще не сконфигурирована. Как я уже говорил - такой клиент - это PC с CANopen конфигуратором и сканером.
А получив доступ к словарю через SDO - уже можно настроить идентификаторы и параметры PDO. После этого все параметры записывается во флеш и сеть запускается. С этого момента обмен через SDO становится больше не нужен - когда параметры PDO заданы - узлы сами будут обмениваться PDOгками даже после перезагрузки.

По моему такая ситуация в некторых конфигурациях сети вполне реальна.
Рассмотрим линю протяженностью 500м с тремя узлами. В точке 0м стоит узел 1, в точке 10м узел 2 и в точке 500 - узел 3. В том же шкафу где установлен узел 3 клацают пусактели с могучими нагрузками.
Узел 1 посылает TPDO узлу 3, и как назло момент прихода PDO на 3 узел совпал с переключеним нагрузки, в которой опять же по случайному стечению обстоятельств подклинило двигатель. Узел 1 получил ACK от узла 2 и считает что передача прошла успешно а узел 3 отбросил пакет из-за ошибок. Heartbeat однократную потерю пакета не заметил.
Идеологически PDO хорошо подходит для данных потеря которых не приводит к плохим последствиям, и их желательно слать периодически а не только однократно по событию.



Там далеко не все продумано. Например Plug-and-play слабо реализован.

Так в CANe не пройдет. Узел 3 в момент, когда он обнаружит ошибку в пакете, забъет всю шину доминантным Error frame, который увидят и узел 1 и узел 2. Никто тогда пакет не примет и узел 1 ретранслирует весь пакет.


А зачем он там нужен?

Нет в мире совершенства на canbus это правило действует тоже
Local Errors in EOF
Message Doubling


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

Ну и шо? Это наоборот демонстрирует, что CAN - совершенен . В худшем случае одно и то же сообщение передастся дважды.

с CANOpen не работал и полностью реализовывать протокол не хочу. Достаточно одного SDO и карты индексов, субиндексов и мин/макс значений. Есть ли какие средства, которые из EDS преобразуют в заголовочный файл с дефайнами этих индексов субиндексов и мин/макс значений?

Последний мой вопрос не актуален, так как придумал механизм удовлетворяющей моей задаче.
Все SDO пишутся и читаются, всё отлично.
Остался последний вопрос. Я отправляю NMT, но не понимаю как проверить прохождение, так как устройство никак не реагирует на мою посылку. Может я не верно отправляю.
Мой пакет выглядит так:

CAN_ID = 0
RTR = 0
LEN = 8 // пробовал и LEN = 2
DATA[0] = NMT_MODE // согласно описанию
DATA[1] = node_id + 1 // +1 указан в описании
DATA[2...7] = 0

Дальше я это дело отправляю, но как проконтролировать прохождение не понятно , так как в поведении устройства ничего не меняется.