JP6481248B1 - モーション制御プログラム、モーション制御方法及びモーション制御装置 - Google Patents

Abstract

非リアルタイムＯＳ上の受付部は、複数の制御対象装置を制御するユーザ作成プログラムから制御指令を受け付け、受け付けた制御指令の内容を示す制御指令情報を制御部に通知し、リアルタイムＯＳ上の制御部は、受付部から通知された制御指令情報に基づいて、制御対象装置ごとの補間指令をモーション制御サイクルごとに繰り返し生成し、生成した補間指令を、制御対象装置ごとに確保されるメモリ領域に格納し、リアルタイムＯＳ上の通信モジュール部は、制御対象装置ごとに確保されたメモリ領域から補間指令を取得し、取得した補間指令を、制御部が認識可能な所定の信号フォーマットから、複数の制御対象装置の各々が認識可能な通信インターフェース規格の信号フォーマットに変換して送信するようにコンピュータを機能させる、モーション制御プログラムを提供する。

Description

本発明は、モーション制御プログラム、モーション制御方法及びモーション制御装置に関する。

ロボット及びＦＡ（ファクトリーオートメーション）等の分野では、ベルトコンベアの位置やアームの位置などを、意図した通りに動作させることが求められる。このような動作をさせるためには、サーボモータやステッピングモータ等の複数の制御対象装置を、高精度に同期させながら制御する必要がある。このように、複数の制御対象装置を高精度に同期させながら制御する装置は、モーションコントローラやモーション制御装置等と呼ばれる。例えば特許文献１には、安価で簡単な低速通信を利用しつつ滑らかな制御を実現可能なモーション制御用指令システムが開示されている。

特開２０１０−１７０４３５号公報

一般的に、モーションコントローラは、高精度なリアルタイム性能を要求されることから、モーション制御に特化した専用のハードウェアとして提供される。専用のハードウェアとして提供されることで、必要なリアルタイム性能を確保することができる反面、価格が高く、制御対象装置やその通信プロトコルに依存した構成となっており、汎用性に欠けるというデメリットがある。

一方、汎用的な情報処理装置であるパーソナルコンピュータは、専用のハードウェアであるモーションコントローラと比較して安価であるというメリットを有している。また、ユーザが使い慣れたデザインのユーザインタフェースを提供することが可能というメリットもある。

ここで、現在、パーソナルコンピュータのＯＳ（Operating System）として広く利用されている非リアルタイムＯＳ（例えばＷｉｎｄｏｗｓ（登録商標））をインストールしたパーソナルコンピュータ上にインストール可能なリアルタイムＯＳが提供されている。そのため、非リアルタイムＯＳ及びリアルタイムＯＳの両方をインストールしたパーソナルコンピュータをモーションコントローラとして利用することができれば、様々なメリットを享受できると考えられる。また、１つのパーソナルコンピュータ上に、通信プロトコルが異なる様々な制御対象機器を接続して制御することができれば、更にコスト軽減が図られると考えられる。

しかしながら、現在、非リアルタイムＯＳ及びリアルタイムＯＳの両方をインストールした１つのパーソナルコンピュータに接続された、通信プロトコルが異なる複数の制御対象機器を制御することが可能な技術は知られていない。

そこで、本発明は、非リアルタイムＯＳ及びリアルタイムＯＳがインストールされたコンピュータに、通信プロトコルが異なる複数の制御対象機器を接続して制御することが可能な技術を提供することを目的とする。

本発明の一態様に係るモーション制御プログラムは、非リアルタイムＯＳ及びリアルタイムＯＳがインストールされ、複数の制御対象装置をモーション制御するためのコンピュータで実行されるモーション制御プログラムであって、コンピュータを、非リアルタイムＯＳ上で動作する受付部と、リアルタイムＯＳ上で動作する制御部と、リアルタイムＯＳ上で動作する複数の通信モジュール部と、として機能させ、受付部は、複数の制御対象装置を制御するユーザ作成プログラムから、複数の制御対象装置の各々が複数のモーション制御サイクルに渡って行うべき動作を示す制御指令を受け付け、受け付けた制御指令の内容を示す制御指令情報を制御部に通知し、制御部は、受付部から通知された制御指令情報に基づいて、複数の制御対象装置の各々に対してモーション制御サイクルごとに実行させるべき動作を示す、制御対象装置ごとの補間指令をモーション制御サイクルごとに繰り返し生成し、生成した補間指令を、制御対象装置ごとに確保されるメモリ領域に格納し、通信モジュール部は、制御対象装置ごとに確保されたメモリ領域から補間指令を取得し、取得した補間指令を、制御部が認識可能な所定の信号フォーマットから、複数の制御対象装置の各々が認識可能な通信インターフェース規格の信号フォーマットに変換して送信する。

本発明によれば、非リアルタイムＯＳ及びリアルタイムＯＳがインストールされたコンピュータに、通信プロトコルが異なる複数の制御対象機器を接続して制御することが可能な技術を提供することができる。

実施形態に係るモーション制御システムのシステム構成例を示す図である。 モーション制御装置の概要を説明するための図である。 ＡＰＩチャネル及び状態チャネルの一例を説明するための図である。 モーション制御装置のハードウェア構成例を示す図である。 モーション制御装置の機能構成例を示す図である。 デバイス作成処理の一例を説明するための図である。 デバイス作成処理が行われる際に生成される各種管理情報の一例を説明するための図である。 デバイス作成処理の一例を説明するための図である。 デバイス作成処理が行われる際に生成される各種管理情報の一例を説明するための図である。 モーション制御装置が行うモーション制御処理の一例を示す図である。 モーション制御装置が行うモーション制御処理の一例を示す図である。 制御指令モジュールが行う処理手順の一例を示すフローチャートである。 制御指示部がクラッシュした場合の処理手順の一例を示す図である。 マッピング情報の一例を示す図である。 プロトコル変換処理の処理手順の一例を説明するための図である。

添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

＜システム構成＞
図１は、実施形態に係るモーション制御システムのシステム構成例を示す図である。モーション制御システム１は、モーション制御装置１０と、複数の制御対象装置２０とを含む。なお、モーション制御システム１には、必ずしも複数の制御対象装置２０が含まれている必要はなく、１つの制御対象装置２０のみが含まれる構成としてもよい。

制御対象装置２０は、具体的には、サーボモータ（サーボドライバを含む）及びステッピングモータ等のモータである。モーション制御装置１０は、複数の制御対象装置２０を同期させながら制御することで、ベルトコンベアの回転制御、多軸ロボットの軸制御、回転テーブルの位置決め制御などを行う。１つの制御対象装置２０は１つの「軸」を制御する。例えば、６軸ロボットとは、モータである制御対象装置２０を６個備えたロボットを意味する。

制御対象装置２０に制御指令を与えるための通信インターフェース規格として、例えば、ＥｔｈｅｒＣＡＴ（登録商標）、ＲＴＥＸ（登録商標）（Realtime Express（登録商標））及びＭＥＣＨＡＴＲＯＬＩＮＫ（登録商標）等が知られている。モーション制御装置１０には、異なる通信インターフェース規格の制御対象装置２０を混在させて接続することが可能である。

モーション制御装置１０は、非リアルタイムＯＳ及びリアルタイムＯＳがインストールされた汎用的な情報処理装置である。非リアルタイムＯＳの具体例として、例えば、Ｗｉｎｄｏｗｓ（登録商標）、ｍａｃＯＳ（登録商標）等が挙げられる。また、リアルタイムＯＳは、例えば、ＲＴＸ（Real Time Extension）、ＲＴＨ（Real Time Hypervisor）等が挙げられる。また、汎用的な情報処理装置の具体例としては、例えば、ＰＣ（パーソナルコンピュータ）、ノート型ＰＣ、サーバ等が挙げられる。

ここで、サーボモータやステッピングモータの制御に用いられる従来のモーションコントローラは、高精度なリアルタイム性能を確保するために、モーション制御に特化した専用のハードウェアとして提供されることが一般的である。また、モーション制御の内容をユーザがプログラミングするためのＧＵＩ（Graphical User Interface）を提供するプログラムについては、モーションコントローラに接続されたパーソナルコンピュータにより提供されることが一般的である。

一方で、本実施形態に係るモーション制御装置１０は、モーション制御の内容をユーザがプログラミングするためのＧＵＩを非リアルタイムＯＳ上で提供し、プログラミングされた内容に基づいて制御対象装置２０を実際に制御する処理をリアルタイムＯＳ上で行う。これにより、専用のハードウェアによるモーションコントローラを利用した場合と同様の高精度なモーション制御を汎用的な情報処理装置のみで実現する。

＜モーション制御装置の概要＞
図２は、モーション制御装置１０の概要を説明するための図である。制御指示部１１０は、非リアルタイムＯＳ１００上で動作し、制御対象装置２０が複数のモーション制御サイクルに渡って行うべき動作を示す制御指令を１又は複数発行することで、制御対象装置２０を制御する。制御指示部１１０は、モーション制御システム１を用いるユーザが作成するプログラムを含んでおり、当該プログラムは、制御対象装置２０に対して発行する制御指令、制御指令を発行する順序及びタイミング等が、所定のプログラミング言語を用いて記述されている。ユーザが作成するプログラムの具体例としては、例えば、ＦＡを実現するためのベルトコンベア及びアーム等の制御を行うプログラム、ロボット操作を行うプログラム等が挙げられる。非リアルタイムＯＳ１００では、複数の制御指示部１１０を動作させることが可能である。

制御指令は、制御指令の識別子（ＩＤ等）と指令値とを含む。制御指令の具体例としては、例えば、ＰＴＰ（Point to Point）動作（指定した地点に移動させる動作）、ＪＯＧ動作（指定した速度でモータを動作）、直線補間によるＰＴＰ動作、円弧補間によるＰＴＰ動作、加速時間を指定するＪＯＧ動作、行動時間を指定するＪＯＧ動作等が挙げられる。制御指令の識別子は、制御指令の内容を具体的に特定する情報（例えば円弧補間によるＰＴＰ動作であることを示す識別子等）である。指令値は、動作目標を具体的に示すパラメータであり、例えば円弧補間によるＰＴＰ動作の場合、移動先の地点を示す値、移動速度、回転半径等である。制御指示部１１０で発行された制御指令は、後述するチャネルを用いて連携部３１０に通知される。

制御指示部１１０での制御指令の発行は、ユーザが作成するプログラムにおいてＡＰＩ（Application Programming Interface）関数を呼び出すことで行われる。また、指令値の指定は、ＡＰＩ関数の引数（argument）に値を設定することで行われる。ＡＰＩ関数は、制御指令ごとに１つ用意されており、例えばＰＴＰ動作に対しては「startpos()」というＡＰＩ関数が用意されている。本実施形態では、制御指示部１１０で呼び出されたＡＰＩ関数及び当該ＡＰＩ関数に設定された引数を示す情報を、「ＡＰＩ情報」と言う。なお、本実施形態では、ＡＰＩ情報を、「制御指令情報」と呼んでもよい。

