Назрел уже давно вопрос по поводу уровней дифференциального сигнала в CAN. Отчего может так различаться уровень.
Иммею вот такую картинку:
Нажмите для просмотра прикрепленного файла - Одна посылка.
Нажмите для просмотра прикрепленного файла - Серия посылок 1
Нажмите для просмотра прикрепленного файла - Серия посылок 2

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

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

И несколько информации о сети: в сети три устройства и преобразователь на оптоканал, с преобразователя оптоканала оптика идёт на такой же преобразователь оптоканала в электрический CAN и потом стоит одно устройство (устройство 4). Осциллограммы сняты на устройстве 1. В электрической части используется витая пара в экране, экран обьединяет минусы плат. Сеть работает так: три устройства шлют посылки с периодичностью 30 мс, а устройство на другом конце оптоканала отвечает. Соответственно чтобы небыло конфликта ID всего используется шесть разных ID.

Вопрос возник потому что с какого то момента связь стала глючить и непериодически всё выключается из-за пропадания связи.

Структурная схема сети:
Нажмите для просмотра прикрепленного файла
Судя по уровням нагрузка шины для разных устройств получается разная, хотя терминаторы стоят только в устройстве 1 и устройстве 3. Есть еще мысль: источники 3.3 вольта (которыми питается каждый трансивер SN65HVD231) на платах глючат.

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

Достаточно отличия в 10% в длительности битов.

Шина настроена правильно, работала 2 года и ничего такого небыло, всмысле глюков, осциллографом никто туда не лазил пока всё было в порядке. Все устройства однотипные, ну кроме устройства 4, которое через оптоканал цепляется. Да и глюк какой то непостоянный. Устройства - это инверторы напряжений для двигателей. Пока двигатель не включен ни разу еще связь не пропадала, как только включают двигатель, то может всё работать нормально, а может и по связи выключаться. Как видно из последней осцилограммы кто то не принимает посылку и сеть начинает засирать. Проблема в оптоканале ну может быть (и преобразователе в частности), только вот на 500кбит/с тестировал этот конвертер работал, а тут 125 кит/с всего. На объекте стоят еще две такие же системы с такими же настройками CAN и таких проблем нету. Может как-то влияет то что экран витой пары объединяет земли всех устройст, кстати на двух других системах экран повесили просто в воздухе.

Ну это уже новые обстоятельства.
CAN протокол не такой примитивный чтобы из-за одной ошибки 200 раз повторять. Он повторяет до первого же принятого пакета.
А постоянный повтор означает что кто-то постоянно не может принять.

Возможно есть некое временное защелкивание драйверов.

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

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

Дальше ситуация такая: после неполучения ответа за заданный интервал инвертор выдаёт аварию и переходит в стоп, что тянет за собой выключение всех инверторов. Причём похоже получается так: устройство 1 (может впринципе и 2-е и 3-е) запалило отвал связи CAN и выставило у себя аварию (соответственно выключилось), потом всё же видимо сообщение дожно до получателя (устройство 4) и раз выключился хотябы один из инверторов нужно выключать и остальные и выключается все остальные, потом сбрасываем ошибки с пульта и вся эта система стоит сколько угодно долго, запускаем инверторы снова и через несколько минут может или сразу отвал связи, а может и проработать хоть 10-ть часов. Обнаружилось что именно в месте установки этих трёх инверторов нету заземления, точнее оно есть но не вбито в землю в конце (там где стоят подобные инверторы и не глючат заземление нормальное). Может ли это как то влиять в купе с обьединённым минусом по экрану у CAN? Может фронты наклонить нужно?

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

У меня сейчас в работе система с двумя контроллерами движков в пике по 10 кВт каждый. Еше 7 узлов CAN дополнительно в системе.
Земли экранов везде соединены к земле плат. Заземление в одном месте - на щитке.

Контроль связи на heartbeat сообщениях.
При самых крутых перегрузках и коммутациях CAN не сбивается.
Но стоит только в каком нибудь узле чуть уйти таймингам как сразу все начинает глючить.

Ну у меня не килловатные движки, а три движка по 1,2 МВт. Таймингам счего улетать так, если работает система с такой топологией и конкретно эта отработала немало уже, разве что в оптоконверторе настройки наклона фронта несколько иные и при каких то условиях тайминги не соблюдаются? Оптоконверторы вроде поменяли местами с подобными рабочими устройствами, результатов нету, получается остаётся устройство 4 (в лице ПЛК сименс и модулем Helmholtz CAN, а именно сам модуль CAN). Ну как раз бригада скоро туда полетит будет выяснять.

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

Да дело в том что с пропускной способность всё нормально, когда всё работает как надо в 30мс проходит 6-ть сообщений всего, на скорости 125 - это 1мс*6=6мс, окно громадное остаётся, да и у устройства 1(чаще всего как щас выяснилось глючит) не самый низкий приоритет, есть мысль что на плате ножка RX модуля CAN плохо контачит (она через разъём наподобие PLD на плате). Вообщем буду ждать вестей с фронта что бы хоть как то прояснить ситуацию подробнее.
Кстати протокол не типа CANopen, поэтому как таковых отдельных сообщений контроля связи нету, есть только основные сообщения по которым и судится наличие связи (запрос-ответ), потому как система всё же реального времени.

Как я и думал что-то с линией. Ну пока результаты такие: терминатор один стоял не в том месте.