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

Молодчина !!!!!
 

КЛАСНУЮ ТЕМУ ПАДНЯЛ!!!!!!!
НИ ВСЕ ВОЛОКУТ- В ЧЕМ ПРИКОЛ!!!!!!
А КТО ВОЛОКЁТ ПОМАЛКИВАЕТ!!!
ЕСЛИ ЭТУ ТЕМУ РАСКАЧАТЬ-- ПРОДАВЦАМ АВТОДИАГНОСТИКИ НЕ СЛАДКО БУДЕТ,,,,,,,,

USB-CAN адаптер 150 у.е
USB-K Line адаптер 50 у.е
USB-Lin адаптер 100 у.е

ВОТ и вся диагностика!!!!!! ВЕСЬ МИР ЗАКРЫВАЕТ!!!
ну и до кучи RS485.....
USB-CAN транслирует данные в реальном времени ВСЁ что происходит в автомобиле видишь в реальном времени(АБСОЛЮТНО!!!)
ХОЧЕШЬ БОЛЬШЕГО-ПОЖАЛУЙСТА.... отправляешь команду через USB-KLine, и по кану возвратом ещё больше параметров!!!!

Если переферию посмотреть--USB-Lin тебе в помощь!!!!!!

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

МЫ ХОТИМ УЧИТСЯ!!! но нас никто не учит.........
 

КАКИМ АДАПТЕРОМ ПОЛЬЗУЕШСЯ РАСКАЖИ.....
КАКОИ ПРОГОЙ ИНТЕРПРЕТИРУЕШЬ СООБЩЕНИЯ?...
ПОПОДРОБНЕЕ ПОЖАЛУЙСТА..... ТЕМА ООООООЧЕНЬ ИНТЕРЕСНАЯ.
ЕСЛИ самому залазить с нуля, при отсутствии информации-это капец!!!
ЛИЧНО Я РАД ,что появился такой ЧЕЛОВЕК !!!

Alexo НАДО развивать эту тему!!!!!
(Эту ветку,в частности)
так что . всё с нуля- и поподробнее....(читателей будет- ОКЕАН)

Да, полностью согласен..
Я использую MARATHON и IXXAT - CAN-USB адаптеры. Самое главное, что программирование под них отработано (у одного - юзаешь библиотеку CHAI, у другого - API расписаны). Кроме того, есть и стандартные программы, идущие с ними..
А по поводу CAN - да, возможностей масса - мы действительно, помимо диагностических, видим ВСЕ сигналы (и управления, и от периферии) В РЕАЛЬНОМ времени, помимо этого, можем вмешаться в любой процесс управления (понятно, что ОООчень аккуратно и четко осознавая, что делаешь, - для этого и нужны точные протоколы обмена, в частности)... Тут, как говорится, ещё то "поле деятельности"...
На меня уже, правда, вышли, обещали прислать для Форда (2006 -...) протоколы.

надо идти дальше.
 

например
начать показывать -как с ними работать.
1.видео работы интерпретатора.
2.команды
3.прописывание (интерпретаций и отправляемых команд)
4. графические оболочки и работа с ними.

дело за тобой...
что касается кан-сообщений(протокольных) -они все стандартизированны по SAE (95%) и лишь 5% это для OEM.
но их тоже найти можно. некоторые выложены.
SAE их продаёт -2000уе но и выложенных тоже есть....

Один из приборов
 

Это ешо одно устойство
 

SAE 1939
 

Протокол SAE J1939 определен SAE и предназначен для коммерческих транспортных средств, а также для морских судов, железнодорожных транспортных средств, сельскохозяйственного оборудования и больших генераторов. SAE J1939 является базой для международных стандартов NMEA 2000 (морские) и ISO 11783 (ISO шина для сельскохозяйственного оборудования), поэтому протокол SAE J1939 можно использовать и для этих приложений.

Последовательные протоколы для коммерческих транспортных средств, стандартизированные SAE, применяются уже давно. Они предназначены для установления связи между отдельными электронными блоками управления и компонентами приводных механизмов. J1708/J1587 протокол основаный на последовательном порте, обычно доступным в микроконтроллерах, может рассматриваться как предшественник J1939.

Для того, чтобы обеспечить требования совместимости с J1708/J1587 протоколом, необходимо расширение идентификатора CAN сообщения (с 11 бит до 29 бит – расширенный формат), а также разработка CAN модулей или реализация протоколов, поддерживающих формат такого сообщения.

Расширенный CAN идентификатор позволяет установить соответствие между принципами связи CAN и J1708. Для этого, часть идентификатора используется для определения 8-ми разрядного исходного адреса и 8-ми разрядного целевого адреса (номер узла). С помощью SAE J1939 возможно как передавать значения измерений и управлять данными, так и конфигурировать компоненты. Также возможно считывать или удалять диагностические данные отдельных компонентов, а также выполнять калибровку отдельных единиц управления.

Чтобы это стало возможным в SAE J1939 определяются всек переменные, относящиеся к коммерческим транспортным средствам, вместе с их диапазоном значений, дискретностью, идентификационным номером и т.д. Это реализуется на основе уже имеющейся в J1587 спецификации.

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

SAE J1939 и ISO/OSI уровневая модель


