[bezobraznic 0]

Привет всем! 

Есть N-блоков соединенных CAN-шиной.  Главного master-блока на шине нет, все равнозначные.  Необходимо постоянно делать перекличку между блоками, чтоб каждый блок всегда знал сколько блоков есть на шине.  Помогите с идеей реализации!! Может кто делал похожее!? Благодарствую!

 

[HardEgor 62]

Только что, bezobraznic сказал:

Есть N-блоков соединенных CAN-шиной.  Главного master-блока на шине нет, все равнозначные.  Необходимо постоянно делать перекличку между блоками, чтоб каждый блок всегда знал сколько блоков есть на шине.  Помогите с идеей реализации!! Может кто делал похожее!?

Значит они все master и равноправные. В этом случае любой из них(в случайном порядке) занимает шину и опрашивает остальных. Остальные слушают шину и записывают адреса ответов.

[bezobraznic 0]

Уже кое что! Спасибо.

Значит я думаю так,  каждому блоку я присваиваю свой ID по убыванию. Допустим первый начинает передачу запроса. Все взводят таймера и отвечают в свое время, а также слушают  ответы других. Теперь вопрос, если первый блок я отключаю,  как другие поймут что надо начинать запрос? Либо сделать чтоб все блоки по таймеру инициализировали запрос. Пытаюсь уложить в голове.  

[Edit2007 3]

Можно в зависимости от номера (ID) сделать разные таймауты. Если 1-й блок отключили и он не произвел опрос, то сработает таймаут второго блока и запустит опрос по шине.

Второй вариант - каждый блок периодически генерирует сообщение о своем присутствии на линии (скажем 100мс). Остальные блоки отслеживают это сообщение, и если оно отсутствует более заданного интервала (например 300 мс) считать что блок отключился (завис, умер и т.д).

[jcxz 184]

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

Значит они все master и равноправные. В этом случае любой из них(в случайном порядке) занимает шину и опрашивает остальных. Остальные слушают шину и записывают адреса ответов.

Чревато коллизиями. Да и вообще - чревато.

 

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

Значит я думаю так,  каждому блоку я присваиваю свой ID по убыванию.

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

У меня уже такой протокол работает. 

[bezobraznic 0]

15 minutes ago, jcxz said:

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

У меня уже такой протокол работает

Можно по-подробнее!?

[HardEgor 62]

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

Чревато коллизиями. Да и вообще - чревато.

А что, коллизии это неразрешимая вещь? Вроде как штатное состояние шины с несколькими мастерами.

[jcxz 184]

26 минут назад, HardEgor сказал:

А что, коллизии это неразрешимая вещь? Вроде как штатное состояние шины с несколькими мастерами.

Я говорю не про коллизии, разрешаемые штатным арбитражем, а про коллизии в поле данных кадра, которые суть есть - ошибки в обмене, никак не разрешаемые штатно.

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

Можно конечно добавить уникальный ID узла в CAN-ID, но уникальный ID узла обычно бывает длинный - 32 или 64 бита (у меня 64). И он просто не влезет в 29 бит CAN-ID.

[jcxz 184]

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

Можно по-подробнее!?

Рассказывать долго. Основная идея: Уникальные ID узлов передавать в поле 29-битного CAN-ID. По частям, если нужно (если ID - 64-битный, то можно передать его в 4 приёма по 16 бит). Начиная со старших 16 бит. Начинать всё с отправки в шину короткого кадра "старт цикла". Далее - каждый из узлов передаёт свой уникальный ID по 16 бит начиная со старших 16 бит. Если при очередной передаче узел выяснит, что передача не состоялась (так как был проигран арбитраж), то остальные биты ID данный узел больше не передаёт (до старта нового цикла). Передавать эти 16-битные сегменты нужно в RTR-кадрах: сперва все узлы формируют ответные кадры (для RTR) и разрешают их передачу, даётся пауза (чтоб все узлы успели сформировать), потом в шину отправляется RTR-запрос данного 16-битного сегмента. И так все сегменты. В результате одного цикла будет обнаружен один узел. Дальше его нужно изолировать от дальнейшего участия в протоколе сканирования. И начинаем следующий цикл, для обнаружения следующего узла.

Поле данных у всех кадров запроса - фиксированное = 0байт. Поэтому коллизий в данных нет, идёт нормальный арбитраж CAN по ID.

Примерно так вкратце. Там ещё много нюансов.

[bezobraznic 0]

Ясно. Спасибо, буду думать.

[Arlleex 131]

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

Есть N-блоков соединенных CAN-шиной.  Главного master-блока на шине нет, все равнозначные...

А ПО у этих блоков одинаковое? И ID, по которым они отправляют, тоже одинаковые или задаются при производстве?

[AlexandrY 2]

6 hours ago, bezobraznic said:

Привет всем! 

Есть N-блоков соединенных CAN-шиной.  Главного master-блока на шине нет, все равнозначные.  Необходимо постоянно делать перекличку между блоками, чтоб каждый блок всегда знал сколько блоков есть на шине.  Помогите с идеей реализации!! Может кто делал похожее!? Благодарствую!

Не master, а координатор. Без координатора сетей не бывает. 
Значит сначала должна пройти фаза выборов координатора.
Выигрывает тот у кого меньший ID назначеный для фазы выборов.  
Выборы кончаются когда спустя некоторое время никто не перебивает претендента на координатора, и координатор высылает ID  окончания выборов. 
После чего координатор знакомит дивайсы друг с другом. 

[HardEgor 62]

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

Ясно. Спасибо, буду думать.

Вариантов в общем много, всё будет зависеть от того как часто необходимо пересканировать сеть, как быстро надо узнать о появлении/исчезновении и какой плотности обмен пакетами в сети.

[bezobraznic 0]

6 hours ago, HardEgor said:

Вариантов в общем много, всё будет зависеть от того как часто необходимо пересканировать сеть, как быстро надо узнать о появлении/исчезновении и какой плотности обмен пакетами в сети.

Ну допустим, раз в 100мс.  Это предварительно. 

Пока пытаюсь осмыслить предложенное. 

Все упирается в вопрос актуального количества работающих блоков.

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

Блоки также объединены rs485 для внешнего мониторинга. У каждого есть адрес. На основании этого адреса рассчитывается ID для CANа.

По софту, блоки все одинаковые.

Как-то так.

 

 

 

 

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

[AKK 0]

Все уже давно придумано за нас. 

Здесь большую роль играет протокол верхнего уровня. Например, если вы работаете в стандарте SAE J1939, то Вам нужно читать часть J1939-81 (NETWORK MANAGEMENT), которая собственно и посвящена данному вопросу.

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

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

12 hours ago, AlexandrY said:

Не master, а координатор. Без координатора сетей не бывает. 
Значит сначала должна пройти фаза выборов координатора.

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

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

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

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