CANOpen, С чего начать? Опции

[Chip115]

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

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

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

[Golikov A.]

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

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

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

[syoma]

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

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

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

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

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

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

[_3m]

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

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

Также не забываем - Heartbeat имеет самый низкий идентификатор и следовательно самый высокий приоритет, то есть он не может быть задавлен PDOшками. В CANopen все продумано

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