[геннадий75 1]

6 часов назад, AKK сказал:

 (ни разу не видел автомобиль с двумя дизельными двигателями)

Насчёт двух моторов в одной машине тоже не видел . А два ,не зависимых друг от друга блока управления двигателя с 2000 года, притеняются в авто . Причём он может быть как master так и scave и иметь разные ID .

[jcxz 184]

4 минуты назад, геннадий75 сказал:

Насчёт двух моторов в одной машине тоже не видел .

Так посмотрите:  https://www.ixbt.com/news/2020/07/22/tesla-ford-mustang-mach-e-7-1400.html

Правда не 2, а 7.  

[AKK 0]

4 hours ago, Eddy_Em said:

Возможно, в современных автомобилях заводят несколько CAN-шин. Но я сомневаюсь, что найдется горе-инженер, который на CAN-шину жизненно важных цепей (ESP, ABS и управление двигателем) повесит не особо важные вроде фар, стеклоподъемников и магнитол…

 

Привет французам и китайцам, по вашему - они горе инженеры :-). Магнитолу пока в CAN не подключили, но датчики топлива, уровня охлаждающей жидкости, датчик температуры, крена и тангажа, управление адаптивными фарами и т.д. - успели.

1 hour ago, jcxz said:

Вот! Вот в этом и причина почему это работает в той системе - адрес фиксированный и заранее известный всем остальным участникам обмена по шине. У ТС совсем другая ситуация, поэтому ваш пример с автомобилем не подходит к данной теме.

Именно по этому я и привел пример с гидравлическими распределителями для грузоподъемной технике (типа автомобильный кран), где на каждую секцию вешается один и тот же блок, а у гидрораспределителя секций может быть мнооого ...., а еще гидрораспредилетель может быть не один, а два (встречал даже с 3, общее количество гидравлических секций в этой машине было 15 шт.).

По поводу идентификаторов. Идентификатор CAN ID 29 битный, в него входит адрес устройства (source address). А уникальный идентификатор устройства, ранее я его обозначал как NAME устройства (чтобы не путать с CAN ID), передается в поле данных, которых 8 байт или 64 бита, и выдается при подключении в сеть или по запросу от любого другого устройства.

Не вижу причин, почему этот механизм не будет работать на 11 битном can id. 

Есть предложение - сперва прочитайте стандарт, разберитесь в том, что он предлагает в части network menagement. Потом, если останутся вопросы - задавайте. А поддерживать далее тему в данном ключе считаю флудом, не помогающим ТС, поэтому отвечать на неконструктивные вопросы не буду.

2 hours ago, геннадий75 said:

Насчёт двух моторов в одной машине тоже не видел . А два ,не зависимых друг от друга блока управления двигателя с 2000 года, притеняются в авто . Причём он может быть как master так и scave и иметь разные ID .

 

2 hours ago, jcxz said:

Так посмотрите:  https://www.ixbt.com/news/2020/07/22/tesla-ford-mustang-mach-e-7-1400.html

Правда не 2, а 7.  

Опять же речь идет о дизельных двигателях. Ясен пень, что в гидбридных и электрических их больше одного. Как правило на каждый силовой электромотор есть свой контроллер, который следит только и исключительно за своим двигателем, а контроллер трансмиссиии координирует их работу. И не надо тут о том, что ВОТ ПОЯВИЛСЯ КООРДИНАТОР сети. Это не координатор сети, а координатор движения машины по дороге, обеспечивающий согласование работы колес, к каждому из которых привязан свой мотор.

 

Тфу, блин, опять во флуд втянули ......

[bezobraznic 0]

На данный момент победил вариант ув. JCXZ  его и прорабатываю. Всем спасибо!

[jcxz 184]

17 минут назад, AKK сказал:

По поводу идентификаторов. Идентификатор CAN ID 29 битный, в него входит адрес устройства (source address). А уникальный идентификатор устройства, ранее я его обозначал как NAME устройства (чтобы не путать с CAN ID), передается в поле данных, которых 8 байт или 64 бита, и выдается при подключении в сеть или по запросу от любого другого устройства.

"По запросу" каким образом??? По какому CAN-ID? Как запросить устройство если его адрес не известен?

"выдается при подключении в сеть" - опять с каким CAN-ID выдаётся этот CAN-кадр?

С каким CAN-ID вы собрались передавать в шину эти 8 байт если имеется только длинный 64-битный NAME?

Вот именно про это и был вопрос. И это не возможно без коллизий в поле данных. Если конечно знать как работает CAN-шина.  

Я об этом говорил ещё в первых сообщениях в этом топике.

Цитата

Не вижу причин, почему этот механизм не будет работать на 11 битном can id. 

На каком??? Напишите конкретное содержимое CAN-кадра. Тогда может и поймёте почему это не получится.

Цитата

Есть предложение - сперва прочитайте стандарт, разберитесь в том, что он предлагает в части network menagement.

Может вы сперва прочитаете что такое CAN-шина и как она работает?  

[AKK 0]

On 10/30/2020 at 5:09 PM, jcxz said:

Может вы сперва прочитаете что такое CAN-шина и как она работает?  

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

работаю больше 8 лет, знаю как она работает получше вашего.

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

[jcxz 184]

4 часа назад, AKK сказал:

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

По какому "определению"? Просветите. А то мы тут все тёмные - никто кроме вас с CAN-шиной не работал и не знаем ничего.  

[Edit2007 3]

Уважаемые AKK и jcxz, поправте меня если я не прав.

Если два узла одновременно начинают передачу, то на этапе арбитража сообщения шину захватывает устройство с более приоритетным сообщением.

Арбитраж осуществляется только в процессе передачи идентификатора сообщения (CAN ID)

Приоритет определяется по типу идентификатора (11-битный имеет приоритет выше чем 29-битный) и значению идентификатора (меньшее значение CAN ID имеет более высокий приоритет). Сообщения с флагом удаленного запроса (Remote Ask) имеют приоритет ниже чем обычные сообщения.

Если два узла одновременно будут передавать одинаковый CAN ID, то арбитраж не сможет выявить "победителя". Оба узла начнут передавать данные, и на этом этапе возникнет коллизия (ошибка, сбой), которую можно будет обнаружить только после расчета контрольной суммы сообщения. И сообщение уйдет в "мусор", как недостоверное.

[jcxz 184]

6 минут назад, Edit2007 сказал:

Уважаемые AKK и jcxz, поправте меня если я не прав.

Почти так. За небольшим уточнением, что арбитраж осуществляется не только по CAN-ID, а и ещё по нескольким битам. Но сути это не меняет - в целом Вы правы.

8 минут назад, Edit2007 сказал:

Если два узла одновременно будут передавать одинаковый CAN ID, то арбитраж не сможет выявить "победителя". Оба узла начнут передавать данные, и на этом этапе возникнет коллизия (ошибка, сбой), которую можно будет обнаружить только после расчета контрольной суммы сообщения. И сообщение уйдет в "мусор", как недостоверное.

Именно так. Об этом я тут уже неоднократно и говорил. Но видимо AKK, "работающий с CAN больше 8 лет", об этом не догадывается. 

[Arlleex 131]

34 минуты назад, Edit2007 сказал:

Если два узла одновременно будут передавать одинаковый CAN ID, то арбитраж не сможет выявить "победителя". Оба узла начнут передавать данные, и на этом этапе возникнет коллизия (ошибка, сбой), которую можно будет обнаружить только после расчета контрольной суммы сообщения. И сообщение уйдет в "мусор", как недостоверное.

Не совсем так. В случае, если оба CAN ID совпали при передаче, но данные в них разные, то:

• узел, передающий рецессивный уровень, увидев доминантное состояние шины, выставит у себя некий флаг "Bit Error";
• узел, передающий доминантный уровень, ошибку не обнаружит, но это и не столь важно (см. далее).

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

Таким образом, если в шине несколько узлов одновременно отправляют одинаковые данные по одним и тем же ID - страшного ничего не будет.
Если отправляют разные данные - один из них (кто первый отправил рецессивный бит) разрушит трафик. В целом, это не нештатная ситуация на шине.
Однако при интенсивном обмене может сильно ее нагрузить повторными передачами и сопроводить соответствующими штрафами вплоть до Bus Off.

[AKK 0]

18 hours ago, Arlleex said:

Не совсем так. В случае, если оба CAN ID совпали при передаче, но данные в них разные, то:

• узел, передающий рецессивный уровень, увидев доминантное состояние шины, выставит у себя некий флаг "Bit Error";
• узел, передающий доминантный уровень, ошибку не обнаружит, но это и не столь важно (см. далее).

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

Таким образом, если в шине несколько узлов одновременно отправляют одинаковые данные по одним и тем же ID - страшного ничего не будет.
Если отправляют разные данные - один из них (кто первый отправил рецессивный бит) разрушит трафик. В целом, это не нештатная ситуация на шине.
Однако при интенсивном обмене может сильно ее нагрузить повторными передачами и сопроводить соответствующими штрафами вплоть до Bus Off.

Спасибо, что объяснили вместо меня знатоку сетей jcxz прописные истины.

 

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

 

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

[AKK 0]

ага, дали свет :-) !

 

Подводя итог:

- два устройства имеют одинаковые CAN ID, одинаковые данные, передают в одно время - оба блока передадут данные успешно и не заметят, что передача была дублирована.

- два устройства имеют одинаковые CAN ID, разные данные, передают в разное время - оба блока передадут сообщения успешно.

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

По поводу захвата арбитража линии по CAN ID - все тоже самое, только счетчик ошибок увеличиваться не будет.

Изменено 3 ноября, 2020 пользователем AKK

[Arlleex 131]

2 часа назад, AKK сказал:

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

Это справедливо только для узлов, находящихся в состоянии пассивной ошибки.
В случае, если узел находится в состоянии активной ошибки, он не отвалится, а разрушит весь трафик передачей флага активной ошибки.

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

[Edit2007 3]

30.10.2020 в 06:33, AKK сказал:

Если взять контроллер гидравлического распределителя (для грузоподъемной техники), управляемого по CAN, то там есть возможность задания адреса. Никто не станет делать отдельный уникальный девайс на каждую секцию гидрораспределителя, это попросту глупо. Что хорошо коррелирует с данным конкретным случаем. В качестве дополнительных примеров могу привести джойстики (устанавливается до 4 шт в систему) если поковыряться еще можно накопать устройств с одинаковым ПО.

Разрядность уникального идентификатора устройства составляет согласно спецификации 64 бита (т.е. все 8 байт информации), из них только 21 бит приходится на собственно идентификационный номер, остальные - код производителя, выполняемая функция и т.д.

Еще вопросы? (отвечаю медленно, т.к. часто в разъездах, работы много).

Такой вопрос возник, Предположим что есть 2 гидрораспределителя один с правого борта, другой с левого (они же формально одинаковые). Система сможет прописать им адреса для обмена по CAN шине, чтобы не было конфликтов при работе. Но как она определит, какой из них справа, а какой слева для корректного управления? Или это прописывается при монтаже гидрораспределителя на машину через сервисное ПО?

[haker_fox 60]

3 minutes ago, Edit2007 said:

Но как она определит, какой из них справа, а какой слева для корректного управления?

А это сильно важно? В принципе, может чуть-чуть подёргать каким-либо исполнительным механизмом через распределитель и по датчикам в обратной связи соориентироваться, где какой стоит. Но я бы не стал так делать...