連携部３１０は、制御指示部１１０から通知されたＡＰＩ情報を一時的に蓄積するためのＦＩＦＯキュー（以下、「ＡＰＩバッファ」と言う。）を備えている。連携部３１０は、制御指示部１１０から受け取った複数のＡＰＩ情報を一旦ＡＰＩバッファ３４０に蓄積する。また、連携部３１０は、ＡＰＩバッファ３４０からＡＰＩ情報を１つずつ取り出して定周期処理部３６０に渡す。つまり、連携部３１０は、キューを利用して定周期処理部３６０との間でＡＰＩ情報の受渡を行う。

定周期処理部３６０は、リアルタイムＯＳ３００上で動作し、連携部３１０から通知された制御指令に基づいて、モーション制御サイクルごとに制御対象装置２０に実行させる動作を示す補間指令を算出する。また、定周期処理部３６０は、算出した補間指令をモーション制御サイクルに従って制御対象装置２０に送信することで、制御対象装置２０をモーション制御させる。１つのモーション制御サイクルは、例えば０．５ｍｓや１ｍｓといった単位である。制御対象装置２０は、モーション制御サイクルごとに通知される補間指令に従って動作することで、最終的に、制御指令により指示される動作目標を達成する。

また、定周期処理部３６０は、定周期処理部３６０が認識可能な信号フォーマット（以下、「共通信号フォーマット」と言う。）と、制御対象装置２０が認識可能な通信インターフェース規格に対応する信号フォーマットとの間でプロトコル変換を行う。なお、共通信号フォーマットは、「所定の信号フォーマット」の一例である。

制御指示部１１０及び連携部３１０は、制御指示部１１０及び連携部３１０が共通に書き込み及び読み出し可能なメモリ領域（以下、「チャネル」と言う。）を介して各種情報の受け渡しを行う。チャネルには、操作チャネル、ＡＰＩチャネル及び状態チャネルが存在する。

「操作チャネル」は、制御指示部１１０及び連携部３１０が制御情報を送受信するために用いるチャネルである。操作チャネルは、全ての制御指示部１１０が共通に使用するチャネルであり、制御指示部１１０が１つ以上動作している間、１つの操作チャネルがモーション制御装置１０内に存在する。本実施形態では、操作チャネルを、「操作用チャネル」と呼んでもよい。

「ＡＰＩチャネル」は、ＡＰＩ情報を制御指示部１１０から連携部３１０に伝えるために使用するチャネルである。ＡＰＩチャネルは、制御指示部１１０ごとに少なくとも１つ存在する。本実施形態では、ＡＰＩチャネルを、「制御指令用チャネル」と呼んでもよい。

「状態チャネル」は、制御対象装置２０からのフィードバック情報を格納するチャネルである。状態チャネルは、複数の制御指示部１１０が共通に使用するチャネルであり、モーション制御装置１０内には１又は複数の状態チャネルが存在する。フィードバック情報とは、制御対象装置２０の状態（動作状態）を示す情報であり、制御対象装置２０が内部に備えるセンサ又は制御対象装置２０に接続されたセンサ等により測定される。フィードバック情報には、例えば、軸の位置、軸の回転速度、アームの位置、ベルトコンベアの位置、制御対象装置２０の温度など、あらゆる情報が含まれる。制御指示部１１０は、状態チャネルを参照することで、制御対象装置２０の動作状態を把握することができる。

本実施形態では、１つの制御指示部１１０に関連付けられたＡＰＩチャネル、状態チャネルなどをまとめて「デバイス」と呼ぶ。後述するように、ＡＰＩチャネルは、制御指示部１１０からデバイス作成要求があった際に、その制御指示部１１０専用のチャネルとしてメモリ上に確保される。一方、状態チャネルは、最初にその状態チャネルを利用する制御指示部１１０からデバイス作成要求があった際にメモリ上に確保され、確保された後は他の制御指示部１１０からも利用可能となる。

ここで、ＡＰＩチャネル及び状態チャネルの具体例を説明する。図３は、ＡＰＩチャネル及び状態チャネルの一例を説明するための図である。図３（ａ）に、ＡＰＩチャネルに格納されるデータ例を示す。「デバイス識別子」には、生成されたデバイスを一意に識別するためのデバイス識別子が格納される。「モジュール識別子」については後述する。「制御指令識別子」には、制御指令の内容（例えば、位置決め（ＰＴＰ）、ＪＯＧ動作、直線補間、円弧補間等）を特定する情報が格納される。制御指令識別子は、制御指令の種別を一意に示す識別子であってもよいし、ＡＰＩ関数を一意に示す識別子であってもよい。

「ＡＰＩバッファ識別子」には、ＡＰＩバッファ３４０を一意に特定するＡＰＩバッファ識別子が格納される。「記録中フラグ」については後述する。「指令値」には、軸ごとの指令値が格納される。例えば制御指令識別子がＰＴＰ動作の場合、指令値には、移動先の位置を示す値等が軸ごとに格納される。「生存報告」については後述する。

図３（ｂ）に、状態チャネルに格納されるデータ例を示す。「モジュール識別子」については後述する。「エラーコード」には、何らかのエラーが生じたことでフィードバック情報を状態チャネルに格納できない場合に、発生したエラーの内容を示すエラーコードが格納される。「フィードバック情報」には、制御対象装置２０から取得されたフィードバック情報が、制御対象装置２０ごと（軸ごと）に格納される。

＜ハードウェア構成＞
図４は、モーション制御装置１０のハードウェア構成例を示す図である。モーション制御装置１０は、ＣＰＵ（Central Processing Unit）１１、メモリ１２、ＨＤＤ（HardDisk）やＳＳＤ（Solid State Drive）等の記憶装置１３、有線又は無線通信を行う通信ＩＦ（Interface）１４、入力操作を受け付ける入力デバイス１５、及び情報の出力を行う出力デバイス１６を有する。入力デバイス１５は、例えば、キーボード、タッチパネル、マウス及び／又はマイク等である。出力デバイス１６は、例えば、ディスプレイ及び／又はスピーカ等である。

＜機能構成＞
図５は、モーション制御装置１０の機能構成例を示す図である。共有メモリ２００は、非リアルタイムＯＳ１００側の各機能部とリアルタイムＯＳ３００側の各機能部とから共通に参照及び書込み可能なメモリである。共有メモリ２００には、操作チャネル、ＡＰＩチャネル及び状態チャネルに対応するメモリ領域が確保される。制御指示部１１０及び連携部３１０は、当該メモリ領域にデータを書き込んだり、当該メモリ領域からデータを読み出したりすることでデータの送受信を行う。

（非リアルタイムＯＳ）
非リアルタイムＯＳ１００上では、１以上の制御指示部１１０、及び１以上のデバイス管理部１２０が動作する。

制御指示部１１０は、制御指令を発行することで、制御対象装置２０をモーション制御する機能を有する。制御指示部１１０には、ユーザ作成プログラム１１１、指令受付部１１２、及びＩＦ（Ｎ側）部１１３が含まれる。

ユーザ作成プログラム１１１は、モーション制御装置１０を利用するユーザが作成するプログラムである。ユーザは、ユーザ作成プログラム１１１において、非リアルタイムＯＳ１００側に用意されている多様なＡＰＩ関数を呼び出すことで、任意のモーション制御を実現するプログラムを作成することができる。なお、ユーザ作成プログラム１１１は予めモーション制御装置１０にプリセットされていてもよい。すなわち、本実施形態において、ユーザ作成プログラム１１１は、必ずしもユーザが作成したプログラムに限定されない。

指令受付部１１２は、ユーザ作成プログラム１１１にＡＰＩ関数を提供する。具体的には、指令受付部１１２は、ユーザ作成プログラム１１１にて呼び出されたＡＰＩ関数についてのＡＰＩ情報を、ＡＰＩチャネルに格納するようにＩＦ（Ｎ側）部１１３に指示する機能を有する。

なお、指令受付部１１２は、制御指令ライブラリ１１２１Ａ〜１１２１Ｚ（以下、制御指令ライブラリＡ〜Ｚを特に区別しない場合は、単に制御指令ライブラリ１１２１と言う。）及び通信ライブラリ１１２２Ａ〜１１２２Ｚ（以下、通信ライブラリＡ〜Ｚを特に区別しない場合は、単に通信ライブラリ１１２２と言う。）のうち、ユーザ作成プログラム１１１が実際にプログラム内で参照するライブラリに含まれるＡＰＩ関数を提供する。

制御指令ライブラリ１１２１Ａ〜１１２１Ｚは、それぞれ、制御対象装置２０をモーション制御する処理を行うための複数のＡＰＩ関数のロードモジュール（実行ファイル）をひとまとめにしたライブラリである。また、通信ライブラリ１１２２Ａ〜１１２２Ｚは、モーション制御装置１０が制御対象装置２０との間で行う通信に関する処理を行うための複数のＡＰＩ関数のロードモジュール（実行ファイル）をひとまとめにしたライブラリである。

なお、当該通信に関する処理とは、例えば、断線などで切断された通信路が復帰した際に、通信を再開するタイミングをユーザ作成プログラム１１１から指定する処理、モーション制御装置１０及び制御対象装置２０の間の通信路におけるパケットロスの監視等である。通信ライブラリ１１２２が提供するＡＰＩ関数が呼ばれた場合も、制御指令ライブラリ１１２１が提供するＡＰＩ関数が呼ばれた場合と同様、ＡＰＩ情報が連携部３１０を介して定周期処理部３６０に通知される。

ＩＦ（Ｎ側）部１１３は、操作チャネル及びＡＰＩチャネルにデータを格納する機能、操作チャネル、ＡＰＩチャネル及び状態チャネルからデータを取得する機能、及び、操作チャネル、ＡＰＩチャネル及び状態チャネルを管理する機能を有する。

なお、指令受付部１１２及びＩＦ（Ｎ側）部１１３は、ユーザ作成プログラム１１１が呼び出したＡＰＩ関数を受け付けてＡＰＩチャネルに格納する役割を担うことから、指令受付部１１２及びＩＦ（Ｎ側）部１１３を、まとめて「受付部」と呼んでもよい。

デバイス管理部１２０は、制御指示部１１０の生死確認を行う。また、デバイス管理部１２０は、ＡＰＩバッファ３４０へのＡＰＩ情報の格納に関する各種の処理等を行う。デバイス管理部１２０は、制御指示部１１０がデバイスを作成する際に起動される。なお、デバイスには、より詳細には、ＡＰＩチャネル及び状態チャネルに加えて、デバイス管理部１２０も含まれる。

