Ошибка приема кадра сообщения

Сегодня отнёс ккм в ЦТО, там покрутили, сказали, что железо новое, т.к. 55Ф раньше был без Ethernet порта, а у меня с ним, да и пломба не старая. Поменяли на всякий случай полностью модуль печати, сославшись на его частые проблемы, мол забивается остатками от резчика бумаги, тяжело протягивает, подгорает обмотка двигателя и в таком роде.
Погоняли тесты. При тестировании работает стабильно хорошо.

Принёс на точку, поставил, и уже на втором чеке — вначале долго думает, потом мееедленно по одной строчечке, раз в 2-3 секунды вжик вжик.
Перезагрузил ККМ. Перезапустил сервер. Норма.

Я подумал, может быть дело все таки не в тайм ауте?
Проблема наблюдается на двух одинаковых атолах и именно после перепрошивки на 1.05
Я использую планшеты под Win8,Win10. Работаю по https через Chrome. KKM подключен по ethernet к роутеру. Все устройства в одной подсети.

Может мне использовать расширение вместо сервера?
Или может перейти на USB подключение?

Благодарю за поддержку, можно ли попробовать какие то варианты ещё?
Спасибо

Протокол CAN. Описание, формат кадра, контроль ошибок.

Приветствую всех на нашем сайте! Сегодняшняя статья будет целиком и полностью посвящена обзору протокола CAN. А в одной из следующих статей мы реализуем обмен данными по CAN на практике. Но не буду забегать вперед…

CAN (Controller Area Network) — это промышленный стандарт, позволяющий осуществить объединение в единую сеть различных узлов, механизмов, датчиков и т. п. Протокол является широковещательным, это значит, что все устройства в CAN-сети принимают все передаваемые по шине сигналы. Режим передачи данных — последовательный, при этом байты сообщений формируют кадры определенного вида. Структуру этих кадров данных мы также обязательно разберем в этой статье.

Основные характеристики протокола CAN:

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

Первоначально стандарт был разработан для автомобильной промышленности. И занималась этим компания Bosch в 1980-х годах. Основная идея заключалась в том, чтобы уйти от использования огромного количества проводов, соединяющих многочисленные узлы автомобиля. И протокол CAN позволил этого достичь! С тех пор CAN является основным механизмом соединения устройств, узлов и датчиков автомобиля между собой. Помимо этого, интерфейс CAN активно используется в промышленной автоматизации, а также в системах «умного дома».

Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна 🙂 Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:

Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:

В отличие от многих других протоколов в CAN не рекомендуется описание битов данных как «логического нуля» и «логической единицы». Здесь используются понятия доминантный и рецессивный бит.

Важнейшим свойством является то, что если один из узлов сети хочет выставить на линии рецессивный бит, а другой доминантный, то в итоге на линии окажется доминантный бит. В общем-то отсюда и следует его название, от слова «доминировать» 🙂 Очень хорошо этот процесс иллюстрирует пример с оптоволоконной линией. Как вы помните, в оптоволокне для передачи данных используется «свет», либо он есть (единица), либо его нет (ноль). При использовании в CAN-сети «свет» — доминантный бит, соответственно, отсутствие света или «темнота» — рецессивный. Вспоминаем про важнейшее свойство передачи данных в сети…

Пусть один узел выставляет на линии рецессивный бит, то есть «темноту». Второй узел, напротив, выставляет доминантный бит — «свет». В итоге на линии будет «свет», то есть доминантный бит, что в точности соответствует требованиям сети!

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

Это свойство используется для арбитража в сети CAN. Пусть несколько устройств хотят передать данные. Каждый из этих передатчиков сравнивает значение, которое он передает, со значением, фактически присутствующим на линии. В том случае, если передаваемое значение совпадает со считанным, устройство продолжает высылать свои данные. Если значения совпали у нескольких устройств, то все они продолжают передачу как ни в чем не бывало.

Продолжается это до того момента, когда значения станут различными. Если несколько устройств хотят передать рецессивный бит, а одно — доминантный, то в соответствии с правилом, которое мы обсудили выше, на линии окажется доминантный бит. В таком случае отправленные и считанные значения для устройств, пытающихся выдать на линию рецессивное состояние, не совпадут. В этом случае они должны прекратить передачу. А тот узел, который в этот момент передавал доминантный бит, продолжит свою работу. Доминирование в чистом виде 🙂

Сигналы, которые передаются по витой паре, получили название CAN_H и CAN_L (High и Low). Доминантное состояние соответствует случаю, когда потенциал сигнала CAN_H выше потенциала CAN_L. Рецессивное — когда потенциалы равны (разница потенциалов не превышает допустимого отклонения, 0.5 В).

С этим вроде бы разобрались, давайте двигаться дальше!

Пришло время определить, как биты объединяются в кадры. Протокол CAN определяет 4 вида кадров:

• Кадр данных (data frame)
• Кадр удаленного запроса (remote frame)
• Кадр перегрузки (overload frame)
• Кадр ошибки (error frame)

Для кадра данных возможны два варианта — базовый формат и расширенный. Вот так выглядит структура базового формата:

А это структура расширенного:

Результирующий идентификатор получается в результате объединения полей «Идентификатор A» и «Идентификатор B«.

Кадр удаленного запроса (remote frame) представляет из себя кадр данных, описанный выше, но без поля данных и с рецессивным битом RTR. Он используется в случае, когда один узел хочет запросить данные у другого узла.

Кадр ошибки (error frame) передает устройство, обнаружившее ошибку в сети. Фрейм ошибки имеет наивысший приоритет и принимается всеми устройствами сети в обязательном порядке.

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

