slimjack

А изоляция двигателя выдержит 3кратное перенапряжение?

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

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

Т.е. 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 на выход. Правильно ли я понимаю?

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

Спасибо! Похоже, что уже для меня все стало ясно. Еще вопрос - словарь ограничивает объем данных для одной ячейки или нет? Можно ли тот же 1 Мб в нем хранить? Буду благодарен!

Дело не в этом-просто не до конца понятна идеология. Но спасибо за советы. Буду копать дальше.

Все равно не понял на счет PDO. Значит все-таки в идентификатор PDO закладывается nodeID? Но зачем? Кому нужно знать с какого узла пришли данные? Кому нужна информация о направлении сообщения? Зачем разделять на входящие и исходящие? Если устройство передает PDO, то, естественно, оно знает, что для него это сообщение исходящее. И совсем непонятно, что такое входящее сообщение? Что устройство с nodeID=99 может принимать только те PDO, в идентификаторе которых зашит nodeID=99? А если оно хочет принять PDO от других устройств в сети? Ну может в первом варианте нет, но в итоге понадобится гибкость и совместимость. Проектируется распределенная система сбора данных. Разрабатывается не одно устройство, а несколько - контроллер и несколько типов датчиков. Предполагается возможность использования устройств ввода-вывода сторонних производителей (хотя это не обязательно). Но система должна быть масштабируема и универсальна. Если разрабатывать свой протокол, в итоге получу исковерканую версию какого-нибудь стандартного протокола. Зачем тогда мучаться - можно использовать уже готовый протокол. И по поводу SDO. Правильно ли я понял - каждому узлу в сети назначается по 2 SDO (не более)?

В сети предполагается два "умных" устройства. Одно собирает инфу с цифровых датчиков, а второе - тоже что-то типа датчика, но оно собирает высокочастотные куски осциллограмм (т.е. размер большой, до 1 Мб) и некоторые из них отправляет на первое устройство. Т.е. без SDO никак. По поводу PDO можете подсказать для они чего разделяются на входящие и исходящие (Rx Tx)? Какой смысл? Я пока для себя понял, есть PDO с каким-то идентификатором. Он попадает в сеть (неважно откуда) и тот, кому надо, подбирает его. Зачем тут делить на входящие и исходящие? У меня есть устройство (датчик) с контроллером ATTiny (128 б ОЗУ), получится ли реализовать хоть что-нибудь от CANopen?

Добрый день! Не хотел плодить новые ветки и решил написать сюда, т.к. похоже тут собрались знатоки CANopen. Не ругайте сильно (возможно будут глупые вопросы), но очень хочется получить простое, доступное объяснение основ CANopen. Я перерыл форум, почитал стандарты, читал статьи, но все равно как-то все смутно. Правда я не разглядывал исходники (CANfestival и CANopenNode). Попытаюсь объяснить как я понимаю CANopen, попутно задавая вопросы в непонятных местах. Итак, пользовательское приложение не видит сеть напрямую - оно видит словарь обектов, который представляет собой массив переменных, которые связаны с параметрами, допустим, технологического процесса (температуры, токи и т.д.), а также с параметрами настройки режимов работы самого устройства. Т.е. (как я понимаю) часть словаря - личные данные конкретного устройства, а другая часть - общие данные всей сети (т.е. такие же данные могут находиться и в словаре другого устройства). Т.о. пользовательскому приложению не нужно знать о существовании сети, оно просто берет данные из словаря (например, чтоб узнать текущую влажность воздуха) или записывает данные в словарь (например, давление масла, если это давление измеряется непосредственно данным устройством). Перемещением данных между словарями занимается CANopen. Обмен между словарями производится посредством сетевых объектов PDO и SDO. PDO сообщения могут переносить до 8 байт полезной информации и используются для передачи данных о тех. процессе. PDO являются широковещательными сообщениями. Источником (производителем) PDO должно быть устройство которое непосредственно вычисляет или измеряет какой-то параметр, входящий в PDO. Каждый PDO имеет свой уникальный идентификатор (именно он и указывается в качестве идентификатора в сообщении CAN). Т.о. устройство измеряет какие-то параметры и пишет их в словарь. В этом же словаре хранится информация о том, какие данные, в каком порядке и в какое PDO нужно упаковать. Также для каждого PDO существуют правила отправки в сеть (по времени, по изменению, по синхроимпульсу и т.д.). Если выполняется условие отправки, CANopen упаковывает данные со словаря в PDO и отправляет их в сеть. Другие устройства в сети, если они настроены на прием данного PDO (определяется по идентификатору), принимают это PDO и распихивают его содержмое по словарю в определенные ячейки. Теперь вопрос: для чего разделяются PDO на входящие и исходящие (Rx Tx)? Правильно ли я понял, что идентификатор PDO не подразумевает привязки к устройству (т.е. в нем отсутствует информация, о том кто именно в сети отправил PDO)? Если требуется передать какую-то часть словаря размером более 8 байт, необходимо применять SDO сообщения. Существует два типа SDO (для передачи информации и для подтверждения). В виду необходимости подтверждения SDO подразумевает только соединение точка-точка. Через SDO одновременно передается только один объект словаря (а в PDO можно несколько), но он может быть большим (более 8 байт). Дальше у меня практически одни вопросы. 1. При передаче SDO, что из себя представляет идентификатор сообщения? Есть ли в нем адрес конкретного устройства? 2. Какое отношение приложение имеет к SDO? 3. Как устанавливается связь между SDO и объектом словаря? Просьба - разъясните мне "на пальцах", я не смог найти ответы на свои вопросы из спецификаций.

