バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/
はじめに
ISO-TPのシミュレーションをしよう。のシリーズ。
pyton-canのcan.playerによるCANログ再生。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
python-canのインストール
次はお待ちかねのpython-can。
こいつでpythonからCANの送受信ができるようになる。
(前回説明せずにぶった切ったということは、
まぁまぁのボリュームがあるってことなのかな・・・。)
インストール自体は簡単。
pipっていうPythonのパッケージ管理ツールを使用する。
お、ということはコマンド一発でインストール完了なのか。
そうだね。
ホント便利な世の中だよね。
ちなみに以下でインストールOKだよ。
> pip install python-can
あれ？
エラーになった！
あー。太郎くんとこの会社だとプロキシが必要みたいだね。
プロキシを指定した上で再度実行。
> pip --proxy=[プロキシサーバ名]:[プロキシポート番号] install python-canお、通った。
良かった。
python-canの動作確認
これも単体で動作確認してしまおう。
以下の構成で確認。
ん？
このcan.plyaerって何？
python-canに含まれているモジュールなんだけど、
スクリプトとして呼び出すことで単体アプリ動作が可能なんだ。
(何言ってるかちょっとわからなかったぞ。静観してみるか)
(「何言ってるかわからずにとりあえず静観を決め込んだ」波動を感じた。)
一種のサンプルプログラムと思えばOKだよ。
おー、そういうことか！
can.player用の再生asc作成
まずcan.playerに再生してもらうascファイルを作成する。
ascファイルって何だっけ？
Vector社製品で使用するCANのログファイルフォーマットだね。
まぁフォーマットとしてはデファクトスタンダードな感じなんで、Vector社以外でも使われていることは多いかな。
やはり、CANの話になるとVector社強いな。
ざっとテキストエディタで書いてみた。
Begin Triggerblock
0.000000 Start of measurement
0.000000 1 111 Rx d 3 01 02 03
0.001000 1 222 Rx d 4 0A 0B 0C 0D
0.002000 1 333 Rx d 8 11 22 33 44 55 66 77 88
0.010000 1 111 Rx d 3 01 02 03
0.011000 1 222 Rx d 4 0A 0B 0C 0D
0.012000 1 333 Rx d 8 11 22 33 44 55 66 77 88
0.020000 1 111 Rx d 3 01 02 03
0.021000 1 222 Rx d 4 0A 0B 0C 0D
0.022000 1 333 Rx d 8 11 22 33 44 55 66 77 88
0.030000 1 111 Rx d 3 01 02 03
0.031000 1 222 Rx d 4 0A 0B 0C 0D
0.032000 1 333 Rx d 8 11 22 33 44 55 66 77 88
0.040000 1 111 Rx d 3 01 02 03
0.041000 1 222 Rx d 4 0A 0B 0C 0D
0.042000 1 333 Rx d 8 11 22 33 44 55 66 77 88
End TriggerBlock
あ、なんか見たことある！
これがascファイルか。
一番左の列がタイムスタンプで単位は秒。
can.playerはこのタイムスタンプに則って送信する作りになってると思う。
思うって・・・。
さっきpython-canのドキュメントを流し読みしただけだから、
まだ動くかどうかも分かってない。
まぁチャレンジネタって言ってたもんね・・・。
BusMasterの収録モード設定
じゃまずBusMasterを起動して、収録可能状態する。
LoggingのConfigureを選択。
addボタンを押して、ログファイルの保存先を指定しておく。
LoggingのActivateをクリックすると収録モードになるよ。
あー、これは設定する場所が分かれば雰囲気で設定できそう。
can.playerで再生したものをBusMasterで受けてみる。
can.playerでCANログを再生してみよう。
can.playerの起動コマンドは以下。
> python -m can.player -i vector -c 0 canlog.asc-m：動作モジュール指定
-i：インターフェース指定
-c：チャンネル指定
オプション無しパラメータで再生ファイル指定
インターフェースはVectorだから-i vectorなのね。
そして、以下がBusMasterで収録したログ。
***<Time><Tx/Rx><Channel><CAN ID><Type><DLC><DataBytes>***
00:00:01:4980 Rx 1 0x111 s 3 01 02 03
00:00:01:4999 Rx 1 0x222 s 4 0A 0B 0C 0D
00:00:01:5018 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88
00:00:01:5069 Rx 1 0x111 s 3 01 02 03
00:00:01:5089 Rx 1 0x222 s 4 0A 0B 0C 0D
00:00:01:5110 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88
00:00:01:5178 Rx 1 0x111 s 3 01 02 03
00:00:01:5197 Rx 1 0x222 s 4 0A 0B 0C 0D
00:00:01:5218 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88
00:00:01:5279 Rx 1 0x111 s 3 01 02 03
00:00:01:5289 Rx 1 0x222 s 4 0A 0B 0C 0D
00:00:01:5299 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88
00:00:01:5368 Rx 1 0x111 s 3 01 02 03
00:00:01:5388 Rx 1 0x222 s 4 0A 0B 0C 0D
00:00:01:5408 Rx 1 0x333 s 8 11 22 33 44 55 66 77 88
***[STOP LOGGING SESSION]***
あれ？
ascファイルフォーマットじゃないんだ？
そうみたいだね。
BusMaster自体はETAS社が主導で作ったものらしいんで、
ETASのCANログフォーマットなのかもしれないね。
あれ？
時間をよく見ると、
ちょっとズレてない？
1[ms]ごとに3つのフレームで、それが10[ms]周期のascだと思ってたんだけど？
まぁ完全な再現は難しいっぽいね。
たぶん、精度としては１～2[ms]くらいのズレは発生するんだと思うよ。
CANoeとかだともっと良い感じなのかな？
そうだねぇ。
CANoeの方だと250～500[us]オーダーの精度になるんじゃないかな？
そこは流石にCANoeの方が上かー。
ここが互角だとますますCANoeの立場が危うくなるし。
そもそもPython自体はスクリプト言語なんで、速度面ではちょっと不利だしね。
でも、おおよそのテストには使えるんじゃない？
確かにそこまでの精度を求めないなら十分かな。
まとめ
まとめだよ。
- python-canのインストールをした。
- python-canの動作確認をした。
- can.playerで送信してBusMasterで収録。
- python-canの動作性能は1～2[ms]オーダー。
- CANoe等だともっと早い。
バックナンバーはこちら。
コメント