В этом МК есть аппаратный CAN интерфейс. С ним я разобрался, вот только могу пользоваться им лишь для связи с другим таким же МК.
А мне требуется интегрироваться в сетку с протоколом CANOpen.
Вопрос: Возможно ли такое выполнить ? И как ? Очень нужны базовые примеры и документы.
Сам я пока лопачу документацию. Но без вашего опыта буду долго возиться.
Уважаемое сообщество, прошу помощи.

Документацию на что?

CANopen так с бодуна не делается.
Помимо стека с реализацией коммуникационного уровня по спецификации DS301
нужно еще реализовать профиль из набора спецификаций DS4XX
Ну и еще понадобится конфигуратор на PC для формирования dcf файлов
Ну и менеджер сети нужен как минимум для отладки.
Т.е. солидный набор тулсов. Возьмите лучше готовый стек CANopen .

Спасиб за мнение.
На данный момент смотрю в сторону CANFestival.

Тогда уж лучше CANopenNode - в нем исходники гораздо внятнее и есть хорошая документация по ним и примеры.
Хороший покупной стек стоит очень дорого. На практике не требуются абсолютно все фичи CANopen. Да и не так уж и сложен CANopen. А сложности в нем другого рода: перестраховки на самые "нелепые" случаи работы других узлов и самого мастера сети, исчерпывающий набор методов отправки/приема важных и критичных ко времени данных и т.п. Но в большинстве узлов (девайсов) это все не нужно и хватает основных базовых возможностей CANopen (например, см. стек от Microchip).

В моем случае я реализовывал CANopen slave самостоятельно (узлы для работы с ПЛК под CoDeSys).
На полное понимание CANopen ушло около двух недель. Вполне достаточно одного документа DS301 и какого-нибудь "профильного" документа, например, DS401.
Еще примерно месяц на реализацию (на С++ удалось отказаться от шаблонов).
Конечно похвастаю: у меня получилось абсолютно кросплатформенное решение, хотя это - и не цель.
Я не все сделал (просто не требуется для текущего проекта), но спроектирован практически весь стек CANopen. На одном кристалле могут абсолютно без ущерба друг другу работать более одного стека, каждый из которых может висеть на своем CAN драйвере (мне это нужно для реализации надежной сети с дублированием шин CAN - девайс далеко не бытового назначения).

Вот пример простейшего проекта на моей реализации стека:


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

Кстати, скажу по-секрету, военные и космические заинтересовались CAN-ом. И можно понять почему: в настоящее время в отечественной авиации, космосе и войне для связи девайсов используется старая шина MIL-STD-1553 (успешно "спертая" военными у янков аж в далеком 1973). Так вот, трансивер + контроллер этой шины для одного узла стоит минимум 1000$ !!! Все решение полностью покупается у янок. А в космосе это обходится и того больше. А цена решения CAN шины обойдется в 1000 руб (для военных) или того меньше, если военные/космос догадаются купить исходники CAN-контроллера и запихать их в рад-стойкую ПЛИС.

Так все-таки CANopenNode или CANfestival?
Что лучше, если надо реализовать и мастер и слейв?

По мне так CANopenNode будет попроще в реализации для контроллера, а вот для ПК надо CANfestival использовать.

Я имел ввиду, конечно контроллер. Например STM32F. Хоть и как сдесь сказали, CANopenNode лучше документирован, но на форуме CANFestival есть информация, что его достаточно легко можно портировать под STM.
Еще интересно - имеет ли смысл все это дело на CANpie заворачивать, или стандартных библиотек и функций достаточно?

А что такое CANpie?

Привет.
В общем я теперь вроде нахожусь на том уровне понимания стека, что как работает - понятно, но теперь вижу ущербность Open-source стеков и даже некоторых не-Opensource. Поэтому есть пара вопросов.
1. Я так понял что у Вас, как и у многих других реализаций, есть функция CANOPen.dispatch, которая должна циклически вызываться из главной программы и выполнять раскидку и создание PDO,SDO сообщений и реакцию на NMT. То есть время выполнения такой функции зависит от загрузки сети и точно не детерминировано - что мне как-то не нравится. Или это нормально?
2. Как у Вас выглядит Object Directory - просто массив данных одинаковой длины? Как вы к нему обращаетесь? Через функции, чтобы избежать порчи данных при чтении и чтобы CANopen знал, когда слать PDO? Или просто?
3. Как насчет NMT master и сервисов LSS. Реализовывали ли их?
4. Что посоветуете для первой попытки связи с CANopen устройством?
У меня есть CANanalyzer с IXXATшным USB адаптером. Как я понял, NMT и PDO сообщения я еще смогу сгенерить самостоятельно, но SDO - надо бы что-то получше. Я думал, действительно какой-нибудь ПЛК взять для экспериментов, но не могу понять, какой.
5. Вы брали какой нибудь стек за основу или полностью свой лепили?
6. Отправка сообщений - используете ли Вы какой-нибудь буфер или по одному шлете?

