JP5026413B2 - 拡張可能な動作制御システム - Google Patents

Description

クロスリファレンス

関連出願への相互参照
本出願は、その全体が参照として本願明細書に引用されており、２００５年６月８日に出願された米国仮出願第６０／６８８，６３６の優先権を主張する。

開示された実施例は、複雑な複数軸非リニアマシン用制御システムに関し、特に、性能、柔軟性及び拡張性についての所望の組合せを有する精密ロボットの正確な同期制御用システムに関する。

エレクトロニクス及び通信の領域における技術的進歩の結果として、複雑な動作システムに対する制御テクノロジーは、ネットワークアーキテクチャに向けた明確な方向に進んで来た。ネットワークソリューションは、リモートコントローラと称される複数の簡単なコントローラを利用し、リモートコントローラはモータ及び他のアクチュエータなどの制御対象の構成要素の近くに位置して通信ネットワークを介してマスタコントローラによって統合される。

ネットワークアーキテクチャは、マスタコントローラとリモートコントローラとの間の制御情報の分配、高度な制御アルゴリズムの実施、通信ネットワークの利用、異なるリモートコントローラによって駆動される構成要素の同期、動作の複数軸の位置取得などの複数のリモートコントローラへの入力と関係するイベントの処理、作業空間における人的存在の適応、及び電力損失状況の処理といった領域における多数のチャレンジを開く。

マスタコントローラとリモートコントローラとの間の制御情報の分配は、制御アルゴリズムの全てまたは大部分がマスタコントローラ上で実行される完全な集中型アーキテクチャから、制御アルゴリズムが実質的に自律リモートコントローラ上で実施される分散型ソリューションへ変化してもよい。

非常に集中化されたアーキテクチャの利点は、高度な制御アルゴリズムを提供する能力を含む。それはしばしば、マルチ入力マルチ出力（ＭＩＭＯ）制御などの、複数軸からのリアルタイム情報を必要とし、マスタコントローラ上で実施され得ることが都合がよい。この種のアーキテクチャにおけるリモートコントローラは、比較的低い計算能力及び少量のオンボードメモリを必要とし、相対的に簡単で費用のかからない設計を可能にする。

これらの利点は、リモートコントローラとマスタコントローラとの間の集中的でタイムクリティカルなデータ交換のせいで通信ネットワークの相対的に高い利用度を犠牲にして実現されるかもしれない。なんとなれば、マスタコントローラは、制御ループを閉じているからである。これらのシステムは、通常、限定された拡張性を有する。なんとなれば、軸の最大数は、通信ネットワークの帯域幅だけでなくマスタコントローラの計算能力によって制約されるからである。さらに、リモートコントローラは、通信ネットワークの障害の場合にそれぞれの動作軸の制御された停止を実施することなどの、障害関連のオペレーションなどを自律的に支援するための十分な情報を有していないかもしれないので、障害の場合には満足できる制御を実現するのは疑わしいかもしれない。

対照的に、マスタコントローラから受信した軌道情報で実行している、リモートコントローラ上で制御ループを閉じている分散制御アルゴリズムを備えた制御システムは、比較的低いネットワークトラフィック及び、リモートコントローラにおいてバッファされて通信ネットワークの全体の容量限界を改善することが都合がよいかもしれない実質的に少ないタイムクリティカルデータを利用する。この方法は、制御システムの所望の拡張性を提供してもよい。なんとなれば、追加の軸に対するリモートコントローラの数を増加することは、制御ループの実行に対して利用可能な全体の計算能力を自動的に高めるからである。さらに、単純な軌道を生成して制御アルゴリズムを実行することが可能なリモートコントローラは、通信ネットワークの障害の場合には、制御された停止などの障害関連オペレーションを支援するための十分な情報を有する。

しかしながら、分散型アーキテクチャにおけるリモートコントローラについての追加情報は、より高い計算能力及びメモリを必要とする。それは、概してリモートコントローラをより高価にする。同様に、十分なＭＩＭＯ制御アルゴリズムの実施は、疑問がある。なんとなれば、１つのリモートコントローラ上で起動している制御アルゴリズムは、概して、他のリモートコントローラによって駆動される軸の状態へのリアルタイムのアクセスができないからである。

ネットワーク制御システムの実施は、概して、適当な性能を備えた通信ネットワークを用いることによって容易にされる。「ファイヤーワイヤー（登録商標）」としても周知であるＩＥＥＥ １３９４通信ネットワークは、高速シリアルバスに基づいている。それは最新のパラレルバスと同じサービスだが実質的により低コストで提供するよう開発された。ＩＥＥＥ １３９４ｂ−２００２修正条項は、下位互換性のある方法におけるギガビット速度拡張及びバストポロジーにおける物理ループの検出を提供する特徴とメカニズム、並びに物理層（ＰＨＹ）ポートの選択的な無効によるそれらのその後の解決とを定義する。軽量ＩＥＥＥ １３９４プロトコルは、１３９４トレードアソシエーション（the 1394 Trade Association）による電子計装及び産業用制御機器に対する効率的な非同期通信のために開発された。ＩＩＣＰ（the Instrument and Industrial Control Protocol）と称されて、それはフロー制御された方法でデータ及びコマンド／制御シーケンスを転送するためのデュアル−デュプレックスプラグ構造を用いる。

精密ロボットの正確な同期化制御用制御システムは、概して、ある程度のレベルのシステム保全を必要とする。即ち、制御システムは、インターロック、フェ−ルセーフメカニズム、最小１００％動作可能時間の維持メカニズム、製造される製品に対する損傷を避けるメカニズム及び技術、及び、制御システムの作業空間における人的存在を適応させるメカニズム及び技術を必要とするかもしれない。

特定のレベルのインテグリティを備えたプログラム可能なシステムを実行する最先端のエレクトロニクス及びコンピュータは、高性能の産業用機械及び処理への市場に出回る傾向がある。これらの種類のシステムは、概して、例えば、ＥＮ９５４ カテゴリ ４またはＩＥＣ６１５０８ ＳＩＬ ３などのより厳密なカテゴリに適応可能であり、高性能プロセッサまたは組み込みＣＰＵのプロセッサを用いる。これらの種類のシステムは、概して高価であり、例えばカテゴリ２または３などのより低いレベルのインテグリティを必要としている低価格の機械またはシステムに対して必要とされるよりも高い性能を有する。

プログラム可能なインテグリティに対する替わりの解決法を実施して専門の高性能エレクトロニクスに対する追加の費用を避けたい機械設計者は、制御システムのエレクトロニクス、ネットワーク及びソフトウェアをインテグリティ要求に適合させること及び監督機関または監査員の承認を得ることという極端に複雑な作業に直面させられる。規定のレベルのインテグリティを実行する既存の技術での他の問題は、寸法及び形状因子である。それらは、厳しい空間制約を有するインテグリティアプリケーションに対して不適当である。

集中化されていてかつ分散されているアーキテクチャの利点を有する制御システムの必要性がある。それは柔軟で拡張性があって、構成要素の動作を同期させ、制御を受ける構成要素の作業空間における電力損失及び人的存在を適応させ、必要なシステムインテグリティレベルを提供する。

開示された実施例は、マスタコントローラと、マスタコントローラの直接制御下にある１つ以上の第１リモートコントローラを含む中央制御部と、マスタコントローラによって制御されるクラスタコントローラを含む分散制御部と、を有するクラスタ化されたアーキテクチャを含む制御システムを対象とし、クラスタコントローラは、１つ以上の第２リモートコントローラの働きを制御する。第１及び第２リモートコントローラの各々は、１つ以上の軸を駆動するために利用される。

開示された実施例はまた、制御システムの軸を作動する方法を対象とし、それは、軌道上の複数のポイントのうちの各々のポイントに対する位置、速度及び加速に関して軸に対する軌道を生成するステップと、各々のポイントに対する利得値及びフィードフォワードターム（term）を決定するための軸の逆ダイナミクスモデルを算出するステップを含む。

開示された実施例はまた、ネットワーク上のノードを同期させる方法を対象とし、メッセージが送出された時間を示すタイムスタンプを含む開始メッセージを発行するステップと、タイムスタンプを用いて高分解能クロックを更新するステップと、タイムスタンプによって示された時間と高分解能クロックが更新された時間との間の差分を補償するステップと、を含む。

開示された実施例はまた更に、制御システムのノードの間で通信するためのメッセージセットを対象とする。それは、コマンド及びコマンド応答を交換するためのアクションメッセージ、予め定められたイベントに関係するデータをマスタコントローラに報告するためのイベントメッセージ、リモートコントローラとマスタコントローラとの間でシリアルメッセージチャネルを提供するためのストリングメッセージ、及びネットワークノードへデータを送出するためのデータポートメッセージを含む。

開示された実施例はまた、イベント時の軸データを得る方法を含む。それは、１つ以上の軸ノードでデータをバッファリングすること、１つ以上の軸ノードのうちのトリガイベントノードにおいて生じるトリガイベントの時間情報を記録すること、及びバッファリングされたデータを処理して記録された時間情報によって示される期間における一組の値を決定することを含む。

開示された実施例はまた更に、クラスタ化アーキテクチャにおいて組織化された複数のノード及びノードの２つ以上が通信する無線通信ネットワークを有する制御システムを対象とする。

開示された実施例はまた、制御システムの軸を制御する方法を含む。それは、軸のエンドエフェクタに対するオペレーティングパラメータ値を計算するステップと、エンドエフェクタに対する動作プロファイルがオペレーティングパラメータ値を超えないように軸の個々の結合に対する動作プロファイルを生成するステップと、を含む。

軸を制御する方法も開示される。それは、軸位置に対する速度及びトルクを算出するステップと、軸速度が算出された速度を超えてもよい第１の最大期間を予め決定するステップと、軸トルクが算出されたトルクを超える第２の最大期間を予め決定するステップと、第１または第２の最大期間を超える場合に軸を無効にするステップと、を含む。

ここで開示された別の実施例は、制御システムネットワークを介して送信されるデータのインテグリティを確認する方法を含む。該方法は、ネットワーク上のノードにおいて動作パラメータを記憶するステップと、ネットワークを介して受信されるコマンドが動作パラメータを超えるノードの動作を生じさせないということを確認するステップと、を含む。

開示された実施例の一部として制御システムネットワークのインテグリティを確認する方法は、周期的なメッセージを発行するステップと、メッセージが期間内に受信されない場合に制御システムネットワークの１つ以上のノードを無効にするステップと、を含む。

開示された実施例はまた、制御システムネットワークのインテグリティを維持する方法を含む。それは、ネットワークのノードをゾーンに割り当てて第1のゾーンの動作が第１ゾーン以外のゾーンにおける動作から切り離されるステップと、ゾーンを制御して第１のゾーンのイベントが第１のゾーン以外のゾーンのオペレーションに影響を与えないこと、を含む。

本実施例はまた、軸を制御された停止の状態に至らせる方法を対象とする。それは、軸を含むシステムに対して電力が失われた否かを判断するステップと、予め定めた期間内に軸をゼロ速度の状態に至らせる軸への軌道を適用するステップと、予め定めた期間の終わりに軸から電力を除去するステップと、を含む。

ここで開示された実施例はまた、制御システムにおける同期遅延を補償する方法を含む。それは、メッセージを発行するネットワークノードとメッセージを受信するネットワークノードとの間の遅延を判断するステップと、判断された遅延を用いて受信ノードに対する軌道を調整するステップとを含む。

ロボットを操作する方法が開示される。それは、ロボットのアイドル時間を記録するステップと、アイドル時間閾値を超えるロボットの性能特性を判断するステップと、判断された性能特性が仕様を満たさない場合にウォーミングアップ運動を実施するようロボットに指示するステップと、を含む。

動作制御システムに対するアプリケーションプログラムインタフェースも開示された実施例に含まれ、動作制御システム構成要素の間で情報の交換するための標準化された一組のインタフェース協約と、オペレーション及び特定の引数を実施してオペレーションを実施するための特定の構成要素及び動作を識別するための一般的なコマンドを提供する汎用コマンドセットと、を含む。

発明を実施するための形態

開示された実施例の前述の態様及び他の特徴は以下の説明において説明され、添付の図面と関連して理解される。

図１は、ここで開示される実施例を実施するのに適しているシステム１００のブロック図を示す。開示される実施例は、図面に示される実施例を参照して説明されるが、開示される実施例は、多くの代替実施例形式で具体化されてもよいということが理解されるべきである。さらに、いかなる適当な寸法、形状、または、要素または材料の種類が用いられてもよい。

開示される実施例の制御システム１００は、ネットワーク化された制御システムにおいて集中化された制御情報の割り当ての利点と分散化された制御情報の割り当ての利点とを組み合わせる。この組合せアーキテクチャは、本願明細書においてクラスタ化アーキテクチャと称される。

クラスタ化アーキテクチャ制御システム１００は、マスタコントローラ１０５、１つ以上のクラスタコントローラ１１０、１つ以上のリモートコントローラ１１５、及び通信ネットワークを介して一緒に接続されている１つ以上の自律リモートコントローラ１５０を含む。マスタコントローラ１０５、クラスタコントローラ１１０、リモートコントローラ１１５及び自律リモートコントローラ１５０を、ネットワークノードと称してもよい。

図１に図示されているように、マスタコントローラ１０５は、制御システム１００の全体的なオペレーションを監督する。クラスタコントローラ１１０の各々は、１つ以上のリモートコントローラのオペレーションを監督し、リモートコントローラの各々は、１つ以上の軸１２５を駆動するために利用される。軸は、例えば、精度ロボットのシステムなどの、１つ以上の複合複数軸非リニアマシンの一部であってもよい。リモートコントローラ１１５は、クラスタコントローラによって制御されてもよく、自律リモートコントローラ１５０は、マスタコントローラ１０５によって直接作動されてもよい。リモートコントローラ１１５は、通常、クラスタ１３０においてグループ化される。

クラスタ化アーキテクチャ制御システム１００はまた、少なくとも１つのブリッジノード１３５を含んでもよく、それは、マスタコントローラがコントローラエリアネットワーク（ＣＡＮ）などの別の通信ネットワーク上のノードと通信することを可能にする。制御システムは、そのとき、例えば、ＣＡＮ軸コントローラ、グリッパ、ドア、アクチュエータ、センサ、その他のＣＡＮに基づくモジュール及び構成要素を制御することが可能でもよい。

クラスタ化アーキテクチャは、ネットワークトポロジの範囲内で必要な集中制御ネットワーク及び分散制御ネットワークの特徴を提供する。ネットワーク内で必要なクラスタ１３０が分散されてもよく、さらに各々のクラスタコントローラ１１０はそれが管理するクラスタ内で高度に集中化された制御を提供することができるので、本願明細書において開示されるアーキテクチャは有利である。高度に集中化された制御に関係するネットワークトラフィックは、通常、各々のクラスタ１３０内に限定されている。そして、自律リモートコントローラ１５０は、自律リモートコントローラ１５０が制御する軸の近くに位置してもよく、電力及び信号ケーブル布線と関係する問題を減少させる。また、該アーキテクチャは、必要とされるマスタコントローラ１０５による自律リモートコントローラ１５０の直接の制御を可能にする。さらに、強いネットワークトラフィックは、通常、クラスタ１３０内で限定されてクラスタ１３０が高レベルの制御が可能であるので、該アーキテクチャは、多数のクラスタを収容してもよい。このように、該アーキテクチャは、高レベルの拡張性を提供し、コントローラの効率的な分散を可能にする。

集中化制御の例として、マスタコントローラ１０５は自律リモートコントローラ１５０を直接制御してもよい。ここで、マスタコントローラは軌道を生成し、制御アルゴリズムを実行し、自律リモートコントローラ１５０によって実施されるトルクコマンドを提供してもよい。自律リモートコントローラ１５０は、また、モータなどの軸アクチュエータ１４０に電圧を印加するといった制御動作を生成するためにトルクコマンドを用いてもよい。自律リモートコントローラ１５０は、エンコーダなどのフィードバック器具１４５から位置情報及び軸１２５からの電流引き込みなどのフィードバック信号を読み込んで、フィードバック信号をマスタコントローラ１０５に伝達してもよい。この例では、高性能が実現されるとともに、ネットワーク利用度も高くてもよい。なんとなれば、制御ループ及びフィードバックループは、通信ネットワーク１２０を介して閉じられているからである。

分散化制御の例として、マスタコントローラ１０５は、１つ以上の自律リモートコントローラ１５０の間の働きを統合して、１つ以上の自律リモートコントローラ１５０による実施のための軌道データを生成してもよい。自律リモートコントローラ１５０は、リアルタイム制御アルゴリズムの軌道データを用いて軸アクチュエータ１４０への電力印加などの制御動作を生成し、またマスタコントローラ１０５に状態情報を伝達してもよい。この例では、フィードバック制御ループはリモートコントローラ上で閉じているので、ネットワーク利用度は低くてもよい。しかしながら、動的に結合された軸の制御性能は限定されていてもよい。なんとなれば、フィードバック制御ループは、通常、他のリモートコントローラ上に存在する情報にリアルタイムアクセスできないからである。

組合せクラスタ化制御の例として、マスタコントローラ１０５は、高レベル監視制御機能を実施して、１つ以上のクラスタコントローラ１１０の間の働きを統合してもよい。クラスタコントローラ１１０は、その制御下で軸の局所的な動的モデリングを含むリアルタイム制御アルゴリズムを実行させて、そのそれぞれのリモートコントローラ１１５にトルクコマンドを与えてもよい。クラスタコントローラ１１０によって管理されるリモートコントローラは、例えば、トルクコマンドに応答して軸アクチュエータ１４０に電力を印加してもよく、さらに、例えば、実際の位置などの、軸情報をクラスタコントローラ１１０に伝達してもよい。このように、ほとんどの制御及びフィードバック通信は、概して、クラスタコントローラ１１０とそのそれぞれのリモートコントローラ１１５との間で局所的に生じて、クラスタ外のノードの間でネットワーク利用を節約する。

クラスタ化アーキテクチャは、概して、全通信ネットワーク１２０に重大でタイムクリティカルなトラフィックを負わせることなしに必要な構成要素のサブセットに対する高性能制御を提供する。

ここで図２に戻ると、マスタコントローラ１０５がより詳細に説明される。上記したように、マスタコントローラ１０５は、クラスタ化アーキテクチャ制御システム１００のオペレーションを制御する。マスタコントローラ１０５は、概して、プロセッサ２０５、リードオンリメモリ２１０、ランダムアクセスメモリ２１５、プログラム記憶装置２２０、ユーザインタフェース２２５、及びネットワークインタフェース２３０を含んでもよい。

プロセッサ２０５は、オンボードキャッシュ２３５を含んでいてもよく、通常、オンボードキャッシュ２３５、リードオンリメモリ２１０、ランダムアクセスメモリ２１５、及びプログラム記憶装置２２０などのコンピュータ使用可能媒体といったコンピュータプログラム製品から、情報及びプログラムを読み込むことができる。

電源を入れると、プロセッサ２０５は、リードオンリメモリ２１０の中にあるオペレーティングプログラムを開始し、初期化の後に、プログラム記憶装置２２０からランダムアクセスメモリ２１５への命令をロードし、それらのプログラムの制御下で動作してもよい。頻繁に用いられる命令は、オンボードキャッシュ２３５の中に一時的に記憶されてもよい。リードオンリメモリ２１０及びランダムアクセスメモリ２１５の両方は、半導体技術または、その他の材料及び技術を利用してもよい。プログラム記憶装置２２０は、ディスケット、コンピュータのハードドライブ、コンパクトディスク（ＣＤ）、デジタル多様途ディスク（ＤＶＤ）、光ディスク、チップ、半導体またはコンピュータが読み込み可能なコードの形式でプログラムを記憶することができるその他のデバイスを含んでもよい。

オンボードキャッシュ２３５、リードオンリメモリ２１０、ランダムアクセスメモリ２１５及びプログラム記憶装置２２０のいずれか個々に、または、いずれの組合せでも、オペレーティングシステムプログラムを含んでもよい。オペレーティングシステムプログラムは、任意のリアルタイムオペレーティングシステムを追加されて、マスタコントローラ１０５によって提供されるデータの質を改善してもよい。任意のリアルタイムオペレーティングシステムも、マスタコントローラ１０５が、クラスタコントローラ１１０及び自律リモートコントローラ１５０から受信したデータ及びメッセージへの保証応答時間を提供することを可能にしてもよい。

特に、オンボードキャッシュ２３５、リードオンリメモリ２１０、ランダムアクセスメモリ２１５及びプログラム記憶装置２２０の、いずれか個々、または、いずれの組合せも、軸軌道生成、動的モデリング、エラー処理、データ収集及びメッセージング設備のためのプログラムを含んでもよい。メッセージング設備は、ネットワークノードの間でメッセージを構築して交換するプログラム、フレームを構築して交換するプログラムを含んでもよく、以下に開示されるように、アプリケーションプログラムインタフェースを提供するためのプログラムを含んでもよい。さらに、オンボードキャッシュ２３５、リードオンリメモリ２１０、ランダムアクセスメモリ２１５及びプログラム記憶装置２２０は、例えばネットワークインタフェース２３０を介してプロセッサ２０５によって、新規またはアップグレードされたプログラムをロードされてもよい。

ネットワークインタフェース２３０は、概して、マスタコントローラ１０５と通信ネットワーク１２０との間のインタフェースを設けるようになされていてもよい。通信ネットワーク１２０は、公共交換電話網（ＰＳＴＮ）、インターネット、無線ネットワーク、有線ネットワーク、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、仮想プライベートネットワーク（ＶＰＮ）、その他を含んでもよく、さらに、Ｘ．２５、ＴＣＰ／ＩＰ、ＡＴＭ、その他を含む他の種類のネットワークを含んでもよい。１つの実施例では、通信ネットワーク１２０は、「ファイヤーワイヤー」ネットワークとも称されるＩＥＥＥ １３４９ネットワークであってもよい。

マスタコントローラ１０５は、ディスプレイ２４０を備えたユーザインタフェース２２５及び、例えばキーボード２５５またはマウス２４５などの入力装置を含んでいてもよい。ユーザインタフェースは、プロセッサ２０５の制御下でユーザインタフェースコントローラ２５０によって作動されてもよい。ユーザインタフェースコントローラは、また、外部ネットワーク、他の制御システムまたはホストコンピュータへの接続またはインタフェース２５５を提供してもよい。

マスタコントローラ１０５は、概して、クラスタ化アーキテクチャ制御システム１００に対する高レベルの監視機能及び制御機能を実行してもよい。これらの機能は、オペレータ及び／または高レベルホストコンピュータとの通信インタフェース、コンフィグレーションデータ管理、クラスタ及びリモートコントローラの統合、運動シーケンス及び軌道生成、動的モデリング（必要であれば）、エラー処理及びデータロギングを提供することを含んでいてもよい。

ここで図３に戻ると、クラスタコントローラ１１０の構造及びオペレーションが説明されている。単一のクラスタコントローラ１１０が説明されるが、クラスタ化アーキテクチャ制御システム１００はいかなる数のクラスタコントローラを含んでもよいということが理解されるべきである。

先に述べたように、クラスタコントローラ１１０は、マスタコントローラ１０５から情報を受信してもよく、その情報を利用して１つ以上の軸１２５を制御してもよい。クラスタコントローラ１１０は、通常、プロセッサ３０５、リードオンリメモリ３１０、ランダムアクセスメモリ３１５、プログラム記憶装置３２０、及び通信ネットワーク１２０へのネットワークインタフェース３３０を含んでいてもよい。プロセッサ３０５は、また、オンボードプログラマブルメモリ３３５を含んでいてもよい。

プロセッサ３０５は、通常、オンボードプログラマブルメモリ３３５、リードオンリメモリ３１０、ランダムアクセスメモリ３１５、及びプログラム記憶装置３２０などのコンピュータ使用可能媒体のようなコンピュータプログラム製品から情報及びプログラムを読み込むことができる。

オンボードプログラマブルメモリ３３５、リードオンリメモリ３１０、ランダムアクセスメモリ３１５、及びプログラム記憶装置３２０は、ネットワークノードの間でメッセージを作成して交換するプログラムを含んでいてもよく、ネットワークノードの間のアプリケーションプログラムインタフェースを支持するプログラムを含んでいてもよい。オンボードプログラマブルメモリ３３５、リードオンリメモリ３１０、ランダムアクセスメモリ３１５、及びプログラム記憶装置３２０はまた、クラスタコントローラ１１０がマスタコントローラ１０５から動作コマンドを受信することを可能にするプログラムを、通常、少なくとも位置、速度及びタイムスタンプ（ＰＶＴフレーム）を有するフレームの形式で含んでいてもよい。フレームは、以下に説明するように、例えば、フィードフォワードターム、利得ターム、または両方などの他のデータを含んでいてもよい。ランダムアクセスメモリ３１５及びプログラム記憶装置３２０はまた、受信時にフレームを個々にまたは一緒にバッファリングすることができてもよい。

プログラム制御下で、クラスタコントローラ１１０は、クラスタコントローラ１１０が制御する軸の動的モデルを含むリアルタイム制御アルゴリズムを用いてフレームに含まれるデータで動作し、クラスタコントローラ１１０の特定のクラスタの一部であるリモートコントローラ１１５に対するトルクコマンドを算出してもよい。クラスタコントローラ１１０は、例えば、実際の軸位置、エラー表示、その他などのリモートコントローラ１１５からのデータを得てもよく、さらに、マスタコントローラ１０５へデータを報告してもよい。

リモートコントローラ１１５及び自律リモートコントローラ１５０の構造及びオペレーションが、図４を参照しつつ説明される。単一のリモートコントローラ１１５、１５０が説明されるが、クラスタ化アーキテクチャ制御システム１００は複数のリモートコントローラ１１５及び自律リモートコントローラ１５０を含んでもよいということが理解されるべきである。この検討のために、リモートコントローラ１１５及び自律リモートコントローラ１５０は、リモートコントローラ１１５、１５０と称される。いくつかの実施例では、リモートコントローラ１１５は、自律リモートコントローラ１５０として動作する能力を有していてもよく、自律リモートコントローラ１５０は、リモートコントローラ１１５として動作する能力を有していてもよい。

リモートコントローラ１１５、１５０は通常、駆動し、１つ以上の軸から位置情報を受信することができる。特に、リモートコントローラは、例えばモータ巻線に電力を供給するための１つ以上のループ電流を駆動し、通常、運動制御ループを実施し、さらにリアルタイムでデータを収集する、単一または複数軸制御が可能であってもよい。リモートコントローラ１１５、１５０は、マスタコントローラ１０５またはクラスタコントローラ１１０からのコマンドを受信しかつそれらに情報を与えてもよい。

リモートコントローラ１１５、１５０は、プロセッサ４０５、半導体メモリデバイス４１０、非半導体メモリ４１５、及びネットワークインタフェース４２０を含んでいてもよい。リモートコントローラ１１５、１５０はまた、１つ以上の軸１２５（図１）に電力を印加する回路４２５及びドライバ４３０を含んでいてもよい。リモートコントローラ１１５、１５０は、１つ以上の軸１２５の各々から、軸位置情報４４０を受信する回路４３５を更に含んでもいてよい。位置情報は、軸１２５の一部であってもよい１つ以上のエンコーダ１４５から出力されてもよい。

プロセッサ４０５は通常、半導体メモリ４１０及び非半導体メモリ４１５などのコンピュータ使用可能媒体のようなコンピュータプログラム製品上に記憶されたプログラムの制御下で動作する。非半導体メモリ４１５は、ディスケット、コンピュータのハードドライブ、コンパクトディスク（ＣＤ）、デジタル他用途ディスク（ＤＶＤ）、光ディスク、またはコンピュータが読み込み可能なコード形式でプログラムを記憶することができる他のいかなるデバイスを含んでもよい。

半導体メモリ４１０及び非半導体メモリ４１５のいずれか個々にまたはいずれの組合せでも、リモートコントローラオペレーティングシステムプログラムを含んでいてもよい。半導体メモリ４１０及び非半導体メモリ４１５のいずれか個々にまたは組合せはまた、ネットワークノードの間でメッセージを作成して交換するためのプログラムを含んでいてもよく、さらに、ネットワークノードの間のアプリケーションプログラムインタフェースを支持するプログラムを含んでいてもよい。特に、半導体メモリ４１０及び非半導体メモリ４１５のいずれか個々にまたは組合せはでも、トルクモードオペレーション、セットポイントモードオペレーション及びリモートコントローラ１１５、１５０のポイントツーポイントモードオペレーションのうちの少なくとも１つに対するプログラムを含んでいてもよい。さらに、半導体メモリ４１０及び非半導体メモリ４１５はいずれか個々にまたは組合せでも、以下に説明されるように、受信時にフレームをバッファリングすることができてもよい。

リモートコントローラ１１５は、クラスタコントローラによって制御されるときに、トルクモードで動作してもよい。上記したように、クラスタコントローラ１１０は、通常、マスタコントローラからデータフレームを受信して、それらを利用してそのクラスタにおけるリモーコントローラに対するトルクコマンドを算出する。各々のリモートコントローラ１１５は、そのそれぞれのトルクコマンドを実行するのに必要な制御機能を実行してもよい。

例えば、リモートコントローラ１１５は、モータ数、モータ毎の位相、位相抵抗、逆起電力定数、その他などの、リモートコントローラが制御する軸または複数軸の特徴を用いて事前プログラムされてもよい。クラスタコントローラ１１０は、例えばモータなどのアクチュエータ１４０が与えるべきトルクを指示しているリモートコントローラ１１５へのコマンドを発行してもよい。リモートコントローラ１１５は、アクチュエータ１４０に所望のトルクを与えさせる事前プログラムされた特性を用いて特定の期間アクチュエータ１４０に印加されるべき電圧、電流または電力を算出してもよい。

リモートコントローラ１１５も、例えば、リモートコントローラ１１５によって制御される軸の実際の位置などのトルクコマンドを決定するためにクラスタコントローラ１１０へ情報を提供してもよい。エンコーダ１４５は、例えばエンコーダカウントまたはステップの数、角度測定、その他などの生の位置情報をリモートコントローラ１１５に供給することができ、そこからリモートコントローラ１１５が実際の位置情報を算出してもよい。このように、クラスタコントローラ１１０及びリモートコントローラ１１５の組合せは、マスタコントローラ１０５からフレームの形式で相対的に高レベルのコマンドのより少ない数を受信し、次に相対的に多数のコマンドを交換してそれら自身の間でフィードバックしてフレームによって命令された動作を実行してもよい。

マスタコントローラ１０５の制御下で動作している場合、リモートコントローラは、上記したように自律リモートコントローラ１５０とも称されてもよい。自律リモートコントローラ１５０は、セットポイントモードで動作してもよい。セットポイントモードでは、マスタコントローラ１０５は、自律リモートコントローラ１５０に、軌道データを送出してもよい。例えば、軌道データは、通常、特定の軸に対する位置、速度、及び時間スタンプのデジタル表現を含んでいてもよい。

自律リモートコントローラ１５０は、リアルタイムアルゴリズムを実行して、軸に所望の軌道に従って移動させる、軸１２５に対する一組の関連するトルクコマンドを決定してもよい。自律リモートコントローラ１５０は、次に、トルクコマンドを用いて、アクチュエータ１４０に従って印加される電力を算出してもよい。セットポイントモードでは、自律リモートコントローラ１５０は、通常、クラスタコントローラの機能のいくつかを実施してもよく、それ自体とそれが制御する軸との間の制御ループを閉じて、通信ネットワーク１２０の帯域を節約してもよい。

替わりに、自律リモートコントローラ１５０は、マスタコントローラ１０５の制御下で、ポイントツーポイントモードで動作してもよい。このモードでは、自律リモートコントローラ１５０は、マスタコントローラ１０５から動作コマンドを受信して、動作コマンドを実行するために必要なオペレーションを実行してもよい。典型的な動作コマンドは、軸の作業空間における三次元ポイントを含んでいてもよい。動作コマンドを実行するために必要なオペレーションは、軸が三次元ポイントに至るように、軌道を算出すること、トルクコマンドを算出すること、及び自律リモートコントローラ１５０によって制御される軸のモータに印加される必要な電力を算出することのうちの１つ以上を含んでいてもよい。

ポイントツーポイント動作コマンドに応答して、自律リモートコントローラ１５０は、コマンドの結果を報告する応答を送出してもよい。マスタコントローラ１０５は、次に、次の三次元ポイントを備えた別のポイントツーポイントコマンドを送出してもよい。この交換は、自律リモートコントローラ１５０が所望の一連の動作コマンドを実行するまで進んでもよい。ポイントツーポイント動作モードは、データフレームの数とは対照的に、自律リモートコントローラ１５０へ送信されたデータを運動コマンド毎に１つのエンドポイントに限定することをマスタコントローラ１０５に可能にし、よって、ネットワーク帯域を保つ。しかしながら、ポイントツーポイント動作モードにおいて、マスタコントローラ１０５は、多くの自律リモートコントローラ１５０によって実行される軌道の正確な同期という能力を失う。

クラスタ化アーキテクチャ制御システムの典型的なアプリケーションは、図５ａに示される。制御システムを組み込んでいるワークセル５０５は、２つのロボット５１０、５２０及び２つの基板アライナ５１５、５２０を含む。クラスタコントローラ５４０及び３つのリモートコントローラ５５０、５５５、５６０はロボット５１０を制御するために用いられる。同様に、他のクラスタコントローラ５４５及び３つのリモートコントローラ５６５、５７０、５７５は、ロボット５２０を制御するために用いられる。マスタコントローラ５８０は、基板アライナ５１５、５２５のための自律リモートコントローラ５８５、５９０だけでなく２つのクラスタコントローラ５４０、５４５を制御する。マスタコントローラ５８０、クラスタコントローラ５４０、５４５、リモートコントローラ５５０、５５５、５６０、５６５、５７０、５７５及び自律リモートコントローラ５８５、５９０は、通信ネットワーク５９５によって接続されている。

アライナ５１５、５２５が２軸マシンであってもよいとともに、ロボット５１０、５２０は複数の非リニア動力学を有する５軸マシンであってもよい。この例では、ロボット５１０、５２０は指示された位置から基板５３０、５３５を取り上げて、それらをそれぞれアライナ５２５、５１５の上に配置する。アライナ５２５、５１５は、基板５３０、５３５を偏心及びアラインメント特徴を求めてスキャンしてもよい。スキャン後、ロボット５１０、５２０は、基板５３０、５３５を取り上げてそれらをほかの場所に配置してもよい。１つの実施例では、ワークセル５０５は、クラスタ化アーキテクチャ制御システム１００の一部であってもよい（図１）。

ワークセルのスループットを最大化しかつ衝突のないオペレーションを保証するために、マシンの動作、即ち、ロボット５１０、５２０及び基板アライナ５１５、５２５は、正確に同期しなければならない。ロボット５１０、５２０及び基板アライナ５１５、５２５のいずれかの間の動的接続はなくてもよい。各々は、リアルタイムデータの共有なしで独立制御アルゴリズムを用いてもよい。しかしながら、ロボット５１０、５２０の機械構成は、各々のロボットマニピュレータ内で個々の軸の間の強い動的接続をもたらす。ロボット５１０の個々の軸間の連携は、リモートコントローラ５５０、５５５、５６０との組み合わせでクラスタコントローラ５４０によって管理されてもよい。ロボット５２０の個々の軸間の連携は、リモートコントローラ５６５、５７０、５７５との組み合わせでクラスタコントローラ５４５によって管理されてもよい。このように、クラスタコントローラ５４０及びリモートコントローラ５５０、５５５、５６０は１つのクラスタを形成し、クラスタコントローラ５４５及びリモートコントローラ５６５、５７０、５７５は別のクラスタを形成する。

図５ａに示されたワークセル５０５aでは、マスタコントローラ５８０は、通常、運動シークエンシング、データ収集、イベントロギング及びエラー処理などの監視機能を提供してもよい。さらに、それは、ワークセル５０５における全ての運動軸に対する軌道を算出してもよい。この例では、マスタコントローラ５８０は、算出結果を各々の個々の運動軸に固有なフレームにして、ネットワーク５９５を介して周期的にそれらを送出する。クラスタコントローラ５４０、５４５及び自律リモートコントローラ５８５、５９０は、それらが制御しその結果動作する軸に対するフレーム及びコマンドを認識する。

例えば、クラスタコントローラ５４０、５４５は、高度なマルチ入力マルチ出力制御に対するロボット５１０、５２０の動的モデルを利用し、トルクコマンドを算出し、それらのそれぞれのクラスタのリモートコントローラにそれらのトルクコマンドを周期的に送出してもよい。

自律リモートコントローラ５８５、５９０は、セットポイントモードで動作していてもよく、それぞれアライナ５１５、５２５に対する関連するトルクコマンドを決定するリアルタイムアルゴリズムを実行してもよい。自律リモートコントローラ５８５、５９０は、次にトルクコマンドを用いて、アライナ５１５、５２５の各々の範囲内でモータにそれに応じて印加されるべき電力を算出してもよい。

集中化制御アルゴリズムと関係する重大なリアルタイムトラフィックのそうでなければ支配下にある、特にマスタコントローラ５８０との接続であるネットワーク５９５の残りを負担することなしに、ネットワーク５９５を介して制御ループを閉じることと関係するタイムクリティカルなトラフィックは２つのクラスタの各々の範囲内に含まれるということに注意することが重要である。

注目すべきは、アーキテクチャは、必要とされる自律リモートコントローラ５８５、５９０をマスタコントローラ５８０が直接制御することを可能にするということである。アプリケーション例が、図５ｂに示される。多くのアプリケーションにおいて、性能は、以下に説明される分散モデルベース制御方法によって向上されてもよい。

ここで開示されたクラスタ化アーキテクチャ制御システムは、有益である。なんとなれば、各々のクラスタコントローラは、それが管理するクラスタの範囲内で高度に集中化された制御を提供することができるからである。非常に集中した制御に通常必要なネットワークトラフィックの大容量は、通常各々のクラスタに限定される。通信ネットワーク１２０内で必要なクラスタは分散されてもよく、リモートコントローラは、それらが制御する軸の近くに配置されてもよく、ケーブル敷設要求及び相当な長さに亘って制御信号を起動することと関係する問題を減少させる。

さらに、リアルタイムデータ通信はクラスタの範囲内に存在し、かつ強いネットワークトラフィックは通常クラスタの範囲内に限定されるので、クラスタは、高性能制御を行うことが可能で、該アーキテクチャは、マスタコントローラが多数のクラスタを監視することを可能にする。その結果、該アーキテクチャは、必要とされる高性能制御、高レベルの拡張性、及びコントローラの効率的な分散を提供する。

ロボット５１０またはアライナ５８５などのマシンを制御するために上記した１つの方法は、各々の軸に対する軌道を計算することである。前述のように、かかる軌道は、ＰＶＴフレームと称され、フレームへグループ化される一連の位置、速度及び時間の値によって画定されてもよいことが都合がよい。