А давайте вернемся чуть назад, к арбитражу данных, и рассмотрим, что это может означать на практике! Итак, несколько устройств начинают передачу сообщения, а точнее кадра данных. Передается бит начала кадра и затем начинается передача идентификатора сообщения. Как вы помните, приоритет будет у того устройства, которое будет передавать доминантный бит, в тот момент, когда все остальные будут передавать рецессивный. То есть чем «позже» среди битов идентификатора появится «рецессивный бит», тем выше будет его приоритет! Другими словами: более высокий приоритет при использовании интерфейса CAN имеют сообщения с меньшим значением идентификатора.

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

Итак, что у нас на очереди теперь? Конечно же контроль ошибок — важнейший аспект работы протокола CAN! Стандарт предусматривает несколько механизмов контроля ошибок.

• Во-первых, это контроль передачи битов — уровень сигнала в сети сравнивается с передаваемым для каждого бита.
• Второй механизм заключается в использовании дополнительных битов (stuffing bit). После передачи любых пяти одинаковых битов автоматически добавляется передача бита противоположного значения. Таким образом, при передаче шести одинаковых битов диагностируется ошибка stuffing’а. Этот механизм используется для кодирования всех полей фреймов данных и запроса. Исключением являются только поля промежутка подтверждения, разграничителя контрольной суммы и EOF.
• Стандартная процедура проверки контрольной суммы. Передатчик вычисляет контрольную сумму для текущего кадра и передает ее в линию. В свою очередь, приемник также вычисляет контрольную сумму для принимаемых данных и сравнивает ее с тем значением, которое было отправлено передатчиком. В случае не совпадения значений диагностируется ошибка CRC.
• Также выполняется контроль битов фрейма, которые должны иметь заранее определенное значение. В случае, если реальное значение не совпадает с тем, которое ожидается, возникает ошибка.

Благодаря всем этим механизмам, вероятность необнаружения ошибки является очень низкой, что, конечно же, не может не радовать 🙂

Кроме того, если один из узлов обнаружил ошибку в сообщении, он сообщает об этом в сеть CAN при помощи фрейма ошибки. А поскольку сеть у нас широковещательная, то о возникновении ошибки становится известно всем участникам коммуникации. И если в сообщении была обнаружена ошибка, его передача будет осуществлена еще раз.

И на этом еще не все! Каждый узел может находиться в одном из трех состояний:

• Error Active
• Error Passive
• Bus Off

Протокол CAN предусматривает, что изначально, после старта, узел находится в первом из этих состояний — Error Active. Каждое устройство имеет два счетчика ошибок:

• Счетчик ошибок передачи
• Счетчик ошибок приема

Существуют определенные правила обслуживания этих счетчиков, которые сводятся к следующему. Передатчик, обнаруживший ошибку, увеличивает свой счетчик ошибок передачи быстрее, чем приемники увеличивают свои счетчики ошибок приема. Это связано с предположением, что при ошибке, вероятность того, что сбой произошел именно в передатчике, а не в приемнике, достаточно велика. На практике ошибка передачи увеличивает соответствующий счетчик на 8, а ошибка приема лишь на 1. При приеме или передаче корректного сообщения как счетчик ошибок передачи, так и счетчики ошибок приема уменьшаются на 1.

Если значение любого из этих двух счетчиков узла превысит значение 127, то узел переходит в состояние Error Passive. А если величина одного из счетчиков превысит 255, то узел перейдет в состояние Bus Off.

Разница между этими состояниями заключается в действиях узла при диагностировании ошибки:

• Узел в состоянии Error Active при обнаружении ошибки передает в шину Active Error Flags — 6 доминантных бит. Поскольку биты доминантные, то это сообщение нарушает обычную работу шины и поэтому все устройства сети также фиксируют возникновение ошибки.
• Узел в состоянии Error Passive при обнаружении ошибки передает в шину Passive Error Flags — 6 рецессивных бит, которые игнорируются всеми другими участниками обмена. Поэтому увеличивается только величина счетчика ошибок одного конкретного узла.
• И, наконец, узел в состоянии Bus Off ничего не передает в сеть — ни фреймы ошибок, ни фреймы данных, никакие другие.

Как видите, протокол CAN крайне интересен для изучения, надежен, безопасен, и удобен в использовании 🙂

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

Источник

После предыдущей статьиВведение в шину CAN (4) -Каркас данных и кадр управления 》

4.3.3 Ошибка кадра

4.3.3.1 Структура кадра ошибок

При отправке и получении сообщений, если узел на шине обнаруживает ошибку, узел отправляет кадр ошибки, чтобы уведомить узел на шине, что он допустил ошибку.
Кадр ошибки состоит из флага ошибки и разделителя ошибок.
Флаг активной ошибки: 6 последовательных доминирующих бит (0);
Флаг пассивной ошибки: 6 последовательных рецессивных битов (1);
Неверный разделитель: 8 последовательных рецессивных битов (1).

Можно видеть, что после флага ошибки перекрываются 0-6-битовые флаги ошибок. Этот сегмент имеет наименьшие 0 битов и максимальные 6 битов. Как будет сформирован этот сегмент, будет объяснено ниже.

4.3.3.2 Обнаружение ошибок

4.3.3.2.1 Принцип битовой начинки

Прежде чем разбираться в обнаружении ошибок в шине CAN, вам необходимо понять, что такое битовая вставка.
Как указано в протоколе CAN,Когда уровень одинаковой полярности продолжается в течение пяти битов, добавьте бит противоположной полярности。
Для отправки узлов:
При отправке кадра данных и кадра дистанционного управления для потока битов между SOF ~ CRC (исключая разделитель CRC), если уровень одинаковой полярности сохраняется в течение 5 битов, следующий бит Вставьте обратный уровень с предыдущими 5 битами;

Для принимающего узла:
При получении кадра данных и кадра дистанционного управления для потока битов между SOF ~ CRC (исключая ограничитель CRC), если уровень одинаковой полярности сохраняется в течение 5 битов, необходимо удалить Один человек получает это снова.

Советы: Примечание: добавление и удаление битов заполнения выполняется отправляющим узлом и принимающим узлом. CAN-BUS отвечает только за передачу и не манипулирует сигналами.