（リアルタイムＯＳ）
リアルタイムＯＳ３００上では、連携部３１０及び定周期処理部３６０が動作する。

連携部３１０は、制御指示部１１０で行われる処理と、定周期処理部３６０で行われる処理とを連携するための機能部であり、制御指示部１１０から受けたＡＰＩ情報を定周期処理部３６０に伝える機能を有する。連携部３１０は、ＦＩＦＯキューとして機能するＡＰＩバッファ３４０を備えており、制御指示部１１０からＡＰＩチャネルを介して伝えられる制御指令（ＡＰＩ情報）をＡＰＩバッファ３４０に蓄積する。また、連携部３１０は、ＡＰＩバッファ３４０に蓄積されたＡＰＩ情報を取り出して定周期処理部３６０に渡す。また、連携部３１０は、操作チャネル、ＡＰＩチャネル及び状態チャネルの状態管理（生成、維持及び破棄）を行う。

連携部３１０には、上述の各機能を実行する機能部として、メイン処理部３２０、ＡＰＩ実行要求処理部３３０、ＡＰＩバッファ３４０及び指令実行処理部３５０が含まれる。メイン処理部３２０には、更に、ＩＦ（Ｒ側）部３２１が含まれる。

メイン処理部３２０は、制御指示部１１０からの要求を受けた場合に、リアルタイムＯＳのメモリ領域にＡＰＩバッファ３４０を生成する機能を有する。本実施形態では、メイン処理部３２０を「キュー生成部」と呼んでもよい。

ＩＦ（Ｒ側）部３２１は、操作チャネル、ＡＰＩチャネル及び状態チャネルの作成（共有メモリ２００へのメモリ領域割り当て）、割り当てたメモリ領域の管理、及び、ＡＰＩチャネル及び状態チャネルの破棄（共有メモリ２００の解放）に関する各種の処理を行う。本実施形態では、ＩＦ（Ｒ側）部３２１を、「チャネル管理部」と呼んでもよい。或いは、ＩＦ（Ｒ側）部３２１は連携部３１０の一部であることから、連携部３１０を「チャネル管理部」と呼んでもよい。

具体的には、ＩＦ（Ｒ側）部３２１は、リアルタイムＯＳ３００の指示によりＩＦ（Ｒ側）部３２１自身が起動した場合に、操作チャネルを共有メモリ２００に生成する。また、ＩＦ（Ｒ側）部３２１は、制御指示部１１０（より詳細にはＩＦ（Ｎ側）部１１３）からの要求を受けてＡＰＩチャネルを生成する。また、ＩＦ（Ｒ側）部３２１は、制御指示部１１０（より詳細にはＩＦ（Ｎ側）部１１３）からの指示を受けて状態チャネルを生成する。

ＡＰＩ実行要求処理部３３０は、ＡＰＩチャネルからＡＰＩ情報を取得し、取得したＡＰＩ情報をＡＰＩバッファ３４０に格納する。本実施形態では、ＡＰＩ実行要求処理部３３０を、「格納部」と呼んでもよい。なお、連携部３１０内では、前述した“デバイス”ごとに１つのＡＰＩ実行要求処理部３３０が動作する。例えば、非リアルタイムＯＳ１１０内で４つの制御指示部１１０がそれぞれデバイスを１つずつ生成した場合、連携部３１０内では、各デバイスに対応するＡＰＩ実行要求処理部３３０が４つ動作することになる。本実施形態では、「デバイス」には、ＡＰＩチャネル、状態チャネル及びデバイス管理部１２０に加えて、ＡＰＩ実行要求処理部３３０も含まれることとしてもよい。

指令実行処理部３５０は、ＡＰＩバッファ３４０に格納されているＡＰＩ情報を取得し、取得したＡＰＩ情報を制御指令モジュール３７０に渡す。本実施形態では、指令実行処理部３５０を、「指令処理部」と呼んでもよい。指令実行処理部３５０は、ＡＰＩ実行要求処理部３３０のようにデバイス単位で並列に動作するのではなく、予め設定ファイルで指定された数の指令実行処理部３５０が連携部３１０の中で並列に動作する。

定周期処理部３６０は、ＡＰＩ情報（制御指令情報）に基づいて、制御対象装置２０に対してモーション制御サイクルごとに実行させるべき動作を示す補間指令をモーション制御サイクルごとに送信することで、制御対象装置２０をモーション制御する機能を有する。また、定周期処理部３６０には、更に、制御指令モジュール３７０、ＩＦ部３８０及び通信モジュール３９０が含まれる。

制御指令モジュール３７０Ａ〜３７０Ｚ（以下、制御指令モジュールＡ〜Ｚを特に区別しない場合は、単に制御指令モジュール３７０と言う。）は、ＡＰＩ情報（制御指令情報）に基づいて補間指令を算出する。また、制御指令モジュール３７０は、算出した補間指令を、ＩＦ部３８０に渡す。なお、制御指令モジュール３７０は、ＡＰＩ情報と、制御対象装置２０のフィードバック情報に含まれる制御対象装置２０の状態とに基づいて補間指令を算出するようにしてもよい。本実施形態では、制御指令モジュール３７０を、「制御部」と呼んでもよい。

本実施形態では、制御指令ライブラリ１１２１Ａが提供するＡＰＩ関数に対応するＡＰＩ情報（制御指令情報）は、制御指令モジュール３７０Ａで処理される。同様に、制御指令ライブラリ１１２１Ｂ〜１１２１Ｚが提供するＡＰＩ関数に対応するＡＰＩ情報（制御指令情報）は、それぞれ、制御指令モジュール３７０Ｂ〜制御指令モジュール３７０Ｚで処理される。つまり、制御指令ライブラリ１１２１Ａ〜１１２１Ｚは、それぞれ制御指令モジュール３７０Ａ〜３７０Ｚと１対１で対応づけられる。なお、これは実装方法の一例であり、必ずしも１対１で対応づけられていなくてもよい。例えば、複数の制御指令ライブラリ１１２１が１つの制御指令モジュール３７０に対応づけられていてもよい。本実施形態では、制御指令モジュール３７０を一意に特定する識別子を、「モジュール識別子」と言う。

制御指令モジュール３７０の具体例としては、前述したＰＴＰ動作やＪＯＧ動作の他に、例えば、特定の動作（あるビットが１になった場合等）や、特定の軸が指定位置まで移動したことをトリガーとして、所定の動作を実行させる制御指令モジュール３７０、制御対象装置２０との間の通信インターフェースから特定の値を取得する制御指令モジュール３７０が挙げられる。また、指定された制御対象装置２０の動作（位置、速度、加速度等）を記録する制御指令モジュール３７０、制御対象装置２０のゆがみ等に起因する位置の誤差等を補正する制御指令モジュール３７０等が挙げられる。当然ながら、これらの機能に対応するＡＰＩ関数を提供する制御指令ライブラリ１１２１も、非リアルタイムＯＳ１１０上に用意されている。

ＩＦ部３８０は、制御指令モジュール３７０及び通信モジュール３９０が共通に参照可能なメモリ領域を提供する。ＩＦ部３８０は、制御指令モジュール３７０と通信モジュール３９０との間で補間指令値及びフィードバック情報を相互に受渡しするために用いられる。

通信モジュール３９０Ａ〜３９０Ｚ（以下、通信モジュールＡ〜Ｚを特に区別しない場合は、単に通信モジュール３９０と言う。）は、それぞれ、異なる通信インターフェース規格に対応している。また、本実施形態では、通信ライブラリ１１２２Ａが提供するＡＰＩ関数が呼び出されることで定周期処理部３６０に通知されるＡＰＩ情報は、通信モジュール３９０Ａで処理される。同様に、通信ライブラリ１１２２Ｂ〜１１２２Ｚが提供するＡＰＩ関数が呼び出されることで定周期処理部３６０に通知されるＡＰＩ情報は、それぞれ、通信モジュール３９０Ｂ〜通信モジュール３９０Ｚで処理される。つまり、通信ライブラリ１１２２Ａ〜１１２２Ｚは、それぞれ通信モジュール３９０Ａ〜３９０Ｚと１対１で対応づけられる。なお、これは実装方法の一例であり、必ずしも１対１で対応づけられていなくてもよい。例えば、複数の通信ライブラリ１１４が１つの通信モジュール３９０に対応づけられていてもよい。

以上説明した、制御指示部１１０、デバイス管理部１２０、連携部３１０、定周期処理部３６０は、モーション制御装置１０のＣＰＵ１１が、メモリ１２又は記憶装置１３に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、非一時的な記憶媒体（Non-transitory computer readable medium）であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ−ＲＯＭ等の記憶媒体であってもよい。なお、当該プログラムには、ユーザ作成プログラム１１１が含まれていてもよいし、含まれていなくてもよい。

＜処理手順＞
続いて、モーション制御装置１０が行う具体的な処理手順について説明する。

（デバイス作成処理）
図６及び図８は、デバイス作成処理の一例を説明するための図である。また、図７及び図９は、デバイス作成処理が行われる際に生成される各種管理情報の一例を説明するための図である。図６〜図９を用いて、制御指示部１１０が、ユーザ操作により、制御指示部（１）１１０−１、制御指示部（２）１１０−２の順に起動された場合に、各々が実行するデバイス作成処理について説明する。

［前提条件］
最初に、デバイス作成処理を説明するにあたり前提とする条件について説明する。図６〜図９において、制御指示部（１）１１０−１は、制御指令ライブラリ１１２１Ａが提供するＡＰＩ関数を呼び出すものとする。同様に、制御指示部（２）１１０−２は、制御指令ライブラリ１１２１Ａ、制御指令ライブラリ１１２１Ｂ及び制御指令ライブラリ１１２１Ｃがそれぞれ提供するＡＰＩ関数を呼び出すものとする。

また、制御指示部（１）１１０−１に含まれるユーザ作成プログラム１１１、指令受付部１１２及びＩＦ（Ｎ側）部１１３を、それぞれ、ユーザ作成プログラム１１１−１、指令受付部１１２−１、ＩＦ（Ｎ側）部１１３−１と呼ぶ。また、制御指示部（１）１１０−１に対応するデバイス管理部１２０を、デバイス管理部１２０−１と呼ぶ。

また、制御指示部（２）１１０−２に含まれるユーザ作成プログラム１１１、指令受付部１１２及びＩＦ（Ｎ側）部１１３を、それぞれ、ユーザ作成プログラム１１１−２、指令受付部１１２−２及びＩＦ（Ｎ側）部１１３−２と呼ぶ。また、制御指示部（２）１１０−２に対応するデバイス管理部１２０を、デバイス管理部１２０−２と呼ぶ。