図６は、典型的なＰＶＴフレーム６０５を示す。ＰＶＴフレーム６０５は、位置データ６１０、速度データ６１５及び時間データ６２０を含む。１つの実施例では、データは、１バイト以上でグループ化されたバイナリ形式である。別の実施例では、位置データ６１０、速度データ６１５、及び時間データ６２０の各々は、４バイトを占める。ＰＶＴフレーム６０５は、ヘッダ情報６２５及び末尾情報６３０を任意で含んでもよく、その両方は、同期、識別、パリティ、エラー修正、または他の種類のデータを含んでもよい。ＰＶＴフレーム６０５は、ヘッダの間又は中の長さ及び量、位置、速度、時間、末尾データを変化させる追加データを含んでもよい。図６は、フレームの特定の位置または領域における様々な情報またはデータを示すとともに、情報及びデータの異なる種類はＰＶＴフレーム６０５内のどこかに配置されてもよいということに注目すべきである。ＰＶＴフレーム６０５はいずれかの特定の長さに限定されないということに注目すべきである。

制御されるマシンの動的モデルに対する入力としてこれらの一連の値を用い、各々の軸に適用されるべき理論上のトルクを算出し、各々の軸が所望の軌道に従うということが開示された実施例の特徴である。動的モデルの構成要素を用いて、各々の軸に対するリモートコントローラによって用いられるフィードバック信号をスケーリングすることも開示された実施例の特徴である。

トルクターム及びスケーリングタームが、個々のマシン軸の間の非リニア及び動的クロス接続を説明することが有利である。トルクタームは、本願明細書でフィードフォワードタームと称される。なんとなれば、それは、位置または速度などの軸の実際の状態に依存しなくてもよいからである。スケーリングタームは、利得タームと称される。

例として図５ａのワークセルを用いると、マスタコントローラ５８０は、命令された位置、速度及び加速に関してロボット５１０の各々の軸に対する軌道を生成してもよい。ロボット５１０の逆の動的モデルを用いて、マスタコントローラは、軌道情報を利用して対応するフィードフォワードターム及び利得タームを生成してもよい。これらのターム（term）は、ＰＶＴ−ＦＧフレームと称されて、各々の軸に特有のフレームにおいて軌道情報とともにグループ化されてもよい。図７は、典型的なＰＶＴ−ＦＧフレーム７０５を示す。ＰＶＴ−ＦＧ７０５は、ＰＶＴフレーム６０５と同様に、任意のヘッダ７１０、位置７１５、速度７２０、時間７２５、及び任意の末尾情報７３０を含む。さらに、ＰＶＴ−ＦＧフレーム７０５は、少なくとも１つのフィードフォワードターム７３５及び少なくとも１つの利得ターム７４０を含む。データは、１バイト以上でグループ化されたバイナリ形式であってもよい。ＰＶＴ−ＦＧフレーム７０５の１つの実施例では、位置７１５、速度７２０、時間７２５、フィードフォワード７３５及び利得７４０タームの各々は４バイトを占有する。ＰＶＴフレームと同様に、ＰＶＴ−ＦＧフレーム７０５は、異なるタームの間又は中で分散された異なる長さまたは量の他のデータを含んでもよい。

ＰＶＴ−ＦＧフレームは次に、ネットワーク５９５を介して分配されてもよい。データを受信するクラスタコントローラ５４０は、２つの連続したフレームの間で補間して瞬間位置、速度、フィードフォワードターム及び利得値を得て、この情報を利用してロボット５１０を制御する。同様に、クラスタコントローラ５４５及び自律リモートコントローラ５８５、５９０は、マスタコントローラ５８０から対応するデータを受信して、それらを利用してそれぞれロボット５２０及びアライナ５１５、５２５を制御する。

フィードフォワードターム及び利得タームをもたらすための典型的な技術が、ここで詳細に説明される。以下の動的モデルが用いられてもよい。

ここでτ_ｉは、軸ｉに適用されたトルクを意味し、θ_ａｃｔｉ及びθ_ｃｍｄｉは、それぞれ軸ｉの実際の位置及び命令された位置である。｛θ_ａｃｔ｝及び｛θ_ｃｍｄ｝は、｛θ_ａｃｔ｝＝｛θ_ａｃｔ１，θ_ａｃｔ２，・・・，θ_ａｃｔｎ｝^Ｔ及び｛θ_ｃｍｄ｝＝｛θ_ｃｍｄ１，θ_ｃｍｄ２，・・・，θ_ｃｍｄｎ｝^Ｔと定義される位置ベクトルを表す。Ｍ_ｉｊは、軸ｉとｊとの間の慣性クロス接続を示す慣性マトリクス構成要素である。ｈ_ｉは、遠心性でコリオリで重力タームなどの軸ｉに対する他の位置及び速度依存動的効果を示す関数である。ｕ_ｉは軸ｉに対応するユニット慣性システムに対する制御低出力を表す。ｉは１からｎまで変化し、ｎは軸の全部の数または自由度である。点及び二点はそれぞれ第１及び第２時間導関数を表す。

位置及び速度追跡エラーが小であることを与えられて、実際の位置及び速度は、命令された量を用いて予測されてもよい。さらに、ｉ≠ｊに対するＭ_ｉｊｕ_ｊを無視すると、方程式（１）のダイナミクスは、以下の逆ダイナミクスモデルとして書き直されて予測されてもよい。

ここで、

Ｇ_ｉ及びＦ_ｉに対する上記の式は、それぞれ利得ターム及びフィードフォワードタームを定義する。 指数ｉは、フィードフォワードターム及び利得タームがその軸に適用されることを示す。制御性能をさらに改善するために、外乱オブザーバは、各々の軸に対して利用されて成された単純化を補償してもよい。

このロボット５１０例における、制御されたマシンに対する軌道及び逆ダイナミクスモデル計算は、マスタコントローラ５８０によって実施されてもよい。Ｇ_ｉ及びＦ_ｉに対する値が決定されると、マスタコントローラ５８０は、各々の軸に対するＰＶＴ−ＦＧフレームを組立てて、ネットワーク５９５を介してそれらをロボット５１０のクラスタコントローラ５４０に分配してもよい。

ロボット５１０のクラスタコントローラ５４０は、例えばそれ自体とリモートコントローラ５５０、５５５、５６０との間でトルクコマンドを送出してフィードバック信号を受信することによって、ロボット５１０を動作させるために、そのメモリに記憶された命令及びアルゴリズムを有していてもよい。マスタコントローラ５８０からのＰＶＴ−ＦＧフレームを用いて、クラスタコントローラ５４０は、リモートコントローラ５５０、５５５、５６０によって制御された各々の軸に対する改善されたトルクコマンドを算出する。トルクコマンドは改善されるべきと言われる。なんとなれば、方程式２の逆ダイナミクスモデル並びに方程式３及び４から得られるＧ_ｉターム及びＦ_ｉタームは、軸（例えば、Ｍ_ｉｊ）と位置及び速度依存効果（例えば、ｈ_ｉ）との間の慣性クロス接続を表す構成要素及び関数を少なくとも含むからである。このように、クラスタコントローラ５４０は、Ｇ_ｉターム及びＦ_ｉタームを用いてトルクコマンドを算出して、それらが関係する軸の動作をより正確に制御するトルクコマンドをもたらす。

一旦、改善されたトルクコマンドが算出されると、クラスタコントローラ５４０は次にそれらを適当なリモートコントローラ５５０、５５５、５６０に分配してもよい。リモートコントローラ５５０、５５５、５６０は、通常、モータの数、モータ毎の位相、位相抵抗、逆起電力定数、その他などの、それらが制御する軸の特性を用いてプログラムされてもよい。改善されたトルクコマンドに応答して、リモートコントローラ５５０、５５５、５６０は、それらが制御するモータに印加されるべき適当な電圧、電流、または電力を算出してもよい。

方程式２、方程式１を用いるアルゴリズムを含む様々なアルゴリズム及び従来の単一入力単一出力（ＳＩＳＯ）フィードバックアルゴリズムは、ロボット５１０と同様の５軸ロボットに適用されて、トラッキングエラーを比較し、それぞれ利得ターム及びフィードフォワードタームＧｉ及びＦｉをもたらす典型的な技術の有効性を検証した。５軸ロボットは、半導体製造アプリケーションにおいて自動化されたピックアンドプレースオペレーションに通常利用される種類であった。５軸ロボットは、垂直リフト駆動によって補間される平行な水平面において動作している２つのエンドエフェクタを有する多関節アームを含んだ。この特定のアプリケーションは、チャレンジングテストベッドを表した。なんとなれば、ダイナミクスは、軸の間の強いクロス接続を備えた高度の非リニアである。他の動作の間に、５軸ロボットは、半径方向において第１エンドエフェクタの直線拡張運動を実施するように命令された。

図８は、各々の適用されたアルゴリズムに対して、特に、所望の直線パスからの第１エンドエフェクタの偏差を示すその通常の構成要素である、第１エンドエフェクタの測定されたトラッキング誤差を示す。方程式２（８１０）を用いるアルゴリズムのトラッキング性能は方程式１（８２０）を用いるアルゴリズムの性能に近づき、従来の単一入力単一出力フィードバックアルゴリズム（８３０）を明らかに上回る。

クラスタ化アーキテクチャ制御システム１００に関して前に述べたように、システムの軸を正確に同期させてスループットを最大化し、衝突のない動作を保証することは重要である。

ネットワークノードの各々の上で共通の正確なタイムリファレンスを維持することによってかつ全ての時間依存ネットワークトラフィックをタイムスタンピングすることによって、クラスタ化アーキテクチャ制御システム１００により制御されたオペレーションを同期させることは、開示された実施例の特徴である。特に、ＰＶＴ及びＰＶＴ−ＦＧフレームは、フレームによって説明された動作が起きるべき時間でスタンピングされ、よって通信ネットワーク１２０を介して軸運動の同期を保証する。

図２を参照すると、マスタコントローラ１０５は、高分解能レジスタ２６５及び低分解能レジスタ２７０を有していてもよい時間保持回路２６０を含む。マスタコントローラはまた、ネットワークノードの間で共通のタイムリファレンスを維持することと関係する他のオペレーションを実施するためのタイミング制御回路を含んでいてもよい。図３を参照すると、各々のクラスタコントローラ１１０は、高分解能レジスタ３４５及び低分解能レジスタ３５０を備えた時間維持回路３４０を有していてもよい。図４を参照すると、各々のリモートコントローラ１１５及び自律リモートコントローラ１５０も、高分解能レジスタ４５５及び低分解能レジスタ４６０を含む時間維持回路４５０を有していてもよい。

共通のタイムリファレンスを維持するために、マスタコントローラは、通信ネットワーク１２０上で各々のバスサイクルの開始時に「サイクルスタート」メッセージを発行してもよい。典型的なバスサイクルは、約１２５μｓｅｃを占めていてもよく、図９ａに示したように、「サイクルスタート」で開始して等時性トラフィック及び同期トラフィックに対する間隔が続いてもよい。図９ｂは、典型的なサイクルスタートメッセージを示し、図９ｃは、典型的な高分解能レジスタ２６５、３４５、４５５を示す。

図２を参照すると、ネットワークインタフェース２３０は通常、各々のサイクルスタートメッセージに基づく高分解能レジスタ２６５、３４５、４５５を自動的に更新するメカニズムを提供してもよい。

新しい等時性サイクルが開始されると、即ち、高分解能レジスタの下位ビットが切り替わりかつ６４秒に達すると、中断を提供し、高分解能レジスタの７番目のビットが変更されたことを示すメカニズムを、各々のネットワークノードはまた含んでいてもよい。通信ネットワーク１２０は、ＩＥＥＥ １３９４ネットワークである場合、上記した特徴のいくつかまたは全ては、ＩＥＥＥ １３９４標準に従って提供されてもよい。ＩＥＥＥ １３９４ネットワークでは、高分解能レジスタは、サイクルタイムレジスタと称されてもよく、低分解能レジスタは、バスタイムレジスタと称されてもよい。

ネットワーク同期は、以下のように実施されてもよい。通信ネットワーク１２０が初期化されるかまたはリセットされた後に、マスタコントローラ１０５は通信ネットワーク１２０を介して制御すると仮定し、タイム維持回路２６０及びタイミング制御回路２７５を利用する低分解能レジスタ２７０を維持してもよい。各々のクラスタコントローラ１１０、リモートコントローラ１１５、及び自律リモートコントローラ１５０は、初期化またはリセットでマスタコントローラ１０５上の低分解能レジスタ２７０にそれ自体の低分解能レジスタ３５０、４６０を同期させてもよい。各々のクラスタコントローラ１１０、リモートコントローラ１１５、及び自律リモートコントローラ１５０は次に、その高分解能レジスタ３４５、４５５に基づいてその低分解能レジスタ３５０、４６０を維持して更新する。通信ネットワーク１２０自体は、通常、通信ネットワーク１２０を介して高分解能レジスタ２６５、３４５、４５５の自動同期のための機能を提供してもよい。マスタコントローラ１０５は、クラスタコントローラ１３０または自動リモートコントローラ１５０にＰＶＴまたはＰＶＴ−ＦＧフレームを送出する。

本願明細書で開示された同期システムでは、ＰＶＴまたはＰＶＴ−ＦＧフレームは、将来ＰＶＴまたはＰＶＴ−ＦＧフレームが実行されるべきときを示すタイムスタンプを含む。示された時間に至ると、クラスタコントローラ１３０及び自律リモートコントローラ１５０は、フレームにおいて受信された情報に従ってそれらのそれぞれの軸を動作させる。

要約すれば、共通のタイムリファレンスは、マスタコントローラ１０５、クラスタコントローラ１１０、リモートコントローラ１１５、及び自律リモートコントローラ１５０の間で維持される。共通のタイムリファレンスを維持しかつフレームによって説明される動作が起こるべき時でＰＶＴ及びＰＶＴ−ＦＧフレームをタイムスタンピングすることによって、通信ネットワーク１２０を介して軸運動の同期は、正確に維持されてもよい。

上記したように、軽量ＩＥＥＥ １３９４プロトコルは、産業用制御デバイスのために開発されて、機器及び産業制御プロトコル（「ＩＩＣＰ」と称される、１３９４ＴＡ ＩＩＣＰ）と称される。

ＩＩＣＰ及び他の同様のプロトコルは、フロー制御、システム構成要素の間の通信接続を生成して閉じるフレームワーク、バスリセット後に接続を復活させるメカニズム、及びマスタコントローラからＰＨＹアドレスを通信接続に説明して、リモートコントローラからネットワークを列挙する負担を取り除くメカニズムを提供してもよい。さらに、通信接続は、これらの種類のプロトコルを用いるときにバスリセットイベントにわたって持続してもよい。

マスタコントローラ１０５、クラスタコントローラ１１０、及び自律リモートコントローラ１１５の間で情報を交換するための使用スキーム及びメッセージフォーマットを含む、使用されているプロトコルへの拡張を提供することが開示された実施例の特徴である。使用スキーム及びメッセージフォーマットは、まとめてプロトコル拡張と称される。

本願明細書で説明されるネットワークプロトコル拡張は、それらがネットワーク通信メッセージのための特定のメッセージフレームワークを提供するということに利点がある。メッセージの内容は、用いられる転送プロトコルを通してもよい。

制御システム１００において用いられている種類のプロトコルの典型的な構造が、図１０に示される。プロトコルは、アプリケーション層１１０５、接続層１１１０及びトランザクション層１１１５を含んでいてもよい。アプリケーション層１１０５は、接続層１１１０の機能を用い、プラグと称されるポイントツーポイント接続はマスタコントローラ１０５（図１）などのマスタデバイスとリモートコントローラ１５０（図１）などのリモートデバイスとの間で構築されてもよい。

図１１は、これらのプラグが実行される方法の例を示す。マスタデバイスは、リモートデバイスの各々に対して１つ以上のプラグ１０２０を開いてもよい。プラグ１０２０は、１つ以上のポート１０２５、１０３０を設ける。各々のポート１０２５、１０３０は、ＰＶＴまたはＰＶＴ−ＦＧフレームなどのフレームを送出する手段を設け、そこで、フレームは、ポートの斜視図からデータの不透明な部分である。ポート１０２５、１０３０は通常、二重モードで動作する。即ち、データが両方向に並行して送出され得る。アプリケーション層１１０５は、制御ポート１０３０またはデータポート１０２５としてポートを用いてもよい。制御ポート１０３０上のメッセージは、通常、メッセージの内容を記載しているメッセージのヘッダに組み込まれたメタデータを有する。データポートメッセージは、通常、かかるメタデータを欠いている。リモートコントローラ１５０及びマスタコントローラ１０５は、通常、プログラミング、予め定められたテーブル、定義、を介して、または他の手段によってデータポートメッセージ構造を知らされる。制御ポート１０３０上のメッセージは、１つ以上のデータポート１０２５の内容を画定するかそうでなければ１つ以上のデータポート１０２５上のメッセージを識別してもよい。いくつかの実施例では、このことは、ヘッダ情報またはいくつかのメッセージ定義なしでデータポートメッセージが送出されることを可能にし、かかるメッセージを送出することと関係する諸経費を下げる。制御ポートとデータポートとの間の相互作用は特定のプラグに分離されるか、または、特定の制御ポート上のメッセージは同じかまたは異なるリモートデバイスに開かれた他のプラグのデータポートに対する制御を提供してもよい。

開示された実施例に説明されているプロトコル拡張は、特定のプロトコルに対する使用に限定されないが、プラグを支持するいずれかのプロトコルとともに用いられてもよいということが理解されるべきである。

本願明細書に説明されるアプリケーション層拡張は、比較的簡単な制御ポートメッセージタイプを含んでいてもよい階層化された方法を利用する。該拡張は、また、ベンダ固有の拡張に対するフレームワーク、即ち、特定のデバイス製造者の構成要素専用に調整されてもよいメッセージ、を提供してもよい。このことは、多数の制御ポートメッセージタイプで包まれた、ベンダ固有のアプリケーション層のコマンドセットの使用を容易にする。データポートメッセージフォーマットも、ベンダ固有であってもよい。

制御ポート１０３０は、通常、システム構成要素の間でコマンド及び応答を交換してもよい。データポート１０２５は、リモートコントローラまたはマスタコントローラ上の特定のオブジェクトに提出されるデータフレームを送信してもよい。アドレス指定は、概して、ポート指示から暗示されてもよく、メッセージの一部でなくてもよい。データポートメッセージ構造は、概して、ベンダ固有であってもよい。

典型的な制御メッセージ構造１７００が、図１７に示される。４バイト分のデータ（クアドレット）１７０５はデータの３２ビット幅ピースを意味する。Ｄフィールド１７１０は、例えばマスタコントローラ１０５からリモートコントローラ１５０にメッセージが送出されるかまたはその逆かを示す方向を指定する。メッセージタイプ１７１５は、下記に説明される定義済みのメッセージタイプを指定してもよい。最高で２＾１５メッセージタイプまでが定義されてもよい。メッセージＩＤフィールド１７２０は、例えばアクション（ＡＣＴＩＯＮ）タイプメッセージなどのトランザクションのようなメッセージに対するコマンド及び応答に一致させるために用いられてもよい。例えばストリング（ＳＴＲＩＮＧ）タイプのメッセージなどのストリーム状のメッセージに対して、メッセージＩＤフィールド１７２０は、追加の配列情報を提供するために用いられてもよい。アクション及びストリングタイプメッセージは以下に説明される。いくつかの実施例では、メッセージＩＤフィールド１７２０は、任意であってもよい。予備のフィールド１７２５は、メッセージヘッダの範囲内でベンダ固有の拡張に対するプレースホールダを提供してもよい。いくつかの特定の制御ポートメッセージは、アクション（ＡＣＴＩＯＮ）、イベント（ＥＶＥＮＴ）、及びストリング（ＳＴＲＩＮＧ）タイプメッセージを含んでもよい。プラグの制御ポート上で送出されたメッセージは、全て類似した構造を有していてもよい。これらのメッセージタイプは相対的にほんの少しでもよく、特定のコマンドの実行においてリモートコントローラレベル上の大幅な柔軟性を可能にするということが、開示された実施例の特徴である。例えば、パラメータを設定して得るための全てのコマンドは、アクションコマンドであってもよく、そこで、データのフォーマットだけでなく設定／得られるべき実際のパラメータは、リモートコントローラの製造者によってさらに定義されてもよい。このように、リモートコントローラ製造者は、制御システムに準拠するために大変限定されたコマンドセットを実行することだけが必要とされてもよい。