От загрузки сети это почти не будет зависеть, если отсев левых кадров будет производится еще в прерываниях по приему кадров.
Более того вызов dispatch я делаю в отдельной задаче RTOS по событию (сообщению) из прерывания по приему.
Разумеет, контроллер должен иметь достаточную производительность.
В RTOS есть анализ загрузки, типа профайлинг. Так что, все под контролем



Нет, не массив. Список с абстрактным интерфейсом для доступа к объекту.
Т.е. TObject - полностью абстрактный класс, все методы - виртуальные.
CANopen стек имеет доступ ко всем объектам только через этот абстактный класс.
Подобное построение реализовано во всем стеке.



Нет. Не требовалось. Но, если понадобиться, добавить недолго - стек построен прозрачно.


Я использовал ПЛК от BECK@IPC: SC23/24. Среда CoDeSys.
http://www.beck-ipc.com



Исключительно свой, по документам CANopen CIA.



Разумеется, буфер. По передаче тоже. Более того, у CAN контроллера есть как правило свои аппаратные буферы.

Я не имел ввиду со стороны стека, а как обстоит дело с доступом со стороны приложения?


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

При объявлении класса объекта (TObjectXXX) он должен обязательно наследоваться от шаблона TObjectCustom<>.
При статическом (желательно) или динамическом объявлении экзэмпляра этого класса TObjectXXX, он автоматически включается в список объектов и доступен стеку через закрытые и уже реализованные самим стеком методы (для приложения они недоступны).
Для приложения необходимо реализовать лишь одну чисто виртуальную функцию updateInputs, которую будет вызывать сам стек CANopen, это обновляет выходные сигналы (со стороны узла), т.е. RPDO.
В самом классе TObjectXXX можно наделать сколько угодно своих методов, но для обновления входов (со стороны узла), т.е. TPDO,
необходимо в этих методах в нужных местах вызывать уже реализванную в TObjectCustom<> функцию updateOutputs.




Я этого не могу сказать, поскольку я - не руководитель фирмы, а лишь ее сотрудник: платил не я
Одно знаю: преобразователь CAN-USB и софт (все от отечественной компании Марафон) обошелся в ~20 тыр.
Но этот вариант не советую, все ж лучше один раз раскошелиться на нормальный набор, например, от IXXAT.
Без сторонних железок и софта нормальный CANopen практически невозможно реализовать.

Я вот смотрю, что вы с STM32 работаете. Я тоже собираюсь на нем реализовывать.
Вопрос - у вас, я так понял, реализация с использованем ООП?
На CANopenNode - есть вариант обычной реализации и ООП - правда он еще полностью не протестеный, но доступный. Вот я и не понимаю, чего тот чел тоже перелез на объекты, если и без них все прекрасно работало. Зачем для микроконтроллера объектная реализация?
Или может есть весомые преемущества ООП реализации CANopen стека, по сравнению с обычной реализацией, с точки зрения понимаемости программы в будущем и расширяемости, если основное приложение будет оставаться обычным - без объектной реализации?

ПС. Я это спрашиваю еще потому, что посмотрел документацию на основные коммерческие CANopen стеки от IXXAT, Vector и т.д - там все без ООП. Но это наверное в угоду портируемости.

А у кого вы купили за такую цену? На сайте марафона он 6 тысяч рублей стоит.

5 тыр. коробка USB-CAN
15 тыр. софт: CANWize+CANopen (DLL-ка)
Год назад покупали



Ну, типа того



1. Простота реализации и отладки. Дешевле выходит, но требуются хороший навыки использования C++ и соотв. абстактное мышление. Мне последного слегка недостает
2. Простота применения в новом очередном проекте. Это факт. Проект выходит предельно прозрачным.
3. Б'ольшая безопасность применения, из-за преимуществ C++.
4. Меньший объем кода (на С будет тяжелее из-за больших проблем с правильным проектированием). Проверял.
Но данных (ОЗУ) нужно больше. Хотя и это решаемо.



В том-то все и дело, что если основное приложение тоже - ООП, то применения CANopen стека, RTOS (у меня C++ обертка для TNKernel, так намного удобнее), других стеков (TCP/IP, например) становиться намного удобнее и меньше ошибок.

Что-то типа этого:




Пожалуй,...
К тому же далеко не для всех процов есть C++ компилер.

Спасибо за ответ


Ага, значит Вы еще и CANopen модуль к анализатору докупали.
Блин, а он дороже чем сам анализатор будет.