また、制御指示部（１）１１０−１（より詳細には制御指示部（１）１１０−１が生成したデバイス）に対応するＡＰＩ実行要求処理部３３０を、ＡＰＩ実行要求処理部（１）３３０−１と呼ぶ。同様に、制御指示部（２）１１０−２（より詳細には制御指示部（２）１１０−２が生成したデバイス）に対応するＡＰＩ実行要求処理部３３０を、ＡＰＩ実行要求処理部（２）３３０−２と呼ぶ。

また、起動設定情報４００には、制御指令モジュール３７０Ａ〜３７０Ｃ、及び通信モジュール３９０Ａ〜３９０Ｚが起動対象として指定されていると仮定する。なお、起動設定情報４００とは、定周期処理部３６０にて動作させる制御指令モジュール３７０及び通信モジュール３９０を指定する情報である。

［制御指示部（１）が行うデバイス作成処理］
図６及び図７を用いて、制御指示部（１）が行うデバイス作成処理を説明する。ユーザ操作により制御指示部（１）１１０−１が起動されると、ユーザ作成プログラム１１１−１は、制御対象装置２０へのモーション制御を開始する準備を行うことの準備指示（以下、「デバイス作成要求」と言う。）を指令受付部１１２−１に通知する。当該通知は、具体的には、ユーザ作成プログラム１１１−１がデバイスの作成を指示するＡＰＩ関数を呼び出すことで行われる。続いて、指令受付部１１２−１は、ＩＦ（Ｎ側）部１１３−１に、デバイス作成要求を通知する（Ｓ１００）。デバイス作成要求には、ユーザ作成プログラム１１１−１が発行する（後述する「モーション制御処理」にて発行予定である）制御指令を処理する制御指令モジュール３７０のモジュール識別子（制御指令モジュールＡ）が含まれる。また、指令受付部１１２−１は、ステップＳ１００の処理手順の前又は後で、デバイス管理部１２０−１を起動する。

次に、ＩＦ（Ｎ側）部１１３−１は、リアルタイムＯＳ３００側で連携部３１０が起動しているか否かを確認する。起動していない場合、リアルタイムＯＳ３００に対して連携部３１０の起動指示を送信する（Ｓ１０１）。なお、連携部３１０が起動していない状態とは、例えば、モーション制御装置１０を起動した直後などである。起動指示を受けたリアルタイムＯＳは、連携部３１０を起動する。

続いて、連携部３１０のメイン処理部３２０は、起動設定情報４００で指示されている制御指令モジュール３７０及び通信モジュール３９０を起動する（Ｓ１０２）。

続いて、リアルタイムＯＳ３００の指示により起動した連携部３１０のＩＦ（Ｒ側）部３２１は、共有メモリ２００に操作チャネルに使用するメモリ領域を確保し（Ｓ１０３）、メモリ領域の確保が完了したこと（つまり、操作チャネルを作成したこと）をＩＦ（Ｎ側）部１１３−１に通知する（Ｓ１０４）。このとき、ＩＦ（Ｒ側）部３２１は、共有メモリ２００において操作チャネルのために確保されたアドレス範囲もＩＦ（Ｎ側）部１１３−１に通知する。ＩＦ（Ｒ側）部３２１は、操作チャネルに確保したアドレス範囲をアドレス管理情報（図７（ｅ））に格納する。また、ＩＦ（Ｎ側）部１１３−１は、操作チャネルのアドレス範囲を、各ＩＦ（Ｎ側）部１１３から共通に参照可能なリソース（ファイル又は共通の変数等）に格納する。なお、ＩＦ（Ｎ側）部１１３−１は、操作チャネルのアドレス範囲を、更に、アドレス管理情報（図７（ｄ））に格納することとしてもよい。図７（ｄ）は、操作チャネルのアドレス範囲が格納された状態を示している。 操作チャネルの作成が完了したことの通知を受けたＩＦ（Ｎ側）部１１３−１は、他の制御指示部１１０のＩＦ（Ｎ側）部１１３との間で操作チャネルの利用について競合が生じないようにするため、操作チャネルの利用権限を取得する（Ｓ１０５）。

利用権限が取得できた場合、ＩＦ（Ｎ側）部１１３−１は、デバイス作成要求を、操作チャネルを介してＩＦ（Ｒ側）部３２１に通知する（Ｓ１０６）。デバイス作成要求には、ステップＳ１００の処理手順で通知されたモジュール識別子（制御指令モジュールＡ）が含まれる。

デバイス作成要求を受けたＩＦ（Ｒ側）部３２１は、デバイス識別子を例えば「Ｄ１」に決定する。また、ＩＦ（Ｒ側）部３２１は、ＡＰＩチャネルに使用するメモリ領域を確保すると共に、ＡＰＩチャネル識別子を例えば「ＡＰＩチャネル１」に決定する（Ｓ１０７）。また、ＩＦ（Ｒ側）部３２１は、決定したデバイス識別子及びＡＰＩチャネル識別子を対応づけて、デバイス管理情報（図７（ｂ））に格納する。

また、ＩＦ（Ｒ側）部３２１は、共有メモリ２００に、制御指令モジュール３７０Ａに対応する状態チャネルＡに使用するメモリ領域を確保する（Ｓ１０８）。ＩＦ（Ｒ側）部３２１は、作成した状態チャネルＡと制御指令モジュール３７０Ａとの対応関係を、状態チャネル管理情報（図７（ｃ））として保持する。また、ＩＦ（Ｒ側）部３２１は、ＡＰＩチャネル１及び状態チャネルＡに確保したメモリ領域のアドレス範囲を、アドレス管理情報（図７（ｅ））に格納する。

続いて、メイン処理部３２０は、ＡＰＩ実行要求処理部（１）３３０−１を起動する（Ｓ１０９）。なお、ステップＳ１０７〜ステップＳ１０９の処理手順は、図６に示す順序であることに限定されず、どのような順序で行われてもよい。

続いて、ＩＦ（Ｒ側）部３２１は、デバイスの作成が完了したこと（ＡＰＩチャネル１及び状態チャネルＡの作成が完了したこと）をＩＦ（Ｎ側）部１１３−１に通知する（Ｓ１１０）。当該通知は、作成されたＡＰＩチャネル識別子（ＡＰＩチャネル１）、ＡＰＩチャネル１及び状態チャネルＡに確保されたメモリ領域のアドレス範囲、並びにデバイス識別子（Ｄ１）を含む。

デバイスの作成が完了したとの通知を受けたＩＦ（Ｎ側）部１１３−１は、ＡＰＩチャネル１及び状態チャネルＡに確保されたメモリ領域のアドレス範囲を、アドレス管理情報（図７（ｄ））に格納する。続いて、ＩＦ（Ｎ側）部１１３−１は、操作チャネルの利用権限を解放し（Ｓ１１１）、デバイスの作成が完了したことを、指令受付部１１２−１に通知する。また、指令受付部１１２−１は、デバイスの作成が完了したことをユーザ作成プログラム１１１−１に通知する（Ｓ１１２）。当該通知には、デバイス識別子（Ｄ１）及びＡＰＩチャネル識別子（ＡＰＩチャネル１）が含まれる。当該通知は、例えば、デバイス作成を指示するＡＰＩ関数の戻り値であってもよい。

ユーザ作成プログラム１１１−１は、通知されたデバイス識別子（Ｄ１）及びＡＰＩチャネル識別子（ＡＰＩチャネル１）を対応づけて、デバイス管理情報（図７（ａ））として保持する。なお、デバイス管理情報として保持するとは、具体的には、デバイス作成を指示するＡＰＩ関数の戻り値として通知されたデバイス識別子及びＡＰＩチャネル識別子を変数に格納して保持することを意図しているが、これに限定されず、例えばファイル等で保持することも可能である。

［制御指示部（２）が行うデバイス作成処理］
図８及び図９を用いて、制御指示部（２）が行うデバイス作成処理を説明する。ユーザの操作により制御指示部（２）１１０−２が起動されると、ユーザ作成プログラム１１１−２は、デバイス作成要求を指令受付部１１２−２に通知する。指令受付部１１２−２は、ＩＦ（Ｎ側）部１１３−２に、デバイス作成要求を通知する（Ｓ１５０）。デバイス作成要求には、ユーザ作成プログラム１１１−２が発行する（後述する「モーション制御処理」にて発行予定である）制御指令を処理する制御指令モジュール３７０のモジュール識別子（制御指令モジュールＡ、制御指令モジュールＢ及び制御指令モジュールＣ）が含まれる。また、指令受付部１１２−２は、ステップＳ１００の処理手順の前又は後で、デバイス管理部１２０−２を起動する。

次に、ＩＦ（Ｎ側）部１１３−２は、リアルタイムＯＳ３００側で連携部３１０が起動しているか否かを確認する。ここでは、制御指示部（１）１１０−１が連携部３１０を既に起動していることから、ＩＦ（Ｎ側）部１１３−２は、連携部３１０の起動処理を行わない。続いて、ＩＦ（Ｎ側）部１１３−２は、操作チャネルの利用権限を取得する（Ｓ１５１）。

利用権限が取得できた場合、ＩＦ（Ｎ側）部１１３−２は、デバイス作成要求を、操作チャネルを介してＩＦ（Ｒ側）部３２１に通知する（Ｓ１５２）。デバイス作成要求には、モジュール識別子（制御指令モジュールＡ、制御指令モジュールＢ及び制御指令モジュールＣ）が含まれる。なお、ＩＦ（Ｎ側）部１１３−２は、操作チャネルのアドレス範囲を、各ＩＦ（Ｎ側）部１１３から共通に参照可能なリソース（ファイル又は共通の変数等）から取得する。また、ＩＦ（Ｎ側）部１１３−２は、操作チャネルのアドレス範囲を、アドレス管理情報（図９（ｄ））に格納することとしてもよい。図９（ｄ）は、操作チャネルのアドレス範囲が格納された状態を示している。

デバイス作成要求を受けたＩＦ（Ｒ側）部３２１は、デバイス識別子を例えば「Ｄ２」に決定する。また、ＩＦ（Ｒ側）部３２１は、共有メモリ２００に、ＡＰＩチャネルに使用するメモリ領域を確保するとともにＡＰＩチャネル識別子を例えば「ＡＰＩチャネル２」に決定する（Ｓ１５３）。また、ＩＦ（Ｒ側）部３２１は、決定したデバイス識別子及びＡＰＩチャネル識別子を対応づけて、デバイス管理情報（図９（ｂ））に追加する。

続いて、ＩＦ（Ｒ側）部３２１は、共有メモリ２００に、制御指令モジュール３７０Ａに対応する状態チャネルＡ、制御指令モジュール３７０Ｂに対応する状態チャネルＢ及び制御指令モジュール３７０Ｃに対応する状態チャネルＣに使用するメモリ領域を確保する。なお、制御指令モジュール３７０Ａに対応する状態チャネルＡは既に作成済み（図６のステップＳ１０８）であることから、ＩＦ（Ｒ側）部３２１は、状態チャネルＢ及び状態チャネルＣに使用するメモリ領域の確保を行う（Ｓ１５４、Ｓ１５５）。