4.3.3.2.2 Типы ошибок

В связи по шине CAN существует пять типов ошибок:
(1) Ошибка бита
(2) ошибка ACK
(3) Ошибка заполнения
(4) ошибка CRC
(5) Ошибка формата

4.3.3.2.2.1 Ошибка проверки бита

Узел сравнивает уровень, отправленный на шину, с уровнем, считываемым с шины одновременно. Если обнаружится, что эти два значения несовместимы, узел обнаружит битовую ошибку.

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

Tips:  Есть три исключения, которые не являются битовыми ошибками:

 В области арбитража узел отправляет рецессивный бит на шину, но считывает доминантный бит, который не считается ошибкой в ​​битах. Эта ситуация указывает на то, что узлу не удалось выполнить арбитраж;

 В слоте ACK узел отправляет рецессивный бит на шину, но считывает доминантный бит, который не считается ошибкой в ​​битах. Эта ситуация указывает на то, что кадр, в данный момент отправленный узлом, был правильно принят по меньшей мере одним другим узлом;

 Этот узел отправляет флаг пассивной ошибки. Node_A отправляет шесть последовательных рецессивных битов (флаг пассивной ошибки) на шину, но считывает доминантный бит, который не считается ошибкой в ​​битах. Поскольку флаг пассивной ошибки представляет собой шесть последовательных рецессивных битов, возможно, что шесть последовательных рецессивных битов «съедаются» доминирующим уровнем, отправляемым другими узлами в соответствии с проводом и механизмом;

4.3.3.2.2.2 Ошибка подтверждения

Согласно протоколу CAN, после отправки сообщения кадра (фрейма данных или кадра дистанционного управления), если принимающий узел Node_B успешно принимает сообщение кадра, то принимающий узел Node_B должен находиться в периоде времени, соответствующем интервалу ACK кадра. Доминирующий бит отправляется на входящей шине в ответ на отправляющий узел Node_A. Таким образом, отправляющий узел Node_A будет считывать доминирующий бит с шины в течение периода слота ACK.

Поэтому:
Когда отправляющий узел Node_A не считывает доминирующий бит в течение периода слота ACK, отправляющий узел Node_A обнаружит ошибку ответа ACK. Это означает, что ни один из узлов успешно не получил сообщение кадра.

4.3.3.2.2.3 Ошибка заполнения

В сегменте кадра (последовательность SOF ~ CRC кадра дистанционного управления кадром данных), который должен реализовать принцип вставки битов, если обнаружено шесть последовательных гомосексуальных битов, обнаружена ошибка вставки.

4.3.3.2.2.4 Ошибка CRC

Когда отправляющий узел Node_A отправляет кадр данных или кадр дистанционного управления, он вычисляет последовательность CRC сообщения кадра.
Принимающий узел Node_B также выполняет тот же алгоритм CRC при получении сообщения. Если значение последовательности CRC, вычисленное принимающим узлом Node_B, не соответствует значению последовательности CRC, отправленному отправляющим узлом Node_A, принимающему узлу Узел обнаруживает ошибку CRC.

4.3.3.2.2.5 Ошибка формата

Когда кадр отправляется, если в области, где должно быть передано предопределенное значение, обнаружено недопустимое значение, обнаруживается ошибка формата.
Области в сообщении CAN с предопределенными значениями включают в себя:

Ограничитель CRC, разделитель ACK, EOF фрейма данных и фрейма дистанционного управления;
разделитель кадра ошибки
разделитель кадра перегрузки

4.3.3.3 Уведомление об ошибке

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

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

4.3.3.3.1 Состояние ошибки узла

Согласно протоколу CAN, узлы на шине CAN всегда находятся в одном из следующих трех состояний.
А. Активный статус ошибки
б. Пассивный статус ошибки
c. Всегда закрыт

При соблюдении определенных условий узел может переходить из одного состояния в другое.

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

1) Активный статус ошибки

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

2) Пассивная ошибка состояния

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

Советы: Примечание. Говорят, что узлы в состоянии активной ошибки или в состоянии пассивной ошибки все еще могут нормально взаимодействовать.
Обычный обмен данными здесь означает, что узлы все еще могут получать сообщения от шины, а также могут конкурировать за отправку сообщений на шину после ее победы.
Однако это не означает, что полученное сообщение должно быть правильным, и не означает, что сообщение может быть отправлено правильно.

3) автобус выключен
Узел находится в состоянии отключения, поэтому узел не может отправлять или получать сообщения;
Узел в состоянии отключения шины может только ждать вечно, а когда он удовлетворяет определенным условиям, он снова переходит в активное состояние ошибки.

4.3.3.3.2 Ошибка состояния перехода

Теперь мы знаем:
Узел в активном состоянии ошибки отправляет кадр ошибки с активным флагом ошибки, когда он обнаруживает ошибку;
Узел в состоянии пассивной ошибки отправляет кадр ошибки с флагом пассивной ошибки при обнаружении ошибки.

Итак, при каких обстоятельствах узел CAN находится в состоянии активной ошибки, а при каких обстоятельствах он находится в состоянии пассивной ошибки?

Согласно протоколу CAN, в узле CAN есть два счетчика:Счетчик ошибок передачи (TEC) иСчетчик ошибок приема (REC)。

Советы: обратите внимание, что:
Эти два счетчика не учитывают ни количество отправленных или полученных пакетов, ни количество отправленных или полученных кадров ошибок.
Значения счетчиков TEC и RCE изменяются в соответствии со следующей таблицей

Переход состояния ошибки узла CAN основан на этих двух счетчиках.

Можно видеть, что переход статуса ошибки узла — это процесс «количественного изменения» к «качественному изменению»:

1) Активный статус ошибки
Если в начале TCE и REC меньше 127, ** они находятся в состоянии активной ошибки.

