Glmi bizerba ошибка инициализации can bus eksi 2

Часовой пояс GMT +3, время: 23:26.

Автор

Colonel Burrows · Опубликовано 35 минут назад

Ни хрена ты мне ничего не доказал, ты фраернулся, что индуктивность твоей полуобмотки-120гн, а где это видно конкретно? Абсолютно точно можно всё расчитать без твоих Шмелей, если задать стабилизированное напр. на экранной сетке. Задать анодное, да не простое, а реальное, на котором будет работать проектируемый усилитель У меня давно сложилось мнение, что ты не разбираешься в ВАХах на лампы и понятия не имеешь, что такое нагрузочная линия.  Индукция в сердечнике и магн. проницаемость, определяется проще простого-поход в институт физики металлов, коньячок с колбаской и дело в шляпе. Критерий проверки правильности сконструированного транса-сравнение активных и приведённых сопротивлений обмоток расчётных, с реальными. Если всё в пределах нормы, то и все параметры взятые при расчёте, тоже будут в норме. Шмель отдыхает! Это не моя идея-так говорил незабвенный Кондо-сан. Преимущества торов перед другими видами сердечников-чисто инженерно-технологические, НО НЕ ЗВУКОВЫЕ! Они проще, дешевле, экономичнее, но они не музыкальны. Торы не годятся  для звука, это твой маркетинговый ход, Василич, скрытая реклама твоей продукции. Поставь рядом твой усилитель и Аудио-Ресёрч VT-60, да с филармонии пригласи музыкантов, сравнение будет не в твою пользу-уверяю.  Люди, хлопающие тебе в ладоши и ошарашенные твоими картинками  и графиками-это люди (твой электорат), ничего никогда не слышавшие в своей жизни, не имеющие коллекций звуконосителей и не имеющие слуха, вон как этот карабас-барабас. Но я тебе прямо говорю — не может нормально работать усилитель на таком керне как у тебя, не верь приборам, а верь ушам профи-музыкантов, если у тебя со слухом херово. Ты поставил на поток свои поделия, я не возражаю, бизнес есть бизнес и без рекламы не обойтись. На Шмелях и на осциках проверяли и настраивали с парнями-музыкантами усилители примерно по твоей методике, но вот незадача, при мин. КНИ и ИМД и маленьких вых. трансах, куда-то пропадала музыка, я не расслышал Вест-сайдскую историю Леонарда Бернстайна, Голубые Гаваи Элвиса Пресли, звучание было замыленным и неясным. Не любит музыкальный сигнал  насилия над собой-ему простор нужен, но если ты строишь свои усилители только как регистрационно-демонстрационный прибор и щеголяешь этими картинками, то конечно, мне с тобой не по пути.

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

Вот скетч:

// demo: CAN-BUS Shield, send data
// [email protected]

#include <mcp_can.h>
#include <SPI.h>

// the cs pin of the version after v1.1 is default to D9
// v0.9b and v1.0 is default D10
const int SPI_CS_PIN = 10;

MCP_CAN CAN(SPI_CS_PIN);                                    // Set CS pin

void setup()
{
    Serial.begin(115200);

    while (CAN_OK != CAN.begin(CAN_500KBPS))              // init can bus : baudrate = 500k
    {
        Serial.println("CAN BUS Shield init fail");
        Serial.println(" Init CAN BUS Shield again");
        delay(100);
    }
    Serial.println("CAN BUS Shield init ok!");
}

unsigned char stmp[8] = {0, 0, 0, 0, 0, 0, 0, 0};
void loop()
{
    // send data:  id = 0x00, standrad frame, data len = 8, stmp: data buf
    stmp[7] = stmp[7]+1;
    if(stmp[7] == 100)
    {
        stmp[7] = 0;
        stmp[6] = stmp[6] + 1;
        
        if(stmp[6] == 100)
        {
            stmp[6] = 0;
            stmp[5] = stmp[6] + 1;
        }
    }
    
    CAN.sendMsgBuf(0x00, 0, 8, stmp);
    delay(100);                       // send data per 100ms
}

// END FILE