SAE J1939 имеет несколько уровней, соответствующих OSI уровневой модели. Каждый уровень определен соответствующим документом. Аналогично практически всем протоколам полевой шины, в SAE J1939 уровень 5 и уровень 6 не используются, поэтому они не определены для данного протокола.



Функциональность SAE J1939 разделяется в соответствие с уровнями:

SAE J1939-1X. A Physical Layer (физический уровень) – определяет электрический интерфейс и физическую среду
SAE J1939-21. Data Link Layer (канальный уровень) – определяет обмен данными по CAN согласно спецификации CAN 2.0B
SAE J1939-31. Network Layer (сетевой уровень) – в основном, описывает функциональность моста для обмена сообщениями между двумя сегментами сети. Он является значимым только для реализации J1939 моста
SAE J1939-4X. Transport Layer (транспортный уровень) – описывает сетевые сервисы для режима запроса сообщений, передачи уведомлений и фрагментированной передачи больших блоков данных
SAE J1939-71. Vehicle Application Layer (прикладной уровень) – описывает фактические данные (параметры или переменные сети с диапазоном значений, разрешением, физическим модулем и типом передачи). Каждое сообщение имеет однозначную ссылку по номеру (номер группы параметров)
Так как управление сетью может рассматриваться как отдельный элемент (распространяется от 7 до 1 уровня), то этот блок в уровневой модели представлен как независимый функциональный блок, изображенный на рисунке справа. Обычно управление сетью состоит из автоматического назначения или определения адреса узла (принцип plug & play). В SAE J1939 не определен мониторинг узла, он реализуется с помощью циклических сообщений на прикладном уровне.

НА ТЕБЯ ВСЯ СТРАНА СМОТРИТ!!!
 

ALEXO примерно в таком духе продолжи,пожалуйста.
И несколько практических примерчиков, очень помогут пониманию глубоких уровней диагностики- а это приведёт к широкому интересу к этой теме.
адаптеры то стоят копейки.

на самом деле- нужно только расширить базу данных по сообщениям(КАН) .РАЗОБРАТЬСЯ с интерпретацией(расшифровка) их.
как только народ это увидит........

Тут, для меня проблем работы с МАРАФОНОМ вплоть до создания своих программулин, например, нет. Дело больше в самом CAN – для самого начала неплохо бы изучить структуру КАН-кадра (или «сообщения», или «фрейма» – в разной документации возможно различное название). Для этого, опять же, надо представлять для чего вообще была создана эта технология и, если хотите, её «философия» - то есть, чем принципиально она отличается от других (того же, например RS485). Тут важно понимать, что за «простоту» принципа обмена информацией «расплачиваются» повышением общих накладных за счет обязательности у каждого прибора в сети наличия КАН-контроллера. Далее, - естесственно, это все стандартизировано, и ещё на аппаратном уровне имеются и проверки целостности, и защита от ошибок, и аппаратные фильтры и ещё много чего нужного, но делаемого автоматически и, таким образом, освобождающего программиста от заботы об этом всем.. Для программера остается только сам формат кадра – идентификатор сообщения и восемь байт с данными. И ВСЕ – больше он ни о чем может не волноваться. Протокол обмена устроен так: например, там написано, что некий датчик общается с основными «мозгами» авто в следующем порядке: на скорости 500 кБит/с, форма – «запрос – ответ», формат данных – «в первом байте – каждый бит (из 8-ми) говорит о его состоянии, - 1-ый, допустим, исправен-неисправен (да-нет – булева переменная, 2-ой – есть связь-нет связи, третий - ещё какие-то булевы параметры.)» То есть первый байт, по протоколу ответственен за булевы переменные (да-нет). Второй байт может быть уже какой-то аналоговой величиной (допустим, напряжение). Тогда весь байт отдан под него (может быть под аналоговые переменные отдано и больше – один байт максимум обеспечивает 255 – и то, если беззнаковая переменная, если знаковая – то до 127). Ну, и так далее – все зависит от того, как заранее ДОГОВОРИЛИСЬ это все дело передавать. Если для передачи данных не хватает восьми байт, то в протоколе прописывают ещё один кадр со своим идентификатором и восемью байтами данных. И т.д. Далее – контроллер датчика постоянно слушает сеть (как, впрочем, и все остальные контроллеры остальных приборов). «Слышит» он все сообщения, которые в ней «гуляют». Как только он услышал в сети кадр с идентификатором, который прописан у него программно (или в фильтре), только на него он реагирует – шлет свой пакет из предписанных ему по протоколу сообщений (о своем состоянии, величинах которые он контролирует и проч.) Кстати, очень часто, в одном из байт, как правило, передается так называемый «счетчик» - в каждом новом сообщении величина счетчика увеличивается на 1 и так до 255, потом – по-новой. Для «принимающей» стороны это, хоть и косвенно, говорит о том, что прибор исправен. Да и при необходимости, можно точно восстановить последовательность кадров. Формат общения не обязательно может быть «запрос-ответ», зачастую такие приборы, как датчики сами с некоторой «договоренной» периодичностью шлют свои сообщения. Или наоборот, - шлют только по запросу, если же превышен некоторый критичный порог, - начинают слать постоянно с некоторой периодичностью.. И т.д. – все это и есть описание протокола информационного обмена… Ну, как, нужен такой «ликбез»?... :smile: