K line шина
 

Здравствуйте, подскажите пожалуйста, была ли у кого нибудь такая задача, типа снять коды ошибок с К-line шины и передать в ПО с помощью автографа. Поделитесь своими соображениями по этому поводу, если этого нельзя сделать на прямую, то какими закоулками нужно идти.

Покопался я в интернете по вышеуказанному вопросу, и выяснил, что существует такая компания, которая делает прибор под названием Адаптер-интерпретатор «RS232-ECU FMS2» по суте своей этот прибор позиционируется как прибор позволяющий считывать с ЭБУ по К-Лайн шине, моментальный расход топлива. Однако этот прибор также способен опрашивать ЭБУ на наличие ошибок и передавать коды ошибок трекеру по шине RS232, их инструкции и коды открыты для использования. Учитывая, что большое количество автомобилей используют K-Лайн шины в том числе и зарубежные и отечественные, это будет большой и полезной плюшкой для автографа!!!! прошу прокомментировать разработчиков и менеджеров ТехноКома данную мысль.

Сделайне переходник, к примеру, в j1939, продавайте как большую плюшку для АвтоГРАФ-а :good2:

Так, сразу скажу, это не реклама, а попытка с подвигнуть Вас.

вот сайт компании, ссылка непосредственно на прибор, где есть инструкции и протоколы

http://www.acelab.ru/dep.auto/RS232-FMS.php

Добавлено через 13 минут
А вот руководство пользователя с протоколами и прочей ерундой

http://www.acelab.ru/dep.auto/files..../rs232fms2.pdf

Добавлено через 35 секунд
А еще ребята там нормальные, готовы сотрудничать.

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

NickolaDed, а чем не устраивают ошибки полученные самим автографом???

А ничего, что у нас в приборе и RS232-то нет, это не автомобильный и не промышленный интерфейс?

Какие ошибки полученные автографом, он может получать ошибки?

Добавлено через 6 минут
есть преобразователи интерфейсоф http://www.ellab.ru/russian/razrabot...l203-1_rus.htm

NickolaDed, для чего нужны ошибки двигателя знать дистанционно?
Дистанционная диагностика, это как-то несерьезно, т.к. код ошибки это не далеко диагноз. Ни один диагност в сервисе не воспримет вопрос "У меня такой код ошибки, что не так?".

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

ИМХО

Почему нужно делать K-Line, да потому, что не на всех автомобилях есть CAN шина а вот K-Line шина есть на подавляющем большинстве, даже на тех где есть CAN шина.

Добавлено через 28 минут
Как правило клиенты имеют свои мастерские и своих очень грамотных инженеров и вот эти инженера, хотят знать о машине как можно больше и коды ошибок в том числе. Но таких инженеров не очень много. В сельской местности очень много техники с K-Line шиной, те же самые John Deee и Case и NewJolland, так колхозники их чинят методом научного тыка, они не знают какой датчик у них сломан, какую ошибку ЭБУ выдает, они просто начинают перебирать запчасти, подставляя новые, пока трактор не заработает. И таких организаций, тьма тьмущая. Мужики там не дураки по суте своей, могут перебрать и Case и John Deere, но они не знают причин поломок и времени на ремонт тратят много, да даже если вызывают сервисника, он тоже долго к ним едет, инженеру проще было бы узнать причину и самому все сделать в течении нескольких часов. Да клиент который очень хочет знать эти ошибки имеет свое производство, их продукция скоропортящаяся, и основное место поставок это сети, они мне говорят, - Николай нам это надо для того, что автомобиль пока приехал на погрузку механик уже к нему бежал с запчастями. У них очень плотные графики поставок. А сети как правила не прощают опозданий и простоев а карают виновников большими штрафами. Соответственно они готовы платить деньги, лишь бы повысить отказоустойчивость автомобилей.

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

Я не о кан шине говорю а о к-лайн

NickolaDed, а почему Вы не потребуете от тех, кто делает RS232-FMS сделать RS485-FMS ? Это было бы логичнее. Современные терминалы в основном работают с RS-485. Для чего производить FMS-конвертеры, которые ни в компьютер не воткнуть, ни в терминал ?

А лучше сразу k-line -> j1939 (CAN)
Потому как CAN - это действительно автомобильная шина, в отличии от промышленной RS485, и получает всё большее и большее распространение.

А если с таким предложением вышел бы сам ТехноКом, то это было бы совсем не то же самое, как если к ним обращается простой клиент. Что скажете?

