CANopen プロトコルを理解しようとしています。
今のところ、実験する CAN ハードウェアも CANopen スタックもありません。
RS-232 ポートで受信した CANopen メッセージを単純に解釈する Java プログラムの書き方を知りたいです。
シリアル ポートに接続する CAN インターフェイスを知りません (CAN とシリアル ポートを備えたマイクロコントローラーに基づいて作成するのはそれほど難しくありません)。ただし、標準のシリアル ポートは遅すぎて、CAN で利用可能な高速をサポートできません。
通常、CAN インターフェースの API を使用する場合、ID、長さ、および最大 8 バイトのデータで構成されるメッセージを読み取ることができます。SOF/EOF を気にする必要はありません。低レベルで直接 CAN コントローラーとインターフェースする場合 (つまり、ドライバー/API を自分で作成する必要がある CAN インターフェースがある場合) であっても、それらの詳細を気にする必要はありません。また、CANコントローラーをまったく使用せずにCANバスにアクセスしようとするのは望ましくありません...
CAN インターフェイスを持っているふりをしたい場合は、ID、データ長、および 64 ビット データ バッファーの 3 つの項目を返すスタブ関数を作成できます。これは基本的に、すべての CAN インターフェイス API が提供するものです。また、CAN メッセージを送信するときは、同じパラメーター (ID、長さデータ) を使用します。
PDO は、CAN ID フィールドを使用して定義されます。理論的には、デバイスの PDO の数は実際にはそれほど制限されていませんが、定義済みの接続セットは各ノードに少数 (4 つ) の PDO しか割り当てていません。
PDO は標準の CAN フレームです。前述のように、CAN ID は PDO を識別します。事前定義された接続セット (ほとんどのデバイスが従います) では、すべてのメッセージの CAN ID は機能部分とモジュール ID 部分で構成されます (モジュール ID はデバイス用にハードコードされているか、ディップ スイッチなどで構成可能です)。CAN ID のビット 10 ～ 7 は機能コードで、ビット 6 ～ 0 はモジュール番号です。たとえば、モジュール ID が 0x10 のデバイスからの TxPDO1 は、CAN ID が 0x190 になります。11 ビット CAN ID の上位 4 ビット は((CAN_ID & 0x780) >> 7)機能コード (TxPDO1 = 3) を示し、残りのビット(CAN_ID & 0x7f)はモジュール ID (この例では 0x10) を示します。したがって、CAN ID 0x190 の CAN バスでメッセージを読み取ると、これがモジュール ID 0x10 のデバイスからの PDO であることがわかります。
<module ID>(これを表現する簡単な方法は、TxPDO1 の CAN ID が 0x180+に設定されている、TxPDO2 の CAN ID が 0x280+ に設定されている、などと言うかもしれません<module ID>)。
PDO 内のデータをどのように解釈する必要があるかは、デバイスによって異なります。
CANopen の優れたチュートリアルを見つけることをお勧めします。残念ながら、それらのほとんどは、実際よりもはるかに複雑に聞こえます。ですから、理解できると思われるものが見つかるまで周りを見回してください。
シリアル ポートから実行できる CAN インターフェイスは多数あります - VSCOM、Vector などです。生の CAN フレームを送受信できる無料のプログラムもあります。
私が見つけられなかったのは、CANopen を解釈できる無料のプログラムです。ほとんどは有料プログラムです。例外は、Linux 用のWiresharkです。SocketCANを使用してパケットを取り込み、すべての CANopen フレームを解析できます。
CAN バスを 1 Mbit/s で実行し、VSCOM インターフェイスを使用してシリアル ポートで監視しています。
CANFestivalは、ベア マシンだけでなく Linux にも簡単に移植できる優れたオープン ソース スタックです。