続いて、ＩＦ（Ｒ側）部３２１は、作成した状態チャネルＢ及び状態チャネルＣが、それぞれ制御指令モジュール３７０Ｂ及び制御指令モジュール３７０Ｃに対応づけられることを、ＩＦ（Ｒ側）部３２１が保持する状態チャネル管理情報（図９（ｃ））に追加する。また、ＩＦ（Ｒ側）部３２１は、ＡＰＩチャネル２、状態チャネルＢ及び状態チャネルＣに確保したメモリ領域のアドレス範囲を、ＩＦ（Ｒ側）部３２１が保持するアドレス管理情報（図９（ｅ））に追加する。

続いて、ＩＦ（Ｒ側）部３２１は、デバイスの作成が完了したこと（ＡＰＩチャネル２、状態チャネルＢ及び状態チャネルＣの作成が完了したこと）をＩＦ（Ｎ側）部１１３−２に通知する（Ｓ１５７）。当該通知には、ＡＰＩチャネル２、状態チャネルＡ、状態チャネルＢ及び状態チャネルＣに確保されたメモリ領域のアドレス範囲、ＡＰＩチャネル識別子（ＡＰＩチャネル２）並びにデバイス識別子（Ｄ２）が含まれる。

デバイスの作成が完了したとの通知を受けたＩＦ（Ｎ側）部１１３−２は、ＡＰＩチャネル２、状態チャネルＡ、状態チャネルＢ及び状態チャネルＣに確保されたメモリ領域のアドレス範囲を、アドレス管理情報（図９（ｄ））に格納する。

続いて、ＩＦ（Ｎ側）部１１３−２は、操作チャネルの利用権限を解放し（Ｓ１５８）、デバイスの作成が完了したことを、指令受付部１１２−２に通知する。また、指令受付部１１２−２は、デバイスの作成が完了したことをユーザ作成プログラム１１１−２に通知する（Ｓ１５９）。当該通知には、デバイス識別子（Ｄ２）及びＡＰＩチャネル識別子（ＡＰＩチャネル２）が含まれる。ユーザ作成プログラム１１１−２は、通知されたデバイス識別子（Ｄ２）及びＡＰＩチャネル識別子（ＡＰＩチャネル２）を対応づけて、デバイス管理情報（図９（ａ））として保持する。

なお、以上説明したデバイス作成処理では、デバイス作成要求を取得したＩＦ（Ｒ側）部３２１側は、ＡＰＩチャネル及び状態チャネルの両方を作成するようにした。しかしながら、本実施形態は、これに限定されない。例えば、図６のステップＳ１００〜ステップＳ１１２及び図７のステップＳ１５０〜ステップＳ１５９の処理手順ではＡＰＩチャネルを作成し、その後、同様の処理手順を繰り返すことで、ＡＰＩチャネルの作成と状態チャネルの作成を別々のタイミングで行うようにしてもよい。

具体的には、ユーザ作成プログラム１１１は、モジュール識別子を含まないデバイス作成要求をＩＦ（Ｎ側）部１１３に通知し、ＩＦ（Ｎ側）部１１３も同様に、モジュール識別子を含まないデバイス作成要求をＩＦ（Ｒ側）部３２１に通知する。当該デバイス作成要求を受けたＩＦ（Ｒ側）部３２１は、ＡＰＩチャネルを作成し、デバイスの作成が完了したことをＩＦ（Ｎ側）部１１３に通知する。ＩＦ（Ｎ側）部１１３は、デバイスの作成が完了したことをユーザ作成プログラム１１１に通知する。

その後、ユーザ作成プログラム１１１は、例えば制御指令を発行する前などのタイミングで、当該制御指令を処理する制御指令モジュール３７０のモジュール識別子を含む状態チャネル作成要求をＩＦ（Ｎ側）部１１３に通知し、ＩＦ（Ｎ側）部１１３も同様に、モジュール識別子を含む状態チャネル作成要求をＩＦ（Ｒ側）部３２１に通知する。当該状態チャネル作成要求を受けたＩＦ（Ｒ側）部３２１は、状態チャネルを作成し、状態チャネルの作成が完了したことをＩＦ（Ｎ側）部１１３に通知する。ＩＦ（Ｎ側）部１１３は、状態チャネルの作成が完了したことをユーザ作成プログラム１１１に通知する。

（モーション制御処理）
続いて、モーション制御装置１０が制御対象装置２０をモーション制御する際の処理手順について具体的に説明する。

［前提条件］
以下の説明では、制御指示部１１０が、ＰＴＰ制御を実行可能な制御指令モジュール３７０Ａを使用し、軸１に対応する制御対象装置（軸１）２０−１及び軸２に対応する制御対象装置（軸２）２０−２に対してモーション制御を行うものとするまた、制御指示部１１０が生成したデバイスのデバイス識別子はＤ１であり、当該デバイスに対応するＡＰＩチャネル識別子はＡＰＩチャネル１であるものとする。また、ＡＰＩチャネル１及び制御指令モジュール３７０Ａに対応する状態チャネルＡは既に生成されているものとする。また、以下の説明において、制御指示部１１０は、ＰＴＰ制御に関するＡＰＩ関数を呼び出すことで、軸１及び軸２の２軸を同時に制御するものとする。

図１０及び図１１は、モーション制御装置１０が行うモーション制御処理の一例を示す図である。まず、図１０を用いて、ＡＰＩバッファ３４０の作成から、ＡＰＩバッファ３４０にＡＰＩ情報がキューイングされるまでの処理手順について説明する。

［ＡＰＩバッファ作成、ＡＰＩ情報蓄積］
まず、ユーザ作成プログラム１１１は、ＡＰＩバッファ３４０の作成を指示するＡＰＩ関数を呼び出す。当該ＡＰＩ関数が呼び出されると、指令受付部１１２は、ＡＰＩバッファの作成をＩＦ（Ｎ側）部１１３に通知する（Ｓ２００）。当該通知には、作成するＡＰＩバッファ３４０に対応するＡＰＩバッファ識別子が含まれる。ＡＰＩバッファ識別子はどのように決定されてもよいが、例えば、ステップＳ２００の処理手順を行う前に、例えばメイン処理部３２０から払い出されることとしてもよい。ここではＡＰＩバッファ識別子は「１」であると仮定する。

ＩＦ（Ｎ側）部１１３は、操作チャネルを介して、ＡＰＩバッファ３４０の作成をメイン処理部３２０に要求する（Ｓ２０１）。当該要求には、ＡＰＩバッファ識別子が含まれる。メイン処理部３２０は、ＡＰＩバッファ識別子「１」に対応するＡＰＩバッファ３４０を作成する（メモリ領域を確保する）（Ｓ２０２）。

続いて、ユーザ作成プログラム１１１が、ＡＰＩバッファ識別子「１」を指定してＡＰＩ情報の記録を開始する（ＡＰＩ情報のキューイングを開始する）ことを指示するＡＰＩ関数を呼び出すと、指令受付部１１２は、当該ＡＰＩ情報の記録を開始することをＩＦ（Ｎ側）部１１３に通知する（Ｓ２０３）。ＩＦ（Ｎ側）部１１３は、当該ＡＰＩ情報の記録を開始することをデバイス管理部１２０に通知する（Ｓ２０４）。デバイス管理部１２０は、ＡＰＩチャネル１の「ＡＰＩバッファ識別子」に「１」をセットすると共に、「記録中フラグ」をセットする（Ｓ２０５）。

記録中フラグは、ユーザ作成プログラム１１１が呼び出したＡＰＩ関数に対応するＡＰＩ情報を、一旦ＡＰＩバッファ３４０にキューイングしてから定周期処理部３６０に渡すのか、又は、ユーザ作成プログラム１１１が呼び出したＡＰＩ関数に対応するＡＰＩ情報を、ＡＰＩバッファ３４０にキューイングせずに直接、定周期処理部３６０に渡すのかを切り替えるために用いられる。具体的には、フラグがセットされている間にＡＰＩチャネルにＡＰＩ情報が格納された場合、ＡＰＩチャネルに格納されたＡＰＩ情報は、ＡＰＩ実行要求処理部３３０によりＡＰＩバッファ３４０にキューイングされる。一方、当該フラグがセットされていない状態でＡＰＩチャネルにＡＰＩ情報が格納された場合、ＡＰＩチャネルに格納されたＡＰＩ情報は、ＡＰＩ実行要求処理部３３０により取得されて定周期処理部３６０に渡され、定周期処理部３６０で実行される。

続いて、ユーザ作成プログラム１１１は、軸１に指示する指令値、軸２に指示する指令値及びデバイス識別子（ここではＤ１）を引数に指定して、ＰＴＰ制御を行うためのＡＰＩ関数を呼び出す。当該ＡＰＩ関数が呼び出されると、指令受付部１１２は、呼び出されたＡＰＩ関数に対応するＡＰＩ情報をＩＦ（Ｎ側）部１１３に通知する（Ｓ２０６）。

続いて、ＩＦ（Ｎ側）部１１３は、ＡＰＩ情報をＡＰＩチャネル１に格納する（Ｓ２０７）。具体的には、ＡＰＩチャネル１の「デバイス識別子」、「モジュール識別子」及び「制御指令識別子」に、それぞれ、「Ｄ１」、「制御指令モジュールＡ」及び「ＰＴＰ」を格納する。また、「指令値」には軸１の指令値及び軸２の指令値を格納する。「ＡＰＩバッファ識別子」及び「記録中フラグ」には、ステップＳ２０５の処理手順で格納された情報がそのまま格納されている。

なお、ＡＰＩチャネルに格納する「モジュール識別子」は、制御指令モジュール３７０を明示的に特定可能な識別子に限られず、制御指令モジュール３７０を暗示的に示す識別子であってもよい。また、ＡＰＩチャネルから「モジュール識別子」を省略するようにしてもよい。本実施形態では、「制御指令識別子」で示される制御指令を実行する制御指令モジュール３７０は１つであることから、連携部３１０は、制御指令識別子に基づいて、制御指令モジュール３７０を一意に特定することが可能であるためである。

ＡＰＩ実行要求処理部３３０は、ＡＰＩチャネル１の「記録中フラグ」がセットされている場合、ＡＰＩチャネル１に格納されているＡＰＩ情報（「デバイス識別子」、「モジュール識別子」、「制御指令識別子」、「ＡＰＩバッファ識別子」及び「指令値」）を取得する（Ｓ２０８）。また、取得したＡＰＩ情報を、ステップＳ２０８で取得した「ＡＰＩバッファ識別子」に対応するＡＰＩバッファ３４０にキューイングする（Ｓ２０９）。

