[Forger 17]

Откуда Вы это взяли?

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

 

совсем необязательно ограничение в 4шт на узел. Может быть и 8 и 100 TPDO в одном узле.

Да, это так. Максимум 512 TPDO и 512 RPDO (128 узлов * 4 в каждом узле).

Но четыре PDO железно зафиксированы за одним nodeID. Но, если узел хочет больше PDO, то он может "заимствовать" PDO из других nodeID. Т.е. занять больше, чем один nodeID. Проблема возникнет, если к сети поключать тот самый узел, nodeID которого уже кто-то использует. Тут сеть усложняется. Для отлавливания таких непрятностей нужен доп. софт, например, IXAAT.

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

 

Но по идее SDO - это как доступ через заднюю дверь ко всему словарю.

 

Точно, но, к сожалению (может, даже к лучшему), SDO транзакции идут однократно после сброса узла или подачи ему питания.

В принципе, можно "обмануть" стек CANopen и в этом случае - узлу просто нужно "имитировать" то, что он якобы сбросился. В этом случае SDO посыпяться от мастера заново, все! (точнее только те, которые прописаны в конф. файл к конкретному узлу).

В этом случае можно уже "подсовывать" в один и тот же объект словаря уже другие данные.

Но представьте себе трафик по шине! И как себя поведет мастер при таких "фортелях" некоторых узлов - неизвестно.

Короче, через SDO слать периодически изменяющиеся данные, на мой взгляд, не очень разумное решение. Для этой цели как раз и предназначен PDO.

 

 

[syoma 1]

Но четыре PDO железно зафиксированы за одним nodeID.

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

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

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

Точно, но, к сожалению (может, даже к лучшему), SDO транзакции идут однократно после сброса узла или подачи ему питания.

В принципе, можно "обмануть" стек CANopen и в этом случае - узлу просто нужно "имитировать" то, что он якобы сбросился.

Я чего-то не понимаю, че Вы имеете ввиду. SDO обмен возможен всегда. Ничего узлу имитировать не надо.

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

 

Кстати вот ссылка:

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

[Forger 17]

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

 

Вот структура 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. Юзеру так удобнее. Повторюсь, такая реализация очень удобна в относительно простых сетях пром. автоматизации.

 

Я чего-то не понимаю, че Вы имеете ввиду. SDO обмен возможен всегда.

Согласен, тут я перепутал с PDO: в режиме PreOperational PDO не доступен, но доступен SDO. А в рабочем режиме - Operational - доступен не тока PDO, но и SDO.

Но в том же моем любимом CoDeSys чтобы использовать SDO, нужно лезть в дебри их (3-S Software) библиотеки, доку на которую они не дают обычным юзерам. Юзеру же доступны только PDO, а точнее - объекты словаря более 0x6000.

Можно выбрать те, которые у узла будут использоваться (т.е. реализовано динамическое маппирование PDO). Все это делается в соотв. окошках среды, весьма удобно, т.к. в этом случае шину CANopen может настроить малообразованый юзер. Это выгодно и удобно.

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

[syoma 1]

В них из 11 бит cobID 7 отводятся под номер узла (0...127), а старшие 4 бита определяют тип протокола.

из 16 возможных значений этих 4-бит восемь значений отводятся под PDO (4 пары PDO).

Это сделано железно и изменить их нельзя.

То что Вы привели - это так называемый Predefined Connection Set - параметры по умолчанию, которые имеют устройства при первом включении в сеть.

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

Из этих параметорв только SDO и NMT сообщения должны иметь фиксированные и привязанные к Node-ID идентификаторы. Идентификаторы остальных сервисов пользователь может спокойно менять. Кстати в некоторых профилях CANopen есть PDO, идентификаторы которых - фиксированны и не зависят от номера узла.

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

Я смотрю Вы описание какого-то ПЛК читаете, у которого все ограничено пром.автоматизацией и юзеру не разрешены самовольности, чтоб он там ничего не натворил. А надо читать сам стандарт.

CANopen не ограничен автоматизацией - есть еще профили для лифтов, кранов, грузовиков и куча всего - где использование PDO более гибкое, чем в автоматизации.

[Forger 17]

Из этих параметорв только SDO и NMT сообщения должны иметь фиксированные и привязанные к Node-ID идентификаторы. Идентификаторы остальных сервисов пользователь может спокойно менять. Кстати в некоторых профилях CANopen есть PDO, идентификаторы которых - фиксированны и не зависят от номера узла.

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

