CANopenのハートビート プロトコルについて奇妙な発見があります。たぶん、他の誰かがこのようなものを見たことがあり、おそらくこのように動作するはずです... とにかく、これがそれについてです:
CANopen には 2 つのタイムアウト ベースのライフ ガード メカニズムがあります。1 つ目はノード ガードです。
もう 1 つはハートビートと呼ばれます。それは非常に単純です。ネットワーク上のすべての参加者が、そのノード ID とその状態を示す通常のメッセージを送信します。頻度はオブジェクト 0x1017sub0 によって定義され、ハートビート プロデューサー時間と呼ばれます。ゼロに設定すると、ハートビートは送信されません。
他の参加者は、ネットワーク上で検索するノードの数に加えて、2 つの連続するハートビート メッセージ間の最大時間を定義できます。この情報は、オブジェクト 0x1016sub1..n に、この特定のノードがリッスンする必要があるノードと同じ数の 32 ビット エントリとして格納されます。
エントリは、ノード ID (ビット 22 から 16) と、ハートビート消費者時間 (ビット 15..0) と呼ばれる、ハートビート間に経過する可能性がある前述の最大時間で構成されます。ここでも、エントリがゼロの場合は無視されています。
お気づきかもしれませんが、ネットワーク マスター (ノード ID 1) とスレーブ (ノード ID 2 ～ 127) の間に区別はありません。
これまでのところ、理論は次のとおりです。
ネットワーク内のスレーブ ノードの 1 つをマスターのハートビート コンシューマーとして構成しているため、オブジェクト 0x1016sub1 に 0x000107D0 のようなエントリがあります。マスターからのハートビート メッセージが少なくとも 2 秒後に期待されることを意味します。
これが 2 つの例で機能することを確認しました。しばらくマスター ハートビートを送信してから停止すると、ノードは運用前モードに戻るか、適切な緊急メッセージを送信します。
master-heartbeat-messages を送信しない場合、ノードを起動 (運用モードに移行) した後、ノードが運用前モードに戻るか、適切な緊急メッセージ、あるいはその両方。しかし、私が試した 2 つの例では、何も起こりませんでした。ハートビートをまったく送信しない場合、ノードはハートビートを予期せず、そのまま実行を続けます。
2 つの例は、互いに大きく異なります。おそらく同じCANopenスタックライブラリを使用しているかどうかはわかりません。
説明はありますか？