バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/
はじめに
ISO-TPのシミュレーションをしよう。のシリーズ。
pyton-canのcan.playerによるCANログ再生&can.loggerによる収録。
登場人物
博識フクロウのフクさん

イラスト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
今回の実験構成

前回、can.playerでログ再生して、BusMasterでそれを収録したわけなんだけど。

確かそうだったね。

今回はこんな構成にする。


ん?
can.logger?
これもpython-canのモジュールの一種?

Yes。

察すると、BusMasterみたいに収録してくれるものなのかな?

それもYes。
なかなか鋭くなったね。

まぁ前回はpthon-canの送信の確認は取れたことにはなったと思うけど、
受信の確認は取れてないよね?
だから今回はそれの確認かなって思って。

おー。成長しておる。
can.playerで再生

流れとしては以下になるね。
①Anaconda Promptを2つ起動(1つ目をPrompt1、2つ目をPrompt2とする。)
②Prompt1でcan.logger起動
③Prompt2でcan.player起動
これで、can.playerが再生したCANフレームをcan.loggerが収録する。

なるほど。
先にcan.loggerを起動しておかないとダメってことだね。

再生するのは前回作ったascファイル。
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

can.playerとcan.loggerの起動は以下のコマンドになる。
> python -m can.player -i vector -c 0 canlog.asc
> python -m can.logger -i vector -c 0 -f canlog2.asc
-m:動作モジュール指定
-i:インターフェース指定
-c:チャンネル指定
-f:収録ファイル指定

よし!動かした!

じゃ、can.loggerで収録したascを確認してみよう。
can.loggerで受けてみる
Begin Triggerblock
0.000000 Start of measurement
0.000000 1 111 Rx d 3 01 02 03
0.002097 1 222 Rx d 4 0A 0B 0C 0D
0.003940 1 333 Rx d 8 11 22 33 44 55 66 77 88
0.009920 1 111 Rx d 3 01 02 03
0.011952 1 222 Rx d 4 0A 0B 0C 0D
0.013984 1 333 Rx d 8 11 22 33 44 55 66 77 88
0.018071 1 111 Rx d 3 01 02 03
0.020078 1 222 Rx d 4 0A 0B 0C 0D
0.021930 1 333 Rx d 8 11 22 33 44 55 66 77 88
0.029016 1 111 Rx d 3 01 02 03
0.031089 1 222 Rx d 4 0A 0B 0C 0D
0.033030 1 333 Rx d 8 11 22 33 44 55 66 77 88
0.038912 1 111 Rx d 3 01 02 03
0.041058 1 222 Rx d 4 0A 0B 0C 0D
0.041927 1 333 Rx d 8 11 22 33 44 55 66 77 88
End TriggerBlock

おー、ちゃんと取れてるね!

んー、やっぱり精度はBusMasterで確認したときと一緒か。
でも、can.loggerはascファイルフォーマットなんだ。

実際はファイル指定した時の拡張子でフォーマットが決定するね。
以下が選べるようだよ。
- asc
- blf
- csv

blfってなんだっけ?
これも見たことあるような?

これもVectorのCANログフォーマットの一つ。
ascがテキスト形式に対して、blfはバイナリ形式になる。
よって、テキストエディタで開いても何が書いてるかは分からない。

だったら、ascの方が良くない?

blfの方がファイルサイズが小さくなるのと、
収録負荷が下がるという利点はあるかな。
ただ、中身を見るにはCANoeかCANalyzerが必要になるけど。

CANoeかCANalyzerがあるんだったら、そっち使うんじゃない?

まぁそうだろうねぇ。
あり得る状況としては、
can.loogerをPythonベースの自動計測システムに組み込んで収録。
収録データは後でまとめてCANoeで確認。
とか。

まぁある得るかどうかだとあり得るのかなぁ。

まぁそういう機能があって、そういう選択肢があるってことだけ覚えておけば良いと思うよ。

そーだね。選択肢として知っとくってのも良いね。
まとめ

まとめだよ。
- can.playerで再生してcan.loggerで収録した。
- can.loggerの収録ファイルフォーマットは3種類。
- asc、blf、csv。
バックナンバーはこちら。
コメント