CAN

バックナンバーはこちら。 はじめに 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のコツはシンプルに書く。 複雑な処理はライブラリに逃がすなどがコツ。

FMUとCANシグナルの紐づけのためついにCAPLに手を付け始める。 CAPLではイベントハンドラを使うことが多い。 イベントはおおよそ以下。 シミュレーション開始。 タイマ。 CAN受信。 シグナル更新。 ネットワークノード毎にCAPLを設定できるので、ノードの役割を意識する必要がある。

FMUの中に指令器もあったが、CANoeから指令値を変えられた方が便利なのでシグナルジェネレータ機能を使用する方針となる。 dbcファイルで定義したシグナルに対して自由は波形を載せることが可能な機能。 シグナルジェネレータで台形波を作成しTargetシグナルとして出力できるように設定。 さまざまは波形を設定可能。

CANoe.IL機能でシグナルを簡単に叩けるようにはなったが、FMUとの接続が無いとCAPLを実装してもイマイチ。というわけでFMUインポートから実施。FMUインポートの手順確認。最終的にはCANoeシステム変数と紐づいて、そのシステム変数を読み書きすることで結果としてFMUのInput、Outputにアクセスできる。

dbcファイルが出来上がったのでCANoeのデータベースインポートウィザードを使ってみた。 dbcを読み込むことでdbc内で定義されているネットワークノードをCANoeに割り当てることが可能。 生成されたノードはdbcで定義されたCANメッセージを同じく定義された送信周期で送信可能。 CANoe.IL機能の一端。

CANdb++エディターで各種定義を実施。 シグナル、メッセージ、ノードの順番で定義していく。 メッセージの周期時間は送信周期を示す。 単位は[ms]。 属性の「GenMsgCycleTime」パラメータを修正することで変更可能。 CANoe.IL機能を使用する時に生きてくるパラメータ。