А как иначе?
По опыту работы с этим набором скажу, что CANopen DLL-ка от Марафон не особо нужна -
она там весьма упрощенная, поэтому все можно сделать без нее.
Достаточно купить софтину CANwize, впрочем, даже эта софтина не блещет удобствами.
Вполне можно написать софтину своими силами. Благо марафоновцы дают исчерпывающий
набор примеров и документации на USB-CAN коробку.
Однако, есть у этой коробки одна серьезная беда.
При очень интенсивном обмене по шине (1 МБит скорость, кадрый сыпяться без перерыва) -
эта коробка теряет кадры и получает некоторые битыми.
Буфер в ней забивается настоко, что драйвер не успевает выбирать все кадры.
Явные софтовые проблемы.
Я бы все-таки не советовал покупать этот вариант, несмотря на его очень низкую цену.
Если б я знал это раньше, то лучше попросил у кого-нить в долг за деньги нормальный набор от IXXAT или подобное.
Или вовсе убедил бы боссов купить этот набор.
А делать свою коробку USB-CAN не советую - на первых порах лучше, чем у марафон не выйдет, а обойдется намного дороже. Да и времени на это тоже нужно немало - много заморочек и косяков с софтовой частью: прошивка контроллера, драйвер под винду, софт для пользователя.

По-видимому, Вы имеете ввиду CANopen анализатор. Это лишь один из модулей набора, который и должен быть достаточно простым. Ведь большинство CANopen протоколов являются "однокадровыми" т.е. поддерживаются одним CAN кадром канального уровня. Анализатор лишь интерпретирует такие кадры в терминах стандарта CANopen DS301.
Одним из достоинств анализатора является отслеживание контекста SDO обмена, в том числе для блочного протокола, который в большинстве свободных CANopen библиотек не реализован (вообще говоря, он и используется не очень часто). Вот это свойство без опыта программирования CANopen систем реализовать самостоятельно весьма непросто. Наибольшую пользу CANopen анализатор может принести как раз на начальном этапе освоения CANopen. Если Вы преодолели этот этап без помощи анализатора, в дальнейшем его ценность будет для вас снижаться (до определенной степени).


Данная "софтина" является бесплатным приложением к любому CAN контроллеру Марафон и может быть загружена с сайта компании. Стоимость CAN-USB интерфейса - 5000 рублей без НДС, CANopen анализатора - 9500 рублей без НДС.


Есть такая беда-проблема. Она связана с использованием устаревшего FTDI USB контроллера, а также с некоторыми ограничениями используемого USB протокола. У IXAAT контроллеров таких проблем нет - сказывается почти 15 летняя фора по CAN разработкам, да и возможность привлечь к ним заметно бОльшие ресурсы. Вместе с тем, отметим, что такая ситуация (минимум проблем) наблюдается лишь у CAN разработчиков первого эшелона (Vector, IXXAT). Нам доводилось сталкиваться с CAN-USB интерфейсом, также разработанным в Германии, который при переполнении буферов на максимальном CAN трафике просто и тихо зависал. Марафоновский контроллер, теряя кадры, не виснет, но ругается, сообщая о различных оверранах и прочих неприятностях.
В настоящее время Марафон выпускает новый вариант CAN-USB контроллера. Он является двухканальным и свободен от недостатка производительности, в том числе на максимальной скорости CAN сети 1 Мбит.

Что ж, выходит, что набор от Марафон вообще самый дешевый!



Тоже за 5 тыр?


А не планируете CAN-ETHERNET коробку?
Очень была бы удобна.

Можно вопрос чуть-чуть в сторону от темы. Я, вообще-то, пользуюсь CodeWarrior 8.2. В нём вроде CAN не программируется. Вы как его программируете?

Компилятор и среда тут не имеют значения.
Какой контроллер?

MC56F8037 Freescale. Насколько я знаю, там к CAN нужно что-то дополнительно в CodeWarrior.

Заходите на сайте Freescale, качайте оттуда даташит на контроллер, примеры программ и т.п.
В CodeWarrior есть HELP и мануал.
Короче, RTFM

C чего бы это.

см. http://projects.caxapa.ru/?ID=23

Двухканальные на Cortex-M3 будут в районе 3000 - 3500 http://www.mcutool.ru/products/connectivit...ser/us-can.aspx

Одноканальные, недорогие ( но без пропуска пакетов) - 1500-2000 http://www.mcutool.ru/products/connectivit...n/uccanlhs.aspx

В начале июня начнем.

А софт какой ? Чето по ссылке не нашел, так железку можно за пару дней сделать, прицепить SJA1000 к FT2232HL (апноут даже есть)

