JP2020098608A - モーション制御プログラム、モーション制御方法及びモーション制御装置 - 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）１１、メモリ１２、ＨＤＤ（HardDis
k）やＳＳＤ（Solid State Drive）等の記憶装置１３、有線又は無線通信を行う通信ＩＦ
（Interface）１４、入力操作を受け付ける入力デバイス１５、及び情報の出力を行う出
力デバイス１６を有する。入力デバイス１５は、例えば、キーボード、タッチパネル、マ
ウス及び／又はマイク等である。出力デバイス１６は、例えば、ディスプレイ及び／又は
スピーカ等である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (9)

1. 非リアルタイムＯＳ及びリアルタイムＯＳがインストールされ、制御対象装置をモーシ
   ョン制御するためのコンピュータで実行されるモーション制御プログラムであって、
   前記コンピュータを、
   前記非リアルタイムＯＳ上で動作する受付部と、
   前記リアルタイムＯＳ上で動作する格納部と、
   前記リアルタイムＯＳ上で動作する指令処理部と、
   前記リアルタイムＯＳ上で動作する定周期処理部と、
   して機能させ、
   前記受付部は、前記制御対象装置を制御するユーザ作成プログラムから、前記制御対象
   装置が複数のモーション制御サイクルに渡って行うべき動作を示す制御指令を受け付け、
   受け付けた制御指令の内容を示す制御指令情報を、前記非リアルタイムＯＳ及び前記リア
   ルタイムＯＳから参照可能な共有メモリに確保される制御指令用チャネルに格納し、
   前記格納部は、前記制御指令用チャネルから前記制御指令情報を取得して、取得した前
   記制御指令情報を、ＦＩＦＯキューに格納し、
   前記指令処理部は、前記ＦＩＦＯキューから前記制御指令情報を取出して前記定周期処
   理部に渡す、取出し処理を行い、
   前記定周期処理部は、前記指令処理部から渡される前記制御指令情報に基づいて、前記
   制御対象装置に対して前記モーション制御サイクルごとに実行させるべき動作を示す補間
   指令を前記モーション制御サイクルごとに送信することで、前記制御対象装置をモーショ
   ン制御する、
   モーション制御プログラム。
2. 前記コンピュータを、更に、
   前記リアルタイムＯＳ上で動作し、前記受付部からの指示を受けた場合に、前記共有メ
   モリに前記制御指令用チャネルを確保するチャネル管理部と、
   して機能させる、
   請求項１に記載のモーション制御プログラム。
3. 前記受付部は、前記ユーザ作成プログラムから、前記制御対象装置へのモーション制御
   を開始するための準備を行うことの指示を受けた場合に、前記チャネル管理部に対して、
   前記制御指令用チャネルの確保を指示する、
   請求項２に記載のモーション制御プログラム。
4. 前記コンピュータを、更に、
   前記リアルタイムＯＳ上で動作し、前記受付部からの指示を受けた場合に、前記リアル
   タイムＯＳのメモリ領域に前記ＦＩＦＯキューを生成するキュー生成部と、
   して機能させる、
   請求項１乃至３のいずれか一項に記載のモーション制御プログラム。
5. 前記受付部は、前記ユーザ作成プログラムから前記ＦＩＦＯキューの生成を行うことの
   指示を受け付けた場合、前記キュー生成部に対して、前記ＦＩＦＯキューの生成を指示す
   る、
   請求項４に記載のモーション制御プログラム。
6. 前記受付部は、前記ユーザ作成プログラムから、前記取出し処理を開始すべきことを前
   記指令処理部に指示し、
   前記指令処理部は、前記指示を受けた場合に、前記ＦＩＦＯキューに格納される前記制
   御指令情報を取得して前記定周期処理部に渡す、
   請求項１乃至５のいずれか一項に記載のモーション制御プログラム。
7. 前記定周期処理部は、前記制御対象装置から取得した、前記制御対象装置の状態を示す
   フィードバック情報を、前記共有メモリに確保される状態チャネルに格納し、
   前記受付部は、前記ユーザ作成プログラムから指示を受けた場合に、前記状態チャネル
   から前記フィードバック情報を取得して前記ユーザ作成プログラムに渡す、
   請求項１乃至６のいずれか一項に記載のモーション制御プログラム。
8. 非リアルタイムＯＳ及びリアルタイムＯＳがインストールされ、制御対象装置をモーシ
   ョン制御するためのモーション制御装置が行うモーション制御方法であって、
   前記モーション制御装置は、
   前記非リアルタイムＯＳ上で動作する受付部と、
   前記リアルタイムＯＳ上で動作する格納部と、
   前記リアルタイムＯＳ上で動作する指令処理部と、
   前記リアルタイムＯＳ上で動作する定周期処理部と、
   を有し、
   前記受付部が、前記制御対象装置を制御するユーザ作成プログラムから、前記制御対象
   装置が複数のモーション制御サイクルに渡って行うべき動作を示す制御指令を受け付け、
   受け付けた制御指令の内容を示す制御指令情報を、前記非リアルタイムＯＳ及び前記リア
   ルタイムＯＳから参照可能な共有メモリに確保される制御指令用チャネルに格納するステ
   ップと、
   前記格納部が、前記制御指令用チャネルから前記制御指令情報を取得して、取得した前
   記制御指令情報を、ＦＩＦＯキューに格納するステップと、
   前記指令処理部が、前記ＦＩＦＯキューから前記制御指令情報を取出して前記定周期処
   理部に渡すステップと、
   前記定周期処理部が、前記指令処理部から渡される前記制御指令情報に基づいて、前記
   制御対象装置に対して前記モーション制御サイクルごとに実行させるべき動作を示す補間
   指令を前記モーション制御サイクルごとに送信することで、前記制御対象装置をモーショ
   ン制御するステップと、
   を含むモーション制御方法。
9. 非リアルタイムＯＳ及びリアルタイムＯＳがインストールされ、制御対象装置をモーシ
   ョン制御するためのモーション制御装置であって、
   前記非リアルタイムＯＳ上で動作する受付部と、
   前記リアルタイムＯＳ上で動作する格納部と、
   前記リアルタイムＯＳ上で動作する指令処理部と、
   前記リアルタイムＯＳ上で動作する定周期処理部と、
   を有し、
   前記受付部は、前記制御対象装置を制御するユーザ作成プログラムから、前記制御対象
   装置が複数のモーション制御サイクルに渡って行うべき動作を示す制御指令を受け付け、
   受け付けた制御指令の内容を示す制御指令情報を、前記非リアルタイムＯＳ及び前記リア
   ルタイムＯＳから参照可能な共有メモリに確保される制御指令用チャネルに格納し、
   前記格納部は、前記制御指令用チャネルから前記制御指令情報を取得して、取得した前
   記制御指令情報を、ＦＩＦＯキューに格納し、
   前記指令処理部は、前記ＦＩＦＯキューから前記制御指令情報を取出して前記定周期処
   理部に渡す、取出し処理を行い、
   前記定周期処理部は、前記指令処理部から渡される前記制御指令情報に基づいて、前記
   制御対象装置に対して前記モーション制御サイクルごとに実行させるべき動作を示す補間
   指令を前記モーション制御サイクルごとに送信することで、前記制御対象装置をモーショ
   ン制御する、
   モーション制御装置。

Images