典型的なアクションメッセージ１８００が図１８に示される。アクションメッセージ１８００は、リモートコントローラにコマンドを送出するために、そして、リモートコントローラに対して、マスタコントローラから以前に送出されたコマンドに対して応答を送出するために用いられてもよい。以前に送出されたアクションコマンドへの応答は通常、Ｄフィールド１８１０以外のコマンドのヘッダをコピーしてもよい。アクションコマンドに対して、メッセージＩＤフィールド１８２０が必要とされてもよい。メッセージ本体のフォーマットは、特定のリモートデバイスのベンダに固有であってもよい。

アクションメッセージは、リモートコントローラのようなリモートデバイス上で構成パラメータを設定し、得て、または記憶すること、追跡、イベント、状態、ＰＶＴまたは他のアプリケーション固有オペレーション用の１つ以上のデータポートを構成すること、リモートデバイス上でＩ／Ｏを作動させること、軌道がリモートデバイス上で生成される場合の離散的移動のための、そして例えば構造、診断などのリモートデバイスが支持するなんらかの他の独特なコマンドを送出することのための動作コマンドを送出すること、または、他の動作状態へデバイスを遷移させること、に用いられてもよい。アクションメッセージは、ベンダ固有であってもよい。

リモートデバイスからマスタコントローラへのアクション応答メッセージにおいて、予備フィールド１８２５は、８ビットのベンダ固有の結果コードを含んでいてもよい。この条件で、結果コードだけを含むアクションコマンドへの応答は、応答においてヘッダだけを送出することによって実行され得る。リモートデバイスにおいてパラメータ値を設定するためのコマンドは、かかる動作モードの例である。

ベンダ固有ヘッダ１８３０は、特定のデバイスパラメータに対する設定、獲得、または記憶のうちの１つを示してもよい。軸ＩＤフィールド１８３５は、特定のデバイスに対する特定のデバイスパラメータに対して最高２５６軸まで（または例）さらに送り出すことを提供する。ベンダコマンドＩＤ１８４０は、ベンダ固有のデバイスパラメータまたはコマンドを指示してもよい。ベンダコマンドＩＤ１８４０は、２＾１６の個々のコマンドまたはパラメータまで支持してもよい。ベンダ固有コマンドパラメータ１．．．ｎ １８４５は、コマンドまたは応答において１つ以上の任意のパラメータを提供してもよい。

典型的なイベントメッセージ構造１９００が、図１９に示される。イベントメッセージ１９００は、リモートコントローラからマスタコントローラにイベントデータを送出するために用いられる。イベントメッセージはまた、所定のアプリケーション固有データ転送に対する別個のプラグを開く代わりに制御ポートメッセージを用いるためのメカニズムを提供してもよい。イベントデータは、イベント特定プラグを開くことの代わりにイベントメッセージを介して送出されてもよい。

メッセージヘッダにおけるメッセージＩＤフィールド１９２０は、仮想イベント接続番号を指示するために用いられる。このフィールドにおける値は、ベンダ固有の「イベントへの追加パラメータ」制御メッセージにおけるパラメータであってもよい。

ベンダ固有のイベントメッセージ２０００の例が図２０に示される。この例では、最高６の仮想イベント接続までが、設定されてもよい。この例では、「イベントパラメータ１．．．６（２０４５）であるイベントパラメータフィールドの数は、イベント補足に対して設定された特定の駆動パラメータに依存する。これらのフィールドは、イベントの発生時のパラメータ値を表す。イベントパラメータフィールドは、所定のパラメータがイベント補足に準備が整っていない場合、０を含む。この特定のデバイス製造業者のために、最高６つのパラメータまでが、イベントパラメータとして構成されてもよい。

ストリングメッセージタイプは、フォーマットされていないテキストデータを送出することによってマスタコントローラからリモートコントローラまでまたはその逆に仮想の一連のチャネルを生成するために用いられる。ストリングメッセージ構造２１００の例が、図２１に示される。

メッセージＩＤ２１２０は、リモートデバイスまたはマスタコントローラ（これらのカウンタは別個に増加する）から送出されたあらゆるメッセージを用いて順番に増加してもよく、メッセージが順序がバラバラで到着した場合に、トラフィックを順序付ける追加の手段を提供してもよい。

典型的なベンダ固有ストリングコマンド２２００が、図２２に示される。この例では、一連のメッセージ本体２２４５は各々、４つのキャラクタを含んでもよい。この例に対するリモートデバイスは、メッセージ本体情報の最高６つの４バイト分データまでを支持してもよく、プレーンテキストのＡＳＣＩＩコード化を用いているキャラクタをコード化してもよい。

データポートメッセージ構造は、通常純粋なデータを表してもよく、ヘッダを有していなくてもよい。それらはまた、リモートデバイスベンダ固有であってもよく、そのコンテキストにおいて解釈されるべきである。この例のリモートデバイス製造業者は、ＰＶＴ状態及びトレースメッセージタイプを用いる。他のメッセージタイプも用いられてもよい。

典型的なＰＶＴまたはＰＶＴ−ＦＧメッセージ構造２３００が、図２３に示される。ＰＶＴメッセージは、通常、動作パスに沿って１つの軌道セットポイントを表す。以前に述べたように、ＰＶＴまたはＰＶＴ−ＦＧメッセージは、通常、マスタコントローラ１０５から１つ以上のクラスタコントローラ１１０または自律リモートコントローラ１５０まで送出される。ＰＶＴまたはＰＶＴ−ＦＧメッセージは通常、タイムスタンプされた軌道セットポイントデータを送出するために用いられる。ＰＶＴまたはＰＶＴ−ＦＧメッセージはまた、トルク限定条件を含んでもよいことは任意である。ＰＶＴまたはＰＶＴ−ＦＧメッセージはまた、受信クラスタコントローラ１１０または自律リモートコントローラ１５０が事前動作状態にある場合に、周期的タイムスタンプを送出するために用いられてもよい。ＰＶＴまたはＰＶＴ−ＦＧメッセージは、例えば１００Ｈｚの周期的割合で送出されてもよい。１つの実施例では、ＰＶＴメッセージは、命令された位置２３０５、命令された速度２３１０、及びネットワーク時間２３１５を含む。ＰＶＴまたはＰＶＴ−ＦＧメッセージは、フィードフォワードターム２３２０、利得ターム２３２５、及びトルク限定ターム２３３０のうちの１つ以上を任意で含んでもよい。

ステータス（ＳＴＡＴＵＳ）メッセージは通常、ステータスメッセージが生成されたときのリモートデバイス状態を表す。ステータスメッセージ２４００の例が、図２４に表される。

ステータスメッセージは通常、１つ以上のクラスタコントローラ１１０または自律リモートコントローラ１５０からマスタコントローラ１０５まで送出される。ステータスメッセージは、タイムスタンプされた状態、実際の位置、及び速度データを１つ以上のクラスタコントローラ１１０または自律リモートコントローラ１５０からマスタコントローラ１０５まで送出するために用いられてもよい。

ステータスメッセージはタイムスタンプされたＩ／Ｏデータを送出するために用いられてもよいということは任意である。ステータスメッセージは、例えば１００Ｈｚの周期的な割合で送出されてもよく、低遅延のＩ／Ｏイベント捕捉に対して非周期的な割合で送出されてもよい。１つの実施例では、ステータスメッセージは、実際の位置２４０５、さまざまなデジタル入出力装置２４１０の状態、タイムスタンプ２４１５、命令された位置２４２０、実際の速度２４２５を含む。

ステータスワード２４３０は、駆動エラー／障害／警告状態についての情報を含む。それはまた、リモートデバイスＰＶＴバッファの状態（フロー制御情報）についての情報を含む。

典型的なトレース（ＴＲＡＣＥ）メッセージ３２００が図３２に示される。トレースメッセージは、ｎサンプリングレコードまでを含むことができ、各々のレコードはｍサンプルまでを有してもよい。フレームは、以下のデバイス固有の制約に従うべきである。
ｎ＊ｍ＜＝１２８
ｍ＜＝６

トレースメッセージ３２００は、１つ以上のクラスタコントローラ１１０またはリモートコントローラ１１５、１５０からマスタコントローラまで通常送出される。トレースメッセージ３２００は、タイムスタンプされて周期的にサンプリングされた診断データをマスタコントローラ１０５に送出するために用いられる。トレースメッセージ３２００は、例えば１６ｋＨｚまでの周期的または可変の割合で送出されてもよく、アクションコマンドを介して設定可能であってもよい。データ及びトレース（トリガ、遅延、サンプリングレート、その他）の他のパラメータの構造は、アクションコマンドを介して設定可能であってもよい。さらに、他のメッセージのいくつかと同様に、トレースメッセージ３２００は、高分解能データ転送を支持するために具体的に開かれたプラグを介して送出されてもよい。１つの実施例では、トレースメッセージは、多くのトレース変数３２０５を含む。

開示された実施例のプロトコル拡張は、ＰＶＴＦＧ、ＨＩＲＥＳ＿ＰＯＳ、及びＨＩＲＥＳ＿ＶＥＬメッセージのようなメッセージタイプを含んでもよいトレースメッセージの固有の実施を含んでいてもよい。上記されたステータスメッセージは、トレースメッセージの固有の実施として構成されてもよい。

以前に述べたように、ＰＶＴまたはＰＶＴ−ＦＧメッセージは、通常、マスタコントローラ１０５から１つ以上のクラスタコントローラ１１０または自律リモートコントローラ１５０へ送出される。ＰＶＴまたはＰＶＴ−ＦＧメッセージは、タイムスタンプされた軌道設定ポイントデータを送出するために用いられてもよい。ＰＶＴまたはＰＶＴ−ＦＧメッセージは、また、以下に詳細に説明されるように教示モードを支持するためにトルク限界タームを含んでもよい。ＰＶＴまたはＰＶＴ−ＦＧメッセージは、また、受信クラスタコントローラ１１０または自律リモートコントローラ１５０が事前動作状態にあるときに周期的タイムスタンプを送出するために用いられてもよい。ＰＶＴまたはＰＶＴ−ＦＧメッセージは、例えば１００Ｈｚの周期的割合で送出されてもよい。１つの実施例では、ＰＶＴメッセージは、４バイトのタイムスタンプ、４バイトの命令された位置、及び４バイトの命令された速度を含む。ＰＶＴ−ＦＧメッセージは、１つ以上の４バイトのフィードフォワードターム、４バイトの利得ターム、及び４バイトのトルク限界を任意で含んでもよい。

ＨＩＲＥＳ＿ＰＯＳメッセージは通常、１つ以上クラスタコントローラ１１０または自律リモートコントローラ１５０からマスタコントローラ１０５へ送出される。ＨＩＲＥＳ＿ＰＯＳメッセージは、タイムスタンプされて周期的にサンプリングされた実際の位置を１つ以上のノードからマスタコントローラに送出するために用いられる。ＨＩＲＥＳ＿ＰＯＳメッセージは、例えば１６ｋＨｚまでの周期的または可変の割合で送出されてもよく、下記に説明されるアクションコマンドを介して設定可能であってもよい。さらに、ＨＩＲＥＳ＿ＰＯＳメッセージは、高分解能データ搬送に対して具体的に開かれたプラグを介して送出されてもよい。１つの実施例では、メッセージは、４バイトのタイムスタンプ及び４バイトの実際の位置を有するブロックを含む。ブロックは、最高１６回まで繰り返され、１２８バイトまでの全体の長さを備えて、６２．５サンプリングレートでの１ｍｓ分のデータを表してもよい。

替わりのフォーマットでは、ＨＩＲＥＳ＿ＰＯＳメッセージは、４バイトのタイムスタンプ、及び４バイトの繰り返しの実際の位置フィールドを含んでもよく、それは１ｍｓ分の１６ｋＨｚサンプリングデータを表して最高１６回まで繰り返してもよい。メッセージは、サンプルがサンプリングデータと等しく間隔を取られていてかつ、第１の位置フィールドがスタンプにおいて指定された時間でサンプリングされると仮定して、フレーム毎に１つのタイムスタンプを用いて構成されていてもよい。

ＨＩＲＥＳ＿ＶＥＬメッセージは、通常、１つ以上のクラスタコントローラ１１０または自律リモートコントローラ１５０からマスタコントローラ１０５へ送出される。ＨＩＲＥＳ＿ＶＥＬメッセージは、タイムスタンプされて周期的にサンプリングされた実際の速度データをマスタコントローラ１０５に送出するために用いられてもよい。ＨＩＲＥＳ＿ＶＥＬメッセージは、例えば１６ｋＨｚまでの周期的または可変の割合で送出されてもよく、以下に検討されるアクションコマンドを介して設定可能でもよい。さらに、ＨＩＲＥＳ＿ＶＥＬメッセージは、高分解能データ転送を支持するために具体的に開かれたプラグを介して送出されてもよい。１つの実施例では、ＨＩＲＥＳ＿ＶＥＬメッセージは、４バイトのタイムスタンプと４バイトの実際の速度を含んでいてもよい。

さらに、クラスタコントローラ１１０及び自律リモートコントローラ１５０からマスタコントローラ１０５へ情報を運ぶために、上記の説明による、ステータス、ＨＩＲＥＳ＿ＰＯＳ及びＨＩＲＥＳ＿ＶＥＬメッセージが、１つ以上のリモートコントローラ１１５からクラスタコントローラ１１０のうちの１つまたはマスタコントローラ１０５へ送出されてもよい。

このように、開示された実施例は、プロトコル拡張、即ち、マスタコントローラ１０５、クラスタコントローラ１１０、リモートコントローラ１１５及び自律リモートコントローラ１５０の間で情報を交換するために設定された固有のメッセージを含む。固有のメッセージの設定は、有利である。なんとなれば、それは、例えば１３４９ＴＡ ＩＩＣＰなどの標準ネットワークプロトコルによって提供されるサービスにわたってかつサービス上でクラスタ化アーキテクチャコントロールシステム１００に対する追加の機能を提供するからである。

クラスタ化アーキテクチャ制御システム１００などの制御システムにおいて、特定のイベントの発生時に１つ以上のクラスタコントローラ１１０またはリモートコントローラ１１５、１５０から瞬間軸または他の特性を捕捉するということが利点であってもよい。図１２は、かかる特性が有益であってもよいワークセル１２００を示す。ワークセル１２００は、クラスタコントローラ１２１５及び３つのリモートコントローラ１２３０、１２３５、１２４０を備えたロボット１２１０を含む。クラスタコントローラ１２１５は、通信ネットワーク１２５０を介してマスタコントローラ１２４５と通信する。１つの実施例では、ワークセル１２００は、クラスタ化アーキテクチャ制御システム１００（図１）の一部であってもよい。

例として、「オンザフライ」認識及びロボット１２１０によって運ばれる半導体基板１２０５などの円形のペイロードの偏心またはずれに対する修正は、瞬間のデータ捕捉を必要としてもよい。この場合には、ロボット１２１０は、ペイロード１２０５の先頭及び末尾を検出する一組の静止センサ１２１６を介して移動してもよい。リモートコントローラ１２３０、１２３５、１２４０は、例えばロボット１２１０の各々の軸の位置及び速度などのある特性を捕捉して、データをマスタコントローラ１２４５に提供してもよい。マスタコントローラ１２４５は、次に、ペイロードのエッジが検出されるときにロボットのエンドエフェクタ１２２０の位置を決定し、次にペイロード１２０５の中心の実際の位置を決定してもよい。一旦ペイロードの中心が決定されると、マスタコントローラ１２４５は、ペイロード１２０５が最初の偏心の量及び方向に関わりなく中心におかれる方法で供給されるように、ロボット１２１０の軌道を変更してもよい。

別の例では、ロボット１２１０はクラスタコントローラ１２１５に接続された１つ以上のインターロック１２２５を含んでもよい。インターロック１２２５が何らかの理由で外れた場合、ロボットの軸の位置及び、インターロック１２２５が外れたときにロボット１２１０が相互作用していてもよい他の装置の位置を決定することが重要であるかもしれない。

トリガとなるイベントの発生でまたはトリガとなるイベントと関係付けられて、クラスタ化アーキテクチャ制御システム１００の一組の軸から瞬間データを捕捉することが、開示された実施例の特徴である。以下に説明される手順は、通常マスタコントローラ１２４５を含むが、適当な処理能力及びメモリを備えたクラスタコントローラまたはリモートコントローラはまた、マスタコントローラ１２４５によって提供される機能を実施してもよい。

図１２及び図１３のフローチャートを参照すると、瞬間データ捕捉順序は、以下のように進められてもよい。リモートコントローラ１２３０、１２３５、１２４０は、ブロック１３０５及び１３０６に示すように、例えば１つ以上のセンサ１２１６の変更出力状態などのトリガーイベントとしてあるイベントを認識するように指示されてもよい。リモートコントローラ１２３０、１２３５、１２４０はまた、ブロック１３１０に示されるように特定のイベントの発生時に指定された一組のノードと通信するように指示されてもよい。リモートコントローラ１２３０、１２３５、１２４０はさらに、ブロック１３１５及び１３１６に示すように、特定の軸を制御するために用いられるサーボループのそれより通常低い、指定されたサンプリングレートで、例えば軸位置または速度などの１つ以上の特定の数量の関心をバッファするように指示されてもよい。このように、少なくとも１つの実施例では、関心の量のあらゆるデータポイントが、サンプリングされてもよいというわけでない。命令は、各々のリモートコントローラのオペレーションシステムの一部であってもよく、または、命令は、クラスタコントローラ１２１５またはマスタコントローラ１２４５から提供されてもよい。関心の量、トリガーイベント、及び指示されたノードの組は、各々のリモートコントローラに対して異なっていてもよい。

一旦指示されると、リモートコントローラ１２３０、１２３５、１２４０は、データをバッファリングすること（ブロック１３２０）及びトリガーイベントを監視すること（ブロック１３２５）を開始する。トリガーイベントの発生で、イベントを認識しているリモートコントローラは、ブロック１３３０に示すようにイベントの時間を記録し、ブロック１３３５に示すように、特定のイベントに対する指示された一組のノードにイベント時間情報を備えたメッセージを送出する。指示されたノードは、それらの関心のバッファされた量を補間してブロック１３４０に示すようにイベント時の量に対する値を決定する。指示されたノードは、ブロック１３４５に示すようにマスタコントローラに関心の量の補間された値を送出する。マスタコントローラは、次にブロック１３５０に示すようにシステム内で軌道またはオペレーションを変更するためにデータを用いてもよい。

いくつかの場合には、リモートコントローラの間の直接の通信は、例えば必要な多数のプラグのせいで望ましくないかもしれない。この場合、マスタコントローラが、イベント時間を指示されたノードに分配してもよい。

マスタコントローラによるイベント時間分配を収容するために変更された瞬間のデータ捕捉データ手順は、以下のように進められてもよい。ここで図１２及び１４を参照すると、リモートコントローラ１２３０、１２３５、１２４０は、例えば１つ以上のセンサ１２１６の変更出力状態などの、ブロック１４０５及び１４１０に示すようなトリガーイベントとしてあるイベントを認識するように指示されてもよい。リモートコントローラ１２３０、１２３５、１２４０は、特定の軸を制御するために用いられるサーボループのサンプリングレートより概して低い、指示されたサンプリングレートで、例えば軸位置または速度などの、ブロック１４１１及び１４１５に示すような関心の１つ以上の特定の量をバッファするように指示されてもよい。一旦指示されると、リモートコントローラ１２３０、１２３５、１２４０は、データをバッファリングすること（ブロック１４２０）及びトリガーイベントを監視すること（ブロック１４２５）を開始する。

トリガーイベントの発生時に、イベントを認識するリモートコントローラは、ブロック１４３０に示すようにイベント時間を記録し、ブロック１４３５に示すように、マスタコントローラ１２４５にイベント時間情報を備えたメッセージを送出する。マスタコントローラ１２４５は、次にブロック１４４０に示すように特定のイベントに対して指示された一組のノードにイベント時間を送出する。ブロック１４４５では、指定されたノードは、それらの関心のバッファされた量を補間してイベント時間における量に対する値を決定する。マスタコントローラ１２４５は、次に、ブロック１４５５に示すように、データを用いてシステム１２００内で軌道またはオペレーションを変更してもよい。

別の代替案として、１つ以上のリモートコントローラは、例えば限定されたメモリまたは計算能力のための十分な資源を所有していない場合に、これらのオペレーションも、マスタコントローラによって実行されてもよい。しかしながら、この方法は、通信ネットワークトラフィックの増加という結果になるかもしれない。

図１２及び１５を参照すると、マスタコントローラ１２４５によってデータバッファリング及び補間を収容するために変更された瞬間のデータ捕捉手順は、次のように進む。ブロック１５０５及び１５０６に示すように、リモートコントローラ１２３０、１２３５、１２４０は、例えば、１つ以上のセンサ１２１６の変更出力状態などのトリガーイベントとしてあるイベントを認識するように指示されてもよい。ブロック１５１０及び１５１１に示すように、リモートコントローラ１２３０、１２３５、１２４０は、特定の軸を制御するために用いられるサーボループのサンプリングレートより概して低い、指示されたサンプリングレートで、例えば軸位置または速度などの１つ以上の関心の量を監視するように指示されてもよい。一旦指示されると、リモートコントローラ１２３０、１２３５、１２４０は、マスタコントローラ１２４５に、監視された関心の量を周期的に送出することを開始し（ブロック１５１５）、それは、ブロック１５２０に示すように、例えば循環バッファを用いて、指示された期間それらを記憶する。同時に、リモートコントローラ１２３０、１２３５、１２４０も、ブロック１５２５に示すようにトリガーイベントを監視することを開始する。ブロック１５３０に示すように、トリガーイベントの発生時に、イベントを認識しているリモートコントローラは、イベント時間を記録し、さらにブロック１５３５に示すように、マスタコントローラ１２４５にイベント時間情報を備えたメッセージを送出する。ブロック１５４０に示すように、マスタコントローラ１２４５は次にバッファされた関心の量を補間してイベント時の量に対する値を決定する。マスタコントローラ１２４５は次に、データを用いて、ブロック１５４５に示すようにシステム１２００内で軌道またはオペレーションを変更してもよい。

上記した手順ではリモートコントローラがトリガーイベントを認識してトリガーイベントを観察し、トリガーイベントが生じた時間を記録すると考えられるが、自律リモートコントローラ、クラスタコントローラまたはマスタコントローラも、リモートコントローラを参照して上記されたこれらの機能を実施してもよい。

多くのイベント捕捉アプリケーションでは、特に瞬間位置捕捉目的に対して、得られるデータは、イベントをトリガーするセンサの遷移遅延によるエラーを含む。これらのエラーは、特に高速／高精度アプリケーションにおいて重要である。アプリケーションでは、制御されたマシンの軸は、イベントが物理的に起こる時間からイベントが制御システムに信号送出される時点まで、所望しない長い距離を移動するかもしれない。

「オンザフライ」認識及び円形のペイロード１２０５の偏心またずれに対する修正の上記の例において、ロボット１２１０のエンドエフェクタ１２２０は、ペイロードのエッジがセンサ１２１６を通過する場所からトリガーイベントが認識されて時間が記録される場所まで所望しない長い距離を移動するかもしれない。信号の遷移遅延は決定性であると仮定すると、これらのエラーは、以下に説明される簡単な遅延補償メカニズムによって最小化され得る。

イベントが生じる場所とそれが制御システムによって実際に認識される場所までの間の運動の長さを予測するために、速度情報が、位置データに加えて捕捉されてもよい。関心の軸の速度が２つの場所の間で実質的に一定のままであると仮定して、時間経過が周知の時間遅延に等しいということが与えられると、２つの場所の間の関心の軸の動作は、再構築されて、以下の方程式を用いてイベントが物理的に生ずるときに各々の軸の実際の位置の予測を得てもよい。

ここで、

は、位置捕捉イベントが生じたときの軸ｉの実際の位置を示す。θ_ｉ及び

はそれぞれ制御システムによって補足されたときの軸ｉの位置及び速度を表す。τは、センサ遷移遅延であり、ｍは関心の軸の数を示す。

センサの遷移遅延は通常仕様書に含まれているが、実際の待ち時間は、センサが用いられる特定の状態にしばしば依存する。従って、遷移遅延のより正確な値は、較正プロセスを介して得られることが必要であってもよい。図１２及び１６を参照すると、単一の動作の軸を含む例が説明される。図１２のワークセル１２００は、また、自律リモートコントローラ１２５５によって制御される軸１２７０を有する少なくとも１つのアライナ１２５０を含んでもよい。自律リモートコントローラ１２５５は、マスタコントローラ１２４５によって順に制御される。刻み目をつけられた基板１２６０がアライナ１２５０上に配置されてもよく、アライナはまた基板１２６０における刻み目の位置を検出するセンサを含む回路１２６５を有していてもよい。ブロック１６０５に示されるように、自律リモートコントローラ１２５５は、軸１２７０を移動させて位置捕捉イベントをトリガーする。この例では、回路１２６５が基板１２６０内の刻み目を感知する。自律リモートコントローラ１２５５は、オペレーションの一定の速度で軸１２７０を移動させ、ブロック１６１０に示すように、回路１２６５がイベントを検出するときに軸１２７０の即時の位置及び速度を記録する。ブロック１６１５に示すように、自律リモートコントローラ１２５５は次に、同じ方向に軸１２７０を移動させて実質的により遅い速度でイベントを繰り返す。それは、回路１２６５の遷移遅延に対応する時間間隔において軸１２７０によって移動される距離が必要な位置捕捉精度より小さいというように選択される。結果として、なんらかの遷移遅延による位置エラーは無視されるかもしれない。さらに、ブロック１６２０に示すように、回路１２６５がイベントを検出すると、軸１２７０の瞬間位置が捕捉される。ブロック１６２５に示すように、得られるデータは、τに対する方程式（５）を解くことによって回路遷移遅延を予測するために用いられてもよい。ここで、

は、低速度で位置捕捉結果によって予測され、θ_ｉ及び

は、オペレーションの通常速度でイベント捕捉結果である。

複数の軸の結合動作が位置捕捉イベントに含まれる場合、較正手順は、システムのセンサ（または複数のセンサ）及び移動構成要素（または複数の構成要素）の形状構成を考慮に入れることが必要である。この種のケースに対する例の較正手順は、参照により組み込まれている、共通の出願人による米国特許出願第１０／７３９，３７５に見出される。そこで、位置捕捉メカニズムは、ペイロードの偏心のオンザフライ認識のために利用されている。

位置捕捉イベントが、例えばアライナ１２５０などの制御されたマシンの動作によってトリガーされる場合、較正プロセスは、制御システムによって十分に自動化されてもよい。

このように、開示された実施例は、クラスタ化アーキテクチャ制御システムにおいて特定の関心の量についてのデータを捕捉する多数の方法を提供する。ネットワークノードの間でトリガーイベントを伝播するために必要であるかもしれない、極めて低遅延の通信ネットワークを該方法が必要としないということにおいて、該方法は有利である。トリガーとなるイベントが生じると、イベントを認識するコントローラはイベント時間を記録する。１つ以上の軸からイベント時間前後のデータが補間されてイベント時間に対する算出されたデータ値を生じてもよい。算出されたデータ値は、システム１２００内で軌道またはオペレーションを変更するために用いられてもよい。較正手順はまた、イベントが発生する時とイベントが制御システムによって認識された時との間の相違を説明するために提供される。

無制限の回転を必要としているロボットは、回転可能な接続を介して信号または電力を接続するためにスリップリングまたは誘導フィードスルー及び容量性フィードスルーを用いてもよい。周波数及び帯域幅が増加するにつれて、これらの種類の接続は、ますます実施及び維持することが難しくなる。真空ロボットの場合、スリップリングは、汚染源を提起するかもしれない。通信及び電源を提供している車または横断者に搭載されたロボットは通常、サービスループを備えたケーブルを必要とする。さらに、システム構成要素へのサービス接続は通常、コネクタ及び対応ケーブルを必要とする。

ケーブル、スリップリング、フィードスルー及び様々な機械的接続の物理的属性により問題を排除し、有線の接続と比較してメンテナンス必要条件を下げるためにかつより一層の信頼性のために、無線接続を利用してシステム構成要素の間の通信を設けるということが開示された実施例の特徴である。

図１を参照すると、通信ネットワーク１２０は、１つ以上のマスタコントローラ１０５、クラスタコントローラ１１０、リモートコントローラ１１５及び自律リモートコントローラ１５０の間の通信パスを提供する１つ以上の無線部分を含んでもよい。

図２５は、無線接続が実施されたクラスタ化アーキテクチャ制御システム１００の一部を示す。ロボット２５０５は、多数の軸を含んでもよく、クラスタコントローラ２５１０及び３つのリモートコントローラ２５１５、２５２０、２５２５よって制御されてもよい。（ここで再び示される図１の）マスタコントローラ１０５は、通信ネットワーク１２０を介してクラスタコントローラ２５１０を制御する。この実施例では、クラスタコントローラ２５１０及び通信ネットワーク１２０は、それらの間に無線接続２５４０を提供する対応する無線インタフェース２５３０、２５３５を有する。無線インタフェース２５３０、２５３５は、ＴＤＭＡ、ＣＤＭＡ、ＩＥＥＥ ８０２．ｘｘ、ＣＩＰプロトコル、ブルートゥース、閉領域ＲＦ、光学的、その他などのいかなる適当な無線通信プロトコルまたは、信号技術または標準を提供してもよい。選択された無線プロトコルは、不正な変更を防止するために暗号化送信のようなセキュリティメカニズムを含んでいてもよい。

さらに、例えば、コントローラ、軸、エンドエフェクタ及びサービス接続の間の他の通信パスは無線でもよい。またさらに、ロボット化されたオートメーションシステムにおいて、ロードポート、ファンシステム、フィルタユニット、その他も、無線接続を利用してもよい。無線接続は、それらが構成要素の周囲をケーブルで侵すことなしに通信を可能にするので有利である。例えば、フィールドサービス技術者は構成要素のワークスペースに入ることなく構成要素に接続してもよい。無線接続及びプロトコルの利用は通常、構成要素の接続を簡単にし、いくつかの例では、電力接続だけがケーブルを必要とするかもしれない。

開示された制御システム１００は、構成要素の各々のワークスペースにおける人的存在を収容することが要求されてもよく、システム保全を保証する機能を含んでもよい。

ドアスイッチなどのハードウェアインターロックは、オペレータが、ロボットなどの制御下の機械のワークスペース内にいるときに、通常、モータが電力供給されるのを妨ぐ。しかしながら、システム構成要素を教示するときに、即ち、構成要素が教示モードにあるときに、通常のハードウェアインターロックは、オペレータがロボットのワークスペースに入ることができるようにバイパスされてもよい。多くの例では、ロボットを導くために用いられる教示ペンダントは、圧力がスイッチに適用されないイベントにおいてロボットへの電力を除去するリモートの「ライブマン(live-man)」スイッチを有する。開示された実施例によれば、マスタコントローラ１０５またはクラスタコントローラ１１０はまた、ロボットの速度及び力が、ワークスペース内で人的存在を収容するために指定された許容制限の中で保持されるということを保証する命令を与えてもよい。

制御システム１００は、人的存在を収容するためにいくつかの特徴を組み入れてもよい。図１を参照すると、一般的なシステムの動作の間、マスタコントローラ１０５は、個々の軸１２５に対する動作プロファイルを生成してもよい。図１２の例では、いくつかの軸は、ロボット１２１０の一部としてグループ化されてもよく、マスタコントローラ１２４５はリモートコントローラ１２３０、１２３５、１２４０によって制御される一連のＰＶＴフレームを生成して、エンドエフェクタ１２２０は特定の軌道を実行してもよい。エンドエフェクタは一定の速度で移動しているが、ロボット１２１０を構成する異なる軸の速度は、位置及び時間で変化してもよい。このように、ＰＶＴフレームの速度パラメータは、ロボット運動学により位置及び時間に関して変化してもよい。オペレータがワークセル１２００に存在する場合、システムはオペレータを保護するために速度制限技術を用いてもよい。実際には、システムは、軌道を生成し、得られるエンドエフェクタ動作プロファイルが要求された速度制限内にあってもよい。このことは、リモートコントローラ１２３０、１２３５、１２４０によって制御される軸に対するＰＶＴフレームの速度パラメータを位置及び時間依存上限限度に設定するとともに、ロボットに対して上記したような軌道を算出することによって実現されてもよい。

同様に、エンドエフェクタは特定の方向に一定の力を示しているが、ロボット１２１０を構成する異なる軸のトルクは、位置及び時間で変化してもよい。位置及び時間依存トルク限度はまた、オペレータがワークセル１２００内に存在するときに課されてもよく、エンドエフェクタの得られる力は、リモートコントローラ１２３０、１２３５、１２４０を管理するクラスタコントローラ１２１５に送出されたタームを追加することによって特定の限界より低いままである。ロボット１２１０の特定の位置において、軸レベルでモータによって印加されたトルクとエンドエフェクタによって生成された力との間に一意の関係がある。従って、最大モータトルクを計算してエンドエフェクタ１２２０によって生成される対応する力が最大許容値を超えることができないようにロボットのモデルを用いることは可能である。リモートコントローラ１２３０、１２３５、１２４０によって制御される軸に対する新しい一組のＰＶＴまたはＰＶＴ−ＦＧフレームが生成されてクラスタコントローラ１２１５に送出される場合に、これらの最大トルクはいつも算出されてもよい。

オペレーションの教示モードにおいて、ＰＶＴリミット（ＬＩＭＩＴ）フレームと称される、一意のメッセージフレームを利用することが本実施例の特徴である。ＰＶＴリミットフレームは、上記の図６及び７において示したフレームに類似していてもよい。しかし、ＰＶＴリミットフレームの速度タームは、特定の限界を超えないように算出され、ＰＶＴリミットフレームは任意のトルク限界タームを含む。

図２６は、トルク限界タームを備えた典型的なＰＶＴリミットフレーム２６００を示す。ＰＶＴリミットフレーム２６００は、位置データ２６１０、速度データ２６１５、及び時間データ２６２０を含む。１つの実施例では、データは、１バイト以上でグループ化されたバイナリ形式である。別の実施例では、位置データ２６１０、速度データ２６１５、及び時間データ２６２０の各々は、４バイトを占める。ＰＶＴリミットフレーム２６００は、ヘッダ情報２６２５及び末尾情報２６３０を任意で含み、その両方は、同期、識別、パリティ、エラー修正、または他のタイプのデータを含んでいてもよい。

開示された実施例の特徴として、ＰＶＴリミットフレーム２６００は、上限トルク限界を指示するトルク限界ターム２６３５を含む。ＰＶＴリミットフレーム２６００は、また、ヘッダ、位置、速度、時間及び末尾データの間または中の長さまたは量を変化させる追加データを含んでもよい。ＰＶＴリミットフレーム２６００は、いずれかの他の適当なデータに対する別のデータフィールド２６４０を任意で含んでもよい。図２６がフレームの特定の場所または領域における様々な情報またはデータを示すとともに、異なる種類の情報及びデータは、ＰＶＴリミットフレーム２６００内のどこに位置してもよい。ＰＶＴリミットフレーム２６００は、いずれかの特定の長さに限定されないということも注目されるべきである。

図２７は、任意のトルク限界タームを備えた典型的なＰＶＴ−ＦＧリミットフレーム２７００を示す。ＰＶＴ−ＦＧリミットフレーム２７００は、任意のヘッダ情報２７１０、位置情報２７１５、速度情報２７２０、時間情報２７２５、及び任意の末尾情報２７３０を含む。

さらに、ＰＶＴ−ＦＧリミットフレーム７０５は、少なくとも１つのフィードフォワードターム２７３５及び少なくとも１つの利得ターム２７４０を含む。データは、1バイト以上でグループ化されたバイナリ形式であってもよい。ＰＶＴ−ＦＧリミットフレームの１つの実施例では、位置ターム２７１５、速度ターム２７２０、時間ターム２７２５、フィードフォワードターム２７３５及び利得ターム２７４０は、各々４バイトを占める。ＰＶＴリミットフレーム２６００と同様に、ＰＶＴ（ＦＧ）リミットフレーム２７００は、異なるタームの中でまたは間で分散された、長さまたは量を変化させる他のデータを含んでいてもよい。

ＰＶＴフレーム２６００と同様に、開示された実施例は、上限トルク限界を指示するＰＶＴ−ＦＧリミットフレーム２７００の一部としてトルクリミットターム２７４５を含む。ＰＶＴリミットフレーム２７００はまた、ヘッダ、位置、速度、時間及び末尾データの間または中で長さ及び量を変化させる追加のデータを含んでいてもよい。別のデータフィールド２７５０は、いかなる他の適当なデータに対して含まれてもよい。図２７はフレームの特定の場所または領域における様々な情報またはデータを示すとともに、異なるタイプの情報及びデータがＰＶＴ−ＦＧリミットフレーム２７００内のどこに配置されてもよいということが注目されるべきである。ＰＶＴ−ＦＧリミットフレーム２７００はいずれかの特定の長さに限定されないということも注目されるべきである。

上記したように、速度及びトルク限界タームが算出されて、エンドエフェクタ１２２０（図１２）の速度及び力へ全体的な限界を課してもよい。軌道は、その速度が指示された制限を超えないように、エンドエフェクタに対して算出される。得られた位置、速度及び加速プロファイルは、次に、上記したロボットの逆の運動学的方程式を用いて、個々の軸の位置、速度及び加速に変換される。軌道情報は、ＰＶＴリミットフレームまたはＰＶＴ−ＦＧリミットフレームに変換されてリモートコントローラ１２３０、１２３５、１２４０を管理するクラスタコントローラ１２１５へ送出される。

例えば、ロボット軸のいくつかまたは全てが、クラスタコントローラに従属させられたリモートコントローラによってよりはむしろ自律リモートコントローラによって制御される場合に、マスタコントローラは、ＰＶＴリミットフレームまたはＰＶＴ−ＦＧリミットフレーム、同様に自律リモートコントローラに送出されてもよい。

開示された実施例の態様の１つとして、オペレーションの教示モードの間、リモートコントローラ１２３０、１２３５、１２４０を管理するクラスタコントローラ１２１５、または、通常、ロボット軸のいくつかまたは全部を制御する自律リモートコントローラは、マスタコントローラ１２４５によって送出された軌道データを照合するために動作してもよい。このように、コントローラがＰＶＴリミットフレームを受信すると、コントローラは、最大速度、速度追跡ウインドウ、速度デバウンス時間、最大トルク、及び最大トルクデバウンス時間に対するチェックを含む多数の照合を実施することによって、メッセージ及びそのデータの適用性を変化させるために動作してもよい。

最大速度をチェックするために、コントローラは、軸が教示モードにあって軸に対する最大速度制限も認識するということを認めてもよい。フレームを受信すると、コントローラは、速度タームが教示モードにおける軸に対して指示された最大速度より下であるということを確かめる。最大速度を超過している場合には、リモートコントローラは、マスタコントローラに警報を送出してもよい。

コントローラは、また、速度追跡ウインドウ、即ち、フレームメッセージからの命令された速度と、軸に対するエンコーダによって測定されるような実際に測定された速度との間の差分に対する最大値を決定してもよい。速度追跡ウインドウを超えた場合には、リモートコントローラは上記したように警報を送出してもよい。いくつかの遷移状態では、速度追跡ウインドウを、発行される警報なしに短い時間の間上回ってもよい。しかしながら、この期間は指定されて監視され、さらに速度追跡ウインドウをこの指定された時間上回る場合には、コントローラは警報を発してもよい。

上記したように、軸に見込まれる最大トルクは、軌道実行の間、特に教示モードで決定されてもよい。コントローラは、受信されたＰＶＴリミットフレームまたはＰＶＴ−ＦＧリミットフレームの限界タームによって指定された最大トルクに対して制御ループによって命令されたトルクをチェックしてもよく、フレームによって指定された最大トルクを上回る場合に警告を生成してもよい。最大速度と同様に、発行される警告なしに短期間の間最大トルクを上回ってもよい。しかしながら、この期間はまた、指示されかつ監視されていて、最大トルクがこの指定された期間を超える場合には、コントローラはまた、警告を発してもよい。コントローラは、軸が教示モードにあるということを認識して、コントローラがフレーム内で受信することを期待する上限のトルク限界で関連する全体の最大を識別してもよい。この全体の最大を上回る場合、コントローラはまた警報を発してもよい。

警報に加えて、これらのパラメータのいずれかの障害はまた、コントローラにモータ駆動出力ステージを無効にさせて、いかなる動作も止める。マスタコントローラは警告されて、全ての他の関係する軸上で全ての動作を停止してもよい。

図１２を再び参照すると、ワークスペースにおける人間の存在を収容するために用いられる開示された実施例の別の態様は、通信ネットワーク、クラスタコントローラ及びマスタコントローラが有効であるという周期的な検証を含んでいてもよい。リモートコントローラ１２３０、１２３５、１２４０は、メッセージが周期的に受信されない場合にリモートコントローラがその軸に対する動作を止めるように、通信を監視するようにプログラムされていてもよい。

例えば、リモートコントローラ１２３０、１２３５、１２４０は、トルクコマンドを受信することなどのメッセージ送信の間の期間を監視するようにプログラムされていてもよい。別の例として、自律リモートコントローラは、ＰＶＴフレームの間の期間を監視してもよい。トルク命令またはＰＶＴフレームが予想される期間内に到着しない場合は、リモートコントローラまたは自律リモートコントローラは、通信ネットワーク１２５０、クラスタコントローラ１２１５またはマスタコントローラ１２４５を有効でないと見なしてもよく、軸またはその制御下の軸に関する動作を止めるように進めてもよい。リモートコントローラまたは自律リモートコントローラによって監視される周期的メッセージは、また、これらのコントローラのクロックを同期させるために用いられるサイクルスタートメッセージであってもよい。

マスタコントローラ１２４５は、また、周期的なステータスメッセージの受信を監視することによってネットワーク通信を監視してもよい。クラスタコントローラ１２１５またはリモートコントローラ１２３０、１２３５、１２４０のいずれかからステータスメッセージを受信しそこねると、マスタコントローラ１２４５は、クラスタコントローラ１２１５と関連しかつリモートコントローラ１２３０、１２３５、１２４０によって制御された軸のいずれかに関するすべての動作を停止させようとしてもよい。

通信ネットワーク、マスタコントローラ、及びリモートコントローラの軌道データ、検証を照合する態様は、各々のネットワークノードにおける特にその目的のためのハードウェアによって達成されてもよい。例えば、クラスタコントローラ１２１５、リモートコントローラ１２３０、１２３５、１２４０、または自律リモートコントローラは、マスタコントローラ１２４５によって送出される軌道データに対して上記した照合機能のいずれかを実施するために個々に動作する専用の回路を含んでもよい。他の実施例として、マスタコントローラ１２４５、クラスタコントローラ１２１５、リモートコントローラ１２３０、１２３５、１２４０、または自律リモートコントローラの１つ以上は、メッセージの間の時間または周期的なメッセージの受信を監視する専用の回路を各々含んでいてもよい。

図２８は、システム保全を特に監視する専用の回路を含む典型的なインテグリティ監視装置２８００のブロック図を示す。インテグリティ監視装置２８００は、プロセッサ２８１０、半導体メモリデバイス２８１５、非半導体メモリ２８２０、及び通信ネットワーク１２０とのインタフェース２８２５を含んでもよい。インテグリティ監視装置２８００はまた、軸位置情報信号２８３５を受信する軸エンコーダ検出回路２８３０、及び軸モータ電流引き込みを指示する信号２８４５を受信する軸モータ電流検出回路２８４０を含んでもよい。さらに、インテグリティ監視装置はまた、タイマ２８５０、教示モードが用いられているということを検出する入力（教示、２８５５）、及び何らかの即時停止要求（Ｉ停止、２８６０）及び、軸に対する電力を制御するスイッチインタフェース２８６５を含んでいてもよい。

通常、プロセッサ２８１０は、メモリ２８１５に記憶されたプログラムの制御下で動作して軌道速度及びトルクデータを照合し、通信ネットワーク１２０の動作を検証し、特定の軸がその動作パラメータを超えるときを認識し、必要な場合は軸から電力を除去するように動作する。

プロセッサ２８１０は、軸が教示モードにあるということを察知し、受信されたＰＶＴフレーム内の速度タームを用いる軸に対する最大速度限界を識別してもよい。プロセッサ２８１０は次に、受信されたフレームの軸タームの実際の速度が、教示モード限界において軸に対して指示されたこの最大速度を超えないということを検証するために動作してもよい。プロセッサ２８１０はまた、速度追跡ウインドウ、それを上回ったか否かそしてどれだけの間かを判断してもよい。プロセッサ２８１０はまた、許容された最大トルク、それを超えたか否か、そしてどのくらいの長さかを判断してもよい。いかなるパラメータの障害の場合でも、プロセッサ２８８０は、軸のシャットダウンを制御し、それらの軸に制御された停止をもたらしてもよい他のコントローラと連携してもよい。

プロセッサ２８１０はまた、ＰＶＴフレームを受信するなど、メッセージ送信の間の期間を監視してもよく、ＰＶＴフレームが予想される期間内に到着しない場合には警報を発するかまたは制御されたシャットダウンを開始してもよい。インテグリティ監視装置２８００は、専用のネットワーク２８７０を介して他のインテグリティ監視装置と通信してもよいのは任意である。

ヨーロッパ機械指令（ＥＮ ６０２０４−１）は、即時停止についての２つのカテゴリを定義する。先ず、カテゴリ０は、電力が単に除去される「未制御のシャットダウン」として定義される。第２のカテゴリであるカテゴリ１は、電力が除去される前に動作を停止させるのに十分な長さを維持される「制御されたシャットダウン」として定義される。人間の存在を適応させるためにカテゴリ１の停止に一致すること、及び製品の損傷を防ぐことは、制御システムの構成要素にとってたいへん望ましい。

電力損失の場合に、システムの軸の運動を制御して軸が設備及び材料に損傷を生じさせないでまたはオペレータを危険にさらさないで軸が停止するようにすることは重要であるかもしれない。共通して用いられる１つの方法は、電力損失が起こるときにレジスタを介して軸モータの巻線を短絡させることである。しかしながら、このことは、モータ巻線パラメータを一致させて所望の減速度を得る抵抗値の慎重なチューニングを要求し、さらに、統合された動作を実行するロボットを受け入れ可能でないかもしれない。なんとなれば、実質的な追跡エラー及びその後の装置または材料への損傷は、個々の軸のシャットダウンが調整されない場合に生じるかもしれないからである。

別の共通の実行は、無停電電源装置（ＵＰＳ）を含むことである。この解決法は、軸を統合された方法で停止するために必要な電力を与えるとともに、それは、実質的な費用、寸法、及び重量を加えてもよく、さらに周期的なサービスを要求してもよい。

別の方法は、電力供給の出力に静電容量または電池容量を提供して、リモートコントローラまたは自律リモートコントローラによってそれらの関係する軸に制御された停止をもたらすことを可能にするのに十分な電力を供給することを含む。このことは、実質的な静電容量または電池容量を必要とするが、電力は、全ての減速イベントの間相対的に安定したままであるからである。

本制御システムで利用される１つの方法は、力率補正（ＰＦＣ）回路のＤＣ出力において供給される静電容量を備えたＰＦＣ回路を介して、入力ＡＣ電圧（典型的な場合では２２０Ｖ）の整流に基づいていてもよい。得られるＤＣ電圧は、広範な入力範囲のＤＣ電力供給（典型的な例では、４８V）へ供給されてもよい。電力が失われると、静電容量は、入力電圧における実質的な減衰にかかわらずＤＣ電力供給を稼動し続ける。

静電容量によって記憶されるエネルギは、動作コントローラが軌道を計画し実施することを可能にするのに十分であるべきである。それは、装置及び材料を保護するために指定された、予め定義された減速率でロボットのエンドエフェクタをそのときの速度からゼロ速度にし、よって、損傷なしにかつ軸位置情報を失うことなしに指定された軌道に沿って統合された動作を維持しながら、制御された停止をロボットにもたらす。

別の実施例は、図３３に示すように、容量記憶モジュール３３００を含んでいてもよい。典型的な容量記憶モジュールは、必要な電力を提供して、停電及び電圧低下の間でさえ、カテゴリ１オペレーションを可能にしてもよい。一意の設計のため、モジュールはまた、例えば、欧州連合またはＳｅｍｉのＦ−４７電圧低下テストなどの、ある電圧低下要求に一致しなくてもよい民生（ＣＯＴＳ）のＰＦＣ電力供給の使用を容易にしてもよい。

容量記憶モジュール３３００の構成要素は、単一のプリント回路基板上に実装されてもよい。ＡＣ電圧３３３５は、ブリッジ３３０５によって整流され、整流された電圧出力３３０７は、力率補正された電力供給へ直接渡されてもよい。整流された電圧出力３３０７と平行に、充電回路３３１０は、容量記憶バンク３３１５上で高電圧を充電しかつ維持してもよい。電力供給監視回路３３２０は、容量記憶バンク３３１５と平行に接続されてもよい。

電力供給監視回路３３２０は、プロセッサ、メモリ、プログラム記憶装置、並びに様々なセンサ及び監視回路を含んでいてもよい。プログラム記憶装置は、プロセッサによってアクセスされるプログラムを含んでいてもよい。プロセッサは、出力電圧３３０７、スイッチ３３２５を作動させること、記憶容量及び容量記憶バンク３３１５の電圧を監視すること、並びに入力電圧３３３５を監視することを含む、電力供給監督装置のオペレーションを指示する。

電力供給監視回路３３２０は、直接接続を介してまたは他のメカニズムによって、整流電圧出力３３０７を監視してもよい。電力供給監視回路３３２０は、例えば電力損失の結果として、整流電圧出力３３０７が予め定めた基準を満たさないと判断すると、電力供給監視回路３３２０は、容量性記憶バンク３３１５をスイッチ３３２５を介して整流電圧出力３３０７に接続する。

いくつかの利点が、この設計によって実現されてもよい。第１に、容量記憶バンクのコンデンサは、減速イベントに必要な総電力より数パーセントだけ多く供給される寸法であってもよい。第２に、ＣＯＴＳ ＰＦＣ電力供給は通常、広範な入力電圧領域にわたって動作してもよいので、コンデンサが蓄積されたエネルギの約８５％を放電しながら出力電圧が正確に維持されてもよい。第３に、高電圧でのエネルギ蓄積は、この解決法をよりコンパクトにし、より費用がかからなくする。なんとなれば、コンデンサに蓄積されたエネルギは、静電容量と二乗された電圧の積に比例し、コンデンサの物理的寸法は、静電容量と電圧の積にほぼ比例するからである。

別の実施例では、電力供給監視装置３３２０は、例えば、システム保全、電力制御機能、またはマスタコントローラ１０５を監視する回路などの、外部回路に警告信号を与えてもよい。警告信号が用いられて、可能な電力問題または他の目的についての他のネットワーク構成要素に警告して、ＥＮ ６０２０４−１によって定義されるようなカテゴリ１停止を可能にしてもよい。制御システムはまた、この警告信号３３３０を用いて、容量記憶バンク３３１５が動作を初期化する前に十分に充電されたということを確認してもよい。警告信号３３３０及び容量記憶バンク３３１５は通常、同時に使用可能にされ、制御システム１００が容量記憶バンク３３１５内で蓄積されたエネルギを利用していかなる移動軸も静止するようにすることを可能にする。蓄積されたエネルギは通常、システムがシステムの状態にかかわりなく静止するようにするのに必要なエネルギに等しいかまたは大きくてもよい。例えば、蓄積されたエネルギは、全ての軸が最大速度で移動しているときに、システムが静止するようにするのに十分なエネルギを含んでもよい。

替わりに、警告信号３３３０のタイミングは容量記憶バンク３３１５の係合に関してシフトされてもよく、一時的な入力電力異常は、サービス中に不要な混乱を生じさせない。このことは、実行の特に魅力的な方法である。なんとなれば、それは、電圧低下要求を満たさなくてもよい電力供給の使用を可能にするからである。

警告信号はまた、予測的で自動の障害検出に対して用いられてもよい、エネルギ記憶容量、入力電圧、容量バンク電圧、及び入力電力インテグリティに関する情報を提供してもよい。

モニタされた、冗長な、ソリッドステート論理を利用して、軸電力の除去を必要とする入力を検出して反応することが本実施例の別の特徴である。このことは、以下に説明されるように、柔軟性を提供し、即時停止情報が複数のゾーンにわたって共有され得るアーキテクチャを支持する。

この特徴を実施するための電力制御機能４０００が、図４０に示される。電力制御機能は、即時停止入力４００５、１つ以上のタイマ４０１０、及び様々なプロセッサ、メモリ、及び電力制御機能を実行するための支持回路を検出するための回路を含む。電力制御機能は、電力制御機能が電力除去を開始したということを示す信号（ステップ４０３５）、１つ以上のロボットの論理電力供給４０５５に対する制御信号４０４０、及びロボットのモータ電力供給４０６５を制御している１つ以上のリレー４０４０に対する制御信号４０４５を提供する。即時停止検出回路４００５は、様々なインターロック４０１５、即時停止信号４０２０、ライブマン信号４０２５、及び様々な制御システム構成要素からの教示モード信号４０３０を受信し、また、マスタコントローラ１０５からモータ電力可能信号４０７０を、かつリレー４０６０からモニタ信号４０５０を受信する。ライブマン信号４０２５は、制御システム１００の少なくとも１つのロボットのワークスペース内に存在する人間がいるということを示す。教示モード信号４０３０は、システムの少なくとも１つの構成要素がオペレーションを教示されているということを示す。

電力制御機能は様々なハードウェア構成要素を含んでいるように説明されるとともに、電力制御機能はハードウェア、ソフトウェア、及びハードウェアとソフトウェアとのいかなる組合せにおいて実施されてもよいということが理解されるべきである。

マスタコントローラ１０５はモータ電力が有効にされるということを要求する場合に、電力制御機能４０００は、最初に、全ての即時停止信号４０２０、ライブマン信号４０２５、インターロック信号４０１５、及び教示モード信号４０３０の状態を検証する。電力制御機能４０００はまた、リレー４０６０の接触器が適当な状態にあって、溶接されていないということを確認して、リレーに関するいかなるソリッドステートスイッチも伝導していないことを検証してもよい。即時停止、ライブマン、インターロック、教示モード信号、接触器及びスイッチの各々の状態が全ての必要要件を満たす場合に、リレー４０６０は有効にされる。リレー４０６０はまた、１つ以上のソリッドステートスイッチイングデバイスとして実施されてもよい。

即時停止信号、ライブマン信号、インターロック信号、または教示モード信号のいずれかが、モータ電力の除去を必要とする状態に至ると、電力制御機能は、マスタコントローラ１０５に警告し、タイマ４０１０を開始する。タイマ４０１０は、電力除去を要求する信号を生成して制御された停止へ至る十分な時間をシステム構成要素に可能にするようにプログラムされる。タイマ４０１０の持続時間は、システム構成要素オペレーションモードによって決定されてもよい。例えば、タイマは、異なる速度または教示モードで動いているロボットに対して異なる間隔で設定されてもよい。

タイマ４０１０の満了で、電力制御機能４０００は、リレー制御信号４０４５を介してモータ電力供給を無効にする。モータ電力は、即時停止信号、ライブマン信号、インターロック信号、または教示モード信号の全てが、モータ電力の回復を可能にする状態に復帰する場合に再度印加されて、モータ電力使用可能信号４０７０は回復する。

電力制御機能４０００は通常、電力分配ユニット内にあってもよい。それは、例えば、以下に説明するように、制御システムの個々のゾーンの電力分散ユニットへ組み込まれる場合、リモートコントローラ及び自律リモートコントローラ群のために働いてもよい。電力制御機能４０００はまた、特定のアプリケーションのために設計された異なる電力分散ユニットにおいて再利用されてもよいプラグ着脱可能なドーター（daughter）カードまたはモジュールとして実施されてもよい。

図４１は電力制御機能４１００の別の実施例を示し、それは、即時停止検出回路が、上記した容量記憶モジュール３３００の電力供給監視回路３３２０からの警告信号を検知する回路を含む。警告信号３３３０は、即時停止信号、ライブマン信号、インターロック信号、または教示モード信号と同様の方法で用いられて、１つ以上のネットワーク構成要素からの電力除去のトリガーとなってもよい。

いかなる障害及びその後のダウンタイムが、損傷を与えられた材料及び失われた生産性における何万ドルを意味する生産環境において、動作制御システムの信頼性は、重大な要求である。開示された実施例の制御システム１００（図１）のアーキテクチャは、制御下の構成要素の近くにリモートコントローラを配置して、よってフィードバック信号及びアクション信号を運ぶ無線及び装置の長さ及び複雑さを減じることによって、よりよい信頼性を概して実現してもよい。しかしながら、いくつかの例では、通信ネットワーク１２０自体は、通信ネットワーク１２０が相対的に長い距離を実行するので、障害に脆弱であって、多くの場合には、全てのノードとノードの間の接続が機能的である場合にだけ十分動作し続けるかもしれない。そうでなければ、多くのトポロジにおいて、単一の接続または単一のノードの機能不良は、通信ネットワーク１２０のセグメントまたは全体に障害を生じるかもしれない。従って、ケーブル破損などの欠陥のある通信ネットワーク接続、または１つ以上のネットワークノードの障害の場合にさえ可能な最大範囲まで制御システム１００を動作可能に維持する通信ネットワークソリューションを提供することが望ましい。

