このCANバスでのメッセージデータのデコード

最初のメッセージを除いて、これは一般的な SDO トラフィック（ CANopen ）、リクエストとレスポンスのペア：

0x665 SDO request (range 0x600 - 0x67F, depending on the node ID) 0x5E5 SDO response (range 0x580 - 0x5FF, depending on the node ID) 

最初のペアの場合、デッドギブアウェイは応答の最初のバイトの0x4Bです。これは、返されるデータのサイズが2バイトであることを示しています（1バイトと4バイトの場合、それぞれ0x4Fと0x43です）。リクエストの最初のバイトの0x40は、それが read リクエストであることを示します（標準では別の用語"アップロード、インターネット（ダウンロード）とは逆の意味-アドレス指定されたデバイスの観点からです。

要求CANIDは0x600 +ノードIDです。応答CANIDは0x580 +ノードIDです。したがって、次のようになります。

665 A read request to the device with node ID 0x65 5E5 A read response from the device with node ID 0x65 

SDOの場合、CANopenインデックスとサブインデックスは2番目、3番目、4番目のバイトにあります（CANopenインデックスの最下位バイトが最初）。したがって、最初のペア40 78 60 00の場合、リクエスターは次のように言います。 "ノードID0x65（101）のデバイス、6078sub0 " 。

この場合、情報はアドレス指定されたデバイスからリクエストを行った人に流れます（リクエスターはCANバスログからはわかりませんが、これは通常、システムの中央コントローラーまたはPCで実行されているサービスツール（通常はUSB-CANアダプター）です。

したがって、表示されているトラフィックに対して、読み取り要求が行われます（最後の応答は、投稿されたCANバスログに含まれていません）：

6078sub0 (2 bytes, 0xDB00 = 219) 6064sub0 (4 bytes, 0x005E7DE4 - 6,192,612) 6041sub0 (2 bytes, 0x0227 - 551) 6041sub0 (2 bytes, 0x0227 - 551) 606Csub0 (?? bytes) 

不思議なことに、6041sub0の要求が繰り返されます。

さらに、SDOは通常、構成情報のみを対象としていますが、CANopenインデックス範囲0x6000〜0x6FFFは通常、測定量やステータスなどの非構成情報に使用されます。

マニュアルの詳細

SDOインデックス/サブインデックスはマニュアルで調べることができます（I hサンプルCANバスログからの実際の値が含まれています）：

6078sub0 Motor current, 219 mA 6064sub0 "Position Actual Internal Value" is 6,192,612 6041sub0 Statusword, 0x0227 = 0000 0010 0010 0111, meaning: "ready to switch on", "switched on", "operation enabled", "quick stop" "remote" 606Csub0 "Velocity Actual Value". The value is not included, but it is a 32-bit signed integer. 

最初のメッセージ

最初のメッセージもCANopenであると仮定すると、 4E5 F0 16 00 00：すべてのCANopen CANメッセージのIDは、4ビットの機能コード（0〜15）とそれに続く7ビットのノードIDです。この場合、0x4E5 = 10011100101bです。したがって、機能コードは1001b = 9であり、" PDO4を意味し、"を送信します。 PDOの情報フローの方向（この場合は"送信"）は定義の問題です（アプリケーションによって異なります） ）。ノードIDは1100101b = 0x65です。

PDOのノードIDはSDOの場合と同じです。

このPDOの情報"送信PDO4 "は、SDO 0x1A03、"送信PDOマッピングパラメーター4 。デフォルトから変更されていない場合、PDOのデータはSDO 0x60FAsub0、符号付き32ビット整数と同じです。

コントロール位置制御ループの出力としての努力。位置制御機能では、制御力の表記はモードに依存するため、指定されていません。

結論

モーターデバイスノードIDが0x65の場合、 PDO を使用して（おそらく一定の時間間隔で）制御作業を送信します。

コントローラーまたはサービスツールのリアルタイムモニターウィンドウが読み取り、表示します。 SDO を使用した同じモーターデバイスからの他の測定量/ステータス。

コメント

• この種のCANを使用しています毎日のバスデータなので、これは簡単に認識できます。ただし、正確な解釈/意味は、特定のシステムに関する情報によって異なります。この質問は包括的な答えに値すると思いました。

リスティングの内容を正確に説明していませんが、可能性がありますはメッセージID、括弧内のデータバイト数、実際のデータバイトの順です。IDが11ビットか29ビットかを明示的に示しているものはないようです。おそらく、IDに3つのHEX桁を使用するだけです。リストには11ビットIDが示されています。その場合、29ビットIDに対して8つのHEX桁が表示されます。

したがって、各行は1つのCANメッセージであることを示しています。デコードするものはこれ以上ありません。 CANメッセージを理解してください。明示的に表示されます。

たとえば、最後の行は、メッセージがID 665h（10進数で1637）で表示され、このメッセージには8データバイトがあり、データバイトは（HEXでは）40、6C、60、0、0、0、0、および0でした。最初の3つは、10進数で64、108、および96になります。

そのメッセージの意味は、メッセージを発信したデバイス、またはメッセージに基づいて動作することを目的としたデバイスに対するものです。特定のデバイスのドキュメントを調べる必要があります。その「CANの上のレイヤー。

デバイスのノードIDは101

ノードがありませんCAN内のID、メッセージIDのみ。デバイスがノードIDの概念を使用している場合、これはCANの上のプロトコルレイヤーに固有のものです。CAN標準ではそれを支援できません。特定のデバイスのドキュメントを参照する必要があります。これは、CANより上で使用される高レベルのプロトコルを参照している可能性があります。おそらく別のドキュメントにあります。

コメント

• 'は基本的なCANではなく、マニュアルに示されているようにCANopenです。
• 私の答え。

デバイスは CANopenプロトコル。 CANopenはCANベースの通信システムです。上位層のプロトコルとプロファイル仕様で構成されています。

自動化で使用されます。通信全体を把握するためのプロトコルアナライザがいくつかあります。 CANopenを使用した自動化システムは、マスター/スレーブアーキテクチャです。ウィキペディアでCANopenに関する情報を見つけることができますが、メッセージ指向のCAN自体ほど簡単ではありません。

コメント

• はい、それは正しいです。 CANopenです。

通信をデコードするには、モーターのCANopenオブジェクト辞書を知っている必要があります。 TPDOとその内容は、通信オブジェクトとマッピングオブジェクトに依存しているようです。

プロトコルを理解するには、CANopenの次の用語を学習する必要があります。 -オブジェクトディクショナリ-プロセスデータオブジェクト（PDO）-通信パラメータ-マッピングパラメータ