IMHO - Это все игрушки для наколенных проектов. Сам в свое время такой CAN-анализатор купил - поигрался и на полку положил. Потому, что смысл не в железе а в софте.
Во первых драйвера - тот же адаптер от IXXAT имеет драйвера и под LabView и под MATLAB и библиотеки под C - куда хочешь его прилепить можно. А тот, что за 70$ - с каким софтом его можно будет использовать?
Тот же CANanalyzer - жалко, что нет взломаного, намного круче любого монитора, который идет в комплекте со всеми этими игрушками. Про более навороченые вещи типа CANopen модуля я вообще молчу - их просто для таких девайсов нет и не будет.
Так что, если на фирму брать - это 100% выкинутые на ветер деньги. Купите IXXAT CAN-to-USB - за 300$ и этот адаптер 10 лет будет работать и дрова на него всегда будут, а разработчики спасибо скажут. Эта инвестиция намного лучше.

+1

Привет. Если кому интересно.
Короче запустил я этот CANfestival на STM32F103. Заняло это дело 2 месяца подходов к компьютеру и чтения документации и аж 2 дня на перелопачивание драйверов на CAN контроллер и таймер. Исходники могу выложить.
Аж сам удивился, но буквально при первой компиляции эта штука запустилась и начала генерить heartbit и даже реагировать на NMT команды.
На следующий день запустил PDO обмен - тоже работает без проблем. Несмотря на приличную навороченность (стек занял 20кБ места в МК) стек пока выглядит довольно стабильно. Работает все - и SDO и PDO и NMT сервисы (на слэйве).
Вчера даже получилость прикрутить к нему запись параметров во FLASH, а-ля EEPROM. Правда не все скопом, а для заданных объектов при записи.
2 Штуки мне очень понравились по сравнению с CanOpenNode.
1. Во-первых тут есть редактор eds файлов (правда хитро устанавливается, но вполне сносно) который позволяет создать профиль своего устройства и затем по этой информации генерирует .с и .h файлы для стека и сам .eds файл. Работает очень не плохо. Созданные файлы просто копируются в проэкт и перекомпилируются, а eds файл скармливается программе - монитору CANopen шины. О ней дальше внизу.
2. Во-вторых CANfestival имеет намного более развитые возможности. Например программа пользователя общается со стеком только через глобальные переменные, которые являются объектами словаря. При приходе нового PDO переменные сами собой обновляются. При изменении переменной программой - нужно только выполнить функцию послыки PDO и CANfestival сам определит, какая переменная в какой PDO пойдет и нужно ли его слать. Даже по таймеру все работает.
В общем я доволен пока.
Кстати насчет программы. Есть такой сайт: http://www.canwizard.de Там можно скачать одноименную программу.
Она хоть и предназначена для лифтов, но достаточна полезна и для простых CANopen сетей. Она позволяет подключаться к CANopen сети, искать узлы, читать eds файлы, генерить NMT и LSS команды, общаться с любыми узлами по SDO протоколу и т.д. Даже софт по сети обновлять может. Правда лог файлы она не ведет. Единственное ограничение, что бесплатная версия может работать толька максимум с тремя узлами. Поддерживает она Vector, Ixxat, Peak адаптеры.

Было бы очень интересно взглянуть и сравнить!

Дык чего там сравнивать - взял исходники на CANконтроллер и Таймер со всем известной библиотеки FWlib от ST. Все остальное - родное CANfestivalевское.
Ладно, исходники дров выложу вечером, так как я еще туда кучу всего приделал, чего в CANfestivale не было - запись и чтение параметров из EEPROM - приделал пример эмуляции от ST. Еще добавил управление светодиодиками по DS303-3.
Единственное - обработка Heartbeat в CANfestival не очень реализована - добавил обработчик ошибки по Heartbeatу.

Вот что хочется изменить - не нравится мне функция посылки сообщений от ST - в F103 есть всего три буффера, и если они полны, то новое сообщение можно потерять. Я думаю - либо сделать посылку блокируещей - чтобы все ждали пока сообщение отошлется, либо добавить FIFO буфер побольше.

Я тоже сталкивался с этой проблемой. Решил применением программного FIFO как на передачу и на прием заодно.

Ну, а щас сделано у меня по-другому: использование RTOS позволило использовать ее встроенные сервисы для работы очередями сообщений. А обертка вокруг них создана на базе smart pointer (только C++). Теперь не нужно беспокоиться за валидность указателя на очередное сообщение: если хоть кто-то его еще использует, оно лежит в буфере. А как только все, кому нужно было сообщения, "отстали" от него - это сообщение автоматом освобождается из очереди. Работает изумительно! Оптимизатор компилятора прекрасно работает, удаляя, казалось бы, избыток кода.