В этом состоянии узел обнаруживает ошибку и отправляет кадр ошибки с активным флагом ошибки.
Поскольку флаг активной ошибки состоит из шести последовательных доминирующих битов, на этот раз флаг активной ошибки будет «покрывать» другие узлы на шине.
Ранее переданное сообщение на шине CAN было уничтожено этими «шестью последовательными доминирующими битами».

Если узел, отправляющий активный кадр ошибки, является отправляющим узлом, этот случай эквивалентен:
 Я просто отправил неправильный фрейм, а теперь уничтожаю его (отправляю активный фрейм с ошибками), независимо от того, что вы получаете;

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


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

2) Пассивная ошибка состояния
Если узел отправляет много кадров с ошибками, он установит TCE 127 или REC 127, тогда узел будет находиться в состоянии пассивной ошибки.

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

Если узел Node_A, отправляющий кадр пассивной ошибки, является отправляющим узлом сообщения,
 Затем после отправки фрейма пассивной ошибки только что отправленное сообщение повреждено,
 И Node_A не может продолжать отправлять сообщение, которое только что не удалось отправить после кадра ошибки.

 Далее следует интервал кадра, который сопровождается8Сегмент "отложенной передачи" рецессивного бита;

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

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


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

3) автобус выключен
Если узел в состоянии пассивной ошибки все еще отправляет кадры пассивной ошибки несколько раз, это неизбежно приведет к TEC> 255, что приведет к отключению шины.

В состоянии отключения шины узел Node_A не может отправить сообщение на шину и не может получить сообщение с шины, и весь узел покидает шину. Когда 128 последовательных рецессивных битов обнаружены 128 раз, TEC и REC устанавливаются в 0, а затем возвращаются в активное состояние ошибки.

Как я понимаю 
 Это так называемое "обнаруженное128второстепенный11«Непрерывные рецессивные биты» на самом деле держать этот узел изолированным в течение некоторого времени, успокоиться,
 Потому что, когда он находится в выключенном состоянии, он не будет иметь никакого соединения с шиной.
 В это время, пока он рассчитывает время, равное достижению передачи128второстепенный11Время, необходимое для двух последовательных рецессивных битов, может быть повторно подключено к шине.


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

4.3.3.3.3 Передача кадров с ошибками

Когда кадр ошибки отправляется после обнаружения ошибки?
Согласно протоколу CAN:
Ошибка бита, ошибка заполнения, ошибка формата, ошибка ACK: Кадр ошибки начинает передаваться рядом с битом, в котором произошла ошибка.
Ошибка CRC: Кадр ошибки передается сразу после разделителя ACK.

