Померяй напряжение на хх на этом "КАНе".М.б. это псевдо-КАН,его прообраз =) МАНовская фишка,предтеча КАН-шины.Хотя х.з.,уже КАМАЗы с мочевиной бегают..все может быть.Пиши по результатам,уже любопытно

4еснок, на выходных буду у аппарата, померяю. Это будет ближе к выходным или в выходные. Машина в рейсах.

Что-то типа SAE J1587 или J1708?
По МАЗовским докам - указан CAN. Обозначение сигналов CAN-H и CAN-L.
Хотя, если там J1708 и 11-байтный пакет, то MS5.1 может и понять команды. Т.к. J1939 замена J1708 и J1587, т.е. совместимы снизу вверх.


Был удивлен, когда узнал, что на ГАЗ 3309-E4 движек common rail. Все развивается. :smile:

Тогда из дешевого лучше VAG K+CAN Commander 1.4 чем ELM но вероятность возрастает. A может говорить и о том, что там используется шина CAN, а вот в каком виде передаются по ней данные это вопрос, и тогда может оказаться что ни тот ни другой адаптер не подойдет. Отсюда и возражение о первичности программы. Кроме того, если данные передаются по SAE -J1708 то там описан интерфейс RS-485.

Да .... 17 страниц ... и не одной ссылки на доки SAE J1939 ?! :shock:

[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]
Мне кажется интересная статья.

Juan7, статья интересная, даже xls файлик нашел за 2008 год.
SAE за свежий файлик хочет 132$.

Решил я тут на форуме кобальтоводов написать, так как у самого сей "девайс", который я активно пользую в свободное время. Думал, там предметно, может, кто что знает по кану.. С позволения администрации (чтобы не переписывать все заново):
[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]
А здесь есть кому что сказать по любому из затронутых там вопросов?..

Появился у меня CANHacker, сделаю переходник - буду пробовать.

Умеет ли Delphi DS150E New VCI писать CAN шину в автономном режиме? Легко ли парсить данный лог файл?

Был удивлен, когда узнал, что на ГАЗ 3309-E4 движек common rail. Все развивается ГАЗ 3309-E2 common rail что удивительного! По CAN протоколу Вы че паритесь!В Мазе,Камазе,Газе протокол по Can 11 bit 500! Автоком или Делпши берет!Закладкой Камаз!Выбираете Эбу какой стоит и вперед!Только ошибки определяет смотри документацию от производителя!Ищете документацию например на 7UC31 и т.д!На Газах 2 разъема OBD-II, один KL для движка,второй CAN для ABS, приборки и т.д!Потом пальцами разводят,что за ошибки!

zamj, то, что Вы описали - моторный CAN.
Мой МАЗ по движку MAN F2000. ABS - любая скания или даф, который с WABCO.

Возможно, я не так выразился.
Delphi может работать в качестве самописца. Меня интересует, пишет ли в лог CAN в режиме самописца? Так же хотел узнать, криптованный ли файл лога? Логи в бинарном виде или простой текст?
Возможно, кто-то уже сталкивался с этим.

Он пишет логи данных, логи Can протокола нет,это сниффер Can нужен!Зачем Вам дебри в виде ID и куча цифр!Без документации на протоколы,а она весьма внушительных денег стоит!Просто трата времени!По снифферу это текстовый файл!Например будет лог выглядить так! 243 01 CA 23 44 02 08 77 23
430 05 DF 34 23 01 05 23 13
и т.д!Это поток данных из бесконечных цифр, кроме трехзначных,которые будут циклически повторяться, это ID номер устройства!

zamj, вот и чудненько. Инфу, кторая мне нужна - достану из логов.
Что касается документации - один файлик я ужепривел выше. Там довольно хорошо все описано.

Я выполняю определенные действия и на шину выплевываются определенные пакеты. Это обчный реверс-инженеринг протокола производителя.

Время у меня есть, да и тема интересная.

