[Guintter 0]

Добрый день!

Есть вопрос по использованию 512 TxPDO, RxPDO. Изначально в предустановленных настройках сети используется 4 TxPDO, RxPDO. Насколько я понял из документации DS301, чтобы использовать остальные надо иметь устройства с поддержкой CAN2.0B (29-bit идентификатор). Этот 29-bit идентификатор = COB-ID, по которому можно выбрать из словаря объектов нужный PDO. В стандарте есть оговорка "независимо используется или нет 29-битный идентификатор" при предустановленных настройках связи нужно использовать только 11-бит идентификаторы и дана таблица, в которой прописаны COB-ID для этих 4 TxPDO, RxPDO. Теперь вопрос: Если ли правило генерации COB-ID, описанное стандартом CANOpen для остальных PDO или его нет? И если нет, то это делает разработчик и это будет его собственное расширение никак не совместимое с другими решениями? А если есть то подскажите, пожалуйста, правило генерации (стр. стандарта и т.д.). В стандарте есть только формат 11-битного COB-ID. (4-bit func code; 7-bit nodeid).

Заранее спасибо!

[garry_ 0]

Отвечу вам и здесь, в одном узле столько не получить, максимум 4 PDO

[Forger 17]

в одном узле столько не получить, максимум 4 PDO

Несколько криво, но это можно обойти: в одном узле CANopen допускает наличие до 8 виртуальных узлов.

У каждого такого виртуальгного узла должен быть свой nodeId,.одинакокая. одинаковая шины, один EDS файл.

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

[garry_ 0]

Несколько криво, но это можно обойти: в одном узле CANopen допускает наличие до 8 виртуальных узлов.

У каждого такого виртуальгного узла должен быть свой nodeId,.одинакокая. одинаковая шины, один EDS файл.

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

Это геморойный путь , но все равно получиться что это 128 узлов, иначе никак , смысл это делать на одной железке это уже другой вопрос

 

PS. В последнем варианте DS301 (от 07.2007) они убрали виртуальные узлы и предлагают использовать MPDO

[syoma 1]

Если ли правило генерации COB-ID, описанное стандартом CANOpen для остальных PDO или его нет? И если нет, то это делает разработчик и это будет его собственное расширение никак не совместимое с другими решениями?

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

По крайней мере в книжке "Embedded networking with CAN and CANOPEN" как вполне нормальное решение описывается, такой вариант:

Если количество узлов в сети известно, например не более 32, то вполне нормально "украсть" PDOшки у неиспользованых узлов. Таким образом узел 1 получает к своим предустановленным PDO еще PDO узлов 33, 65 и 97 и т.д.

В итоге получаем 28 TPDO(своих 4 + (12TPDO + 12 RDPO) неиспользуемых узлов) на узел. Плюс еще можно украсть неиспользуемые SDO

Единственное, что ПО должно позволять конфигурировать более 4-х PDO. Не даром же Communication Parameters в Object Dictionary есть для каждого из 512 PDO, независимо от номера узла.