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のコツはシンプルに書く。複雑な処理はライブラリに逃がすなどがコツ。