Пример 1: ! [Вставьте описание изображения здесь] (https://img-blog.csdnimg.cn/20190715180704148.png?x- oss-process = image / watermark, type_ZmFuZ3poZW5naGVpdGk, shadow_10, text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NpZWxsZWU =, size_16, color_FFFFFF, t_70), узел_ отправляется из узла, и отправляется из узла. Возникает битовая ошибка; (2) После того, как Node_A обнаруживает битовую ошибку, он немедленно отправляет активный кадр ошибки со следующим битом: флаг активной ошибки из 6 последовательных доминирующих бит + 8 последовательных рецессивов Разделитель битовых ошибок; (3) В соответствии с флагом активной ошибки, отправляемым Node_A, уровень на шине составляет 6 последовательных доминирующих битов;

(4) Принимающие узлы Node_B и Node_C прослушивают 6 последовательных доминирующих битов из шины, тогда будет обнаружена ошибка заполнения, поэтому оба узла отправят активные кадры ошибок;
(5) В соответствии с флагом активной ошибки, установленным Node_B и Node_C, уровень шины имеет 6 последовательных доминирующих уровней, соответствующих разделителям ошибок, выпущенным Node_B и Node_C. 8 последовательных рецессивных уровней.
(6) После прерывистого поля узел Node_A повторно отправляет только что появившееся сообщение.

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

Протокол CAN. Описание, формат кадра, контроль ошибок.

Приветствую всех на нашем сайте! Сегодняшняя статья будет целиком и полностью посвящена обзору протокола CAN. А в одной из следующих статей мы реализуем обмен данными по CAN на практике. Но не буду забегать вперед…

CAN (Controller Area Network) — это промышленный стандарт, позволяющий осуществить объединение в единую сеть различных узлов, механизмов, датчиков и т. п. Протокол является широковещательным, это значит, что все устройства в CAN-сети принимают все передаваемые по шине сигналы. Режим передачи данных — последовательный, при этом байты сообщений формируют кадры определенного вида. Структуру этих кадров данных мы также обязательно разберем в этой статье.

Основные характеристики протокола CAN:

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

Первоначально стандарт был разработан для автомобильной промышленности. И занималась этим компания Bosch в 1980-х годах. Основная идея заключалась в том, чтобы уйти от использования огромного количества проводов, соединяющих многочисленные узлы автомобиля. И протокол CAN позволил этого достичь! С тех пор CAN является основным механизмом соединения устройств, узлов и датчиков автомобиля между собой. Помимо этого, интерфейс CAN активно используется в промышленной автоматизации, а также в системах «умного дома».

Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна 🙂 Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:

Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:

В отличие от многих других протоколов в CAN не рекомендуется описание битов данных как «логического нуля» и «логической единицы». Здесь используются понятия доминантный и рецессивный бит.

Важнейшим свойством является то, что если один из узлов сети хочет выставить на линии рецессивный бит, а другой доминантный, то в итоге на линии окажется доминантный бит. В общем-то отсюда и следует его название, от слова «доминировать» 🙂 Очень хорошо этот процесс иллюстрирует пример с оптоволоконной линией. Как вы помните, в оптоволокне для передачи данных используется «свет», либо он есть (единица), либо его нет (ноль). При использовании в CAN-сети «свет» — доминантный бит, соответственно, отсутствие света или «темнота» — рецессивный. Вспоминаем про важнейшее свойство передачи данных в сети…

Пусть один узел выставляет на линии рецессивный бит, то есть «темноту». Второй узел, напротив, выставляет доминантный бит — «свет». В итоге на линии будет «свет», то есть доминантный бит, что в точности соответствует требованиям сети!

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

Это свойство используется для арбитража в сети CAN. Пусть несколько устройств хотят передать данные. Каждый из этих передатчиков сравнивает значение, которое он передает, со значением, фактически присутствующим на линии. В том случае, если передаваемое значение совпадает со считанным, устройство продолжает высылать свои данные. Если значения совпали у нескольких устройств, то все они продолжают передачу как ни в чем не бывало.

Продолжается это до того момента, когда значения станут различными. Если несколько устройств хотят передать рецессивный бит, а одно — доминантный, то в соответствии с правилом, которое мы обсудили выше, на линии окажется доминантный бит. В таком случае отправленные и считанные значения для устройств, пытающихся выдать на линию рецессивное состояние, не совпадут. В этом случае они должны прекратить передачу. А тот узел, который в этот момент передавал доминантный бит, продолжит свою работу. Доминирование в чистом виде 🙂

Сигналы, которые передаются по витой паре, получили название CAN_H и CAN_L (High и Low). Доминантное состояние соответствует случаю, когда потенциал сигнала CAN_H выше потенциала CAN_L. Рецессивное — когда потенциалы равны (разница потенциалов не превышает допустимого отклонения, 0.5 В).

С этим вроде бы разобрались, давайте двигаться дальше!

Пришло время определить, как биты объединяются в кадры. Протокол CAN определяет 4 вида кадров:

• Кадр данных (data frame)
• Кадр удаленного запроса (remote frame)
• Кадр перегрузки (overload frame)
• Кадр ошибки (error frame)

Для кадра данных возможны два варианта — базовый формат и расширенный. Вот так выглядит структура базового формата:

А это структура расширенного:

Результирующий идентификатор получается в результате объединения полей «Идентификатор A» и «Идентификатор B«.

Кадр удаленного запроса (remote frame) представляет из себя кадр данных, описанный выше, но без поля данных и с рецессивным битом RTR. Он используется в случае, когда один узел хочет запросить данные у другого узла.

Кадр ошибки (error frame) передает устройство, обнаружившее ошибку в сети. Фрейм ошибки имеет наивысший приоритет и принимается всеми устройствами сети в обязательном порядке.

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

А давайте вернемся чуть назад, к арбитражу данных, и рассмотрим, что это может означать на практике! Итак, несколько устройств начинают передачу сообщения, а точнее кадра данных. Передается бит начала кадра и затем начинается передача идентификатора сообщения. Как вы помните, приоритет будет у того устройства, которое будет передавать доминантный бит, в тот момент, когда все остальные будут передавать рецессивный. То есть чем «позже» среди битов идентификатора появится «рецессивный бит», тем выше будет его приоритет! Другими словами: более высокий приоритет при использовании интерфейса CAN имеют сообщения с меньшим значением идентификатора.

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

Итак, что у нас на очереди теперь? Конечно же контроль ошибок — важнейший аспект работы протокола CAN! Стандарт предусматривает несколько механизмов контроля ошибок.

• Во-первых, это контроль передачи битов — уровень сигнала в сети сравнивается с передаваемым для каждого бита.
• Второй механизм заключается в использовании дополнительных битов (stuffing bit). После передачи любых пяти одинаковых битов автоматически добавляется передача бита противоположного значения. Таким образом, при передаче шести одинаковых битов диагностируется ошибка stuffing’а. Этот механизм используется для кодирования всех полей фреймов данных и запроса. Исключением являются только поля промежутка подтверждения, разграничителя контрольной суммы и EOF.
• Стандартная процедура проверки контрольной суммы. Передатчик вычисляет контрольную сумму для текущего кадра и передает ее в линию. В свою очередь, приемник также вычисляет контрольную сумму для принимаемых данных и сравнивает ее с тем значением, которое было отправлено передатчиком. В случае не совпадения значений диагностируется ошибка CRC.
• Также выполняется контроль битов фрейма, которые должны иметь заранее определенное значение. В случае, если реальное значение не совпадает с тем, которое ожидается, возникает ошибка.

Благодаря всем этим механизмам, вероятность необнаружения ошибки является очень низкой, что, конечно же, не может не радовать 🙂

Кроме того, если один из узлов обнаружил ошибку в сообщении, он сообщает об этом в сеть CAN при помощи фрейма ошибки. А поскольку сеть у нас широковещательная, то о возникновении ошибки становится известно всем участникам коммуникации. И если в сообщении была обнаружена ошибка, его передача будет осуществлена еще раз.

И на этом еще не все! Каждый узел может находиться в одном из трех состояний:

• Error Active
• Error Passive
• Bus Off

Протокол CAN предусматривает, что изначально, после старта, узел находится в первом из этих состояний — Error Active. Каждое устройство имеет два счетчика ошибок:

• Счетчик ошибок передачи
• Счетчик ошибок приема

Существуют определенные правила обслуживания этих счетчиков, которые сводятся к следующему. Передатчик, обнаруживший ошибку, увеличивает свой счетчик ошибок передачи быстрее, чем приемники увеличивают свои счетчики ошибок приема. Это связано с предположением, что при ошибке, вероятность того, что сбой произошел именно в передатчике, а не в приемнике, достаточно велика. На практике ошибка передачи увеличивает соответствующий счетчик на 8, а ошибка приема лишь на 1. При приеме или передаче корректного сообщения как счетчик ошибок передачи, так и счетчики ошибок приема уменьшаются на 1.

Если значение любого из этих двух счетчиков узла превысит значение 127, то узел переходит в состояние Error Passive. А если величина одного из счетчиков превысит 255, то узел перейдет в состояние Bus Off.

Разница между этими состояниями заключается в действиях узла при диагностировании ошибки:

• Узел в состоянии Error Active при обнаружении ошибки передает в шину Active Error Flags — 6 доминантных бит. Поскольку биты доминантные, то это сообщение нарушает обычную работу шины и поэтому все устройства сети также фиксируют возникновение ошибки.
• Узел в состоянии Error Passive при обнаружении ошибки передает в шину Passive Error Flags — 6 рецессивных бит, которые игнорируются всеми другими участниками обмена. Поэтому увеличивается только величина счетчика ошибок одного конкретного узла.
• И, наконец, узел в состоянии Bus Off ничего не передает в сеть — ни фреймы ошибок, ни фреймы данных, никакие другие.

Как видите, протокол CAN крайне интересен для изучения, надежен, безопасен, и удобен в использовании 🙂

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

Источник

После предыдущей статьиВведение в шину CAN (4) -Каркас данных и кадр управления 》

4.3.3 Ошибка кадра

4.3.3.1 Структура кадра ошибок

При отправке и получении сообщений, если узел на шине обнаруживает ошибку, узел отправляет кадр ошибки, чтобы уведомить узел на шине, что он допустил ошибку.
Кадр ошибки состоит из флага ошибки и разделителя ошибок.
Флаг активной ошибки: 6 последовательных доминирующих бит (0);
Флаг пассивной ошибки: 6 последовательных рецессивных битов (1);
Неверный разделитель: 8 последовательных рецессивных битов (1).

Можно видеть, что после флага ошибки перекрываются 0-6-битовые флаги ошибок. Этот сегмент имеет наименьшие 0 битов и максимальные 6 битов. Как будет сформирован этот сегмент, будет объяснено ниже.

4.3.3.2 Обнаружение ошибок

4.3.3.2.1 Принцип битовой начинки

Прежде чем разбираться в обнаружении ошибок в шине CAN, вам необходимо понять, что такое битовая вставка.
Как указано в протоколе CAN,Когда уровень одинаковой полярности продолжается в течение пяти битов, добавьте бит противоположной полярности。
Для отправки узлов:
При отправке кадра данных и кадра дистанционного управления для потока битов между SOF ~ CRC (исключая разделитель CRC), если уровень одинаковой полярности сохраняется в течение 5 битов, следующий бит Вставьте обратный уровень с предыдущими 5 битами;

Для принимающего узла:
При получении кадра данных и кадра дистанционного управления для потока битов между SOF ~ CRC (исключая ограничитель CRC), если уровень одинаковой полярности сохраняется в течение 5 битов, необходимо удалить Один человек получает это снова.

Советы: Примечание: добавление и удаление битов заполнения выполняется отправляющим узлом и принимающим узлом. CAN-BUS отвечает только за передачу и не манипулирует сигналами.

4.3.3.2.2 Типы ошибок

В связи по шине CAN существует пять типов ошибок:
(1) Ошибка бита
(2) ошибка ACK
(3) Ошибка заполнения
(4) ошибка CRC
(5) Ошибка формата

4.3.3.2.2.1 Ошибка проверки бита

Узел сравнивает уровень, отправленный на шину, с уровнем, считываемым с шины одновременно. Если обнаружится, что эти два значения несовместимы, узел обнаружит битовую ошибку.

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

Tips:  Есть три исключения, которые не являются битовыми ошибками:

 В области арбитража узел отправляет рецессивный бит на шину, но считывает доминантный бит, который не считается ошибкой в ​​битах. Эта ситуация указывает на то, что узлу не удалось выполнить арбитраж;

 В слоте ACK узел отправляет рецессивный бит на шину, но считывает доминантный бит, который не считается ошибкой в ​​битах. Эта ситуация указывает на то, что кадр, в данный момент отправленный узлом, был правильно принят по меньшей мере одним другим узлом;

 Этот узел отправляет флаг пассивной ошибки. Node_A отправляет шесть последовательных рецессивных битов (флаг пассивной ошибки) на шину, но считывает доминантный бит, который не считается ошибкой в ​​битах. Поскольку флаг пассивной ошибки представляет собой шесть последовательных рецессивных битов, возможно, что шесть последовательных рецессивных битов «съедаются» доминирующим уровнем, отправляемым другими узлами в соответствии с проводом и механизмом;

4.3.3.2.2.2 Ошибка подтверждения

Согласно протоколу CAN, после отправки сообщения кадра (фрейма данных или кадра дистанционного управления), если принимающий узел Node_B успешно принимает сообщение кадра, то принимающий узел Node_B должен находиться в периоде времени, соответствующем интервалу ACK кадра. Доминирующий бит отправляется на входящей шине в ответ на отправляющий узел Node_A. Таким образом, отправляющий узел Node_A будет считывать доминирующий бит с шины в течение периода слота ACK.

Поэтому:
Когда отправляющий узел Node_A не считывает доминирующий бит в течение периода слота ACK, отправляющий узел Node_A обнаружит ошибку ответа ACK. Это означает, что ни один из узлов успешно не получил сообщение кадра.

4.3.3.2.2.3 Ошибка заполнения

В сегменте кадра (последовательность SOF ~ CRC кадра дистанционного управления кадром данных), который должен реализовать принцип вставки битов, если обнаружено шесть последовательных гомосексуальных битов, обнаружена ошибка вставки.

4.3.3.2.2.4 Ошибка CRC

Когда отправляющий узел Node_A отправляет кадр данных или кадр дистанционного управления, он вычисляет последовательность CRC сообщения кадра.
Принимающий узел Node_B также выполняет тот же алгоритм CRC при получении сообщения. Если значение последовательности CRC, вычисленное принимающим узлом Node_B, не соответствует значению последовательности CRC, отправленному отправляющим узлом Node_A, принимающему узлу Узел обнаруживает ошибку CRC.

4.3.3.2.2.5 Ошибка формата

Когда кадр отправляется, если в области, где должно быть передано предопределенное значение, обнаружено недопустимое значение, обнаруживается ошибка формата.
Области в сообщении CAN с предопределенными значениями включают в себя:

Ограничитель CRC, разделитель ACK, EOF фрейма данных и фрейма дистанционного управления;
разделитель кадра ошибки
разделитель кадра перегрузки

4.3.3.3 Уведомление об ошибке

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

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

4.3.3.3.1 Состояние ошибки узла

Согласно протоколу CAN, узлы на шине CAN всегда находятся в одном из следующих трех состояний.
А. Активный статус ошибки
б. Пассивный статус ошибки
c. Всегда закрыт

При соблюдении определенных условий узел может переходить из одного состояния в другое.

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

1) Активный статус ошибки

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