ＩＥＥＥ １３９４ｂ標準並びに他のネットワーク標準及び実施は、他の３つのタイプのネットワークトポロジにおいて物理的ループを形成する非アクティブセグメントを可能にする。非アクティブセグメントは、通信ネットワーク１２０のノードの間で冗長な接続を設けるために用いられてもよい。ネットワークは、例えば、ＰＨＹポートを選択的に無効にすることによって、自動的に冗長接続を無効にすることを可能にされてもよい。障害時に、ネットワークは、冗長接続を選択的に有効にして、障害によって切り離されたノードへのパスを形成する能力を有していてもよい。このことは、例えば、ＩＥＥＥ １３９４ｂ標準における固有の機能を用いて実現されてもよい。他のネットワーク実施はまた、冗長な接続を検出して無効にし、次に障害の場合にそれらを選択的に有効にする能力を有していてもよい。

これらの特徴は、ケーブル破損または通信ネットワーク１２０上のノードの完全な故障がある場合であっても制御システム１００が動作するということを保証する一意の自己回復耐障害性を提供するために利用されてもよい。特に、ネットワークノードまたはアクティブなネットワーク接続が機能しなくなる場合に、通信ネットワーク１２０は、障害の前にアクティブでなかった冗長接続を介して通信のルートを決めるためにそれ自体を再構成してもよい。２つのネットワークノードの間の接続は、セグメントと称される。

ＩＥＥＥ １３４９標準は、開示された実施例を説明するときに例として用いられるとともに、開示された実施例は、ＩＥＥＥ １３９４に基づくネットワークに限定されないということに注意することが重要である。他のネットワークが、開示された実施例を実施するのに適当な特徴を含む限り、他のネットワークの実施も利用されてもよい。

ネットワーク１２０上のノードが機能しなくなる場合に、ネットワークは、代替セグメントを介して通信のルートを決めるためにそれ自体を再構成してもよく、新しい通信ルートを用いて全てまたは選択された動作の軸の即時停止を実施してもよい。このように、バストポロジの物理的ループは、ネットワーク全体を介して冗長な通信パスを提供してもよく、それは、障害の場合に二次的なデータチャネルとして用いられ得る。

図３４ａは、冗長接続を提供するネットワーク１２０の典型的なトポロジ３４００を示す。トポロジ３４００は、メインループ２３０５及び多数の周辺ループ３４１０、３４１５、３４２０をふくむ。メインループ３４０５は、マスタコントローラ３４２５を含み、メインループ３４０５及び周辺ループ３４１０、３４１５、３４２０の各々はリモートコントローラ３４３０を含む。非アクティブなセグメント３４７５がノードの間で冗長なループ接続を提供するとともに、トポロジ３４００のアクティブなセグメント３４７０はツリータイプのトポロジを形成するということに注意すべきである。

図３４ｂは、メインループ３４０５のセグメント３４４０において障害３４３５を有するトポロジ３４００を示す。上記したように、ネットワーク１２０は、障害ノード３４３５においてそのとき未使用のセグメント３４４０を無効にし、以前に未使用のセグメント３４４５を介して通信のルートを決めるためにそれ自体を再構成した。図３４ｃは、メインループ３４０５において例えば機能しないリモートコントローラなどの機能しないノード３４５０を有するトポロジ３４００を示す。この例では、ネットワーク１２０は、セグメント３４５５、３４６０を無効にし、以前に未使用のセグメント３４６５を介してこのとき通信のルートを決める。図３４ｄ及び３４ｅは、周辺ループ３４２０における同様の典型的な障害及び再構成技術を示す。

単純なリングトポロジでは、障害を識別して冗長な接続に切り替えることは相対的に容易であるかもしれない。しかし、複数の物理的ループを備えた一般的なシステムにおけるこの種の自己組織化していて自己回復機能を有効にすることは実質的により難しいかもしれない。本実施例は、冗長接続を利用することができるなんらかのネットワーク実施のフレームワークを利用して、障害を補償するというメカニズムを提供する。通信ネットワーク１２０における多数の物理ループを備えた制御システムが、セグメントまたはノードの障害による時間にわたってその構成が変化するときにさえ、機能を続けることを可能にする。

本実施例によるメカニズムはまた、軌道フレームの効果的なバッファリングに対する方法及び、通信ネットワークにおける同期遅延を補償する方法を含む。

動作同期は、マスタコントローラ１０５、クラスタコントローラ１１０、並びにリモート及び自律リモートコントローラ１１５を含む全てのネットワークノード上でクロックを同期させることによってクラスタ化アーキテクチャ制御システム１００において維持されてもよい。１つの実施では、サイクルスタートメッセージとも称される同期メッセージは、通常マスタコントローラ１０５である、サイクルマスタとして指定されたノードによって送出されてもよい。

ネットワークノードによってマスタコントローラ１０５から同期メッセージを受信する際の遅延は、ネットワークノードにおけるクロックの間の差分を生じる。遅延の最大構成要素は、同期メッセージの送信の間リピータ遅延と関連する。リピータ遅延は、メッセージの受信及びメッセージがそのあて先へ到達するまでの次のノード上にメッセージを送出する処理の間、各々のノードによってもたらされる遅延をいう。所定のノードに対する全体の伝播遅延は、マスタコントローラから目的ノードへのパスに沿った全てのリピータ遅延の累積合計であると仮定されるかもしれない。

サイクルスタートメッセージのパスは、ネットワークトポロジから各々のノードに対して決定されてもよい。伝播遅延は、メッセージパスに基づいて予測されてもよい。各々のノードに対する予測された伝播遅延は、そのノードに対するＰＶＴフレームにおける軌道データを調整することによって相殺されてもよい。

伝播遅延を予測する１つの方法では、マスタコントローラ１０５は、より大きな伝播遅延が１４４ｎｓを上回らないようにネットワークトポロジが設計されたという仮定に基づいて、１４４ｎｓの名目上の値を単に用いてもよい。別の方法では、各々のノードに対するリピータ遅延は、例えばノード内のメモリ位置において予め定められて記憶されてもよい。マスタコントローラは、メモリ位置から特定のノードに対するリピータ遅延を読み込んでもよい。１つの例では、リピータ遅延は、例えば、ベースＰＨＹレジスタなどのノードレジスタの遅延フィールドに記憶されてそこから読み込まれてもよい。

マスタコントローラ１０５は、次に、リピータ遅延を利用して、各々のノードに対する遅延補償を算出してもよい。１つの実施例では、マスタコントローラ１０５は、拡張された一意の識別子（ＥＵＩ−６４）によってＥＵＩ−６４を報告するノードに対してリピータ遅延にインデックスを付けてもよく、そうしないノードに対して予測された値を用いてもよい。

マスタコントローラ１０５から通信ネットワーク１２０上のノードのいずれかへの全体の伝播遅延を予測する別の方法は、マスタコントローラ１０５に対して各々のノードにピンを打ってピンに対する応答時間を記録することである。替わりに、マスタコントローラは、ＰＨＹレジスタ要求パケットへの応答を記録してもよい。ピンまたは要求及び応答に対する往復の時間の差は、マスタコントローラから通信ネットワーク１２０上の異なるノードへの累積伝播遅延として利用されてもよい。

各々のノードに対する遅延補償は、通信ネットワークがそれ自体再構成するたびにマスタコントローラによって再算出されてもよい。

図３８は、代表的なＩＥＥＥ １３９４ｂ自己同一化プロセスの結果を示す。他のネットワーク実施は、この種の自己同一化が可能であってもよく、そして、開示された実施例はＩＥＥＥ １３９４ｂタイプのネットワークに限定されないということに注意することが重要である。

マスター（ルート）へのノードＭ_０に対するパスは、ノードＭ_０、Ｍ_１、Ｍ_２、・・・、Ｍ_ｎによって定義され、ここで、Ｍ_ｉはＰＨＹ ｉｄであり、Ｍ_ｎはルート（Ｍ_０＜Ｍ_１＜Ｍ_２＜・・・＜Ｍ_ｎ）であり、Ｍ_ｉの親としてｐ（Ｍ_ｉ）及びｔ（Ｍ_ｉ）としてＭ_ｉに対するリピータ遅延を意味し、ノードＭ_０に対する全伝播遅延はΣｔ（ｐ（Ｍ_ｉ））であり、ここでｉ＝０，１，２，・・・，ｎ−２である、と仮定せよ。

マスタコントローラ１０５は、通信ネットワーク１２０上で起こっているバスリセット及びセルフィドコンプリート（selfid-complete）メッセージを観察することによって、再構成イベントを知らせることができる。セルフィドコンプリートパケットは、十分な情報を提供して、マスタコントローラ１０５は、新しいネットワークトポロジ及びマスタコントローラから各々のノードへのパスを決定してもよい。各々のノードからマスタコントローラ１０５へのパスは、ルートが到達されるまでいずれかのノードからその親ノードへパスの連結によって一意に画定されてもよい。各々のノードからの全体の伝播遅延は、そのパスに沿ったリピータ遅延の合計から判断されてもよい。一旦ノードに対する全体の伝播遅延が判断されると、ノードは、伝播遅延情報を用いて、軌道データ（ＰＶＴフレーム）を相殺してもよい。

図３５を参照すると、通信ネットワーク１２０がセグメントまたはノード障害の結果として再構成するときに伝播遅延を再計算することにおいて、以下の手順が有利である。

ブロック３５０５に示すように、マスタコントローラ１０５は通常、通信ネットワーク１２０におけるサイクルマスタの役割を得てもよく、ブロック３５１０に示すように、上記したように通信ネットワーク１２０上の各々のノードに対するリピータ遅延を予測してもよい。ブロック３５１５に示すように、マスタコントローラは、通信ネットワーク１２０上の各々のノードに、対応する遅延見積りを送出する。通信ネットワーク１２０上の各々のリモートノードは、ブロック３５２０に示すようにＰＶＴフレームを実行するときに、タイムオフセットとしてマスタコントローラ１０５から受信した見積りを適用する。例えば、所定のＰＶＴフレームの実施のための時間は、ＰＶＴフレームの時間フィールドから伝播遅延の見積りを引いて算出され得る。

別の実施例では、マスタコントローラ１０５によって送出されたＰＶＴまたはＰＶＴ−ＦＧフレームは、伝播遅延情報を運ぶタイムオフセット（ＴＩＭＥ＿ＯＦＦＳＥＴ）と称される追加フィールドを含んでもよい。

各々のネットワークノードは、次に、ＰＶＴフレームを実施するときにタイムオフセットフィールドから伝播遅延情報を適用してもよい。例えば、所定のＰＶＴフレームの実施のための時間は、ＰＶＴフレームの時間フィールドからタイムオフセットを引いて算出され得る。

バスリセットイベントを伴うトポロジ変更の場合には、リモートノードは、バスリセットの前にバッファリングされてバスリセット後に再同期クロックを用いて実施されるべきＰＶＴフレームのタイムオフセットフィールドを廃棄してもよく、バスリセット後に受信された第１のＰＶＴフレームからのタイムオフセット情報を備えたフィールドに置換してもよい。

図３６は、追加のタイムオフセットフィールドを有する典型的なＰＶＴフレーム３６０５を示す。ＰＶＴフレーム３６０５は、位置データ３６１０、速度データ３６１５及び時間データ３６２０を含む。ＰＶＴフレーム３６０５は、ヘッダ情報３６２５及び末尾情報３６３０を任意で含んでもよく、その両方は、同期、識別、パリティ、エラー修正、または他の種類のデータを含んでもよい。さらに、フレームがアドレス指定されたノードに対する伝播遅延情報を含むタイムオフセットフィールド３６３５を、ＰＶＴフレーム３６０５が含んでいてもよい。

図３６は、フレームの特定の場所または領域のさまざまな情報またはデータを示すと共に、情報及びデータの異なるタイプは、ＰＶＴフレーム３６０５内のどこに位置していてもよい。ＰＶＴフレーム３６０５はいかなる特定の長さにも限定されないということに注意すべきである。

図３７は、追加のタイムオフセットフィールドを有する典型的なＰＶＴ−ＦＧフレーム３７０５を示す。ＰＶＴ−ＦＧフレーム３７０５は、ＰＶＴフレーム３６０５と同様に、任意のヘッダ３７１０、位置３７１５、速度３７２０、時間３７２５、及び任意の末尾情報３７３０を含む。さらに、ＰＶＴフレーム３７０５は、フレームがアドレス指定されたノードに対する伝播遅延情報を含むタイムオフセットフィールド３７３５を含んでもいてよい。

ＰＶＴフレーム３６０５と同様に、ＰＶＴ−ＦＧフレーム３７０５は、さまざまなタームの中または間で分散された、長さまたは量を変化させる他のデータを含んでもよい。

また別の方法として、伝播遅延は、ネットワークノード上で直接予測されてもよい。各々のネットワークノードは、バスリセットに続く自己ＩＤパケット内の情報に基づいてマスタコントローラ１０５からのパスを決定してもよい。各々のノードは、次に、伝播遅延に本質的に等しい予測された遅延を算出してもよく、ＰＶＴフレームを実施するときに対応するオフセットを適用してもよい。

制御システム１００では、１つ以上の構成要素に即時中止するように要求するかまたは、上記した速度制限または力限界特性のいくらかを引き起こすように要求するイベントが生じてもよい。これらの状況は、影響を受けた構成要素と相互に作用する他の構成要素に逆に衝撃を与えるかもしれず、場合によっては、制御システム全体に不利に影響するかもしれない。

制御システム１００を複数ゾーンに分割して、１つのゾーンで起こっている構成要素の停止、速度限界、または力限界を必要としているイベントが、他のゾーンのオペレーションに影響を及ぼさないようにすることは、開示された実施例の特徴である。システムをゾーンに分離する別の利点は、他の構成要素またはノードが働き続けるとともに、制御システム１００の構成要素またはノードは、例えば、教示モードまたは除去された電力でのシャットダウンにおいてサービスを提供されているということである。

複数のワークゾーンを有する制御システムは、全てのゾーンにわたって広範囲の即時停止機能を提供し、他のゾーンにおいてオペレーションを維持しつつ選択されたゾーンへのアクセスを提供するために各々のゾーンにおいてインターロックを局所的に扱ってもよい。教示ペンダント及びライブマン機能はまた、ゾーン毎方式で支持されてもよい。各々のゾーンは、また、統合された安全サポートを有するそれ自体の電力配分装置を有していてもよい。

開示された実施例による複数のゾーンを有する制御システム例の適用は、図３９に示される。

図３９は、大気ゾーン３９０５及び真空ゾーン３９１０を有する制御システム１００の一部を示す。大気ゾーン３９０５は、２台のロボット３９０６、３９０７及び２つのアライナ３９０９、３９０８を含む。真空ゾーン３９１０は、ロボット３９１１を含む。各々のゾーンは、上記したように電力制御機能４０００を含んでもよい関連するインテリジェント電力配分装置３９１５、３９２０を有していてもよい。ローカルシステムインテグリティ信号３９３０は、Ｉ停止、インターロックまたはライブマンイベントをマスタコントローラ１０５に通信して、広範囲にまたは単一のゾーン内でのいずれかで制御された停止を開始するために用いられる。この特定の例では、ローカルシステムインテグリティ信号３０３０は、各々のゾーン内でリモートコントローラ３９４０、３９４５の１つに供給されて、マスタコントローラ１０５に通信される。マスタコントローラは、通信ネットワーク１２０を介して各々のゾーンの構成要素へ通信する。

さらに、例えばイーサネット（登録商標）ネットワークなどの一般的な通信ネットワーク３９５０は、１つまたは複数の教示ペンダント３９５５、３９６０と通信することを含む、半導体基板処理アプリケーションにおけるロードポートなどの他の下位のまたは独立した自動化構成要素との制御システムの通信を収容するのに役立つ。教示ペンダントインタフェースは、一般的な通信ネットワーク３９５０へ通信を提供して、Ｉ停止、ライブマン、及びペンダント存在信号を含んでもよい。

各々のゾーン３９０５、３９１０は、ゾーンツーゾーンインテグリティ信号３９２５を共有し、それは、インターロック、即時停止指示、及びシステムＡＣ電源の状態に対する信号を含む。隣接するゾーンの存在を示す、前のゾーン及び次のゾーンの信号が含まれてもよい。

マスタコントローラはゾーン３９０５、３９１０内の動作を分離するように動作して、大気ゾーン３９０５で起こっているイベントは真空ゾーン３９１０の動作のオペレーションを生じさせない。例えば、大気ゾーン３９０５における障害の場合には、大気ゾーンは、無効にされて、制御された停止になされてもよい。実施例は、１つのゾーンの動作を別のゾーンでの動作から分離するのに役立つとともに、それらも、ゾーンの間でイベントを通信しかつ１つ以上のゾーンの統合されて制御されたシャットダウンを保証する能力を提供してもよい。

例えば、マスタコントローラは、大気ゾーン３９０５のシャットダウンを要求するようなゾーンツーゾーン即時停止信号を識別してもよい。マスタコントローラ１０５はまた、真空地帯３９１０をシャットダウンしてもよい。なんとなれば、それは大気ゾーン３９０５から物質を受けとるからである。替わりに、マスタコントローラは、制御システム１００の別のゾーンに大気ゾーン３９０５に対して元々予定されていた仕事を送ってもよい。

このように、開示された実施例は、第１のゾーンにおける動作が第１のゾーン以外のゾーンにおける動作と分離されるように、ネットワークのノードをゾーンに割り当てることによって制御システムネットワークのインテグリティを維持するという方法を提供する。

いくつかのロボットが静止している場合、それらは再開時に位置エラーを有するかもしれないということが観察された。例えば、アイドル後の開始時に、ロボットは適当な場所へ進むことができないかまたは受け入れ可能な動作の耐性の範囲内で適当な場所に基板を配置しないかもしれない。これらのエラーは、様々な構成要素の温度及び相対的な場所、潤滑剤粘度、または様々な他の要因によるかもしれない。これらのエラーは、多くの運動の後、通常除去される。

ロボットが働いていない時間を記録することは、開示された実施例の特徴である。ある一定のアイドルタイムを上回った場合、ロボットの性能特性が判断されてもよい。性能特性が仕様を満たさない場合、ロボットはウォーミングアップ運動を実施するように指示されてもよい。ウォーミングアップ運動は、十分な運動を提供する１つ以上の動作を含み、働いていないロボットの結果として浮上する位置精度エラーを排除してもよい。

開示された実施例の別の態様では、アイドルタイムを上回った場合、ロボットは、性能特性を判断することなしにウォーミングアップ運動を実施するように指示されてもよい。

図２９は、この実施例が実施されてもよいワークセル２９００を示す。ワークセル２９００は、クラスタコントローラ２９１５及び３台のリモートコントローラ２９３０、２９３５、２９４０を有するロボット２９１０を含む。クラスタコントローラ２９１５は、通信ネットワーク２９４０を介してマスタコントローラ２９４５と通信する。ワークセル２９００は、また、リモートコントローラ２９６０によって制御されてもよいアライナ２９５５を含んでもよい。リモートコントローラ２９６０は、マスタコントローラ２９４５によって制御されてもよい。ワークセル２９００は、ロボットの位置を検知する１つ以上のセンサ２９６０、２９６５、２９７０を任意に含んでいてもよい。１つの実施例では、センサ２９６０、２９６５、２９７０は、ロボット２９１０に搭載されるかまたはそうでなければ中に組み込まれてもよい。典型的な実施例では、ワークセル２９００は、クラスタ化アーキテクチャ制御システム１００（図１）の一部であってもよい。

図３に戻って参照すると、クラスタコントローラ２９１５は通常、プロセッサ３０５、リードオンリメモリ３１０、ランダムアクセスメモリ３１５、プログラム記憶装置３２０、及びネットワーク１２０に対するネットワークインタフェース３３０を含む。プロセッサ３０５は通常、例えば、オンボードプログラム可能メモリ３３５などのコンピュータ使用可能媒体、リードオンリメモリ３１０、ランダムアクセスメモリ３１５、及びプログラム記憶装置３２０などのコンピュータプログラム製品から情報及びプログラムを読み込むことができる。