Спасибо за поддержку.

Я выше вам дал всю информацию, действительно лучше было бы если бы вы сами с ними связались и обсудили технические вопросы, получиться быстрее и качественнее!

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

http://trk.tk-chel.ru/issue/FWGSM-9
http://trk.tk-chel.ru/issue/FWGSM-12

Понимаете, NickolaDed, к нам как раз никто не прислушается.
Прислушиваются либо к непосредственным потребителям, либо к тем, кто пообещает 2000 штук купить немедленно. Мы (непосредственно ТехноКом) не собираемся закупать у них их коробочки.

bege,
Значит, надо сделать это отключаемым. Вообще, это уже частности. Вы лучше скажите, насколько эта идея интересна.

Какая именно ?

SK,
Сорри, ответ уже есть, я несколько поторопился.

Сейчас, этот прибор можно подключить к автограф, я выше указал, что есть преобразователь RS232 в RS485, проблема в том, как автограф с ним будет взаимодействовать, насколько я понимаю, сейчас он сможет получить только мгновенный расход топлива а остальные данные не получит в том числе ошибки. http://www.ellab.ru/russian/razrabot...l203-1_rus.htm

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

Преобразоывать нужно не в RS-485 и не в 1-wire !!!
Преобразовывать нужно в CAN J1939.

Идею я конечно понял, что мол под j1939 у вас все написано...

Добавлено через 10 секунд
и сделано

Ну так а зачем дублировать одно и то же на все возможные интерфейсы ???

вопрос в том можно ли будет преобразовать нормально из RS232 в j1939, я пока занят поисками этой возможнотью

Внешнего конвертера не найдете - и не пытайтесь.
RS-232 и RS-485 - это по сути один и тот же интерфейс с точки зрения самих данных, а j1939 - принципиально другой.

Я имею ввиду, чтобы с k-line преобразовывать в стандартные посылки статуса j1939, в те, которые в 1939 предназначены для передачи кодов ошибок.

NickolaDed, а где у вас клайн? Лады и волги? В них дешевле маршрутник воткнуть, а трактора вроде все с каном кто напрямую кто через CANLOG

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

Добавлено через 46 секунд
К-Лайн шина как на автотранспорте так и на тракторах и импортных комбайнах.

Добавлено через 16 секунд
Везде где есть ЭБУ

NickolaDed, Вы представляете себе количество протоколов по К-line? Не всё так просто....:crazy:

Просто хотелось бы видеть это решение на базе вашего продукта, а на базе других СМТ это уже работает.

Например ?

геликс 2

Работает и имеется возможность подключения это разные вещи, и как оно работает??

Добавлено через 1 минуту
Простите, но бугага, геликс не производит СМТ! Только контроллеры,

6 последовательно соединенных блоков...

ну контроллер, в качестве ПО используется Wialon

Извините, NickolaDed, но Геликс даже не рассматривается в качестве примера.
Это настолько специфичная штука, что Вы врят-ли бы захотели, чтобы АГ работал точно так же как Геликс.

Я сталкивался с геликсом и знаю с чем его употреблять. Поэтому данную задачу решу на его основе.

Добавлено через 49 секунд
Извините, что потревожил по пустяковому вопросу.

Да, господа, вы все больше и больше перестаете слушать своих пользователей!
Все меньше и меньше до конечного пользователя доходит информация о программном продукте. За последнее три года не было ни одного мануала по ПО. Конечный пользователь тыкает по всем кнопкам, как слепой котенок, авось что-то и настроит.
Вы, конечно же отправите меня с всеми вопросами к дилеру, но опять проблема – у дилера мануала тоже нет. Всем приходится узнавать программу АвтоГРАФ путем проб и ОШИБОК.
Вам очень повезло, что у вас такие дилеры, которые сами ищут решения проблем, возникающих у клиентов не стандартными методами. 90% просьб о помощи на вашем форуме заканчиваются пустыми отписками. За последние пять лет конечному пользователю мало видеть маршрут, остановки, километраж, он желает видеть всю информацию об автомобиле (уровень топлива, tмасла, ошибки двигателя, нагрузки по осям и т.д.). У нас еще есть и спецтехника, у которой запросы гораздо сложнее. А вы оперируете продуктом пятилетней давности и, к сожалению, не разрабатываете ничего нового. Услышьте нас, УСЛЫШЬТЕ! Нам с вами работать…
:sos:

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