2) Пассивная ошибка состояния

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

Советы: Примечание. Говорят, что узлы в состоянии активной ошибки или в состоянии пассивной ошибки все еще могут нормально взаимодействовать.
Обычный обмен данными здесь означает, что узлы все еще могут получать сообщения от шины, а также могут конкурировать за отправку сообщений на шину после ее победы.
Однако это не означает, что полученное сообщение должно быть правильным, и не означает, что сообщение может быть отправлено правильно.

3) автобус выключен
Узел находится в состоянии отключения, поэтому узел не может отправлять или получать сообщения;
Узел в состоянии отключения шины может только ждать вечно, а когда он удовлетворяет определенным условиям, он снова переходит в активное состояние ошибки.

4.3.3.3.2 Ошибка состояния перехода

Теперь мы знаем:
Узел в активном состоянии ошибки отправляет кадр ошибки с активным флагом ошибки, когда он обнаруживает ошибку;
Узел в состоянии пассивной ошибки отправляет кадр ошибки с флагом пассивной ошибки при обнаружении ошибки.

Итак, при каких обстоятельствах узел CAN находится в состоянии активной ошибки, а при каких обстоятельствах он находится в состоянии пассивной ошибки?

Согласно протоколу CAN, в узле CAN есть два счетчика:Счетчик ошибок передачи (TEC) иСчетчик ошибок приема (REC)。