Мы, похоже, говорим одно и то же , но разными словами :)

[slimjack 0]

А что если узел с одним nodeID будет использовать все 8 PDO на передачу? Какие проблемы тут возникнут?

[syoma 1]

А что если узел с одним nodeID будет использовать все 8 PDO на передачу? Какие проблемы тут возникнут?

Никаких. Каждый узел может задать до 512 различных PDO на передачу и 512 PDO на прием.

Для них даже свои адреса под коммуникационные параметры выделены. http://www.softing.com/home/en/industrial-...vanchor=3010610

Единственное, что количество одновременно используемых PDO ограничивается возможностями стека. Для каждой реализации это пишется в спецификации. Коммерчесские стеки, обычно, поддерживают до 512шт, как в спецификации CANopen.

http://www.ixxat.com/canopen_stack_en.html

Есть урезанные модификации - http://www.canopenstore.com/pip/microcanopen.html

Бесплатные - еще меньше.

В CANopennode - помоему 8 шт возможно.

Но в любом случае Ваше устройство должно в eds файле указать - сколько конкретно PDO штук оно поддерживает путем указания, какие адреса в области 1400h-1BFFh существуют.

[slimjack 0]

Т.е. 512 PDO одного направления - это чисто такая договоренность для конкретизации структуры словаря (ну или способа настройки узлов)?!

Изначально я думал, что возможен такой вариант: допустим, в сети всего два устройства и объявлены 1024 PDO. Одно из устройств является производителем всех этих 1024 PDO, а другое является потребителем этих же 1024 PDO. Т.о. у одного устройства обьявлено 1024 TPDO, а у другого - 1024 RPDO (с теми же идентификаторами).

 

Попытаюсь еще одним способом выразить как я себе представляю PDO в CANopen. В сети возможно существование 1024 PDO с различными идентификаторами (тут вроде все ясно). Эти PDO периодически возникают в сети и тот кому интересен тот или иной PDO вылавливает его и обрабатывает. А возникают PDO в сети благодаря производителям этих PDO. Т.о. возможно просто 1024 PDO, а какие они Tx или Rx - зависит кто с этим PDO работает: для производителя - это TPDO, а для потребителя - это RPDO. А то, что в CANopen описано 4 PDO на вход и 4 PDO на выход - это всего лишь рекомендации (которые меня сбивают с толку). Может быть 0 на вход и 8 на выход, или 200 на вход и 0 на выход.

 

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

[Forger 17]

у одного устройства обьявлено 1024 TPDO, а у другого - 1024 RPDO

Арифметика здесь простая:

В CAN кадре из 11 бит cobID 7 бит идут на идентификатор (0...127), 2 бита - на номер пары PDO (0...3), и 1 бит - направление PDO (RPDO или TPDO).

Всего выходит 10 бит, 2^10 = 1024 PDO (512 RPDO + 512 TPDO).

http://electronix.ru/forum/index.php?act=a...st&id=53581

 

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

Это точно! На каждый поддержанный PDO мастер сети должен выделить кусок памяти для обслуживания этого PDO.

Делается это либо статически, или динамически, но однократно при запуске стека.

Т.о. памяти 512x2 PDO кушают довольно много, особенно, если PDO требуют таймера (циклическая передача).

Да и на обслуживание такого массива требуется недюженных ресурсов проца. Такая реализация потянет тока довольно мощном проце.

С другой стороны, процы щас стали намного быстрее (в смысле, микроконтроллеры), дешевле и ОЗУ у них стало уже довольно.

Поэтому может и заработать на обычном дешевом ARM-е, например, на каком-нить Cortex-M3, коих щас навалом.

Но мне все же нравиться идея syoma: использовать PDO для сигнализации свежих данных от узла, а по SDO их забирать у узла. Размер таких данных, в теории, ничем не огораничен.

[slimjack 0]

1 бит - направление PDO (RPDO или TPDO)

Не понял. Допустим, устройство с nodeID 05h посылает в сеть сообщение PDO, например, с номером b0011 (согласно таблицы). Т.о. у устройства с nodeID 05h есть TPDO с идентификатором 185h. Где-то в сети есть устройство с nodeID 06h и оно хочет принять PDO с идентификатором 185h. Но у этого PDO бит направления установлен на передачу. Как быть? Я к тому - зачем нужен этот бит направления? Если для того, чтобы принять сообщение, его придется прогигнорить?

 

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

[Forger 17]

