То о чем я буду писать ниже, интересно наверное только программистам, которые собираются написать что-нибудь для работы с CAN шиной через ELM327 или для очень увлеченных людей, которые уже пробовали работать с ELM через терминал. Если Вы, уважаемый читатель, скорее обычный пользователь, то время на чтение тратить не стоит, поскольку эти знания Вам вряд ли пригодятся.
К сожалению нигде не встречал толковых описаний команд ELM и процесса работы с ним, кроме как в оригинальном первоисточнике
www.elmelectronics.com/wp…oads/2016/07/ELM327DS.pdf
Но и там с первого раза не все понял и перечитывал дважды, от корки до корки. В результате, знания в голове немного уложились и сегодня решил их закрепить здесь. Авось еще кому-нибудь пригодятся.
На совсем простых вещах долго останавливаться на буду и сосредоточусь на описании того, как работать с различными блоками на CAN шине (а не только с ЭБУ впрыска) и как посылать длинный команды и принимать длинные ответы на них. Заодно вкратце опишу как устроены фреймы данных на CAN шине.
Рассмотрим логи процесса замены VIN кода в приборной панели, которые были записаны скриптом pyren.
VIN у нас длиной 17 байт и естественно в один фрейм CAN шины не влезет. Приборная панель в моем примере имеет tx CAN ID: 0x743 и rx CAN ID: 0x763, соответственно фреймы будем отправлять по адресу 743 а получать с заголовком 763
В самом конце статьи я приведу лог целиком, а пока разберу процесс инициализации ELM
>[17:03:57.524]at ws
<[0.025]at ws
ELM327 v1.5
>
Все логи ниже будут примерно в таком формате. Знаком “>” отмечены посылаемые команды и в квадратных скобках, как Вы догадались, указано время отправки с точностью до миллисекунды, а знаком “<” отмечены отклики ELM и в квадратных скобках указано время отклика в секундах. Т.е. здесь ответ на команду ATWS пришел через 25 миллисекунд.
ATWS я использую вместо ATZ потому, что ATWS не сбрасывает настройки скорости COM порта и в начале работы программы ее можно “мягко” повысить командой ATBRD
>[17:03:57.549]at e1
<[0.016]at e1
OK
>
Здесь включаем эхо
>[17:03:57.565]at s0
<[0.016]at s0
OK
>
Здесь для экономии трафика на COM порте отключаем ненужные пробелы
>[17:03:57.581]at h0
<[0.016]at h0
OK
>
Здесь мы отключаем выдачу заголовков фреймов, поскольку там нет для нас ничего интересного
>[17:03:57.597]at l0
<[0.016]at l0
OK
>
Еще немного экономим на “line feed”, мы же работаем не руками через терминал.
Далее команды поинтереснее.
>[17:03:57.613]at al
<[0.016]at al
OK
>
Команда ATAL позволяет передавать на CAN шину не 7 байт, как это сделано по умолчанию, а 8. В CAN фрейм влезает не более 8 байт, причем первый из них несет особое значение и собственно не относится к данным. По умолчанию, этот байт подставляет сам ELM и этот процесс называется “CAN autoformatting”, о котором речь пойдет следом.
Старшие 4 бита этого байта могут иметь значение 0, 1, 2 или 3 (это не касается системных фреймов, где и первый байт фрейма несет в себе данные и соответственно может может иметь любое значение)
“0” означает что это единственный фрейм в последовательности и в младших 4 битах указывается длина команды ( но не более 7)
“1” означает, что это первый фрейм последовательности передающей длинную команду. Все последующие будут начинаться с “2”. Младшие 4 бита этого байта и весь следующий байт несут в себе длину команды. Из этого следует, что одна команда может содержать не более 4095 байт и еще это значит, что в первом фрейме у нас осталось всего 6 байт под данные
“2” ставится в начале каждого последующего фрейма в последовательности и младшие 4 бита здесь содержат циклически бегущий каунтер, по которому можно отслеживать потери (правда не получится отследить 16 последовательных потерь, но это крайне мало вероятно)
“3” означает что этот фрейм у нас FlowControl. В нем нет данных а только служебная информация об управлении потком данных.
Здесь сразу остановлюсь на содержимом фрейма FlowControl. В нем всего 3 значащих байта и посылаются они принимающей стороной.
1 байт — старшие 4 бита содержат “3” (как мы уже знаем) и младшие 4 бита могут принимать следующие значения (0 = Clear To Send, 1 = Wait, 2 = Overflow/abort)
2 байт — BS (block size или burst size) количество фреймов, которое посылающая сторона может послать друг за другом не дожидаясь следующего фрейма FlowControl от принимающей стороны
3 байт — STmin (Separation Time minimum) или минимальное допустимое время между очередными фреймами в миллисекундах. Этот байт может принимать значения от 0x00 до 0xF9, причем, если значение меньше 0xF1 то это миллисекунды, а если значение от 0xF1 до 0xF9, то в последней цифре содержатся сотни миллисекунд. Так. 0xF1 — 100 мс, а 0xF9 — 900 мс. При этом, обратите внимание, что это минимальное значение запрашиваемое принимающей стороной, но вы можете посылать фреймы реже.
>[17:03:57.629]at caf0
<[0.016]at caf0
OK
>
ATCAF0 отключает автоматическое форматирование фреймов для CAN шины. Это значит, что делить нашу длинную команду на фреймы и подставлять первый байт, о котором мы только что говорили, мы отныне будем самостоятельно.
>[17:03:57.645]at cfc0
<[0.016]at cfc0
OK
>
ATCFC0 отключает автоматическую обработку фреймов FlowControl. В большинстве случаев, включать такой режим нет необходимости. Правильный ELM нормально справляется с этой задачей и отправлять длинные команды обычно получается и без этого (если принимающая сторона достаточно быстрая), но вот принять длинный ответ может не получиться из за ограниченной скорости работы COM порта.
Теперь приступим к настройке CAN для работы с приборной панелью.
############################################################
>[17:03:57.662]at sh 743
<[0.015]at sh 743
OK
>
Устанавливаем адрес приборной панели в 0х743 — по этому адресу мы будем отправлять наши команды
>[17:03:57.677]at cra 763
<[0.016]at cra 763
OK
>
Настраиваем RX Filter на CAN ID = 0х763, с этим CAN ID будут приходить ответы на наши запросы от приборной панели, и чтобы не отвлекать ELM на обработку системных фреймов мы явно указали, откуда нужно ждать ответы.
>[17:03:57.693]at fc sh 743
<[0.016]at fc sh 743
OK
>
Здесь мы начали настраивать параметры для автоматического FlowControl. В данном случае это лишнее, поскольку мы ранее отключили автоматический FC, но для порядка настроим. ATFCSH устанавливает CAN ID для отправляемых фреймов FlowControl и он равен тому, что мы ставили в команде ATSH
>[17:03:57.709]at fc sd 30 00 00
<[0.016]at fc sd 30 00 00
OK
>
Здесь устанавливается дефолтное значение отправляемых фреймов FC. BS=0 означает, что мы готовы принять любое количество фреймов. STmin=0 значит, что мы готовы принимать их с любым интервалом, так быстро как только сможет послать наша приборная панель.
>[17:03:57.725]at fc sm 1
<[0.016]at fc sm 1
OK
>
ATFCSM1 означает, что ELM должен руководствоваться параметрами FC, которые мы только что установили.
>[17:03:57.741]at st ff
<[0.016]at st ff
OK
>
Установка внутреннего таймера ELM, в течение которого он ожидает ответ об ЭБУ. Значение этого таймера автоматически регулируется самим ELM для обеспечения оптимального времени отклика. ELM почему-то не заглядывает внутрь фреймов, а именно в их первый байт, иначе он бы “знал” когда все фреймы ответа получены и когда передача закончена. Вместо этого ELM имеет этот таймер и динамически оптимизирует его, правда есть возможность отключить эту автоматическую подстройку и иногда это необходимо.
>[17:03:57.757]at at 0
<[0.016]at at 0
OK
>
Отключаем адаптивный тайминг, т.е. подстройку таймера st, который мы выше выставили в максимальное значение. Нам это необходимо для инициализации протокола, которую мы далее будем делать и просто для сброса его, поскольку мы переключаемся на работу с новым блоком.
>[17:03:57.773]at sp 6
<[0.016]at sp 6
OK
>
Здесь мы переключили ELM в режим работы по шине CAN со скоростью 500 Кбит/сек. (При этом нужно помнить, что реальная пропускная способность в пересчете на полезные данные, будет в районе 280 Кбит/сек)
>[17:03:57.789]at at 1
<[0.016]at at 1
OK
>
Снова включаем адаптивный тайминг — теперь он нам пригодится.
Начинаем работать непосредственно с приборной панелью.
>[17:03:57.805]0210C01
<[0.032]0210C01
0250C08484848484
>
Здесь мы открываем диагностическую сессию к приборной панели, посылая туда команду 10С0, состоящую из двух байт 0х10 и 0хС0. Т.к. мы отключили автоформатирование, нам нужно самим заполнить первый байт и поэтом перед 10С0 мы ставим 02. Как мы писали выше, “0” означает что команда влезет в один фрейм. “2” — просто длина команды в байтах. Внимательный читатель наверное уже обратил внимание на единицу после 10С0. Эта единица не является частью команды и предназначена не для приборной панели, а для ELM. Она означает, что мы ждем всего один фрейм в ответе на нашу команду. ELM получив первый фрейм ответа сразу вернет его и завершит выполнение команды возвратом символа “>” в COM порт. Это позволяет не дожидаться истечения того таймаута о котором мы говорили выше и позволяет экономить несколько миллисекунд на каждом запросе.
Теперь рассмотрим ответ, который вернулся к нам через 32 мс. В первой строке у нас эхо нашей команды, по нему мы проверяем, что данный ответ является ответом именно на наш запрос (иногда это может быть не так). Во второй строке отклик приборной панели “0250C08484848484”. Начинаем читать с первой цифры. Здесь “0” — значит ответ полностью влез в один фрейм. Вторая цифра “2” — значит следом идет два значащих байта ответ 50С0 — это позитивный ответ на нашу команду 10С0. Первый байт позитивного ответа должен быть равен первому байту запроса + 0х40. Наша команда начиналась на 0х10, значит позитивный ответ должен начинаться на 0х10 + 0х40 = 0х50, что мы и имеем. Значит диагностическая сессия открылась. Бывает еще и негативный ответ, который начинается на 0х7F и это значит что команда не была принята или полностью исполнена ЭБУ. Далее мы с таким случаем познакомимся.
Остаток ответа “8484848484” это просто паддинг фрейма до 8 байт.
#[17:04:07.636]KeepAlive
>[17:04:07.636]0210C01
<[0.049]0210C01
0250C08484848484
>
Здесь со знака # начинается лог вставленный программой pyren. В данном случае он означает, что после отправки предидущей команды прошло более 5 секунд и скорее всего диагностическая сессия к ЭБУ закрылась по таймауту — так поступает большинство ЭБУ. В этом случае нужно повторить команду открытия сессии перед отправкой следующих команд.
>[17:04:07.685]0221811
<[0.032]0221811
1015618131313131
>
>[17:04:07.717]3003003
<[0.048]3003003
2131313131313131
223131313131319F
23B5848484848484
>
А здесь длинный ответ на команду 2181. Это команду чтения текущего VIN из приборной панели. Последовательность действий такая:
1) отправляем команду 2181, предварительно обвесив ее “02” спереди и “1” сзади
2) получаем первый фрейм ответа “1015618131313131” Здесь по порядку “1”-означает, что ответ будет состоять из нескольких фреймов, следующие 12 бит “015” — это дина ожидаемого ответа 0х015 = 21 байт (2 байта позитивного ответа + 17 байт VIN кода + 2 байта CRC). В первом фрейме мы получили только 6 полезных байт “618131313131” (как проверить что это начало позитивного ответа мы уже знаем). Осталось получить (21-6)/7 = 3 фрейма.
3) чтобы продолжить получение ответа мы должны отправить фрейм FlowControl “300300”. Напомню, первый байт “30” — собственно означает, что это FC, второй байт “03” — мы говорим посылающей стороне, что готовы принять три оставшихся фрейма, третий байт “00” — означает, что мы готовы принимать оставшиеся фреймы с максимальной скоростью. Последняя “3” как и раньше, предназначена для ELM и сообщает ему, что он должен вернуть нам ответ, как только получит три фрейма.
4) получаем оставшиеся фреймы. Они все начинаются с “2” и вторым символом у нас просто счетчик, который бежит по кругу от 0 до F. Далее в каждом фрейме (кроме последнего) по 7 байт данных. В последнем только один байт данных и 6 байт паддинга до 8 байт.
Таким образом мы получили ответ “618131313131” + “31313131313131” + “3131313131319F” + “B5”. Как видим, VIN код у нас состоял из 17 единиц в ASCII коде и CRC = “9FB5”.
Теперь сформируем и отправим команду на запись нового VIN состоящего из 17 двоек. Команда записи VIN в моей приборной панели “3B81”. За ней должно быть 17 байт в ASCII и 2 байта нового CRC. Итого, нам нужно послать команду “3B8132323232323232323232323232323232327E70”. Сначала поделим ее на фреймы. В первый влезет 6 байт, во второй и третий по 7, а на последний останется 1 байт.
#[17:04:29.256]KeepAlive
>[17:04:29.257]0210C01
<[0.029]0210C01
0250C08484848484
>
Пока мы раскладывали команду на фреймы, прошло более 5 секунд и пришлось снова открывать сессию.
Теперь посылаем первый фрейм (что означает 1015 в начале, мы уже знаем)
>[17:04:29.286]10153B8132323232
<[0.111]10153B8132323232
3001148484848484
>
В ответ получаем от приборной панели фрейм FC, который говорит нам, что следом можно послать только один фрейм и не ранее чем через 0х14 мс. “8484848484” — как всегда паддинг.
>[17:04:29.397]2132323232323232
<[0.111]2132323232323232
3001148484848484
>
Отправили второй фрейм и получили очередное указание как быть далее в виде нового FC
>[17:04:29.509]223232323232327E
<[0.112]223232323232327E
3001148484848484
>
Отправили третий фрейм команды и снова получили FC
>[17:04:29.621]23701
<[0.016]23701
037F3B2384848484
>
И вот отправили последний фрейм команды и в ответ получили “037F3B23”. “03” — значит, что ответ на нашу длинную команду записи VIN состоит из 3 байт “7F3B23”. Ответ начинается с “7F” и это негативный ответ, но расстраиваться пока рано. Давайте расшифруем. Второй байт негативного ответа равен первому байту той команды к которой относится этот негативный ответ. Третий байт “23” это код ошибки и pyren для нас его расшифровал
#[0.380845069885] rsp:7F 3B 23:NR: Routine Not Complete
Негативный ответ здесь означает, что панель приборов команду приняла и начала ее отрабатывать, но пока работу не закончила.
Посмотрим что будет дальше. Попробуем считать наш новый VIN и для этого снова отправляем команду 2181
>[17:04:29.742]0221811
<[0.022]0221811
037F212184848484
>
Но мы снова получили негативный ответ “7F2121”. Теперь уже на команду “21” и код ошибки здесь тоже “21”. Этот код ошибки означает "NR: Busy Repeat Request”. Т.е. приборная панель еще занята выполнением предидущей команды и просит нас повторить команду через какое-то время. pyren ждет 500 мс и повторяет команду
>[17:04:30.608]0221811
<[0.032]0221811
1015618132323232
>
>[17:04:30.640]3003003
<[0.048]3003003
2132323232323232
223232323232327E
2370848484848484
>
На сей раз мы получили позитивный ответ и из него видно, что наш новый VIN в приборной панели состоит из 17 двоек.
Теперь для удобства повторю весь лог слитно без моих скучных коментариев
############################################################
>[17:03:57.524]at ws
<[0.025]at ws
ELM327 v1.5
>
>[17:03:57.549]at e1
<[0.016]at e1
OK
>
>[17:03:57.565]at s0
<[0.016]at s0
OK
>
>[17:03:57.581]at h0
<[0.016]at h0
OK
>
>[17:03:57.597]at l0
<[0.016]at l0
OK
>
>[17:03:57.613]at al
<[0.016]at al
OK
>
>[17:03:57.629]at caf0
<[0.016]at caf0
OK
>
>[17:03:57.645]at cfc0
<[0.016]at cfc0
OK
>
############################################################
>[17:03:57.662]at sh 743
<[0.015]at sh 743
OK
>
>[17:03:57.677]at cra 763
<[0.016]at cra 763
OK
>
>[17:03:57.693]at fc sh 743
<[0.016]at fc sh 743
OK
>
>[17:03:57.709]at fc sd 30 00 00
<[0.016]at fc sd 30 00 00
OK
>
>[17:03:57.725]at fc sm 1
<[0.016]at fc sm 1
OK
>
>[17:03:57.741]at st ff
<[0.016]at st ff
OK
>
>[17:03:57.757]at at 0
<[0.016]at at 0
OK
>
>[17:03:57.773]at sp 6
<[0.016]at sp 6
OK
>
>[17:03:57.789]at at 1
<[0.016]at at 1
OK
>
>[17:03:57.805]0210C01
<[0.032]0210C01
0250C08484848484
>
#[17:04:07.636]KeepAlive
>[17:04:07.636]0210C01
<[0.049]0210C01
0250C08484848484
>
>[17:04:07.685]0221811
<[0.032]0221811
1015618131313131
>
>[17:04:07.717]3003003
<[0.048]3003003
2131313131313131
223131313131319F
23B5848484848484
>
#[17:04:29.256]KeepAlive
>[17:04:29.257]0210C01
<[0.029]0210C01
0250C08484848484
>
>[17:04:29.286]10153B8132323232
<[0.111]10153B8132323232
3001148484848484
>
>[17:04:29.397]2132323232323232
<[0.111]2132323232323232
3001148484848484
>
>[17:04:29.509]223232323232327E
<[0.112]223232323232327E
3001148484848484
>
>[17:04:29.621]23701
<[0.016]23701
037F3B2384848484
>
#[0.380845069885] rsp:7F 3B 23:NR: Routine Not Complete
>[17:04:29.742]0221811
<[0.022]0221811
037F212184848484
>
>[17:04:30.608]0221811
<[0.032]0221811
1015618132323232
>
>[17:04:30.640]3003003
<[0.048]3003003
2132323232323232
223232323232327E
2370848484848484
>
Комментарии 150
А вот так напрямую через CAN:
После получения первого фрейма нужно отправить FC, например 300303
Да, спасибо, разобрался!
Подскажите, хочу вытащить температуру АКПП через CAN, но ответ не умещается в 8 байт и судя по тому как приходит ответ через ELM происходит досыл следующим сообщением. Но я никак не могу прочитать это второе сообщение. Вот как выглядит ответ через ELM:
Здравствуйте. Проблема в следующем:
Купил ELM, подаю на него команды (опрос температур) через ардуино, а ответы приходят как будто не полностью. С другой ELM такой проблемы нет.
А есть лог обмена? Как вы поняли что ответы приходят не полностью? Вы прямо к серийному порту ELM подключились?
К сожалению не сохранил лог. Как сделаю скину. Я подключаюсь к ELM через модуль блутуз НС-05
Добрый день!
Как можно объяснить такое поведение блока:
>0210C01
0250C0FFFFFFFFFF
>105A3B02C7CFFDFF
300100FFFFFFFFFF
>218B2A0000DF2D00
300100FFFFFFFFFF
>2200DF31E400CD32
300100FFFFFFFFFF
>230301D333B401DF
300100FFFFFFFFFF
>2437750237399102
300100FFFFFFFFFF
>2543D1980C000000
300100FFFFFFFFFF
>26000004004C4CC9
300100FFFFFFFFFF
>27BA00001E000000
300100FFFFFFFFFF
>280000E20002FCFF
300100FFFFFFFFFF
>2900FFFF07B30080
300100FFFFFFFFFF
>2A00330080000000
300100FFFFFFFFFF
>2B40010005800780
300100FFFFFFFFFF
>2C0C0014001E0032
037F3B12FFFFFFFF
037F3B12 это значит NR: SubFunction Not Supported
Команда 3B02 не поддерживается блоком или длина не правильная
Похоже длина не верная, т.к. поддержку команды по 3b00 вижу. При этом записываю то же самое что считывается по 2102.
Спасибо!
Shr-lnm
037F3B12 это значит NR: SubFunction Not Supported
Команда 3B02 не поддерживается блоком или длина не правильная
Может быть требуется контрольная сумма, возможно такое?
КОнтрольную сумму встречал только у VIN. А что это за блок? На него есть какое-нибудь описание?
С описаниями плохо, это блок адаптивного света в Ниссан
подскажите, такой же elm, но не могу сменить пароль блютуз на 0000, который по умолчанию 1234. Модуль блютуз не хочет общаться через команты АТ, общается только весь блок, но команды подобной AT+PIN не нашел
На сколько я знаю, у BT модуля должен быть отдельный COM порт к которому нужно подпаиваться, и уже на том порту будут доступны AT команды модуля BT.
Позволите задать несколько вопросов?)
1) В статье описан случай передачи длинного сообщения, когда сервер готов принимать по одному Consecutive Frame, передавая после каждого очередной Flow Control, т.е. ELM фактически получает ответ на каждый свой запрос.
Как Вы обрабатываете передачу, когда сервер готов принимать несколько Consecutive Frame, т.е. ELM не получает ответа на передачу? Выставляете перед первым промежуточным фреймом ATR0 и перед передачей последнего фрейма ATR1?
2) Как происходит обработка передачи, когда ответ приходит позже, чем через максимальное время, которое можно выставить через AT ST (FF это чуть больше секунды)? Обычно P2*CAN у автомобильных блоков составляет 5 секунд, т.е. ELM уже давно прислал NO DATA и уже ничего не ждет.
3) У ELM327 есть баг, который не позволяет указать количество ожидаемых ответов, если отправляемый фрейм имеет длину 8 байт. Как вы обрабатываете эту ситуацию?
Заранее спасибо!
civil-zz спасибо за интересные вопросы. Видно, что Вы серьезно занялись проблемой )
На первый вопрос, да — так и есть, использую ATR0 для временного отключения ожидания ответа. gitlab.com/py_ren/pyren/-…/pyren3/pyren3/mod_elm.py Строчки 1675 и 1743
По проблеме номер 2, я сталкивался с NR:78 Request Correctly Received-Response Pending это когда в ответ на запрос блок присылает NR:78 а реальный ответ прилетает спустя какое-то время, когда ELM его уже не ждет. Эта задача довольно эффективно решается временным переход в режим мониторинга ATMA (строчка 1728) Если Вам попался блок который не шлет NR:78 а просто долго отвечает, тогда в режим мониторинга наверное можно переходить привентивно.
По третьей проблеме у меня эффективного решения нет. Для команд короче 8 байт я храню длину ответа ( в коде это называется l1_cache) и при повторной отправке команды явно указываю сколько фреймов буду ждать, а вот с 8 байтами остается только полагаться на таймеры. Тут я сталкивался с другой связанной проблемой. Есть блоки которые измеряют таймаут сессии не от момента отправки последнего фрейма, а от момента отправки первого фрейма в длинной команде. В таком случае, если нам например нужно отправить 4000 байт, нам нужно успеть напихать в шину все 572 фрейма за 5 секунд и здесь проблема заключается в том, что elm не возвращает FC фрейм сразу по факту его получения, и ждет истечения таймера ATST, а указать ELM что мы ждем именно один фрейм FC нельзя, из-за этого самого бага. Тут приходится перед началом отправки длинной команды подбирать длительность таймера ATST так чтобы успеть отправить все фреймы длинной команды за время таймаута сессии, причем нужно еще учитывать round trip между компом и ELM. Тут можно конечно поэкспериментировать все с тем же ATR0 но тогда мы просто будем методично отправлять фреймы на шину не понимая, что там происходит сейчас и уповать на то, что нам повезет и после отправки последнего фрейма мы увидим PR.
Спасибо большое! Для меня основной проблемой является именно 2 (с отложенным ответом), спасибо за подсказку с монитором. Я на самом деле пробовал его тоже использовать, стабильно это не работало, возможно, ввиду неоптимального кода, буду пробовать еще.
Добрый день!
Пытаюсь разобраться с записью id датчиков tmps. Например они имеют такой вид: 09079a3f 0cb8935e 09079a19 09079f97
Попробовал составить команду, получилось так:
0210031
10132E151009079A
213F0CB8935E0907
229A1909079F97AA
Возможно можете подсказать, что делаю неправильно, принимается только первый фрейм?
А как ELM инициализируете?
at caf0 ?
at al ?
Полность проведу, на всякий случай:
at ws
at e1
at s0
at h0
at l0
at al
at caf0
at cfc0
AT SH 758
AT CRA 778
AT FC SH 758
at fc sd 30 00 00
at fc sm 1
at st ff
at at 0
at sp 6
at at 1
Дайте тогда и лог отправки фреймов посмотреть. ELM точно нормальный?
Write (18:35:46,895): 0210031
Read (18:35:46,912): 0210031
065003003201F4FF
>
Write (18:35:46,979): 10132E151009079A
Read (18:35:48,028): 10132E151009079A
300100FFFFFFFFFF
>
Write (18:35:48,092): 213F0CB8935E0907
Read (18:35:49,151): 213F0CB8935E0907
NO DATA
>
Write (18:35:49,225): 229A1909079F97AA
Read (18:35:50,275): 229A1909079F97AA
NO DATA
Elm относительно нормальный.
ELM хороший. Думаю, что проблема в таймауте. Ответ на первый фрейм ждем слишком долго — 1 секунду. Попробуйте поставить atst05 — должно хватить.
Спасибо! Частично сработало, команды ушли, датчики не прописались
Write (17:12:04,102): 10132E151009079A
Read (17:12:04,130): 10132E151009079A
300100FFFFFFFFFF
>
Write (17:12:04,155): 213F0CB8935E0907
Read (17:12:04,200): 213F0CB8935E0907
300100FFFFFFFFFF
>
Write (17:12:04,277): 229A1909079F97AA
Read (17:12:04,307): 229A1909079F97AA
037F2E13FFFFFFFF
"NR 13 : Incorrect Message Length Or Invalid Format"
AlexsandK
Спасибо! Частично сработало, команды ушли, датчики не прописались
Write (17:12:04,102): 10132E151009079A
Read (17:12:04,130): 10132E151009079A
300100FFFFFFFFFF
>
Write (17:12:04,155): 213F0CB8935E0907
Read (17:12:04,200): 213F0CB8935E0907
300100FFFFFFFFFF
>
Write (17:12:04,277): 229A1909079F97AA
Read (17:12:04,307): 229A1909079F97AA
037F2E13FFFFFFFF
А что выдают команды?
221510
22F1A0
22F18A
22F194
22F195
Read (08:54:37,721): 221510
013
0:621510000000
1:00000000000000
2:000000000000FF
Read (08:54:37,817): 22F1A0
62F1A011
Read (08:54:37,933): 22F18A
019
0:62F18A434F4E
1:54494E454E5441
2:4C204155544F4D
3:4F54495645FFFF
Read (08:54:38,056): 22F194
62F19431333130
Read (08:54:38,179): 22F195
62F19532343432
Точного соответствия этому модулю в базе не нашел но нашел вот с такой командой
<request Name="WriteData.$1510_TPMS_ID_REGISTRATION_2">
<sent>
<sentbytes>2E151000000000000000000000000000000000</SentBytes>
<dataitem Name="Config.Data_$1510_#004_TPMS_ID_REGISTRATION_2_ID1_Current_FL" FirstByte="4"/>
<dataitem Name="Config.Data_$1510_#008_TPMS_ID_REGISTRATION_2_ID2_Current_FR" FirstByte="8"/>
<dataitem Name="Config.Data_$1510_#012_TPMS_ID_REGISTRATION_2_ID3_Current_RR" FirstByte="12"/>
<dataitem Name="Config.Data_$1510_#016_TPMS_ID_REGISTRATION_2_ID4_Current_RL" FirstByte="16"/>
</Sent>
<received MinBytes="3">
<replybytes>6E1510</ReplyBytes>
</Received>
</Request>
Попробуйте убрать последний байт AA в 3 фрейме 229A1909079F97AA
Не сработало, nr 13.
Странно. А если попробовать изменить порядок байт у каждого датчика? Длина команды с большой вероятностью правильная 0х13. Значит дело в формате или в этот блок параметры датчиков пишутся как то иначе. Там нет режима автоматического изучения? Я у себя просто с бортовой ММ запускаю режим обучения, каждый раз когда меняю колеса. У блока N_B02E_TPMS_UDS_PT_20161007 есть процедуры типа RoutineStart$0111_ID Registration или RoutineStart$0113_ID TPMS_Customize_data_reset Правда тут нужно быть уверенным что этот блок именно такой. И как вы этим xml файлом пользуетесь? Каким софтом к блоку подключаетесь?
Процедуры запуска обучения из этого хмл не работают, работают сбросы. Есть еще одна команда, побольше для записи ай ди датчиков, но ее пока не пробовал. Изменение режима автообучения пробовал, команды принимаются, что дают не ясно, лично у меня даже датчиков нет :).
AlexsandK
Read (08:54:37,721): 221510
013
0:621510000000
1:00000000000000
2:000000000000FF
Read (08:54:37,817): 22F1A0
62F1A011
Read (08:54:37,933): 22F18A
019
0:62F18A434F4E
1:54494E454E5441
2:4C204155544F4D
3:4F54495645FFFF
Read (08:54:38,056): 22F194
62F19431333130
Read (08:54:38,179): 22F195
62F19532343432
А где вы нашли эту команду 2E1510 ?
Из базы ddt2000 xml файл N_B02E_TPMS_UDS_PT_20161007 . Собираю базу к х трейлу, пробую разные варианты.
Я нашел там же )
Но у вашего блока другой autoident
<autoident DiagVersion="17" Supplier="CONTINENTAL AUTOMOTIVE" Soft="1310" Version="2442"/>
Не обращаю внимания на идентификаторы. Точнее ничего о них не знаю.
Добрый день. Вы пишите про команды и ответы. Например про открытие сессии и подтверждение открытия, про длину команды, про задержку команд. Вы эти данные узнали опытным путем или есть какая-то литература? Спасибо.
День добрый. Основной источник информации здесь это стандарты. Например UDS ISO 14229-1
Спасибо!
mrs252s Имеете ввиду FlowControl? Можно сделать 900 мс
3 байт — STmin (Separation Time minimum) или минимальное допустимое время между очередными фреймами в миллисекундах. Этот байт может принимать значения от 0x00 до 0xF9, причем, если значение меньше 0xF1 то это миллисекунды, а если значение от 0xF1 до 0xF9, то в последней цифре содержатся сотни миллисекунд. Так. 0xF1 — 100 мс, а 0xF9 — 900 мс. При этом, обратите внимание, что это минимальное значение запрашиваемое принимающей стороной, но вы можете посылать фреймы реже.
Можно ли на саn шине сделать задержку в 1 секунду для команды?
Снимаю шляпу! Молодец.
подскажите какие коды для терминала чтобы выудить информацию о пробеге авто и не только, где то встречал статю про это, то вопрос для всех марок авто они универсальны или могут отличатся.
Приветствую.
Есть задача помониторить вторую КАН-шину.
Отследить "диалог" магнитолы с блоком климат контроля.
Можно это сделать при помощи ELM327 или надо через ардуину городить?
Приветствую. А можете помочь составить скрипт для просто отправки одного сообщения? И для прослушивания одного айди без отправки?
добрый день
собираю кастомную приборную панель на arduino
на оригинальную приборку данные о значении оборотов двигателя и скорости приходят по кан шине
можно ли посредством ELM считать данные, приходящие по шине на приборку, и перевести их в читабельный вид, для дальнейшего запрограммирования?
Подскажи пожалуйста где посмотреть все возможные коды ошибок при отрицательном ответе 7F на команду? Гдето сохранял себе, но сейчас не могу найти. И ссылка на первоисточник сейчас не открывается, если есть другая, дай пожалуйста
gitlab.com/py_ren/pyren/-…b/master/pyren/mod_elm.py
Начиная с 76 строки
Благодарю
Добрый день! Тема очень интересная. При помощи ELM327 пытаюсь эмулировать работу cd ченджера, подскажите что делаю не так:
ATWS; ATL0; ATAL; ATE0; ATS1; ATH0; ATSP2; ATSH8D93010180;
На последней команде пишет no data. Последняя команда, это фрейм по мануалу, отвед CD ченджера на запрос от радио. Использую приложение на телефоне Serial Bluetooth Terminal
День добрый. Последняя команда это установка заголовка и он кажется получается слишком длинным и не влезает в формат. На какой шине работает ченджер? Какой у него адрес и на какой адрес он должен послать данный?
J1850 vpw, радио в шину отправляет 8d 0f 00, где состояние радио: 00 — радио выключено, 21 — режим fm включен, 24 — режим cd ченджера включён. Cd ченджера должен ответить 8d 93 01 01 80, где состояние cd ченджера: 01 — выбран диск, 01 — выбран трек, 80 — время радио. Ссылка с описанием www.mictronics.de/project…c-protocols/#ChryslerJeep
Я указал то что нужно?
Как можно увеличить возможность передачи заголовка
С этой шиной я никогда не работал. По хорошему нужно почитать стандарт, но могу предположить что проблема в в неправильном использовании команды установки заголовка. По ссылке сказано, что у этого прибора заголовок состоит из одного байта но такой команды у elm нет. Заголовок там минимум три байта, но установка заголовка не отсылает на шину ничего. Предлагаю попробовать так. Если нужно послать 8d 93 01 01 80 то первые три байта задаем как заголовок и оставшиеся отправляем на шину. Первые три должны к ним пристегнуться при отправке
AT SH 8D 93 01
01 80
Как быть с более короткими, пока не знаю
Спасибо
Статья огонь, все правильно и понятно написано!
Вот бы такую иметь в 2012, тогда пришлось все это раскуривать самостоятельно, просиживая ночи в машине)))
Я тоже в машине не один час провел мучая CAN шину и блоки всевозможными экспериментами. ))
Спасибо за подробное описание!
Я разбираюсь с ELM327. Мне нужно отправлять CAN запрос и получать ответ. Отправить запрос нет проблем — работает. А вот ответ приходит с другого адреса, вот пример:
ATZ // Reset
AT SP 6 // 6 — ISO 15765-4 CAN (11 bit ID, 500 kbaud)
AT AL // Разрешить сообщения больше 7 байт
AT SH 714 // Обращаемся к 714 адресу
03 22 22 0D 55 55 55 55 // Запрос открыты/закрыты двери
Ответ с адреса 77E
77E 05 62 22 0D 55 65 AA AA — все закрыты
77E 05 62 22 0D 00 65 AA AA — все открыты
Есть ли способ решить это?
AT MA // Мониторить шину
Команда мониторинга шины похоже не успевает запуститься, если ее выполнить сразу после запроса.
Тут вроде все стандартно. ЭБУ всегда данные читают с одного id и отвечают с другим.
Вам нужно вот так настраивать ELM
at sh 714
at cra 77E
at fc sh 714
at fc sd 30 00 00
at fc sm 1
at al
at sp 6
Спасибо, почитал про Flow Control. Сегодня буду пробовать
Shr-lnm
Тут вроде все стандартно. ЭБУ всегда данные читают с одного id и отвечают с другим.
Вам нужно вот так настраивать ELM
at sh 714
at cra 77E
at fc sh 714
at fc sd 30 00 00
at fc sm 1
at al
at sp 6
>atz
ELM327 v1.5
>at sh 714
OK
>at cra 77e
OK
>at fc sh 714
OK
>at fc sd 30 00 00
OK
>at fc sm 1
OK
>at al
OK
>at sp 6
OK
>03 22 22 0d 55 55 55 55
NO DATA
Как думаете в чем проблема?
Здесь нужно либо ATCAF0 либо 22220d
Спасибо! Работает
ELM327 v1.5
>at sh 714
OK
>at cra 77e
OK
>at fc sh 714
OK
>at fc sd 30 00 00
OK
>at fc sm 1
OK
>at al
OK
>at sp 6
OK
>at ca f0
OK
>03 22 22 0d 55 55 55 55
05 62 22 0D 55 65 AA AA
Shr-lnm
Здесь нужно либо ATCAF0 либо 22220d
Единственное не разобрался, что вот здесь происходит at fc sd 30 00 00 ?
Здесь мы указываем, что elm в качастве фрейма fc всегда будет сообщать ЭБУ, что тот может посылать любое количество оставшихся фреймов ответа, с любым временным интервалом между ними.
Когда команда или ответ должны состоять больше чем из одного фрейма, отправляющая сторона всегда посылает только один, первый фрейм. Принимающая сторона должна послать фрейм fc, в котором сообщает как слать оставшиеся фреймы. По сколько за раз, и с каким интервалом.
Спасибо за разъяснение! Очень сильно помогли.
Здравствуйте!
наблюдал странную картину:
попробовал сделать скрипт что бы собрать все запросы по аналогии с дампом mod_ddt (взял из дампа команды и занес их списком)
то есть после открытия сессии отправил:
print elm.cmd("10C0")
print elm.cmd("2177") # Dump
print elm.cmd("21FD")
при этом в ответе вернулся результат на 2177 а дальше почему-то FC переключился и последующие команды перестали выполняться:
>[15:23:01.433]0210C0
<[0.238]0210C0
0250C00000000000
>
>[15:23:01.673]022177
<[0.24]022177
1016617720111011
>
>[15:23:01.914]AT CFC0
<[0.063]AT CFC0
OK
>
>[15:23:01.978]0221771
<[0.262]0221771
NO DATA
то есть ответы по 2177 должны были быть больше чем один ответ?
в дампе от mod_ddt такой ответ:
2177:61 77 10 1D 20 00 10 1D 20 1E 10 1E 20 1F 10 1F 20 00 10 1F 20 1F 00 00 00 00 00
21FD:61 FD 00 00 00 00 00 46 30 30 30 30 30 30 30 30 30 00 10 03 24 12 00 5C 92 56 00
То есть мне для длинных команд надо ждать несколько ответов?
отдать 022177, а затем 0221771, 0221772?
Здравствуйте.
Без предыдущих команд боюсь ошибиться, но думаю, что там обшибка в определении CANid. Хвосты у atsh xx и atfcsh xx должны совпадать.
Видимо изначально cfc0 отключен и думаю, если его включить, то и без проверки atfcsh может все заработать.
Самое странное, что у меня команда отработала с первого раза полностью без ошибок. Возможно отключалось зажигание на удаленной машине.
Идея была в том, что бы собрать дамп блока по аналогии с mod_ddt. Я прогнал все команды (хотя по-честному для включения подсветки в двери нужна была одна), что бы подготовить нужные параметры в команде-включения, т.к. это команда с большим числом параметров.
Может быть от адаптера это зависит? Мой поддерживает FC, может удаленный адаптер не поддерживал это нормально, хотя пирен работает у человека?
скрипт и свои логи выложил тут
drive.google.com/open?id=…ogm8_L01O2HvNHJabPCo6txMK
cmdr_10707_DDCM_Dump.py
Но делал просто по командам из дампа ддт.
Есть ли в пирен возможность "выдрать" все команды для дампа при функции mod_ddt? что бы на телефоне получать дамп не только от базы клип, но и от базы ддт?
Скрипт правильный, но я бы туда добавил принудительное включение cfc0. Там просто нужно добавить
mod_globals.opt_cfc0 = True
Возможно, действительно удаленный ELM не поддерживал FC
В пирене, к сожалению, нет такой функции чтобы из базы ddt извлекать команды для дампа. Можно попробовать автоматически генерить макро для терминала и добавить запуск макро в Android лаунчер
спасибо!
И мой опель-виваро двигатель 10774, АВС 10833, панель приборов 10911, ЦЭКБС 10663, подушки без 10832 — во всех блоках CRC2020
Ещё один трафик
Другой авто Трафик VF1FLBHB67Y208050
двигатель 10672 Вин код не прописан 2181:61 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
АВС 10450 — винкод не требуется
ЦЭКБС 10491 2181:61 81 56 46 31 46 4C 42 48 42 36 37 59 32 30 38 30 35 30 5B 95
пОД.бЕЗ 10449 2181:61 81 56 46 31 46 4C 42 48 42 36 37 59 32 30 38 30 35 30 5B 95
У меня непонятки с записью винкода, а так же определения
CRC.
1. В программе ddt4all есть дополнение-калькулятор для
определения CRC винкода. Если прописать семнадцать
единичек, то CRC определяется такой же, как и у вас. Так
же, если записать двойки. Но если написать мой винкод
W0LF7AMA, то определяется CRC 0395. А в
блоках двигателя с этим же винкодом-CRC 2020 (вот
строка с дампа двигателя 2181:61 81 57 30 4C 46 37 41 4D
41 36------------------ 20 20 ).
2. Так же непонятки с прописью винкода в PyRene. Если в
демо режиме я запишу свой винкод, то PyRen дает ошибку,
а стоит изменить в винкоде хотя бы один знак (хотя бы
заменить последнюю 5 на 6)- PyRen отрабатывает как
положено. Я уже пробывал переставить программу,
заходить в демо режиме с чужим saved файлом и чистыми
папками кеш-дампов, но pyren всё-равно отку -дато
подхватывал мой винкод (грешу, что я заполненную папку -копию
Scripts оставил на рабочем столе, может программа его
от-туда подтянула) Вот ошибка (точнее -не показывает отправляемую команду)
Некоторые блоки иногда вообще не считают CRC. Возможно 2020 это просто мусор из памяти, на самом деле это два пробела. Возможно у Вас именно такой блок. Либо в вашем блоке другой алгоритм расчета CRC, но скорее всего первый вариант.
В пирен нужно бы добавить возможность писать просто vin и vin+crc. Блоков где vin пишется без crc достаточно много
Почему pyren на работает с вашим VIN разобрался — там ошибка в алгоритме была. При случае поправлю.
Спасибо
Shr-lnm
Некоторые блоки иногда вообще не считают CRC. Возможно 2020 это просто мусор из памяти, на самом деле это два пробела. Возможно у Вас именно такой блок. Либо в вашем блоке другой алгоритм расчета CRC, но скорее всего первый вариант.
В пирен нужно бы добавить возможность писать просто vin и vin+crc. Блоков где vin пишется без crc достаточно много
Почему pyren на работает с вашим VIN разобрался — там ошибка в алгоритме была. При случае поправлю.
Посмотрел я два дампа от трафиков 2008года- VIN код, CRC- прописано всё, в соответствии с калькулятором. Получается, что CRC пишется по особому либо с 2010 года, либо на моделях других марок (у меня опель-виваро), либо у меня часный случай. В общем- стоит подождать появления дампа аналогичного моему авто, и смотреть как там.
А так во всех блоках?
Нет, в подушках без. CRC 2020
Трафик VF1FLBHB68Y294542 двигатель 10672 2181:61 81 56 46 31 46 4C 42 48 42 36 38 59 32 39 34 35 34 32 CE E1 00 00 00 00 00 00
АБС 10450 — винкод прописки не требуется
ЦЭКБС 10500 2181:61 81 56 46 31 46 4C 42 48 42 36 38 59 32 39 34 35 34 32 CE E1
П.Без. 10449 — здесь прописан чужой винкод VF1FLBHB69V334442 2181:61 81 56 46 31 46 4C 42 48 42 36 39 56 33 33 34 34 34 32 20 20
Скажите, вот Вы, для примера, вводили вин-код 17 двоек, при этом CRC у Вас 7E70. Как вы опредилили CRC ( я сумировал 17 двоек в HEX единицах, и у меня получилось 7E. А откуда появилось еще 70? Или для опредиления CRC Вы пользуетесь какой-то программой? Если не секрет- какой?
Собственно, мне это только ради любопытства, и если есть с этим трудности -то лучше не надо, CRC для своего винкода я посмотрел в mod-DDT, просто пытаюсь понять как все работает (не думал, что под старость захочется рыться в програмировании))))
Какие наши годы?.. ))
Здесь для рассчёта CRC используется специальный алгоритм. Его можно посмотреть в коде pyren. Функция hex_VIN_plus_CRC в фале mod_utils.py
Спасибо, просто сейчас приходится по пять раз перечитывать, что бы вникнуть… Раньше как-то всё сходу. )))
Shr-lnm, Здравствуйте!
Подскажите, пожалуйста, в чем проблема? Torque Pro, ELM 327 v1.5, Настройки профиля в Торке взяты из Пирена (протокол подключения и строка инициализации.)
(Сам пирен с машиной через этот элм связывается.)
Торк через ЕЛМ начинает подключаться: идет проверка протокола… иницилизация ЭБУ…, а после встаёт колом на проверке модели автомобиля…
Megane II 4KJ 2003 VF1BM0H0H29951796
Здравствуйте. Не могли бы Вы мне подсказать ? Имея на руках ELM327 USB как я могу "послушать CAN шину" Например: Закрывая/открывая двери, моя сигнализация по CAN отправляет соот-но команды, вот мне нужно посмотреть код этих команд. Как это сделать, подскажите пожалуйста.
Для этого у ELM есть команда ATMA, но там будут лететь сотни фреймов в секунду нескольких десятков типов. Лучше воспользоваться не терминалом а какой-нибудь готовой программой, которая позволит отфильтровывать явно не интересные, периодически посылаемые фреймы.
Для себя я писал вот такую простенькую про грамму
github.com/shrlnm/CanBusMonitor
Можете взять ее за основу.
ELM327 мощная штука и народ ее пользует, как из пушки по мухам. Можно настроить ELM на роботу как тупой преобразователь rs-232<->can ?
Согласен. При наличии определенных знаний, его и как вполне надежный флешер можно использовать.
Не подскажете, какими командами отключить фильтрацию (защиту) команд ОБД2?
Какую фильтрацию вы имеете в виду? Можете пример привести?
Например надо отправить команду pid 0x2100, которая не предусмотрена ru.wikipedia.org/wiki/OBD-II_PIDs
Сканер такую команду не пропустит видимо, т.е. стоит защмта от дурака…
У elm327 нет такой защиты. Он не фильтрует команды. Как это выглядит в терминале?
Недавно заметил странность- при попытке прописать винкод в панель приборов (опель виваро) mod-ddt отправляет одну конечную команду, а PyRen- немного другую. Здесь нет ошибки?
pyren умеет считать и подставлять контрольную сумму. Она правда, часто не нужна, поэтому, наверное, в mod_ddt срабатывает и без нее.
Кажется нашел способ как решить проблему.На официальном сайте на форуме нашел pdf файл" powersave".Там с помощью команд ST можно переключить питание для программ написанных под ELM327, но для меня это пока темный лес.Не могли бы вы посмотреть эту инструкцию и прислать мне команды которые надо отослать в адаптер. Выкладываю ссылку на файл: один оригинал, а второй переведен гуглом. yadi.sk/d/7FXm3Wp93P5e4L.
Давайте для начала текущие настройки посмотрим
STSLCS
А там посмотрим что дальше делать
Я так понимаю, что надо отправить эту команду в адаптер и посмотреть, что он ответит?
Shr-lnm
Давайте для начала текущие настройки посмотрим
STSLCS
А там посмотрим что дальше делать
Ответ адаптер HG WAKE: OFF, 0.20v in 1000ms0 s
Верно, только это последняя строка вывода. Чтобы увидеть все, сначала введите
ATE1
ATL1
Судя по этой картинке, адаптер засыпать не должен. Но поменять режим засыпания на ELM можно изменив регистры
сначала выведите и сохраните текущее состояние
AT PPS
затем можно включить/выключить этот режим командами
AT PP 0E SV 1A
AT PP 0E ON
обратно
AT PP 0E SV 9A
AT PP 0E ON
сброс всех изменений в регистрах : AT PP FF OFF
Попробовал переключить режим все осталось как и было. Мне кажется, что приложения для диагностики держат постоянную связь из-за того, что постоянно запрашивают данные с датчиков, а датчики постоянно посылают ответы.Пирен работает как терминал, а терминалы отваливаются каждые 10 секунд.Приеду домой попробую подключить пирен через скрипт busmon ведь через него постоянно идет информация от датчиков.
Shr-lnm
Судя по этой картинке, адаптер засыпать не должен. Но поменять режим засыпания на ELM можно изменив регистры
сначала выведите и сохраните текущее состояние
AT PPS
затем можно включить/выключить этот режим командами
AT PP 0E SV 1A
AT PP 0E ON
обратно
AT PP 0E SV 9A
AT PP 0E ON
сброс всех изменений в регистрах : AT PP FF OFF
Подключился скрипом busmon связь держится постоянно. Может попробовать дикампилировать приложение torque и посмотреть какие команды оно посылает для постоянной связи?
Попробуйте в скрипте заменить mod_elm.py вот на этот
cloud.mail.ru/public/345Q/q4R8jKhb8
Подключился с помощью этого мода связь держится постоянно до тех пор пока не перейду в какой нибудь пункт, тоесть зашел в блок отсканировал ошибки в нем и адаптер снова отваливается. Но уже если не чего не делаешь связь постоянная.
подправил
cloud.mail.ru/public/7EFX/8vVUvwz7E
Этот мод также работает если загружаются блоки через savedecus то связь постоянная, светодиод host моргает каждую секунду. Если запускаю скрипт через scan, то сканируются блоки потом светодиод host один раз моргает и связь отваливается.
Попробую завтра в машине проверить — пока не могу сообразить в чем причина такого поведения.
Большое спасибо. Кажется получилось. Я переустановить пирен и адаптер стал держать связь. Рядом с модом создавался такой же файл с расширением "рус" наверное из за него этот мод не работал. У меня еще вопрос, а этот мод подойдет к ddt4all.
Боюсь, что прямо в таком виде это модуль не подойдет для ddt4all. Модуль elm.py в ddt4all это форк одной из ранних версий mod_elm.py и Седрик уже много чего там оптимизировала под нужды своей программы, но насколько я вижу, полезные фичи из новых версий mod_elm.py он периодически переносит в elm.py
А вы бы не могли мне сказать, что вы добавили в мод и номера строчек в нем. А то я сам пытаюсь изменить elm.py в ddt4all, но у меня не получается. Внес изменение Седрика в elm.py, ecu.py, но адаптер все ровно отваливается. Мне конечно удобней через пирен подключаться, но через пирен окно баз ДДТ постоянно зависает windows постоянно пишет, что приложение не отвечает.
Там много строчек я подправил — проще посмотреть какими-нибудь утилитами типа diff
А у меня mod_ddt не виснет, если не сложно, пришлите скриншоты на каких xml и при каких обстоятельствах он зависает — может его проще подправить
Если к машине не подключаться mod_ddt работает с дампом без проблем, а когда подключен к машине, то окно программы открывается и при попытке войти в какой нибудь пункт зависает. Выхожу из программы, только сняв задачу в диспетчера задач. Скрин смогу сделать только в выходные. Может надо подправить mod_ecu. Седрик у себя в программе для Wi-Fi его правил.
C такими симптомами скриншот тогда не поможет ( — тут видимо проблема во взаимодействии с ELM или ЭБУ.
mod_ecu.py и ecu.py из ddt4all это совсем разные модули — Седрик писал свой вариант с нуля.
Тогда попробую скинуть адаптер на заводские настройки и попробую внести ваши изменения в elm_py
Если не сложно, запишите лог во время зависания mod_ddt и посмотрите на загрузку памяти и процессора. Возможно в логи попадет несколько команд. Хотелось бы понять из-за чего происходит зависание. Из-за обмена с ELM или из-за ошибки в софте. Ко мне недавно обращался один человек с похожей проблемой на талисмане. Там один из блоков вел себя не совсем обычно и мне не удалось придумать как заставить ELM адекватно работать с этим блоком. Возможно у Вас похожий случай.
Хорошо в выходные запишу логи, так как до машины доберусь только в выходные. Может из-за того, что адаптер не поддерживает команды ATCEA и ATCEA04 программа так себя ведет?
А какая машина? У Вас вряд ли используется расширенная адресация. В любом случае, ни pyren, ни mod_ddt, ни ddt4all расширенную адресацию не поддерживают и эти команды не используют
Машина рено сандеро степвей 2016г. Я вообще думал вам дать адаптер, вам ведь с ним будет проще поправить моды. Я весь декабрь буду в Москве.
Shr-lnm
А какая машина? У Вас вряд ли используется расширенная адресация. В любом случае, ни pyren, ни mod_ddt, ни ddt4all расширенную адресацию не поддерживают и эти команды не используют
Вот ссылка на логи yadi.sk/d/Ee3z7yGr3PeA2f Память процессора загружена на 30%, а сам процессор на 5%
В логах огромное время отклика
>[10:27:17.296]0322010B1
<[0.407]0322010B1
0462010B00000000
Экраны с большим количеством параметров будут обновляться по 6 -10 секунд
Многое зависит и от ЭБУ, но у меня по USB многие блоки читаются в 50 — 80 раз быстрее.
По идее и DDT4ALL должен работать так же медленно. Если он работает быстрее, то можно попробовать включить опцию --n1c
Sema371
Кажется нашел способ как решить проблему.На официальном сайте на форуме нашел pdf файл" powersave".Там с помощью команд ST можно переключить питание для программ написанных под ELM327, но для меня это пока темный лес.Не могли бы вы посмотреть эту инструкцию и прислать мне команды которые надо отослать в адаптер. Выкладываю ссылку на файл: один оригинал, а второй переведен гуглом. yadi.sk/d/7FXm3Wp93P5e4L.
Нету там файла уже
Попробовал я подключится с помощью putty, задал три секунды, адаптер все ровно отключается секунд через 10, но к ноутбуку подключен.Torque и FORScan подключаются к адаптеру и держат стабильное подключение.
Еще я смог подключится с телефона приложением ConnectBoot. Оно секунд через 10 разъединяется и сразу опять соединяется.Получается, что приложение должно постоянно посылать что-нибудь.Заходил в настройки адаптера, там нет опции настройки тайм-аута.
Т.е. ставили галку и указывали 3 секунды, как на левой половинке вот этой картинки?
i.stack.imgur.com/Mbewt.png
Если так, то проблему решить несколько сложнее…
Да именно так и делал.Еще в ConntctBoot пару раз отправил команду АТ и соединение было стабильным.
Все подключился но после сканирования блоков Wi-Fi через секунд 10 отключается и если не успел зайти в какой нибудь блок надо сканировать заново, тесть адаптер держит соединение секунд 10 после выполнения какой нибудь команды
Там web сервер есть? Маловат тайм-аут. Нужно хотя бы секунд 40 поставит или вообще убрать
Спасибо за помощь, но просмотрев форум производителя я понял, что проблема по отключение Wi-Fi почти у каждого адаптера, обновить прошивку обещают с 2014 года. Надо было заказывать Bluetooth. Придется ждать официального обновления. Еще раз спасибо за помощь.
Я бы так быстро не сдавался. Давайте попробуем задействовать TcpKeepAlive. Возможно поможет
Дело в том, что адаптер теряет связь только с приложением, а с телефоном он сопряжен. Телефон показывает, что он подключен к сети адаптера. По ходу у них свое приложение постоянно посылает какие то команды, пока я ни чего не предпринимаю. Потому, что индикаторы постоянно моргают после нажатия на кнопку connect.
Я об этом и говорю. Нужно только понять, достаточно приложению выставить опции сокета TcpKeepAlive или приложение периодически должно слать в адаптер что-нибудь типа команды AT. Второй вариант несколько сложнее, но тоже может быть реализован.
Sema371
Дело в том, что адаптер теряет связь только с приложением, а с телефоном он сопряжен. Телефон показывает, что он подключен к сети адаптера. По ходу у них свое приложение постоянно посылает какие то команды, пока я ни чего не предпринимаю. Потому, что индикаторы постоянно моргают после нажатия на кнопку connect.
Наверное с помощью pytty легко провести такой эксперимент. У него в настройках Connection есть возможность включить эту опцию на сокет и задать период их отправки. Поставьте там секунды 3 и проверьте будет ли адаптер отваливаться
Хорошо попробую, но я сейчас в командировке. Приеду попробую.
попробовал с модом который вы мне дали все тоже самое.мне кажется, что у пирена нет связи с адаптером значок wifi просто мигает, а когда есть связь он должен гореть.даю вам ссылку на логи и скриншоты проверки адаптера yadi.sk/d/QMzYMErP3NsVL3
Да, проблема видимо в подключении по wifi. Нужно только понять почему chk_elm работает а сам пирен нет. Как вы их запускали?
я запускал через универсальный лаунчер и через лаунчер из версии 0.9с меняв строку на адрес адаптера.когда запускаю chk_elm индикаторы питания и wifi горят, а два других быстро мигают.а когда запускаю пирен индикатор wifi моргает, когда начинает сканировать 1 блок индикатор ближний к индикатору wifi 1 раз моргает и на этом все заканчивается.когда запускаю программу obd link и нажимаю connect индикатор wifi горит постоянно а два других индикатора постоянно моргают даже если я не чего не сканирую еще когда индикатор wifi медленно мигает это значит что он подключен к телефону а когда горит постоянно значит что выполняет команды
здравствуйте у меня адаптер obdlink mx wifi с помощью какой программы мне подключить его к терминалу и как его подключить. адаптер определяется как elm327 v1.3a на сайте производителя пишут что версию можно поменять с помощью команды STSATI через программу putty программу установил а как подключится к адаптеру не знаю
подключиться к wifi адаптеру можно стандартной утилитой telnet (в последних версиях Windows ее иногда нужно доустанавливать самостоятельно из дистрибутива как компонент) либо можно воспользоваться такими утилитами как putty
Саму версию прошивки командами с консоли изменить невозможно. Есть только команды, которые меняют надпись возвращаемую на команду запроса версии — это все равно что мелом на сарае написать… алгоритм работы адаптера от этого не изменит.
Ваша версия 1.3 на многое должна быть способна и переживать по этому поводу не нужно
разработчик адаптера пишет, что он поддерживает все команды v1.4 кроме одной ATCEA и по этому ставит v1.3a и для некоторых приложений надо поменять номер версии.У меня проблема с подключением Pyrena к рено сандеро степвей 2016г. Когда проверяю версию адаптера все диоды моргают и проверка проходит результат 85 команд из 95 поддерживается, а когда пытаюсь соединится с ЭБУ диоды на адаптере не горят очень долго сканирует блоки и на 9 блоке выскакивает ошибка таймаута.
Давайте логи сканирования посмотрю
а куда отправить логи?
Положите на какой-нибудь обменник
yadi.sk/d/aMNa7bBL3NqJLH вот ссылка.
попробуйте вот с этим модулем
cloud.mail.ru/public/5RFH/DLk67fGPW
мне подменить этот мод в папке с версией pyrena или положить его в корень папки script и запускать с помощью его
Нужно заменить такой же
спасибо вечером проверю отпишусь
Привет… с трудом понимаю то о чём тут идёт речь… Скажи, вот на моём пежо 307 есть две шины — CAN и VAN. Первое: Нашёл я два заветных проводочка шины КАН (ибо в диагностической колодке их нету, … прозвонил тестером где какой — высокий низкий…, подсоединил к ним свой ЕЛМ327… запускаю на планшете программульку "обд доктор" и… вместо привычного подклчения — НИ ЧЕ ГО! Планет перебирает протоколы и не может никак подобрать. Хотя по К-линии через розетку работает всё нормально. ПОЧЕМУ?..
Второе: если подключить ЕЛМ327 к ВАН шине что будет? Сможет ЕЛМ327 её прочитать или сгорит? Померял тестером напругу — там 1 и 4 вольт. В КАН шине — 2,4 и 2,6 вольт соответственно.
Что за тип шины VAN я не знаю, а CAN скорее всего там 1Мегабит, иначе ELM должен был ее опознать, если конечно ELM исправный.
"Внимание! Этот пользователь указал, что не понимает русского языка. Наше сообщество привлекает всё больше единомышленников за рубежом, пожалуйста, приветствуйте их и пишите им на их языке."
Полезная информация! Спасибо!
Старался )