Извините, Вы заглядывали в файл WhatsNew.rtf ? Там как раз перечислено, чего мы не разрабатывали за всё это время.

Хотя... А какая у Вас версия ПО ? Там действительно нет уровней топлива, показаний 8 датчиков температуры, отчетов с ошибками CAN, нагрузками ?

Запросы в студию

Прислать вам сборку от 24.07.2008г.? Поглядите сколько всего ТК не делает...
Если бы софт стоял на месте, ТК бы не был там где сейчас он находится по продажам.
Запросов слишком много, и много бестолковых. Есть приоритеты разработок. И всегда что-то допиливается и создается новое.
А если ТК не сказал нет и отмалчивается, то вероятно заявка принята к сведению и поставлена в очередь.

Настройки приборов пятилетней давности... Счастливые были времена...
Меньше настроек - меньше проблем :)

Господа. Мы не отказываемся от доработок, но должны же быть разумные компромиссы. Почему именно МЫ должны адаптировать терминал к заскокам разработчиков различной периферии ? Во-первых, это снижает надежность, во-вторых - безосновательно удорожает систему.
В терминале есть интерфейс CAN J1939 поддерживающий коды ошибок.

Вместо этого все лепят RS-232. А почему ? А потому что дешево и не требует особой квалификации. Хотя ценник на такое периферийное устройство обычно х10 от себестоимости.
Зато из-за этого, имеется ряд проблем:
1. Один RS-232 - одно устройство. Т.е. чтобы еще что-то подключить с RS-232 - надо еще один RS-232 порт в терминале городить, в то время как по CAN и RS-485 - можно подключить кучу устройств на два провода (два контакта в разъеме, один чип-драйвер интерфеса).
2. Надо писать по сути разбор протокола под RS-232 - т.е. продублировать всё, что уже было написано для CAN. А зачем ? Завтра нас попросят все то же самое но в протоколе ModBUS или J1708 или RS-422 или еще можно нагородить кучу интерфейсов...

Может, правильнее будет производителю такой периферии посмотреть - что поддерживается на рынке - и сделать под рынок ? А не заставлять весь рынок перекраиваться под свою хрень ?
Понимаете ?

Почему давление оказывается обязательно на нас, а не на производителя такой периферии ? Ведь сделав стандартный интерфейс - тот же CAN J1939 - он сразу получает целую кучу терминалов разных производителей, АВТОМАТИЧЕСКИ поддерживающих его периферийное устройство. Где логика ?
Если мы будем ставить лишние интерфейсы под каждую кнопку с собственным хитрым выходом, то Вы будете платить за это в каждом купленном АвтоГРАФе, хотя таких периферийных устройств Вы подключите к едва ли 0.01 % от общего числа терминалов. А Вам самим это надо ?

А давайте мы сделаем вместо USB интерфейс FireWire или ThunderBolt и все пользователи должны будут ставить в свои компьютеры расширители под эти интерфейсы. Почему вместо этого мы используем наиболее распространенные интерфейсы ?

k-Line менее распространенная чем CAN шина?

Добавлено через 4 минуты
И про RS 232 и RS485 я выше говорил, есть переходник проблем в этом нет. проблема лишь в том, что бы получить по RS485 текстовое сообщение и передать его на сервер