шилд сидит с верху на ардуино

вот шилд

const int SPI_CS_PIN = 9; писать пробовал, не помогло

Доброго всем времени!
Эпопея началась давно, с момента приобретения китайского ГУ на Андроиде.
В кратце, с самого начала были проблемы с тем, что заявленный функционал не работал, а точнее не отображадось комфортинфо и не работало автоматическое отключение ГУ, что приводило к разряду АКБ. У продавана отжал 30% стоимости и начал копать что и как.
Для начала выяснил, что у нас в авто нет привычного АСС, и дело точно в канбус декодере, который это АСС и делает для ГУ, как в прочем и переводит на понятные значения для ГУ множество инфы из канбус шины. Ок. Капаем дальше. Долгими переборами и комбинациями понял, что виснет декодер после первого перезапуска авто с момента отсоединения АКБ. Ок. Поставил в цепь питания декодера микрик от ресета кейса ПК. Алгоритм следующий, после глушения мотора, для надёжности или просто перед заведением мотора, нажимаем на микрик, тем самым ресетится декодер и… И о чудо, тогда весь заявленный функционал работает!
Понятно было, что декодер по какой-то причине виснит. Возможно прошивка кривая, или ещё чего, как в прочем может и не поддерживаются новые версии б6х…
Не важно. Были разные мысли как допилить и приколхозить. Много читал, гуглил, общался. И нашел повторяющиеся записи про то, что в разных местах нашего авто, люди в проводке получали сигнальные 12 вольт. Кто с двери брал, кто с кондиционера и ещё кто где, но все оно было не то, ибо были побочки. В итоге наткнулся на то, что с фишки замка зажигания, на 16м пине (зелёный) есть заветный сигнал при попадании ключа в замок! Опантки! И ведь да, оно вроде как для разблокировки руля! Замечательно. Врезается в пин:

Далее выводим сигнальный провод к разъёму квадрлока. Можно его туда и интегрировать, но этого мало. Я не решился на него вешать нагрузку. Пошел путем изолирования нагрузки от сигнального провода. На разборке выдернул 12 вольтовой реле с какой-то машинки, на 4 пина ( кажется 30, 65, 66, 67), и запитал через него декодер. И о чудо! Все как в аптеке. Теперь как ключь в замке, реле питает декодер и вуаля, он даёт и АСС и переводчиком работает для ГУ.
Кстати, данный метод подходит и для тех у кого были проблемы с кан шиной, проблемы с засыпанием. Ведь в данном варианте к ней ничего не подключено и она спокойна ;))) в смысле пока не запитаем декодер, то шину никто не читает.

Вот и все! Радости всем и знайте, терпение и блудливые ручки все перетрут ;)))
Всем добра!

Вот оно, доработано

Еще раз о диагностике CAN-шины

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

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

Конструктивно шина представляет собой неэкранированную витую пару. Провода шины называются CAN High и CAN Low.

Шина может находиться в двух состояниях:

1. Рецессивное состояние, или логическая единица. Оба провода в этой ситуации имеют практически одинаковый потенциал: и на проводе CAN High, и на проводе CAN Low присутствует около 2 , 5 В. В рецессивном состоянии шина может находиться сколь угодно долго, хотя в реальности этого не происходит, ведь рецессивное состояние – это всего лишь пауза между сеансами передачи информации.
2. Доминантное состояние, или логический ноль. В него шина переходит тогда, когда один из входящих в сеть блоков управления начинает передачу данных. Потенциалы на проводах шины меняются следующим образом: на проводе CAN High потенциал повышается на один вольт, на проводе CAN Low наоборот, становится на один вольт ниже.

Рассмотрим форму сигнала шины, чтобы обосновать ее помехоустойчивость:

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

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

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

Сигнал шины поступает в блок управления на дифференциальный усилитель и обрабатывается. Иллюстрация поясняет процесс обработки:

Большинство автопроизводителей придерживаются скорости передачи 500 кБд, соответственно, продолжительность одного бита при этом составит 2 мкс.

