Godzilla R32〜Inhouse Consult Scan Tool Wrap Up

Godzilla R32〜Inhouse Consult Scan Tool Wrap Up

サービスマニュアルを見ているとHicasのActive TestのDemonstrationに興味が惹かれる。後輪操舵角は高々最大1度であるが、直視できれば面白かろう。手動でのTest実施はBeautifulではないので、Consultを使ってActive Testを実行するが、Challengeの過程で思いもよらぬ展開に発展する事になろうとは。Browsing the service manual, I am very fascinated by a demonstration of Hicas Active Test. While the rear wheel steers at most 1 degree, it would be a great fun to observe it actually. Since the active test is not a beautiful manner to be conducted manually, I shall challenge it with Consult. The challenging efforts won’t be thought to lead to unexpected developments.

これ迄Arduino環境下でEngine ECUのConsult情報を取得して整備に活用してきた事はご既承の通り。

当初目論んだ計画は達成済みであるが、HicasのConsult情報の取得を目的としてプロジェクトの再開に着手する。

整合性の欠如

ArduinoのSketchを開始。Engine ECU用Sketchを書き換えるだけなのでプログラミング自体は至って簡単。Half a Day Jobで書き上げる。

Run!

うんともすんとも動かない。Consultから同期コマンドを送っても、Hicas ECUからResponseが返って来ないのだ。何度チャレンジしても同期出来ず、原因が究明できない。結局、前提条件をScratchから検証することにする。

  • Hicas ECUに不具合はないか？
  • Engine ECUの初期化は必要か？
  • Inhouse Consult I/Fの不具合？
  • PLMS Protocolの記載は正しいか？

その際、本体のSketchとは別にSerial CommunicationのStatus検証用Sketchを作成して、一つ一つ検証していく。

Hicasは寝起きは悪いが、連続してアクセスしているとResponseが返って来るようになる。その結果、二つの要因が判明。

最大の要因はどうもInhouse Consult I/FとArduinoの整合性が悪いようだ。

例えば、Consult Outlet <-> Inhouse Consult I/F <-> USB TTL (CH340) <-> Laptopの動作環境で市販DataScanデモソフトでは問題なくHicas ECU Part Numberを確認できる。

一方、Consult Outlet <-> Inhouse Consult I/F <-> ArduinoのシステムではHicasから受信できない。I/FのLogic Levelの不具合かと疑い、基準電圧をUSB-TTLに近い水準(2.1V)まで落とすべく分圧抵抗を変更するが、期待した割には改善なし。

色々試みる。

その過程で、Tx/Rx双方に対して入出力抵抗4.7KΩを付加すると、Engine ECUに対しても同期しなくなる事を発見するが、改善の兆しはない。

  • Initial Version
  • Updated Version
Inhouse Consult Adapter I/F

結局、打つ手なく、早い段階でキッパリと諦める。抜本的な対応策もあるが、これ以上追求する事を断念する。

断念する主な理由は、

  1. ArduinoはHandy性に大きな優位性があるもののキーボードもなくグラフィック機能も貧弱で使い勝手が悪い。
  2. 以前AIを学ぶ為利用したPythonは完全に忘れたので、この機会にPythonを再取得するモチベーションとしたい。C++より使いやすく、時代はPythonですね。GUI I/F用TKlinterやGame I/F用Pygameも使える。

余談だが、2mm間隔のコネクターを漸く入手。愚息の挙式で博多に出かけた折、天神のカホパーツセンターで購入。博多は何度行っても良いね。食い物は美味いし人々がおおらか。美人も多い！

新Pythonシステムの構築

Python Hicas Monitoring Systemを構築する。

具体的な動作環境は、Consult Outlet <-> Inhouse Consult I/F <-> USB TTL (CH340) <-> Laptopシステムとなる。Engine ECUにはシステム構築済みのArduinoをそのまま使う。

Linux環境に於いてRunしているが、Windowsで使う場合、シリアル通信のPort番号を変更するだけでWorkする。モニタリング項目は

  • Diagnostic Trouble Code(DTC)
  • Sensorの動作状況

動作挙動は下図参照の事。尚、モニタリングの更新頻度はConsultからの受信頻度に準ずる。

Python Hicasシステムの出力実例
R32整備書より引用

Pythonを使ったシリアル通信の解析作業の検証過程でHicas ECUの特異性を把握する。それが先に述べた問題の二点目となる。

ヒントはHicas ECUはEngine ECUとは別個で離れたTrunk Roomにあることに起因する。アクセスに苦労する有志諸君は本文中にヒントがあるので挑戦されたし。また、Protocolに一箇所Minorな印字ミスも判明。

Consultシリアル通信の仕組みは解明してみれば何の事はないLogicalな設定だ。トラブルのお陰でConsultへの送信Commandに対応するECUのResponseの仕組みを完全に解明できた事は大きな成果。特に、Hicas ECUのAccessに対するAcknowledge Commandに関する記載がProtocolにないが、これも容易に自己解決できる。

賢明な諸君はProtocolを一読しただけで解明できると推察するが、俺はつくづく頭が悪いなあと落ち込む。

以前の繰り返しとなるが、重要な論点であるので、ポイントをもう一度整理してみよう。

  • Consultのシリアル通信は８Bitを基準としている。
  • Bit(Binary Bit)とは２進数(Binary, 0と1)で表した数字の桁数
  • ８Bitのデータは８桁の2進数から構成される為(2^8＝256)、0～255 までの256通りの数字を表すことができる。Consultは一度に0~255迄の数字を扱う。それを超える数字については2回送受信する必要がある。
  • ８Bitで１Byte。１Byteの数字を表すのに16進数を使うと便利。256＝16×16なので，１Byteの数字が丁度2桁の16進数で表せる。
  • Consultの送信、それに対応するECUのResponseコマンドのシステムは１Byteで構成される。

