[AlexandrY 2]

2 hours ago, AKK said:

Ну, как-то так.

Ну это по вашему. 
А в реальности будет так:

Т.е. есть в сети J1939 координаторы и еще какие. И они обязательны. 

[jcxz 183]

9 часов назад, bezobraznic сказал:

Блоки также объединены rs485 для внешнего мониторинга.

А зачем? Если уже есть CAN.

[Eddy_Em 1]

14 minutes ago, jcxz said:

А зачем? Если уже есть CAN.

Тоже думаю, что проще подключить внешний мониторинг через один из блоков. Его же и назначить "мастером". И пускай он периодически шлет себе запросы с идентификаторами от IDmin до IDmax, а все остальные слушают линию и отмечают существующие идентификаторы в своей внутренней таблице. Хотя, с другой стороны, коль в сети будет мастер, зачем остальным знать идентификаторы присутствующих устройств? Как в том же примере про бортовую CAN-шину автомобиля: там есть один мастер (ЭБУ) и куча слейвов (причем количество слейвов варьируется в зависимости от "фарша"). Не нашел мастер модуль ESP — ОК, значит, машина будет без ESP ездить, не нашел контроль стеклоподъемников — ОК, пользователь ручками окна открывать/закрывать будет…

Изменено 27 октября, 2020 пользователем Eddy_Em

[jcxz 183]

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

каждый блок, регистрируюсь в сети при включении посылает "address claim" со своим адресом и NAME (не знаю как поточнее перевести, но в этом NAME целый пласт инфы от производителя до кода с кратким описанием функционала), если адрес свободен, то занимает его если адрес занят, то там целая процедура разруливания кто и с какого адреса работать будет. Но смысл в том, что если адрес занят, то блок занявший этот адрес отвечает на сообщение что адрес занят. А если послать запрос "addresss claim" на широковещательный адрес (0x255), то ответят ВСЕ блоки с указанием адресов по которым они общаются. После чего зная занятые адреса можно запросить у каждого из блоков его HARD ID, SOFT ID и т.д. Там еще много тонкостей взаимодействия расписано, прочитайте документ, не пожалеете. Тем более в нем всего 40 страниц текста.

А теперь объясните - каким образом такое организовать поверх CAN? Вы знаете как он (CAN) работает?  

Вопрос был не о том какие есть красивые и мегастандартные протоколы, а о методе реализации поверх CAN.

Цитата

Данная сеть используется в грузовых автомобилях. Кто там важнее: контроллер двигателя, контроллер трансмиссии или контроллер АБС? Зачастую координатора просто нет, что позволяет гибко нафаршировывать автомобиль примочками: нет АБС, да х... на него всем остальным блокам, нашелся в сети контроллер круиз-контроля, добро пожаловать в общую сеть, дружище. А кто там вякает про то, что он координатор, ну попробуй, может что и получится... :-).

Что за "сеть"? Речь идёт о CAN или о какой-то другой сети?

Если о CAN, то у ТС имхо не тот случай. Так как у него все узлы - одинаковые, с одинаковым ПО, различающиеся только уникальным ID (кстати - ТС так и не сказал какой разрядности у него ID?). И если этот ID имеет большую разрядность (>=29 бит), то таким образом, как Вы привели пример, по CAN обмен организовать не удастся. Без предварительного назначения более коротких адресов по какому-то алгоритму.

Чтобы было более понятно, подумайте что будет с "этими нафаршированными примочками" в вашем грузовом автомобиле, если в эту сеть добавить ещё один идентичный "контроллер двигателя"?... А если ещё 5 добавить? 

 

PS: Вопрос к ТС - какова разрядность уникальных ID (серийных номеров) узлов у вас? А то может всё гораздо проще решается (если разрядность малая)...

[Eddy_Em 1]

Да даже для 29-битных адресов можно придумать процедуру автоматической идентификации навроде аналогичной процедуры у Dallas в их мерзком 1-wire: мастер поочередно по одному биту перебирает и регистрирует ответы. Но и здесь без мастера не обойтись.

А вот меня все терзает любопытство: что ж за одноранговая сеть  такая, где все устройства абсолютно одинаковые? Чем она должна заниматься, если нет мастера, через который выполняется внешнее управление и мониторинг?

[bezobraznic 0]

4 hours ago, jcxz said:

PS: Вопрос к ТС - какова разрядность уникальных ID (серийных номеров) узлов у вас? А то может всё гораздо проще решается (если разрядность малая)...

Разрядность 11 бит.

[jcxz 183]

27 минут назад, bezobraznic сказал:

Разрядность 11 бит.

С этого надо было начинать!

Тогда вообще никакой проблемы нет, всё элементарно: Выделить одно фиксированное значение адреса (18-битное) и пусть каждый узел периодически отправляет на адрес состоящий из этих 18 старших бит + 11 бит собственного уникального ID (в младших 11-ти битах), какое-то сообщение "я здесь, такой-то". А все узлы подпишутся на приём этого адреса с маскированными младшими 11-ю битами.

[bezobraznic 0]

22 minutes ago, jcxz said:

С этого надо было начинать!

Тогда вообще никакой проблемы нет, всё элементарно: Выделить одно фиксированное значение адреса (18-битное) и пусть каждый узел периодически отправляет на адрес состоящий из этих 18 старших бит + 11 бит собственного уникального ID (в младших 11-ти битах), какое-то сообщение "я здесь, такой-то". А все узлы подпишутся на приём этого адреса с маскированными младшими 11-ю битами.

А во времени их надо разделять?

[jcxz 183]

1 минуту назад, bezobraznic сказал:

А во времени их надо разделять?

кого?

[bezobraznic 0]

Посылки от блоков.

Я может глупые вопросы задаю, но это мое первое применение CANа.

За идею спасибо чую, это то, что надо!

Изменено 27 октября, 2020 пользователем bezobraznic

[amaora 20]

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

[jcxz 183]

20 часов назад, bezobraznic сказал:

Посылки от блоков.

Задайте вопрос более вразумительно и развёрнуто.

16 часов назад, amaora сказал:

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

Имхо - не лучшее решение, так как будет приводить к коллизиям в поле данных и ошибкам на шине. Довольно частым при достаточно большом количестве узлов на шине и достаточно плотном обмене (кроме этих передач).

[bezobraznic 0]

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

Задайте вопрос более вразумительно и развёрнуто.

Вы написали выделить 18 +11битный ID  для посылок от блоков. Эти посылки надо во времени разделять?

[jcxz 183]

45 минут назад, bezobraznic сказал:

Эти посылки надо во времени разделять?

В смысле "разделять"? Какие "эти" и от кого их "разделять"???  

Вот у вас 1-й CAN-узел, у него уникальный_ID=XXX. И 2-й, у которого уникальный_ID=YYY. XXX и YYY - 11-битные.

И есть некая константа в ПО - KKK (18-битная), которая задаёт старшие 18 бит адреса для всех сообщений данного протокола.

Так вот - 1-й узел должен периодически посылать CAN-кадр с ID = KKK << 11 | XXX. А 2-й узел - с ID = KKK << 11 | YYY. Период отправки - любой удобный. Данные кадра - любые (например - какая-нить дополнительная инфа об узле)

И все узлы, которые желают принимать такие кадры, должны подписаться на приём сообщений с ID = KKK << 11 | MMM, где: MMM - маска, маскирующая ненужные биты адреса для фильтра входящих CAN-кадров.

 

PS: Вроде же совершенно примитивный способ. Неужто неясно? 

[bezobraznic 0]

Спасибо за разъяснения. Теперь стало понятнее!