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

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

Сообщение отредактировал vptr - Mar 22 2013, 10:39

А как вы будете их по приему различать?


К сожалению арбитраж происходит только по ID, хотя можно было бы и по всему пакету его производить.
Т.е. если отправляются одновременно два фрейма с разными ID - то по шине успешно проходит с меньшим ID.
А вот если с одинаковым ID но разными данными - будет выставлена ошибка! Увеличатся счетчики ошибок у обоих устройств и они могут быстро попасть в bus off.
Обойти такую ситуацию можно установив одноразовую попытку передачи, и потом если пакет ушел - то все ок! иначе анализировать ошибку... и если это конфликт то делать случайную задержку перед повторной передачей. Но это все хорошо на этапе идентификации устройств и назначении им идентификаторов (как DHCP)

Предполагается, что при включении мастер будет запрашивать по очереди все устройства для получения из заводских номеров и еще кое-какой информации. Когда произойдет обращение к устройствам с одним идентификаторам, они начнут передачу одновременно, коллизия произойдет при передаче данных. Вопрос в том, может ли контроллер одного из них узнать об этом? Ведь арбитраж происходит только по ИД? Если бы устройство могло узнать об ошибке, оно бы инкрементировало "суб-идентификатор" (например два младших бита идентификатора). После окончания ответа первого устройства оно выдает свой ответ, но уже со своим идентификатором и мастер узнает о наличии двух устройств.

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


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

Да, примерно так и хотим сделать: 9 старших бит раздать датчикам по их назначению, а 2 младших использовать для отличия датчиков одного назначения.

Сообщение отредактировал 777777 - Mar 25 2013, 10:11

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

Все намного проще. Мастер может послать одну команду всем узлам - выдайте свои идентификационные данные. Каждый узел после случайной задержки выдает сообщение со своими данными. Это сообщение может иметь даже одинаковый идентификатор для всех - в случае коллизии узлы узнают, что она произошла и повторят передачу через случайные интервалы времени. Проблем тут не будет.
А конце концов мастер получит информацию о всех узлах, присутвующих в сети. И затем может сказать - мол ты, такой-то узел, с таким серийным номером - получаешь идентификатор 0x15A, а ты - 0x25B и т.д. Это кстати в протоколах высокого уровня типа CANopen реализовано уже.

Обычно это делается так:
ID DATA
00000460 01 07 00 85 00 00 0B 4B
00000460 00 0F A0 00 00 00 00 24
00000460 02 0F A0 00 00 00 00 24
00000460 03 0F A0 00 00 00 00 24
По нулевому байту определяется откуда пришло сообщение.

Главное при отправке указать что бы была только одна попытка отправить! Все CAN контроллеры это умеют, но по разному немного.
Этот механизм довольно сложно отладить в том смысле, что в большинстве случаев конфликтов реально не будет! Но можно налететь на то что в один момент два или больше устройства будут это делать одновременно и система будет стартовать с большими задержками. Поэтому стоит исходить из худшего - и делать одноразовую передачу и при ошибке опять случайную задержку (плюс можно хеш серийник использовать и добавлять несколько бит в ID)

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



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

CAN на уровне пакетов- не может. CAN как система- может. Советую CANopen, немцы довольно дружественно раздают официальную документацию (но не всю .
Ваш вопрос- это стандартная процедура, которая реализована по крайней мере в CANopen. смотрите например тут для затравки.

Про себя добавлю, что полная реализация на базе документации в Майкрочипе заняла ну может неделю, в результате получился стандартный мастер, контролирующий горячее подключение к системе и раздающий в том числе и эти самые ID. Ну а в торону компьютера видна уже база с собранными на этом единственном мастере данными, очень удобно для PC программера.
В CAN вообще много чего напихано стандартно, что в протоколах типа RS485/MODBUS приходится придумывать либо вообще невозможно сделать так как принцип сети другой. Лично мне CAN очень нравится по идеологии (CANopen как верхний уровень), но он более требователен к качеству линии связи, на чем попало не работает.