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

[Chip115]

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

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

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

[syoma]

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

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

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

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

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

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

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

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

[Golikov A.]

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

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

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

[_3m]

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

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

[syoma]

На самом деле поностью отказаться от конфигуратора проблематично. Кто то все равно должен следить за всеми устройствами как минимум для реакциии на внезапный "отвал" какого либо из узлов. Все пакеты в кан широковещательные и посылающий узел не узнает что тот кому адресован пакет его уже не слышит.

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

Да у меня есть один опасный момент где хорошо бы знать что все кто надо все что надо сделали.

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

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

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