К сожалению, мне это пока не грозит. Мне пока достаточно мучений с обычными С указателями.

Я тоже мучался на чистом С, пока не начал всерьез осваивать С++ не под ПК, а именно под обычные МК.
После перехода, полного перехода на С++, многие детские болезни из С по-просту отпали

Добрый день!

Я так же запустил CANfestival в AT90CAN128. Все как бы работает. Но непонятен ряд вещей. Если с контролер в мастер шлеца PDO, то как контроллер узнает о том, что PDO дошло – в программе CAMmonitor – никаких подтверждений я не видел? Как этим протоколом передавать большие объемы данных – есть ли стандартные профили? Как передавать метку времени?
C уважением

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

PDO для этого не предназначен. Смотрите SDO - это типа peer-to-peer соединения. По нему можно передавать большие объемы данных. Вроде в CANfestival реализован и клиент и сервер, но я еще не разбирался.

Добрый день!
Не хотел плодить новые ветки и решил написать сюда, т.к. похоже тут собрались знатоки CANopen.
Не ругайте сильно (возможно будут глупые вопросы), но очень хочется получить простое, доступное объяснение основ CANopen. Я перерыл форум, почитал стандарты, читал статьи, но все равно как-то все смутно. Правда я не разглядывал исходники (CANfestival и CANopenNode).
Попытаюсь объяснить как я понимаю CANopen, попутно задавая вопросы в непонятных местах.


Итак, пользовательское приложение не видит сеть напрямую - оно видит словарь обектов, который представляет собой массив переменных, которые связаны с параметрами, допустим, технологического процесса (температуры, токи и т.д.), а также с параметрами настройки режимов работы самого устройства. Т.е. (как я понимаю) часть словаря - личные данные конкретного устройства, а другая часть - общие данные всей сети (т.е. такие же данные могут находиться и в словаре другого устройства). Т.о. пользовательскому приложению не нужно знать о существовании сети, оно просто берет данные из словаря (например, чтоб узнать текущую влажность воздуха) или записывает данные в словарь (например, давление масла, если это давление измеряется непосредственно данным устройством). Перемещением данных между словарями занимается CANopen.
Обмен между словарями производится посредством сетевых объектов PDO и SDO.
PDO сообщения могут переносить до 8 байт полезной информации и используются для передачи данных о тех. процессе. PDO являются широковещательными сообщениями. Источником (производителем) PDO должно быть устройство которое непосредственно вычисляет или измеряет какой-то параметр, входящий в PDO. Каждый PDO имеет свой уникальный идентификатор (именно он и указывается в качестве идентификатора в сообщении CAN). Т.о. устройство измеряет какие-то параметры и пишет их в словарь. В этом же словаре хранится информация о том, какие данные, в каком порядке и в какое PDO нужно упаковать. Также для каждого PDO существуют правила отправки в сеть (по времени, по изменению, по синхроимпульсу и т.д.). Если выполняется условие отправки, CANopen упаковывает данные со словаря в PDO и отправляет их в сеть. Другие устройства в сети, если они настроены на прием данного PDO (определяется по идентификатору), принимают это PDO и распихивают его содержмое по словарю в определенные ячейки. Теперь вопрос: для чего разделяются PDO на входящие и исходящие (Rx Tx)? Правильно ли я понял, что идентификатор PDO не подразумевает привязки к устройству (т.е. в нем отсутствует информация, о том кто именно в сети отправил PDO)?

Если требуется передать какую-то часть словаря размером более 8 байт, необходимо применять SDO сообщения.
Существует два типа SDO (для передачи информации и для подтверждения). В виду необходимости подтверждения SDO подразумевает только соединение точка-точка. Через SDO одновременно передается только один объект словаря (а в PDO можно несколько), но он может быть большим (более 8 байт).
Дальше у меня практически одни вопросы.
1. При передаче SDO, что из себя представляет идентификатор сообщения? Есть ли в нем адрес конкретного устройства?
2. Какое отношение приложение имеет к SDO?
3. Как устанавливается связь между SDO и объектом словаря?

Просьба - разъясните мне "на пальцах", я не смог найти ответы на свои вопросы из спецификаций.

вы очень все внятно разложили по полочкам

Мой опыт разработки кэн-приложения был таков:

Исходники
1) использовал CANopenNode. У меня тоже PIC-процессор, но другой. Но переписывать ничего не пришлось, забегало сразу.
2) там же редактор словаря, мощная штука, без этого загнулся бы. Но нужен FireFox.
3) даже автора нашел на каком-то форуме, на письма очень быстро отвечает

