バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はxcp_canクラスをXCPonCANFD版に対応した、xcp_canfdクラスへ拡張対応した。
単体テストとしては問題無く動作し、
仮想ECU側のPID制御の性質も見て取れるような結果となった。
少なとも、XCPonCANの時の挙動と同一。
今回からはDAQリスナーのCAN-FD対応を始める。
登場人物
博識フクロウのフクさん
![指差しフクロウ](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/指差しフクロウ.png)
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
![技術者太郎](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/技術者01アップ.png)
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
DAQリスナーのCAN-FD対応の要否について
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/「技術者a」13アップ.png)
今回からはDAQリスナーのCAN-FD対応ってことだけど、
具体的にはどうなるのかな?
python-can周りを修正すればOKな気はしてるけど。
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/指差しフクロウ.png)
そうだね。
しかも8byteで十分なデータ量だったので、特にデータフィールドのレイアウトも変えない。
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/「技術者a」13アップ.png)
じゃー、そもそもCAN-FD対応も要らないんじゃない?
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/お休みフクロウ.png)
まぁデータを送るという観点に於いては不要には見えるな。
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/「技術者a」20アップ.png)
そういう言い方をするってことは何か問題があるってことか・・・。
DAQリスナーをCAN-FD対応しなかった場合の問題点
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/指差しフクロウ.png)
CANとCAN-FDの関係はCAN-FDがCAN上位互換という位置づけになる。
つまり、以下が言える。
- CAN-FD対応のインタフェースはCANのフレームを認識できる。
- CANのみ対応のインターフェースはCAN-FDのフレームを認識できない。
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/技術者01アップ.png)
うん。これはなんとなくわかる。
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/お休みフクロウ.png)
そして、問題になるのが後者。
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/「技術者a」13アップ.png)
どういう問題になるの?
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/指差しフクロウ.png)
CANのみ対応インターフェースがCAN-FDのフレームを検知すると、
「異常なフレーム」と認識して、即時エラーフレームを発行してCAN-FDフレームをぶっ壊す。
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/「技術者a」10アップ.png)
ぶっ壊すの?!
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/お休みフクロウ.png)
ぶっ壊す。
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/「技術者a」20アップ.png)
これは確かに問題だ・・・。
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/指差しフクロウ.png)
というわけで、CAN-FDフレームが流れる回線上に「CANのみ対応のインターフェース」を混ぜることは厳禁となるわけだ。
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/技術者02アップ.png)
なるほど。
これがDAQリスナーをCAN-FD対応する理由になるのか。
DAQリスナーのCAN-FD対応
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/お休みフクロウ.png)
DAQリスナーのCAN-FD対応自体はシンプルで2か所書き換えるだけだな。
まぁ2つ目は送信するCANフレームをCAN-FDにしてるだけなので、対応しなくてもOKだけどね。
# バス接続
bus = can.interface.Bus(bustype='vector', channel='1', bitrate=500000)
↓
# バス接続
bus = can.interface.Bus(bustype='vector', channel='1', bitrate=500000, fd=True, data_bitrate=2000000)
send_msg = can.Message(arbitration_id=0x111, extended_id=0, data=[byts[0], byts[1], byts[2]])
↓
send_msg = can.Message(arbitration_id=0x111, is_extended_id=0, data=[byts[0], byts[1], byts[2]],is_fd=True, bitrate_switch=True)
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/技術者02アップ.png)
一つ目の初期化でCAN-FD対応のインターフェースにして、
二つ目のメッセージ構築で送信フレームをCAN-FDにしてるのか。
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/まるフクロウ.png)
正解。
![太郎くん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/技術者01アップ.png)
いろいろややこしい話は出て来たけど、やることは恐ろしくシンプルだった。
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/お休みフクロウ.png)
次回は念のため挙動確認をしておこう。
まとめ
![フクさん](https://www.simulationroom999.com/blog/wp-content/uploads/2020/05/指差しフクロウ.png)
まとめだよ。
- DAQリスナーのCAN-FD対応の要否ついて説明。
- CANのみ対応のインターフェースはCAN-FDフレームを検知すると「異常フレーム」と認識しエラーフレームをもってフレーム破壊を行う。
- よって、CAN-FDフレームが流れるネットワークにCANのみ対応インターフェースは接続禁止。
- CANのみ対応のインターフェースはCAN-FDフレームを検知すると「異常フレーム」と認識しエラーフレームをもってフレーム破壊を行う。
- DAQリスナーの修正は一撃。
バックナンバーはこちら。
コメント