PID

DAQ listのODT_ETNRYのデータ長変更(16bit→32bit)。 namedtupleを使用していたので修正は楽。 DAQの受信レイアウト調整。 int.from_bytesを使用してるので16bitから32bitへの変更は楽。 DAQ受信データの物理値変換(1/65536→浮動小数点)。

xcp_canクラス改造箇所を整理。 予想以上に多いが、仮想HILSにXCPの都合を見せないための部分なので修正内容が集中し易い。 コンフィグレーション用のJSON記述の修正。 事前のPyXCP CAN-FD実験を元に修正。 SERIALを消して、FDとDATA_BITRATEと追加。

PyXCP Version0.16.5にてCAN-FDの動作確認。 UPLOAD、DOWNLOAD、DAQ、STIMを確認。 基本的にOK。 PyXCP側からのCAN-FDはBitrate_switchが無効になっているが、現状のPyXCPの仕様上やむを得ない。 この結果を元にxcp_canクラスを改造予定。

PyXCP Version0.16.5にてCAN-FDの動作確認再開。 まずはコンフィグレーション用JSON記述を修正。 SERIALパラメータを削除。 SERIALパラメータはデバイスの製品シリアルを指定するもの。 CAN-FD対応有無を判断しているようで、この判定でCAN-FD不可側になってるように見える。

PyXCPのVersion別CAN-FD対応状況を確認。 かなり、いろいろ変化してい居る。 SERIALパラメータがあると、CAN-FDフレーム送信でエラーが発生する。 よって、現時点では0.16.5のVersionを使用する。 CAN-FDフレーム送信可能、DLC可変。

PyXCPのCAN-FD対応の動作確認の結果を確認。 一見するとうまく動いているように見える。 が、どうやらPyXCP側からの送信フレームがCAN-FDになっていない。 少なくともCAN-FDフレームの受信はできている。 PyXCPもVersionがあるので、Version別の挙動を確認してみる。

PyXCPのCAN-FD対応はコンフィグレーションのJSON記述部分だけではあるが、動作確認用に修正する部分もある。 UPLOAD、DOWNLOADのサイズ。 DAQ listのODTのサイズ。 上記の方針に合わてコード修正実施。 DAQ listはODT_ENTRYの数を増やした。

xcp_canクラスのCAN-FDに関係する部分を確認。 要はPyXCPをCAN-FD対応にする部分。 コンフィグレーションのJSON記述を修正すればOKっぽい。 ソースコードからのリバースエンジニアリングによる調査結果。 本当合ってるか不安なのでJupyterNoteBookで動作確認を先に実施予定。

指令器の修正範囲を確認。 CANがCAN-FDに変えることから逆算して特定。 バス初期化とメッセージ構築の部分。 バス初期化はCAN-FD有効化とDataRateの設定。 メッセージ構築はCAN-FD化とbitrate_switch有効。 bitrate_switch無効でもOKだがbitrateは切り替わらない。

仮想ECU側のPID制御の入出力定義はポインタで実施。 元々が符号付き16bit変数へのポインタだったのでこれを符号付き32bit長変数に差し替え。 上記に伴い、参照先のアドレス境界を16bitから32bitに切替。 PID制御器の入力はfloat64で、参照変数が16bitか32bitかは気にしなくてもOKなコード。