http://focus.ti.com/docs/prod/folders/print/sn65mlvd040.html Где-то в апноутах NI предлагается входы передатчиков подтянуть навсегда к единице, а данные подавать на вход разрешения передатчиков. При этом если передается логический ноль, передатчик отключается и диф. напр. равно 0, что для приемников Типа 2 означает логический ноль (для приемников Типа 1 - это неопределенное состояние).

По поводу FlexRay. Уже очень даже доступны в Украине драйвера но никто не хочет продавать контроллеры с FR или stand-alone FR контроллеры. Очень скупая информация в интернете по этому протоколу (если сравнивать с CAN). И у меня такой вопрос. Шина M-LVDS Type-2 (вроде техасовская фишка), как я понял, позволяет реализовать доминантное и рецессивное состояние шины, т.е. неразрушающий арбитраж. Т.е. как бы имеем физическую среду для CAN с большими скоростями (хотя расстояние небольшое, но лично в моем случае и 5 м хватит). Но как теперь заставить CAN контроллер работать, например, на 10 МГц? Собираюсь освоить TMS320f28335 - в доке пишут, что CAN до 1 Мбит (подробно еще не изучил). Как вариант, можно использовать какойнить шустрый контроллер с программным CAN, но где взять этот софтовый CAN?

Спасибо! Простите за глупые вопросы, но есть еще. 1. Так если я объединю "общие" (я имею в виду не земли) всех драйверов (даже удаленных на, например, 100 м), т.е. добавлю третий проводник в кабель, то от этого станет только лучше, я правильно понял? 2. Я имею в виду конец кабеля, где нет ни драйвера ни устройства. Но в кабеле, например, есть питание, к которому можно подключить стабилизатор 2.5В и подключить эти 2.5В в среднюю точку терминатора. Можно ли так? 3. И как я понял, подтяжка линии, это не просто желательно, а необходимо. Иначе приемники будут ловить "мусор"? 4. Как правильно соединить "общий" линии (он же общий всех драйверов) с "землей": через резистор 100 Ом? через резистор и конденсатор, соединенные последовательно? через резистор и конденсатор, соединенные параллельно? 5. Соединение "общего"с "землей" нужно делать только в одной точке или возле каждого драйвера? Большое спасибо за помощь! У некоторых драйверов CAN есть вывод Vsplit или Vref равный 2.5В, который предназначен для подтяжки средней точки терминатора. Не совсем понял замечания. На схеме 0V_1 и 0V_2 - это разные цепи.

Спасибо за ответ! Появились еще вопросы. 1. Если удаленные устройства (с изолированным интерфейсом) связаны между собой только через диф. пару (нет никакого третьего проводника, земли, корпуса и т.д.), то, как я понимаю, эти устройства могут приобретать различные и разные потециалы (и даже очень высокие). Не пробьет ли изоляторы и не повредится ли драйвер линии? 2. Вопрос по терминированию. Рекомендуется в шинах CAN разделять терминаторы на две части, а среднюю точку соединять через кондер на "общий" драйвера. Но зачастую удобнее ставить терминатор в конце линии, а не в последнем устройстве. И куда в таком случае зацепить кондер ("общего" драйвера поблизости нет)? 3. Тоже терминирование. Если все драйвера переходят в третье состояние линия повисает в воздухе. Пишут, что это плохо. Не пойму чем. То ли в линии наводится напряжение, но ведь линия дифференциальная - вроде не должно. Рекомендуют подключить среднюю точку терминатора к источнику напряжения 2.5 В. Но этот источник привязан будет к "общему" только драйвера, возле которого установлен терминатор. Для остальных это ничего не значит. Что я тут неправильно понимаю? И можно ли использовать в качестве источника 2,5В внешний (не встроенный в драйвер) источник? 4. Почему в документации на CAN Open в описании разьема "общий" указан как обязательный (третий) проводник? 5. На картинке схема, с помощью которой я хочу до конца понять как правильно соединять удаленные устройства. Нужно ли точки А и В подключать к источнику 2.5 В? Правильно ли я подключил экран? Нужно ли "общие" приемопередатчиков (драйверов) привязывать к "земле" и правильно ли я это сделал? Спасибо!

Все-таки непонятно, обязательно ли соединять 0V двух или более приемопередатчиков (изолированы от устройств по линиям RX/TX и питанию) в сети CAN? И зачем? В некоторых статьях на RS-485 показано соединение общих точек, но через резистор 100 Ом, в некоторых - напрямую. Пока из прочтенной документации складывается впечатление, что общий всех приемопередатчиков нужно объединять. Но в документации на кабель для CAN показана только одна витая пара, третьего провода нет! Вот и смутился.