制御指示部１１０が複数のＡＰＩを呼び出す場合、ステップＳ２０６〜ステップＳ２０９の処理手順が繰り返されることで、複数のＡＰＩ情報がＡＰＩバッファ３４０にキューイングされる。

ＡＰＩバッファ３４０にキューイングさせるＡＰＩ関数の呼出が完了すると、ユーザ作成プログラム１１１は、ＡＰＩバッファ３４０へのＡＰＩ情報の記録を終了する（ＡＰＩ情報のキューイングを終了する）ことを指示するＡＰＩ関数を呼び出す。制御指示部１１０は、ＡＰＩバッファ３４０へのＡＰＩ情報の記録を終了することをＩＦ（Ｎ側）部１１３に通知し（Ｓ２１０）、ＩＦ（Ｎ側）部１１３は、当該通知をデバイス管理部１２０に通知する（Ｓ２１１）。デバイス管理部１２０は、ＡＰＩチャネル１にセットされている記録中フラグを消去する（Ｓ２１２）。

ＡＰＩバッファ３４０は、ユーザ作成プログラム１１１（より詳細にはデバイス）の指示により生成されるが、１つのユーザ作成プログラム１１１が複数のＡＰＩバッファ３４０を作成することが可能である。また、複数のユーザ作成プログラム１１１が同一のＡＰＩバッファ３４０を共用することも可能である。本実施形態では、１つのユーザ作成プログラム１１１が複数のＡＰＩバッファ３４０を利用可能とすることで、複数の複雑なモーション制御を同時に動作させることを可能としている。また、複数のユーザ作成プログラム１１１が同一のＡＰＩバッファ３４０を共用することを可能とすることで、ユーザがユーザ作成プログラム１１１を作成する際の自由度を高めることができる。

［制御対象装置の制御］
次に、図１１を用いて、ＡＰＩバッファ３４０にキューイングされたＡＰＩ情報に従って、制御対象装置（軸１）２０−１及び制御対象装置（軸２）２０−２を制御する際の処理手順について説明する。

図１１に示すように、制御指令モジュール３７０Ａは、制御指令モジュール３７０Ａが同時に制御可能な複数の軸について、軸ごとに、指令値と、指令値を更新したことを示す実行フラグとを格納するメモリ領域３７１を保持している。図１１の例では、制御指令モジュール３７０Ａは最大１２８軸まで同時制御することが可能であり、軸１〜軸１２８の各々について、指令値及び実行フラグを格納するためのメモリ領域３７１を有している。実行フラグには、「実行中」又は「実行済み」のいずれかが格納される。「実行中」は、制御指令モジュール３７０Ａがモーション制御サイクルに従って軸を制御中であることを示し、「実行済み」は、軸の制御が完了した状態であることを示す。

ここで、ＩＦ部３８０は、定周期処理部３６０が同時に制御可能な複数の軸について、軸ごとに、補間指令値及びフィードバック情報を格納するためのメモリ領域３８１を有している。図１１の例では、ＩＦ部３８０には、軸１〜軸１２８の各々について、補間指令値及びフィードバック情報を格納可能なメモリ領域３８１を有している。

まず、ユーザ作成プログラム１１１は、ＡＰＩバッファ識別子（１）に対応するＡＰＩバッファ３４０について、実行を開始することを示すＡＰＩ関数を呼び出す。具体的には、ユーザ作成プログラム１１１は、当該ＡＰＩ関数の引数に、ＡＰＩバッファ識別子（１）を設定する。続いて、指令受付部１１２は、ＡＰＩバッファ識別子（１）のＡＰＩバッファからＡＰＩ情報を取り出して制御指令モジュール３７０に渡す処理を開始すべきことをＩＦ（Ｎ側）部１１３に通知する（Ｓ２５０）。ＩＦ（Ｎ側）部１１３は、ＡＰＩバッファ識別子（１）のＡＰＩバッファからＡＰＩ情報を取り出して制御指令モジュール３７０に渡す処理を開始すべきことを、操作チャネルを介して指令実行処理部３５０に通知する（Ｓ２５１）。

ＩＦ（Ｎ側）部１１３から通知を受けた指令実行処理部３５０は、指定されたＡＰＩバッファ３４０に格納されているＡＰＩ情報を取得して定周期処理部３６０に渡す。具体的には、指令実行処理部３５０は、ＡＰＩバッファ識別子「１」に対応するＡＰＩバッファ３４０からＡＰＩ情報を１つ取得する。取得したＡＰＩ情報の「モジュール識別子」、「制御指令識別子」及び「指令値」には、それぞれ、「制御指令モジュールＡ」、「ＰＴＰ」及び「軸１の指令値及び軸２の指令値」が格納されている。指令実行処理部３５０は、ＡＰＩ情報の「モジュール識別子」により指定された制御指令モジュール３７０Ａに対して、実行すべき制御指令識別子（ここではＰＴＰ）を通知する（Ｓ２５３）。続いて、指令実行処理部３５０は、制御指令モジュール３７０Ａのメモリ領域３７１における軸１の指令値及び軸２の指令値を、ＡＰＩ情報から取得した軸１の指令値及び軸２の指令値で更新すると共に、軸１の実行フラグ及び軸２の実行フラグを「実行中」に変更する（Ｓ２５４）。

続いて、制御指令モジュール３７０Ａは、メモリ領域３７１に格納された軸１及び軸２の指令値に基づいて、軸１及び軸２に対する補間指令値を算出し、算出した補間指令値をＩＦ部３８０に格納する（Ｓ２６０）。補間指令値は、制御指令の内容に応じて所定のロジックで算出される。所定のロジックとしては、例えば、従来のＰＴＰ制御における制御ロジック等を利用することができる。通信モジュール３９０は、ＩＦ部３８０に格納された軸１及び軸２の補間指令値を取得し、軸１及び軸２の通信インターフェース規格に応じた信号に変換して制御対象装置（軸１）２０−１及び制御対象装置（軸２）２０−２に送信する（Ｓ２６１）。

ステップＳ２６０及びステップＳ２６１の処理手順がモーション制御サイクル（例えば１ｍｓ間隔や０．５ｍｓ間隔等）に従って繰り返されることで、軸１及び軸２が補間指令値に従って滑らかに動作する。軸１及び軸２の状態が指令値に到達すると、制御指令モジュール３７０Ａは、軸１及び軸２の実行フラグを「実行済み」に更新する。軸１及び軸２の実行フラグが「実行済み」に更新されたことを検出した指令実行処理部３５０は、次にＡＰＩバッファ３４０に格納されているＡＰＩ情報を読み出し、上述したステップＳ２５３及びステップＳ２５４の処理手順を繰り返し行う。これにより、制御指令モジュール３７０Ａのメモリ領域３７１における指令値が更新され、再度、ステップＳ２６０及びステップＳ２６１の処理手順が実行される。以上説明したステップＳ２５２〜ステップＳ２６１の処理手順の動作が、ＡＰＩバッファ３４０が空になるまで繰り返される。

ここで、通信モジュール３９０は、制御対象装置（軸１）２０−１及び制御対象装置（軸２）２０−２からフィードバック情報を取得し、共通信号フォーマットのフィードバック情報に変換してＩＦ部３８０に格納する（Ｓ２６２）。続いて、制御指令モジュール３７０Ａは、ＩＦ部３８０に格納された軸ごとのフィードバック情報を取得する（Ｓ２６３）。ステップＳ２６２及びステップＳ２６３の処理手順は、モーション制御サイクルに従って繰り返されるようにしてもよいし、モーション制御サイクルとは異なる周期（例えば数ｍｓ周期等）で繰り返されるようにしてもよい。

制御指令モジュール３７０Ａは、取得した軸１及び軸２のフィードバック情報をメイン処理部３２０に通知する（Ｓ２６４）。メイン処理部３２０は、通知された軸１及び軸２のフィードバック情報を状態チャネルＡに格納する（Ｓ２６５）。ユーザ作成プログラム１１１が、状態チャネルＡに対応するフィードバック情報を読み出すＡＰＩ関数を呼び出すと、指令受付部１１２は、ＩＦ（Ｎ側）部１１３に対して、状態チャネルＡに格納されたフィードバック情報を読み出すべきことを通知する。ＩＦ（Ｎ側）部１１３が読みだしたフィードバック情報は、指令受付部１１２を介してユーザ作成プログラム１１１に伝えられる。これにより、ユーザ作成プログラム１１１は、各軸がどのように動作しているのかを把握することができ、例えば、軸の状態に基づいて制御指令を切り替えるといった複雑なモーション制御を実現することができる。

なお、制御指令モジュール３７０Ａは、ステップＳ２６０の処理手順において、例えばモーション制御サイクル毎にフィードバック情報に含まれる軸１及び軸２の状態を参照し、軸１及び軸２が意図する動作を行っているかをモーション制御サイクル毎に確認しながら次のモーション制御サイクルにおける補間指令値を算出するようにしてもよい。

図１２は、制御指令モジュール３７０が行う処理手順の一例を示すフローチャートである。まず、制御指令モジュール３７０は、メモリ領域３７１から、実行フラグが「実行中」にセットされた軸についての指令値を取得する（Ｓ３００）。続いて、制御指令モジュール３７０は、指令値に基づき、１モーション制御サイクル分の指令値（つまり補間指令値）を算出し（Ｓ３０１）、算出した補間指令値を、ＩＦ部３８０のメモリ領域３８１に格納する（Ｓ３０２）。続いて、制御指令モジュール３７０は、ＩＦ部３８０から軸ごとのフィードバック情報を取得する（Ｓ３０３）。続いて、制御指令モジュール３７０は、ステップＳ３００で指令値を取得した軸について、フィードバック情報が指令値に達しているか否かを判定する（Ｓ３０４）。指令値に達している場合は、当該軸の実行フラグを「実行済み」にセットし、処理を終了する。指令値に達していない場合は、次のモーション制御サイクルまで待機し（Ｓ３０５）ステップＳ３０１の処理手順に進む。なお、ステップＳ３０３の処理手順を省略し、ステップＳ３０４の処理手順を、軸の動作が指令値に達しているか否かを、現代制御理論を利用することでフィードバック情報を利用せず判定することに置き換えるようにしてもよい。

（エラーハンドリング処理）
［制御指示部のクラッシュ］
次に、制御指示部１１０が何らかの理由でクラッシュした際に行われる処理手順について説明する。デバイス管理部１２０は、制御指示部１１０が生存（動作）していることを定期的に監視し、制御指示部１１０が生存している間、制御指示部１１０が生存していることを示す生存報告をＡＰＩチャネルに書き込む。ＩＦ（Ｒ側）部３２１は、各制御指示部１１０が生存していることを示す生存報告の有無を、各ＡＰＩチャネルを参照することで周期的に取得し、生存報告が所定の期間の間なされていない場合、生存報告が報告されなかった制御指示部１１０に対応するＡＰＩチャネルを破棄（消去）する（当該ＡＰＩチャネルのメモリ領域を解放する）。以下、図を用いて制御指示部がクラッシュした際の処理手順を具体的に説明する。

