AKK

ага, дали свет :-) ! Подводя итог: - два устройства имеют одинаковые CAN ID, одинаковые данные, передают в одно время - оба блока передадут данные успешно и не заметят, что передача была дублирована. - два устройства имеют одинаковые CAN ID, разные данные, передают в разное время - оба блока передадут сообщения успешно. - два устройства имеют одинаковый CAN ID, разные данные, передают в одно время. Один блок, в котором раньше встретится рецессивный бит, выставит ошибку, увеличит внутренний счетчик ошибок и отвалится от передачи. Другой, в котором первым встретиться доминантный бит, продолжит свою работу и выдаст сообщение в линию. После завершения передачи первый блок (если в нем установлен режим многократных попыток передачи), попытается отправить сообщение снова. Как только количество ошибок в каком-либо блоке достигнет максимум CAN модуль отвалиться (перейдет в состояние Bus Off). По поводу захвата арбитража линии по CAN ID - все тоже самое, только счетчик ошибок увеличиваться не будет.

Спасибо, что объяснили вместо меня знатоку сетей jcxz прописные истины. Маленькое замечание: при работе с модулем CAN в контроллере смотрите настройки, можно настроить на однократную отправку сообщения. В этом случае в случае неудачи сообщения (потери арбитража линии) контроллер выставит ошибку передачи данных. Если модуль настроен на многократную отсылку сообщений, то он при потере арбитража попытается выдать свое сообщение еще раз. До тех пор, пока не наберется критическая масса ошибок (как правило это число составляет 255), после чего модуль остановиться до обработки состояния ошибки и перестанет пытаться отослать что либо в CAN линию. Здесь есть подводный камень: если вы пытаетесь выдать в линию сообщение с наименьшим приоритетом, то при большой загруженности линии блок может пытаться делать это довольно долго безуспешно, срывая таймауты в том числе и более приоритетным сообщениям, но попавшим в физический буфер передатчика позднее наименее приоритетного. Именно этим и обосновывается рекомендация максимальной загрузки сети не более 30%. Как правило, при разруливании адресов в сети устанавливается посылка с однократной попыткой передачи, в случае неудачи выставляется случайная выдержка времени до попытки повторной передачи сообщения. Ой, свет вырубают, на сегодня все - наработался.

Еще раз - прочтите документ, на который я ссылался, там есть все ответы на поставленные вопросы. С CAN шиной работаю больше 8 лет, знаю как она работает получше вашего. Если изучите механизм работы CAN линии, то поймете, что коллизий в ней не может быть по определению. Учите матчасть.

Привет французам и китайцам, по вашему - они горе инженеры :-). Магнитолу пока в CAN не подключили, но датчики топлива, уровня охлаждающей жидкости, датчик температуры, крена и тангажа, управление адаптивными фарами и т.д. - успели. Именно по этому я и привел пример с гидравлическими распределителями для грузоподъемной технике (типа автомобильный кран), где на каждую секцию вешается один и тот же блок, а у гидрораспределителя секций может быть мнооого ...., а еще гидрораспредилетель может быть не один, а два (встречал даже с 3, общее количество гидравлических секций в этой машине было 15 шт.). По поводу идентификаторов. Идентификатор CAN ID 29 битный, в него входит адрес устройства (source address). А уникальный идентификатор устройства, ранее я его обозначал как NAME устройства (чтобы не путать с CAN ID), передается в поле данных, которых 8 байт или 64 бита, и выдается при подключении в сеть или по запросу от любого другого устройства. Не вижу причин, почему этот механизм не будет работать на 11 битном can id. Есть предложение - сперва прочитайте стандарт, разберитесь в том, что он предлагает в части network menagement. Потом, если останутся вопросы - задавайте. А поддерживать далее тему в данном ключе считаю флудом, не помогающим ТС, поэтому отвечать на неконструктивные вопросы не буду. Опять же речь идет о дизельных двигателях. Ясен пень, что в гидбридных и электрических их больше одного. Как правило на каждый силовой электромотор есть свой контроллер, который следит только и исключительно за своим двигателем, а контроллер трансмиссиии координирует их работу. И не надо тут о том, что ВОТ ПОЯВИЛСЯ КООРДИНАТОР сети. Это не координатор сети, а координатор движения машины по дороге, обеспечивающий согласование работы колес, к каждому из которых привязан свой мотор. Тфу, блин, опять во флуд втянули ......