オンボードプログラム可能メモリ３３５、リードオンリーメモリ３１０、ランダムアクセスメモリ３１５及びプログラム記憶装置３２０は、ロボット２９１０の性能特性を判断しかつウォーミングアップ運動の動作を介してロボット２９１０に指示するためのプログラムを含んでいてもよい。

図２９及び３０を参照しつつ、開示された実施例の典型的なオペレーションがここで説明される。

ロボットアイドルタイム、ロボット性能特性を決定して、ロボットウォーミングアップ運動を実施することと関係する機能が、クラスタコントローラ２９１５によって実施されるように主に説明されるとともに、ワークセル２９００がかかるシステムの一部である場合、機能はマスタコントローラ２９４５、リモートコントローラ２９３０、２９３５、２９４０、ワークセル２９００のいずれかの適当な構成要素、またはクラスタ化アーキテクチャ制御システム１００（図１）のいずれかの適当な構成要素によって実施されるということが理解されるべきである。

さらに、アイドルタイム、性能特性、及びウォーミングアップ運動が通常、ロボット２９１０と関係付けられるとともに、これらの機能及び特性を決定することに関係付けられた機能も、個々の軸またはロボットの結合、ワークセル２９００の他の構成要素に対して、または他のクラスタ化アーキテクチャ制御システム構成要素に対して実施されてもよい。

クラスタコントローラ２９１５は、ロボット２９１０がアイドル状態にあるときを認識する回路またはプログラムを備えていてもよい。例えば、ロボット２９１０は、スタンドバイモードに入り、シャットダウンするための特別の命令を受信してもよいし、または単にある一定の時間の間いずれの動作コマンドも受信しなくてもよい。ブロック３０１０に示すように、クラスタコントローラ２９１５は、ロボット２９１０が働いていないということを判断し、ブロック３０１５に示すように、アイドル状態が判断される時間の表示としてタイムスタンプを取っておく。

クラスタコントローラ２９１５は、ブロック３０２０に示すようにロボット２９１０に送出されたコマンドを監視する。動作コマンドが受信されると、クラスタコントローラ２９１５は、ブロック３０２５に示すように、ロボットが働いていなかった時間を判断する。ブロック３０３０に示すように、アイドルタイム閾値を上回る場合、クラスタコントローラは、次に、例えば、ブロック３０３５に示すように働いていないロボットによる位置精度エラーを排除するのに十分な運動を通常与える１つ以上の動作コマンドの形式で、ロボット２９１０にウォーミングアップ運動を発行してもよい。ウォーミングアップ運動を実施した後、ロボットは次に、ブロック３０４５に示すように、動作コマンドを実行してもよい。

図３１は、図３０のブロック３０３５に対する代替手順を示す。ブロック３１１０に示すように、アイドルタイム閾値を上回った場合、クラスタコントローラ２９１５はロボット２９１０の性能特性を確認してもよい。例えば、クラスタコントローラ２９１５は、ロボットにテスト動作コマンドを発行して、次に、センサ２９６０、２９６５、２９７０を確認し、ロボットが仕様書の範囲内でコマンドを実行したことを保証してもよい。別の例として、クラスタコントローラは、ロボット２９１０にアライナ２９５５上に基板２９７５を置くように指示し、次に置かれた基板の整列を確認することによって、性能特性を確認してもよい。

性能特性が仕様の範囲内にある場合、クラスタコントローラ２９１５は、図３１のブロック３０４５に示すように、ロボットが動作コマンドを実行することを可能にしてもよい。仕様を満たさない場合、クラスタコントローラ２９１５は、ブロック３１１５に示すように、例えば、オーバーライドを要求している、ユーザインタフェース２２５（図２）を介して、オペレータへの警告またはアシストするための要求を発行してもよい。他の選択肢として、クラスタコントローラ２９１５は、ユーザが介入するまでロボット２９１０のオペレーションを停止してもよい。一旦オーバーライドが提供されると、ロボットは次に、図３１のブロック３０４５に示すように、動作コマンドを実行してもよい。

開示された実施例は、ウォーミングアップ運動を実施することによってロボット配置エラーを補償するメカニズムを提供するとういことが理解されるだろう。実施例の１つの態様では、ロボットがある一定期間働いていなかった場合、ウォーミングアップ手順が実施されてもよい。更なる改良として、特定の仕様が満たされない場合、ロボットの性能特性が判断されて、ウォーミングアップ運動が実施されてもよい。ウォーミングアップ運動は、十分な運動を提供する１つ以上の動作を含み、働いていないロボットの結果として浮上する位置精度エラーを取り除く。

複雑な制御システムでは、システム構成要素にアクセスするための標準化された一組のインタフェース協定を利用することが有利である。これらは、様々なシステム構成要素と通信するための共通の形式をユーザに提供する、一組のコマンド、パラメータ、変数、その他を含んでもよいアプリケーションプログラムインタフェース（ＡＰＩ）によって提供されてもよい。

一般的なコマンドの使用が、オペレーションを実施するための特定の構成要素、位置、及び他のパラメータを識別するオペレーション及び特定の引数を実施することを可能にする、汎用コマンドセットを含むＡＰＩを提供することが、開示された実施例の特徴である。

ＡＰＩを介して、オペレーションを実施する実際の動作が、引数に依存して変化してもよいということは、開示された実施例の別の特徴である。例えば、位置としてロボット及びアライナを指定する「ピックフロム（ＰｉｃｋＦｒｏｍ）」コマンドを用いることは、位置としてロボット及びロードポートを指定することよりもむしろ完全に異なる一組の運動という結果になってもよい。

図４２を参照すると、ＡＰＩは、資源コーディネータ４３０５、シーケンス製法４３１０、及びシーケンスマネージャ４３１５を含んでいてもよい。資源コーディネータ４３０５からのコマンドは、シーケンス製法４３１０に投入される。シーケンス製法４３１０は次に、一連のコマンドをシーケンスマネージャ４３１５に提示し、シーケンスマネージャ４３１５は資源を割り当ててコマンドシーケンスを実行させる。ＡＰＩは、下記のような一組のコマンドを含んでいてもよい。各々のコマンドは通常、コマンド引数が続くコマンド名を含む。開示された実施例のコマンドでは、ターム主体、資源及びロボットは、オペレーションを実行することができるいかなるデバイスにも言及する。

指定されたロボット位置を用いて指定された物質資源位置から物質を取り出すためのコマンドは、ピックフロムコマンドと称され、以下のフォーマットを有していてもよい。
PickFrom(IRobot robot, int robotLocation, IMaterialHolder materialSource, int sourceLocation)
ここで、robotは、取り出し動作に対する主要な主体を指定する。
robotLocationは、取り出し動作に対して用いられるべき通常チップである主体インデックスを指定する。
MaterialSourceは、そのとき物質を保持しているデバイスを指定する。
sourceLocationは、物質が存在するデバイスへのインデックスを指定する。

指定されたロボット位置を用いて指定された物質目的位置に物質を配置するためのコマンドは、プレースツー（PlaceTo）コマンドと称され、以下のフォーマットを有していてもよい。
PlaceTo(Irobot robot, int robotLocation, IMaterialHolder materialDestination, int destinationLocation）
ここで、robotは、配置動作に対する主な主体（ロボット）を指定する。
robotLocationは、通常物質が存在するチップである、主体インデックスを指定する。materialDestinationは、あて先オブジェクトを指定する。さらに、
destinationLocationは、あて先オブジェクトへのインデックスを指定する。

構成されたポイントに対するピックフロムオペレーションの一部を実行するコマンドは、ピックプレップ（PickPrep）コマンドと称されてもよい。ピックプレップコマンドは通常、ツールのスループットを上げるために指定された物質資源に近いロボットを移動させるために用いられてもよい。ピックフロムコマンドがロボット減速に先立ち送出されなければ、オペレーションは構成されたポイントで停止してもよい。

ピックプレップコマンドは、以下の形式を有していてもよい。
PickPrep(IRobot robot, int robotLocation, IMaterialHolder materialSource, int sourceLocation)
ここで、robotは、取り出し動作に対する主な主体を指定する。
robotLocationは、取り出しオペレーションに対して用いられるべき通常チップである主体インデックスを指定する。
materialSourceは、そのとき物質を保持するデバイスを指定する。そして、
sourceLocationは、物質が存在するデバイスへのインデックスを指定する。

構成されたポイントへのプレースツーオペレーションの一部を実行するコマンドは、プレースプレップ（PlacePrep）コマンドを称されてもよい。プレースプレップコマンドは、通常、ツールのスループットを上げるために指定された物質資源に近いロボットを移動させるために用いられてもよい。オペレーションは、プレースツーコマンドがロボット減速に先立ち送出されなければ、構成されたポイントで停止してもよい。

プレースプレップコマンドは、以下の形式を有していてもよい。
PlacePrep(IRobot robot, int robotLocation, IMaterialHolder materialDestination, int destinationLocation)
ここで、robotは、配置動作に対する主な主体（ロボット）を指定する。
robotLocationは、物質が存在する通常チップである、主体インデックスを指定する。
materia1Destinationは、あて先オブジェクトを指定する。そして、
destinationLocationは、あて先オブジェクトへのインデックスを指定する。

指定されたロボット位置を用いて、物質資源位置から目的位置へ基板を移動させるコマンドは、ムーブフロムツーコマンド（MoveFromTo）と称され、以下の形式を有していてもよい。
MoveFromTo(IRobot robot, int robotLocation, IMaterialHolder materialSource, in sourceLocation IMaterialHolder materialDestination, int destinationLocation)
ここで、robotは、オペレーションに対して用いられるべき主な主体を指定する。
robotLocationは、オペレーションに対して用いられるべき通常チップである主体インデックスを指定する。
materia1Sourceは、そのとき物質を保持する目的を指定する。
sourceLocationは、物質が存在する目的へのインデックスを指定する。
materia1Destinatianは、あて先オブジェクトを指定する。そして、
DestinationLocationは、あて先オブジェクトへのインデックスを指定する。

指定されたマッピングデバイスを用いて、指定された資源をマッピングするコマンドは、マップリソース（MapResource）コマンドと称されてもよい。資源をマッピングすることは、資源がなんらかのアイテムを保持または支持しているかどうかを判断することを含んでいてもよく、また、保持されるかまたは支持されているアイテムの位置を判断することを含んでいてもよい。マップリソースコマンドはまた、指定された資源における位置の状態の記録を、例えば占有された、占有されない、その他などの、適当な値に更新してもよい。

マップリソースコマンドは、以下の形式を有していてもよい。
MapResource(IMapper, IMaterialHolder resource)
ここで、mapperは、指定された資源をマッピングすることができるデバイスを識別する。
resourceは、マッピングを要求しているデバイスを識別する。

準備が出来ている状態へ指定された資源を開始するコマンドは、イニシャライズリソース（InitializeResource）コマンドと称されてもよい。例えば、資源がロボットである場合、イニシャライズリソースコマンドは、ロボットに周知の位置またはホームへ移動させ、次に安全な位置へ移動させる。このコマンドはまた、メカニズムが有効である場合には、資源のロッキングメカニズムをリセットしてもよい。

イニシャライズリソースコマンドは、以下の形式を有していてもよい。
InitializeResource（IWorkcellObject resource）
ここで、resourceは、開始する資源を指定する。

戦略または製法に基づいて資源を初期化するコマンドは、また、イニシャライズリソース（InitializeResource）コマンドと称されてもよい。戦略または製法が指定されない場合には、標準またはデフォルトの製法が最初にロボットを、次に取り付けられたモジュールを初期化してもよい。

戦略を利用するイニシャライズリソースコマンドは、以下の形式を有していてもよい。
InitializeResources（recipe)
ここで、recipeは、初期化された戦略を指定する。

開示された実施例は、一般的なコマンドの使用が、オペレーションを実行するための特定の構成要素、位置、及び他のパラメータを識別するための特定の引数を用いてオペレーションを実行させることを可能にするということが理解される。このように、開示された実施例は、モデルに基づく制御を提供し、構成要素の動作を同期させ、このアーキテクチャのシステムに対して特にプロトコル拡張を提供する、集中化及び分散化、即ち、柔軟であって拡張性があるという両方の利点を有している、ネットワーク化された制御システムを説明する。制御システムはまた、分散されたイベント捕捉及びアプリケーションプログラムインタフェースを提供する。さらに、システムは、無線通信能力を含み、構成要素のワークスペースにおいて人的存在を収容し、高レベルのシステム統合を提供し、即時停止を要求する停電及び環境を提供し、さらにロボットの働かないで座っている時間による位置エラーを排除するためのウォーミングアップ能力を提供する。

開示された実施例を実施するのに適したクラスタ化アーキテクチャの制御システムのブロック図を示す。 クラスタ化アーキテクチャの制御システムのオペレーションを制御するマスタコントローラのブロック図を示す。 マスタコントローラの制御下で動作することができるクラスタコントローラのブロック図を示す。 マスタコントローラまたはクラスタコントローラの制御下で動作することができるリモートコントローラのブロック図を示す。 クラスタ化アーキテクチャ制御システムの典型的なアプリケーションを示す。 自律リモートコントローラを用いている制御システムの典型的なアプリケーションを示す。 位置、速度及び時間情報を運ぶために用いられる典型的なＰＶＴフレームを示す。 フィードフォワードターム及び利得タームを含む、位置、速度及び時間情報を運ぶために用いられる典型的なＰＶＴ−ＦＧフレームを示す。 異なる種類の制御アルゴリズムを用いている実験的に得られた追跡エラーの比較を示す。 開示された実施例の通信ネットワークの典型的なバスサイクルを示す。 開示された実施例の通信ネットワークの典型的なサイクルスタートメッセージを示す。 通信ネットワークノードの間の同期のための典型的な高分解能レジスタを示す。 通信プロトコル構造を示す。 通信プロトコル構造の一部としてプラグ実装を示す。 ワークセルの図を示す。 瞬間データ収集シーケンスについてのフロー図を示す。 瞬間データ収集シーケンスについての別の実施例のフロー図を示す。 瞬間データ収集シーケンスのさらに別の実施例のフロー図を示す。 信号遷移遅延を較正する手続きについてのフロー図を示す。 典型的な制御メッセージ構造を示す。 典型的なアクションメッセージを示す。 典型的なイベントメッセージ構造を示す。 ベンダ固有のイベントメッセージの例を示す。 ストリングメッセージ構造の例を示す。 ベンダの特定のイベントメッセージの例を示す。 ＰＶＴまたはＰＶＴ−ＦＧメッセージ構造の例を示す。 ステータスメッセージの例を示す。 通信ネットワークが無線部分を有している図１のシステムの一部を示す。 任意のトルク限界タームを有する典型的なＰＶＴフレームを示す。 任意のトルク期間を備えたＰＶＴ−ＦＧフレームを示す。 共通の統合されたチェック及びシャットダウン回路ユニットを有するリモートコントローラのブロック図を示す。 ロボットのウォーミングアップ運動を実施するのに適したワークセルの図を示す。 ロボットのウォーミングアップ運動の実施についてのフロー図を示す。 替わりのロボットウォーミングアップ運動手順についてのフロー図を示す。 トレースメッセージの例を示す。 容量性記憶モジュールの例を示す。 冗長接続を設ける典型的なネットワークトポロジを示す。 ネットワーク障害補償スキームの異なる態様を示す。 ネットワーク障害補償スキームの異なる態様を示す。 ネットワーク障害補償スキームの異なる態様を示す。 ネットワーク障害補償スキームの異なる態様を示す。 リピータ遅延を判断して用いる方法を示す。 追加のタイムオフセットフィールドを有する典型的なＰＶＴフレームを示す。 追加のタイムオフセットフィールドを有する典型的なＰＶＴ−ＦＧフレームを示す。 典型的ネットワーク自己識別スキームを示す。 複数ゾーンを有する制御システムの典型的なアプリケーションを示す。 電力制御回路のブロック図を示す。 容量性記憶モジュールに接続された電力制御回路の別の例を示す。 アプリケーションプログラムインタフェースのブロック図を示す。

Claims (5)

1. マスタコントローラを有するクラスタ化アーキテクチャと、
   前記マスタコントローラの直接制御下にあって１つ以上の第１運動軸を駆動するために利用される１つ以上の第１リモートコントローラを含む中央制御部と、
   前記マスタコントローラによって制御されているクラスタコントローラと、前記クラスタコントローラに制御されていて１つ以上の第２運動軸を駆動するために利用される１つ以上の第２リモートコントローラと、を含む分散制御部と、
   を含み、
   制御ループ及びフィードバックループは前記マスタコントローラと前記１つ以上の第１リモートコントローラとの間で閉じられており、
   制御ループ及びフィードバックループは前記クラスタコントローラと前記１つ以上の第２リモートコントローラとの間で閉じられており、
   前記マスタコントローラ、前記第１リモートコントローラ、及び前記第２リモートコントローラの内の少なくとも１つはプロセッサを含み、
   前記プロセッサは、
   前記１つ以上の第１又は第２運動軸のエンドエフェクタに対する最大許容オペレーティングパラメータ値を計算し、
   前記エンドエフェクタに対する第２動作プロファイルにおいて前記エンドエフェクタが前記最大許容オペレーティングパラメータ値を超えないように、前記１つ以上の第１及び第２運動軸の個別の結合部に対する１つ以上の第１動作プロファイルを生成する、
   ように構成されている、ことを特徴とする制御システム。
2. １つ以上の軸に対する軌道を前記軌道上の複数のポイントの各々のポイントに対する位置、速度及び加速に関して生成し、前記軸の逆ダイナミクスモデルを算出して各々の軸に対する前記軌道上の各々のポイントに対する利得値及びフィードフォワードタームを決定する回路を更に含む請求項１記載のシステム。
3. マスタコントローラと、前記マスタコントローラによって制御されている少なくとも１つのクラスタコントローラと、複数のリモートコントローラとを有する制御システムを動作させる方法であって、
   前記方法は、
   前記マスタコントローラと１つ以上の第１リモートコントローラとの間で閉じられている制御ループ及びフィードバックループを利用して前記マスタコントローラの直接制御下にある１つ以上の第１運動軸を駆動するステップと、
   前記クラスタコントローラと１つ以上の第２リモートコントローラとの間で閉じられている制御ループ及びフィードバックループを利用して前記クラスタコントローラによって制御されている１つ以上の第２運動軸を駆動するステップと、
   前記１つ以上の第１及び第２運動軸のエンドエフェクタに対する最大許容オペレーティングパラメータ値を計算するステップと、
   前記エンドエフェクタに対する第２動作プロファイルにおいて前記エンドエフェクタが前記最大許容オペレーティングパラメータ値を超えないように、前記１つ以上の第１及び第２運動軸の個別の結合部に対する１つ以上の第１動作プロファイルを生成するステップと、
   を含むことを特徴とする方法。
4. １つ以上の軸に対する軌道を前記軌道上の複数のポイントの各々のポイントに対する位置、速度及び加速に関して生成するステップと、
   前記軸の逆ダイナミクスモデルを算出して各々の軸に対する前記軌道上の各々のポイントに対する利得値及びフィードフォワードタームを決定するステップと、
   各々のポイントに対する前記位置、速度、加速、利得値、及びフィードフォワードタームをフレームへグループ化するステップと、
   を含むことを特徴とする請求項３記載の方法。
5. ２つの連続的なフレームの間で補間して、前記軸を制御するために利用される瞬間位置、瞬間速度、瞬間フィードフォワードターム、及び瞬間利得値を得るステップを含むことを特徴とする請求項４記載の方法。

Images