Физически k-line не представляет никакой сложности в схемной реализации. (http://texinf.ru/content/SKHEMA-K-Line-ADAPTERA для ISO 14230, для k-line ISO 9141 нужна еще одна линия)
Вся сложность в протоколах от конкретных марок машин.
Как Вы думаете, почему мы J1939 читаем по CAN сами, а всякие хитрые проприетарные CAN-протоколы требуют адаптера CAN-LOG ?
Будь у нас протоколы - CAN-LOG был бы не нужен.

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

Ну судя по постановке вопроса, вакуум информации на лицо. Оно как-бы вещи для разных классов техники предназначены. Учите мат. часть!

Я не знаю где вакуум нашли.

Добавлено через 12 минут
Две принципиально разные шины дают одни и те же данные. Только вот одна из них более распространена, так как большое количество отечественных авто производителей еще не используют CAN и датчики ставят аналоговые и поэтому соединяют каждый датчик с ЭБУ отдельным проводом а не CAN шиной. И используют для соединения ЭБУ и диагностического сервисного оборудования K-Line шину. где тут информационный ваккум. просто я сейчас наблюдаю такую ситуацию, каждый считает себя пупом земли и все должны вертеться вокруг них, и делать так, что бы им было удобно. Мне очень хотелось реализовать это на автографе, но увы придеться выбирать между геликсом и телтоникой, все зависит от того, в каком приборе будет возможность реализовать как можно больше данных из K-Line шины.

Вы ошибаетесь. CAN и k-line не одно и то же, но в разных физических интерфейсах. Они не дают одни и те же данные. Просто CAN J1939 содержит и диагностическую информацию В ТОМ ЧИСЛЕ.
Не стоит путать чисто диагностический интерйфейс и шину данных для объединения в единую сеть различных исполнительных устройств и датчиков автомобиля.

То же самое сказал один производитель мышек с I2C-интерфейсом производителям материнских плат.

NickolaDed, поймите правильно: мы делаем достаточно большое количество терминалов. Более 100.000 в год. Так кто должен подстроиться - производитель периферии или мы ? Ну без лишних эмоций - как бы Вы считали, будь Вы производителем ? Только честно.

NickolaDed, вот пример: на рынке объявится производитель ДУТ, который сделает выход своих ДУТ через... LPT-порт (помните, наверное, такой разъем принтера - CENTRONICS).
Ну вот такой он оригинальный. Должны ли мы будем в свои терминалы ввести прием данных от таких ДУТ и встроить LPT-вход ?

Кстати, а вы видели сигналки с подключением к K-line? Только с помощью специальных адаптеров.
А вот с CAN сигналок всё больше и больше...

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

Это же хорошо, что есть выбор.

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

NickolaDed, я к тому - почему Вы именно нас хотите "загнуть" под некий датчик ?
Почему с теми же аргументами не обратиться к производителю считывателя с k-line ? Ведь у них интерфейс, которого нет в большинстве современных терминалов. Это реальный вариант поднять им сбыт. Причем с учетом уже установленных терминалов различных производителей.

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

NickolaDed, не спешите, хватануть головной боли Вы всегда успеете...:grabli:

Постараюсь :dorabotka:

NickolaDed, дык чтоб в серийную прошивку все это ввести, протестировать, выпустить, а потом новые типы записей ввести в диспетчерское ПО, в OLE-выгрузки, а потом в модуль отчетов - время тоже потребуется. Цепочка получается достаточно длинная.

А что бы все это ускорить, свяжитесь с производителями, уточните технические вопросы у них, и к новому году вместе с ними реализуйте интерпретатор с j1939 в полном объеме на автографе

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

Блин. Я же сказал - если они смогут выдавать в J1939 - доработок не потребуется. J1939 - это стандарт в котором описан и формат сообщений и идентификаторы типов сообщений.

А вот это, что?

Это работа программеров Технокома, уже на реальных образцах

Я имел ввиду, если мы начнем подключать их адаптер по RS-232/485 в их текущем терминально-текстовом протоколе.
В J1939 все уже готово - осталось заполнить соответствующие поля в посылках и всё.

я бы не надеялся, что там будет тоже все гладко, камни подводные везде есть

NickolaDed, а какие именно параметры Вы хотели получить из k-line ?

Т.е. ???

Я про то, что однозначно сказать "работает" можно после реальных испытаний...

plex, я имею ввиду, что у нас уже реализовано всё для этого. Мы же берем параметры из CAN-шины.

Ребята из acelab тоже не новички - читать J1939 они умеют, идентификаторы и поля с параметрами - знают, посылки с запросами параметров (on request) они делают, стало быть и выдать в J1939 не запрос а посылку - тоже могут.

SK, я же не спорю, поживем -увидим

Но я бы все таки вас попросил связаться с ACELAB и пообщаться по этому поводу, ради профилактики "нежданчиков"!!!

NickolaDed, а какие именно параметры Вы хотели получить из k-line ?

Обязательно, как-только подобных просьб станет больше чем одна.

Я могу рассчитывать получить ответ на свой вопрос ?

Обороты двигателя
мгновенный расход топлива
уровень топлива в баке
показания одометра
положение педали акселератора (открытие дроссельной заслонки)
температура двигателя
коды ошибок

это все на вскидку, там больше параметров.

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

В общем-то там есть:

http://www.acelab.ru/dep.auto/files..../rs232fms2.pdf

Ага. Действительно. Что-ж - им минус за документацию. Такие вещи должны были быть прописаны в списке параметров.