Конечно смогут, если все устройства, завязанные на кнопки и исполнительные элементы в наличии. Если не верите - поэкспериментируйте: выдерните контроллер двигателя, а потом попробуйте поуправлять чем-либо, не завязанным на двигатель. Или под ЭБУ вы имели ввиду контроллер управления электрооборудованием. Ясен пень, в этом случае стеклоподъемники работать не будут, ведь управляющие сигналы на двигатели стеклоподъемников формирует именно контроллер электрооборудования. а аварийка как правило не завязана на какие-либо шины, а включается напрямую через специальное реле к поворотникам.

ЭБУ - электронный блок управления, собирательное название. Конкретнее пожалуйста. Блок управления чем? Двигателем? Ясен пень, без него не двинется, ведь двигателем управлять нечему. Только причем тут координатор?

Не совсем понимаю ваш вопрос, возможно у нас проблема с терминологией. В моем случае под CAN я понимаю общие физические принципы передачи данных по сети (типа RS485), под протоколами верхнего уровня SAE J1939 то, каким правилам подчиняются данные передаваемые по этой самой сети (типа MODBUS). Т.е. ваша передача данных поверх CAN, если я все правильно понял, и есть то, что я понимаю под протоколами верхнего уровня, т.е. SAE J1939. И я не призываю использовать именно данный стандарт (кстати действительно мега-крутой, над ним не одна сотня голов поумнее наших с вами работала не один год). Вопрос был - как организовать сканирование устройств в сети, я и привел пример как это осуществляется в данном протоколе, который уже ни один год УСПЕШНО работает на сотнях тысяч грузовых машин ВСЕХ крупнейших производителей данной техники и помирать, что показательно, не собирается. Да, речь идет о CAN сети. Разрядность CAN ID - 29 бит. Протокол SAE J1939-81, который я привел в пример, в том числе и определяет каким образом блоки в сети договариваются о своих sourse address (младшие 8 бит CAN ID). Добавить еще один контроллер двигателя никто не мешает, если производителем контроллера это предусмотрено. По факту в подавляющем большинстве случаев контроллер двигателя относится к одноадресным неконфигурируемым устройствам (ни разу не видел автомобиль с двумя дизельными двигателями). Но! Если взять контроллер гидравлического распределителя (для грузоподъемной техники), управляемого по CAN, то там есть возможность задания адреса. Никто не станет делать отдельный уникальный девайс на каждую секцию гидрораспределителя, это попросту глупо. Что хорошо коррелирует с данным конкретным случаем. В качестве дополнительных примеров могу привести джойстики (устанавливается до 4 шт в систему) если поковыряться еще можно накопать устройств с одинаковым ПО. Разрядность уникального идентификатора устройства составляет согласно спецификации 64 бита (т.е. все 8 байт информации), из них только 21 бит приходится на собственно идентификационный номер, остальные - код производителя, выполняемая функция и т.д. Еще вопросы? (отвечаю медленно, т.к. часто в разъездах, работы много). Назовите мне блок координатор в CAN сети, ну скажем грузовика производства КАМАЗ?? Ну или любого другого, на Ваш выбор. Просветите, кто там координатор, буду благодарен.

