[Golikov 0]

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

 

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

 

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

[syoma 1]

Кстати стандарт CANopen есть на местном FTP. Правда с тех пор уже куча стандартов доступна для свободного доступа. Не бойтесь на CAN-CIA спрашивать. Они в течении пары дней свободные стандарты высылают, если данные правдивые написали.

А кто в сети переводи устройства из режима преоператед, в оператед?

Написал в предыдущем сообщении.

[_3m 7]

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

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

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

В этом отношении запросы к SDO серверу лучше поскольку они идут с подтверждением. Т.е выдавать команду на подрыв лучше через SDO.

DS301 в сети находится без проблем, а это один из основных документов.

[Golikov 0]

Угу я запросил доки, поглядим...

 

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

 

Главная трудность в понимании канопен - это выбросить из головы все другие протоколы, и понять что тут другой уровень абстракции, я когда читал все пытался мыслить устройствами, узлами, их обменами друг с другом. А тут фактически все устройства говорят с глобальным словарем, да и то механизм разговора скрыт, пока это не поймешь схемы из доков не помогают ни разу:)...

 

Значит придется еще NMT устройство назначить....

 

 

[Golikov 0]

ой сдублировалось:(

[_3m 7]

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

Тут надо думать о вашей конктерной задаче.

Вы получаете опасные данные или посылаете их?

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

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

Про Remote frame сразу забудьте. CiA в рекомендациях настоятельно советует избегать применения Remote frame.

 

 

 

[Golikov 0]

Странно, ремот фрейм есть, и вроде бы даже я в стандарте видел что есть ремот PDO, а просят избегать, ну да ладно, просят будем избегать:)

 

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

 

Хотя и по SDO там тоже не много данных собрать надо... подумаем...

 

Спасибо всем за разъяснения, вроде бы стало понятно что за чем и как, остаются уже рабочие моменты, но поняв концепцию это уже просто...

 

 

[syoma 1]

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

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

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

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

 

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

Хотя и по SDO там тоже не много данных собрать надо... подумаем...

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

[Golikov 0]

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

 

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

 

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

 

 

[syoma 1]

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

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

 

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

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

NMT мастер же отличается от слейва только тем, что мастер посылает а слейв принимает сообщения о запуске сети или узла,т.е перевода его в различные состояния.

 

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

В SDO-обмене - сервер - это тот узел к которому залазят в его объектный словарь за данными или запихивают что-то туда.

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

 

[Golikov 0]

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

 

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

 

А для важных узлов можно сделать PDO эхо, хотя это здорово загрузить сеть всяким мусорным трафиком

 

 

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

 

А вот у меня вопрос про переменные словаря, правильно я понимаю что одна и та же переменная может быть использована во многих устройствах? И следовательно все они могут иметь едины приемный PDO который эту переменную настраивает, или такое в стандарте не разрешается? Правильно я понимаю что устройство хранит только ему нужную часть словаря?

 

Могут ли 2 разных объекта слать одинаковые идентификаторы PDO (вроде бы нет, иначе они могут одновременно их послать, и будет коллапс)? Есть ли ограничение на количество обрабатываемых PDO на приеме? На что выделены 2 входных PDO, чтобы гарантировать возможность как минимум 2 другим устройствам задавать переменные? А если надо чтобы это могли сделать 3 или больше устройств, занимать PDO у других что их не используют?

А мастера на шине имеют огромный список исходящих PDO?

[syoma 1]

Могут ли 2 разных объекта слать одинаковые идентификаторы PDO (вроде бы нет, иначе они могут одновременно их послать, и будет коллапс)? Есть ли ограничение на количество обрабатываемых PDO на приеме? На что выделены 2 входных PDO, чтобы гарантировать возможность как минимум 2 другим устройствам задавать переменные? А если надо чтобы это могли сделать 3 или больше устройств, занимать PDO у других что их не используют?

А мастера на шине имеют огромный список исходящих PDO?

Опять упираемся в понимание PDO - я Вам советую - забудьте вы этот Predefined Connection Set - это просто пример, и в реальной сети конфигурация может быть совсем другая.

 

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

Спокойно можно сделать. Главное, чтобы переменная "Состояние" могла меппиться в соответсвующее TPDO.

 

А вообще советую почитать соседнюю тему, где мы обсуждали сокраментальный смысл PDO http://electronix.ru/forum/index.php?s=&am...st&p=886979

 

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

Да правильно.

Правильно я понимаю что устройство хранит только ему нужную часть словаря?

Нет. Каждое устройство имеет свой локальный словарь.

 

Короче, вот пример использования PDO:

Допустим у нас есть узлы 1,2 и 3, связанные по CANopen. Узел 1 стоит на улице и измеряет температруру воздуха. Узлы 2 и 3 должны знать эту температуру, чтобы регулировать обороты вентилятора в ванной и на кухне.

Чтобы это реализовать в узле 1 в его объектном словаре есть переменная "Температура воздуха", куда с АЦП записывается температура, непосредственно им измеряемая.

В узлах же 2 и 3 в ихних локальных объектных словарях есть переменная "Температура уличного воздуха" - которую считывает алгоритм управления вентилятором в этих узлах.

Чтобы все как-то заработало необходимо, чтобы переменная "Температура уличного воздуха" отображала значение переменной "Температура воздуха".

Для этого нужно сделать дальнейшие действия только один раз при настройке сети:

Узел 1 настраивает TPDO с адресом XXX, в которое маппится переменная "Температура воздуха", и настраивает это TPDO на передачу по изменению значения переменной. Таким образом при изменении температуры воздуха в сети появится сообщение с идентификатором XXX и значением температуры. Чтобы узлы 2 и 3 принимали это сообщение, мы настраиваем в них RPDO с адресом XXX и маппим туда переменную "Температура уличного воздуха". Таким образом если узлы 2 и 3 принимают PDO с таким адресом, они автоматически достают из сообщения нашу температуру и записывают ее в локальный словарь.

После проделывания данных процедур сеть начнет работать, и узлы 2 и 3 смогут узнать температуру воздуха просто посмотрев в свой локальный словарь и прочитав переменную "Температура уличного воздуха". И неважно, что она измеряется совершенно другим узлом за тридевать километров - всю работу, связанную с обновлением локальной переменной возъмет на себя CANopen.

[Golikov 0]

Все всосал:)... я думал что словарь глобальный на всю сеть, и каждый узел просто отрезает себе от него кусочек.

 

Начальные TPDO и RPDO - это настройка для простоты, то есть можно брать узлы и встраивать их в систему с адресом, и всегда знать как к нему обратиться чтобы что-то записать, и понимать какое сообщение придет от него с данными, и не более того... Так?

 

Спасибо за тему соседнюю, я ее уже читал, перечитаю с новым пониманием.

[syoma 1]

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

Примерно так, но только с SDO. PDO всегда надо настраивать ручками. В принципе в CANopen всегда есть возможность просканировать сеть - каждый узел хотя-бы один раз при включении выплевывает в сеть одно сообщение с идентификатором равным номеру узла - это т.н. Bootup message. Зная этот идентификатор автоматически определяются идентификаторы для обмена SDO сообщениями с этим узлом. Они равны 580h+Node_ID и соответственно 600h+Node_ID. Таким образом с помощью SDO клиента можно всегда получить доступ к любому узлу в сети, даже если сеть еще не сконфигурирована. Как я уже говорил - такой клиент - это PC с CANopen конфигуратором и сканером.

А получив доступ к словарю через SDO - уже можно настроить идентификаторы и параметры PDO. После этого все параметры записывается во флеш и сеть запускается. С этого момента обмен через SDO становится больше не нужен - когда параметры PDO заданы - узлы сами будут обмениваться PDOгками даже после перезагрузки.

[_3m 7]

Я тоже когда изучал 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 слабо реализован.