Советы: обратите внимание, что:
Эти два счетчика не учитывают ни количество отправленных или полученных пакетов, ни количество отправленных или полученных кадров ошибок.
Значения счетчиков TEC и RCE изменяются в соответствии со следующей таблицей

Переход состояния ошибки узла CAN основан на этих двух счетчиках.

Можно видеть, что переход статуса ошибки узла — это процесс «количественного изменения» к «качественному изменению»:

1) Активный статус ошибки
Если в начале TCE и REC меньше 127, ** они находятся в состоянии активной ошибки.

В этом состоянии узел обнаруживает ошибку и отправляет кадр ошибки с активным флагом ошибки.
Поскольку флаг активной ошибки состоит из шести последовательных доминирующих битов, на этот раз флаг активной ошибки будет «покрывать» другие узлы на шине.
Ранее переданное сообщение на шине CAN было уничтожено этими «шестью последовательными доминирующими битами».

Если узел, отправляющий активный кадр ошибки, является отправляющим узлом, этот случай эквивалентен:
 Я просто отправил неправильный фрейм, а теперь уничтожаю его (отправляю активный фрейм с ошибками), независимо от того, что вы получаете;

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


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

2) Пассивная ошибка состояния
Если узел отправляет много кадров с ошибками, он установит TCE 127 или REC 127, тогда узел будет находиться в состоянии пассивной ошибки.

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

Если узел Node_A, отправляющий кадр пассивной ошибки, является отправляющим узлом сообщения,
 Затем после отправки фрейма пассивной ошибки только что отправленное сообщение повреждено,
 И Node_A не может продолжать отправлять сообщение, которое только что не удалось отправить после кадра ошибки.

 Далее следует интервал кадра, который сопровождается8Сегмент "отложенной передачи" рецессивного бита;

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

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


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

3) автобус выключен
Если узел в состоянии пассивной ошибки все еще отправляет кадры пассивной ошибки несколько раз, это неизбежно приведет к TEC> 255, что приведет к отключению шины.

В состоянии отключения шины узел Node_A не может отправить сообщение на шину и не может получить сообщение с шины, и весь узел покидает шину. Когда 128 последовательных рецессивных битов обнаружены 128 раз, TEC и REC устанавливаются в 0, а затем возвращаются в активное состояние ошибки.

Как я понимаю 
 Это так называемое "обнаруженное128второстепенный11«Непрерывные рецессивные биты» на самом деле держать этот узел изолированным в течение некоторого времени, успокоиться,
 Потому что, когда он находится в выключенном состоянии, он не будет иметь никакого соединения с шиной.
 В это время, пока он рассчитывает время, равное достижению передачи128второстепенный11Время, необходимое для двух последовательных рецессивных битов, может быть повторно подключено к шине.


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

4.3.3.3.3 Передача кадров с ошибками

Когда кадр ошибки отправляется после обнаружения ошибки?
Согласно протоколу CAN:
Ошибка бита, ошибка заполнения, ошибка формата, ошибка ACK: Кадр ошибки начинает передаваться рядом с битом, в котором произошла ошибка.
Ошибка CRC: Кадр ошибки передается сразу после разделителя ACK.