図１３は、制御指示部がクラッシュした場合の処理手順の一例を示す図である。図１３の説明では、前述した「（デバイス作成処理）」で説明した前提条件と同一の前提条件が適用されるものとする。

デバイス管理部１２０−１及びデバイス管理部１２０−２は、それぞれ、ＡＰＩチャネル１及びＡＰＩチャネル２に生存報告を周期的に書き込むように構成されている（Ｓ４００、Ｓ４０１）。生存報告は、例えばタイムスタンプであってもよい。また、周期は任意であるが、例えば、１秒間隔や１０秒間隔といった周期であってもよい。ここで、制御指示部（１）１１０−１がクラッシュしたことで、デバイス管理部１２０−１が生存報告をＡＰＩチャネル１に書き込まなくなったと仮定する（Ｓ４００）。

その後、制御指示部（１）１１０−１が再起動すると、制御指示部（１）１１０−１は、デバイス作成要求をＩＦ（Ｎ側）部１１３−１に通知する（Ｓ４１０）。ステップＳ４１１及びステップＳ４１２の処理手順は、それぞれ、図６のステップＳ１０５及びステップＳ１０６と同一であるため説明は省略する。なお、ＩＦ（Ｎ側）部１１３−１は、操作チャネルのアドレス範囲を、各ＩＦ（Ｎ側）部１１３から共通に参照可能なリソース（ファイル又は共通の変数等）から取得する。

続いて、ＩＦ（Ｒ側）部３２１は、共有メモリ２００にＡＰＩチャネルに使用するメモリ領域を確保する（Ｓ４１３）。また、ＩＦ（Ｒ側）部３２１は、デバイス識別子及びＡＰＩチャネル識別子を決定する。ここでは、デバイス識別子を例えば「Ｄ３」に決定し、ＡＰＩチャネル識別子を例えば「ＡＰＩチャネル３」に決定したとする。ＩＦ（Ｒ側）部３２１は、確保したＡＰＩチャネル１のアドレス範囲を、アドレス管理情報に格納すると共に、デバイス管理情報に、デバイス識別子（Ｄ３）及びＡＰＩチャネル３が対応づけられたレコードを追加する。ステップＳ４１４〜ステップＳ４１６の処理手順は、それぞれ図６のステップＳ１１０〜ステップＳ１１２と同一であるため説明は省略する。

続いて、ＩＦ（Ｒ側）部３２１は、ＡＰＩチャネル１にて生存報告が所定の期間書き込まれていないことを検出し、ＡＰＩチャネル１を破棄する（Ｓ４１７）。また、ＩＦ（Ｒ側）部３２１は、デバイス管理情報から、ＡＰＩチャネル１を含むレコードを削除し、更に、アドレス管理情報から、ＡＰＩチャネル１のアドレス範囲が格納されたレコードを削除する。

なお、ＩＦ（Ｒ側）部３２１が、生存報告が書き込まれていないことを検出するタイミングによっては、ステップＳ４１７の処理手順が、ステップＳ４１４の処理手順より前になることも想定される。この場合、ＩＦ（Ｒ側）部３２１は、共有メモリ２００に、ＡＰＩチャネルに使用するメモリ領域を確保する際、破棄されたＡＰＩチャネル１のメモリ領域（つまり、空きメモリ領域）を、新たに生成するＡＰＩチャネルのメモリ領域として確保する（再利用する）ようにしてもよい。

本実施形態では、２以上の操作チャネルが共有メモリ２００に確保されることはなく、また、状態チャネルが、リアルタイムＯＳ３００に実装された制御指令モジュール３７０の数以上に確保されることはない。一方、共有メモリ２００に確保されるＡＰＩチャネルの数は、起動される制御指示部１１０の数や制御指示部１１０が作成するデバイスの数に応じて変化する。そのため、利用されなくなったＡＰＩチャネルが共有メモリ２００に残り続けると、共有メモリ２００の空きリソースが不足してモーション制御装置１０自体が動作不能になる可能性がある。以上説明したエラーハンドリング処理によれば、生存報告が書き込まれなくなったＡＰＩチャネルは共有メモリ２００から消去されることから、制御指示部１１０が何度もクラッシュすることにより共有メモリ２００のリソースが不足する可能性を抑止することが可能になる。

また、以上説明したエラーハンドリング処理によれば、制御指示部１１０がクラッシュした場合、当該制御指示部１１０に関係のあるＡＰＩチャネルの削除や作成のみが行われ、クラッシュしていない他の制御指示部１１０が使用しているＡＰＩチャネルや状態チャネルについては、共有メモリ２００にそのまま確保され続けることになる。すなわち、制御指示部１１０がクラッシュしたとしても、クラッシュしていない他の制御指示部１１０は、何の影響を受けることなく動作を継続することが可能になる。

［連携部のクラッシュ］
連携部３１０がクラッシュした場合、ＩＦ（Ｒ側）部３２１は、自身が記憶しているデバイス管理情報（図９（ｂ）、状態チャネル管理情報（図９（ｃ））及びアドレス管理情報（図９（ｅ））を失ってしまうことになる。これらの情報を失ってしまうと、ＩＦ（Ｒ側）部３２１は、各チャネルにアクセスすることが出来なくなる。

そこで、本実施形態では、共有メモリ２００における予め定められた領域に、操作チャネル、ＡＰＩチャネル及び状態チャネルのために確保されているアドレス範囲を示す情報と、各アドレス範囲がどのチャネルのために確保されているメモリ領域なのかを示す情報とを格納しておく。連携部３１０がクラッシュして再起動した場合、連携部３１０は、当該予め定められた領域にアクセスすることで、操作チャネル、ＡＰＩチャネル及び状態チャネルが確保されているアドレス範囲等を認識し、認識した情報に基づいて、デバイス管理情報、状態チャネル管理情報及びアドレス管理情報を生成する。

これにより、連携部３１０がクラッシュした場合であっても、制御指示部１１０側にて再度デバイス生成処理等をやり直すことなく、モーション制御装置１０の動作を復旧させることが可能になる。

（プロトコル変換処理）
モーション制御装置１０は、通信インターフェース規格が異なる複数の制御対象装置２０を同時に制御することができる。このような制御を実現するために、ＩＦ部３８０のメモリ領域３８１では、共通信号フォーマットに従った補間指令値及びフィードバック情報を保持する。共通信号フォーマットはどのようなフォーマットであってもよいが、複数の通信インターフェース規格との間で相互に変換（プロトコル変換）可能なように、当該複数の通信インターフェース規格の必須項目を全て含有するフォーマットであることが望ましい。

制御指令モジュール３７０は、共通信号フォーマットに従って補間指令値を生成してＩＦ部３８０に格納する。また、通信モジュール３９０は、補間指令値をＩＦ部３８０から取得し、取得した補間指令値を、共通信号フォーマットから、通信モジュール３９０が信号の送受信を行う制御対象装置２０の通信インターフェース規格に対応する信号フォーマットに変換してから制御対象装置２０に送信する。

同様に、通信モジュール３９０は、制御対象装置２０からフィードバック情報を受信し、受信したフィードバック情報を、制御対象装置２０の通信インターフェース規格に対応する信号フォーマットから、共通信号フォーマットにプロトコル変換してからＩＦ部３８０に格納する。

各通信モジュール３９０が受け持つ軸（各通信モジュール３９０が受け持つ制御対象装置２０と同義）及びＩＦ部における軸ごとのアドレス範囲は、マッピング情報に定義されている。各通信モジュール３９０は、マッピング情報に基づき、各通信モジュール３９０が受け持つべき軸（制御対象装置２０）向けに確保されたメモリ領域３８１にアクセスすることで補間指令値を取得すると共に、フィードバック情報をメモリ領域３８１に格納する。同様に、各制御指令モジュール３７０は、マッピング情報に基づき、各軸向けに確保されたメモリ領域３８１にアクセスすることで補間指令値を取得すると共に、フィードバック情報をメモリ領域３８１に格納する。

図１４は、マッピング情報の一例を示す図である。マッピング情報４１０には、軸（制御対象装置２０）ごとに、各軸を受け持つ通信モジュール３９０と、通信インターフェース規格で使用される、制御対象装置２０を一意に特定する識別子（スレーブ番号）とが対応づけられている。

図１４の例では、軸１は、ＥｔｈｅｒＣＡＴ（登録商標）に対応する通信モジュール３９０が受け持ち、ＥｔｈｅｒＣＡＴ（登録商標）におけるスレーブ１に接続された制御対象装置２０に対応していることが定義されている。同様に、軸２は、ＥｔｈｅｒＣＡＴ（登録商標）に対応する通信モジュール３９０が受け持ち、ＥｔｈｅｒＣＡＴ（登録商標）におけるスレーブ２に接続された制御対象装置２０に対応していることが定義されている。同様に、軸３は、ＲＴＥＸ（登録商標）に対応する通信モジュール３９０が受け持ち、ＲＴＥＸ（登録商標）におけるスレーブ１に接続された制御対象装置２０に対応していることが定義されている。なお、マッピング情報は、例えば、複数の通信モジュール３９０がアクセス可能なリアルタイムＯＳ３００上の所定の領域に格納されていてもよい。或いは、各通信モジュール３９０が、自身に関係のある軸に関するマッピング情報を自ら保持するようにしてもよい。例えば、ＥｔｈｅｒＣＡＴ（登録商標）に対応する通信モジュール３９０は、軸１及び軸２に対応するスレーブ番号が格納されたマッピング情報を保持し、ＲＴＥＸ（登録商標）に対応する通信モジュール３９０、軸３に対応するスレーブ番号が格納されたマッピング情報を保持するようにしてもよい。

図１５は、プロトコル変換処理の処理手順の一例を説明するための図である。通信モジュール３９０−１及び通信モジュール３９０−２は、連携部３１０からの指示により起動したタイミング（図６のステップＳ１０２）など、少なくとも制御対象装置２０との間で通信を開始する前にマッピング情報４１０を読み出すことで自身が制御すべき軸の情報を取得しておく。なお、以下の処理手順において、ＩＦ部３８０に格納されている各軸の補間指令値及びフィードバック情報を読み出す処理、及び各軸の補間指令値及びフィードバック情報をＩＦ部３８０に書き込む処理は、例えば、制御指令モジュール３７０及び通信モジュール３９０が所定の関数を呼び出すことで行われる。

