[jcxz 182]

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

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

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

О недостатках такого способа я говорил ещё в самом начале. Здесь: 

И здесь: 

 

Так как заведомо будут попытки передачи на шину CAN-кадров с одинаковым ID и разными данными. О чём опять же неоднократно я уже говорил в этой теме. Читайте внимательно.

 

PS: Заведомо закладывать в устройство протокол костыльный колхоз, который будет генерить ошибки на шине - признак безграмотности разработчика.  

 

1 час назад, Arlleex сказал:

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

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

36 минут назад, haker_fox сказал:

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

Подёргать на скорости, в потоке других машин??? 

Хотя уже не удивлюсь если кто-то здесь считает, что это - норм. Есть и здесь такие "специалисты" как видно. 

[Arlleex 131]

28 минут назад, jcxz сказал:

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

А устройства тут причем? Это штатная работа CAN-контроллера, и разработчики на это никак повлиять не смогут.
CAN устроен так, чтобы достоверные данные получили либо все активные устройства на шине, либо ни одного.

[jcxz 182]

2 минуты назад, Arlleex сказал:

А устройства тут причем? Это штатная работа CAN-контроллера, и разработчики на это никак повлиять не смогут.

"Такие устройства" - устройства заведомо создающие ошибки на шине. Разработчики как раз и влияют, если создают такое устройство.

Другое дело если такие ошибки возникают в случае нештатной ситуации, возникшей при эксплуатации.

При штатной работе устройства, не должно быть ситуаций, приводящих к ошибкам на шине.

[haker_fox 60]

45 minutes ago, jcxz said:

Подёргать на скорости, в потоке других машин???

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

46 minutes ago, jcxz said:

Есть и здесь такие "специалисты" как видно.

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

17 minutes ago, jcxz said:

При штатной работе устройства, не должно быть ситуаций, приводящих к ошибкам на шине.

А помехи?

[Arlleex 131]

4 минуты назад, jcxz сказал:

Другое дело если такие ошибки возникают в случае нештатной ситуации, возникшей при эксплуатации.

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

[jcxz 182]

10 минут назад, Arlleex сказал:

Естественно, если в процессе штатной работы несколько устройств могут одновременно пульнуть в сеть разные данные по одним ID - это вред.

Именно это и предлагает AKK (насколько можно понять, пытаясь выудить крупицы смысла из кучи пустых фраз). Передавать CAN-кадры с одинаковыми ID и разными данными на шину в случайное время.

10 минут назад, Arlleex сказал:

Однако, если только протокол гарантирует, что в процессе опознавания и назначения ID, коллизии не переведут участников сети в состояние Bus Off. С этим сложнее.

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

[haker_fox 60]

1 minute ago, jcxz said:

Передавать CAN-кадры с одинаковыми ID и разными данными на шину в случайное время

Гм... по-моему шина не предназначена для таких извращений. Другие приёмопередатчики, получившие ID не смогут ориентироваться в этой каше.

[Arlleex 131]

3 минуты назад, haker_fox сказал:

Другие приёмопередатчики, получившие ID не смогут ориентироваться в этой каше.

Ну, скорее Вы имели ввиду CAN-контроллер. Он как раз сможет ориентироваться что есть каша, а что есть данные от четких братьев-узлов на шине

4 минуты назад, haker_fox сказал:

Гм... по-моему шина не предназначена для таких извращений.

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

[Arlleex 131]

1 час назад, jcxz сказал:

Именно это и предлагает AKK... Передавать CAN-кадры с одинаковыми ID и разными данными на шину в случайное время.

Мне показалось, что он имел ввиду некий единичный процесс идентификации, который происходит при старте ПО:

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

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

 

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

[jcxz 182]

39 минут назад, Arlleex сказал:

Мне показалось, что он имел ввиду некий единичный процесс идентификации, который происходит при старте ПО:

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

Особенно - если устройства на шине могут включаться, выключаться, перезапускаться в произвольные моменты времени. Сканировать нужно всегда, периодически. Да ещё и добавить возможность "сбора мусора" (обнаружение отключившихся устройств).

Да и изначальный вопрос ТС однозначно указывал на необходимость периодического скана, и скорей всего - параллельно с остальным обменом по шине:

26.10.2020 в 10:20, bezobraznic сказал:

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

[Edit2007 3]

03.11.2020 в 13:01, haker_fox сказал:

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

Предположим что они управляют гидроцилиндрами подъема кузова - для сброса груза на правую или левую сторону (ну или аутригерами).

Не уверен, что это вариант. Обычно для работы гидравлики на автомобилях требуется запуск двигателя (для создания рабочего давления) или специального мотора.

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

[haker_fox 60]

4 minutes ago, Edit2007 said:

Поэтому, мне кажется, должен быть другой механизм обнаружения.

1. В плату встраивается гироскоп. Слева и справа блоки крепятся с разницей ориентации 180 градусов, это обеспечивается механически, например  сверловкой отверстий определённым образом.

2. На плате паяются страрые добрые dip-переключатели.

3. В посадочном месте блока смонтирован разъём, в котором адрес блока уже задан. При установке блока, его адрес определяется однозначно.

4. Адреса блокам программируются перед подключением к сети.

[bezobraznic 0]

Запустил по алгоритму jcxz. Работает отлично! Обошелся 11битным ID. Спасибо за помощь!

[Edit2007 3]

3 часа назад, haker_fox сказал:

1. В плату встраивается гироскоп. Слева и справа блоки крепятся с разницей ориентации 180 градусов, это обеспечивается механически, например  сверловкой отверстий определённым образом.

2. На плате паяются страрые добрые dip-переключатели.

3. В посадочном месте блока смонтирован разъём, в котором адрес блока уже задан. При установке блока, его адрес определяется однозначно.

4. Адреса блокам программируются перед подключением к сети.

Данные рекомендации понятны и они больше относятся к аппаратным реализациям формирования адреса, при их применении частично отпадает необходимость в распределении адресов, потому как правый борт может попытаться работать с адресом "А", левый борт с адресом "Б". И только в случае конфликта (когда дефолтные адреса оказались заняты) инициировать процедуру перераспределения (захвата) адресов в сети.

Цитата

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

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

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