Документация по протоколам
1) протоколы запросил прямо на их сайте (www.can-cia.org) при регистрации. Любопытно, они очень внимательно проверяют чего там в регистрации им пишут. Мне прислали запрос, почему указанный мной почтовый адрес не совпадает с адресом, написанном на указанном мной www сайте. Для ускорения позвонил им голосом, объяснил, через 10 минут все выслали
2) советую посмотреть также профили, если подойдет готовый- то меньше придумывать придется.
3) ну конечно и дополнительно неофициально гуляющими версиями документации пользовался.
4) посмотрите аппноты, мне помогло: http://www.microcontrol.net/en/know-how/canopen.html
5) еще цикл статей "CAN basics", 8 частей : http://www.can-cia.de/index.php?id=66 ( от "CAN basics: CAN in Automation history and CAN, part 1 of 8" до "CAN basics: Traffic control, part 8 of 8")

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


ага.

Я не пользовал SDO, про это не подскажу. А Вы уверены что оно Вам надо (SDO)?

В сети предполагается два "умных" устройства. Одно собирает инфу с цифровых датчиков, а второе - тоже что-то типа датчика, но оно собирает высокочастотные куски осциллограмм (т.е. размер большой, до 1 Мб) и некоторые из них отправляет на первое устройство. Т.е. без SDO никак.

По поводу PDO можете подсказать для они чего разделяются на входящие и исходящие (Rx Tx)? Какой смысл? Я пока для себя понял, есть PDO с каким-то идентификатором. Он попадает в сеть (неважно откуда) и тот, кому надо, подбирает его. Зачем тут делить на входящие и исходящие?

У меня есть устройство (датчик) с контроллером ATTiny (128 б ОЗУ), получится ли реализовать хоть что-нибудь от CANopen?

У каждого узла в сети CANopen есть всегда 4 TPDO и 4 RPDO. Данные, которые отправляются узлом в сеть - именуются TPDO, принимаемые из сети - RPDO. Какие именно данные (точнее, объекты словаря) в них входят - настраиваются один раз после сброса устройства мастером сети CANopen (в подавлющем числе случаев мастер всегда один) через SDO. Далее настроенные таким узлы мастер переводит в состояние Operational, в котором данные уже идут к узлу и от узла только по PDO (в подавлющем числе случаев). CANopen практически не используются для передачи огромных массивов данных. Для этого лучше сделать свой простой протокол, используя шину CAN. Хотя в документации на CANopen я находил такой объект словаря, предназначенный для удаленной смене прошивки узла.


Все возможно
А вам так важен именно CANopen?
Я бы в вашем случае значительно быстрее "накидал" свой простенький протокольчик для указанной задачи, чем пытался бы использовать CANopen, т.к. на это у меня вышло бы гораздо больше времени и сил.
Исключение составляет тот случай, когда ваш узел должен встраиваться в УЖЕ существующую сеть CANopen.
Распишите по-подробнее сеть, в которой все это будет делаться. Какие узлы, сколько их всего?

Все равно не понял на счет PDO.

Значит все-таки в идентификатор PDO закладывается nodeID? Но зачем? Кому нужно знать с какого узла пришли данные?

Кому нужна информация о направлении сообщения? Зачем разделять на входящие и исходящие? Если устройство передает PDO, то, естественно, оно знает, что для него это сообщение исходящее. И совсем непонятно, что такое входящее сообщение? Что устройство с nodeID=99 может принимать только те PDO, в идентификаторе которых зашит nodeID=99? А если оно хочет принять PDO от других устройств в сети?

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

И по поводу SDO. Правильно ли я понял - каждому узлу в сети назначается по 2 SDO (не более)?

CANopen изначально проектировался для ОДНОГО мастера и кучи узлов.
Поэтому в RPDO nodeID хранит тот узел, которому это PDO предназначен. TPDO - от какого узла эти данные идут, чьи они.
Так мастер и другие узлы точно знают предназначение кадров.


Если вам не нравиться или не понятна логичность CANopen - используйте другой протокол или пишите свой.
В сети полно инфы по CANopen, даже на русском, ищите, и все получится


Изначально в шине CAN ВСЕ узлы могут принимать ВСЕ кадры. CANopen тут не накладывает ограничений.



Если уж так нужен CANopen, то есть простое решение (я сам делал что-то подобное): через один PDO организовать свой минипротокол: например, 1-й байт (а всего из в PDO может быть до 8 включ.) - код команды, 2..4 байты - адрес, 5...8 байты - 32-битное слово данных. А в конце желательно передавать контрольную сумму всего массива данных. По SDO выйдет значительно дольше.

p.s. Я вижу, что вам пока туго даются даже базовые понятия CANopen. Поэтому, может оказаться, что эта задача вам пока что будет не по силам. Особенно если сроки жесткие.
Но, в любом случае, желаю удачи

