2400509_ja-JP

はい

CRANK、mpc5775eによるCPSのキャプチャ

こんにちは、

私はNXP eTPUのCRANK機能を36-2クランクホイールで使用しています。CPS信号は、回転数（加速プロファイル）の増加に伴って生成されます。CRANKパラメータ(gap_ratio、win_ratio_normal、win_ratio_across_gap、win_ratio_after_gap、win_ratio_after_timeout)は、ファンクションセレクタに付属するExcelシートを使って計算されます。

エンジンの位置がFS_ETPU_ENG_POS_PRE_FULL_SYNCに達したら、TCR2を同期するためにfs_etpu_crank_set_sync()を一度呼びます。呼び出しの前後でTCR2の値を確認することで、同期が正しく適用されていることを確認しました。値は期待どおりに変化しています。

RPMを計算するために、FS_ETPU_CRANK_TOOTH_AFTER_GAPからCRANK状態が変化した後、fs_etpu_crank_copy_tooth_period_log()を使用して歯周期ログをコピーし、平均歯周期を計算してからRPMを計算します。最初の回転数（RPM）の値は正しく計算されています。

しかし、1回か数回転すると、CRANK機能がFS_ETPU_CRANK_ERR_TIMEOUTとFS_ETPU_CRANK_ERR_STALLを報告します。これらのエラーが発生すると同期が失われ、回転数を計算できなくなります。

混乱するのは、デバッガをリセットして同じCPS信号と設定で再度アプリケーションを実行すると、正常に動作し続けてRPM値を長期間記録できる場合もあれば、エラーがほぼ即座に現れることもあります。入力信号と構成は変更されていないのに、なぜ動作が矛盾するのか理解できません。

これはウィンドウ比率のパラメータに関連しているのでしょうか?もしSOなら、加速するクランク信号に対してどのパラメータを最初に調整すればよいでしょうか(win_ratio_normal、win_ratio_after_timeout、gap_ratioなど)。急速に加速する信号に対して、これらのパラメータを調整するための推奨手順はありますか？

よろしくお願いします！

Re: Capturing CPS with CRANK, mpc5775e

こんにちは、

現在のところ、最も可能性の高い原因は、適用されたアクセラレーションプロファイルに対してウィンドウの余白が狭すぎるか、デバッガーのリセット後に異なる開始条件が生じる不完全な再初期化のいずれかであると考えられます。
現時点では、根本原因が確定したとは言えません。提供された情報に基づくと、CRANK機能は初期段階で同期を達成し、有効なRPM値を生成するため、基本構成は正常に機能していることがわかります。この問題は、関数がタイミングの許容範囲を失い、最終的にFS_ETPU_CRANK_ERR_TIMEOUTとFS_ETPU_CRANK_ERR_STALLを報告するときに後から発生します。

根本原因を効率的に絞り込むために、まずは2つの簡単な実験から始めます。

関連するウィンドウ比率を増やして、タイムアウト/停止状態が遅延するか解消されるかを確認してください。
加速度勾配を小さくして試験を繰り返し、元のプロファイルとの挙動を比較してください。

ウィンドウ幅を広げたり、加速ランプを緩やかにしたりすることで問題が改善される場合は、根本的な設定の問題ではなく、タイミングマージンに関連している可能性が高いと考えられます。

よろしくお願いいたします。

ピーター