「CANopenプロトコル 〜実践編〜」

先述の通りCANopenでは機能に応じて機器ごとの関係性が変わりますが、NMTマスタとNMTスレーブという関係が一番強力な関係性となります。各NMTスレーブは、NMT状態という4種類のステータスでNMTマスタに管理されます。下表の通り、NMT状態によって使用できる機能に制限があるため、NMT状態を管理できるNMTマスタが一番強力な機器となります。

表 1. 各NMT状態で使用できる機能一覧

NMT状態	通信関連機能 (○：使用可、×：使用不可)				備考
	Heartbeat	SYNC	SDO	PDO
Initialization(※2)	-	-	-	-	起動直後の数秒のみ
Pre-operational	△	△	△	×	△：ノードID確定時のみ可
Operational	○	○	○	○
Stopped	○	×	×	×

各機器は起動直後にInitialization状態となり、不揮発性メモリからパラメータを RAM にロードするなど初期化を実行します。初期化完了後、自動的にPre-operational状態に移行します。そのため、Initialization状態は起動やリセットした直後(通常は数秒)だけ現れる状態です。 Pre-operational状態では、ノードIDが確定している場合に限り、PDO以外の機能を使用できます。後述するLSS機能を使用する場合、起動しただけではデバイスのノードIDが決まらないため、起動直後にPre-operational状態となった後も各機能を使用できません。

CANopenではノードIDの決め方が静的と動的の2種類あり、どちらを使用するかはEDSファイル(※3)などで設定します。このうち動的割り当てのことをLSS(Layer Setting Services)機能と呼びます。
静的割り当ては、デバイス側がロータリースイッチなどで自身のIDを事前に設定しておき、起動後はそのIDを使用します。
対して動的割り当ては、デバイス側はLSSスレーブであるという設定をしておきますが、起動後はIDが無いため通信せず、IDを付与するために管理側が送信するメッセージを待ち続けます。そのため、起動する度にIDが変わる可能性があります。

CANopenには、デバイス側が機能しているかを確認する手段としてNode Guarding(※4)とHeartbeatという2種類の機能が備わっており、どちらかの機能を必ず有効にする必要があります。
Heartbeatは、デバイス側が定周期でメッセージを送信し、管理側はそのメッセージが届いているかを確認するという方法で、各デバイスの生存確認を行う機能です。逆に、管理側が各デバイスにメッセージを送信してデバイス側が管理側の生存確認を行うことも可能です。

対象機器のオブジェクトディクショナリ(以下、OD)の値を読み書きする機能で、主にデバイス間で設定値を参照・変更する場合に使用します。唯一クライアント／サーバの関係となる通信で、データを読み書きしたいタイミングで意図的に実行します。
読み出し時も書き込み時も、常にクライアント側からサーバ側に要求を掛けるため、通常どの機器もサーバ側は使用できる設定になっています。一方で、SDOを自発的に読み書きする必要が無いため、市販機器の中にはデフォルトでクライアント側設定をしていないものもあるようです。

各機器の測定データなど、主にリアルタイムデータを自動的に送受信する際に使用します。送信されたPDOのことをTPDO(Transmit-PDO)、受信したPDOのことをRPDO(Receive-PDO)と呼びます。特徴的な動作として、PDOではマッピングと呼ばれる機能を使用しています。マッピングとは、ODの所定のインデックス(マッピング先)の値を送信し、受信データを所定のインデックスに格納する機能です。つまり、TPDO時はマッピング先に送信したいデータを格納し、RPDOではマッピング先に受信データが格納されます。
規格上はTPDOとRPDOをそれぞれ512個ずつ実装できます(つまり512個のCOB-IDから同時に送受信できる)。しかし実際は、CiAの仕様としてデフォルトで用意されているCOB-IDはそれぞれ4つずつで、5つ目以降はCOB-IDのデフォルト値がなく、ユーザーがCOB-IDを決めて使用する形になっています。よって、4つ以下の実装が一般的です。

送受信のタイミングは以下の3種類あります。タイミングはTPDO/RPDOごとに設定できるため、TPDO1はイベントドリブン、TPDO2はSYNC同期といった設定が可能です。

• イベントドリブン (計測値が変化した場合やタイマーなど、任意のタイミングで実行)
• リモートリクエスト (RPDO側から送信をリクエストする、SDOに近い方法)
• SYNC同期 (詳細は後述)

ネットワーク同期を図る機能ですが、基本的にはPDO機能でのみ使用されます。
注意点として、PDOの送信時と受信時で影響が異なります。TPDOではPDOを送信するタイミングに関わりますが、RPDOではPDO受信タイミングではなく、受信後にマッピングするタイミングに関係します。

上記をまとめると、起動から全機能を使用できるようになるまでの流れは下図のようになります。

図 1. 全機能を使用できるようになるまでの流れ

デバイスにIDを付与後、NMT状態を「Operational」にすることを忘れがちです。
デバイス側はIDが付与されると、NMT状態が「Pre-Operational」になりますが、この時PDO機能は使用できません。ID付与後のPre-Operational状態では、ハートビートの送受信に成功し、SDO機能でのデータ送受信も可能になるため、準備完了と誤解しないよう注意が必要です。
TPDO機能を使用するためには、管理側からNMT状態通知を送ってデバイス側のNMT状態を「Operational」にする必要があります。