初物の言語のプログラミングは慣れるまで大変だが楽しみでもある。教科書類はネットで公開されているが、肝心なポイントは自己解決するしかない。

Arduino言語との最も大きな特異点はシリアル通信におけるデータの読込みの型が異なる事。なお、Python3.xの使用を前提とする(Python2.xは開発終了済み故)。

  • Python(3.x)では原則stringはUnicode型に統一されている。Byte型stringを表記する場合、引用符前に文字bを付加するので分かりやすい。
    b’\xff\x1a\x01757 270′
    一方、ArduinoはByte型stringとして捉える。Pythonよりコマンドが送信される場合、自動的にUnicode型stringがbyte型stringに.encode()される。逆に、受信する場合Byte型stringに.decode()される。
  • 実用的な留意点としては、当初struct方式にてコマンドを送信するが一度に送信できるバイト数は20バイトが上限の模様。この制限を回避する為にbyte型stringにて送信することでArduino同様一度に20バイト以上のコマンドを送信できるようになる。但し、Consult が受ける最大のコマンド数は18バイトである(Protocolには20バイトとの記載)。この点が今回一番悩んだ箇所かな。また、2バイト以上のread() や readline()で読み込む際には、Byte型stringの文字列として代入される事に注意。1バイト毎に読み込むには反復入力等の処理が必要となる。
  • 些細な事だが、RPM Referenceコマンド(0x02と0x03)はvalidでなくエラー(0xfe)としてConsultは認識するようだ。
  • その他の留意事項
    • Asciiに該当する数字は16進法ではなくAscii表記される。
    • “com.readline()”は1行を受信。改行符号”\n”まで読み取る。
    • “ord(x)”関数は引数に渡した文字の Unicode に対する整数値を返す。
    • 数字の表記の一例
      >>> hex(255)
      ‘0xff’
      >>> bin(255)
      ‘0b11111111’

以上、必要な情報は全て伝授した。有志諸君の健闘を願っている。

課題

今回、別の切り口で実証する重要性を改めて再認識させられた訳で、ある意味成果のあった試みとPositiveに捉えている。

一旦Consult Hicas Python版を構築すると横展開は容易で、Engine ECUのPython版も書換え済みである。下図出力例参照。

Python ECUシステムの出力事例

グラフィック機能を付加しようと考え、インターフェスをtkinterかpygameかで悩んだが、最終的にtkinterでタコメーターを作成する。描画を更新するコマンドを見つけるのにチョット苦労したが、PagodaのVersatile Dashboard Interface制作の経験が生き、思ったより簡単でThree Days Jobで構築。下図のように稼働を確認済みであるが、描画速度が若干遅い様な気がする。更に、ボタン操作を含めた総合的なScan Toolの構築を考えたが、やっている事に発展性がないので、馬鹿らしくなって止める。

タコメーター作動状況

一番試したいActive TestのDemonstrationはLaptopを見ながらステアリングを操作する必要があるので、独り身では手動によるTestの方が実用的ではないかと思い直し着手していない。HicasからのResponseは問題なく受信できているので支障はないと思料するが、継続検討課題としておこう。

ROM情報の取得、修正を試みるBraveな御仁もいるようだが、俺には全く興味のない分野だ。

以上にてConsult情報の取得に係る一連のEffortsを終了としたい。

Seize the Day!

補遺1: Inhouse Consult Scan Tool

Engine Scan ToolArduinoシステム
20x4LCDにて表示
Engine Idle AdjustmentArduinoシステム
20x4LCDにて表示
AAC On/Off機能付属
Hicas Scan ToolPythonシステム
CF-J10使用
Graphic機能付属
Inhouse Consult Scan Tool システム設定一覧
Inhouse Consult Scan Tool 出力事例
Inhouse Consult Scan Tool Command 事例

補遺2: 文字コード

Pythonの文字列を扱い使い始めた時、見慣れないコード”Unicode“に出会う。

Wikipediaで調べると、”Unicode”とは、世界中の全ての言語の文字に対して、一つの文字コード体系で対応する試みで構築されて以来、OSやJava等の内部コードとして広く利用されているとの事。Pythonの文字コードのデフォルトでもある。

“Unicode”をコンピューターで扱う為、「符号化形式」に従って数値変換する。この「符号化形式」として”UTF-8″、”UTF-16″等がある。これらは文字に振られた番号をバイト表現に変換する際の方法を以下に引用する。

ASCIIコード

最も基礎となる文字コード。米国の国内規格。キーボードの数字、ラテン文字、記号等を1バイトで定義している。エスケープシーケンス(LF、CR)やタブ文字(HT)、NULLやBS等の制御コードも含める。

俺的には通常”ASCII”コードで用は足りる。プログラミングに於ける重要な事は、区切記号(“Backslash”)とパス記号(“Path”)はLinux/macOS系では”\”で表記される一方、Windows系では”￥”で表現される事である。

Shift-JIS

“ASCII”の文字に加えて、日本語の文字を加えたのが”Shift-JIS”である。半角カタカナは１バイト、それ以外の全角文字は２バイトで定義。俺は日本語は余り使わないので気にかけた事がないコード。

UTF-8

“ASCII”の文字に加えて、世界中の文字を追加したコードが”UTF-8″である。”ASCII”以外の文字は２～６バイトで定義。
“ASCII”との互換性が良いため扱いやすく、多くのソフトが”UTF-8″に対応している。

UTF-16

“UTF-16″は基本的な世界中の文字を２バイト、マイナーな文字を４バイトで表現した文字コード。”ASCII”は含めず、対応ソフトは限定的。

以上で情報としては充分であろう。

Comments are closed.