PID

CANoeテストノードに記載するXCPセットアップ関連のCAPLコード開示。 ネットワークノードはイベントドリブン型、テストノードはシーケンシャル型とやや性格が違う。 といっても、テストノードでもCAN送信/受信イベントは受け取れるので気にするほどの差ではない。

CANoeでXCP関連の処理を追加する際の方針を確認。 複数のノードにXCP関連処理を記載するので連携が必要。 ノード間連携はCANoeシステム変数を使うのが最も手っ取り早い。 CANoeシステム変数の追加方法を確認。 CAPLからシステム変数にアクセスする際は変数名の目に「@」をつける。

CANoe上の指令器をdisable。 シミュレーション設定ウィンドウのノード上でdisable操作が可能。 CANOe上にテストノード追加。 シミュレーション設定ウィンドウのバス上で追加操作可能。 今回はCAPLテストモジュールを使用。 .NET、XMLのテストモジュールは気が向いたら調べる。

残り作業はXCPだけではない。 構造が複雑なので一旦整理。 Virtual CAN BusとCANoeシミュレーションバスは直結していると思って良い。 CANoe仮想HILSと仮想ECU連携のロードマップ提示。 指令器disable。 テストノード追加。 XCP関連セットアップ。 DAQ/STIM関連。

32bit FMU作成しCANoeに組み込んだ。 CANoeでFMU駆動の実験。 かなりキレイな波形が取れた。 FMU、CAN送信共に1ms駆動させているため。 Pythonの時は100ms駆動相当になっていた。 このあとはCAPLでXCPを実現するがpython-canでやったことと同じことをやればOK。

バックナンバーはこちら。 はじめに CANoeの内部プロセスとして描画プロセスと計測/演算プロセスが存在することと、プロセス間通信がTCP/IPを使用していることのの裏付けの調査結果を確認。 引き続き調査結果の話とCANoeの設計思想の話。...

バックナンバーはこちら。 はじめに 前回、CANoeが32bitFMUを要求する調査結果を確認。どうらやCANoe内で２つのプロセスが動作しており、FMUを処理する側のプロセスが32bitプロセスになっているようである。 今回はこれらの推測...

CANoeが32bitFMUを要求する理由の調査結果。 CANoe内に２つのアプリケーションが動作しているもよう。 描画担当で64bitプロセス。 計測/演算担当の32bitプロセス。 FMUは計測/演算担当のプロセス側が読み込んでるっぽい。 CANoeの内部構成についていろいろ考察したので次回説明予定。

ついにCANoe上でFMUを動作させる実験を開始・・・したが・・・。 謎エラー発生。 32bitアプリケーションから呼ばれるFMUの場合はwin32向けFMUである必要がある。 しかし、今回使用しているCANoeは64bitアプリケーションのため辻褄が合わない。 なぜこのようなことになっているか要調査。

仮想HILS向けCAPLコード公開。 イベントハンドラは関数先頭に「on」が付く。 その後ろに以下が続く。 start：シミュレーション開始。 timer：タイマ。 signal：シグナル更新。 CAPLのコツはシンプルに書く。 複雑な処理はライブラリに逃がすなどがコツ。