まず、制御指令モジュール３７０は、ＩＦ部３８０のメモリ領域３８１に共通信号フォーマットに従って格納されている、軸１〜軸３の補間指令値を更新する（Ｓ５００）。通信モジュール３９０−１は、軸１の補間指令値及び軸２の補間指令値を取得し（Ｓ５０１、Ｓ５０２）、取得した補間指令値の信号フォーマットを、共通信号フォーマットからＥｔｈｅｒＣＡＴ（登録商標）の信号フォーマットに変換する。続いて、通信モジュール３９０−１は、信号フォーマットの変換を終えた軸１の補間指令値及び軸２の補間指令値を、それぞれ、制御対象装置２０−１及び制御対象装置２０−２に送信する（Ｓ５０４、Ｓ５０５）。同様に、通信モジュール３９０−２は、軸３の補間指令値を取得し（Ｓ５０３）、取得した補間指令値の信号フォーマットを、共通信号フォーマットからＲＴＥＸ（登録商標）の信号フォーマットに変換する。続いて、通信モジュール３９０−２は、変換した軸３の補間指令値を制御対象装置２０−３に送信する（Ｓ５０６）。

次に、通信モジュール３９０−１は、制御対象装置２０−１及び制御対象装置２０−２から、軸１のフィードバック情報及び軸２のフィードバック情報を取得し（Ｓ５１０、Ｓ５１１）、取得したフィードバック情報の信号フォーマットをＥｔｈｅｒＣＡＴ（登録商標）の信号フォーマットから共通信号フォーマットに変換する。続いて、通信モジュール３９０−１は、変換した軸１のフィードバック情報及び軸２のフィードバック情報を、ＩＦ部３８０のメモリ領域３８１に格納する（Ｓ５１３、Ｓ５１４）。

同様に、通信モジュール３９０−２は、制御対象装置２０−３から軸３のフィードバック情報を取得し（Ｓ５１２）、取得したフィードバック情報の信号フォーマットを、ＲＴＥＸ（登録商標）の信号フォーマットから共通信号フォーマットに変換する。続いて、通信モジュール３９０−２は、変換した軸２のフィードバック情報を、ＩＦ部３８０のメモリ領域３８１に格納する（Ｓ５１５）。制御指令モジュール３７０は、ＩＦ部３８０のメモリ領域３８１に格納されている軸１〜軸３のフィードバック情報を取得する（Ｓ５１６）。

以上説明したプロトコル変換処理では、ステップＳ５００〜ステップＳ５１６の処理手順が、モーション制御サイクルごとに繰り返し行われる。

＜まとめ＞
以上、実施形態に係るモーション制御装置１０について説明した。制御対象装置２０に対してモーション制御を行う場合、複数の制御対象装置２０を同期させながら高精度に動作させるためには、モーション制御サイクル（例えば１ｍｓごとや０．５ｍｓ）ごとに補間指令を制御対象装置２０に送信し続けることが必要である。Ｗｉｎｄｏｗｓ（登録商標）のような非リアルタイムＯＳ１００では、ＯＳ自身が行うバックグラウンド処理等の影響により処理負荷が高くなると、実行中であるプログラムの動作速度が遅くなってしまうことから、１ｍｓや０．５ｍｓといった周期で補間指令を制御対象装置２０に送信し続けることは困難である。

一方、本実施形態では、非リアルタイムＯＳ１１０側で複数のモーション制御サイクルに渡る制御指令（ＡＰＩ情報）を発行し、リアルタイムＯＳ３００側でＡＰＩバッファ３４０を介して当該制御指令を取得して、モーション制御サイクルごとの補間指令を発行する構成を採用した。これにより、非リアルタイムＯＳ１１０での処理速度の変化を吸収し、非リアルタイムＯＳ１１０及びリアルタイムＯＳ３００がインストールされた汎用の情報処理装置を用いてスムーズな高精度のモーション制御を実行することを可能とした。また、複数の制御指令が発行される場合、当該複数の制御指令がＡＰＩバッファ３４０に格納されることになる。これにより、各々の制御指令による連続したモーション制御（モーション制御シーケンス）をスムーズに実行することを可能とした。

また、本実施形態では、制御指示部１１０を非リアルタイムＯＳ１１０側に配置したことで、モーション制御サイクルに沿ったリアルタイム処理を実現しつつ、ユーザが使い慣れたデザインのユーザインタフェースを提供することを可能とした。

また、本実施形態では、モーション制御を行う際に必要になるＡＰＩチャネル等のリソースを制御指示部１１０ごと（より詳細にはデバイスごと）に用意するようにした。これにより、制御指示部１１０が制御指令を発行することで制御対象装置２０を制御するという一連の動作に必要なリソースを制御指示部１１０ごとに（すなわちユーザ作成プログラム１１１ごとに）分離することができ、万が一、制御指示部１１０にクラッシュ等の異常が生じたとしても、当該異常が他の制御指示部１１０の動作に影響を与えてしまう可能性を抑制することを可能とした。

また、本実施形態では、リアルタイムＯＳ３００上の制御指令モジュール３７０からＩＦ部３８０までの処理を、共通信号フォーマットを用いて共通化し、通信モジュール３９０にて、共通信号フォーマットから制御対象装置２０に対応する通信インターフェース規格の信号フォーマットにプロトコル変換するようにした。これにより、モーション制御装置１０が行う殆どの処理を共通化することができ、通信インターフェース規格が異なる複数の制御対象装置２０を混在させた制御を、容易に実現することを可能とした。

＜変形例＞
以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。

例えば、ＡＰＩチャネルはデバイスごとに生成されることから、デバイスが特定されればＡＰＩチャネルも一意に特定できることになる。そのため、本実施形態において「ＡＰＩチャネル識別子」を「デバイス識別子」に置き換えることとしてもよい。

Claims (6)

1. 非リアルタイムＯＳ及びリアルタイムＯＳがインストールされ、複数の制御対象装置をモーション制御するためのコンピュータで実行されるモーション制御プログラムであって、
   前記コンピュータを、
   前記非リアルタイムＯＳ上で動作する受付部と、
   前記リアルタイムＯＳ上で動作する制御部と、
   前記リアルタイムＯＳ上で動作する複数の通信モジュール部と、
   して機能させ、
   前記受付部は、前記複数の制御対象装置を制御するユーザ作成プログラムから、前記複数の制御対象装置の各々が複数のモーション制御サイクルに渡って行うべき動作を示す制御指令を受け付け、受け付けた制御指令の内容を示す制御指令情報を前記制御部に通知し、
   前記制御部は、前記受付部から通知された前記制御指令情報に基づいて、前記複数の制御対象装置の各々に対して前記モーション制御サイクルごとに実行させるべき動作を示す、前記制御対象装置ごとの補間指令を前記モーション制御サイクルごとに繰り返し生成し、生成した前記補間指令を、前記制御対象装置ごとに確保されるメモリ領域に格納し、
   前記通信モジュール部は、前記制御対象装置ごとに確保された前記メモリ領域から前記補間指令を取得し、取得した前記補間指令を、前記制御部が認識可能な所定の信号フォーマットから、前記複数の制御対象装置の各々が認識可能な通信インターフェース規格の信号フォーマットに変換して送信する、
   モーション制御プログラム。
2. 前記通信モジュール部は、前記複数の制御対象装置の各々から取得される制御対象装置の状態を示すフィードバック情報を、前記複数の制御対象装置の各々が認識可能な通信インターフェース規格の信号フォーマットから前記所定の信号フォーマットに変換して前記メモリ領域に格納し、
   前記制御部は、前記メモリ領域から、前記所定の信号フォーマットに変換された前記フィードバック情報を取得する、
   請求項１に記載のモーション制御プログラム。
3. 前記複数の通信モジュール部の各々は、前記複数の通信モジュール部の各々が受け持つべき前記制御対象装置と、前記受け持つべき前記制御対象装置に確保された前記メモリ領域との対応関係を定義するマッピング情報に基づいて、前記メモリ領域にアクセスすることで前記補間指令を取得すると共に、前記フィードバック情報を前記メモリ領域に格納する、
   請求項２に記載のモーション制御プログラム。
4. 前記マッピング情報は、前記複数の通信モジュール部がアクセス可能な前記リアルタイムＯＳ上の領域に格納される、
   請求項３に記載のモーション制御プログラム。
5. 非リアルタイムＯＳ及びリアルタイムＯＳがインストールされ、複数の制御対象装置をモーション制御するためのモーション制御装置が行うモーション制御方法であって、
   前記モーション制御装置は、
   前記非リアルタイムＯＳ上で動作する受付部と、
   前記リアルタイムＯＳ上で動作する制御部と、
   前記リアルタイムＯＳ上で動作する複数の通信モジュール部と、
   を有し、
   前記受付部が、前記複数の制御対象装置を制御するユーザ作成プログラムから、前記複数の制御対象装置の各々が複数のモーション制御サイクルに渡って行うべき動作を示す制御指令を受け付け、受け付けた制御指令の内容を示す制御指令情報を前記制御部に通知するステップと、
   前記制御部が、前記受付部から通知された前記制御指令情報に基づいて、前記複数の制御対象装置の各々に対して前記モーション制御サイクルごとに実行させるべき動作を示す、前記制御対象装置ごとの補間指令を前記モーション制御サイクルごとに繰り返し生成し、生成した前記補間指令を、前記制御対象装置ごとに確保されるメモリ領域に格納するステップと、
   前記通信モジュール部が、前記制御対象装置ごとに確保された前記メモリ領域から前記補間指令を取得し、取得した前記補間指令を、前記制御部が認識可能な所定の信号フォーマットから、前記複数の制御対象装置の各々が認識可能な通信インターフェース規格の信号フォーマットに変換して送信するステップと、
   を含むモーション制御方法。
6. 非リアルタイムＯＳ及びリアルタイムＯＳがインストールされ、複数の制御対象装置をモーション制御するためのモーション制御装置であって、
   前記非リアルタイムＯＳ上で動作する受付部と、
   前記リアルタイムＯＳ上で動作する制御部と、
   前記リアルタイムＯＳ上で動作する複数の通信モジュール部と、
   を有し、
   前記受付部は、前記複数の制御対象装置を制御するユーザ作成プログラムから、前記複数の制御対象装置の各々が複数のモーション制御サイクルに渡って行うべき動作を示す制御指令を受け付け、受け付けた制御指令の内容を示す制御指令情報を前記制御部に通知し、
   前記制御部は、前記受付部から通知された前記制御指令情報に基づいて、前記複数の制御対象装置の各々に対して前記モーション制御サイクルごとに実行させるべき動作を示す、前記制御対象装置ごとの補間指令を前記モーション制御サイクルごとに繰り返し生成し、生成した前記補間指令を、前記制御対象装置ごとに確保されるメモリ領域に格納し、
   前記通信モジュール部は、前記制御対象装置ごとに確保された前記メモリ領域から前記補間指令を取得し、取得した前記補間指令を、前記制御部が認識可能な所定の信号フォーマットから、前記複数の制御対象装置の各々が認識可能な通信インターフェース規格の信号フォーマットに変換して送信する、
   モーション制御装置。
   
   

Images