Не понял. Допустим, устройство с nodeID 05h посылает в сеть сообщение PDO, например, с номером b0011 (согласно таблицы). Т.о. у устройства с nodeID 05h есть TPDO с идентификатором 185h. Где-то в сети есть устройство с nodeID 06h и оно хочет принять PDO с идентификатором 185h. Но у этого PDO бит направления установлен на передачу. Как быть? Я к тому - зачем нужен этот бит направления? Если для того, чтобы принять сообщение, его придется прогигнорить?

 

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

Нет там никакого бита направления, это я условно написал для случая, если бы нумерация протоколов CANopen шла от нуля.

Таблица - это основа протокола, именно на нее и ориентируйтесь.

[syoma 1]

Т.е. 512 PDO одного направления - это чисто такая договоренность для конкретизации структуры словаря (ну или способа настройки узлов)?!

Это ограничение CANopen на то количество сообщений, которое может генерить один узел. Ну зачем вам в одном узле больше чем 512 различных сообщений, если в каждое можно по 8 байт данных запихать?

А приведенная таблица - это такая рекомендация, которая в случае простой сети и наличия устройств "из коробки" позволяет одному узлу (мастеру) обмениваться индивидуально данными со 127 узлами. При этом каждый из 127 узлов имеет 4 TPDO, с помощью которых он передает мастеру данные и 4 RPDO, с помощью которых он принимает информацию от мастера. В итоге 128-ой узел - мастер должен иметь 127*4=508 настроенных RPDO и 508TPDO. То есть 508 PDO служат для того, чтобы один мастер передавал информацию 127 узлам, и 508 PDO нужно, чтобы 127 узлов передавали мастеру свою информацию. Ну а оставшиеся 8 PDO - для мастера. Еще раз повторюсь - это только пример.

Изначально я думал, что возможен такой вариант: допустим, в сети всего два устройства и объявлены 1024 PDO. Одно из устройств является производителем всех этих 1024 PDO, а другое является потребителем этих же 1024 PDO. Т.о. у одного устройства обьявлено 1024 TPDO, а у другого - 1024 RPDO (с теми же идентификаторами).

Теоретически такой вариант возможен, но практически нет - так как в стандарте CANopen прописаны адреса в словаре только для 512 TPDO или RPDO. Т.е лимит 512TPDO из одного узла.

Попытаюсь еще одним способом выразить как я себе представляю PDO в CANopen. В сети возможно существование 1024 PDO с различными идентификаторами (тут вроде все ясно). Эти PDO периодически возникают в сети и тот кому интересен тот или иной PDO вылавливает его и обрабатывает. А возникают PDO в сети благодаря производителям этих PDO. Т.о. возможно просто 1024 PDO, а какие они Tx или Rx - зависит кто с этим PDO работает: для производителя - это TPDO, а для потребителя - это RPDO. А то, что в CANopen описано 4 PDO на вход и 4 PDO на выход - это всего лишь рекомендации (которые меня сбивают с толку). Может быть 0 на вход и 8 на выход, или 200 на вход и 0 на выход.

Да - абсолютно правильно понимаете.

Допустим, устройство с nodeID 05h посылает в сеть сообщение PDO, например, с номером b0011 (согласно таблицы). Т.о. у устройства с nodeID 05h есть TPDO с идентификатором 185h. Где-то в сети есть устройство с nodeID 06h и оно хочет принять PDO с идентификатором 185h. Но у этого PDO бит направления установлен на передачу. Как быть?

Никак. В принимающем узле прописываете RPDO с идентификатором 185h и принимаете нужное PDO. Бит направления - это просто условность.

[slimjack 0]

Ну теперь все ясно!

Спасибо за разъяснения всем!

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

[syoma 1]

Смотрите это сообщение: http://electronix.ru/forum/index.php?showt...st&p=790098

У меня железо - USB-to-CAN от IXXAT.

Платный стек стоит от 5000$. Бесплатных - есть 3шт. CanopenNode, CANfestival и бесплатная библиотека от Microchip для PICов.

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

[GreyM 0]

Бесплатные - еще меньше.

В CANopennode - помоему 8 шт возможно.

Это не совсем так. CANopenNode предоставляет 8 шт. по умолчанию (т.е. для них прописано отображение и тому подобное). Однако, в самом стеке (в мануале и в файлах CO_OD .c и .h) оговаривается, что нет никаких принципиальных проблем руками дописать необходимое количество PDO. То же самое относится и к heartbeat'у.