Поговорим о топологии CAN-шины. Физически у шины нет начала и нет конца, шина – это просто единая сеть. Чаще всего встречаются два типа топологии: линейная топология и топология «пассивная звезда», а также их сочетания.

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

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

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

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

Перед нами автомобиль Infinitit Q 50 , оснащенный весьма редким турбированным мотором VR 30 DDT объемом 3 . 0 л и мощностью 400 лошадиных сил. Но проблема заключается не в этом замечательном агрегате, а как раз в CAN-шине: подключив диагностический сканер, не удается установить связь с доброй половиной блоков управления.

Нам повезло – Nissan относится к тому узкому кругу производителей, которые дают диагностам качественную и полноценную информацию. В том числе есть в документации и подробная топология бортовой шины обмена данными. Открываем, смотрим:

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

Итак, первое, что нужно увидеть, это то, что вся сеть разделена на три большие ветви, обведенные пунктиром:

• CAN communication circuit 1 (Коммуникационная цепь CAN 1 );
• CAN communication circuit 2 (Коммуникационная цепь CAN 2 );
• Chassis communication circuit (Коммуникационная цепь шасси).

Первые две цепи связаны между собой посредством CAN gateway (найдите его на иллюстрации). Цепь шасси связана с цепью CAN 2 через блок управления шасси, который также играет роль своеобразного Gateway.

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

А это – блоки цепи CAN 2 . Как видно, связи с ними попросту нет:

Также нет связи с блоками цепи шасси, но это и понятно: эта цепь, согласно блок-схеме, подключена к цепи CAN 2 .

Ну что ж, задача почти решена, осталось лишь локализовать неисправность. А для этого воспользуемся мотортестером и снимем осциллограмму на проводах шины сначала в CAN 1 , а затем в CAN 2 и сравним их.

Сделать это очень несложно, ведь обе шины выведены прямо на диагностический разъем. Согласно более подробной схеме, о которой упоминалось выше, на контакты диагностической колодки 6 и 14 выведены провода CAN 1 , а на контакты 12 и 13 – провода CAN 2 .

Снимаем осциллограмму в цепи CAN 1 . Она имеет прямо-таки академический вид:

Давайте обмерим ее с помощью линеек.

• На проводе CAN High в рецессивном состоянии потенциал составил 2 , 26 В, на проводе CAN Low – 2 , 25 В.
• На проводе CAN High в доминантном состоянии потенциал составил 3 , 58 В, на проводе CAN Low – 1 , 41 В.
• Ширина импульса, соответствующего одной единице передаваемой информации, составляет 2 мкс (обведено красным прямоугольником).

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

А теперь делаем ту же операцию на контактах диагностической колодки 12 и 13 , чтобы получить осциллограмму сигнала CAN 2 . Вот она:

Для наглядности масштаб осциллограмм на обеих иллюстрациях один и тот же.

То, что вы видите на этой осциллограмме, называется «мусор». Часто диагносты так и говорят: блок мусорит в шину. Вот только как найти блок, который это делает? Методика здесь очень проста и сводится она к поочередному отключению блоков и повторному наблюдению за сигналом шины.

Где именно находится тот или иной блок на автомобиле, в документации, как правило, показано. Например, на этом «финике» блоки расположены так:

Но в нашем случае все проще. Кстати, маленький лайфхак, возьмите на заметку. В автомобилях Nissan и Infiniti чаще всего причиной наличия мусора в CAN-шине является блок ABS. Сняв разъем с блока, сразу получаем нормальный обмен и связь сканера со всеми блоками ветви CAN 2 :

Обратите внимание на то, что связь в цепи CAN 2 есть со всеми блоками, кроме блока ABS, ведь он отключен.

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

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

Красным прямоугольником обведено время, в которое укладывается одно деление сетки. Оно составляет 0 , 2 мс. А на осциллограмме, которую мы рассматривали ранее, это время было равно 5 мкс, поэтому отображение импульсов было более правильным. Имейте это ввиду и не допускайте ошибок!

Источник

Протокол 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. Так что подписывайтесь на обновления, буду рад снова видеть вас на нашем сайте!

Источник