Апну темку
18 DA 3D F9 - команда блоку 3D (Denoxtronic) выдать список DTS(ошибки). F9 - адрес тестера. Если блок ответит 18 DA F9 3D 2 88 0 0 0 0 0 0 - ошибок нет. На днях попробую описание протокола выложить связанного с кодами неисправности.

Cotm, посмотрите файлик, что я бросал. Возможно, он поможет Вам в изучении дампов.

Завтра доделаю переходник на OBD и попробую снять дампы с легковой. Если все ок, доберусь до МАЗа и попробую сделать дамп на хх, в движении, поиграться транспортными положениями.

Был удивлен, когда узнал, что на ГАЗ 3309-E4 движек common rail. Все развивается. :smile:[/QUOTE]
Еще бы удивился если бы узнал что ГАЗон скоро будет с роботизированной коробкой.Спрашивается зачем надо на стоп нажать перед запуском?Еще наверно будет круиз-контроль.Бензиновый Газон бы посмотрел Е3 с блоком МИКАС10.3 ,но не инжекторный.Карбюратор ,трамлер блок Микас нужен только для регулировки холостого.БРЕД полнейший в нашей стране и ближнем зарубежье.

Купил свежий файлик ..... :biggrin1:
Файлик подрос до 7.3 Мбайта за 7 лет ....

Существует неплохой КАН монитор, в софте SDD для диагностики марок РОВЕР и Ягуар есть там CAN Link Monitor.exe который работает с любым совместимым адаптером для этого софта. Возможна работа его как отдельной програмки и возможно использовать с умом для других брендов там КАН на двух скоростях 500kHz и 125kHz, в зависимости от адаптера имеет возможность мониторить и оптику.
В последних автомобилях бренда РОВЕР в ОБД колодку выведены все локальные шины КАН их там уже 5-ть. В оригинальном софте SDD во время диагностики возможен одновременно мониторинг шины КАН и в зависимости от качество адаптера успевает на 100% делать протокол мониторинга.

А еще можно снифать кан шину любым преобразователем CAN-USB, на микросхемах SJA1000 TJA1050, чем нибудь вроде CommOperator :thumbup:

Сделал дамп с легковой, сейчас буду ковырять.
Есть подозрение, что в легковых немного не J1939, а J2234. На основании чего сделал такие выводы: Есть Teltonika FM5300, пробовал запустить Can Scanner через конфигуратор - не видит шины, пишет что нет подключения.
Возможно, я не так что-то делал?

Итак судя по всему я нашел Только 1 CAN - 500kbps.
Все сканы делал только для 11 bit CAN identifiers, 29 bit CAN identifiers - не смотрел. Возможно SAE-J2234, ISO 15765 требуют 29 bit CAN identifiers.

PS. Подопытный - Hyundai i30.

Немного не понял, что Вы делали.. Итак, сканировали шину кан через диагностический разъем по пинам 6 и 14?
А далее? Ведь получили же какой-то лог? В чем же сомнения?..

Да, именно это и делал.

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

Ну и попутно сомнения с другим прибором (AVL-треккером). Возможно я некорректно с ним работал, т.к. не получил ответ с CAN-шины. Но это уже другая история 8)

Буду парсить лог, результаты трейса выложу позже.

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

Hyundai Grand Starex, H-1 после 2007г. ISO-15765.

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

Спасибо за подсказку, буду смотреть.

Чтобы "ковырять" КАН в первую очередь нужно осознать что это в первую очередь ТРАНСПОРТНЫЙ ПРОТОКОЛ в который вживили протокол диагностики, сначала каждый производитель делал свое а потом сперва адаптировали общий KWP2000 а потом чтобы навести порядок трансформировали в UDS . Как для "транспортной шины" каждый производитель делает что хочет и передает что хочет.

ddk_f, а где я написал про транспортный? Я сомневался в выборе Application Layer

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

