バックナンバーはこちら。
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を２つ起動(１つ目を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 TriggerBlockcan.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。
バックナンバーはこちら。
コメント