Дело не в этом-просто не до конца понятна идеология.
Но спасибо за советы. Буду копать дальше.

Откуда Вы это взяли? CANopen никак не лимитирует мультимастерность CANа, а наоборот ее расширяет.
PDO расширяются на исходящие и входящие по одной простой причине - так их легче обрабатывать в устройстве. А на самом деле каждый PDO уникален - имеет свой идентификатор и набор данных. Разделение сделано для того, чтобы пользователь знал - источником данного PDO может быть только один узел в сети. В нем и настраивается TPDO с определенным идентификатором - необязательно соответсвующему адресу узла и совсем необязательно ограничение в 4шт на узел. Может быть и 8 и 100 TPDO в одном узле. Приемником же данного PDO могут быть множество узлов в сети. Чтобы они начали принимать это PDO - в них настраивается RPDO с таким же идентификатором, как уже указанное TPDO. Таким образом устанавливается связь между узлами.
А насчет SDO обмена - к сожалению в моей системе он нужен только для конфигурации. И для этого есть комп с купленной конфигурационной программой и CAN-адаптером. Когда я запустил CANfestival, SDO обмен заработал сразу и комп увидел мои устройства и смог обмениваться с ними по SDO. Как он это делает, я к сожалению не вникал.
Но по идее SDO - это как доступ через заднюю дверь ко всему словарю. Поэтому:

У меня - никакого. Т.е SDO обмен производится вообще без участия приложения. Так как при этом сам стек обрабатывает сообщения и посылает ответ.

Тот кто спрашивает - сам определаяет какой объект он хочет прочитать или записать.

Я не могу сказать, как все это дело будет работать с данными объемом 1Мб. Но с меньшими данными это работало так:
У меня было желание присвоить имя плате. В итоге я создал тектовый объект в словаре с тектом: "Тестовая плата №1. Разработчик ФИО"
В eds файле этот объект был описан, как текст с неопределенной длиной.
Размер этого обхекта более 8 байт. Естественно через PDO я его не передавал и ничего в программе с ним не делал. Но когда конфигурационная программа с компа сконнектилась с моим устройством, то она просканировала весь словарь согласно eds файлу и прочитала мой текст - я его увидел на компе. Как она это сделала - без малейшего понятия. Но это работает!

Есть неплохой интернет курс по CANopen - я постараюсь ссылку найти.
Ну и все спецификации есть тут, для Своих.

Спасибо!
Похоже, что уже для меня все стало ясно.
Еще вопрос - словарь ограничивает объем данных для одной ячейки или нет? Можно ли тот же 1 Мб в нем хранить?

Буду благодарен!

Я имею ввиду самые ранние версии CANopen. Когда еще не было такого кол-ва DS4xx. Впрочем, я могу ошибаться, т.к. очень давно это было.


Да, это так. Максимум 512 TPDO и 512 RPDO (128 узлов * 4 в каждом узле).
Но четыре PDO железно зафиксированы за одним nodeID. Но, если узел хочет больше PDO, то он может "заимствовать" PDO из других nodeID. Т.е. занять больше, чем один nodeID. Проблема возникнет, если к сети поключать тот самый узел, nodeID которого уже кто-то использует. Тут сеть усложняется. Для отлавливания таких непрятностей нужен доп. софт, например, IXAAT.
Одна из прелестей CANopen в том, что в одну и ту же сеть можно подключать узлы разных производителей. Поэтому, чтобы не мучиться с настройкой сложной сети, где много nodeID принадлежит одному узлу, производители узлов (коробочек) по-умолчанию настраивают их на четыре пары PDO. Так железно все будет работать. Остальные извращения делает юзер. Я говорю про "коробочки", которые используются в промышленной автоматизации. Всякие там ПЛК (PLC). Узлы там маленькие как внешне, так и по трафику - несколько релюшек, какой-нить концевик, датчик. Т.е. на один узел никогда не вешается стопитсот видеокамер с HDTV трафиком Но узлов может быть довольно много, обычно до 20..30.



Точно, но, к сожалению (может, даже к лучшему), SDO транзакции идут однократно после сброса узла или подачи ему питания.
В принципе, можно "обмануть" стек CANopen и в этом случае - узлу просто нужно "имитировать" то, что он якобы сбросился. В этом случае SDO посыпяться от мастера заново, все! (точнее только те, которые прописаны в конф. файл к конкретному узлу).
В этом случае можно уже "подсовывать" в один и тот же объект словаря уже другие данные.
Но представьте себе трафик по шине! И как себя поведет мастер при таких "фортелях" некоторых узлов - неизвестно.
Короче, через SDO слать периодически изменяющиеся данные, на мой взгляд, не очень разумное решение. Для этой цели как раз и предназначен PDO.

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