ddk_f, еще раз спрашиваю, где я написал про транспортный?

Меня интересовала инкапсуляция пакетов протокола более высокого уровня. Она найдена. Что Вы пытаетесь доказать?

Для новичков Ваша информация будет полезна.

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

//
 

Ещё раз - удалось связаться с шиной (то есть, каким-то образом увидели, что данные идут и(или) записываются), - значит, "транспортно - стандартный" уровень CAN преодолели. Далее - надо думать, как интерпретировать полученные данные. Это все равно, что получил я, к примеру (пример, кстати, реальный, - из того времени, когда изучал ОБД и у меня на авто как раз периодически высвечивался чек), в 4-м и 5-м байте ответа на запрос 0x7DF 01 03 00 00 00 00 00 00 (идентификатор и 8 байт данных) получил ответное сообщение 0x7E8 04 43 01 08 33 AA AA AA (здесь в принятой форме 16-ричной записи (0x) я указал только для идентификаторов сообщений, хотя данные представлены также в 16-ричной форме) Теперь надо понять, какая информация тут представлена. Для этого берем открытое описание OBD и интерпретируем: "0x7DF" - это идентификатор запроса на диагностику по ОБД стандарту (об этом я прочитал ранее, причем в разных местах, в Вики, на буржуйских сайтах и форумах канхакеров и т.д. и уже знал, с каким идетификатором должно быть это сообщение. Далее нулевой байт этого сообщения имеет значение "01". Этим я сообщаю системе диагностики, опять же по стандарту ОБД, что "далее следует 1 байт с данными, а после него - можно байты не читать, - все равно в них не содержится никакой информации". То есть, нулевой байт определяет длину поля со значащими данными. Следующий (первый) байт имеет значение "03". По стандарту ОБД - это служба, отвечающая за хранение и предоставление по запросу действующих на настоящий момент ошибках. Теперь ответное сообщение: "0x7E8" - идентификатор стандартного ответного сообщения. "04" - то же самое - количество следующих байт с полезной информацией "43" - байт, получаемый суммированием 16-ричных 03 (которое я посылал в запросе) и 40 (40 прибавляется всегда в ответном сообщении если все нормально и запрос корректный и принят) - тем самым подсистема диагностки авто как бы дает понять, что она принимает и обрабатывает запросы. Дальше - непосредственно данные: "01" - количество сообщений, содержащих данные об ошибках (ведь их может быть и не одна) В данном случае - ошибка одна и она вполне вместилась в это же сообщение, так как на код каждой ошибки тратится 2 байта. (Видимо, поместится и две ошибки, просто, соответственно, в нулевом байте будет указана длина поля со значащими данными не 4 а 6.) "08" и "33" - непосредственно код ошибки. Не буду долго расписывать, как он декодируется (можно посмотреть в Вики), скажу только, что прикольно - визуально в 16-ричной системе можно сразу сказать без "особой тренировки", что код ошибки P0833. Далее - по-крайней мере в моем Кобальте незначащие байты заполняются именно АА (может, видимо, быть по другому, однако это не интересует - по нулевому байту можно точно сказать, сколько байт рассматривать). А вот далее - по коду ошибки узнаем, что эта ошибка - датчика положения педали сцепления.. Так вот, все эти "описания" как интерпретировать все данные (получаемые, отсылаемые) и проч. и описаны в открытом протоколе обмена ОБД.

----------

Вот реальный принт-скрин лога в момент, когда я посылал запрос и получал ответ как раз для вышесказанного:
http://s020.radikal.ru/i702/1503/d7/a2f33b536569.jpg
Вообще, сообщения делятся на два вида - постоянно "висящие" в шине - это служебные, которой обмениваются блоки как раз по протоколу производителя, некоторая информация из которых понятна, о чем я писал ранее.
В данном случае, во фрагмент кадра попали несколько сообщений между моим запросом и ответом системы.
По времени получения кадра видно, что ответ на запрос пришел примерно через 1 мс.
Интересно, что постоянные служебные сообщения посылаются с периодом менее 1 мс. Это очень быстро - учитывая скорость обмена - 500 кбит/с.
Для эмуляторов это говорит о том, что дешевенькие простенькие контроллеры, допустим ELM327 не справятся с задачей полной эмуляции...

----------

Добавлю - это выполнено при помощи универсального CAN-USB адаптера Marathon.
Можно было, конечно, настроить его аппаратный фильтр для пропуска только интересующих сообщений (настраивается как для одиночного сообщения, так и для группы идентификаторов - по диапазону). Фильтры чаще всего и применяются в подобных случаях - когда в сети много сообщений (сеть сильно загружена), и, чтобы не тратить процессорное время контроллера адаптера и программно-процессорное время непосредственно обрабатывающей системы (например, компа с соответствующей ОС и ПО), и премяняются фильтры.
Как правило, при разработке протоколов обмена стараются скомпоновать сообщения по их идентификаторам наряду с приоритетностью, принадлежностью к тем или иным группам и проч. ещё и из соображений простоты и удобства пользования аппаратной фильтрацией.
Так например, в случае с ОБД при снятии марафоном, - я устанавливаю фильтр (на самом деле в аппаратной фильтрации всегда два параметра - MASK и CODE) и маску и код фильтра в 0x7E0, и адаптер начинает пропускать на обработку сообщения только с идентификаторами из диапазона ОБД.
В том примере, что на рисунке, я аппаратной фильтрацией не пользовался - там мне было интересно, как это все будет коррелировать с другими (служебными) сообщениями...

----------

Так вот - самое главное - реверс - инжениринг и предполагает разобраться во всех этих служебных протоколах конкретного производителя, как это я показал на примере открытого протокола ОБД.
У меня уже есть дешевенькие кан-сканеры vag-com, op-com.
Интересует для GM. Что можно приобрести по цене не выше 5 килорублей?

[QUOTE=Alexo;275580]Для этого берем открытое описание OBD и интерпретируем: "0x7DF" - это идентификатор запроса на диагностику по ОБД стандарту (об этом я прочитал ранее, причем в разных местах, в Вики, на буржуйских сайтах и форумах канхакеров и т.д. и уже знал, с каким идетификатором должно быть это сообщение. Далее нулевой байт этого сообщения имеет значение "01"./QUOTE]

В протоколе "UDS" адрес "0x7DF" для общих команд, к примеру если подать команду вытереть ошибки "14" то откликнутся все блоки на исполнение этой команды.

В пакете первый байт не нулевой а количество байтов , если первая цифра 1Х то пакет длинный , пример 07 - это семь байт а есле 10 08 то это уже 8-мь байт так как он в транспотный КАН не влезает передают его в несколько КАН-посылок. 1F F8 - это передача FF8 hex байт.

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

"Нулевой" - в смысле по счету - это для обывателей счет байтов начинается с 1-го по 8-й, для программистов же это ОБЯЗАТЕЛЬНО с 0-го по 7-ой (так же как и биты). Это важно, так как внутреннее представление определенных байтов и бит в контроллере происходит именно так.
С остальным согласен - в стандарте ОБД все расписано, думаю более детально разжевывать смысла нет...

Как то все натянуто, обычно ответ с ID 00 00 07 E8 приходит на запрос ID 00 00 07 E0.

На что "натянуто"?.. Что значит "обычно"? А бывает и не приходят?
На 7E0 ТОЖЕ придет аналогичный ответ.

P.S. А чего это обозначение идентификатора с кучей нулей (не лень нули писать), или имелись ввиду 29-битные идентификаторы?..

Значит, что адрес запроса и ответа отличается на 8.
не лень, ID передается 4 битами.

Вы вообще представляете предмет, о котором пишите с такой уверенностью?
Вот ещё отдельный запрос и ответ, если не понятен пример, приведенный выше:
http://s017.radikal.ru/i437/1503/15/483c257bcb40.jpg
Ну и сложите 7DF с 8, если получите в сумме 7E8 - получите премию математического института Клэя.
Вообще - моя прога использует только 7DF - запросы и прекрасно получает 7E8 - ответы по всему ОБД-протоколу.
Насчет - "не лень" - у каждого свои причуды..

Alexo, все правильно пишет GASCHE. 7DF, как писал Да вы тоже читали это.
Но есть еще 8 адресов, для каждого из 8 блоков. Т.е. 0x7E0:0x7E8 - пара request/response для первого ECU. Т.е. команды шлем на 0x7E0, а ответ получаем от 0x7E8. И так для каждого последующего ECU.
Например, у меня на посыл команды сброса всех ошибок в 0x7DF - приходит ответ c ID 0x7DC.
Список команд диагностики - см. ISO 15765-3. Chapter 9. Diagnostic service implementation. Посмотрите таблицы 59,60 главы 10.4.2 этого же документа.
Адреса, про которые я писал, вы найдете в ISO 15765-4. Глава 11bit CAN Identifiers.

----------

Сегодня к МАЗу подключиться не удалось, т.к. переходник, которым я пользовался, от Autocom. Других разъемов у меня нет, а автокомовский - литой, раздербанить можно, но не стоит.
Попробую сделать отдельный шнур для МАЗа с пинами и еще разподключиться.

----------

Такое лучше не делать не зная комманд. Не зная номера блока ECU можно нарваться на ECU SRS. Ну и послав что-то не то, могут стрельнуть подушки (тут я утрирую, но все-таки предостережение). :smile:
IMHO, Если команда предназначена какому-то блоку единолично, то лучше слать по request ID этого блока.
Как поступать дальше - решать Вам.

Да я тоже посылал и все эти 7E0 и иже с ними - ответы идентичны 7DF (хотя у себя в проге по ОБД на всякий случай сделал, что можно изменять идентификатор запроса на любой другой).
Более того - я тоже где-то читал, что в некоторых случаях прибавляется 8-ка. Но, далеко не во всех. Поэтому и сам по-возможности, пока лично не проверю, - не делаю безапеляционных заявлений.
По крайней мере, на Кобальте и Фольксе Т5 2008 г. это так. Кстати, что интересно, на Т5 (но только уже 2004 г.) связаться по кан не удалось - как оказалось, - он там хоть и есть, но - внутренний для межблочного общения а на диагн. разъем не выведен.

----------

Все правильно, однако, вышесказанное следует изложить так - можно посылать любые сообщения с идентификаторами больше 0х7DF без боязни. А вот ниже - действительно надо аккуратно..

На МАЗе выведен, но т.к. это шнру-переходник с мультимарочника, то контакты моуг быть попутаны со стороны OBD-II разъема. Внутри литого разъема могут стоять перемычки для определения типа разъема к которому подключен мультимарочник.
Попробуйте через CAN крокодилы подцепиться. Думаю, что схему найти не проблема, да EDC/ECU в фольце может быть бошевский. На него точно распин есть.

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

А на разъеме пины видно? Отдельно к ним можно подключиться? Или вообще ничего не известно, а потому опасно?

----------

Да уже после нашел в нете, что кан есть, но на разъем не выведен..
А, в смысле, к блоковскому кану подключиться, не "разъемному"?

Да, пины есть.
Я планирую подключиться на пины в разъеме МАЗа. Там MANовский 37пиновый разъем. CAN,KL-Line выведен точно. EDC Bosch MS5.2, двигатель MAN.

О результатах сообщу позже. Пока смотрю дампы с легковой.

PS. Удивило то, что в легковой используются 11 битные идентификаторы. Решил проверить на тягаче. Там должны быть 29 битные. и связь EDC и ABS по SAE J1939.

----------

Ну да. Либо по схеме найти провода и подключиться через крокодилы.