概要
産業分野のモータ制御アプリケーションには、堅牢性の高い通信プロトコルとインターフェースが必要です。では、複雑なタスクを実行するために複数のプロセッサの間で絶えず通信を実行する必要がある場合には、どのような技術が必要になるのでしょうか。その有力な候補となるのがCANopen®です。CANopenは、リアルタイムのデータ交換を可能にする通信プロトコルです。この技術は、構成可能性（コンフィギュアビリティ）、効率、信頼性が高いことを特徴とします。また、統合が容易であるといったことも理由となり、産業分野のモータ・アプリケーションにおいて大きな注目を集めています。本稿では、低消費電力のモータ制御アプリケーションでの活用という観点から、このCANopenについて詳しく解説します。
なぜCANopenが必要だったのか？
CANopenについての解説に先立ち、そのベースとなるCAN（Controller Area Network）に触れておきます。CANは、堅牢性が非常に高い通信プロトコルとインターフェースの規格です。その策定作業は、1983年からRobert Boschによって進められました。当時広く使用されていたRS-232などのシリアル通信ネットワークでは、複数のコントローラの間でリアルタイムの通信を円滑に実施することはできませんでした。そうした制約を解消するために生み出されたのがCANです。特に、自動車の業界は複数のセンサーを対象として連続的かつ同時にデータ伝送を実現できる技術を必要としていました。そのため、同業界ではCANの普及が進みました。CANでは、複数のノードが小さなメッセージを使用して相互に通信を実施します。その点が車載アプリケーションにとって非常に有用だったのです。
その堅牢性や長所が高く評価された結果、CANは様々な業界で使用されるようになりました。ただ、CANのプロトコルを使用して、様々なベンダー製の複数のデバイスを1つのシステムに統合するのは容易ではありませんでした。実際、独自のコーディング・ルールが存在することから、統合が不可能なケースもありました。この問題を解決するために、CAN in Automation（CiA）の国際的なユーザや製造業の協会が連携し、CANの上位層にあたるプロトコルが開発されました。それがCANopenです。
本稿では、このCANopenについて詳しく解説します。特に、モータ制御やモーション制御における活用方法に注目することにします。それに向けて、まずはCANopenのプロトコルのアーキテクチャについて解説します。その上で、CANopenを使用して多軸モータ・ドライバを制御する方法を紹介します。より具体的な解説を行うために、本稿ではADI Trinamic™の多軸モータ・コントローラ／ドライバ・モジュール「TMCM-6212」とステッパ・モータ「QSH4218-35-10-027」を例にとることにします。両者の間で行われるリアルタイム通信のログを分析することで、CANopenについての理解が深まるはずです。特に注目していただきたいのは、ネットワーク管理のステートとクライアント／サーバ・ベースのCANopenプロトコルについてです。また、通信時のログを解読し、モータ・ドライブのステータスを判断するための具体的な例も紹介することにします。
CANopenのアーキテクチャ
まずは、NMT（Network Management）やSDO（Service Data Object）など、CANopenのプロトコルの原理に関する要素について説明します。
NMT（Network Management）：CANopenの通信原理においては、NMTが非常に重要な役割を担います。CANopenに対応するすべてのデバイスは、このNMTの仕様に準拠しなければなりません。NMTはステート・マシンとして動作し、CANopenのフレームワーク内で稼働するアプリケーションを制御する役割を果たします。
NMTのステート・マシンのアーキテクチャ：図1は、NMTのステート・マシンについて説明するためのものです。このステート・マシンにおいては、以下に示す3つの異なるステートが主要な要素になります。
- 初期化ステート
- プリオペレーショナル・ステート
- オペレーショナル・ステート
図1. NMTのステート・マシン
CANopenにおいて、クライアントのノードは極めて重要な役割を担います。その役割とは、様々なオペレーショナル・ステートにわたり、関連するサーバのノードが実行している通信の状態を監視するというものです。これは、NMTのメカニズムを実装することで実現されます。クライアントのノードは、サーバのノードの通信の完全性を評価します。それには、ハートビートまたはノード・ガーディングという2つの方法を使用できます。TMCM-6212の場合、ハートビートを利用することによって適切な通信であるか否かを確認します。各ノードは、ユーザがミリ秒単位で設定可能な繰り返し時間でハートビートの信号を発信します。それには、1017hのオブジェクトが使用されます。このような仕組みにより、すべてのノードがアクティブであり、通信がアライブの状態であることが確認されます。
表1は、通信時の様々なステートで使用されるすべてのオブジェクトの組み合わせについてまとめたものです。CANopenを利用するデバイスは、電源の投入後またはリセット後に初期化のステートに移行します。その上でブートアップのメッセージを生成します。その後、デバイスはプリオペレーショナル・ステートに遷移し、所望の動作に備えます。同ステートでは、ネットワーク内のすべてのノードがSDO、ハートビート／ノード・ガーディング、エマージェンシ、時間／同期に関連するすべてのオブジェクトを転送できる状態になります。一方、オペレーショナル・ステートでは、プリオペレーショナル・ステートで使用可能なすべてのオブジェクトに加え、PDO（Process Data Object）のマッピングを実施できる状態になります。停止ステートでは、デバイスはすべてのSDOとPDOの通信をディスエーブルとし、NMTのコマンドの実行だけを許可します。
| 初期化 | プリオペレーショナル | オペレーショナル | 停止 | |
| ブートアップ | • | |||
| SDO | • | • | ||
| エマージェンシ | • | • | ||
| 同期／時間 | • | • | ||
| ハートビート／ノード・ガーディング | • | • | • | |
| PDO | • |
SDO（Service Data Object）：SDOの通信プロトコルは、主にNMTのステート・マシンのプリオペレーショナル・ステートで使用されます。また、SDOはクライアント／サーバ構成で動作します。その際、クライアントは、接続されているすべてのサーバ（ノード）のオブジェクト・ディクショナリで使用可能なすべてのオブジェクトにアクセスすることができます。このプロトコルにおいて、クライアントはサーバとの読み出し／書き込みのトランザクションを開始する役割を担います。一方、サーバはタスクの完了をアクノレッジします。このプロセスにより、SDOのすべてのトランザクションのアクノレッジが確実に実行されることになります。
図2は、マルチノードのネットワークにおけるSDOのプロトコルについて示したものです。ご覧のように、クライアントとサーバをベースとして構成されています。各ノードには、クライアントと通信可能なチャンネルが割り当てられます。その場合、ADITrinamicの6軸のステッパ・モータ・ドライバ／コントローラであるTMCM-6212はサーバとして機能します。一方、クライアントとして機能するのは接続されたPCです。このクライアントは、特定のノード（図2の場合はノード1）との読み出し／書き込みのトランザクションを開始します。SDOクライアントのメッセージはすべてのノードが受信します。ただ、対象となっているノードだけがレスポンスし、他のサーバはクライアントのリクエストを無視します。
図2. マルチノードのSDOの構成
SDOのデータグラム
図3は、SDOのデータグラムの全体的な構造を示したものです。そのヘッダにあるのはCOB-ID（Connection Object ID）です。COB-IDとは、読み出しや書き込みの機能など、特定のタスクに割り当てられる一意的な番号のことです。SDOの通信では、2つのCOB-IDを使用します。1つ目のCOB-IDは、「機能コード + ノードのID」の形で表されます。具体的には、「600h + ノードのID」の形になります。これは、クライアントがアップロード／ダウンロードのリクエストを行うためのものです。2つ目のCOB-IDは、サーバのレスポンスに使用されます。具体的には、「580h + ノードのID」の形になります。
SDOのメッセージにおいて、最初のバイトは指定子（Specifier）と呼ばれます。これは、メッセージの性質を判断する上で重要な役割を果たします。具体的には、クライアントがデータの書き込み（ダウンロード）を行おうとしているのか、読み出し（アップロード）を行おうとしているのかを表します。また、中止メッセージによってトランザクションにエラーがあることも示します。指定子の1バイトに含まれる8ビットのデータは、図3（下）に示したような意味を持ちます。上位3ビット（ビット7 ～ ビット5）はCCS（Client Command Specifier）と呼ばれます。これは、メッセージの性質に関する重要な情報を提供します。CCSには、クライアントの動作に依存した様々な構成があり得ます。クライアントの動作には、読み出し、書き込み、セグメント化による転送（Segmented Transfer）／優先転送（Expedited Transfers）、トランザクションのエラーなどがあります。サーバのレスポンスでは、指定子3ビットのSCS（Sever Command Specifier）によってトランザクションの成否が決定されます。表2は、様々な動作に対するCCSとSCSの組み合わせについてまとめたものです。図3（下）に示したビット4は、4バイトを超えるデータを転送する際に使用されるトグル・ビットです。ビット3とビット2にはデータは含まれておらず、ビット1、ビット0に値が設定されている場合だけ有効になります。ビット1は、SDOのチャンネルを介して転送されるメッセージの種類を決定します。具体的には、セグメント化による転送なのか優先転送なのかを表します。図3に示したとおり、SDOのデータグラムにおける最後の4バイトは、転送したいデータ専用に使用されます。データが4バイトを超える場合には、セグメント化を使用した送信が実行されます。一方、SDOのデータグラムに完全なデータが含まれている場合には、優先転送であると見なされます。ビット1がハイの場合には優先転送となり、ローの場合にはセグメント化による転送になります。セグメント化による転送では、データはパケット単位で扱われます。サーバは、クライアントからの最初の読み出し／書き込みのリクエストに対し、データ・フィールドでデータのサイズを提示する形でレスポンスします。その後、ビット4（トグル・ビット）の値は、クライアントに各データのパケットが転送されるたびにトグルするようになります。最後のビット0に値が設定されている場合、それはビット3、ビット2のデータのサイズを表します。
図3. SDOのデータグラム
| 動作 | CCS | SCS |
| SDOのダウンロード | 1 | 3 |
| SDOのアップロード | 2 | 2 |
| セグメント化によるSDOのダウンロード | 0 | 1 |
| セグメント化によるSDOのアップロード | 3 | 0 |
図3に示したとおり、SDOのデータグラムのバイト2 ～ 3、バイト4は、それぞれインデックス・バイトとサブインデックス・バイトです。これらは、デバイスのオブジェクト・ディクショナリで使用可能なすべてのオブジェクトにアクセスするために使用されます。オブジェクト・ディクショナリには、すべてのデバイスのパラメータが含まれています。それらにより、ユーザはリアルタイム・アプリケーションの要件に基づいてデバイスの機能を構成することができます。デバイスのプロファイルに関するこのようなコンセプトにより、様々なデバイスに対して標準化された動作がもたらされます。つまり、ドライブのような制御デバイスなのか単純なI/Oコンポーネントなのかといったデバイスの種類を問わないということです。先述したように、SDOのデータグラムの最後の4バイトは、SDOのレイヤを介して転送するデータ専用のものとして使用されます。
エラーが発生した場合、SDOの送信は中止されます。対象とするデバイスのマニュアルには、エラー・コードの説明が記載されているはずです。それを参照することで、送信が停止された理由を特定することができます。この例の場合、CCSのビットの値は4になります。そして、インデックスとサブインデックスにより、送信中に影響を受けるデバイスのパラメータが特定されます。最後の4バイトはエラー・コードを表します。
リアルタイム通信の解析
最後に、リアルタイム通信に関するログを分析することにより、SDOのデータグラムについて確認する方法を紹介します。ここでは、マシンがプリオペレーショナル・ステートにある場合を例にとります。繰り返しになりますが、ADI TrinamicのTMCM-6212は、6軸のステッパ・モータ・ドライバ／コントローラです。これは、ステッパ・モータであるQSH4218-35-10-027 [5]と組み合わせて使用します。そのセットアップでは、モータの最大電流（2003hのオブジェクト）として200という値が設定されています。クライントとサーバの間で行われるアップロード／ダウンロードのトランザクションについては、図4のようにCANopen向けの統合開発環境（IDE）を使うことで確認できます。この画面は、対象とするセットアップのソフトウェア・インターフェースです。そのログ用のウィンドウを見ると、メッセージに関する説明が強調表示されています。
図4. CANopen向けの統合開発環境（IDE）
【ケース1】クライアントとサーバの間のダウンロード動作
まずは、クライアントとサーバの間のダウンロード動作について確認してみましょう。
クライアントによる開始：0x601: 2f 03 20 c8 00 00 00（図5）
図5. クライアントによるダウンロード開始のリクエスト
サーバによるレスポンス：0x581: 60 03 20 00 00 00 00（図6）
図6. サーバによるダウンロードのレスポンス
図6では、CCSビットとSCSビットの組み合わせに注目してください。表2に示したように、これらはクライアントからの書き込み動作が成功し、サーバがレスポンスしたことを表しています。
【ケース2】クライアントとサーバの間のアップロード動作
続いて、クライアントとサーバの間のアップロード動作について確認してみましょう。
クライアントによる開始：0x601: 40 03 20 00 00 00 00（図7）
図7. クライアントによるアップロード開始のリクエスト
サーバによるレスポンス：0x581: 4f 03 20 00 c8 00 00 00（図8）
図8. サーバによるアップロードのレスポンス
まとめ
CCSビットとSCSビットの組み合わせは、クライアントとサーバの間のアップロード動作が成功したことを表します。本稿で紹介した例は、デバイスのオブジェクト・ディクショナリに含まれる他のオブジェクトにも適用できます。それにより、マシンのステートに関する知見が得られます。本稿の目的の1つは、ユーザが通信に関するログを解読し、ドライブのステータスを監視できるようにすることにありました。本稿の例を参考にすれば、エラーのトラブルシュートをリアルタイムに実施することができます。また、CANopenに関するADI Trinamicの高度な機能をより効果的に活用することが可能になります。本稿で紹介したように、アナログ・デバイセズは、CANopenのプロトコルに対応した製品を提供しています。それらを採用すれば、お客様は自社のPLC（Programmable Logic Controller）とADI Trinamicモジュールと統合するための柔軟性が得られます。加えて、複数のベンダーの製品を採用したシステムの開発が可能になります。CANopenのインターフェースは、ラボラトリ・オートメーション、ロボット、リキッド・ハンドリング、半導体製造といった複雑なアプリケーションに取り組むお客様にとって特に有用です。本稿の続編となる記事では、CANopenのプロトコルのPDOについて詳細に説明することにします。その上で、モータ制御アプリケーションに向けたTMCM-6212のより高度な機能について解説します。
参考資料
Olaf Pfeiffer、Andrew Ayre、Christian Keydel「Embedded Networking with CAN and CANopen（CAN/CANopenを利用する組み込みネットワーク）」Copperhill Technologies Corporation、 2008年
「TMCM-6212 CANopen Firmware Manual（TMCM-6212用のCANopen対応ファームウェア・マニュアル）」Trinamic Motion Control、2018年
