CANは一度動作しましたが、再起動後に消えてしまいますか? ハードウェアに触れる前に、ブート順序、モジュールのロード タイミング、インターフェイスの名前を確認してください。
OpenArm の起動に関する一般的な問題は、新しい制御 PC で発生します。つまり、CAN は一度機能しますが、再起動後に予期されたインターフェイス名が失われ、デバイスのバインドが異なるか、起動スクリプトがバスを見つけられなくなります。
新しい制御 PC で再起動した後に CAN インターフェイスが失われる OpenArm ケースをどのように診断していますか?
ドライバーのロード、インターフェイスの名前付け、起動順序を確認する方法、および単純なホスト セットアップの問題とケーブルまたはトランシーバーの問題を区別するのに役立つチェック方法を共有してください。
返信する場合は、再起動の症状を正確に 1 つと、根本原因を明らかにしたホスト側のチェックを正確に 1 つ含めてください。
初心者向けのコンテキスト: 私たちの場合、can0 は手動セットアップ直後には存在していましたが、再起動するたびに消えて OpenArm の起動がタイムアウトになりました。 これにより、これはブート順序であり、トランシーバーが故障したわけではないことが分かりました。
初心者向けのコンテキスト: これを解読したチェックは `journalctl -b | `でした。 rg -n "can|socketcan|modprobe"`。 モジュールは起動ユニットの後にロードされたため、インターフェイスのクエリが早すぎて再試行されませんでした。
初心者向けのコンテキスト: 明示的な `After=systemd-modules-load.service` を指定した専用の `openarm-can.service` と、`ip link show can0` の readiness プローブを追加しました。 再起動の信頼性は 3 週間にわたって 100% でした。
初心者向けのコンテキストフォローアップ: 初心者向けのフォローアップの質問: OpenArm を起動する前に別のチームが CAN の準備が整っているかどうかを確認できるように、正確な起動時チェック順序 (3 ～ 5 個のコマンド) を共有してもらえますか?
最も近い症状を選択して、適切なトラブルシューティング パスに従ってください。
配線に触れる前に、モジュールの負荷、インターフェイスの存在、サービス順序を確認してください。
lsmod | rg -i "can|socketcan|peak"
ip -details link show can0
journalctl -b | rg -n "can|socketcan|modprobe"明示的な依存関係を持つ専用の CAN 起動ユニットと can0 の Readiness Gate を追加します。
まずはチェックリストのテンプレートとして使用してください。 実行前に自分のセルでインターフェイス名、フィクスチャ ID、安全条件を確認してください。