Все уже давно придумано за нас. Здесь большую роль играет протокол верхнего уровня. Например, если вы работаете в стандарте SAE J1939, то Вам нужно читать часть J1939-81 (NETWORK MANAGEMENT), которая собственно и посвящена данному вопросу. Или искать в используемом Вами протоколе верхнего уровня подобный раздел. Если используется "самопальный" протокол верхнего уровня, то рекомендую прочитать то, что давно изобретено. Если вкратце (исходя из SAE J1939): каждый блок, регистрируюсь в сети при включении посылает "address claim" со своим адресом и NAME (не знаю как поточнее перевести, но в этом NAME целый пласт инфы от производителя до кода с кратким описанием функционала), если адрес свободен, то занимает его если адрес занят, то там целая процедура разруливания кто и с какого адреса работать будет. Но смысл в том, что если адрес занят, то блок занявший этот адрес отвечает на сообщение что адрес занят. А если послать запрос "addresss claim" на широковещательный адрес (0x255), то ответят ВСЕ блоки с указанием адресов по которым они общаются. После чего зная занятые адреса можно запросить у каждого из блоков его HARD ID, SOFT ID и т.д. Там еще много тонкостей взаимодействия расписано, прочитайте документ, не пожалеете. Тем более в нем всего 40 страниц текста. Тут вы заблуждаетесь. Опять же говорим только о SAE J1939 - данная сеть одноранговая. Все устройства равны, координатора зачастую просто нет. Данная сеть используется в грузовых автомобилях. Кто там важнее: контроллер двигателя, контроллер трансмиссии или контроллер АБС? Зачастую координатора просто нет, что позволяет гибко нафаршировывать автомобиль примочками: нет АБС, да х... на него всем остальным блокам, нашелся в сети контроллер круиз-контроля, добро пожаловать в общую сеть, дружище. А кто там вякает про то, что он координатор, ну попробуй, может что и получится... :-). Просто у каждого из блоков есть стандартизированные входные данные, задавая которые можно менять режимы работы данного конкретного блока, но если никто снаружи ничего не задает, то он выполняет свою функцию по своему разумению, опираясь на полученные данные. Вот и вся координация. Например: контроллер двигателя, если ему идут из сети заказы на поддержание оборотов от контроллера круиз-контроля, то будем держать данные обороты, а если этих сигналов нет, то будем держать обороты, задаваемые педалью газа, подключенной непосредственно к контроллеру. Ну, как-то так.

Гранд мерси.

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

К сожалению к FTP доступа нет, отправил сообщение со своим мылом в личку. Жду с нетерпением. Заранее спасибо.

Ничего особо плохого сказать не могу. Пользуем при отладке и тестировании уже в течении года. Из минусов: 1) Получив первый раз преобразователь не удавалось подцепить его к компу, винда определяла его наличие, но подключать отказывалась. Методом проб и ошибок выявлено, что отверстие под USB разъем сделано криво (недостаточно глубоко) и разъем попросту не до конца вставляется. Была варварским образом выдрана передняя панель :laughing: и ошибки прекратились. 2) Так и не удалось подключить к паре производственных компов (старые, перегруженные софтом машины под управлением XP). Причем данная проблема возникала только с конвертерами серии В (с серией А такой проблемы не возникало). Видимо в серии В чей-то подрезали, подправили и с некоторыми host контроллерами эти девайсы отказались работать. Опять же, подчеркиваю, проявилось только на старинных компах, да и то не на всех, а только на паре штук (собственно старых компов у нас и есть только пара штук ) 3) Было нарекание по работоспособности ПО, шедшего в комплекте (имеется в виду testusbcan). Время от времени оно почемуй-то зависало при непрерывном длительном приеме большого потока данных, не знаю, была решена эта проблема позднее или нет. Мы, воспользовавшись приложенном руководством программиста выпустили собственную программу, заточенную под наши собственные девайсы. С тех пор Славной был выпущен (или использован) какой-то новый софт, но мы его не пользовали. По testusbcan еще одна заморочка — сперва нужно установить подключение к преобразователю, а только потом менять скорость. Причем менять ее надо даже если она установлена в выпадающем списке такой, какая устраивает, иначе подключение происходит на умолчальной скорости (фиг знает какой). На другую скорость необходимо переходить принудительно, не смотря на ту, которая виднеется в окошке ПО :smile3046: . Плюсы: наличие документированного API; низкая стоимость. Т.е. привыкнув к особенностям приложенного старого ПО, дело по отладке наших девайсов сдвинулось с мертвой точки, и в настоящий момент эти девайсы даже производится серийно (и даже работают). И вообще мы этих преобразователей еще несколько штук купили для расширения круга посвященных. P.S. при работе с нашим собственным ПО проблем не наблюдается вообще (за исключением того, что пришлось почти на всех преобразователях отодрать панельки со стороны USB разъема). А в остальном, прекрасная маркиза, все хорошо, все хорошо....

Конечно хотелось бы увидеть и то и другое, но более интересно ADDRESS AND IDENTITY ASSIGNMENTS, т.е. таблицы, по которым можно зашифровать/расшифровать имя (NAME) устройства.

Доброго всем времени суток! Господа, поделитесь где можно глянуть приложение В (интересуют таблицы В2-B9) для SAE J1939.

Буфера FIFO отключены.