Jump to content
    

Перекличка блоков по CAN

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

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

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

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

И здесь: 

 

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

 

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

 

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

45 minutes ago, jcxz said:

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

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

46 minutes ago, jcxz said:

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

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

17 minutes ago, jcxz said:

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

А помехи?

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

1 minute ago, jcxz said:

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

4 minutes ago, Edit2007 said:

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Цитата

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...