RPDOについて、CiAの仕様書に記載されているデフォルト値では動作しません。RPDOのCOB-IDを変更する必要があります。
RPDO設定はODのインデックス0x1400〜0x15FFで設定します。CiA301(※5)では、インデックス0x1400に設定するCOB-IDのデフォルト値は「0x200 + Node-ID」となっています。そのため、0x200 + 管理側のノードID、または、0x200 + デバイス側のノードIDを設定してしまいそうですが、どちらも間違いです。
ここには、“受信したいTPDOのCOB-ID” を ”RPDO領域のCOB-ID” に設定します。TPDOのCOB-IDは、デバイス側のODのTPDO設定(インデックス0x1800〜0x19FF)に設定しているCOB-IDの値です。RPDO領域は、管理側のODのRPDO設定(インデックス0x1400〜0x15FF)のうち、受信したい領域のCOB-IDを指します。

図 2. 管理側のRPDOのCOB-ID設定例

なぜRPDOのCOB-IDのデフォルト値が「0x200 + Node-ID」になっているのかは、CiA301に記載がありません。CANopenでは分野ごとに仕様書が作成されていますが、多くの分野でRPDOはデフォルト値「0x200 + Node-ID」通りか、そもそもRPDO設定自体に触れていません。CiA417-3-1(※5)のPDO設定では、TPDOもRPDOも「0x500 + Node-ID」と記載されているなど、使用できる設定を記載している仕様書もありますが例外的です。
推測ですが、仕様書はデバイス側目線で記載されており、デフォルトでは意図的にPDOを受信できないようにしているのではないかと思います(通常RPDOはデバイス側では必要ないため)。

特殊な仕様をお話しする前に、まずは通常のPDOの動作をご説明します。
デバイスがPDOを送受信するタイミングは、先述の通り3種類あります。このうちSYNCは、管理側がネットワーク同期を図ったタイミングで送受信する機能です。具体的には以下の順で動作します。一般的な同期通信に近い形のやり取りで、要求(SYNC)を出して応答(TPDO)を待ちます。

図 3. 通常のSYNCとPDOの挙動

1. 管理側がSYNCを送信(SYNCのCOB-IDはデフォルトでは0x80)
2. SYNCのCOB-IDが管理側と同じ、且つ、PDO送信タイミングがSYNC設定のデバイスがPDO送信
3. 管理側がPDOを受信するが、受信データをマッピングするのはPDO受信設定による SYNCで受信データをマッピングする設定の場合、受信直後ではなく、次のSYNC送信時にマッピングします。

SYNCのCOB-IDは各デバイス1つしか設定できませんが、プロデューサが複数ある場合、CANバス上では複数のSYNCタイミングを持つことが可能です。また、コンシューマのTPDO設定がSYNC受信時に送信する設定の場合、1つのSYNCに対してしか応答できません。
そのため、プロデューサが要求(SYNC)を出しても、応答(TPDO)を返す機器と応答しない機器があります。また、プロデューサ側がPDOを受信する場合、要求を出していないのに応答を受信することもできます。
文面だけでは分かりにくいと思いますので、まずは下図をご覧ください。

【前提】

• SYNCのCOB-ID仕様
32bitで表します。CiA301に記載されたデフォルト値は「0000 0080h or 8000 0080h」となっていますが間違いで、コンシューマ側なら0000 0080h、プロデューサ側なら4000 0080hが正しい設定です。
0〜28bit目はCOB-ID(デフォルトは0x80)
29bit目はIDが拡張IDならON、標準IDならOFF(通常0 固定)
30bit目はONならプロデューサ側でOFFならコンシューマ側
31bit目は「do not care」(未使用)


• プロデューサ側(PC)
プロデューサとしてSYNCを送信し、マッピングタイミングは受信直後とする。
PC1はSYNCのCOB-IDを0x80として一定間隔でSYNCを送信する。全てのデバイスのPDOを受信する。
PC2はSYNCのCOB-IDを0x90とするが、通常は送信しない。温度計測機器のPDOだけ受信し、温度異常だった場合はSYNCを送信し始める。温度が平常に戻ったらSYNC送信を停止する。


• コンシューマ側
温度計測機器はSYNCのCOB-IDは0x80とし、コンシューマとしてPDOを送信する。
速度計測機器はSYNCのCOB-IDは0x90とし、コンシューマとしてPDOを送信する。




図 4. CANバス上にSYNCタイミングを複数持つ場合の例

上図では、SYNCのCOB-IDが0x80(温度計測用)と0x90(速度計測用)で2つあります。計測中の温度が平常の場合は0x90を送信しない(つまり速度情報を確認しない)、温度異常があった場合に速度調節のため0x90を定期的に送信する(つまり速度情報を確認する)、というイメージです。
この場合コンシューマは、自身のSYNCのCOB-IDとは異なるCOB-IDを受信した場合、PDOを送信しません。例えば上図の温度計測機器(ノード2)は、自身のCOB-IDが0x80であるため、0x90受信時はPDOを送信せず、0x80受信直後にPDOを送信します。
一方でプロデューサのRPDOは、自身のSYNCのCOB-IDは関係せず、TPDOのCOB-IDを見て受信します。例えば上図のPC2は0x90のSYNCを送信していますが、0x80のSYNCに応答したTPDOを受信しています。

同期通信というと、通常は送信側と受信側でタイミングを合わせるイメージですが、CANopeｎのSYNCは一般的な同期通信とは異なります。プロデューサ側は、SYNCを送信していないのにPDOを受信することがあります。コンシューマ側は、受信したSYNCが自身と異なるCOB-IDであったり、SYNC応答ではなくイベントドリブンなどでPDOを送信する設定であったりすると、SYNCを受信してもPDO送信しないことがあります。