Так железно все как раз будет не работать. TPDO еще будут назначены правильно, но RPDO по умолчанию настроены в пустоту. Ведь по умолчанию RPDO тоже имеют идентификаторы, привязанные к этому узлу и отличные от всех TPDO, естественно PDO с такими идентификаторами слать будет некому. А на самом деле RPDO наоборот нужно настроить на PDO других узлов, чтобы узел начал их слышать. Это тот минимум, который нужно настроить, чтобы CANopen сеть начала работать.

Я чего-то не понимаю, че Вы имеете ввиду. SDO обмен возможен всегда. Ничего узлу имитировать не надо.
Нужен просто будет периодический поллинг от мастера конкретного объекта словаря. Или даже проще. Узел должен послать мастеру PDO, что новые данные готовы и их можно загрузить. После этого сообщения мастер инициирует SDO запрос и скачивает не спеша новую инфу в 1Мб из узла. Вот и все.

Кстати вот ссылка:
http://www.softing.com/home/en/industrial-...vanchor=3010572

Вот структура CAN кадра:
Нажмите для просмотра прикрепленного файла
В них из 11 бит cobID 7 отводятся под номер узла (0...127), а старшие 4 бита определяют тип протокола.
из 16 возможных значений этих 4-бит восемь значений отводятся под PDO (4 пары PDO).
Это сделано железно и изменить их нельзя. Суть большего числа PDO на один узел в том, что сам узел может занять под себя не один номер из nodeID, а несколько, и именно их дополнительно к своему родному nodeID и использовать как свои PDO. В принципе в сети может существовать один узел, занимающий все 512 пар PDO.
Кстати, для передачи кучи объектов словаря через один PDO существует еще MPDO (multiplexed). Что-то типа минипротокола поверх PDO.


Под железно я подразумеваю типовую реализацию CANopen в промышленной автоматизации. Например, в CoDeSys (codesys.com) чтобы использовать SDO в ПЛК (обычно он мастер), нужно лезть в глубины их библиотеки CANopen. А PDO доступны через удобный графический конфигуратор прямо в среде CoDeSys. Юзеру так удобнее. Повторюсь, такая реализация очень удобна в относительно простых сетях пром. автоматизации.


Согласен, тут я перепутал с PDO: в режиме PreOperational PDO не доступен, но доступен SDO. А в рабочем режиме - Operational - доступен не тока PDO, но и SDO.
Но в том же моем любимом CoDeSys чтобы использовать SDO, нужно лезть в дебри их (3-S Software) библиотеки, доку на которую они не дают обычным юзерам. Юзеру же доступны только PDO, а точнее - объекты словаря более 0x6000.
Можно выбрать те, которые у узла будут использоваться (т.е. реализовано динамическое маппирование PDO). Все это делается в соотв. окошках среды, весьма удобно, т.к. в этом случае шину CANopen может настроить малообразованый юзер. Это выгодно и удобно.
Ежели все узлы в сети самописные, то тут я согласен, лучше делать, как вы описали - одим PDO сообщать мастеру о свежих данных, а через SDO их забирать.

То что Вы привели - это так называемый Predefined Connection Set - параметры по умолчанию, которые имеют устройства при первом включении в сеть.
http://www.softing.com/home/en/industrial-...vanchor=3010650
Из этих параметорв только SDO и NMT сообщения должны иметь фиксированные и привязанные к Node-ID идентификаторы. Идентификаторы остальных сервисов пользователь может спокойно менять. Кстати в некоторых профилях CANopen есть PDO, идентификаторы которых - фиксированны и не зависят от номера узла.
Параметры по умолчанию просто сгенерированы для того, чтобы устройства не конфликтовали между собой при первом включении.
Я смотрю Вы описание какого-то ПЛК читаете, у которого все ограничено пром.автоматизацией и юзеру не разрешены самовольности, чтоб он там ничего не натворил. А надо читать сам стандарт.
CANopen не ограничен автоматизацией - есть еще профили для лифтов, кранов, грузовиков и куча всего - где использование PDO более гибкое, чем в автоматизации.

Под nodeID - я подразумеваю не просто некий номер узла в сети, а конкретное содержимое 7 младших бит cobID. Поэтому и утверждаю, что на каждый конкретный nodeID отводится железно 4 пары PDO. Но, повторюсь, узел с конкретным nodeID может использовать PDO, по-умолчанию пренадлежащие другим nodeID. Т.е. всего в одной сети CANopen может быть максимум 512 пар PDO, которые могут быть как угодно распределены между всеми узлами этой сети.
Мы, похоже, говорим одно и то же , но разными словами