Пример 1: ! [Вставьте описание изображения здесь] (https://img-blog.csdnimg.cn/20190715180704148.png?x- oss-process = image / watermark, type_ZmFuZ3poZW5naGVpdGk, shadow_10, text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NpZWxsZWU =, size_16, color_FFFFFF, t_70), узел_ отправляется из узла, и отправляется из узла. Возникает битовая ошибка; (2) После того, как Node_A обнаруживает битовую ошибку, он немедленно отправляет активный кадр ошибки со следующим битом: флаг активной ошибки из 6 последовательных доминирующих бит + 8 последовательных рецессивов Разделитель битовых ошибок; (3) В соответствии с флагом активной ошибки, отправляемым Node_A, уровень на шине составляет 6 последовательных доминирующих битов;

(4) Принимающие узлы Node_B и Node_C прослушивают 6 последовательных доминирующих битов из шины, тогда будет обнаружена ошибка заполнения, поэтому оба узла отправят активные кадры ошибок;
(5) В соответствии с флагом активной ошибки, установленным Node_B и Node_C, уровень шины имеет 6 последовательных доминирующих уровней, соответствующих разделителям ошибок, выпущенным Node_B и Node_C. 8 последовательных рецессивных уровней.
(6) После прерывистого поля узел Node_A повторно отправляет только что появившееся сообщение.

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

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

Каждый узел состоит из двух составляющих. Это собственно CAN контроллер, который обеспечивает взаимодействие с сетью и реализует протокол, и микропроцессор (CPU).

Рис. 1. Топология сети CAN.

CAN контроллеры соединяются с помощью дифференциальной шины, которая имеет две линии — CAN_H (can-high) и CAN_L (can-low), по которым передаются сигналы. Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L. Логическая единица — в случае когда сигналы CAN_H и CAN_L одинаковы (отличаются менее чем на 0.5 В). Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях. Логический ноль — называется доминантным битом, а логическая единица — рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN. При одновременной передаче в шину лог. нуля и единицы, на шине будет зарегестрирован только логический ноль (доминантный сигнал), а логическая единица будет подавлена (рецессивный сигнал).

Типы сообщений сети CAN.

Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:

• Data Frame
• Remote Frame
• Error Frame
• Overload Frame

Data Frame — это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей:

• поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть. Поле арбитража состоит в свою очередь из:
  • для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
  • для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)

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

• поле данных (data field) содержит от 0 до 8 байт данных
• поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок
• слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.

Рис. 2. Data frame стандарта CAN 2.0A.

Remote Frame — это Data Frame без поля данных и с выставленным битом RTR (1 — рецессивные бит). Основное предназначение Remote кадра — это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).

Error Frame — это сообщение которое явно нарушает формат солобщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.

Overload Frame — повторяет структуру и логику работы Error кадра, с той разницей, что он используется перегруженным узлом, который в данный момент не может обработать поступающее сообщение, и поэтому просит при помощи Overload-кадра о повторной передаче данных. В настоящее время Overload-кадр практически не используется.

Контроль доступа к среде передачи (побитовый арбитраж).

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

Рис. 3. Побитовый арбитраж на шине CAN.

Методы обнаружения ошибок.

CAN протокол определяет пять способов обнаружения ошибок в сети:

• Bit monitoring
• Bit stuffing
• Frame check
• ACKnowledgement Check
• CRC Check

Bit monitoring — каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается.

Bit stuffing — когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.

Frame Check — некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.

ACKnowledgement Check — каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.

CRC Check — каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.

Механизм ограничения ошибок (Error confinement).

Каждый узел сети CAN, во время работы пытается обнаружить одну из пяти возможных ошибок. Если ошибка обнаружена, узел передает в сеть Error Frame, разрушая тем самым весь текущий трафик сети (передачу и прием текущего сообщения). Все остальные узлы обнаруживают Error Frame и принимают соответствующие действия (сбрасывают принятое сообщение). Кроме того, каждый узел ведет два счетчика ошибок: Transmit Error Counter (счетчик ошибок передачи) и Receive Error Counter (счетчик ошибок приема). Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.

Каждый узел CAN сети может находится в одном из трех состояний. Когда узел стартует он находится в состоянии Error Active. Когда, значение хотя бы одного из двух счетчиков ошибок превышает предел 127, узел переходит в состояние Error Passive. Когда значение хотя бы одного из двух счетчиков превышает предел 255, узел переходит в состояние Bus Off.

Узел находящийся в состоянии Error Active в случае обнаружения ошибки на шине передает в сеть Active Error Flags. Active Error Flags сотстоит из 6 доминантных бит, поэтому все узлы его регистрируют. Узел в состоянии Passive Error передает в сеть Passive Error Flags при обнаружении ошибки в сети. Passive Error Flags состоит из 6 рецессивных бит, поэтому остальные узлы сети его не замечают, и Passive Error Flags лишь приводит к увеличению Error счетчика узла. Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).

Адресация и протоколы высокого уровня

В CAN не существует явной адресации сообщений и узлов. Протокол CAN нигде не указывает что поле арбитража (Identification field + RTR) должно использоваться как идентификатор сообщения или узла. Таким образом, идентификаторы сообщений и адреса узлов могут находится в любом поле сообщения (в поле арбитража или в поле данных, или присутствовать и там, и там). Точно также протокол не запрещает использовать поле арбитража для передачи данных.

Утилизация поля арбитража и поля данных, и распределение адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так называемых протоколов высокого уровня (HLP — Higher Layer Protocols). Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.

Рис. 4. Логическая структура протокола CAN.

Существует множество таких высокоуровневых протоколов. Наиболее распространенные из них это:

• DeviceNet
• CAL/CANopen
• SDS
• CanKingdom

Физичекий уровень протокола CAN

Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411).

В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898. ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом. Физический уровень CAN реализован в специальных чипах — CAN приемо-передатчиках (transceivers), которые преобразуют обычные TTL уровни сигналов используемых CAN-контроллерами в уровни сигналов на шине CAN. Наиболее распространенный CAN приемо-передатчик — Phillips 82C250, который полностью соответствует стандарту ISO 11898.

Махимальная скорость сети CAN в соответствие с протоколом равна 1 Mbit/sec. При скорости в 1 Mbit/sec максимальная длина кабеля равна примерно 40 метрам. Ограничение на длину кабеля связано с конечной скоростью света и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети. Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице:

скорость передачи	максимальная длина сети
1000 Кбит/сек	40 метров
500 Кбит/сек	100 метров
250 Кбит/сек	200 метров
125 Кбит/сек	500 метров
10 Кбит/сек	6 километров

Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.