JP2004001148A - Interface for robot device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To stipulate interface specifications between a system layer and an application layer required for developing software for an entertainment robot. <P>SOLUTION: The software is divided into parts (modularized) based on an object orientation, a plurality of objects having various functions are made to perform parallel operations, and the software is realized in a form that a processing is proceeded, while the objects mutually perform communication (inter-object communication). At this time, connection relations among the objects are described in a file controlled by a system. At the time of a starting, a communication path is secured and set in the system. A connection port for the inter-object communication is discriminated by a service name. As a result, independence as parts (modules) becomes high to be easily replaced. <P>COPYRIGHT: (C)2004,JPO

Description

【００２２】
コアクラスのメンバー関数は、特定のメソッドと対応するものがあります。メソッドには以下のものがあります。
（１）起動時またはシャットダウン時に呼ばれるメソッド
Ｉｎｉｔメソッド：起動時に呼ばれます。インスタンスや変数の初期化を行います。
Ｓｔａｒｔメソッド：起動時にＤｏＩｎｉｔ（）がすべてのオブジェクトで実行された後で呼ばれます。
Ｓｔｏｐメソッド：シャットダウン時に呼ばれます。
Ｄｅｓｔｒｏｙメソッド：シャットダウン時にＤｏＳｔｏｐ（）がすべてのオブジェクトで実行された後で呼ばれます。サブジェクトとオブザーバのインスタンスを消滅します。
Ｉｎｉｔメソッド、Ｓｔａｒｔメソッド、Ｓｔｏｐメソッド、Ｄｅｓｔｒｏｙメソッドは、それぞれコアクラスのＤｏＩｎｉｔ（），　ＤｏＳｔａｒｔ（），　ＤｏＳｔｏｐ（），　ＤｏＤｅｓｔｒｏｙ（）に対応付けられます。
（２）他のオブジェクトからメッセージを受信するときに使用されるメソッド・サブジェクトに使用されるメソッド
Ｃｏｎｔｒｏｌメソッド：サブジェクトと、他のオブジェクトのオブザーバの接続結果を受信します。
Ｒｅａｄｙメソッド：サブジェクトが、他のオブジェクトのオブザーバからＡＳＳＥＲＴ−ＲＥＡＤＹまたはＤＥＡＳＳＥＲＴ−ＲＥＡＤＹを受信します。
・オブザーバに使用されるメソッド
Ｃｏｎｎｅｃｔメソッド：オブザーバと、他のオブジェクトのサブジェクトの接続結果を受信します。
Ｎｏｔｉｆｙメソッド：オブザーバが、他のオブジェクトのサブジェクトからデータを受信します。
【００２３】
これらのメソッドには、以下の特徴があります。
（ａ）Ｃｏｎｔｒｏｌメソッド、Ｒｅａｄｙメソッド、Ｃｏｎｎｅｃｔメソッド、Ｎｏｔｉｆｙメソッドに対応するメンバー関数はｓｔｕｂ．ｃｆｇに記述します。
（ｂ）メッセージを受信するメンバー関数はｓｔｕｂ．ｃｆｇに記述しますが、メッセージを送信するメンバー関数はｓｔｕｂ．ｃｆｇに記述する必要がありません。例として、コアクラスとしてＳａｍｐｌｅＣｌａｓｓ１を定義します、ＳａｍｐｌｅＣｌａｓｓ１はＯＯｂｊｅｃｔを継承し、ＯＰＥＮ−Ｒ用の４個のメンバー関数を定義します。以下は、ＳａｍｐｌｅＣｌａｓｓ１の定義です。

ＳａｍｐｌｅＣｌａｓｓ２が他のオブジェクトと通信する例です。ＯＳｕｂｊｅｃｔとＯＯｂｓｅｒｖｅｒを必要数だけ定義します。必要数は、ｓｔｕｂ．ｃｆｇに記述します。以下は、オブジェクト間通信を行う場合のＯＳｕｂｊｅｃｔとＯＯｂｓｅｒｖｅｒを使った定義例です。

【００２４】
２．３　スタブ
オブジェクトのエントリポイントとコアクラスのメンバー関数を接続するためにスタブが使用されます。スタブはｘｘｘＳｔｕｂ．ｃｃの中で定義されます。ｘｘｘＳｔｕｂ．ｃｃは、スタブジェネレータ（ｓｔｕｂｇｅｎ２コマンド）によってｓｔｕｂ．ｃｆｇから自動生成されます。また、ｘｘｘＳｔｕｂ．ｃｃの中では、大域変数としてコアクラスのインスタンスが１つだけ生成されます。
ｓｔｕｂ．ｃｆｇには以下の項目を記述します。
・サブジェクト数とオブザーバー数
・オブジェクト間通信で使用するサービス
サブジェクトとオブザーバはオブジェクト間通信用のサービスを提供をします。サービスは、他のサービスと区別できる固有のサービス名を持ちます。あるオブジェクトのサブジェクトのサービスと、他のオブジェクトのオブザーバのサービスを接続するには、互いのサービス名をＣＯＮＮＥＣＴ．ＣＦＧに記述します。
【００２５】
以下にｓｔｕｂ．ｃｆｇの記述例を挙げます。
ＯｂｊｅｃｔＮａｍｅ：　ＳａｍｐｌｅＣｌａｓｓ
ＮｕｍＯｆＯＳｕｂｊｅｃｔ　　　：　１
ＮｕｍＯｆＯＯｂｓｅｒｖｅｒ　　：　２
Ｓｅｒｖｉｃｅ　：　’ＳａｍｐｌｅＣｌａｓｓ．Ｆｕｎｃ１．Ｄａｔａ１．Ｓ’，　Ｃｏｎｔｒｏｌ（），　Ｒｅａｄｙ（）
Ｓｅｒｖｉｃｅ　：　’ＳａｍｐｌｅＣｌａｓｓ．Ｆｕｎｃ２．Ｄａｔａ２．Ｏ’，　Ｃｏｎｎｅｃｔ（），　Ｎｏｔｉｆｙ１（）
Ｓｅｒｖｉｃｅ　：　’ＳａｍｐｌｅＣｌａｓｓ．Ｆｕｎｃ３．Ｄａｔａ２．Ｏ’，　ｎｕｌｌ，　Ｎｏｔｉｆｙ２（）
Ｅｘｔｒａ　：　ＵｐｄａｔｅＰｏｗｅｒＳｔａｔｕｓ（）
各項目は、以下のような意味を持ちます。
ＯｂｊｅｃｔＮａｍｅ
コアクラス名です。
ＮｕｍＯｆＯＳｕｂｊｅｃｔ
サブジェクト数です。１以上の数を指定します。サブジェクトを必要としないときは、１個のダミーサブジェクトを登録します。
ＮｕｍＯｆＯＯｂｓｅｒｖｅｒ
オブザーバ数です。１以上の数を指定します。オブザーバを必要としないときは１個のダミーオブザーバを登録します。
Ｓｅｒｖｉｃｅ
オブジェクト用の通信サービスを記述します。各サブジェクトおよびオブザーバにつき、１つのサービスを記述します。
以下はサービスの構成項目です。’（接続名）’，　（メンバー関数１），　（メンバー関数２）
・接続名
接続名は、オブジェクト名、サブ名、データ名、サービス型から構成されている。各接続名は、以下の通りである。
オブジェクト名：任意の名前を指定できますが、通常はコアクラスの名前です。
サブ名：サービスの名前で、固有の名前を使用します。複数のサービスに同じ名前を付けてはいけません。
データ名：オブジェクト間通信で使用するデータ型に対応する名前です。
サービス型：Ｓ（サブジェクト）またはＯ（オブザーバ）の一方を指定します。
【００２６】
また、メンバー関数は以下である。
・メンバー関数１
接続の結果を受信する時に呼ばれるメンバー関数です。メンバー関数１の名前は自由に命名することができます。メンバー関数１は、コアクラス内で実装されます。メンバー関数１が不要のときはｎｕｌｌを記述してください。
・メンバー関数２
オブザーバ用のサービスの場合に、サブジェクトからメッセージを受信したときに呼ばれるメンバー関数です。または、サブジェクト用のサービスの場合に、オブザーバからＡＳＳＥＲＴ−ＲＥＡＤＹまたはＤＥＡＳＳＥＲＴ−ＲＥＡＤＹを受信したときに呼ばれるメンバー関数です。メンバー関数２の名前は、自由に命名することができます。メンバー関数２は、コアクラス内で実装されます。メンバー関数２が不要のときはｎｕｌｌを記述してください。
【００２７】
以下は、ダミーサブジェクトが存在する場合のサンプルコードです。
Ｓｅｒｖｉｃｅ　：　’ＳａｍｐｌｅＣｌａｓｓ．ＤｕｍｍｙＳｕｂｊｅｃｔ．ＤｏｎｔＣｏｎｎｅｃｔ．Ｓ’，　ｎｕｌｌ，　ｎｕｌｌ
複数のサービスが存在する場合は、同じメンバー関数を共有することもできます。以下はサンプルコードです。
Ｓｅｒｖｉｃｅ　：　’ＳａｍｐｌｅＣｌａｓｓ．Ｏｕｔ１．Ｄａｔａ１．Ｓ’，　Ｃｏｎｔｒｏｌ（），　Ｒｅａｄｙ（）
Ｓｅｒｖｉｃｅ　：　’ＳａｍｐｌｅＣｌａｓｓ．Ｏｕｔ２．Ｄａｔａ１．Ｓ’，　Ｃｏｎｔｒｏｌ（），　Ｒｅａｄｙ（）
Ｃｏｎｔｒｏｌ（）　と　Ｒｅａｄｙ（）　は２個のサービスに共通のメンバー関数です。
【００２８】
Ｅｘｔｒａ　ｅｎｔｒｙ
Ｉｎｉｔ，　Ｓｔａｒｔ，　Ｓｔｏｐ，　Ｄｅｓｔｒｏｙ，　Ｃｏｎｔｒｏｌ，　Ｒｅａｄｙ，　Ｃｏｎｎｅｃｔ，　Ｎｏｔｉｆｙメソッド以外のエントリポイントを必要とする場合は、Ｅｘｔｒａ　ｅｎｔｒｙにエントリポイントを追加します。以下はサンプルコードです。例えばネットワーク通信時に使用するコールバック関数がこれにあたります。
Ｅｘｔｒａ　：　ＮｅｗＥｘｔｒａ１（）
Ｅｘｔｒａ　：　ＮｅｗＥｘｔｒａ２（）
ｓｔｕｂ．ｃｆｇの記述例をもとに、Ｆｉｇ１−４を用いてオブジェクトＡのサブジェクトａと、オブジェクトＢのオブザーバｂの間でのメッセージの送受信について説明します。
【００２９】
以下はオブジェクトＡのｓｔｕｂ．ｃｆｇです。
ＯｂｊｅｃｔＮａｍｅ　：　ＯｂｊｅｃｔＡ
ＮｕｍＯｆＯＳｕｂｊｅｃｔ　　　：　１
ＮｕｍＯｆＯＯｂｓｅｒｖｅｒ　　：　１
Ｓｅｒｖｉｃｅ　：　’ＯｂｊｅｃｔＡ．ＳｅｎｄＳｔｒｉｎｇ．ｃｈａｒ．Ｓ’，　ｎｕｌｌ，　ｓｕｂｊｅｃｔ＿ａ（）
Ｓｅｒｖｉｃｅ　：　’ＯｂｊｅｃｔＡ．ＤｕｍｍｙＯｂｓｅｒｖｅｒ．ＤｏｎｔＣｏｎｎｅｃｔ．Ｏ’，　ｎｕｌｌ，　ｎｕｌｌ
以下はオブジェクトＢのｓｔｕｂ．ｃｆｇです。
ＯｂｊｅｃｔＮａｍｅ　：　ＯｂｊｅｃｔＢ
ＮｕｍＯｆＯＳｕｂｊｅｃｔ　　　：　１
ＮｕｍＯｆＯＯｂｓｅｒｖｅｒ　　：　１
Ｓｅｒｖｉｃｅ　：　’ＯｂｊｅｃｔＢ．ＤｕｍｍｙＳｕｂｊｅｃｔ．ＤｏｎｔＣｏｎｎｅｃｔ．Ｓ’，　ｎｕｌｌ，　ｎｕｌｌ
Ｓｅｒｖｉｃｅ　：　’ＯｂｊｅｃｔＢ．ＲｅｃｅｉｖｅＳｔｒｉｎｇ．ｃｈａｒ．Ｏ’，　ｎｕｌｌ，　ｏｂｓｅｒｖｅｒ＿ｂ（）
サブジェクトａとオブザーバｂのサービスの接続がＣＯＮＮＥＣＴ．ＣＦＧで以下のように記述されているとします。
ＯｂｊｅｃｔＡ．ＳｅｎｄＳｔｒｉｎｇ．ｃｈａｒ．Ｓ　　　　　ＯｂｊｅｃｔＢ．ＲｅｃｅｉｖｅＳｔｒｉｎｇ．ｃｈａｒ．Ｏ
このとき、メッセージの送受信の手順は以下になります。
【００３０】
メッセージの送受信の手順を図４に記述します。
（１）オブジェクトＢのＤｏＳｔａｒｔ（）より、オブジェクトＡのサブジェクトへＡＳＳＥＲＴ−ＲＥＡＤＹを送信します。この通知はオブジェクトＡのコアクラスのｓｕｂｊｅｃｔ＿ａ（）に届きます。
（２）ｓｕｂｊｅｃｔ＿ａ（）はサブジェクトにメッセージを送信します。この通知はオブジェクトＢのコアクラスのｏｂｓｅｒｖｅｒ＿ｂ（）に届きます。
（３）オブザーバｂがサブジェクトＡから次のメッセージを送信してほしいときは、サブジェクトへＡＳＳＥＲＴ−ＲＥＡＤＹを送信します。
【００３１】
２．４　ＤｏＩｎｉｔ（），　ＤｏＳｔａｒｔ（），　ＤｏＳｔｏｐ（），　ＤｏＤｅｓｔｒｏｙ（）
コアクラスでＤｏＩｎｉｔ（）、ＤｏＳｔａｒｔ（）、ＤｏＳｔｏｐ（）、ＤｏＤｅｓｔｒｏｙ（）をオーバーライドして、各コアクラスに固有の処理を記述します。
ＤｏＩｎｉｔ（）
ＤｏＩｎｉｔ（）は起動時に呼ばれます。ＤｏＩｎｉｔ（）は通信サービスの登録を行います。以下は記述を簡略化するためのマクロです。
ＮＥＷ＿ＡＬＬ＿ＳＵＢＪＥＣＴ＿ＡＮＤ＿ＯＢＳＥＲＶＥＲ
サブジェクトとオブザーバを必要数だけ登録します。
ＲＥＧＩＳＴＥＲ＿ＡＬＬ＿ＥＮＴＲＹ
他のオブジェクトのサービスとの接続を登録します。
ＳＥＴ＿ＡＬＬ＿ＲＥＡＤＹ＿ＡＮＤ＿ＮＯＴＩＦＹ＿ＥＮＴＲＹ
メッセージを受信するエントリを設定します。
以下はマクロを使用したサンプルコードです。

【００３２】
ＤｏＳｔａｒｔ（）
ＤｏＩｎｉｔ（）がすべてのオブジェクトで実行された後で呼ばれます。通常、各オブザーバは接続先のサブジェクトへＡＳＳＥＲＴ−ＲＥＡＤＹを送信します。ＤｏＳｔａｒｔ（）はＤｏＩｎｉｔ（）の後に１回だけ呼ばれます。特定のオブザーバへＡＳＳＥＲＴ−ＲＥＡＤＹを送信するタイミングを遅らせたいときは、ＤｏＳｔａｒｔ（）の代わりに、別のメンバー関数の中でサブジェクトへ送信することができます。以下は記述を簡略化するためのマクロです。
ＥＮＡＢＬＥ＿ＡＬＬ＿ＳＵＢＪＥＣＴ
コアクラスが持つサブジェクトを有効にします。
ＡＳＳＥＲＴ＿ＲＥＡＤＹ＿ＴＯ＿ＡＬＬ＿ＯＢＳＥＲＶＥＲ
接続されているすべてのサブジェクトにＡＳＳＥＲＴ＿ＲＥＡＤＹを送信します。
以下はマクロを使用したサンプルコードです。

【００３３】
ＤｏＳｔｏｐ（）
シャットダウン時に呼ばれます。各オブザーバは通常、接続先のサブジェクトにＤＥＡＳＳＥＲＴ−ＲＥＡＤＹを送信します。以下は記述を簡略化するためのマクロです。
ＤＩＳＡＢＬＥ＿ＡＬＬ＿ＳＵＢＪＥＣＴ
コアクラスが持つサブジェクトを無効にします。
ＤＥＡＳＳＥＲＴ＿ＲＥＡＤＹ＿ＴＯ＿ＡＬＬ＿ＯＢＳＥＲＶＥＲ
接続されているすべてのサブジェクトにＤＥＡＳＳＥＲＴ＿ＲＥＡＤＹを送信します。
以下はマクロを使用したサンプルコードです。

【００３４】
ＤｏＤｅｓｔｒｏｙ（）
シャットダウン時に、全てのオブジェクトに対するＤｏＳｔｏｐ（）の呼び出しの後に呼ばれます。以下は記述を簡略化するためのマクロです。
ＤＥＬＥＴＥ＿ＡＬＬ＿ＳＵＢＪＥＣＴ＿ＡＮＤ＿ＯＢＳＥＲＶＥＲ
すべてのサブジェクトとオブザーバを消去します。
以下はマクロを使用したサンプルコードです。

【００３５】
２．５　データの送受信
オブザーバがデータを受信できるときは、サブジェクトへＡＳＳＥＲＴ−ＲＥＡＤＹのメッセージを送信します。

オブザーバーからＡＳＳＥＲＴ−ＲＥＡＤＹのメッセージを受信すると、サブジェクトはオブザーバへデータを送信します。

オブザーバは、サブジェクトからデータを受信した後に再びデータを受信できるときは、サブジェクトへＡＳＳＥＲＴ−ＲＥＡＤＹを送信します。

ここでｏｂｊＦｕｎｃ１やｓｂｊＦｕｎｃ２はオブザーバやサブジェクトを特定するためのＩＤで、ｓｔｕｂｇｅｎ２コマンドを実行してｓｔｕｂ．ｃｆｇから自動生成されるｄｅｆ．ｈで定義されます。
【００３６】
第３章　ビルド
図５はオブジェクトをビルドし、実行ファイルを作成する手順を示す図です。
３．１　．ｏｃｆ
．ｏｃｆの拡張子を持つファイルは、オブジェクトの設定を記述するために使用します。以下は．ｏｃｆファイルのフォーマットです。
ｏｂｊｅｃｔ　ＯＢＪＥＣＴ＿ＮＡＭＥ　ＳＴＡＣＫ＿ＳＩＺＥ　ＨＥＡＰ＿ＳＩＺＥ　ＳＣＨＥＤ＿ＰＲＩＯＲＩＴＹ　ＣＡＣＨＥ　ＴＬＢ　ＭＯＤＥ
以下は．ｏｃｆのサンプルコードです。
ｏｂｊｅｃｔ　ｈｅｌｌｏＷｏｒｌｄ　３０７２　１６３８４　１２８　ｃａｃｈｅ　ｔｌｂ　ｕｓｅｒ
以下は．ｏｃｆのパラメーターです。
ＯＢＪＥＣＴ＿ＮＡＭＥ
オブジェクトの名前です。
ＳＴＡＣＫ＿ＳＩＺＥ
スタックのサイズ（単位はバイト）です。スタックは実行時には拡張されません。オブジェクトが指定したサイズ以上のスタックを使用した場合（例えば、多くのａｕｔｏ変数を宣言した場合や、深くネストされた関数呼び出しを行った場合）の結果は不定です。
【００３７】
ＨＥＡＰ＿ＳＩＺＥ
オブジェクトがヒープ領域を使い切ったときに、ヒープがここで指定したサイズ（単位はバイト）だけ拡張されます。ヒープはｍａｌｌｏｃ（）やｎｅｗ演算子で要求されるメモリーを確保するための領域です。ＨＥＡＰ＿ＳＩＺＥの指定が小さいと、オブジェクトはヒープの拡張を頻繁に行うようになり、実行速度の低下につながります。
【００３８】
ＳＣＨＥＤ＿ＰＲＩＯＲＩＴＹ
オブジェクトのスケジューリング優先度を８ビットの符号無し正数によって指定します。上位４ビットがスケジューリングクラスを表します。スケジューリングクラスの低いオブジェクトは、スケジューリングクラスの高いオブジェクトの実行中には実行されません。通常のアプリケーションのスケジューリングクラスの推奨値は１２８以下です。下位４ビットは同じスケジューリングクラスのオブジェクト間での実行率を制御します。この値が高いほど、オブジェクトはより多くの実行時間を確保できます。
【００３９】
ＣＡＣＨＥ
ｃａｃｈｅまたはｎｏｃａｃｈｅを指定します。ｎｏｃａｃｈｅを指定したときは、オブジェクトの実行中にプロセッサーのキャッシュメモリーが無効になります。通常はｃａｃｈｅを指定してください。
【００４０】
ＴＬＢ
ｔｌｂまたはｎｏｔｌｂを指定します。ｔｌｂの指定を推奨します。ＭＯＤＥにｕｓｅｒを指定したときはｔｌｂを指定します。ｔｌｂを指定したときは、オブジェクト用のメモリー領域が仮想アドレス空間に確保されます。ｎｏｔｌｂを指定したときは、オブジェクト用のメモリー領域が物理アドレス空間（ＫＳＥＧ０または１）に確保されます。この値は後述するｎｏｍｅｍｐｒｏｔのコンフィグレーションが使用されたときは無視されます。
【００４１】
ＭＯＤＥ
ｋｅｒｎｅｌまたはｕｓｅｒを指定します。ｕｓｅｒを指定したときは、オブジェクトの実行時にプロセッサーの実行モードがユーザーモードに設定されます。ｋｅｒｎｅｌを指定したときは、カーネルモードでオブジェクトが実行されます。この値はｎｏｍｅｍｐｒｏｔのコンフィグレーションが使用されたときは無視され、オブジェクトは常にカーネルモードで実行されます。
【００４２】
３．２　スタブジェネレータ
ｓｔｕｎｇｅｎ２コマンドによって、オブジェクトのメソッドとコアクラスのメンバー関数を接続するための中間ファイルが、ｓｔｕｂ．ｃｆｇから生成されます。中間ファイルの中にｄｅｆ．ｈがあります。以下はｄｅｆ．ｈのサンプルコードです。
ｃｏｎｓｔ　ｉｎｔ　ｓｂｊＦｕｎｃ１　＝　０；
ｃｏｎｓｔ　ｉｎｔ　ｏｂｓＦｕｎｃ２　＝　０；
ｓｂｊやｏｂｓはｓｔｕｂ．ｃｆｇに記述されるサブ名の先頭に追加されます。
以下はＳａｍｐｌｅＣｌａｓｓ．ｈでの定義です。
ＯＳｕｂｊｅｃｔ＊　　　　　　ｓｕｂｊｅｃｔ［ｎｕｍＯｆＳｕｂｊｅｃｔ］；
ＯＯｂｓｅｒｖｅｒ＊　　　ｏｂｓｅｒｖｅｒ［ｎｕｍＯｆＯｂｓｅｒｖｅｒ］；
ｓｂｊＦｕｎｃ１とｏｂｓＦｕｎｃ２はサブジェクトとオブザーバを指定するためのＩＤの記述です（例　：ｓｕｂｊｅｃｔ［ｓｂｊＦｕｎｃ１］　　ｏｂｓｅｒｖｅｒ［ｏｂｓＦｕｎｃ２］）。
【００４３】
３．３　コンパイルとアセンブル
以下のコマンドを使用してコンパイルもしくはアセンブルを行います。コマンドは、Ｃ＋＋ソースファイル（．ｃｃ）とアセンブリ言語ソースファイル（．ｓ）で共通です。
／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫ／ｂｉｎ／ｍｉｐｓｅｌ−ｌｉｎｕｘ−ｇｃｃ　−ｃ　［ｏｔｈｅｒ　ｏｐｔｉｏｎｓ］　ＦＩＬＥ
これはオブジェクトファイルを作成します。オブジェクトファイルの名前は、ソースファイルの拡張子を．ｏに変えたものになります。−ｃオプションを必ず指定してください。−ｃなしの場合、ｇｃｃはリンクフェーズに進んで失敗します。ＯＰＥＮ−Ｒ　ＳＤＫでは、ｇｃｃコマンドを使ってリンクを行なうことはできません。代わりにｍｋｂｉｎコマンドを使用してください。他のオプションの詳細は、ｇｃｃのマニュアルを参照してください。必要に応じて−Ｉオプションを使用し、ヘッダーファイルの置かれているディレクトリーを指定してください。以下のオプションを使用すると、ＯＰＥＮ−Ｒヘッダーファイルを使用することができます。
−Ｉ／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫ／ＯＰＥＮ＿Ｒ／ｉｎｃｌｕｄｅ／Ｒ４０００
−Ｉ／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫ／ＯＰＥＮ＿Ｒ／ｉｎｃｌｕｄｅ
【００４４】
３．４　リンク
オブジェクトファイルのリンクには、以下のコマンドを使用してください。
／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫ／ＯＰＥＮ＿Ｒ／ｂｉｎ／ｍｋｂｉｎ　−ｏ　ＸＸＸ．ｂｉｎ　ＸＸＸ．ｏｃｆ
［ｏｔｈｅｒ　ｏｐｔｉｏｎｓ］　ＡＡＡ．ｏ　ＢＢＢ．ｏ　ＣＣＣ．ｏ
これはオブジェクトファイルＡＡＡ．ｏ，　ＢＢＢ．ｏ，　ＣＣＣ．ｏ　．．．をリンクし、実行ファイルＸＸＸ．ｂｉｎを作成します。拡張子．ｏｃｆを持つファイルは、オブジェクトの設定を記述するためのファイルです。ｍｋｂｉｎの他のオプションは、下記のリスト挙げたものを除いて、ｍｋｂｉｎが内部的に呼び出すリンカーに渡されます。リンカーに渡すことのできるオプションについては、ＧＮＵ　ｌｄのマニュアルを参照してください。コマンドラインで指定したオプションに加えて、ｍｋｂｉｎは、デフォルトのライブラリをリンクするためのオプションをリンカーに渡します。−ｖフラグを指定してｍｋｂｉｎを実行することにより、リンカーに渡されるオプションを確認することができます。ｍｋｂｉｎはいくつかの中間ファイルを作成しますが、それらは自動的には削除されません。中間ファイルの名前は、作成する実行ファイルの名前をもとに、以下のようにして決められます。
１．　拡張子が．ｂｉｎの場合、それを取り除く。
２．　次に、以下の文字列の１つを末尾に追加する。
．ｓｎａｐ．ｃｃ，　．ｓｎａｐ．ｏ，　．ｎｏｓｎａｐ．ｅｌｆ，　．ｓｎａｐ．ｅｌｆ，　．ｒｅｌ．ｅｌｆ
以下はｍｋｂｉｎで処理されるオプションのリストです。
−ｏ　ＰＡＴＨ
作成する実行ファイルのパスを指定します。デフォルト値はａ．ｂｉｎです。
−ｍ　ＰＡＴＨ
．ｏｃｆのパスを指定します。ＰＡＴＨが．ｏｃｆで終わる場合。　−ｍは省略できます。
−ｐ　ＰＡＴＨ
ＯＰＥＮ−　Ｒ　ＳＤＫがインストールされたディレクトリーを指定します。デフォルト値は／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫです。
−−ｎｏｄｅｆａｕｌｔｌｉｂ
デフォルトライブラリーのリンクを禁止します。
−−ｎｏｃｒｔ
起動定型処理のリンクを禁止します。このオプションを指定しないときは、以下のファイルが自動的にリンクされます。
ｃｒｔｂｅｇｉｎ．ｏ
ｃｒｔｅｎｄ．ｏ
−−ｎｏｖｍ
作成する実行ファイルはｎｏｍｅｍｐｒｏｔのコンフィギュレーションで使用することを指定します。その効果は、．ｏｃｆファイルでＴＬＢに対してｎｏｔｌｂを、ＭＯＤＥに対してｋｅｒｎｅｌを指定したのと同じです。
−ｖ
冗長なメッセージを出力します。
【００４５】
第４章　実行
４．１　ＯＰＥＮ−Ｒコンフィグレーションの選択
ＯＰＥＮ−Ｒコンフィグレーションには下記の種類があります。／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫ／ＯＰＥＮ＿Ｒ／ＭＳ／ディレクトリーに、各コンフィギュレーションに対応したＯＰＥＮ−Ｒディレクトリーが置かれています。ロボットでオブジェクトを実行させるためには、ＯＰＥＮ−Ｒディレクトリーの１つとユーザが作ったオブジェクトを合わせて、ＡＩＢＯプログラミングメモリースティックにコピーして使用します。
ＢＡＳＩＣ／ｍｅｍｐｒｏｔ／ＯＰＥＮ−Ｒ／
ＢＡＳＩＣ／ｎｏｍｅｍｐｒｏｔ／ＯＰＥＮ−Ｒ／
ＷＬＡＮ／ｍｅｍｐｒｏｔ／ＯＰＥＮ−Ｒ／
ＷＬＡＮ／ｎｏｍｅｍｐｒｏｔ／ＯＰＥＮ−Ｒ／
ＷＣＯＮＳＯＬＥ／ｍｅｍｐｒｏｔ／ＯＰＥＮ−Ｒ／
ＷＣＯＮＳＯＬＥ／ｎｏｍｅｍｐｒｏｔ／ＯＰＥＮ−Ｒ／
【００４６】
４．１．１　ＢＡＳＩＣ／ＷＬＡＮ／ＷＣＯＮＳＯＬＥの違い
以下の中から目的に応じて選択します。
ＢＡＳＩＣ
無線ＬＡＮ環境を使用しないとき
ＷＬＡＮ
無線ＬＡＮ環境を使用して、無線コンソールを使用しないとき
ＷＣＯＮＳＯＬＥ
無線ＬＡＮ環境と無線コンソールを使用するとき
【００４７】
４．１．２　ｍｅｍｐｒｏｔ　／　ｎｏｍｅｍｐｒｏｔ
以下の中から目的に応じて選択します。
ｍｅｍｐｒｏｔは、メモリー保護を有効にします。オブジェクトをｕｓｅｒ／ｔｌｂモードで動作させることができます。ｕｓｅｒ／ｔｌｂモードについては「３．１　．ｏｃｆ」を参照してください。ｕｓｅｒ／ｔｌｂモードのオブジェクトが使用するメモリーは、ＴＬＢ（ｔｒａｎｓｌａｔｉｏｎ　ｌｏｏｋａｓｉｄｅ　ｂｕｆｆｅｒ）を使用する仮想アドレス空間に配置されます。以下の長所と短所があります。
長所：ｕｓｅｒモードで実行されるオブジェクトは他のオブジェクトのメモリー空間にアクセスできません。そのため、誤った値のポインターの使用によるバグを見つけやすくなります。仮想アドレス空間では、物理的に連続していない複数のメモリー領域を、連続したメモリー領域として使用することができます。そのため、メモリーの利用効率が向上します。
短所：共有メモリの確保の単位が４０９６バイト単位になります。従って、小さな共有メモリを大量に確保した場合、メモリの利用効率が悪くなります。以下の点で、プログラムの実行速度に多少のオーバヘッドがかかります。（ａ）ＴＬＢミス発生時の、仮想アドレスから物理アドレスへの変換、（ｂ）共有メモリの確保、解放、他オブジェクトへのアタッチ
ｎｏｍｅｍｐｒｏｔは、メモリー保護を無効にします。すべてのオブジェクトはｋｅｒｎｅｌ／ｎｏｔｌｂモードで動作します。ｍｅｍｐｒｏｔとの反対の長所、短所を持ちます。ｎｏｍｅｍｐｒｏｔ環境下では、共有メモリを使用せずに、あるオブジェクトから他のオブジェクトのメモリ領域にアクセスできます。しかし、ｎｏｍｅｍｐｒｏｔ環境でも共有メモリ用のＡＰＩを使用することで、ソースコードをｍｅｍｐｒｏｔ　環境と共通にすることができます。ｎｏｍｅｍｐｒｏｔ環境下では、共有メモリ用のＡＰＩはほとんど何もしないダミー関数として実装されていて、高速に動作します。
【００４８】
４．２　設定ファイル
ＡＩＢＯ上でオブジェクトを実行するためには、複数の設定ファイルを編集します。以下にＯＢＪＥＣＴ．ＣＦＧ、ＣＯＮＮＥＣＴ．ＣＦＧ、ＤＥＳＩＧＮＤＢ．ＣＦＧの記述方法を示します。これらのファイルはＡＩＢＯプログラミングメモリースティックの　／ＯＰＥＮ−Ｒ／ＭＷ／ＣＯＮＦ　ディレクトリーに置かれます。
【００４９】
４．２．１　ＯＢＪＥＣＴ．ＣＦＧ
実行したいオブジェクトに対応する実行ファイル名を列挙します。
／ＭＳ／ＯＰＥＮ−Ｒ／ＭＷ／ＯＢＪＳ／ＸＸＸ．ＢＩＮ
／ＭＳ／ＯＰＥＮ−Ｒ／ＭＷ／ＯＢＪＳ／ＹＹＹ．ＢＩＮ
／ＭＳ／は、ＡＩＢＯプログラミングメモリースティックのルートディレクトリーを表します。
【００５０】
４．２．２　ＣＯＮＮＥＣＴ．ＣＦＧ
サブジェクトとオブザーバの接続を記述します。
Ｃｌａｓｓ１．Ｆｕｎｃ１．Ｄａｔａ１．Ｓ　Ｃｌａｓｓ２．Ｆｕｎｃ２．Ｄａｔａ１．Ｏ
Ｃｌａｓｓ１．Ｆｕｎｃ３．Ｄａｔａ２．Ｓ　Ｃｌａｓｓ３．Ｆｕｎｃ４．Ｄａｔａ２．Ｏ
各行は以下の様に記述します。
’サブジェクトサービス（．Ｓ）’，’スペース’，’オブザーバサービス（．Ｏ）’
サブジェクトサービスとオブザーバサービスのデータ名は同一でなければなりません。
【００５１】
４．２．３　ＤＥＳＩＧＮＤＢ．ＣＦＧ
ロボットの機種によってプログラムの中で参照するファイルを切り替えることができます。ファイルを探すためのキーワードを記述します。
＃
＃　ＤＥＳＩＧＮＤＢ．ＣＦＧ
＃
［ＥＲＳ−２１０］
ＫＥＹＷＯＲＤ１　　　／ＭＳ／ＯＰＥＮ−Ｒ／ＭＷ／ＣＯＮＦ／ＥＲＳ−２１０．ＴＸＴ
ＫＥＹＷＯＲＤ２　　　／ＭＳ／ＯＰＥＮ−Ｒ／ＭＷ／ＤＡＴＡ／Ｐ／２１０．ＷＡＶ
［ＥＲＳ−２２０］
ＫＥＹＷＯＲＤ１　　　／ＭＳ／ＯＰＥＮ−Ｒ／ＭＷ／ＣＯＮＦ／ＥＲＳ−２２０．ＴＸＴ
ＫＥＹＷＯＲＤ２　　　／ＭＳ／ＯＰＥＮ−Ｒ／ＭＷ／ＤＡＴＡ／Ｐ／２２０．ＷＡＶ
／ＭＳ／は、ＡＩＢＯプログラミングメモリースティックのルートディレクトリーを表します。
ＫＥＹＷＯＲＤ１　はファイルの識別用のタグです。ＫＥＹＷＯＲＤ１　はＯＰＥＮ−Ｒ　ＡＰＩを使用してデータファイルを読み込むときに使用します。
ＯＰＥＮＲ：：ＦｉｎｄＤｅｓｉｇｎＤａｔａ（’ＫＥＹＷＯＲＤ１’，
（ＯＤｅｓｉｇｎＤａｔａＩＤ＊）＆ｍｅｍＩＤ，　＆ａｄｄｒ，　＆ｓｉｚｅ）；
【００５２】
４．３　ＡＩＢＯ上での実行
４．３．１　ＡＩＢＯプログラミングメモリースティックの作成
最初にＯＰＥＮ−ＲディレクトリーをＡＩＢＯプログラミングメモリースティックのルートディレクトリーにコピーします。次に実行ファイル（ｘｘｘ．ｂｉｎ）をＡＩＢＯプログラミングメモリースティックにコピーします。実行ファイルは以下のディレクトリーにコピーします。
／ＯＰＥＮ−Ｒ／ＭＷ／ＯＢＪＳ／
ＬＥＤ、モーション、サウンドのコンテンツデータは、ＡＩＢＯプログラミングメモリースティックの以下のディレクトリにコピーします。
／ＯＰＥＮ−Ｒ／ＭＷ／ＤＡＴＡ／Ｐ／
図６にＯＰＥＮ−Ｒのディレクトリ構成を示します。
【００５３】
４．３．１　ＡＩＢＯプログラミングメモリースティックの実行
ＯＰＥＮ−Ｒディレクトリーと設定ファイルを置いたＡＩＢＯプログラミングメモリースティックをＡＩＢＯに挿入して、ポーズボタンを押します。
【００５４】
第５章　デバッグ
５．１　エラーログ出力
デバッグのために文字列を出力する際に、Ｃ／Ｃ＋＋のｐｒｉｎｔｆやｃｏｕｔを使うことも出来ますが、複数オブジェクトが並行動作するＯＰＥＮ−Ｒの環境では表示される文字列が混在して表示されます。この問題をさけるためにＯＳＹＳＰＲＩＮＴ、ＯＳＹＳＤＥＢＵＧ、ＯＳＹＳＬＯＧ１マクロの使用を推奨します。
ＯＳＹＳＰＲＩＮＴ（），　ＯＳＹＳＤＥＢＵＧ（）　は　ｐｒｉｎｔｆ（）　と同じ引数を指定できます。ＯＳＹＳＤＥＢＵＧ（）　は　ＯＰＥＮＲ＿ＤＥＢＵＧ　が定義されていないときには空文字列に展開されます。ＯＰＥＮＲ＿ＤＥＢＵＧ　は、以下に示すようにコンパイラフラグＤＯＰＥＮＲ＿ＤＥＢＵＧ　で定義します。
ＯＳＹＳＰＲＩＮＴ（（’ｔｅｓｔ：　％ｄ￥ｎ’，　ｘ，　ｙ））；
ＯＳＹＳＤＥＢＵＧ（（’Ｈｅｌｌｏ￥ｎ’））；
ＯＳＹＳＰＲＩＮＴとＯＳＹＳＤＥＢＵＧの表示文字列の最大長は、終端に付加されるヌル文字を含めて２４３文字です。
【００５５】
ＯＳＹＳＬＯＧ１は、エラー表示用のマクロです。第１引数にはエラーレベルを定義します。ＯＳＹＳＬＯＧ１では文字列の後ろに改行コードが自動的に付加されます。
ＯＳＹＳＬＯＧ１（（ｏｓｙｓｌｏｇＥＲＲＯＲ，　’Ｔｈｉｓ　ｉｓ　ｅｒｒｏｒ！’））；
ＯＳＹＳＬＯＧ１の結果は次のような文字列が表示されます。
［ｏｉｄ：８０００００４３，ｐｒｉｏ：１］　Ｔｈｉｓ　ｉｓ　ｅｒｒｏｒ！
「ｐｒｉｏ：」に続く数値は第１引数で指定したエラーレベルです。ＯＳＹＳＬＯＧ１の第１引数には以下のエラーレベルが指定できます。
ｐｒｉｏ　　　　　　　ｏｉｄ，ｐｒｉｏの表示　　　ｐｒｉｏ値
ｏｓｙｓｌｏｇＥＲＲＯＲ　　　　表示　　　　　　１
ｏｓｙｓｌｏｇＷＡＲＮＩＮＧ　　　表示　　　　　　２
ｏｓｙｓｌｏｇＩＮＦＯ　　　　　表示　　　　　　３
【００５６】
５．２　ＣＰＵ例外の調査
プログラムが誤まった動作（不正なアドレスの参照や不正な命令の実行など）　を行なうと、ＣＰＵ例外が発生し、プログラムの実行が強制終了する場合があります。強制終了時には、特定のブザー音が鳴り、ＣＰＵ例外の原因の解析に必要な情報がメモリースティックに書き込まれます。ここでは、その情報を元にＣＰＵ　例外の原因を解析する方法を説明します。ＡＩＢＯで使っているＣＰＵはＭＩＰＳプロセッサです。ＣＰＵ例外の原因の解析には、ＭＩＰＳ　アーキテクチャに関する知識が必要です。
【００５７】
５．２．１　解析に必要な基礎知識
・ＯＰＥＮ−Ｒの動作モード
ＣＰＵ　は　３２　ビットモード、リトルエンディアンで動作。
・システムが強制終了となるＣＰＵ例外
ＴＬＢ　例外
アドレスエラー例外
予約命令例外
浮動小数点演算例外
コプロセッサ使用不可例外
バスエラー例外
【００５８】
・コンパイラのレジスター使用方法
ＭＩＰＳ　　ＣＰＵの汎用レジスターは３２個あります。かっこの中の名前は　ｃｏｎｖｅｎｔｉｏｎａｌ　ｎａｍｅ　です。
ｒ０　（ｚｅｒｏ）
値が常に０のレジスターです。
【００５９】
ｒ２，　ｒ３　（ｖ０，　ｖ１）
サブルーチンの戻り値を保持するために使用します。ｖ１　は６４ｂｉｔ　の値を返す場合に使われます。
【００６０】
ｒ４−ｒ７　（ａ０−ａ３）
サブルーチン呼出し時の引数を保持するために使用します。引数が５以上の場合はスタックに積まれます。Ｃ＋＋　のメンバー関数呼出し時には　ａ０　が　ｔｈｉｓ　ポインタになります。
【００６１】
ｒ８−ｒ１５，　ｒ２４，　ｒ２５　（ｔ０−ｔ７，　ｔ８，　ｔ９）
サブルーチンの中で値を保存せずに使います。そのため別のサブルーチンを呼び出して戻ってきた時の値は保証されません。例えば　ｔ０　の値を１にセットし、別のサブルーチンを呼出して戻ってきた時に　　ｔ０　の値が　１　である保証はありません。
【００６２】
ｒ１６−ｒ２３，　ｒ３０　（ｓ０−ｓ７，　ｓ８）
サブルーチンの中で一時的に使いますが、使う前に値を保存します。そのため別のサブルーチンを呼び出して戻ってきた時の値が保証されます。例えば　ｓ０　の値を１にセットし、別のサブルーチンを呼出して戻ってきた時も　ｓ０　の値は　１です。
【００６３】
ｒ２８　（ｇｐ）
サブルーチンの先頭で、シンボル＿ｇｐの実行時のアドレスを指すようにセットします。他のシンボルの実行時のアドレスを決定する際に使用します。
【００６４】
ｒ２９　（ｓｐ）
スタックポインターです。スタックを使用するサブルーチンは、サブルーチンの先頭で使用するサイズ分、スタックポインターの値を減らし、サブルーチンから戻る前にスタックポインターを元の位置まで増やします。
３ｃ８：　　　　２７ｂｄｆｆｃ８　　　　　ａｄｄｉｕ　　ｓｐ，ｓｐ，−５６
４４０：　　　　０３ｅ００００８　　　　ｊｒ　　　　ｒａ
４４４：　　　　２７ｂｄ００３８　　　　ａｄｄｉｕ　　ｓｐ，ｓｐ，５６
【００６５】
ｒ３１　（ｒａ）
サブルーチンの戻りアドレスを保持するために使用します。リンクを伴うジャンプ命令（ｊａｌ，　ｊａｌｒ）を使ってサブルーチンを呼び出した場合、戻りアドレスはこの命令の２つ先です。そしてサブルーチンの最後の命令は概して　ｊａ　ｒａ　です。サブルーチンの中で別のサブルーチンを呼び出す場合は、　ｒａ　をスタックに保存します。
【００６６】
システム制御コプロセッサーのレジスタの中には次のものがあります。
Ｓｔａｔｕｓ
オペレーティングモードや割り込みマスクなどの状態を保持します。
Ｃａｕｓｅ
ＣＰＵ　例外の原因情報を保持します。
ＢａｄＶＡｄｄｒ
仮想アドレスの参照によって発生する　ＣＰＵ　例外（ＴＬＢ例外、アドレスエラー例外）の発生時に、原因になった仮想アドレスを保持します。
ＥＰＣ
ＣＰＵ　例外の発生時に、実行していた命令のアドレスを保持します。
【００６７】
コンパイラのスタック使用方法
サブルーチン呼出しやレジスタ　ｓ０−ｓ８　を使うサブルーチンは使用するレジスタの元の値を保存するためにスタックを使います。スタックは　ａｕｔｏ　変数の記憶領域として使われることも有ります。サブルーチン呼出しをする場合、ＯＰＥＮ−Ｒ　ＳＤＫのコンパイラー　ｇｃｃ，　ｇ＋＋　は、今の　ｒａ　をスタックの最上位ワードアドレスに保存します。
以下に例を示します。

図７は関数　ｅｎｔｒｙ＿ｐｏｉｎｔ０　から順に　ｆｕｎｃ１，　ｆｕｎｃ２　と呼び出され、　ｆｕｎｃ２　のアドレス（ａ）を実行中のスタックの状態を示します。
【００６８】
ＭＩＰＳ　アーキテクチャに関しての詳しい内容は、以下の文献を参照してください。　Ｓｅｅ　ＭＩＰＳ　Ｒｕｎ（著者：　Ｄｏｍｉｎｉｃ　Ｓｗｅｅｔｍａｎ、出版社：　Ｍｏｒｇａｎ　Ｋａｕｆｍａｎｎ　Ｐｕｂｌｉｓｈｅｒｓ、ＩＳＢＮ：　１５５８６０４１０３）、ＭＩＰＳ　ＲＩＳＣ　Ａｒｃｈｉｔｅｃｔｕｒｅ（著者：　Ｇｅｒｒｙ　Ｋａｎｅ，Ｊｏｅ　Ｈｅｉｎｒｉｃｈ、出版社：　Ｐｒｅｎｔｉｃｅ　Ｈａｌｌ、ＩＳＢＮ：　０１３５９０４７２２）、ｍｉｐｓ　ＲＩＳＣ　アーキテクチャ　−　Ｒ２０００／Ｒ３０００　−（著者：　Ｇｅｒｒｙ　Ｋａｎｅ、監訳：　前川　守、出版社：　共立出版、ＩＳＢＮ：　４３２００２５９８９）
【００６９】
５．２．２　ＣＰＵ例外発生時のシステムの動作
システムが強制終了する　ＣＰＵ　例外が発生した場合、システムはすべてのオブジェクトの動作を止めた状態で　Ｅｘｃｅｐｔｉｏｎ　Ｍｏｎｉｔｏｒ　を起動します。この時には無線コンソールの動作も停止します。Ｅｘｃｅｐｔｉｏｎ　Ｍｏｎｉｔｏｒ　はＡＩＢＯプログラミングメモリースティックの／ＯＰＥＮ−Ｒ／ＳＹＳＴＥＭ／ＣＯＮＦ／ＥＭＯＮ．ＣＦＧ　に書かれているコマンドを実行した後、ＡＩＢＯ　の電源を切ります。
【００７０】
５．２．２．１　デフォルトの　ＥＭＯＮ．ＣＦＧ
ＥＭＯＮ．ＣＦＧのファイルは、以下のディレクトリーにあります。
／ＯＰＥＮ−Ｒ／ＳＹＳＴＥＭ／ＣＯＮＦ／
ＥＭＯＮ．ＣＦＧの内容
ｐｌａｙ　ｅｘｃｅｐｔｉｏｎ
ｐｌａｙ　ｗａｒｎｉｎｇ
ｅｘｃｅｐｔｉｏｎ　＞　／ＭＳ／ＯＰＥＮ−Ｒ／ＥＭＯＮ．ＬＯＧ
ｃｐ０　＞＞　／ＭＳ／ＯＰＥＮ−Ｒ／ＥＭＯＮ．ＬＯＧ
ｃｐ１　＞＞　／ＭＳ／ＯＰＥＮ−Ｒ／ＥＭＯＮ．ＬＯＧ
ｏｂｊｓ　＞＞　／ＭＳ／ＯＰＥＮ−Ｒ／ＥＭＯＮ．ＬＯＧ
ｄｓｔａｃｋ　−ｍａｘ　０ｘ４０００　−ｒ　０ｘ４０　＞＞　／ＭＳ／ＯＰＥＮ−Ｒ／ＥＭＯＮ．ＬＯＧ
ｐｌａｙ　ｆｉｎｉｓｈ
【００７１】
／ＭＳ／は、ＡＩＢＯプログラミングメモリースティックのルートディレクトリーを表します。５つのコマンド　ｅｘｃｅｐｔｉｏｎ，　ｃｐ０，　ｃｐ１，　ｏｂｊｓ，ｄｓｔａｃｋ　の出力が、ＡＩＢＯプログラミングメモリースティックの／ＯＰＥＮ−Ｒ／ＥＭＯＮ．ＬＯＧに書かれます。Ｅｘｃｅｐｔｉｏｎ　Ｍｏｎｉｔｏｒ　の起動からシステム終了まで、　ｐｌａｙ　コマンドによって音を鳴らしています。音が鳴っている間は、メモリースティックへの書き込み中です。
【００７２】
５．２．３　ＣＰＵ例外の種類とオブジェクトの特定
ＣＰＵ例外の種類は　ＥＭＯＮ．ＬＯＧ　を調べて　ｅｘｃｅｐｔｉｏｎ　コマンドが最後に出力する　ｅｘｃｅｐｔｉｏｎ　ｃｏｄｅ　の表示を探します。オブジェクトを特定するには　［ｏｂｊｅｃｔ　ｉｎｆｏ］ｃｏｎｔｅｘｔ　の値と　［ｏｂｊｅｃｔ　ｌｉｓｔ］　の情報を使います。例えば　ＥＭＯＮ．ＬＯＧに図８のように書かれていたら、オブジェクトｃｒａｓｈ　がＣＰＵ例外発生の原因です。
【００７３】
５．２．４　アセンブリ命令の特定
ＴＬＢ　例外やアドレスエラー例外が起きた場合は、まず　ＢａｄＶＡｄｄｒ　の値を調べます。アドレスエラー例外の場合、ＢａｄＶＡｄｄｒ　にはアラインのとれていないアドレスなどメモリー参照に失敗したアドレスが保持されています。
【００７４】
ＴＬＢ　例外の場合、ＢａｄＶＡｄｄｒ　にはアドレス変換に失敗した仮想アドレスが保持されています。そして　ＥＰＣ　の値を調べます。ＥＰＣ　の値が　ＢａｄＶＡｄｄｒ　の値と同じ場合は、不正なアドレスにジャンプしてＣＰＵ例外になっていると考えられます。もし　ｒａ　の値が有効なアドレスなら、次に示す手順でそのアドレスのアセンブリ命令を調べます。ＥＰＣ　の値がＢａｄＶＡｄｄｒの値と違う場合は　、ＥＰＣ　の値のアドレスのアセンブリ命令を調べます。そこがデータ領域であったりスタック領域であることもあります。どこかで誤ってデータ領域やスタック領域にジャンプし、偶然にＣＰＵ例外になったという状態です。その時はそこにジャンプする前の付近のアドレスがわかる　ｒａ　の値でアセンブリ命令を調べます。
【００７５】
アセンブリ命令の調べ方
Ｅｘｃｅｐｔｉｏｎ　Ｍｏｎｉｔｏｒ　でわかるアドレスは実行時に決まるアドレスなので、アセンブリ命令を調べるには、それに対応するリンク時のアドレスを計算します。次の計算をします。
＜リンク時のアドレス＞　＝
＜実行時のアドレス＞　−　＜ｇｐ　レジスターの値＞　＋　＜シンボル　＿ｇｐ　のアドレス＞
ｇｐ　レジスターの値は　ＥＭＯＮ．ＬＯＧ　の　［ｇｅｒｅｎａｌ　ｒｅｇｉｓｔｅｒ］　ｇｐ：ｒ２８：　の値を調べます。
シンボル　＿ｇｐ　のリンク時のアドレスは、ＣＰＵ例外を起こしたオブジェクトの　．ｂｉｎ　ファイルを作成したディレクトリーで、次のコマンドを実行して調べます。

２番目に表示される値、この例では　０ｘ００４６６４９０です。
【００７６】
この計算でリンク時のアドレスがわかったら、次のコマンドを実行します。
％　ｍｉｐｓｅｌ−ｌｉｎｕｘ−ｏｂｊｄｕｍｐ　−ｄ　−Ｃ　＜オブジェクト名＞．ｎｏｓｎａｐ．ｅｌｆ
このオブジェクトの逆アセンブル結果が表示されるので、リンク時のアドレス周辺のアセンブリ命令と関数名を確認します。例えば次の例で、知りたいアドレスが　４００３ｄ８　の場合、上記のコマンドを実行すると、図９に示すような実行結果が出力されます。
【００７７】
ここでは、その場所が関数　ａｃｃｅｓｓ＿ｎｕｌｌ＿ｄａｔａ＿ｐｏｉｎｔｅｒ（）　内であることがわかります。関数名までわかったらソースコードを探し、逆アセンブル結果とソースコードを突き合わせて問題の箇所を特定します。仮に逆アセンブル結果に知りたいアドレスがなかった場合は、次のコマンドの実行結果から、そのアドレスがテキスト領域かどうかを確認します。
％　ｍｉｐｓｅｌ−ｌｉｎｕｘ−ｎｍ　−ｎ　−Ｃ　＜オブジェクト名＞．ｎｏｓｎａｐ．ｅｌｆ
また次のコマンドの実行結果から、データ領域の内容を確認します。
％　ｍｉｐｓｅｌ−ｌｉｎｕｘ−ｏｂｊｄｕｍｐ　−ｓｔ　−Ｃ　＜オブジェクト名＞．ｎｏｓｎａｐ．ｅｌｆ
ＥＭＯＮ．ＬＯＧ　の　［ｓｔａｃｋ　ｉｎｆｏ］，　［ｓｔａｃｋ　ｄｕｍｐ］　から、スタックの内容も確認します。
【００７８】
５．２．５　ＥＭＯＮ．ＣＦＧ　で使えるコマンド
ｅｘｃｅｐｔｉｏｎ
このコマンドはＣＰＵ例外を起こしたオブジェクトの情報や例外発生時の汎用レジスターの内容を出力します。
書式：ｅｘｃｅｐｔｉｏｎ
実行例：ｅｘｃｅｐｔｉｏｎの実行例は、図１０に示す。
【００７９】
ｃｐ０
このコマンドはコプロセッサ　０　（ｓｙｓｔｅｍ　ｃｏｎｔｒｏｌ　ｃｏｐｒｏｃｅｓｓｏｒ）　のレジスターの内容を表示します。
書式：　ｃｐ０
実行例：　ｃｐ０の実行例は、図１１に示す。
【００８０】
ｃｐ１
このコマンドはコプロセッサ　１　（浮動小数点ユニット）のレジスターの内容を表示します。
書式：　ｃｐ１
実行例：　ｃｐ１の実行例は、図１２に示す。
【００８１】
ｏｂｊｓ
このコマンドはＣＰＵ例外発生時に存在したオブジェクトのリストを表示します。
このコマンドの出力からオブジェクト名と　ｃｏｎｔｅｘｔ　ＩＤ　との対応を調べることができます。
書式：　ｏｂｊｓ
実行例：　ｏｂｉｓの実行例は、図１３に示す。
【００８２】
ｓｔａｃｋ，　ｄｓｔａｃｋ
ｓｔａｃｋ　コマンドはＣＰＵ例外を起こしたオブジェクトのスタック情報、ｄｓｔａｃｋ　コマンドはさらにスタックの内容を表示します。引数なしで実行した場合、　ｄｓｔａｃｋ　コマンドはスタックを　ｓｐ　の指すアドレスからダンプします。オプション　−ｍａｘ　でダンプする最大サイズを指定することができます。またオプション　−ｒ　を付けた場合、指定サイズ分　ｓｐ　よりも下位のアドレスからダンプします。また両コマンドともにオブジェクトの　ｃｏｎｔｅｘｔ　ＩＤ　を引数に指定して別のオブジェクトのスタック情報を表示することができます。

【００８３】
ｔｌｂ
ｔｌｂ　コマンドは　ＴＬＢ　の内容を表示します。
書式：　ｔｌｂ
実行例：　ｔｌｂの実行例は、図１５に示す。
【００８４】
ｄｕｍｐ
ｄｕｍｐ　コマンドはメモリー内容を１６進数で表示します。引数にはアドレスを指定します。サイズを指定しなかった場合は、サイズを　０ｘ１００　として表示します。オプション　−ｗ　を指定した場合は２バイトごとの表示、−ｌ　を指定した場合は４バイトごとの表示です。１６進表示の右側にはバイトごとにＡＳＣＩＩ文字を表示します。表示できない文字の場合は、代わりにピリオド　’．’　を表示します。この文字表示はオプション　−ｌ，　−ｗ　によって変わりません。
書式：　ｄｕｍｐ　［−ｗ｜−ｌ］　ａｄｄｒ　［ｓｉｚｅ］
実行例　（ｄｕｍｐ　０ｘ８０４６０２３８　０ｘ４０）：　ｄｕｍｐの実行例は、図１６に示す。
【００８５】
ｐｌａｙ
このコマンドは音を鳴らすために使用します。引数で鳴らすメロディを選択します。
書式：　ｐｌａｙ　ｍｅｌｏｄｙ　　引数　ｍｅｌｏｄｙ　の説明
ｅｘｃｅｐｔｉｏｎ：　Ｅｘｃｅｐｔｉｏｎ　Ｍｏｎｉｔｏｒ　の起動用です。
Ｗａｒｎｉｎｇ：　メモリースティック書き込み中の警告用です。このメロディは自動的にループします。
Ｆｉｎｉｓｈ：　メモリースティック書き込みの終了用です。
【００８６】
Ａ．ライブラリー関数
ＯＰＥＮ−Ｒ　ＳＤＫで作成するプログラムでは、以下の関数が利用できます。これらの関数を定義するライブラリは、ｍｋｂｉｎコマンドによって自動的にリンクされます。
【００８７】
Ａ．１　ファイルシステム
以下の関数を使ってファイルシステムにアクセスすることができます。ｗｒｉｔｅ（）とｒｅａｄ（）関数はターミナルにアクセスするためにも使用します。以下の関数は同名のＵＮＩＸ　ＡＰＩとほぼ同様に動作します。関数：ｏｐｅｎ，　ｃｌｏｓｅ，　ｒｅａｄ，　ｗｒｉｔｅ，　ｌｓｅｅｋ，　ｆｓｔａｔ，　ｓｔａｔ，　ｕｎｌｉｎｋ，　ｉｓａｔｔｙ，ｍｋｄｉｒ，　ｒｍｄｉｒ，　ｏｐｅｎｄｉｒ，　ｃｌｏｓｅｄｉｒ，　ｒｅａｄｄｉｒ，ｒｅｗｉｎｄｄｉｒ
以下にＯＰＥＮ−Ｒ　ＳＤＫ特有の動作について説明します。
３未満のファイルディスクリプターは、ターミナルデバイス（ｔｅｌｎｅｔターミナル）を表わします。
ディスクリプター０、１、２の間で違いはありません。ファイルディスクリプターはシステム全体を通じて共通です。あるオブジェクトから他のオブジェクトによってオープンされたファイルディスクリプターを使用することができます。
以下は、ファイルシステムのパスに関する制限です。
・ディレクトリーの区切りは／で示します。
・パスは／ＭＳ／で始める必要があります。／ＭＳ／はＡＩＢＯプログラミングメモリースティックのルートを表わします。相対パスは使用できません。
・ファイル名は８＋３フォーマットです。
例
ＢＡＳＥＮＡＭＥ．ＥＸＴ　　　　　（正）
ＢＡＳＥＮＡＭＥＥＸＴ　　　　　　　　（誤）
ファイル名と拡張子を区別する記号は’．’です。
・以下は使用できる文字です。小文字は自動的に大文字に変換されます。
【００８８】
ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ
ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺ
０１２３４５６７８９
＄＆＃｛｝￣％’（）−＠＾｀！＿
ｏｐｅｎ（）では、以下のフラグが使用できます。
Ｏ＿ＲＤＯＮＬＹ，　Ｏ＿ＷＲＯＮＬＹ，　Ｏ＿ＲＤＷＲ，　Ｏ＿ＡＰＰＥＮＤ，　Ｏ＿ＣＲＥＡＴＥ，　Ｏ＿ＴＲＵＮＣ，　Ｏ＿ＥＸＣＬ
ｏｐｅｎ（）　は、ｍｏｄｅ＿ｔ型の引数を無視します。すでにオープンされているファイルを再度オープンできるのは、双方のｏｐｅｎ（）の呼び出しで、Ｏ＿ＲＤＯＮＬＹを指定した場合に限ります。ｉｓａｔｔｙ（）　は、ファイルディスクリプターが３未満なら１を返します。それ以外は０を返します。
【００８９】
以下は、ｓｔａｔ（）とｆｓｔａｔ（）から返される構造体のメンバー変数です。下記以外のメンバーは、未定義の値を持ちます。
ｓｔ＿ｓｉｚｅ：　ファイルサイズです。この値はファイルがオープンしている間、正しい値を示さない場合があります。
ｓｔ＿ｍｏｄｅ：　アクセス権は常に０７７７です。ファイルの場合Ｓ＿ＩＦＲＥＧビットが１になります。ディレクトリの場合Ｓ＿ＩＦＤＩＲビットが１になります。
ｍｋｄｉｒ（）はｍｏｄｅ＿ｔ型の引数を無視します。ｒｅａｄｄｉｒ（）を使って読み込み可能なエントリの最大数は６８２です。ｒｅａｄｄｉｒ（）の返すｄｉｒｅｎｔ構造体は、ｄ＿ｎａｍｅフィールドのみが有効です。その他のフィールドの値は未定義です。ｄ＿ｎａｍｅフィールドには、ディレクトリエントリの名前がヌルで終わる文字列で格納されます。ｒｅａｄｄｉｒ（）はボリュームラベルとロングファイルネームのエントリを返しません。
【００９０】
Ａ．２　Ｃ標準ライブラリー
ＯＰＥＮ−Ｒ　ＳＤＫはＣライブラリー用にｎｅｗｌｉｂ−１．９．０を使用します。以下はＯＰＥＮ−Ｒ　ＳＤＫ特有の動作について説明します。
以下のＵＮＩＸ　ＡＰＩに依存する関数は動作しません。
ｅｘｅｃｖｅ，　ｆｏｒｋ，　ｇｅｔｐｉｄ，　ｇｅｔｔｉｍｅｏｆｄａｙ，　ｋｉｌｌ，　ｌｉｎｋ，　ｔｉｍｅｓ，　ｗａｉｔ，　ｆｃｎｔｌ
以下の関数がこれにあてはまります。
ｃｌｏｃｋ，　ｆｄｏｐｅｎ，　ｒａｉｓｅ，　ｓｉｇｎａｌ，　ｓｙｓｔｅｍ，　ｍｋｓｔｅｍｐ，　ｍｋｔｅｍｐ，　ｔｅｍｐｎａｍ，　ｔｍｐｆｉｌｅ，　ｔｍｐｎａｍ。
以下のＵＮＩＸ　ＡＰＩに依存する関数については、前節で説明したように、ＯＰＥＮ−Ｒ　ＳＤＫ特有の振舞いを持ちます。
ｏｐｅｎ，　ｃｌｏｓｅ，　ｒｅａｄ，　ｗｒｉｔｅ，　ｌｓｅｅｋ，　ｆｓｔａｔ，　ｓｔａｔ，　ｕｎｌｉｎｋ，　ｉｓａｔｔｙ
以下の関数がこれにあてはまります。
ｆｃｌｏｓｅ，　ｆｆｌｕｓｈ，　ｆｇｅｔｃ，　ｆｇｅｔｐｏｓ，　ｆｇｅｔｓ，　ｆｉｌｅｎｏ，　ｆｉｐｒｉｎｔｆ，　ｆｏｐｅｎ，　ｆｐｒｉｎｔｆ，　ｆｐｕｔｃ，　ｆｐｕｔｓ，　ｆｒｅａｄ，　ｆｒｅｏｐｅｎ，　ｆｓｅｅｋ，　ｆｓｅｔｐｏｓ，　ｆｔｅｌｌ，　ｆｗｒｉｔｅ，　ｇｅｔｃ，　ｇｅｔｃｈａｒ，　ｇｅｔｏｐｔ，　ｇｅｔｓ，　ｇｅｔｗ，　ｉｐｒｉｎｔｆ，　ｐｅｒｒｏｒ，　ｐｒｉｎｔｆ，　ｐｕｔｃ，　ｐｕｔｃｈａｒ，　ｐｕｔｓ，ｐｕｔｗ，　ｒｅｍｏｖｅ，　ｒｅｗｉｎｄ，　ｓｅｔｂｕｆ，　ｓｅｔｖｂｕｆ，　ｕｎｇｅｔｃ，　ｖｆｉｐｒｉｎｔｆ，　ｖｆｐｒｉｎｔｆ，　ｖｐｒｉｎｔｆ，　ｓｃａｎｆ，　ｆｓｃａｎｆ
以下の関数は、ｎｅｗｌｉｂの実装を使用しません。
・ｅｘｉｔ（）はオブジェクトの実行を停止します。オブジェクトは、メッセージ待ち状態に入ります。Ｃ＋＋静的変数のデストラクターは、呼ばれません。
・ａｔｅｘｉｔ（）はなにもしません。
・ａｂｏｒｔ（）は、ａｂｏｒｔ（）が呼ばれたという内容のメッセージを表示します。次にａｂｏｒｔ（）はオブジェクトの実行を停止します。オブジェクトは、メッセージ待ち状態に入ります。
・ｒｅｎａｍｅ（）はファイルまたはディレクトリーのパスを変更します。パスについての制限は前節を参照してください。
・ｍａｌｌｏｃ（）やｆｒｅｅ（）などのメモリー割り当て／開放の実装として、ｄｌｍａｌｌｏｃライブラリーバージョン２．７．０を、ｎｅｗｌｉｂにある２．６．４の代わりに使用します。
【００９１】
Ａ．３　Ｃ＋＋標準ライブラリー
ＯＰＥＮ−Ｒ　ＳＤＫは、Ｃ＋＋標準ライブラリーとしてｇｃｃパッケージに含まれるｌｉｂｓｔｄｃ＋＋−ｖ３を使用します。このライブラリは内部的にｎｅｗｌｉｂの関数を呼び出すので、上記の説明は、Ｃ＋＋の機能にも適用されます。
【００９２】
Ｂ．ｓｔｕｂ．ｃｃ
オブジェクトのソースコードは、以下の項目を満たす必要があります。スタブジェネレーターを使用していないときのみ、下記の項目に注意してください。スタブジェネレータで作成されるコードは、自動的に下記の項目を満たします。
【００９３】
ＯｂｊｅｃｔＥｎｔｒｙＴａｂｌｅ
オブジェクトは、ＯｂｊｅｃｔＥｎｔｒｙＴａｂｌｅという名前の構造体を待ちます。この構造体はセレクタ番号とエントリポイントとの対応を指定します。ＯｂｊｅｃｔＥｎｔｒｙＴａｂｌｅは以下の形式を持ちます。

ＳＥＬＥＣＴＯＲ＿ＮＵＭＢＥＲは、負数でない整数です。セレクタ番号がＳＥＬＥＣＴＯＲ＿ＮＵＭＢＥＲであるメッセージをオブジェクトが受信したとき、ＥＮＴＲＹ＿ＰＯＩＮＴが呼ばれます。ＥＮＴＲＹ＿ＰＯＩＮＴには、後述するＧＥＮ＿ＥＮＴＲＹマクロを使用して定義した関数を指定します。
【００９４】
ＧＥＮ＿ＥＮＴＲＹ　マクロ
ＧＥＮ＿ＥＮＴＲＹマクロは、２個の引数ＥＮＴＲＹＮＡＭＥとＦＵＮＮＡＭＥをとり、ＥＮＴＲＹＮＡＭＥで指定した名前のエントリポイント関数を定義します。この関数はラッパー（ｗｒａｐｐｅｒ）関数です。この関数はいくつかのレジスターを設定しＦＵＮＮＡＭＥで指定した関数を呼びます。ＯｂｊｅｃｔＥｎｔｒｙＴａｂｌｅに登録するすべての関数は、このマクロを使用して定義します。関数ＦＵＮＮＡＭＥはＣリンケージを持ち、受信したメッセージのデータを指すｖｏｉｄ＊型の１個の引数をとります。ＧＥＮ＿ＥＮＴＲＹマクロはａｐｓｙｓ．ｈで定義されます。
【００９５】
ＰｒｏｌｏｇｕｅＥｎｔｒｙ
次の行をオブジェクトのソースコード内に記述する必要があります。
ＧＥＮ＿ＥＮＴＲＹ（ＰｒｏｌｏｇｕｅＥｎｔｒｙ，　Ｐｒｏｌｏｇｕｅ）；
これはエントリポイント関数ＰｒｏｌｏｇｕｅＥｎｔｒｙ（）を定義します。この関数はオブジェクトがロードされたときに呼ばれます。ＰｒｏｌｏｇｕｅＥｎｔｒｙ（）は、ｌｉｂａｐｓｙｓ．ａで定義されるＰｒｏｌｏｇｕｅ（）を呼びます。ｌｉｂａｐｓｙｓ．ａはｍｋｂｉｎコマンドでオブジェクトに自動的にリンクされます。Ｐｒｏｌｏｇｕｅ（）はいくつかの初期化を行い、Ｃ＋＋の大域変数のコンストラクターを呼びます。
【００９６】
コード例
以下は上記の条件を満たすコード例です。

＜レファレンスガイド＞
続いて、本具体例で用いられるオブジェクトの基底クラスについて説明する。
【００９７】
第１章　基底クラス
１．１　ＯＯｂｊｅｃｔクラス
ＯＯｂｊｅｃｔは、オブジェクトの基底クラスです。オブジェクトのｏｅｎｔｒｙＩＮＩＴ、ｏｅｎｔｒｙＳＴＡＲＴ、ｏｅｎｔｒｙＳＴＯＰ、ｏｅｎｔｒｙＤＥＳＴＲＯＹのエントリに対してＩｎｉｔ（）、Ｓｔａｒｔ（）、Ｓｔｏｐ（）、Ｄｅｓｔｒｏｙ（）を対応づけます。ＯＯｂｊｅｃｔＭａｎａｇｅｒからｏｅｎｔｒｙＩＮＩＴ、ｏｅｎｔｒｙＳＴＡＲＴ、ｏｅｎｔｒｙＳＴＯＰ、ｏｅｎｔｒｙＤＥＳＴＲＯＹ　にメッセージが送信されると、Ｉｎｉｔ（）、Ｓｔａｒｔ（）、Ｓｔｏｐ（）、　Ｄｅｓｔｒｏｙ（）が起動され、それぞれＤｏＩｎｉｔ（）、ＤｏＳｔａｒｔ（）、ＤｏＳｔｏｐ（）、ＤｏＤｅｓｔｒｏｙ（）を起動します。ＯＯｂｊｅｃｔの継承クラスでは、ＤｏＩｎｉｔ（）、ＤｏＳｔａｒｔ（）、ＤｏＳｔｏｐ（）、ＤｏＤｅｓｔｒｏｙ（）でオブジェクトに固有の処理を記述します。ＯＯｂｊｅｃｔはｐｒｏｔｅｃｔｅｄメンバーにｍｙＯＩＤ＿　を持ち、継承クラスで使用できます。ｍｙＯＩＤ＿　は、ＯＯｂｊｅｃｔ：：ＯＯｂｊｅｃｔ（）で初期化されます。
【００９８】
ヘッダファイルは、「＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＯｂｊｅｃｔ．ｈ＞」、ライブラリは、「ｌｉｂＯＰＥＮＲ．ａ」である。クラスを以下に示す。

【００９９】
また、ＯＯｂｊｅｃｔクラスには、以下のメンバー関数があります。
・Ｉｎｉｔ（）
構文は、ｖｏｉｄ　Ｉｎｉｔ（ｃｏｎｓｔ　ＯＳｙｓｔｅｍＥｖｅｎｔ＆　ｅｖｅｎｔ）　であり、オブジェクトが初期化されるときにＯＯｂｊｅｃｔＭａｎａｇｅｒ　から呼ばれます。Ｉｎｉｔ時に、ｅｖｅｎｔがＯＯｂｊｅｃｔＭａｎａｇｅｒからオブジェクトへ渡されます。　Ｉｎｉｔ（）はＤｏＩｎｉｔ（）を起動し、ＤｏＩｎｉｔ（）の戻り値をＯＯｂｊｅｃｔＭａｎａｇｅｒに通知します。仮引数は、ｅｖｅｎｔ（Ｉｎｉｔ　のイベント情報）である。戻り値はない。
【０１００】
・Ｓｔａｒｔ（）
構文は、ｖｏｉｄ　Ｓｔａｒｔ（ｃｏｎｓｔ　ＯＳｙｓｔｅｍＥｖｅｎｔ＆　ｅｖｅｎｔ）　であり、オブジェクトが起動するときにＯＯｂｊｅｃｔＭａｎａｇｅｒ　から呼ばれます。Ｓｔａｒｔ時に、ｅｖｅｎｔがＯＯｂｊｅｃｔＭａｎａｇｅｒからオブジェクトへ渡されます。Ｓｔａｒｔ（）はＤｏＳｔａｒｔ（）を起動し、ＤｏＳｔａｒｔ（）の戻り値をＯＯｂｊｅｃｔＭａｎａｇｅｒに通知します。仮引数は、ｅｖｅｎｔ（Ｓｔａｒｔ　のイベント情報）である。戻り値はない。
【０１０１】
・Ｓｔｏｐ（）
構文は、ｖｏｉｄ　Ｓｔｏｐ（ｃｏｎｓｔ　ＯＳｙｓｔｅｍＥｖｅｎｔ＆　ｅｖｅｎｔ）　であり、オブジェクトが停止するときにＯＯｂｊｅｃｔＭａｎａｇｅｒ　から呼ばれます。Ｓｔｏｐ時に、ｅｖｅｎｔがＯＯｂｊｅｃｔＭａｎａｇｅｒからオブジェクトへ渡されます。Ｓｔｏｐ（）はＤｏＳｔｏｐ（）を起動し、ＤｏＳｔｏｐ（）の戻り値をＯＯｂｊｅｃｔＭａｎａｇｅｒに通知します。仮引数は、ｅｖｅｎｔ（Ｓｔｏｐ　のイベント情報）である。戻り値はない。
【０１０２】
・Ｄｅｓｔｒｏｙ（）
構文は、ｖｏｉｄ　Ｄｅｓｔｒｏｙ（ｃｏｎｓｔ　ＯＳｙｓｔｅｍＥｖｅｎｔ＆　ｅｖｅｎｔ）　であり、オブジェクトが破壊されるときにＯＯｂｊｅｃｔＭａｎａｇｅｒから呼ばれます。Ｄｅｓｔｒｏｙ時に、ｅｖｅｎｔがＯＯｂｊｅｃｔＭａｎａｇｅｒからオブジェクトへ渡されます。Ｄｅｓｔｒｏｙ（）はＤｏＤｅｓｔｒｏｙ（）を起動し、ＤｏＤｅｓｔｒｏｙ（）の戻り値をＯＯｂｊｅｃｔＭａｎａｇｅｒに通知します。仮引数は、ｅｖｅｎｔ（Ｄｅｓｔｒｏｙ　のイベント情報）であり、戻り値はない。
【０１０３】
・ＤｏＩｎｉｔ（）
構文は、ＯＳｔａｔｕｓ　ＤｏＩｎｉｔ（ｃｏｎｓｔ　ＯＳｙｓｔｅｍＥｖｅｎｔ＆　ｅｖｅｎｔ）　であり、Ｉｎｉｔ（）から起動されます。継承クラスでオーバーライドして固有の処理を記述します。ｅｖｅｎｔはＩｎｉｔ（）で渡されるものと同じです。ＤｏＩｎｉｔ（）の戻り値がＩｎｉｔ（）の中でＯＯｂｊｅｃｔＭａｎａｇｅｒに対して通知されます。仮引数は、ｅｖｅｎｔ（Ｉｎｉｔのイベント情報）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、その他（失敗の場合は、ｏＳＵＣＣＥＳＳ以外を返します。）がある。戻り値は、オーバライドするＤｏＩｎｉｔ（）で自由に設定できます。
【０１０４】
・ＤｏＳｔａｒｔ（）
構文は、ＯＳｔａｔｕｓ　ＤｏＳｔａｒｔ（ｃｏｎｓｔ　ＯＳｙｓｔｅｍＥｖｅｎｔ＆　ｅｖｅｎｔ）　であり、Ｓｔａｒｔ（）から起動されます。継承クラスでオーバーライドして固有の処理を記述します。ｅｖｅｎｔはＳｔａｒｔ（）で渡されるものと同じです。ＤｏＳｔａｒｔ（）の戻り値がＳｔａｒｔ（）の中でＯＯｂｊｅｃｔＭａｎａｇｅｒに対して通知されます。仮引数は、ｅｖｅｎｔ（Ｓｔａｒｔ　のイベント情報）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、その他（失敗の場合は、ｏＳＵＣＣＥＳＳ以外を返します。）がある。戻り値は、オーバライドするＤｏＳｔａｒｔ（）で自由に設定できます。
【０１０５】
・ＤｏＳｔｏｐ（）
構文は、ＯＳｔａｔｕｓ　ＤｏＳｔｏｐ（ｃｏｎｓｔ　ＯＳｙｓｔｅｍＥｖｅｎｔ＆　ｅｖｅｎｔ）　であり、Ｓｔｏｐ（）から起動されます。継承クラスでオーバーライドして固有の処理を記述します。ｅｖｅｎｔはＳｔｏｐ（）で渡されるものと同じです。ＤｏＳｔｏｐ（）の戻り値がＳｔｏｐ（）の中でＯＯｂｊｅｃｔＭａｎａｇｅｒに対して通知されます。仮引数は、ｅｖｅｎｔ（Ｓｔｏｐ　のイベント情報）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、その他（失敗の場合は、ｏＳＵＣＣＥＳＳ以外を返します。）があり、戻り値は、オーバライドするＤｏＳｔｏｐ（）で自由に設定できます。
【０１０６】
・ＤｏＤｅｓｔｒｏｙ（）
構文は、ＯＳｔａｔｕｓ　ＤｏＤｅｓｔｒｏｙ（ｃｏｎｓｔ　ＯＳｙｓｔｅｍＥｖｅｎｔ＆　ｅｖｅｎｔ）　であり、Ｄｅｓｔｒｏｙ（）から起動されます。継承クラスでオーバーライドして固有の処理を記述します。ｅｖｅｎｔはＤｅｓｔｒｏｙ（）で渡されるものと同じです。ＤｏＤｅｓｔｒｏｙ（）の戻り値が、Ｄｅｓｔｒｏｙ（）の中でＯＯｂｊｅｃｔＭａｎａｇｅｒに対して通知されます。仮引数は、ｅｖｅｎｔ（Ｄｅｓｔｒｏｙ　のイベント情報）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、その他（失敗の場合は、ｏＳＵＣＣＥＳＳ以外を返します。）がある。戻り値は、オーバライドするＤｏＤｅｓｔｒｏｙ（）で自由に設定できます。
【０１０７】
・ＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅＥｎｔｒｙ（）
構文は、Ｏｓｔａｔｕｓ　ＲｅｇｉｓｔｅｒＳｅｒｖｉｃｅＥｎｔｒｙ（ｃｏｎｓｔ　ＯＳｅｒｖｉｃｅＥｎｔｒｙ＆　ｅｎｔｒｙ，　ｃｏｎｓｔ　ｃｈａｒ＊　ｎａｍｅ）　であり、サービスエントリを登録します。仮引数は、ｅｎｔｒｙ（サービスエントリ）、ｎａｍｅ（サービスネーム）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＡＬＲＥＡＤＹ＿ＥＸＩＳＴ（すでに同じ名前のサービスエントリが登録されています。）、ｏＦＡＩＬ（失敗）である。
【０１０８】
第２章　オブジェクト間通信
２．１　ＯＳｕｂｊｅｃｔクラス
Ｏｓｕｂｊｅｃｔクラスには、以下のメンバー関数があります。
・ＯＳｕｂｊｅｃｔ（）
構文は、ＯＳｕｂｊｅｃｔ（ｖｏｉｄ）　であり、コンストラクタです。仮引数及び戻り値はない。
【０１０９】
・￣ＯＳｕｂｊｅｃｔ（）
構文は、￣ＯＳｕｂｊｅｃｔ（）であり、デストラクタです。仮引数及び戻り値はない。
【０１１０】
・ＳｅｔＲｅａｄｙＥｎｔｒｙ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＲｅａｄｙＥｎｔｒｙ（ｃｏｎｓｔ　ＯＳｅｒｖｉｃｅＥｎｔｒｙ＆　ｅｎｔｒｙ）　であり、サブジェクトがＡＳＳＥＲＴ−ＲＥＡＤＹメッセージまたはＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを受信するためのエントリを設定します。この設定はＤｏＩｎｉｔ（）内で行います。仮引数は、ｅｎｔｒｙ（ＡＳＳＥＲＴ−ＲＥＡＤＹメッセージまたはＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを受信するためのエントリ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１１１】
・ＧｅｔＩＤ（）
構文は、ｃｏｎｓｔ　ＳｕｂｊｅｃｔＩＤ＆　　ＧｅｔＩＤ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、サブジェクトのＳｕｂｊｅｃｔ　ＩＤを取得します。ＳｕｂｊｅｃｔＩＤは、サブジェクトごとに固有値です。仮引数はない。戻り値には、Ｓｕｂｊｅｃｔ　ＩＤがある。
【０１１２】
・ＳｅｔＢｕｆｆｅｒＳｉｚｅ（）
構文は、
ＯＳｔａｔｕｓ　　ＳｅｔＢｕｆｆｅｒＳｉｚｅ（ｓｉｚｅ＿ｔ　ｓｉｚｅ）　であり、サブジェクト内で各オブザーバ用に準備される最大バッファサイズを設定します。この設定を行う場合はＤｏＩｎｉｔ（）内で行います。仮引数は、ｓｉｚｅ（各オブザーバー用の最大バッファサイズ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１１３】
・ＧｅｔＢｕｆｆｅｒＳｉｚｅ（）
構文は、ｓｉｚｅ＿ｔ　　ＧｅｔＢｕｆｆｅｒＳｉｚｅ（ｖｏｉｄ）　ｃｏｎｓｔであり、ＤｏＩｎｉｔ（）で設定されたバッファサイズを返します。仮引数はない。戻り値は、現在のバッファサイズである。
【０１１４】
・ＳｅｔＮｏｔｉｆｙＵｎｉｔＳｉｚｅ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＮｏｔｉｆｙＵｎｉｔＳｉｚｅ（ｓｉｚｅ＿ｔ　ｓｉｚｅ）　であり、送信データの最小単位を構成するＳｅｔＤａｔａ（）の数を設定します。例えば、あるデータがヘッダとボディから構成され、別々にＳｅｔＤａｔａ（）を実行しＮｏｔｉｆｙＯｂｓｅｒｖｅｒｓ（）を実行する場合、設定する値は２です。この関数の呼び出しは、サブジェクトが準備すべきバッファの大きさを計算する際に使用します。この値を設定する場合は、ＤｏＩｎｉｔ（）の中で行います。設定しない場合のデフォルト値は１です。これはＳｅｔＤａｔａ（）とＮｏｔｉｆｙＯｂｓｅｒｖｅｒｓ（）が１回づつ交互に呼ばれる場合に対応します。仮引数は、ｓｉｚｅ（送信データの最小単位を構成するのに必要なＳｅｔＤａｔａ（）数）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１１５】
・ＧｅｔＮｏｔｉｆｙＵｎｉｔＳｉｚｅ（）
構文は、ｓｉｚｅ＿ｔ　　ＧｅｔＮｏｔｉｆｙＵｎｉｔＳｉｚｅ（ｖｏｉｄ）　ｃｏｎｓｔであり、送信データの最小単位を構成するのに必要なＳｅｔＤａｔａ（）数を返します。仮引数はない。戻り値は、１回の送信に必要なＳｅｔＤａｔａ（）数である。
【０１１６】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ｃｏｎｓｔ　ｖｏｉｄ＊　ｂｕｆ，　ｓｉｚｅ＿ｔ　ｓｉｚｅ）　であり、すべてのオブザーバ用のバッファにデータ（アドレスとサイズ）を設定します。指定したデータは共有メモリ領域にコピーされるので、この関数を呼んだ後でｂｕｆにより指される領域を上書きできます。オーバーフロー時には、最も古い送信用のデータが現在のデータで上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。仮引数は、ｂｕｆ　（データがある領域を指すポインタ）、ｓｉｚｅ（データのサイズ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１１７】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩｎｆｏ＆　ｉｎｆｏ，　ｃｏｎｓｔ　ｖｏｉｄ＊　ｂｕｆ，　ｓｉｚｅ＿ｔ　ｓｉｚｅ）　であり、指定したオブザーバ用のバッファにデータ（アドレスとサイズ）を設定します。この関数はＦｉｎｄＯｂｓｅｒｖｅｒ（）の呼び出しを省略できる分だけ、ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆，　ｃｏｎｓｔ　ｖｏｉｄ＊，　ｓｉｚｅ＿ｔ）より効率的です。この関数内で、指定データは共有メモリ領域にコピーされるので、この関数を呼んだ後でｂｕｆにより指される領域を上書きできます。オーバーフロー時には、最も古い送信用のデータが現在のデータで上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。仮引数は、ｉｎｆｏ（オブザーバ情報。ＯｂｓｅｒｖｅｒＩｎｆｏ型は、例えばＯＳｕｂｊｅｃｔ：：ｂｅｇｉｎ（）などの呼び出しによって得られるＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ型が指しているデータにアクセスすることにより取得できます。）、ｂｕｆ　（データのある領域を指すポインタ）、ｓｉｚｅ（データのサイズ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１１８】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ，　ｃｏｎｓｔ　ｖｏｉｄ＊　ｂｕｆ，　ｓｉｚｅ＿ｔ　ｓｉｚｅ）　であり、この関数は、ＳｅｔＤａｔａ（＊ＦｉｎｄＯｂｓｅｒｖｅｒ（ｉｄ），　ｂｕｆ，　ｓｉｚｅ）とまったく同じ動作をします。すなわち、指定したオブザーバ用のバッファにデータ（アドレスとサイズ）を設定します。この関数内で、指定データは共有メモリ領域にコピーされるので、この関数を呼んだ後でｂｕｆにより指される領域を上書きできます。オーバーフロー時には送信用のデータのうち最も古いものが上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。仮引数は、ｉｄ（ＯｂｓｅｒｖｅｒＩＤ。ｉｄがこのサブジェクトに対して無効な場合、この関数の結果または効果は不定です。）、ｂｕｆ（データのある領域を指すポインタ）、ｓｉｚｅ（データのサイズ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１１９】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ＲＣＲｅｇｉｏｎ＊　ｒｅｇｉｏｎ）　であり、すべてのオブザーバ用のバッファに、ｒｅｇｉｏｎ引数で指定される共有メモリ領域を設定します。　オーバーフロー時には送信用のデータのうち最も古いものが上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。　この関数内でＲＣＲｅｇｉｏｎ：：ＡｄｄＲｅｆｅｒｅｎｃｅ（）　が呼ばれ、指定した領域に対する参照カウンタをインクリメントします。指定した領域は、再度使用可能になるまで上書き、または変更しないでください。領域が使用可能か調べるにはＲＣＲｅｇｉｏｎ：：ＮｕｍｂｅｒＯｆＲｅｆｅｒｅｎｃｅ（）を使用します。仮引数は、ｒｅｇｉｏｎ（参照カウンタ付き共有メモリ領域へのポインタ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２０】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩｎｆｏ＆　ｉｎｆｏ，　ＲＣＲｅｇｉｏｎ＊　ｒｅｇｉｏｎ）　であり、指定したオブザーバー用のバッファに、ｒｅｇｉｏｎ引数で指定される共有メモリ領域を設定します。この関数はＦｉｎｄＯｂｓｅｒｖｅｒ（）の呼び出しを省略できる分だけ、ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆，　ＲＣＲｅｇｉｏｎ＊　ｒｅｇｉｏｎ）　より効率的です。オーバーフロー時には送信用のデータのうち最も古いものが上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。　この関数内でＲＣＲｅｇｉｏｎ：：ＡｄｄＲｅｆｅｒｅｎｃｅ（）　が呼ばれ、指定した領域に対する参照カウンタをインクリメントします。指定した領域は、再度使用可能になるまで上書き、または変更しないでください。領域が使用可能か調べるには、ＲＣＲｅｇｉｏｎ：：ＮｕｍｂｅｒＯｆＲｅｆｅｒｅｎｃｅ（）を使用します。仮引数は、ｉｎｆｏ（オブザーバ情報。ＯｂｓｅｒｖｅｒＩｎｆｏ型は、例えばＯＳｕｂｊｅｃｔ：：ｂｅｇｉｎ（）などの呼び出しによって得られるＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ型が指しているデータにアクセスすることにより取得できます。）、ｒｅｇｉｏｎ（参照カウンタ付き共有メモリ領域へのポインタ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２１】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ，　ＲＣＲｅｇｉｏｎ＊　ｒｅｇｉｏｎ）　であり、この関数はＳｅｔＤａｔａ（＊ＦｉｎｄＯｂｓｅｒｖｅｒ（ｉｄ），　ｒｅｇｉｏｎ）と同様に動作します。すなわち、指定したオブザーバ用のバッファに、ｒｅｇｉｏｎ引数で指定される共有メモリ領域を設定します。オーバーフロー時には送信用のデータのうち最も古いものが上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。
この関数内でＲＣＲｅｇｉｏｎ：：ＡｄｄＲｅｆｅｒｅｎｃｅ（）　が呼ばれ、指定した領域に対する参照カウンタをインクリメントします。指定した領域は、再度使用可能になるまで上書きしないでください。領域が使用可能か調べるにはＲＣＲｅｇｉｏｎ：：ＮｕｍｂｅｒＯｆＲｅｆｅｒｅｎｃｅ（）を使用します。仮引数は、ｉｄ（Ｏｂｓｅｒｖｅｒ　ＩＤです。ｉｄがサブジェクトに対して無効な場合は、関数の結果や効果は不定になります。）、ｒｅｇｉｏｎ（参照カウンタ付き共有メモリ領域を指すポインタ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２２】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯＳｈｍＰｔｒＢａｓｅ＆　ｐ）　であり、すべてのオブザーバ用のバッファに、指定したポインタが指す共有メモリ領域を設定します。オーバーフロー時には、送信用のデータのうち最も古いものが上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。仮引数は、ｐ（参照カウンタ付き共有メモリ領域を指すポインタ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２３】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩｎｆｏ＆　ｉｎｆｏ，　ｃｏｎｓｔ　ＯＳｈｍＰｔｒＢａｓｅ＆　ｐ）であり、指定したオブザーバー用のバッファに、指定したポインタが指す共有メモリ領域を設定します。　この関数はＦｉｎｄＯｂｓｅｒｖｅｒ（）の呼び出しを省略できる分だけ、ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆，　ｃｏｎｓｔ　ＯＳｈｍＰｔｒＢａｓｅ＆　ｐ）　より効率的です。　オーバーフロー時には送信用のデータのうち最も古いものが上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。仮引数は、ｉｎｆｏ（オブザーバ情報。ＯｂｓｅｒｖｅｒＩｎｆｏ型は、例えばＯＳｕｂｊｅｃｔ：：ｂｅｇｉｎ（）などの呼び出しによって得られるＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ型が指しているデータにアクセスすることにより取得できます。）、ｐ（参照カウンタ付き共有メモリ領域を指すポインタ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２４】
・ＳｅｔＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＤａｔａ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ，　ｃｏｎｓｔ　ＯＳｈｍＰｔｒＢａｓｅ＆　ｐ）　であり、指定したオブザーバー用のバッファに、指定したポインタが指す共有メモリ領域を設定します。　オーバーフロー時には送信用のデータのうち最も古いものが上書きされます。オーバーフローを事前に知るにはＲｅｍａｉｎＢｕｆｆｅｒ（）を使用します。ここの関数は、ＳｅｔＤａｔａ（＊ＦｉｎｄＯｂｓｅｒｖｅｒ（ｉｄ），　ｐ）　と同様の動作をします。仮引数は、ｉｄ（Ｏｂｓｅｒｖｅｒ　ＩＤ。　ｉｄがサブジェクトに対して無効な場合は、この関数の結果または効果は不定です。）、ｒｅｇｉｏｎ（参照カウンタ付き共有メモリ領域を指すポインタ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２５】
・ＮｏｔｉｆｙＯｂｓｅｒｖｅｒ（）
構文は、ＯＳｔａｔｕｓ　　ＮｏｔｉｆｙＯｂｓｅｒｖｅｒ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩｎｆｏ＆　ｏｂｓｅｒｖｅｒ）　であり、指定したオブザーバに、バッファに保持されているデータを送信します。オブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態の場合はデータをすぐに送信します。オブザーバがＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態の場合はデータを削除します。オブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態でもＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態でもない場合はデータをバッファに保持しておき、ＡＳＳＥＲＴ−ＲＥＡＤＹ状態になり次第に送信します。仮引数は、ｏｂｓｅｒｖｅｒ（オブザーバ情報。ＯｂｓｅｒｖｅｒＩｎｆｏ型は、例えばＯＳｕｂｊｅｃｔ：：ｂｅｇｉｎ（）などの呼び出しによって得られるＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ型が指しているデータにアクセスすることにより取得できます。）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２６】
・ＮｏｔｉｆｙＯｂｓｅｒｖｅｒ（）
構文は、ＯＳｔａｔｕｓ　　ＮｏｔｉｆｙＯｂｓｅｒｖｅｒ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ）　であり、指定したオブザーバに、バッファに保持されているデータを送信します。オブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態の場合はデータをすぐに送信します。オブザーバがＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態の場合はデータを削除します。オブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態でもＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態でもない場合はデータをバッファに保持しておき、ＡＳＳＥＲＴ−ＲＥＡＤＹ状態になり次第に送信します。ＮｏｔｉｆｙＯｂｓｅｒｖｅｒ（＊ＦｉｎｄＯｂｓｅｒｖｅｒ（ｉｄ））と同じ処理を行うため、ＦｉｎｄＯｂｓｅｒｖｅｒ（）のオーバーヘッドを含みます。仮引数は、ｉｄ（ＯｂｓｅｒｖｅｒＩＤ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２７】
・ＮｏｔｉｆｙＯｂｓｅｒｖｅｒｓ（）
構文は、ＯＳｔａｔｕｓ　　ＮｏｔｉｆｙＯｂｓｅｒｖｅｒｓ（ｖｏｉｄ）　であり、すべてのオブザーバに、バッファに保持されているデータを送信します。オブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態の場合はデータをすぐに送信します。オブザーバがＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態の場合はデータを捨てます。オブザーバーがＡＳＳＥＲＴ−ＲＥＡＤＹ状態でもＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態でもない場合はデータをバッファに保持しておき、ＡＳＳＥＲＴ−ＲＥＡＤＹ状態になり次第に送信します。仮引数はない。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１２８】
・ＲｅｍａｉｎＢｕｆｆｅｒ（）
構文は、ｓｉｚｅ＿ｔ　　ＲｅｍａｉｎＢｕｆｆｅｒ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩｎｆｏ＆　ｏｂｓｅｒｖｅｒ）　ｃｏｎｓｔ　であり、指定されたオブザーバ用のバッファの残り数を返します。ＳｅｔＤａｔａ（）を戻り値より多い回数呼び出すと、バッファに保持されている古いデータから消去されます。仮引数は、ｏｂｓｅｒｖｅｒ（オブザーバ情報。ＯｂｓｅｒｖｅｒＩｎｆｏ型は、例えばＯＳｕｂｊｅｃｔ：：ｂｅｇｉｎ（）などの呼び出しによって得られるＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ型が指しているデータにアクセスすることにより取得できます。）である。戻り値は、バッファの残り数である。
【０１２９】
・ＲｅｍａｉｎＢｕｆｆｅｒ（）
構文は、ｓｉｚｅ＿ｔ　　ＲｅｍａｉｎＢｕｆｆｅｒ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ）　ｃｏｎｓｔ　であり、指定されたオブザーバ用のバッファの残り数を返します。ＳｅｔＤａｔａ（）を戻り値より多い回数呼び出すと、バッファに保持されている古いデータから消去されます。この関数はＲｅｍａｉｎＢｕｆｆｅｒ（＊　ＦｉｎｄＯｂｓｅｒｖｅｒ（ｉｄ））と同じ動作をします。仮引数は、ｉｄ（ｏｂｓｅｒｖｅｒ　ＩＤ）であり、戻り値は、バッファの残り数である。
【０１３０】
・ＲｅｍａｉｎＢｕｆｆｅｒ（）
構文は、ｓｉｚｅ＿ｔ　　ＲｅｍａｉｎＢｕｆｆｅｒ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、オブザーバ用のバッファの残り数を返します。ＳｅｔＤａｔａ（）を戻り値より多い回数呼び出すと、バッファに保持されている古いデータから消去されます。仮引数はない。戻り値は、バッファの残り数である。
【０１３１】
・ＣｌｅａｒＢｕｆｆｅｒ（）
構文は、ＯＳｔａｔｕｓ　ＣｌｅａｒＢｕｆｆｅｒ（ｖｏｉｄ）　であり、すべてのオブザーバの送信バッファをクリアします。仮引数はない。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１３２】
・ＣｌｅａｒＢｕｆｆｅｒ（）
構文は、ＯＳｔａｔｕｓ　ＣｌｅａｒＢｕｆｆｅｒ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩｎｆｏ＆　ｉｎｆｏ）　であり、指定されたオブザーバ用の送信バッファをクリアします。仮引数は、ｉｎｆｏ（オブザーバ情報）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１３３】
・ＣｌｅａｒＢｕｆｆｅｒ（）
構文は、ＯＳｔａｔｕｓ　ＣｌｅａｒＢｕｆｆｅｒ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ）　であり、指定されたオブザーバ用の送信バッファをクリアします。ＣｌｅａｒＢｕｆｆｅｒ（＊ＦｉｎｄＯｂｓｅｒｖｅｒ（ｉｄ））　と同じ動作をします。仮引数は、ｉｄ（オブザーバＩＤ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１３４】
・ＮｕｍｂｅｒＯｆＯｂｓｅｒｖｅｒｓ（）
構文は、ｉｎｔ　　ＮｕｍｂｅｒＯｆＯｂｓｅｒｖｅｒｓ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、サブジェクトに接続しているオブザーバ数を返します。仮引数はない。戻り値は、サブジェクトに接続しているオブザーバ数である。
【０１３５】
・ｂｅｇｉｎ（）
構文は、ＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ　　ｂｅｇｉｎ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、サブジェクトに接続しているオブザーバのリストの中で、最初のオブザーバを指すイテレータ（反復子）を返します。仮引数はない。戻り値は、最初のオブザーバを指すイテレータである。
【０１３６】
・ｅｎｄ（）
構文は、ＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ　　ｅｎｄ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、サブジェクトに接続しているオブザーバのリストの中で、最後のオブザーバの次を指す無効なイテレータを返します。仮引数はない。戻り値は、最後のオブザーバの次を指す無効なイテレータである。
【０１３７】
・ＦｉｎｄＯｂｓｅｒｖｅｒ（）
構文は、ＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ　　ＦｉｎｄＯｂｓｅｒｖｅｒ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ）　ｃｏｎｓｔ　であり、ｉｄで指定したオブザーバを指すイテレータを返します。ｉｄを持つオブザーバが見つからない場合は、無効なイテレータを返します。仮引数はない。戻り値は、指定したオブザーバを指すイテレータである。
【０１３８】
・ＩｓＡｌｌＲｅａｄｙ（）
構文は、ｉｎｔ　ＩｓＡｌｌＲｅａｄｙ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、すべてのオブザーバが、ＡＳＳＥＲＴ−ＲＥＡＤＹ状態またはＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態のどちらであるかを調べます。仮引数はない。戻り値が０以外であれば、すべてのオブザーバーはＡＳＳＥＲＴ−ＲＥＡＤＹ状態またはＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態のどちらかを必ず保持しており、かつ少なくとも１つのオブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態です。この状態でＮｏｔｉｆｙＯｂｓｅｒｖｅｒ（）を実行すると、メッセージが必要なすべてのオブザーバに対して、ただちにメッセージが送信されます。また、０であれば、ＡＳＳＥＲＴ−ＲＥＡＤＹ状態でもＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態でもないオブザーバが少なくと１つあるか、またはすべてがＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態です。
【０１３９】
・ＩｓＡｎｙＲｅａｄｙ（）
構文は、ｉｎｔ　ＩｓＡｎｙＲｅａｄｙ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、ＡＳＳＥＲＴ−ＲＥＡＤＹ状態のオブザーバが存在するかどうかを調べます。仮引数はない。戻り値が０以外であれば、ＡＳＳＥＲＴ−ＲＥＡＤＹ状態のオブザーバが少なくとも１つ存在します。また、０であればＡＳＳＥＲＴ−ＲＥＡＤＹ状態のオブザーバが存在しません。
【０１４０】
・ＩｓＲｅａｄｙ（）
構文は、ｉｎｔ　　ＩｓＲｅａｄｙ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩｎｆｏ＆　ｉｎｆｏ）　ｃｏｎｓｔ　であり、指定したオブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態かどうかを調べます。仮引数は、ｉｎｆｏ（オブザーバ情報。ＯｂｓｅｒｖｅｒＩｎｆｏ型は、例えばＯＳｕｂｊｅｃｔ：：ｂｅｇｉｎ（）などの呼び出しによって得られるＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ型が指しているデータにアクセスすることにより取得できます。）である。戻り値が０以外であれば、指定したオブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態である。０であれば、指定したオブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態でない。
【０１４１】
・ＩｓＲｅａｄｙ（）
構文は、ｉｎｔ　　ＩｓＲｅａｄｙ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ）　ｃｏｎｓｔ　であり、指定したオブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態かどうかを調べます。ＩｓＲｅａｄｙ　（＊ＦｉｎｄＯｂｓｅｒｖｅｒ（ｉｄ））と同じ動作をします。仮引数は、ｉｄ（Ｏｂｓｅｒｖｅｒ　ＩＤ）である。戻り値が０以外であれば、指定したオブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態であり、０であれば、指定したオブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態でない。
【０１４２】
・ＲｅａｄｙＳｔａｔｕｓ（）
構文は、ｉｎｔ　　ＲｅａｄｙＳｔａｔｕｓ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩｎｆｏ＆　ｉｎｆｏ）　ｃｏｎｓｔ　であり、指定したオブザーバの状態を返します。仮引数は、ｉｎｆｏ（オブザーバ情報。ＯｂｓｅｒｖｅｒＩｎｆｏ型は、例えばＯＳｕｂｊｅｃｔ：：ｂｅｇｉｎ（）などの呼び出しによって得られるＯｂｓｅｒｖｅｒＣｏｎｓｔＩｔｅｒａｔｏｒ型が指しているデータにアクセスすることにより取得できます。）である。戻り値が正数であれば、サブジェクトが指定したオブザーバからＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを受信した（ＡＳＳＥＲＴ−ＲＥＡＤＹ状態）ことを示し、０であれば、サブジェクトが指定したオブザーバがメッセージをまだ送信していないので状態が不明であることを示す。また、負数であれば、サブジェクトが指定したオブザーバからＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを受信した（ＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態）ことを示す。
【０１４３】
・ＲｅａｄｙＳｔａｔｕｓ（）
構文は、ｉｎｔ　　ＲｅａｄｙＳｔａｔｕｓ（ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　ｉｄ）　ｃｏｎｓｔ　であり、指定したオブザーバの状態を返します。ＲｅａｄｙＳｔａｔｕｓ（＊ＦｉｎｄＯｂｓｅｒｖｅｒ（ｉｄ））と同じ動作をします。仮引数は、ｉｄ（Ｏｂｓｅｒｖｅｒ　ＩＤ）である。戻り値が正数であれば、サブジェクトが指定したオブザーバからＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを受信した（ＡＳＳＥＲＴ−ＲＥＡＤＹ状態）ことを示し、０であれば、サブジェクトが指定オブザーバがメッセージをまだ送信していないので状態が不明であることを示し、負数であれば、サブジェクトが指定したオブザーバからＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを受信した（ＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ状態）ことを示す。
【０１４４】
・ＣｏｎｔｒｏｌＨａｎｄｌｅｒ（）
構文は、ｖｏｉｄ　　ＣｏｎｔｒｏｌＨａｎｄｌｅｒ（ｃｏｎｓｔ　ＯＣｏｎｔｒｏｌＭｅｓｓａｇｅ＆　ｍｓｇ，　ＯＳｔａｔｕｓ　ｓｔａｔｕｓ＝ｏＳＵＣＣＥＳＳ）　であり、受信したＯＣｏｎｔｒｏｌＭｅｓｓａｇｅに応じてサブジェクトの設定を行います。オブジェクトの接続フェーズに呼ばれます。仮引数は、ｍｓｇ（オブザーバから受信したＯＣｏｎｔｒｏｌＭｅｓｓａｇｅ）、ｓｔａｔｕｓ（ユーザー定義の状態です。）であり、デフォルト値はｏＳＵＣＣＥＳＳを指定します。ｏＳＵＣＣＥＳＳでない場合に接続は拒否されます。例えば、ユーザー定義のフックメソッドで初期化やリソース割り当てに失敗した場合は、ｏＦＡＩＬを指定してください。戻り値はない。
【０１４５】
・ＲｅａｄｙＨａｎｄｌｅｒ（）
構文は、ｖｏｉｄ　　ＲｅａｄｙＨａｎｄｌｅｒ（ｃｏｎｓｔ　ＯＲｅａｄｙＭｅｓｓａｇｅ＆　ｍｓｇ）　であり、ＯＲｅａｄｙＭｅｓｓａｇｅを受信して処理します。仮引数は、ｍｓｇ（オブザーバから受信したＯＲｅａｄｙＭｅｓｓａｇｅ）であり、戻り値はない。
【０１４６】
２．２　ＯＲｅａｄｙＥｖｅｎｔクラス
ＯＲｅａｄｙＥｖｅｎｔクラスには、以下のメンバー関数があります。
・ＳｂｊＩｎｄｅｘ（）
構文は、ｉｎｔ　　ＳｂｊＩｎｄｅｘ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、ＯＲｅａｄｙＥｖｅｎｔを受け取るサブジェクトのインデックスを返します。仮引数はない。戻り値は、サブジェクトのインデックスである。
【０１４７】
・ＳｅｎｄｅｒＩＤ（）
構文は、ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　　ＳｅｎｄｅｒＩＤ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、ＯＲｅａｄｙＥｖｅｎｔを送信したオブザーバのＯｂｓｅｒｖｅｒＩＤを返します。仮引数はない。戻り値は、ＯｂｓｅｒｖｅｒＩＤである。
【０１４８】
・ＩｓＡｓｓｅｒｔ（）
構文は、ｂｏｏｌ　　ＩｓＡｓｓｅｒｔ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、ＯＲｅａｄｙＭｅｓｓａｇｅがＡＳＳＥＲＴ−ＲＥＡＤＹメッセージか調べます。仮引数はない。戻り値には、ｔｒｕｅ（ＡＳＳＥＲＴ−ＲＥＡＤＹメッセージ）、ｆａｌｓｅ（上記以外）がある。
【０１４９】
・ＩｓＤｅａｓｓｅｒｔ（）
構文は、ｂｏｏｌ　　Ｉｓ　Ｄｅａｓｓｅｒｔ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、ＯＲｅａｄｙＭｅｓｓａｇｅがＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージか調べます。仮引数はない。戻り値には、ｔｒｕｅ（ＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージ）、ｆａｌｓｅ（上記以外）がある。
【０１５０】
２．３　ＯＯｂｓｅｒｖｅｒクラス
ＯＯｂｓｅｒｖｅｒクラスには、以下のメンバー関数があります。
・ＯＯｂｓｅｒｖｅｒ（）
構文は、ＯＯｂｓｅｒｖｅｒ（ｖｏｉｄ）　であり、これはコンストラクタです。仮引数及び戻り値はない。
・￣ＯＯｂｓｅｒｖｅｒ（）
構文は、￣ＯＯｂｓｅｒｖｅｒ（）　であり、これはデストラクタです。仮引数及び戻り値はない。
【０１５１】
・ＳｅｔＮｏｔｉｆｙＥｎｔｒｙ（）
構文は、ＯＳｔａｔｕｓ　　ＳｅｔＮｏｔｉｆｙＥｎｔｒｙ（ｃｏｎｓｔ　ＯＳｅｒｖｉｃｅＥｎｔｒｙ＆　ｅｎｔｒｙ）　であり、オブザーバーがＮＯＴＩＦＹメッセージを受信するためのエントリを設定します。　この設定はＤｏＩｎｉｔ（）内で行います。仮引数は、ｅｎｔｒｙ（ＮＯＴＩＦＹメッセージを受信するためのエントリ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１５２】
・ＧｅｔＩＤ（）
構文は、ｃｏｎｓｔ　ＯｂｓｅｒｖｅｒＩＤ＆　　ＧｅｔＩＤ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、オブザーバのＯｂｓｅｒｖｅｒ　ＩＤを返します。ＯｂｓｅｒｖｅｒＩＤはオブザーバごとに固有の値をとります。仮引数はない。戻り値は、各オブザーバに固有の値である。
【０１５３】
・ＳｅｔＢｕｆＣｔｒｌＰａｒａｍ（）
構文は、ｖｏｉｄ　　ＳｅｔＢｕｆＣｔｒｌＰａｒａｍ（ｓｉｚｅ＿ｔ　ｓｋｉｐ，　ｓｉｚｅ＿ｔ　ｍｉｎ，　ｓｉｚｅ＿ｔ　ｍａｘ）　であり、サブジェクトが保持するオブザーバ用のバッファに必要な制御パラメーターを設定します。この設定はＤｏＩｎｉｔ（）内で行います。
仮引数は、ｓｋｉｐ（受信するデータ数を減少させるために、データスキップ（サンプリング間隔）を指定します。デフォルト値は０で、サブサンプリングなしです。）、ｍｉｎ（サブジェクトがＮＯＴＩＦＹメッセージをオブザーバへ送信するときのデータの最小数を指定します。デフォルト値は１に設定されます。このパラメーターを適切に設定することで、データを損失しないでデータの受信頻度を減らすことができます。）、ｍａｘ（オブザーバがＡＳＳＥＲＴ−ＲＥＡＤＹ状態になるまでに、サブジェクトがバッファに保持しておくべき送信用のバッファサイズの最大値を指定します。このパラメーターはｍｉｎ以上に設定する必要があります。デフォルト値は１で、その場合は最後の送信用のデータだけがバッファに保持されます。）である。戻り値はない。
【０１５４】
・ＳｅｔＳｋｉｐ（）
構文は、ｖｏｉｄ　　ＳｅｔＳｋｉｐ（ｓｉｚｅ＿ｔ　ｓｋｉｐ）　であり、サブジェクトの保持するオブザーバ用のバッファに必要な制御パラメーターを設定します。この設定はＤｏＩｎｉｔ時に行います。この関数は過去との互換をとるためだけいに用意され、ＳｅｔＢｕｆＣｔｒＰａｒａｍ（ｓｋｉｐ，１，１）と同じ動作をします。仮引数は、ｓｋｉｐ（受信するデータ数を減少させるために、データスキップ（サンプリング間隔）を指定します。　デフォルト値は０で、サブサンプリングなしです。）である。戻り値はない。
【０１５５】
・ＡｓｓｅｒｔＲｅａｄｙ（）
構文は、ＯＳｔａｔｕｓ　　ＡｓｓｅｒｔＲｅａｄｙ（ｖｏｉｄ）　であり、接続しているすべてのサブジェクトにＡＳＳＥＲＴ−ＲＥＡＤＹを送信します。仮引数はない。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１５６】
・ＡｓｓｅｒｔＲｅａｄｙ（）
構文は、ＯＳｔａｔｕｓ　　ＡｓｓｅｒｔＲｅａｄｙ（ｃｏｎｓｔ　ＳｕｂｊｅｃｔＩＤ＆　ｉｄ）　であり、ＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを指定したサブジェクトのみに送信します。仮引数は、ｉｄ（メッセージの送信先サブジェクトのＩＤ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）である。
【０１５７】
・ＡｓｓｅｒｔＲｅａｄｙ（）
構文は、ＯＳｔａｔｕｓ　ＡｓｓｅｒｔＲｅａｄｙ（ｃｏｎｓｔ　ＳｕｂｊｅｃｔＩｎｆｏ＆　ｉｎｆｏ）　であり、ＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを指定したサブジェクトのみに送信します。仮引数は、ｉｎｆｏ（メッセージ送信先のサブジェクトのＩＤ情報）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１５８】
・ＤｅａｓｓｅｒｔＲｅａｄｙ（）
構文は、ＯＳｔａｔｕｓ　　ＤｅａｓｓｅｒｔＲｅａｄｙ（ｖｏｉｄ）　であり、接続しているすべてのサブジェクトにＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを送信します。仮引数はない。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１５９】
・ＤｅａｓｓｅｒｔＲｅａｄｙ（）
構文は、ＯＳｔａｔｕｓ　　ＤｅａｓｓｅｒｔＲｅａｄｙ（ｃｏｎｓｔ　ＳｕｂｊｅｃｔＩＤ＆　ｉｄ）　であり、ＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを指定したサブジェクトのみに送信します。仮引数は、ｉｄ（メッセージの送信先サブジェクトのＩＤ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１６０】
・ＤｅａｓｓｅｒｔＲｅａｄｙ（）
構文は、ＯＳｔａｔｕｓ　ＤｅａｓｓｅｒｔＲｅａｄｙ（ｃｏｎｓｔ　ＳｕｂｊｅｃｔＩｎｆｏ＆　ｉｎｆｏ）　であり、ＤＥＡＳＳＥＲＴ−ＲＥＡＤＹ　メッセージを指定したサブジェクトのみに送信します。仮引数は、ｉｎｆｏ（メッセージ送信先のサブジェクトのＩＤ情報）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１６１】
・ＮｕｍｂｅｒＯｆＳｕｂｊｅｃｔｓ（）
構文は、ｉｎｔ　　ＮｕｍｂｅｒＯｆＳｕｂｊｅｃｔｓ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、オブザーバに接続しているサブジェクトの数を返します。仮引数はない。戻り値は、オブザーバに接続しているサブジェクトの数である。
【０１６２】
・ｂｅｇｉｎ（）
構文は、ＳｕｂｊｅｃｔＣｏｎｓｔＩｔｅｒａｔｏｒ　　ｂｅｇｉｎ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、オブザーバに接続しているサブジェクトのリストの中で、最初のサブジェクトを指すイテレータを返します。仮引数はない。戻り値は、最初のサブジェクトを指すイテレータである。
【０１６３】
・ｅｎｄ（）
構文は、ＳｕｂｊｅｃｔＣｏｎｓｔＩｔｅｒａｔｏｒ　　ｅｎｄ（ｖｏｉｄ）　ｃｏｎｓｔ；　であり、オブザーバに接続しているサブジェクトのリストの中で、最後のサブジェクトの次を指す無効なイテレータを返します。仮引数はない。戻り値は、最後のサブジェクトの次を指す無効のイテレータである。
【０１６４】
・ＣｏｎｎｅｃｔＨａｎｄｌｅｒ（）
構文は、ｖｏｉｄ　　ＣｏｎｎｅｃｔＨａｎｄｌｅｒ（ｃｏｎｓｔ　ＯＣｏｎｎｅｃｔＭｅｓｓａｇｅ＆　ｍｓｇ，　ＯＳｔａｔｕｓ　ｓｔａｔｕｓ＝ｏＳＵＣＣＥＳＳ）　であり、受信したＯＣｏｎｎｅｃｔＭｅｓｓａｇｅに応じてオブザーバを設定します。オブジェクトの接続フェースに呼ばれます。仮引数は、ｍｓｇ（ＯＳｅｒｖｉｃｅＭａｎａｇｅｒから通知されるＯＣｏｎｎｅｃｔＭｅｓｓａｇｅ）、ｓｔａｔｕｓ（ユーザ定義の初期化やリソース確保用の関数の状態を示します。）である。デフォルト値はｏＳＵＣＣＥＳＳです。ｏＳＵＣＣＥＳＳ以外では接続が拒否されます。戻り値はない。
【０１６５】
・ＮｏｔｉｆｙＨａｎｄｌｅｒ（）
構文は、ｖｏｉｄ　　ＮｏｔｉｆｙＨａｎｄｌｅｒ（ｃｏｎｓｔ　ＯＮｏｔｉｆｙＭｅｓｓａｇｅ＆　ｍｓｇ，　ＯＮｏｔｉｆｙＥｖｅｎｔ＊　ｐＥｖｅｎｔ）　であり、受信したＯＮｏｔｉｆｙＭｅｓｓａｇｅに応じてＯＮｏｔｉｆｙＥｖｅｎｔの設定と初期化を行います。この関数はｓｔｕｂ．ｃｃで自動的に呼ばれます。仮引数は、ｍｓｇ（サブジェクトから受信するＯＮｏｔｉｆｙＭｅｓｓａｇｅ）、ｐＥｖｅｎｔ（受信したＯＮｏｔｉｆｙＭｅｓｓａｇｅに対応するＯＮｏｔｉｆｙＥｖｅｎｔ型データへのポインタ）である。戻り値はない。
【０１６６】
２．４　ＯＮｏｔｉｆｙＥｖｅｎｔクラス
ＯＮｏｔｉｆｙＥｖｅｎｔクラスには、以下のメンバー関数があります。
・ＯｂｓＩｎｄｅｘ（）
構文は、ｉｎｔ　　ＯｂｓＩｎｄｅｘ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、ＯＮｏｔｉｆｙＥｖｅｎｔの送信先のオブザーバのインデックスを返します。仮引数はない。戻り値は、送信先オブザーバのインデックスである。
【０１６７】
・ＳｅｎｄｅｒＩＤ（）
構文は、ｃｏｎｓｔ　ＳｕｂｊｅｃｔＩｎｆｏ＆　ＳｅｎｄｅｒＩＤ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、ＯＮｏｔｉｆｙＥｖｅｎｔを送信したサブジェクトのＩＤ情報を返します。仮引数はない。戻り値は、送信元サブジェクトのＩＤ情報である。
【０１６８】
・ＮｕｍＯｆＤａｔａ（）
構文は、ｉｎｔ　　ＮｕｍＯｆＤａｔａ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、受信したデータ数を返します。仮引数はない。戻り値は、受信したデータ数である。
【０１６９】
・ＮｕｍＯｆＮｏｔｉｆｙ（）
構文は、ｉｎｔ　　ＮｕｍＯｆＮｏｔｉｆｙ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、送信されたデータに対して、ＮｏｔｉｆｙＯｂｓｅｒｖｅｒ（）を実行した回数を返します。仮引数はない。戻り値は、サブジェクトがＮｏｔｉｆｙＯｂｓｅｒｖｅｒ（）を実行した回数である。
【０１７０】
・Ｄａｔａ（）
構文は、ｃｏｎｓｔ　ｖｏｉｄ＊　　Ｄａｔａ（ｉｎｔ　ｉ）　ｃｏｎｓｔ　であり、受信したデータのうちでｉ番目のデータのアドレスを返します。このポインタは、サブジェクトにＡＳＳＥＲＴ−ＲＥＡＤＹまたはＤＥＡＳＳＥＲＴ−ＲＥＡＤＹメッセージを送信すると、ただちに無効になります。仮引数は、ｉ（処理したいデータのインデックス）である。戻り値は、ｉ番目のデータの先頭アドレスである。
【０１７１】
・Ｄａｔａ（）
構文は、ｃｏｎｓｔ　ｖｏｉｄ＊＊　　Ｄａｔａ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、受信したデータを指すポインタの配列を返します。仮引数はない。戻り値は、ポインタの配列である。
【０１７２】
・ＲＣＤａｔａ（）
構文は、ＲＣＲｅｇｉｏｎ＊　　ＲＣＤａｔａ（ｉｎｔ　ｉ）　ｃｏｎｓｔ　であり、受信したデータのうちで、ｉ番目のデータに対応する参照カウンタ付き共有メモリ領域へのポインタを返します。仮引数は、ｉ　（処理したいデータのインデックス）である。戻り値は、ｉ番目のデータに対応する参照カウンタ付き共有メモリ領域へのポインタである。
【０１７３】
２．５　ＲＣＲｅｇｉｏｎクラス
このクラスは共有メモリ領域へのポインタを保持し、メモリ領域の参照カウンタを制御します。ＲＣＲｅｇｉｏｎクラスには、以下のメンバー関数があります。このクラスをスタック上に作成することはできません。
・ＲＣＲｅｇｉｏｎ（）
構文は、ＲＣＲｅｇｉｏｎ（ｖｏｉｄ）　であり、コンストラクタです。ＮＵＬＬを指すインスタンスを生成します。仮引数及び戻り値はない。
【０１７４】
・ＲＣＲｅｇｉｏｎ（）
構文は、ＲＣＲｅｇｉｏｎ（ｓｉｚｅ＿ｔ　ｓｉｚｅ）　であり、指定したサイズの共有メモリ領域を確保して、このメモリ領域を指すインスタンスを生成します。仮引数は、ｓｉｚｅ（割り当てる共有メモリのサイズ（単位はバイト））であり、戻り値はない。
【０１７５】
・ＲＣＲｅｇｉｏｎ（）
構文は、ＲＣＲｅｇｉｏｎ（ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ　ｍｅｍＩＤ，　ｓｉｚｅ＿ｔ　ｏｆｆｓｅｔ，　ｖｏｉｄ＊　ｂａｓｅＡｄｄｒ＝ＮＵＬＬ，　ｓｉｚｅ＿ｔ　ｓｉｚｅ　＝　０）　であり、指定したメモリ領域を指すインスタンスを作成します。メモリの割り当ては行わないので、事前に外部で対応するメモリ領域を確保してください。仮引数は、ｍｅｍＩＤ（データを保持する共有メモリ領域のＩＤ）、ｏｆｆｓｅｔ（ｍｅｍＩＤで指定される共有メモリ領域の基底アドレスからのｂａｓｅＡｄｄｒのオフセット）、ｂａｓｅＡｄｄｒ（データの基底アドレス（先頭アドレス））、ｓｉｚｅ（データのサイズ）であり、戻り値はない。
【０１７６】
・￣ＲＣＲｅｇｉｏｎ（）
構文は、￣ＲＣＲｅｇｉｏｎ（）　であり、この関数を直接呼ぶことはできません。ＲＣＲｅｇｉｏｎはローカルスタック上ではなくヒープ上に配置します。領域の破壊もできません。その理由は、この領域が他から参照されている可能性があるためです。デストラクタを呼び出す代わりにできる唯一のことはＲＣＲｅｇｉｏｎ：：ＲｅｍｏｖｅＲｅｆｅｒｅｎｃｅ（）を呼びだすことです。仮引数及び戻り値はない。
【０１７７】
・ＡｄｄＲｅｆｅｒｅｎｃｅ（）
構文は、ｖｏｉｄ　　ＡｄｄＲｅｆｅｒｅｎｃｅ（ｖｏｉｄ）　であり、参照カウンタ付き共有メモリ領域の参照カウンタをインクリメントします。仮引数及び戻り値はない。
【０１７８】
・ＲｅｍｏｖｅＲｅｆｅｒｅｎｃｅ（）
構文は、ｖｏｉｄ　　ＲｅｍｏｖｅＲｅｆｅｒｅｎｃｅ（ｖｏｉｄ）　であり、参照カウンタ付き共有メモリ領域の参照カウンタをデクリメントします。領域へのすべての参照がなくなった場合、領域は自動的に破壊されます。自分が領域の所有者である場合、共有メモリ領域が削除されます。仮引数及び戻り値はない。
【０１７９】
・ＮｕｍｂｅｒＯｆＲｅｆｅｒｅｎｃｅ（）
構文は、ｉｎｔ　　ＮｕｍｂｅｒＯｆＲｅｆｅｒｅｎｃｅ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、参照カウンタの数を返します。戻り値が１の場合は、自分しか領域を参照していないので、領域の所有者であればデータを書き変えられます。戻り値が１より大きい場合は、読み出し以外の操作はしないでください。戻り値が０の場合は、領域は破壊されているのでアクセスしないでください。仮引数はない。戻り値は、参照カウンタの数である。
【０１８０】
・Ｂａｓｅ（）
構文は、ｃｈａｒ＊　　Ｂａｓｅ（ｖｏｉｄ）　ｃｏｎｓｔ　であり。共有メモリ領域に保持するデータの基底アドレスを返します。仮引数はない。戻り値は、共有メモリ領域に保持するデータの基底アドレスである。
【０１８１】
・Ｓｉｚｅ（）
構文は、ｓｉｚｅ＿ｔ　　Ｓｉｚｅ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、共有メモリ領域に保持するデータのサイズを返します。仮引数はない。戻り値は、共有メモリ領域に保持するデータのサイズである。
【０１８２】
・ＭｅｍＩＤ（）
構文は、ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ　　ＭｅｍＩＤ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、共有メモリ領域のＩＤを返します。仮引数はない。戻り値は、共有メモリ領域のＩＤである。
【０１８３】
・Ｏｆｆｓｅｔ（）
構文は、ｓｉｚｅ＿ｔ　　Ｏｆｆｓｅｔ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、データ領域のオフセットを返します。オフセットは、共有メモリ領域のＩＤによって取得した基底アドレスからデータの先頭アドレスまでのバイト数です。仮引数はない。戻り値は、データ領域のオフセットである。
【０１８４】
・ＳｅｔＳｉｚｅ（）
構文は、ｖｏｉｄ　　ＳｅｔＳｉｚｅ（ｓｉｚｅ＿ｔ　ｓｉｚｅ）　であり、ＲＣＲｅｇｉｏｎ：：Ｓｉｚｅ（）によって返される値を仮引数の値に設定します。この関数はユーザー独自のメモリ割り当て処理などで最適化を行うときに使用します。仮引数は、ｓｉｚｅ（ＲＣＲｅｇｉｏｎ：：Ｓｉｚｅ（）によって返されるのと同じ値）である。戻り値はない。
【０１８５】
・ＲｅｓｅｒｖｅＳｈａｒｅｄＭｅｍｏｒｙ（）
構文は、ＯＳｔａｔｕｓ　　ＲｅｓｅｒｖｅＳｈａｒｅｄＭｅｍｏｒｙ（ｓｉｚｅ＿ｔ　ｓｉｚｅ）　であり、この関数はＲＣＲｅｇｉｏｎ　クラスの静的メンバー関数です。この関数は、実行時の予期せぬタイミングでのメモリ割り当てを回避するためのものです。この関数は共有メモリ領域の少なくともｓｉｚｅバイトがｌｉｂＯｂｊｅｃｔＣｏｍｍ　ライブラリ用に使用できることを保証します。関数を呼び出した時点で充分な共有メモリ領域がない場合は、必要なメモリが割り当てられます。割り当てられた共有メモリ領域は、ＳｅｔＤａｔａ（ｐｔｒ，　ｓｉｚｅ）を実行するときに使用されます。ＳｅｔＤａｔａ（ｒｅｇｉｏｎ）を使用するときは、この関数を呼ぶ必要はありません。その理由は、ＳｅｔＤａｔａ（ｒｅｇｉｏｎ）関数は、ＲＣＲｅｇｉｏｎクラスの生成タイミングを自由に制御できるからです。仮引数は、ｓｉｚｅ（ＳｅｔＤａｔａ（ｐｔｒ，　ｓｉｚｅ）を呼ぶときに使用されるメモリ領域として、ここで予約するサイズです。）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、上記以外（失敗）がある。
【０１８６】
２．６　ＯＳｈｍＰｔｒＢａｓｅクラス
共有メモリ領域を表す基底クラスです。このクラスはＲＣＲｅｇｉｏｎのカプセルクラスで、自動リファレンスカウンティングを行います。ＯＳｈｍＰｔｒＢａｓｅクラスには、以下のメンバー関数があります。
・ＯＳｈｍＰｔｒＢａｓｅ（）
構文は、ＯＳｈｍＰｔｒＢａｓｅ（ｖｏｉｄ）　であり、無効なＯＳｈｍＰｔｒＢａｓｅを生成します。仮引数及び戻り値はない。
【０１８７】
・ＯＳｈｍＰｔｒＢａｓｅ（）
構文は、ＯＳｈｍＰｔｒＢａｓｅ（ｃｏｎｓｔ　ＯＳｈｍＰｔｒＢａｓｅ＆　ｐ）　であり、指定したＯＳｈｍＰｔｒＢａｓｅと同じ領域を参照するＯＳｈｍＰｔｒＢａｓｅを生成します。仮引数は、ｐ（コピー元のＯＳｈｍＰｔｒＢａｓｅ）である。戻り値はない。
【０１８８】
・ＯＳｈｍＰｔｒＢａｓｅ（）
構文は、ＯＳｈｍＰｔｒＢａｓｅ（ＲＣＲｅｇｉｏｎ＊　ｒｅｇｉｏｎ）　であり、指定した領域を参照するＯＳｈｍＰｔｒＢａｓｅを生成します。仮引数は、ｒｅｇｉｏｎ（参照カウンタ付き共有メモリ領域）である。戻り値はない。
【０１８９】
・￣ＯＳｈｍＰｔｒＢａｓｅ（）
構文は、￣ＯＳｈｍＰｔｒＢａｓｅ（）　であり、ＯＳｈｍＰｔｒＢａｓｅを破壊して、参照カウンタをデクリメントします。仮引数及び戻り値はない。
【０１９０】
・ｏｐｅｒａｔｏｒ＝（）
構文は、ＯＳｈｍＰｔｒＢａｓｅ＆　　ｏｐｅｒａｔｏｒ＝（ｃｏｎｓｔ　ＯＳｈｍＰｔｒＢａｓｅ＆　ｐ）　であり、指定したＯＳｈｍＰｔｒＢａｓｅが参照する領域と同じ領域を参照するように、参照先を変更します。仮引数は、ｐ（ＯＳｈｍＰｔｒＢａｓｅのコピー元）であり、戻り値は、＊ｔｈｉｓである。
【０１９１】
・Ｄｅａｌｌｏｃａｔｅ（）
構文は、ｖｏｉｄ　　Ｄｅａｌｌｏｃａｔｅ（ｖｏｉｄ）　であり、参照カウンタをデクリメントして、ＯＳｈｍＰｔｒＢａｓｅを無効化します。仮引数及び戻り値はない。
【０１９２】
・Ｂａｓｅ（）
構文は、ｃｈａｒ＊　　Ｂａｓｅ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、共有メモリ領域が保持するデータの基底アドレスを返します。仮引数はない。戻り値は、共有メモリ領域が保持するデータの基底アドレスである。
【０１９３】
・Ｓｉｚｅ（）
構文は、ｓｉｚｅ＿ｔ　　Ｓｉｚｅ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、共有メモリ領域が保持するデータのサイズを返します。仮引数はない。戻り値は、共有メモリ領域が保持するデータのサイズである。
【０１９４】
・ＭｅｍＩＤ（）
構文は、ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ　　ＭｅｍＩＤ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、共有メモリ領域のＩＤを返します。仮引数はない。戻り値は、共有メモリ領域のＩＤである。
【０１９５】
・Ｏｆｆｓｅｔ（）
構文は、ｓｉｚｅ＿ｔ　　Ｏｆｆｓｅｔ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、データ領域のオフセットを返します。オフセットとは、対応する共有メモリ領域のＩＤによって取得した基底アドレスからデータの先頭アドレスまでのバイト数です。仮引数はない。戻り値は、データ領域のオフセットである。
【０１９６】
・ＲＣＲＰｔｒ（）
構文は、ＲＣＲｅｇｉｏｎ＊　　ＲＣＲＰｔｒ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、対応するＲＣＲｅｇｉｏｎへのポインタを返します。仮引数はない。戻り値は、対応するＲＣＲｅｇｉｏｎへのポインタである。
【０１９７】
２．７　ＯＳｈｍＰｔｒクラス
共有メモリ領域へのポインタです。ＯＳｈｍＰｔｒＢａｓｅとは異なり、このクラスはテンプレートクラスです。ＯｓｈｍＰｔｒクラスには、以下のメンバー関数があります。
・ＯＳｈｍＰｔｒ（）
構文は、ＯＳｈｍＰｔｒ（ｖｏｉｄ）　であり、ＯＳｈｍＰｔｒ＜Ｔ＞型の無効なインスタンスを生成します。仮引数及び戻り値はない。
【０１９８】
・ＯＳｈｍＰｔｒ（）
構文は、ＯＳｈｍＰｔｒ（ｃｏｎｓｔ　ＯＳｈｍＰｔｒＢａｓｅ＆　ｐ）　であり、指定したＯＳｈｍＰｔｒＢａｓｅが参照する領域を参照するＯＳｈｍＰｔｒ＜Ｔ＞型のインスタンスを生成します。仮引数は、ｐ（コピー元のＯＳｈｍＰｔｒＢａｓｅ）である。戻り値はない。
【０１９９】
・ＯＳｈｍＰｔｒ（）
構文は、ＯＳｈｍＰｔｒ（ＲＣＲｅｇｉｏｎ＊　ｒｅｇｉｏｎ）　であり、指定した領域を参照するＯＳｈｍＰｔｒ＜Ｔ＞型のインスタンスを生成します。仮引数は、ｒｅｇｉｏｎ（参照カウンタ付き共有メモリ領域へのポインタ）である。戻り値はない。
【０２００】
・ＯＳｈｍＰｔｒ（）
構文は、ＯＳｈｍＰｔｒ（ｓｉｚｅ＿ｔ　ｎ）　であり、ｓｉｚｅｏｆ（Ｔ）＊ｎの大きさの共有メモリ領域を確保し、ＯＳｈｍＰｔｒ＜Ｔ＞の要素数ｎ個の配列を生成します。この関数は内部でＡｌｌｏｃａｔｅ（ｎ）を呼びます。型Ｔのコンストラクタは呼ばれません。仮引数は、ｎ（ＯＳｈｍＰｔｒ＜Ｔ＞の配列の要素数）であり、戻り数はない。
【０２０１】
・￣ＯＳｈｍＰｔｒ（）
構文は、￣ＯＳｈｍＰｔｒ（）　であり、ＯＳｈｍＰｔｒ＜Ｔ＞を破壊して、参照カウンタをデクリメントします。仮引数及び戻り値はない。
【０２０２】
・ｏｐｅｒａｔｏｒ＝（）
構文は、ＯＳｈｍＰｔｒ＜Ｔ＞＆　ｏｐｅｒａｔｏｒ＝（ｃｏｎｓｔ　ＯＳｈｍＰｔｒＢａｓｅ＆　ｐ）　であり、指定したＯＳｈｍＰｔｒＢａｓｅが参照するのと同じ領域へ参照を変更します。仮引数は、ｐ（コピー元のＯＳｈｍＰｔｒＢａｓｅ）である。戻り値は、＊ｔｈｉｓである。
【０２０３】
・Ａｌｌｏｃａｔｅ（）
構文は、ｖｏｉｄ　　Ａｌｌｏｃａｔｅ（ｉｎｔ　ｎ）　であり、ｓｉｚｅｏｆ（Ｔ）＊ｎの大きさの共有メモリ領域を確保し、要素数ｎ、型Ｔの配列を割り当てます。新規に作成された共有メモリ領域は参照カウンタで制御されます。型Ｔのコンストラクタは呼ばれません。仮引数は、ｎ（型Ｔの配列の要素数）であり、戻り値はない。
【０２０４】
・ＮｕｍＯｆＥｌｅｍｅｎｔ（）
構文は、ｓｉｚｅ＿ｔ　　ＮｕｍＯｆＥｌｅｍｅｎｔ（ｖｏｉｄ）　ｃｏｎｓｔ　であり、配列の最大要素数を返します。仮引数はない。戻り値は、配列の要素数である。
【０２０５】
・ｏｐｅｒａｔｏｒ＊（）
構文は、ｃｏｎｓｔ　Ｔ＆　　ｏｐｅｒａｔｏｒ＊（ｖｏｉｄ）　ｃｏｎｓｔ　であり、配列の最初の要素への参照を返します。仮引数はない。戻り値は、配列の最初の要素への参照である。
【０２０６】
・ｏｐｅｒａｔｏｒ＊（）
構文は、ＯＳｈｍＰｔｒ＜Ｔ＞：：Ｐｒｏｘｙ　　ｏｐｅｒａｔｏｒ＊（ｖｏｉｄ）　であり、配列の最初の要素を返します。この要素が参照されている最中に他から要素を上書きしようとすると、要素を保持する領域の内容が新規に確保された領域にコピーされ、新規に確保された領域が上書きされます。仮引数はない。戻り値は、最初の要素であり、配列の最初の要素を示す。
【０２０７】
・ｏｐｅｒａｔｏｒ［］（）
構文は、ｃｏｎｓｔ　Ｔ＆　　ｏｐｅｒａｔｏｒ［］（ｉｎｔ　ｉ）　ｃｏｎｓｔ　であり、配列のｉ番目の要素への参照を返します。仮引数は、ｉ　（配列の要素のインデックス）である。戻り値は、配列のｉ番目の要素への参照を示す。
【０２０８】
・ｏｐｅｒａｔｏｒ［］（）
構文は、ＯＳｈｍＰｔｒ＜Ｔ＞：：Ｐｒｏｘｙ　　ｏｐｅｒａｔｏｒ［］（ｉｎｔ　ｉ）　であり、配列のｉ番目の要素を返します。この要素が参照されている最中に他から要素を上書きしようとすると、要素を保持する領域の内容が新規に確保された領域にコピーされ、新規に確保された領域が上書きされます。仮引数は、ｉ　（配列の要素のインデックス）であり、戻り値は、配列のｉ番目の要素である。
【０２０９】
・ｏｐｅｒａｔｏｒ−＞（）
構文は、ｃｏｎｓｔ　Ｔ＊　　ｏｐｅｒａｔｏｒ−＞（ｖｏｉｄ）　ｃｏｎｓｔ　であり、配列の最初の要素へのポインタを返します。仮引数はない。戻り値は、配列の最初の要素へのポインタである。
【０２１０】
第３章　サービス
３．１　ＯＶｉｒｔｕａｌＲｏｂｏｔＣｏｍｍ
以下にＯＶｉｒｔｕａｌＲｏｂｏｔＣｏｍｍのサービスを説明する。
・ＯＶｉｒｔｕａｌＲｏｂｏｔＣｏｍｍ．Ｅｆｆｅｃｔｏｒ．ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ．Ｏ
ジョイントコマンド、ＬＥＤコマンドを受信するサービスです。受信するデータ構造体は、ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａです。ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａは、ＯＰＥＮＲ：：ＮｅｗＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ（）によって共有メモリを確保します。受信したＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａの出力が終了すると、ＲＥＡＤＹ　ＥＶＥＮＴを送信します。
・ＯＶｉｒｔｕａｌＲｏｂｏｔＣｏｍｍ．Ｓｅｎｓｏｒ．ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａ．Ｓ
ロボットで使用可能なすべてのセンサーデータを送信するサービスです。送信するデータ構造体は、ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａです。４フレーム（３２ｍｓ）のデータが１回の送信で送られます。
・ＯＶｉｒｔｕａｌＲｏｂｏｔＣｏｍｍ．ＦｂｋＩｍａｇｅＳｅｎｓｏｒ．ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ．Ｓ
カメラの画像データを送信するサービスです。送信するデータ構造体は、ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａです。画像データのアクセス用にＯＦｂｋＩｍａｇｅとして３枚のＹＣｒＣｂ画像と１枚のＣＤＴ画像が送信されます。
【０２１１】
３．２　ＯＶｉｒｔｕａｌＲｏｂｏｔＡｕｄｉｏＣｏｍｍ
以下に、ＯＶｉｒｔｕａｌＲｏｂｏｔＡｕｄｉｏＣｏｍｍのサービスを説明する。
・ＯＶｉｒｔｕａｌＲｏｂｏｔＡｕｄｉｏＣｏｍｍ．Ｍｉｃ．ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａ．Ｓ
マイクからの音データを送信するサービスです。３２ｍｓごとにデータが送信されます。サウンドデータのフォーマットは１６ｋＨｚ、１６ｂｉｔステレオのＰＣＭデータです。
・ＯＶｉｒｔｕａｌＲｏｂｏｔＡｕｄｉｏＣｏｍｍ．Ｓｐｅａｋｅｒ．ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａ．Ｏ
サウンドデータを受信するサービスです。受信するデータの構造体はＯｓｏｕｎｄＶｅｃｔｏｒＤａｔａです。ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａは、ＯＰＥＮＲ：：ＮｅｗＳｏｕｎｄＶｅｃｔｏｒＤａｔａ（）によって共有メモリを確保します。受信したＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａの出力が終了すると、ＲＥＡＤＹ　ＥＶＥＮＴを送信します。
【０２１２】
第４章　データ型
４．１　共通ヘッダ
・ＯＤａｔａＶｅｃｔｏｒＩｎｆｏ
ＯＤａｔａＶｅｃｔｏｒＩｎｆｏは、ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ、　ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａ、ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ　、ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａ、ＯＣｄｔＶｅｃｔｏｒＤａｔａの共通のヘッダで、データの要素数、要素の情報ブロックサイズ、共有メモリに関する情報を保持します。構造体を以下に示す。

【０２１３】
ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｍｅｍＲｅｇｉｏｎＩＤ：データを保持する共有メモリ領域のＩＤ
ｐｈｙｓＡｄｄｒ　　　：ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ、ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａでは共有メモリの物理アドレスに、それ以外のデータでは０に設定されます。
ｏｆｆｓｅｔ：オフセット
ｔｏｔａｌＳｉｚｅ：データを保持している共有メモリのサイズ
ｔｙｐｅ：データの種類と、それに対応するデータの構造
データの種類とこのデータの構造との関係は、以下のようになっている。
【０２１４】
ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａに対して、ｏｄａｔａＣＯＭＭＡＮＤ＿ＶＥＣＴＯＲ
ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａに対して、ｏｄａｔａＳＥＮＳＯＲ＿ＦＲＡＭＥ＿ＶＥＣＴＯＲ
ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａに対して、ｏｄａｔａＦＢＫＩＭＡＧＥ＿ＶＥＣＴＯＲ
ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａに対して、ｏｄａｔａＳＯＵＮＤ＿ＶＥＣＴＯＲ
ＯＣｄｔＶｅｃｔｏｒＤａｔａに対して、ｏｄａｔａＣＤＴ＿ＶＥＣＴＯＲ
ｉｎｆｏＯｆｆｓｅｔ：データの先頭アドレスから要素の情報ブロックの配列へのオフセット（１９２バイト）
ｍａｘＮｕｍＤａｔａ：保持できるデータの最大要素数
ｎｕｍＤａｔａ：有効なデータの要素数
ｓｙｎｃＫｅｙ：　　　同期キー
ｗａｉｔ：コマンド、サウンドの出力をｗａｉｔで指定されたフレーム（８ｍｓｅｃ）分待ちます。
ｏｐｔＯｆｆｓｅｔ：オプショナル領域の有効データのオフセット
ｏｐｔＳｉｚｅ：オプショナル領域の有効データのサイズ
ｐａｄｄｉｎｇ［３］：総バイト数を調整するための余白
ｏｐｔｉｏｎａｌ［ｏｄａｔａＯＰＴＩＯＮＡＬ＿ＭＡＸ］：ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ，　ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａを送信するオブジェクトとＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａを受信するオブジェクト間で情報の受け渡しに使用します。ｏｐｔｉｏｎａｌ［］のデータのうちｏｐｔＯｆｆｓｅｔ、ｏｐｔＳｉｚｅで指定したデータが更新され、ＯＳｏｕｎｄＦｒａｍｅＶｅｃｔｏｒＤａｔａのｏｐｔｉｏｎａｌ［］にデータがコピーされます。
【０２１５】
４．２　ＯＶｉｒｔｕａｌＲｏｂｏｔＣｏｍｍとの通信
ＯＶｉｒｔｕａｌＲｏｂｏｔＣｏｍｍとの通信に使用するデータは、以下の３個です。
ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ：コマンドデータ
ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａ：センサーデータ
ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ：画像データ
これらのデータは、共有メモリ上に作成されます。各データの内容は、共通ヘッダのＯＤａｔａＶｅｃｔｏｒＩｎｆｏに続いて各要素の情報ブロックの配列、データ本体の配列の順に置かれます。
【０２１６】
４．２．１　ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ
ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａは、ジョイントコマンド、ＬＥＤコマンドを保持するデータ構造体です。ｖｅｃｔｏｒＩｎｆｏに続いてｖｅｃｔｏｒＩｎｆｏ．ｍａｘＮｕｍＤａｔａ数のＯＣｏｍｍａｎｄＩｎｆｏの配列、ＯＣｏｍｍａｎｄＤａｔａの配列が並びます。各コマンドの種類は、ＯＣｏｍｍａｎｄＩｎｆｏのｔｙｐｅにより指定されます。１個の　ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａで異なる種類のコマンドを複数保持することができます。構造体は、以下の通りである。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　である。
【０２１７】
・ＯＣｏｍｍａｎｄＩｎｆｏ
ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａの要素の種類、ＯＰｒｉｍｉｔｉｖｅＩＤ、コマンドフレーム数、
コマンドへのオフセットを保持します。構造体を以下に示す。

【０２１８】
ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｔｙｐｅ：コマンドの種類（ｏｄａｔａＪＯＩＮＴ＿ＣＯＭＭＡＮＤ２、ｏｄａｔａＬＥＤ＿ＣＯＭＭＡＮＤ２）
ｐｒｉｍｉｔｉｖｅＩＤ：コマンドを指定するＣＰＣ　ＰｒｉｍｉｔｉｖｅのＩＤ
ｆｒａｍｅＮｕｍｂｅｒ：コマンドの最初のフレームの処理を行ったときのフレーム番号が格納されます。
ｎｕｍＦｒａｍｅｓ：ＯＣｏｍｍａｎｄＤａｔａが保持するコマンドデータの有効フレーム数。ＯＣｏｍｍａｎｄＤａｔａでは最大ｏｃｏｍｍａｎｄＭＡＸ＿ＦＲＡＭＥＳ　（＝　１６）　フレーム分のうちｎｕｍＦｒａｍｅｓ　分のデータのみが処理されます。
ｆｒａｍｅＳｉｚｅ　　ＯＣｏｍｍａｎｄＤａｔａが保持する１フレーム分のコマンドデータのサイズ（８バイト）
ｄａｔａＯｆｆｓｅｔ：ＯＣｏｍｍａｎｄＩｎｆｏに対応するＯＣｏｍｍａｎｄＤａｔａのオフセット。ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａの先頭アドレスからのオフセットを表します。
ｄａｔａＳｉｚｅ：ＯＣｏｍｍａｎｄＩｎｆｏ　に対応する　ＯＣｏｍｍａｎｄＤａｔａ　のデータサイズ（１２８バイト）
ｐａｄｄｉｎｇ［１］：総バイト数を調整するための余白
【０２１９】
・ＯＣｏｍｍａｎｄＤａｔａ
コマンドデータの本体です。ＯＣｏｍｍａｎｄＶａｌｕｅは、１フレーム分の汎用データの構造体です。ジョイントコマンドの場合はＯＪｏｉｎｔＣｏｍｍａｎｄＶａｌｕｅ２に、耳プランジャーの場合はＯＪｏｉｎｔＣｏｍｍａｎｄＶａｌｕｅ３に、ＬＥＤコマンドの場合はＯＬＥＤＣｏｍｍａｎｄＶａｌｕｅにキャストして使用します。構造体を以下に示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーは、以下である。
ｖａｌｕｅ［ｏｃｏｍｍａｎｄＭＡＸ＿ＦＲＡＭＥＳ］：コマンドデータ。ＯＣｏｍｍａｎｄＤａｔａは、最大ｏｃｏｍｍａｎｄＭＡＸ＿ＦＲＡＭＥＳ　（＝　１６）フレーム分のデータを保持できます。有効フレーム数はＯＣｏｍｍａｎｄＩｎｆｏのｎｕｍＦｒａｍｅｓにより指定されます。
【０２２０】
・ＯＪｏｉｎｔＣｏｍｍａｎｄＶａｌｕｅ２
ＯＪｏｉｎｔＣｏｍｍａｎｄＶａｌｕｅ２は、１フレーム分のジョイントのコマンドデータである。構造体を以下に示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：ジョイントへの指示値。単位はマイクロラジアン（１０^−６　ｒａｄ）で、３６０°の場合は３１４１５９２です。
ｐａｄｄｉｎｇ：総バイト数を調整するための余白
【０２２１】
・ＯＪｏｉｎｔＣｏｍｍａｎｄＶａｌｕｅ３
ＯＪｏｉｎｔＣｏｍｍａｎｄＶａｌｕｅ３は、耳のプランジャ動作のコマンドデータであり、構造体は以下である。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：プランジャーの指示値。ｏｊｏｉｎｔ３−ＳＴＡＴＥ０またはｏｊｏｉｎｔ３−ＳＴＡＴＥ１を指定します。
ｒｅｓｅｒｖｅｄ：予約済み
ｐａｄｄｉｎｇ：総バイト数を調整するための余白
【０２２２】
・ＯＬＥＤＣｏｍｍａｎｄＶａｌｕｅ２
ＯＬＥＤＣｏｍｍａｎｄＶａｌｕｅ２は、ＬＥＤを制御するコマンドデータです。ＬＥＤの制御はＯＮ、ＯＦＦとその時刻で指定します。ＬＥＤのＯＮ、ＯＦＦをコントロールできる時間の最小単位は８　ｍｓです。構造体を以下に示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｌｅｄ：ＬＥＤのＯＮ、ＯＦＦを指定します。ｏｌｅｄＯＮまたはｏｌｅｄＯＦＦを指定します。
ｐｅｒｉｏｄ：ＬＥＤ状態の継続時間を指定します。時間の最小単位は８　ｍｓです。
ｒｅｓｅｒｖｅｄ：予約済み
【０２２３】
４．２．２　ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａ
ジョイント、加速度センサー、スイッチなどの各種センサーのデータを保持するデータ構造体です。ｖｅｃｔｏｒＩｎｆｏに続いてｖｅｃｔｏｒＩｎｆｏ．ｍａｘＮｕｍＤａｔａ数のＯＳｅｎｓｏｒＦｒａｍｅＩｎｆｏ　の配列、ＯＳｅｎｓｏｒＦｒａｍｅＤａｔａの配列が並びます。各センサーデータの種類は、ＯＳｅｎｓｏｒＦｒａｍｅＩｎｆｏのｔｙｐｅにより指定されます。１個のＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａで、異なる種類の複数のセンサーデータを保持することができます。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　である。
【０２２４】
・ＯＳｅｎｓｏｒＦｒａｍｅＩｎｆｏ
ＯＳｅｎｓｏｒＦｒａｍｅＩｎｆｏは、ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａの要素の種類、ＯＰｒｉｍｉｔｉｖｅＩＤ、センサーデータのフレーム数、センサーデータへのオフセットを保持します。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｔｙｐｅ：センサーデータの種類。種類の一覧は　ＯＤａｔａＦｏｒｍａｔｓ．ｈで定義されています。
ｐｒｉｍｉｔｉｖｅＩＤ：センサーデータを得たＣＰＣ　ＰｒｉｍｉｔｉｖｅのＩＤ番号
ｆｒａｍｅＮｕｍｂｅｒ：対応するＯＳｅｎｓｏｒＦｒａｍｅＤａｔａの最初のデータ取得時のフレーム番号
ｎｕｍＦｒａｍｅｓ：ＯＳｅｎｓｏｒＦｒａｍｅＤａｔａが保持するセンサーデータの有効フレーム数
ｆｒａｍｅＳｉｚｅ　　：ＯＳｅｎｓｏｒＦｒａｍｅＤａｔａが保持する１フレーム分のセンサーデータのサイズ（１６バイト）
ｄａｔａＯｆｆｓｅｔ：ＯＳｅｎｓｏｒＦｒａｍｅＩｎｆｏに対応するＯＳｅｎｓｏｒＦｒａｍｅＤａｔａのオフセット。ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａの先頭アドレスからのオフセットになります。
ｄａｔａＳｉｚｅ：ＯＳｅｎｓｏｒＦｒａｍｅＩｎｆｏに対応するＯＳｅｎｓｏｒＦｒａｍｅＤａｔａのデータサイズ（１２８バイト）
ｐａｄｄｉｎｇ［１］：総バイト数を調整するための余白
【０２２５】
・ＯＳｅｎｓｏｒＦｒａｍｅＤａｔａ
ＯＳｅｎｓｏｒＦｒａｍｅＤａｔａは、センサーデータの本体です。ＯＳｅｎｓｏｒＶａｌｕｅは、１フレーム分の汎用的なデータ構造体です。各種センサーデータにキャストして利用します。例えばジョイントデータの場合は　ＯＪｏｉｎｔＶａｌｕｅに、加速度センサーの場合はＯＡｃｃｅｌｅｒａｔｉｏｎにキャストします。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーは以下である。
ｆｒａｍｅ［ｏｓｅｎｓｏｒｆｒａｍｅＭＡＸ＿ＦＲＡＭＥＳ］：センサーデータである。ＯＳｅｎｓｏｒＦｒａｍｅＤａｔａは、最大ｏｓｅｎｓｏｒｆｒａｍｅＭＡＸ＿ＦＲＡＭＥＳ（＝　１６）フレーム分のデータを保持できます。有効フレーム数は、ＯＳｅｎｓｏｒＦｒａｍｅＩｎｆｏのｎｕｍＦｒａｍｅｓにより指定されます。
【０２２６】
・ＯＡｃｃｅｌｅｒａｔｉｏｎ
ＯＡｃｃｅｌｅｒａｔｉｏｎは、加速度であり、単位は、１０^−６　ｍ／ｓｅｃ^２です。以下に構造体を示す。
【０２２７】

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：加速度センサーから得られた信号値をキャリブレーションテーブルにより変換した値。単位は１０^−６　ｍ／ｓｅｃ^２です。
ｓｉｇｎａｌ：加速度センサーから得られたＡＤ信号値
ｐａｄｄｉｎｇ［５］：総バイト数を調整するための余白
【０２２８】
・ＯＡｎｇｕｌａｒＶｅｌｏｃｉｔｙ
ＯＡｎｇｕｌａｒＶｅｌｏｃｉｔｙは、角速度であり、単位は、１０^−６　ｒａｄ／ｓです。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：角速度センサーから得られた信号値をキャリブレーションテーブルにより変換した値。単位は、１０^−６　ｒａｄ／ｓです。
ｓｉｇｎａｌ：角速度センサーから得られたＡＤ信号値
ｐａｄｄｉｎｇ［５］：総バイト数を調整するための余白
【０２２９】
・ＯＴｅｍｐｅｒａｔｕｒｅ
ＯＴｅｍｐｅｒａｔｕｒｅは、温度であり、単位は１０^−６　℃です。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：温度センサーから得られた信号値をキャリブレーションテーブルにより変換した値。単位は１０^−６　℃です。
ｓｉｇｎａｌ：温度センサーから得られたＡＤ信号値
ｐａｄｄｉｎｇ［５］：総バイト数を調整するための余白
【０２３０】
・ＯＦｏｒｃｅ
ＯＦｏｒｃｅは、力であり、単位は１０^−６　Ｎです。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：センサーから得られた信号値をキャリブレーションテーブルにより変換した値。単位は１０^−６　Ｎです。
ｓｉｇｎａｌ：センサーから得られたＡＤ信号値
ｐａｄｄｉｎｇ［５］：総バイト数を調整するための余白
【０２３１】
・ＯＰｒｅｓｓｕｒｅ
ＯＰｒｅｓｓｕｒｅは、圧力であり、単位は１０^−６　Ｐａ　（Ｎ／ｍ^２）です。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：圧力センサーから得られた信号値をキャリブレーションテーブルにより変換した値。単位は１０^−６　Ｐａです。
ｓｉｇｎａｌ：圧力センサーから得られたＡＤ信号値
ｐａｄｄｉｎｇ［５］：総バイト数を調整するための余白
【０２３２】
・ＯＬｅｎｇｔｈ
ＯＬｅｎｇｔｈは、長さであり、単位は１０^−６　ｍ　です。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：センサーから得られた信号値をキャリブレーションテーブルにより変換した値。単位は１０^−６　ｍです。
ｓｉｇｎａｌ：センサーから得られた　ＡＤ　信号値
ｐａｄｄｉｎｇ［５］：総バイト数を調整するための余白
【０２３３】
・ＯＳｗｉｔｃｈＳｔａｔｕｓ
ＯＳｗｉｔｃｈＳｔａｔｕｓは、スイッチの状態である。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：スイッチから得られたＡＤ信号値を変換して得たスイッチの状態。ｏｓｗｉｔｃｈＯＮ　またはｏｓｗｉｔｃｈＯＦＦです。
ｓｉｇｎａｌ：スイッチから得られたＡＤ信号値
ｐａｄｄｉｎｇ［５］：総バイト数を調整するための余白
【０２３４】
・ＯＪｏｉｎｔＶａｌｕｅ
ＯＪｏｉｎｔＶａｌｕｅは、ジョイント値であり、単位は、回転関節の場合は１０^−６　ｒａｄです。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｖａｌｕｅ：ジョイントのフィードバック信号をキャリブレーションテーブルで変換した値です。単位は、回転関節の場合は１０^−６　ｒａｄです。
ｓｉｇｎａｌ：ジョイントのフィードバック信号
ｐｗｍＤｕｔｙ：ＰＷＭ信号値
ｒｅｆＶａｌｕｅ：センサーデータ取得時点の指示値です。単位は、マイクロラジアンです。
ｒｅｆＳｉｇｎａｌ：キャリブレーション変換後の１０ｂｉｔ値
ｐａｄｄｉｎｇ［１］：総バイト数を調整するための余白
【０２３５】
４．２．３　ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ
ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａは、画像データであり、構造体は以下のようになっている。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　である。
【０２３６】
・ＯＦｂｋＩｍａｇｅＩｎｆｏ
ＯＦｂｋＩｍａｇｅＩｎｆｏは、画像情報であり、ＹＣｒＣｂ画像、ＣＤＴ画像を保持するデータ構造体です。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーは、以下である。
ｔｙｐｅ：データの種類。ｏｄａｔａＦＢＫ＿ＹＣｒＣｂまたはｏｄａｔａＦＢＫ＿ＣＤＴです。
ｐｒｉｍｉｔｉｖｅＩＤ：画像データを設定するＦｂｋＩｍａｇｅＳｅｎｓｏｒのｐｒｉｍｉｔｉｖｅＩＤ
ｆｒａｍｅＮｕｍｂｅｒ：画像取得時のフレーム番号
ｄａｔａＯｆｆｓｅｔ：画像データの共有メモリの先頭アドレスからのオフセット
ｄａｔａＳｉｚｅ：　　画像データのサイズ
ｗｉｄｔｈ：画像データの横画素数
ｈｅｉｇｈｔ：画像データの縦画素数
ｐａｄｄｉｎｇ［１］：総バイト数を調整するための余白
【０２３７】
・ＯＦｂｋＩｍａｇｅ
ＯＦｂｋＩｍａｇｅは、ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａの各Ｙ、Ｃｒ、Ｃｂ、ＣＤＴ画像にアクセスするためのクラスです。ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＦｂｋＩｍａｇｅ．ｈ＞　であり、ライブラリは、ｌｉｂＯＰＥＮＲ．ａである。
構文は、ＯＦｂｋＩｍａｇｅ（ＯＦｂｋＩｍａｇｅＩｎｆｏ＊　ｉｎｆｏ，　ｂｙｔｅ＊　ｄａｔａ，　ＯＦｂｋＩｍａｇｅＢａｎｄ　ｂａｎｄ）　であり、ＯＦｂｋＩｍａｇｅのコンストラクタ。ｉｎｆｏ、ｄａｔａにはＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ：：ＧｅｔＩｎｆｏ（）、ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ：：ＧｅｔＤａｔａ（）で得られるポインタを指定します。ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ：：ＧｅｔＩｎｆｏ（）、ＯＦｂｋＩｍａｇｅＶｅｃｔｏｒＤａｔａ：：ＧｅｔＤａｔａ（）の引数がｏｆｂｋｉｍａｇｅＬＡＹＥＲ＿Ｈ、ｏｆｂｋｉｍａｇｅＬＡＹＥＲ＿Ｍ、ｏｆｂｋｉｍａｇｅＬＡＹＥＲ＿Ｌの場合は、　ｂａｎｄにｏｆｂｋｉｍａｇｅＢＡＮＤ＿Ｙ、ｏｆｂｋｉｍａｇｅＢＡＮＤ＿Ｃｒ、ｏｆｂｋｉｍａｇｅＢＡＮＤ＿Ｃｂの何れかを指定します。ｏｆｂｋｉｍａｇｅＬＡＹＥＲ＿Ｃの場合は、ｏｆｂｋｉｍａｇｅＢＡＮＤ＿ＣＤＴを指定します。仮引数は、ｉｎｆｏ（ＯＦｂｋＩｍａｇｅＩｎｆｏ　のポインタ）、ｄａｔａ（画像データのポインタ）、ｂａｎｄ（画像データのバンド）である。
【０２３８】
・ＩｓＶａｌｉｄ（）
構文は、ｂｏｏｌ　ＩｓＶａｌｉｄ（）　であり、ＯＦｂｋＩｍａｇｅが有効かどうかを調べます。コンストラクタが不正な仮引数で呼ばれたときに、ｆａｌｓｅが返ります。仮引数はない。戻り値には、ｔｒｕｅ（有効）、ｆａｌｓｅ（無効）がある。
【０２３９】
・Ｐｏｉｎｔｅｒ（）
構文は、ｂｙｔｅ＊　Ｐｏｉｎｔｅｒ（）　であり、画像データのポインタを返します。仮引数はない。戻り値は、画像データのポインタである。
【０２４０】
・Ｗｉｄｔｈ（）
構文は、ｉｎｔ　Ｗｉｄｔｈ（）　であり、画像の幅を返します。仮引数はない。戻り値は、画像の幅である。
【０２４１】
・Ｈｅｉｇｈｔ（）
構文は、ｉｎｔ　Ｈｅｉｇｈｔ（）　であり、画像の高さを返します。仮引数はない。戻り値は、画像の高さである。
【０２４２】
・Ｓｋｉｐ（）
構文は、ｉｎｔ　Ｓｋｉｐ（）　であり、画像データの次のラインへポインタを進めるとき、スキップするバイト数を返します。仮引数はない。戻り値は、画像データの次のラインへのスキップバイト数である。
【０２４３】
・Ｐｉｘｅｌ（）
構文は、ｂｙｔｅ　Ｐｉｘｅｌ（ｉｎｔ　ｘ，　ｉｎｔ　ｙ）　であり、座標（ｘ，　ｙ）の画像データのピクセル値を返します。座標の原点は左上の点です。仮引数は、ｘ　（画像データのＸ座標）、ｙ　（画像データのＹ座標）である。戻り値は、座標（ｘ，　ｙ）の画像データのピクセル値である。
【０２４４】
・ＦｉｅｌｄＣｏｕｎｔｅｒ（）
構文は、ｗｏｒｄ　ＦｉｅｌｄＣｏｕｎｔｅｒ（）　であり、各レイヤーの画像データの最終ラインに、カウンタ番号が記述されています。カウンタ番号は画像ごとにインクリメントされます。ＦｉｅｌｄＣｏｕｎｔｅｒ（）はこのカウンタ番号を返します。仮引数はない。戻り値は、画像のカウンタ値である。
【０２４５】
・ＣｏｌｏｒＦｒｅｑｕｅｎｃｙ（）
構文は、ｂｙｔｅ　ＣｏｌｏｒＦｒｅｑｕｅｎｃｙ（ＯＣｄｔＣｈａｎｎｅｌ　ｃｈａｎ）　であり、各レイヤーの画像データの最終ラインに色検出された画素数／１６の色頻度情報が記述されています。ＣｏｌｏｒＦｒｅｑｕｅｎｃｙ（）はこの色頻度を返します。仮引数は、ｃｈａｎ（ＣＤＴ　チャンネル）である。戻り値は、色検出された色頻度（画素数／１６）である。
【０２４６】
４．３　ＯＶｉｒｔｕａｌＲｏｂｏｔＡｕｄｉｏＣｏｍｍとの通信
ＯＶｉｒｔｕａｌＲｏｂｏｔＡｕｄｉｏＣｏｍｍとの通信に使用するデータは、「ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａ　音データ」の１つである。データは、共有メモリ上に作成されます。データの内容は、共通ヘッダのＯＤａｔａＶｅｃｔｏｒＩｎｆｏに続いて各要素の情報ブロックの配列、データ本体の配列の順に置かれます。
【０２４７】
４．３．１　ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａ
ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａは、サウンドデータを保持するデータ構造体です。ｖｅｃｔｏｒＩｎｆｏ　に続いて　ｖｅｃｔｏｒＩｎｆｏ．ｍａｘＮｕｍＤａｔａ数のＯＳｏｕｎｄＩｎｆｏの配列、サウンドデータのバイト列が並びます。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　である。
【０２４８】
・ＯＳｏｕｎｄＩｎｆｏ
ＯＳｏｕｎｄＩｎｆｏは、サウンドデータに関する情報を保持するデータ構造体です。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下のものがある。
ｔｙｐｅ：データの種類。ｏｄａｔａＳＯＵＮＤ　が入ります。
ｐｒｉｍｉｔｉｖｅＩＤ：サウンドデータを入出力するＣＰＣ　ＰｒｉｍｉｔｖｅのＩＤ番号。音を出力する場合はスピーカーのＯＰｒｉｍｉｔｉｖｅＩＤを設定します。音を入力する場合はマイクのＯＰｒｉｍｉｔｖｅＩＤを設定します。
ｆｒａｍｅＮｕｍｂｅｒ：音を出力する場合は最初のサウンドのフレームを処理するときのフレーム番号、音を入力する場合はデータを入力したときのフレーム番号です。
ｆｒａｍｅＳｉｚｅ　　：１フレーム分のサウンドデータのサイズ
ｄａｔａＯｆｆｓｅｔ：ＯＳｏｕｎｄＩｎｆｏに対応するサウンドデータのバイト列へのオフセット。
ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａの先頭アドレスからのオフセットを示します。
ｍａｘＤａｔａＳｉｚｅ：ＯＳｏｕｎｄＩｎｆｏに対応するサウンドデータのバイト列の最大サイズ
ｄａｔａＳｉｚｅ：　　有効なサウンドデータのバイト列のサイズ
ｆｏｒｍａｔ：サウンドデータの形式。現在はｏｓｏｕｎｄｆｏｒｍａｔＰＣＭのみサポートしています。
ｃｈａｎｎｅｌ：サウンドデータのチャンネル数
ｓａｍｐｌｉｎｇＲａｔｅ：サンプリングレート
ｂｉｔｓＰｅｒＳａｍｐｌｅ：サウンドデータの１サンプルあたりのビット数
ａｃｔｕａｌＤａｔａＳｉｚｅ：デバイスから転送されたサウンドデータのサイズ。
ｐａｄｄｉｎｇ［６］：総バイト数を調整するための余白
【０２４９】
４．４その他
その他に「ＯＣｄｔＶｅｃｔｏｒＤａｔａ　　ＣＤＴ　テーブルデータ」がある。このデータは、共有メモリ上に作成されます。データの内容は、共通ヘッダのＯＤａｔａＶｅｃｔｏｒＩｎｆｏに続いて各要素の情報ブロックの配列、データ本体の配列の順に置かれます。
【０２５０】
４．４．１　ＯＣｄｔＶｅｃｔｏｒＤａｔａ
ＯＣｄｔＶｅｃｔｏｒＤａｔａは、色検出テーブルを保持するデータ構造体です。最大ｏｃｄｔＮＵＭ＿ＣＨＡＮＮＥＬＳ　（＝　８）のテーブルを保持できます。ＯＤａｔａＶｅｃｔｏｒＩｎｆｏ：：ｎｕｍＤａｔａで有効なＯＣｄｔＩｎｆｏの数を指定します。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　である。
【０２５１】
・ＯＣｄｔＩｎｆｏ
色検出のテーブルは、Ｙ　（輝度信号）を３２のセグメントに分割し、各セグメントに対してＣｒｍａｘ、Ｃｒｍｉｎ、Ｃｂｍａｘ、Ｃｂｍｉｎを指定します。Ｃｒ、Ｃｂの値はオフセットバイナリで、０ｘ０から０ｘｆｆの範囲で指定できます。以下に構造体を示す。

ヘッダファイルは、＃ｉｎｃｌｕｄｅ　＜ＯＰＥＮＲ／ＯＤａｔａＦｏｒｍａｔｓ．ｈ＞　であり、メンバーには、以下ものがある。
ｔｙｐｅ：データの種類。ｏｄａｔａＣＤＴが入ります。
ｐｒｉｍｉｔｉｖｅＩＤ：ＣＤＴを設定するＯＦｂｋＩｍａｇｅＳｅｎｓｏｒのＰｒｉｍｉｔｉｖｅＩＤ
ｃｈａｎｎｅｌ：テーブルを設定するＣＤＴのチャンネル
ｔａｂｌｅ［ｏｃｄｔＭＡＸ＿Ｙ＿ＳＥＧＭＥＮＴ］：テーブルデータの配列
ｐａｄｄｉｎｇ：総バイト数を調整するための余白
【０２５２】
第５章ＯＰＥＮ−Ｒ　ＡＰＩ
以下に、ＯＰＥＮ−Ｒ　ＡＰＩ　を示す。
・ＯＰＥＮＲ：：ＯｐｅｎＰｒｉｍｉｔｉｖｅ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＯｐｅｎＰｒｉｍｉｔｉｖｅ（ｃｏｎｓｔ　ｃｈａｒ＊　ｌｏｃａｔｏｒ，　ＯＰｒｉｍｉｔｉｖｅＩＤ＊　ｐｒｉｍｉｔｉｖｅＩＤ）　であり、ＣＰＣ　ＰｒｉｍｉｔｉｖｅをオープンしてＯＰｒｉｍｉｔｉｖｅＩＤを取得します。失敗した場合は、ｐｒｉｍｉｔｉｖｅＩＤにはｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＮＤＥＦが返ります。仮引数は、ｌｏｃａｔｏｒ（ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒ）、ｐｒｉｍｉｔｉｖｅＩＤ（ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　ＩＤ）である。また、戻り値は、ｏＳＵＣＣＥＳＳ（成功）、ｏＮＯＴ＿ＦＯＵＮＤ（ｌｏｃａｔｏｒ　に対応するＣＰＣ　Ｐｒｉｍｉｔｉｖｅが存在しない。）、ｏＯＰＥＮ＿ＦＡＩＬＵＲＥ（ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　のオープンに失敗）、ｏＩＮＶＡＬＩＤ＿ＡＲＧ（ｌｏｃａｔｏｒがＮＵＬＬ　ポインタ）、ｏＦＡＩＬ（失敗）である。
【０２５３】
・ＯＰＥＮＲ：：ＣｌｏｓｅＰｒｉｍｉｔｉｖｅ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＣｌｏｓｅＰｒｉｍｉｔｉｖｅ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ）　であり、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　をクローズします。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｅＩＤ）がある。
【０２５４】
・ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ，ＯＰｒｉｍｉｔｖｅＲｅｑｕｅｓｔ　ｒｅｑｕｅｓｔ，　ｖｏｉｄ＊　ｐａｒａｍ，　ｓｉｚｅ＿ｔ　ｐａｒａｍＳｉｚｅ，ｖｏｉｄ＊　ｒｅｓｕｌｔ，　ｓｉｚｅ＿ｔ　ｒｅｓｕｌｔＳｉｚｅ）　であり、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　のパラメーターを設定します。ｐａｒａｍ、ｐａｒａｍＳｉｚｅ、ｒｅｓｕｌｔ、ｒｅｓｕｌｔＳｉｚｅについては、ｒｅｑｕｅｓｔで指定します。指定する必要がない場合は０を指定します。以下は、ｒｅｑｕｅｓｔの種類です。
ｏｐｒｍｒｅｑＳＰＥＡＫＥＲ＿ＭＵＴＥ＿ＯＮ
ｏｐｒｍｒｅｑＳＰＥＡＫＥＲ＿ＭＵＴＥ＿ＯＦＦ
ｏｐｒｍｒｅｑＭＩＣ＿ＵＮＩ
ｏｐｒｍｒｅｑＭＩＣ＿ＯＭＮＩ
ｏｐｒｍｒｅｑＭＩＣ＿ＡＬＣ＿ＯＮ
ｏｐｒｍｒｅｑＭＩＣ＿ＡＬＣ＿ＯＦＦ
ｏｐｒｍｒｅｑＣＡＭ＿ＳＥＴ＿ＷＨＩＴＥ＿ＢＡＬＡＮＣＥ
ｏｐｒｍｒｅｑＣＡＭ＿ＳＥＴ＿ＧＡＩＮ
ｏｐｒｍｒｅｑＣＡＭ＿ＳＥＴ＿ＳＨＵＴＴＥＲ＿ＳＰＥＥＤ
【０２５５】
また、以下のように設定します。
／＊　Ｍｕｔｅ　ＯＮ　＊／
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｓｐｅｋｅｒＩＤ，　ｏｐｒｍｒｅｑＳＰＥＡＫＥＲ＿ＭＵＴＥ＿ＯＮ，　０，　０，　０，　０）；
／＊　Ｍｕｔｅ　ＯＦＦ　＊／
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｓｐｅｋｅｒＩＤ，　ｏｐｒｍｒｅｑＳＰＥＡＫＥＲ＿ＭＵＴＥ＿ＯＦＦ，　０，　０，　０，　０）；
／＊　ＵＮＩ　ＭＩＣ　＊／
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｍｉｃＩＤ，　ｏｐｒｍｒｅｑＭＩＣ＿ＵＮＩ，　０，　０，　０，　０）；
／＊　ＯＭＮＩ　ＭＩＣ　＊／
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｍｉｃＩＤ，　ｏｐｒｍｒｅｑＭＩＣ＿ＯＭＮＩ，　０，　０，　０，　０）；
／＊　ＡＬＣ　ＯＮ　＊／
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｍｉｃＩＤ，　ｏｐｒｍｒｅｑＭＩＣ＿ＡＬＣ＿ＯＮ，　０，　０，　０，　０）；
／＊　ＡＬＣ　ＯＦＦ　＊／
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｍｉｃＩＤ，　ｏｐｒｍｒｅｑＭＩＣ＿ＡＬＣ＿ＯＦＦ，　０，　０，　０，　０）；
／＊　ホワイトバランス設定　＊／
ＯＰｒｉｍｉｔｉｖｅＣｏｎｔｒｏｌ＿ＣａｍｅｒａＰａｒａｍ　ｗｂ（ｏｃａｍｐａｒａｍＷＢ＿ＯＵＴＤＯＯＲ＿ＭＯＤＥ）；
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｐｒｍＩＤ，　ｏｐｒｍｒｅｑＣＡＭ＿ＳＥＴ＿ＷＨＩＴＥ＿ＢＡＬＡＮＣＥ，＆ｗｂ，　ｓｉｚｅｏｆ（ｗｂ），　０，　０）；
／＊　カメラゲイン　＊／
ＯＰｒｉｍｉｔｉｖｅＣｏｎｔｒｏｌ＿ＣａｍｅｒａＰａｒａｍ　ｇａｉｎ（ｏｃａｍｐａｒａｍＧＡＩＮ＿ＭＩＤ）；
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｐｒｍＩＤ，　ｏｐｒｍｒｅｑＣＡＭ＿ＳＥＴ＿ＧＡＩＮ，＆ｇａｉｎ，　ｓｉｚｅｏｆ（ｇａｉｎ），　０，　０）；
／＊　シャッタースピード　＊／
ＯＰｒｉｍｉｔｉｖｅＣｏｎｔｒｏｌ＿ＣａｍｅｒａＰａｒａｍ　ｓｈｕｔｔｅｒ（ｏｃａｍｐａｒａｍＳＨＵＴＴＥＲ＿ＦＡＳＴ）；
ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（ｐｒｍＩＤ，　ｏｐｒｍｒｅｑＣＡＭ＿ＳＥＴ＿ＳＨＵＴＴＥＲ＿ＳＰＥＥＤ，＆ｓｈｕｔｔｅｒ，　ｓｉｚｅｏｆ（ｓｈｕｔｔｅｒ），　０，　０）；
【０２５６】
また、仮引数は、ｐｒｉｍｉｔｉｖｅＩＤ（ＯＰｒｉｍｉｔｉｖｅＩＤ）、ｒｅｑｕｅｓｔ（コントロールリクエスト）、ｐａｒａｍ（パラメータデータ）、ｐａｒａｍＳｉｚｅ（パラメータデータのサイズ）、ｒｅｓｕｌｔ（結果データ）、ｒｅｓｕｌｔＳｉｚｅ（結果データのサイズ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｅＩＤ）、ｏＩＮＶＡＬＩＤ＿ＡＲＧ（不正なｒｅｑｕｅｓｔ、ｐａｒａｍ）がある。
【０２５７】
・ＯＰＥＮＲ：：ＮｅｗＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＮｅｗＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ（ｓｉｚｅ＿ｔ　ｎｕｍＣｏｍｍａｎｄｓ，ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ＊　ｍｅｍＩＤ，　ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ＊＊　ｂａｓｅＡｄｄｒ）　であり、ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａの共有メモリを確保します。ｖｅｃｔｏｒＩｎｆｏ．ｎｕｍＤａｔａは０に初期化されます。ＳｅｔＮｕｍＤａｔａ（）を使用して有効要素数を設定します。仮引数は、ｎｕｍＣｏｍｍａｎｄｓ（ＯＣｏｍｍａｎｄＤａｔａ　の要素数）、ｍｅｍＩＤ（ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ　の共有メモリのＭｅｍｏｒｙＲｅｇｉｏｎＩＤ）、ｂａｓｅＡｄｄｒ（ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａへのポインタ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＮＯ＿ＭＥＭＯＲＹ（共有メモリの確保に失敗）がある。
【０２５８】
・ＯＰＥＮＲ：：ＤｅｌｅｔｅＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＤｅｌｅｔｅＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ（ＭｅｍｒｏｒｙＲｅｇｉｏｎＩＤ　ｍｅｍＩＤ）　であり、ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａ　の共有メモリを解放します。仮引数は、ｍｅｍＩＤ（ＯＣｏｍｍａｎｄＶｅｃｔｏｒＤａｔａの共有メモリのＭｅｍｏｒｙＲｅｇｉｏｎＩＤ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）がある。
【０２５９】
・ＯＰＥＮＲ：：ＮｅｗＳｏｕｎｄＶｅｃｔｏｒＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＮｅｗＳｏｕｎｄＶｅｃｔｏｒＤａｔａ（ｓｉｚｅ＿ｔ　ｎｕｍＳｏｕｎｄｓ，　ｓｉｚｅ＿ｔ　ｄａｔａＳｉｚｅ，ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ＊　ｍｅｍＩＤ，　ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａ＊＊　ｂａｓｅＡｄｄｒ）　であり、ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａの共有メモリを確保します。ｖｅｃｔｏｒＩｎｆｏ．ｎｕｍＤａｔａは０に初期化されます。ＳｅｔＮｕｍＤａｔａ（）を使用して有効要素数を設定します。
仮引数は、ｎｕｍＳｏｕｎｄｓ（音声データの要素数）、ｄａｔａＳｉｚｅ（各音声データのサイズ）、ｍｅｍＩＤ（ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａ　の共有メモリのＭｅｍｏｒｙＲｅｇｉｏｎＩＤ）、ｂａｓｅＡｄｄｒ（ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａへのポインタ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＮＯ＿ＭＥＭＯＲＹ（共有メモリの確保に失敗）がある。
【０２６０】
・ＯＰＥＮＲ：：ＤｅｌｅｔｅＳｏｕｎｄＶｅｃｔｏｒＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＤｅｌｅｔｅＳｏｕｎｄＶｅｃｔｏｒＤａｔａ（ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ　ｍｅｍＩＤ）　であり、ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａの共有メモリを解放します。仮引数は、ｍｅｍＩＤ（ＯＳｏｕｎｄＶｅｃｔｏｒＤａｔａの共有メモリのＭｅｍｏｒｙＲｅｇｉｏｎＩＤ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＡＲＧ（不正なｍｅｍＩＤ）、ｏＦＡＩＬ（失敗）がある。
【０２６１】
・ＯＰＥＮＲ：：ＮｅｗＣｄｔＶｅｃｔｏｒＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＮｅｗＣｄｔＶｅｃｔｏｒＤａｔａ（ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ＊　ｍｅｍＩＤ，　ＯＣｄｔＶｅｃｔｏｒＤａｔａ＊＊ｂａｓｅＡｄｄｒ）　であり、ＯＣｄｔＶｅｃｔｏｒＤａｔａの共有メモリを確保します。ｖｅｃｔｏｒＩｎｆｏ．ｎｕｍＤａｔａは０に初期化されます。ＳｅｔＮｕｍＤａｔａ（）を使用して有効要素数を設定します。仮引数は、ｍｅｍＩＤ（ＯＣｄｔＶｅｃｔｏｒＤａｔａの共有メモリのＭｅｍｏｒｙＲｅｇｉｏｎＩＤ）、ｂａｓｅＡｄｄｒ（ＯＣｄｔＶｅｃｔｏｒＤａｔａのポインタ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＮＯ＿ＭＥＭＯＲＹ（共有メモリの確保に失敗）がある。
【０２６２】
・ＯＰＥＮＲ：：ＤｅｌｅｔｅＣｄｔＶｅｃｔｏｒＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＤｅｌｅｔｅＣｄｔＶｅｃｔｏｒＤａｔａ（ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ　ｍｅｍＩＤ）　であり、ＯＣｄｔＶｅｃｔｏｒＤａｔａの共有メモリを解放します。仮引数は、ｍｅｍＩＤ（ＯＣｄｔＶｅｃｔｏｒＤａｔａの共有メモリのＭｅｍｏｒｙＲｅｇｉｏｎＩＤ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）がある。
【０２６３】
・ＯＰＥＮＲ：：ＳｅｔＣｄｔＶｅｃｔｏｒＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＳｅｔＣｄｔＶｅｃｔｏｒＤａｔａ（ＭｅｍｏｒｙＲｅｇｉｏｎＩＤ　ｍｅｍＩＤ）　であり、ＯＣｄｔＶｅｃｔｏｒＤａｔａをＦｂｋＩｍａｇｅＳｅｎｓｏｒに設定します。仮引数は、ｍｅｍＩＤ（ＯＣｄｔＶｅｃｔｏｒＤａｔａの共有メモリのＭｅｍｏｒｙＲｅｇｉｏｎＩＤ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＡＲＧ（不正なＯＣｄｔＩｎｆｏ：：ｃｈａｎｎｅｌ）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｉｅＩＤ）、ｏＩＮＶＡＬＩＤ＿ＤＡＴＡ＿ＴＹＰＥ（ｔｙｐｅがｏｄａｔａＣＤＴ＿ＶＥＣＴＯＲではありません。）、ｏＦＡＩＬ（上記以外の失敗）がある。
【０２６４】
・ＯＰＥＮＲ：：ＥｎａｂｌｅＪｏｉｎｔＧａｉｎ（）
構文は、ＯＳｔａｔｕｓ　ＥｎａｂｌｅＪｏｉｎｔＧａｉｎ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ）　であり、ジョイントのゲインを有効状態にします。ゲインが有効状態の時に、ＯＰＥＮＲ：：ＳｅｔＪｏｉｎｔＧａｉｎ（）　またはＯＰＥＮＲ：：ＳｅｔＤｅｆａｕｌｔＪｏｉｎｔＧａｉｎ（）を実行すると、サーボデバイスにＰＩＤゲインが設定されます。ｐｒｉｍｉｔｉｖｅＩＤにｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＮＤＥＦを指定すると、ＯＰＥＮＲ：：ＯｐｅｎＰｒｉｍｉｔｉｖｅ（）でオープンされているジョイントのゲインが有効状態になります。仮引数は、ｐｒｉｍｉｔｉｖｅＩＤ（ジョイントのＯＰｒｉｍｉｔｉｖｅＩＤまたはｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＤＥＦ）である。また、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｅＩＤ）、ｏＡＬＥＲＴ＿ＪＯＩＮＴ＿ＵＮＣＯＮＴＲＯＬＬＡＢＬＥ（ポテンショが断線していて制御不能）　がある。
【０２６５】
・ＯＰＥＮＲ：：ＤｉｓａｂｌｅＪｏｉｎｔＧａｉｎ（）
構文は、ＯＳｔａｔｕｓ　ＤｉｓａｂｌｅＪｏｉｎｔＧａｉｎ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ）　であり、ジョイントのゲインを０に設定して、ゲインを無効状態にします。ｐｒｉｍｉｔｉｖｅＩＤにｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＮＤＥＦを指定すると、ＯＰＥＮＲ：：ＯｐｅｎＰｒｉｍｉｔｉｖｅ（）　でオープンされているＪｏｉｎｔのゲインを０に設定して、ゲインを無効状態にします。仮引数は、ｐｒｉｍｉｔｉｖｅＩＤ（ジョイントのＯＰｒｉｍｉｔｉｖｅＩＤ　またはｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＤＥＦ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｅＩＤ）、ｏＦＡＩＬ（失敗）がある。
【０２６６】
・ＯＰＥＮＲ：：ＳｅｔＪｏｉｎｔＧａｉｎ（）
構文は、ＯＳｔａｔｕｓ　ＳｅｔＪｏｉｎｔＧａｉｎ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ，ｗｏｒｄ　ｐｇ，　ｗｏｒｄ　ｉｇ，　ｗｏｒｄ　ｄｇ，　ｗｏｒｄ　ｐｓ，　ｗｏｒｄ　ｉｓ，　ｗｏｒｄ　ｄｓ）　であり、ジョイントのゲイン設定を行います。ゲインが無効状態の場合は、ゲインは設定されずにｏＧＡＩＮ＿ＤＩＳＡＢＬＥＤを返します。ｐｒｉｍｉｔｉｖｅＩＤにｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＮＤＥＦ　を指定すると、ＯＰＥＮＲ：：ＯｐｅｎＰｒｉｍｉｔｉｖｅ（）がオープンされているすべてのジョイントのゲインを設定します。ジョイントのゲイン設定に成功するとｏＳＵＣＣＥＳＳ　を返します。仮引数は、ｐｒｉｍｉｔｉｖｅＩＤ（ジョイントのＯＰｒｉｍｉｔｉｖｅＩＤまたはｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＤＥＦ）、ｐｇ（ＰＧＡＩＮ係数）、ｉｇ（ＩＧＡＩＮ係数）、ｄｇ（ＤＧＡＩＮ係数）、ｐｓ（ＰＳＨＩＦＴ係数）、ｉｓ（ＩＳＨＩＦＴ係数）、ｄｓ（ＤＳＨＩＦＴ係数）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（ｐｒｉｍｉｔｉｖｅＩＤが不正）、ｏＧＡＩＮ＿ＤＩＳＡＢＬＥＤ（ゲイン無効状態）、ｏＡＬＥＲＴ＿ＪＯＩＮＴ＿ＵＮＣＯＮＴＲＯＬＬＡＢＬＥ（ポテンショが断線していて制御不能）、ｏＦＡＩＬ（失敗）がある。
【０２６７】
・ＯＰＥＮＲ：：ＲｅｇｉｓｔｅｒＤｅｆａｕｌｔＪｏｉｎｔＧａｉｎ（）
構文は、ＯＳｔａｔｕｓ　ＲｅｇｉｓｔｅｒＤｅｆａｕｌｔＪｏｉｎｔＧａｉｎ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ，ｗｏｒｄ　ｐｇ，　ｗｏｒｄ　ｉｇ，　ｗｏｒｄ　ｄｇ，　ｗｏｒｄ　ｐｓ，　ｗｏｒｄ　ｉｓ，　ｗｏｒｄ　ｄｓ）　であり、ジョイントにデフォルトゲインを登録します。ｐｒｉｍｉｔｉｖｅＩＤにｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＮＤＥＦを指定すると、ＯＰＥＮＲ：：ＯｐｅｎＰｒｉｍｉｔｉｖｅ（）でオープンされているすべてのジョイントにデフォルトゲインを登録します。仮引数は、ｐｒｉｍｉｔｉｖｅＩＤ（ＪｏｉｎｔのＯＰｒｉｍｉｔｉｖｅＩＤまたはｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＤＥＦ）、ｐｇ（ＰＧＡＩＮ係数）、ｉｇ（ＩＧＡＩＮ係数）、ｄｇ（ＤＧＡＩＮ係数）、ｐｓ（ＰＳＨＩＦＴ係数）、ｉｓ（ＩＳＨＩＦＴ係数）、ｄｓ（ＤＳＨＩＦＴ係数）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｅＩＤ）である。
【０２６８】
・ＯＰＥＮＲ：：ＳｅｔＤｅｆａｕｌｔＪｏｉｎｔＧａｉｎ（）
構文は、ＯＳｔａｔｕｓ　ＳｅｔＤｅｆａｕｌｔＪｏｉｎｔＧａｉｎ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ）　であり、登録されているデフォルトゲインをジョイントに設定します。ゲインが無効状態の場合は、ゲインは設定されずにｏＧＡＩＮ＿ＤＩＳＡＢＬＥＤを返します。ｐｒｉｍｉｔｉｖｅＩＤにｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＮＤＥＦを指定すると、ＯＰＥＮＲ：：ＯｐｅｎＰｒｉｍｉｔｉｖｅ（）でオープンされているすべてのジョイントのゲインを設定します。ジョイントのゲイン設定に成功するとｏＳＵＣＣＥＳＳを返します。
仮引数は、ｐｒｉｍｉｔｉｖｅＩＤ（ＪｏｉｎｔのＯＰｒｉｍｉｔｉｖｅＩＤまたはｏｐｒｉｍｉｔｉｖｅＩＤ＿ＵＤＥＦ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｅＩＤ）、ｏＧＡＩＮ＿ＤＩＳＡＢＬＥＤ（ゲイン無効状態）、ｏＡＬＥＲＴ＿ＪＯＩＮＴ＿ＵＮＣＯＮＴＲＯＬＬＡＢＬＥ（ポテンショが断線していて制御不能）、ｏＦＡＩＬ（失敗）がある。
【０２６９】
・ＯＰＥＮＲ：：ＧｅｔＪｏｉｎｔＶａｌｕｅ（）
構文は、ＯＳｔａｔｕｓ　ＧｅｔＪｏｉｎｔＶａｌｕｅ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ，　ＯＪｏｉｎｔＶａｌｕｅ＊　ｖａｌｕｅ）　であり、Ｊｏｉｎｔの現在値を取得します。仮引数は、ｐｒｉｍｉｔｉｖｅＩＤ（ジョイントのＯＰｒｉｍｉｔｉｖｅＩＤ）、ｖａｌｕｅ（ジョイントの現在値）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｅＩＤ）がある。
【０２７０】
・ＯＰＥＮＲ：：ＧｅｔＳｅｎｓｏｒＶａｌｕｅ（）
構文は、ＯＳｔａｔｕｓ　ＧｅｔＪｏｉｎｔＶａｌｕｅ（ＯＰｒｉｍｉｔｉｖｅＩＤ　ｐｒｉｍｉｔｉｖｅＩＤ，　ＯＳｅｎｓｏｒＶａｌｕｅ＊　ｖａｌｕｅ）　であり、センサーの現在値を取得します。仮引数は、ｐｒｉｍｉｔｉｖｅＩＤ（センサーのＯＰｒｉｍｉｔｉｖｅＩＤ）、ｖａｌｕｅ（センサーの現在値）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＰＲＩＭＩＴＩＶＥ＿ＩＤ（不正なｐｒｉｍｉｔｉｖｅＩＤ）がある。
【０２７１】
・ＯＰＥＮＲ：：ＮｅｗＳｙｎｃＫｅｙ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＮｅｗＳｙｎｃＫｅｙ（ＯＶＲＳｙｎｃＫｅｙ＊　ｓｙｎｃＫｅｙ）　であり、ＬＥＤ、サウンド、モーションの開始時の同期をとるために使用します。ＯＰＥＮＲ：：ＮｅｗＳｙｎｃＫｅｙ（）で同期キーを発行し、ＯＰＥＮＲ：：ＤｉｖｉｄｅＳｙｎｃＫｅｙ（）で同期キーをとりたいオブジェクト数に分割して使用します。同期キーの最大数は８　個です。最大数を越えている場合はｓｙｎｃＫｅｙにｏｖｒｓｙｎｃｋｅｙＵＮＤＥＦが入り、ｏＮＯ＿ＳＹＮＣ＿ＫＥＹを返します。仮引数は、ｓｙｎｃＫｅｙ（同期キー）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＮＯ＿ＳＹＮＣ＿ＫＥＹ（最大数８個の同期キーが発行済）がある。
【０２７２】
・ＯＰＥＮＲ：：ＣａｎｃｅｌＳｙｎｃＫｅｙ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＣａｎｃｅｌＳｙｎｃＫｅｙ（ＯＶＲＳｙｎｃＫｅｙ　ｓｙｎｃＫｅｙ）　であり、同期キーをキャンセルします。仮引数は、ｓｙｎｃＫｅｙ（同期キー）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＳＹＮＣ＿ＫＥＹ（不正なｓｙｎｃＫｅｙ）がある。
【０２７３】
・ＯＰＥＮＲ：：ＤｉｖｉｄｅＳｙｎｃＫｅｙ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＤｉｖｉｄｅＳｙｎｃＫｅｙ（ＯＶＲＳｙｎｃＫｅｙ　ｓｙｎｃＫｅｙ，ＯＶＲＳｙｎｃＫｅｙ＊　ｋｅｙ１，　ＯＶＲＳｙｎｃＫｅｙ＊　ｋｅｙ２）であり、同期キーを分割します。仮引数は、ｓｙｎｃＫｅｙ（分割前の同期キー）、ｋｅｙ１、ｋｅｙ２（分割後の同期キー）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）がある。
【０２７４】
・ＯＰＥＮＲ：：ＳｅｔＭｏｔｏｒＰｏｗｅｒ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＳｅｔＭｏｔｏｒＰｏｗｅｒ（ＯＰｏｗｅｒ　ｐｏｗｅｒ）　であり、モーター電源を制御します。ｐｏｗｅｒ　にはｏｐｏｗｅｒＯＮまたはｏｐｏｗｅｒＯＦＦを指定します。仮引数は、ｐｏｗｅｒ（ｏｐｏｗｅｒＯＮまたはｏｐｏｗｅｒＯＦＦ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）がある。
【０２７５】
・ＯＰＥＮＲ：：Ｓｈｕｔｄｏｗｎ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：Ｓｈｕｔｄｏｗｎ（ｃｏｎｓｔ　ＯＢｏｏｔＣｏｎｄｉｔｉｏｎ＆　ｂｏｏｔＣｏｎｄｉｔｉｏｎ）　であり、指定したｂｏｏｔＣｏｎｄｉｔｉｏｉｎを設定して、シャットダウンの処理を開始します。仮引数は、ｂｏｏｔＣｏｎｄｉｔｉｏｎ（ブート条件）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）がある。
【０２７６】
・ＯＰＥＮＲ：：ＧｅｔＢｏｏｔＣｏｎｄｉｔｉｏｎ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＧｅｔＢｏｏｔＣｏｎｄｉｔｉｏｎ（ＯＢｏｏｔＣｏｎｄｉｔｉｏｎ＊　ｂｏｏｔＣｏｎｄｉｔｉｏｎ）　であり、起動要因を取得します。

ここで起動要因は、ｂｉｔｍａｐに格納されます。ｂｏｏｔＴｉｍｅ、ｂａｔｔｅｒｙＣａｐａｃｉｔｙＬｏｗ、ｖｉｂｒａｔｉｏｎＬｅｖｅｌは０になります。起動要因の種類は、以下である。
ｏｂｃｂＢＯＯＴ＿ＴＩＭＥＲ　　　　　　　　＝　０ｘ０００１；　時間で起動
ｏｂｃｂＶＩＢＲＡＴＩＯＮ＿ＤＥＴＥＣＴＥＤ　＝　０ｘ０００２；　振動で起動
ｏｂｃｂＰＡＵＳＥ＿ＳＷ　　　　　　　　　　＝　０ｘ０００４；　ポーズボタンで起動
ｏｂｃｂＳＴＡＴＩＯＮ＿ＣＯＮＮＥＣＴＥＤ　　＝　０ｘ０００８；　ステーション接続で起動
ｏｂｃｂＳＴＡＴＩＯＮ＿ＤＩＳＣＯＮＮＥＣＴＥＤ　＝　０ｘ００１０；　ステーション切断で
ｏｂｃｂＢＡＴＴＥＲＹ＿ＣＡＰＡＣＩＴＹ＿ＦＵＬＬ　＝　０ｘ００２０；　充電完了
ｏｂｃｂＲＥＱ＿ＦＲＯＭ＿ＳＴＡＴＩＯＮ　　　＝　０ｘ００４０；　将来使用予定
仮引数は、ｂｏｏｔＣｏｎｄｉｔｉｏｎ（起動要因）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）がある。
【０２７７】
・ＯＰＥＮＲ：：ＧｅｔＰｏｗｅｒＳｔａｔｕｓ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＧｅｔＰｏｗｅｒＳｔａｔｕｓ（ＯＰｏｗｅｒＳｔａｔｕｓ＊　ｐｏｗｅｒＳｔａｔｕｓ）　であり、以下の構造体で定義されるパワーの状態を取得します。

単位は、以下を使用します。
ｒｅｍａｉｎｉｎｇＣａｐａｃｉｔｙ：バッテリ残量（１％／ｂｉｔ，　０　−　１００％）
ｔｅｍｐｅｒａｔｕｒｅ：バッテリの温度（０．１Ｋｅｌｖｉｎ／ｂｉｔ，　０　−　５００．０Ｋｅｌｖｉｎ）
ｆｕｌｌｙＣｈａｒｇｅｄＣａｐａｃｉｔｙ：満充電時の容量　（ｍＡｈ）
ｖｏｌｔａｇｅ：バッテリの電圧（１ｍＶ／ｂｉｔ，　０　−　６５５３５ｍＶ）
ｃｕｒｒｅｎｔ：バッテリの電流（１ｍＡ／ｂｉｔ，　−３２７６８　−　３２７６７ｍＡ）
ｔｉｍｅＤｉｆ：ＵＴＣ（Ｕｎｉｖｅｒｓａｌ　Ｃｏｏｒｄｉｎａｔｅ　Ｔｉｍｅ）からの時差
ｖｏｌｕｍｅ：ボリューム　０，　１，　２，　３　の何れか
また、仮引数は、ｐｏｗｅｒＳｔａｔｕｓ（パワーの状態）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）がある。
【０２７８】
・ＯＰＥＮＲ：：ＯｂｓｅｒｖｅＰｏｗｅｒＳｔａｔｕｓ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＯｂｓｅｒｖｅＰｏｗｅｒＳｔａｔｕｓ（ｃｏｎｓｔ　ＯＰｏｗｅｒＳｔａｔｕｓ＆　ｎｏｔｉｆｙＳｔａｔｕｓ，　ｃｏｎｓｔ　ＯＳｅｒｖｉｃｅＥｎｔｒｙ＆　ｅｎｔｒｙ）であり、ｎｏｔｉｆｙＳｔａｔｕｓ　で指定したパラメータに変更があればｅｎｔｒｙに通知します。ｎｏｔｉｆｙＳｔａｔｕｓ　のうちｆｕｌｌｙＣｈａｒｇｅｄＣａｐａｃｉｔｙ、ｖｏｌｔａｇｅ、ｃｕｒｒｅｎｔは変更を監視することはできません。　ｒｏｂｏｔＳｔａｔｕｓ、ｂａｔｔｅｒｙＳｔａｔｕｓ　は、指定したビットに変更があれば通知されます。　また、ｒｅｍａｉｎｉｎｇＣａｐａｃｉｔｙ、ｔｅｍｐｅｒａｔｕｒｅ、ｔｉｍｅＤｉｆ、ｖｏｌｕｍｅについては　ＯＰｏｗｅｒ．ｈ　において以下のような記号定数を定義し、ｏｐｓｏ＊＿ＮＯＴＩＦＹ＿ＥＶＥＲＹ＿ＣＨＡＮＧＥ　では変更があれば通知して、ｏｐｓｏ＊＿ＮＯＴ＿ＮＯＴＩＦＹ　では通知せず、それ以外の値では指定した値になったときに通知します。　通知されるメッセージの構造体はＯＰｏｗｅｒＳｔａｔｕｓＭｅｓｓａｇｅです。
【０２７９】
ＯＰｏｗｅｒ．ｈで定義されている記号定数には、以下のものがある。
ｃｏｎｓｔ　ｗｏｒｄ　ｏｐｓｏＴＥＭＰＥＲＡＴＵＲＥ＿ＮＯＴＩＦＹ＿ＥＶＥＲＹ＿ＣＨＡＮＧＥ　＝　０ｘＦＦＦＦ；
ｃｏｎｓｔ　ｗｏｒｄ　ｏｐｓｏＴＥＭＰＥＲＡＴＵＲＥ＿ＮＯＴ＿ＮＯＴＩＦＹ　＝　０ｘＦＦＦＥ；
ｃｏｎｓｔ　ｗｏｒｄ　ｏｐｓｏＲＥＭＡＩＮＩＮＧ＿ＣＡＰＡＣＩＴＹ＿ＮＯＴＩＦＹ＿ＥＶＥＲＹ＿ＣＨＡＮＧＥ　＝　０ｘＦＦＦＦ；
ｃｏｎｓｔ　ｗｏｒｄ　ｏｐｓｏＲＥＭＡＩＮＩＮＧ＿ＮＯＴ＿ＮＯＴＩＦＹ　＝　０ｘＦＦＦＥ；
ｃｏｎｓｔ　ｓｂｙｔｅ　ｏｐｓｏＴＩＭＥ＿ＤＩＦ＿ＮＯＴＩＦＹ＿ＥＶＥＲＹ＿ＣＨＡＮＧＥ　＝　０ｘＦＦ；
ｃｏｎｓｔ　ｓｂｙｔｅ　ｏｐｓｏＴＩＭＥ＿ＤＩＦ＿ＮＯＴ＿ＮＯＴＩＦＹ＝　０ｘＦＥ；
ｃｏｎｓｔ　ｓｂｙｔｅ　ｏｐｓｏＶＯＬＵＭＥ＿ＮＯＴＩＦＹ＿ＥＶＥＲＹ＿ＣＨＡＮＧＥ＝　０ｘＦＦ；
ｃｏｎｓｔ　ｓｂｙｔｅ　ｏｐｓｏＶＯＬＵＭＥ＿ＮＯＴ＿ＮＯＴＩＦＹ＝　０ｘＦＥ；
【０２８０】
一度ＯｂｓｅｒｖｅＰｏｗｅｒＳｔａｔｕｓ（）　を実行すると、ＯＰＥＮＲ：：ＵｎｏｂｓｅｒｖｅＰｏｗｅｒＳｔａｔｕｓ（）　を実行するまで、指定したｎｏｔｉｆｙＳｔａｔｕｓになったときに通知されます。ｎｏｔｉｆｙＳｔａｔｕｓのｒｏｂｏｔＳｔａｔｕｓ、ｂａｔｔｅｒｙＳｔａｔｕｓの各ビットについては立ち上がり、立ち下がり両エッジで　ｎｏｔｉｆｙが通知されます。ｒｅｍａｉｎｉｎｇＣａｐａｃｉｔｙ、ｔｅｍｐｅｒａｔｕｒｅ、ｔｉｍｅＤｉｆ、ｖｏｌｕｍｅについては値が変更される、もしくは指定した値になったら通知されます。　値を指定したときはその値になったときに通知され、その値から変更されたときには通知されません。　また、指定した値が変更されないときも通知されません。
【０２８１】
ここで仮引数は、ｎｏｔｉｆｙＳｔａｔｕｓ（変更を通知してほしいパラメーターを指定した　ＯＰｏｗｅｒＳｔａｔｕｓ構造体）、ｅｎｔｒｙ（変更が通知されるエントリ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）がある。
【０２８２】
・ＯＰＥＮＲ：：ＵｎｏｂｓｅｒｖｅＰｏｗｅｒＳｔａｔｕｓ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＵｎｏｂｓｅｒｖｅＰｏｗｅｒＳｔａｔｕｓ（ｃｏｎｓｔ　ＯＳｅｒｖｉｃｅＥｎｔｒｙ＆　ｅｎｔｒｙ）　であり、ＯＰＥＮＲ：：ＯｂｓｅｒｖｅＰｏｗｅｒＳｔａｔｕｓ（）の監視要求を取り消します。仮引数は、ｅｎｔｒｙ（監視要求を取り消すエントリ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）、ｏＩＮＶＡＬＩＤ＿ＡＲＧ（不正なｅｎｔｒｙ）がある。
【０２８３】
・ＯＰＥＮＲ：：ＦｉｎｄＤｅｓｉｇｎＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＦｉｎｄＤｅｓｉｇｎＤａｔａ（ｃｏｎｓｔ　ｃｈａｒ＊　ｋｅｙｗｏｒｄ，ＯＤｅｓｉｇｎＤａｔａＩＤ＊ｄａｔａＩＤ，　ｂｙｔｅ＊＊　ｄａｔａ，　ｓｉｚｅ＿ｔ＊　ｓｉｚｅ）　であり、デザインデータベースのｋｅｙｗｏｒｄに対応するファイルを検索します。見つかった場合は共有メモリに読み込んでＯＤｅｓｉｇｎＤａｔａＩＤと先頭アドレスを返します。予約キーワード　「ＳＹＳ＿ＣＰＵＩＮＦＯ」　で引数を呼び出すと　ＣＰＵ　の動作周波数を取得することができます。　ＯＣＰＵＩｎｆｏ　の先頭アドレスを返します。このキーワード’ＳＹＳ＿ＣＰＵＩＮＦＯ’は、ＤＥＳＩＧＮＤＢ．ＣＦＧに登録されていなくても使用できます。

仮引数は、ｋｅｙｗｏｒｄ（デザインデータベースを検索するキーワード）、ｄａｔａＩＤ（デザインデータのＩＤ）、ｄａｔａ（デザインデータの先頭アドレス）、ｓｉｚｅ（デザインデータのサイズ）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＮＯＴ＿ＦＯＵＮＤ（ｋｅｙｗｏｒｄまたはデザインデータの実体が存在しません。）、ｏＤＥＳＩＧＮＤＡＴＡ＿ＳＩＺＥ＿ＺＥＲＯ（デザインデータのファイルサイズが０）、ｏＮＯ＿ＭＥＭＯＲＹ（メモリが足りません。）、ｏＦＡＩＬ（失敗）がある。
【０２８４】
・ＯＰＥＮＲ：：ＤｅｌｅｔｅＤｅｓｉｇｎＤａｔａ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＤｅｌｅｔｅＤｅｓｉｇｎＤａｔａ（ＯＤｅｓｉｇｎＤａｔａＩＤ　ｄａｔａＩＤ）　であり、デザインデータのメモリを解放します。仮引数は、ｄａｔａＩＤ（デザインデータのＩＤ）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＩＮＶＡＬＩＤ＿ＡＲＧ（不正なｄａｔａＩＤ）、ｏＦＡＩＬ（失敗）がある。
【０２８５】
・ＯＰＥＮＲ：：ＧｅｔＲｏｂｏｔＤｅｓｉｇｎ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＧｅｔＲｏｂｏｔＤｅｓｉｇｎ（ｃｈａｒ＊　ｒｏｂｏｔＤｅｓｉｇｎ）　であり、ロボットデザインを取得します。仮引数は、ｒｏｂｏｔＤｅｓｉｇｎ（ロボットデザイン）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）がある。
【０２８６】
・ＯＰＥＮＲ：：ＧｅｔＭｅｍｏｒｙＳｔｉｃｋＳｔａｔｕｓ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＧｅｔＭｅｍｏｒｙＳｔｉｃｋＳｔａｔｕｓ（ＯＭｅｍｏｒｙＳｔｉｃｋＳｔａｔｕｓ＊　ｓｔａｔｕｓ）　であり、メモリスティックの状態を調べます。ｏｍｅｍｏｒｙｓｔｉｃｋＮＯＴ＿ＥＸＩＳＴであれば、メモリスティックが存在しないことを示す。ｏｍｅｍｏｒｙｓｔｉｃｋＷＲＩＴＥ＿ＰＲＯＴＥＣＴＥＤであれば、ライトプロテクトスイッチＯＮを示す。また、ｏｍｅｍｏｒｙｓｔｉｃｋＷＲＩＴＡＢＬＥであれば、ライトプロテクトスイッチＯＦＦを示す。仮引数は、ｓｔａｔｕｓ（メモリスティックの状態）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）がある。
【０２８７】
・ＯＰＥＮＲ：：Ｆａｔａｌ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：Ｆａｔａｌ（ＯＦａｔａｌ　ｆａｔａｌ）　であり、ＢＭＮマイコンのブザーで、警告音を鳴らしてから電源ＯＦＦにします。ｆａｔａｌで警告音の種類を指定します。仮引数は、ｆａｔａｌ（警告音の種類。現在はｏｆａｔａｌＭＥＭＯＲＹ＿ＳＴＩＣＹのみをサポートしています。）であり、ｏｆａｔａｌＵＮＤＥＦは、トッカータとフーガを示し、ｏｆａｔａｌＭＥＭＯＲＹ＿ＳＴＩＣＫは、メモリスティック破壊エラー音であり、ｏｆａｔａｌＰＡＵＳＥ＿ＳＷは、無音である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）がある。
【０２８８】
・ＯＰＥＮＲ：：ＳｅｔＴｉｍｅ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＳｅｔＴｉｍｅ（ｃｏｎｓｔ　ＯＴｉｍｅ＆　ｔｉｍｅ）　であり、ＲＴＣの時刻をｔｉｍｅで指定した時刻に設定します。ｔｉｍｅに−１２から＋１２までの値で、かつ現在の時差と異なる時差が設定されている場合は、時差もＢＭＮマイコンに設定されます。仮引数は、ｔｉｍｅ（時刻および時差）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）がある。
【０２８９】
・ＯＰＥＮＲ：：ＧｅｔＴｉｍｅ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＧｅｔＴｉｍｅ（ＯＴｉｍｅ＊　ｔｉｍｅ）　であり、時刻および時差を取得します。仮引数は、ｔｉｍｅ（時刻および時差の構造体）である。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）がある。
【０２９０】
・ＯＰＥＮＲ：：ＳｅｔＴｉｍｅＤｉｆｆｅｒｅｎｃｅ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＳｅｔＴｉｍｅＤｉｆｆｅｒｅｎｃｅ（ｓｂｙｔｅ　ｔｉｍｅＤｉｆｆｅｒｅｎｃｅ）　であり、時差を設定します。仮引数は、ｔｉｍｅＤｉｆｆｅｒｅｎｃｅ（時差）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）がある。
【０２９１】
・ＯＰＥＮＲ：：ＧｅｔＴｉｍｅＤｉｆｆｅｒｅｎｃｅ（）
構文は、ＯＳｔａｔｕｓ　ＯＰＥＮＲ：：ＧｅｔＴｉｍｅＤｉｆｆｅｒｅｎｃｅ（ｓｂｙｔｅ＊　ｔｉｍｅＤｉｆｆｅｒｅｎｃｅ）　であり、時差を取得します。仮引数は、ｔｉｍｅＤｉｆｆｅｒｅｎｃｅ（時差）であり、戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）、ｏＮＯＴ＿ＦＯＵＮＤ（システムオブジェクトが存在しません。）がある。
【０２９２】
・ＯＰＥＮＲ：：ＳｅｔＶｏｌｕｍｅＳｗｉｔｃｈ（）
構文は、ＯＳｔａｔｕｓ　ＳｅｔＶｏｌｕｍｅＳｗｉｔｃｈ（ＯＶｏｌｕｍｅＳｗｉｔｃｈ　ｖｏｌＳＷ）　であり、ボリュームスイッチのレベルを設定します。仮引数は、ｖｏｌＳＷ（ボリュームスイッチのレベル）であり、ｏｖｏｌｕｍｅＳＷ０、ｏｖｏｌｕｍｅＳＷ１、ｏｖｏｌｕｍｅＳＷ２、ｏｖｏｌｕｍｅＳＷ３がある。また、戻り値は、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）である。
【０２９３】
・ＯＰＥＮＲ：：ＧｅｔＶｏｌｕｍｅＳｗｉｔｃｈ（）
構文は、ＯＳｔａｔｕｓ　ＧｅｔＶｏｌｕｍｅＳｗｉｔｃｈ（ＯＶｏｌｕｍｅＳｗｉｔｃｈ＊　ｖｏｌＳＷ）　であり、ボリュームスイッチのレベルを取得します。仮引数は、ｖｏｌＳＷ（ボリュームスイッチのレベル）であり、ｏｖｏｌｕｍｅＳＷ０、ｏｖｏｌｕｍｅＳＷ１、ｏｖｏｌｕｍｅＳＷ２、ｏｖｏｌｕｍｅＳＷ３がある。戻り値には、ｏＳＵＣＣＥＳＳ（成功）、ｏＦＡＩＬ（失敗）がある。
【０２９４】
＜インターネットプロトコル＞
続いて、ＯＰＥＮ−Ｒ　１．１．３が動作しているＯＰＥＮ−Ｒにおいて実装されているインターネットプロトコル第４版（ＩＰｖ４）について解説します。本バージョンのＩＰｖ４には４個のネットワークプロトコル、すなわちＴＣＰ、ＵＤＰ、ＩＰ及びＤＮＳのクライアント側が含まれています。本書は、ＩＰｖ４プログラマーズガイドと、ＩＰｖ４リファレンスガイドの２部から構成されています。
ＩＰｖ４プログラマーズガイドは、ＯＰＥＮ−Ｒ上のネットワーキング及びＩＰｖ４プロトコルスタックの紹介です。ＯＰＥＮ−ＲオブジェクトがスタックにおけるＴＣＰ、ＵＤＰ、ＤＮＳ、ＩＰのサービスをどのように使用するかを詳細に説明します。また、ＩＰｖ４リファレンスガイドは、すべてのクラス及びメッセージ、エラー、操作の詳細な説明です。これらはＩＰｖ４プロトコルスタックと通信するオブジェクトを書くときに必要です。
【０２９５】
以降の説明では、ＯＰＥＮ−Ｒオブジェクトのことを単にオブジェクトと呼びます。また、通信においてリモート側がＯＰＥＮ−Ｒではない場合、例えばＵｎｉｘの場合にはオブジェクトの代わりにプロセスと呼ぶ方が適切ですが、ここではこれらを総称してオブジェクトという語を使用しています。
【０２９６】
ＩＰｖ４プログラマーズガイド
第１章　ＩＰｖ４プロトコルスタック
この章では、ＩＰｖ４プロトコルスタックの現行バージョンに含まれる各プロトコルを記述し、ＯＰＥＮ−Ｒ上の実装であるＩＰＳｔａｃｋを紹介し、オブジェクトとプロトコルスタックとの間の通信方法について説明します。
【０２９７】
１．１　ＩＰｖ４プロトコルスタックのプロトコル
インターネットプロトコル（ＩＰ）は、インターネットで使用されるホスト間のデータ送信用のプロトコルです。ＩＰバージョン４（ＩＰｖ４）は、現在最も広く使用されており、ＯＰＥＮ−Ｒ上で利用できます。ＯＰＥＮ−Ｒ上のＩＰｖ４プロトコルスタックには、基本的なＩＰプロトコルを補足するいくつかのプロトコルが含まれています。現行バージョンのＩＰｖ４プロトコルスタックには以下のプロトコルが含まれています。
【０２９８】
（１）ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ、インターネットプロトコル）：インターネット上でデータグラムを送信する役割を果たす基本プロトコルです。パケット指向、コネクションレス型のプロトコルで、ＩＰデータグラムの信頼性保証のない転送を行います。
【０２９９】
（２）ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ、伝送制御プロトコル）：ＩＰプロトコルの上で動作します。オブジェクトに、コネクション指向で信頼性保証のあるバイトストリームサービスを提供します。
【０３００】
（３）ＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ、ユーザーデータグラムプロトコル）：ＩＰプロトコル上で動作します。オブジェクトに信頼性保証のないデータグラム配送サービスを提供します。
【０３０１】
（４）ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ、ドメインネームシステム）：ドメインネームをＩＰアドレスに、またはＩＰアドレスをドメインネームにマップするサービスです。
【０３０２】
１．２　ＩＰｖ４プロトコルスタック
ＯＰＥＮ−Ｒでは、ＩＰｖ４プロトコルスタックは、Ａｐｅｒｉｏｓ　Ｎｅｔｗｏｒｋｉｎｇ　Ｔｏｏｌｋｉｔ（ＡＮＴ）を使用して実装されています。プロトコルスタックは、実行時にＩＰＳｔａｃｋ内に存在し、そこにはＡＮＴ実行時環境も含まれています。ＩＰＳｔａｃｋは、ＯＰＥＮ−Ｒシステム層のオブジェクトです。また、ＩＰＳｔａｃｋは、メッセージパッシング（ｍｅｓｓａｇｅ　ｐａｓｓｉｎｇ）を使用してオブジェクトやデバイスドライバーと通信します。以下の図１７は、ＯＰＥＮ−Ｒ上におけるＩＰＳｔａｃｋのネットワークサービスを示している。
【０３０３】
１．３　オブジェクトがプロトコルスタックと通信する方法
オブジェクトは、ＩＰｖ４プロトコルスタックが提供するネットワークサービスを利用することができます。オブジェクトは、通常のメッセージパッシングを使用してＩＰＳｔａｃｋとの間で特別なメッセージを送受信することにより、プロトコルスタックと通信します。オブジェクトが最初に実行するのは、ＩＰＳｔａｃｋにエンドポイント（ｅｎｄｐｏｉｎｔ）の作成を依頼することです。エンドポイントは特殊なＡＮＴ構成体で、プロトコルスタックの最上位にあり、オブジェクトとスタックとの通信を請け負います。通常、オブジェクトには、ネットワークコネクションごとに１つのエンドポイントが必要となります。例えば、ＴＣＰコネクションとＵＤＰコネクションを通じてデータを送信するオブジェクトは、２つのエンドポイント（図１８を参照）が必要です。２つのＴＣＰコネクションを通じてデータを送信する場合も同様で、オブジェクトには２つのエンドポイントが必要です。新規のエンドポイントの作成方法については後述します。図１８は、オブジェクトが、ＩＰスタックのエンドポイントに対してネットワークサービス要求を送り、エンドポイントを使用してＩＰｖ４プロトコルスタックにアクセスする様子を示している。
【０３０４】
エンドポイントに加えて、オブジェクトは、１個以上の共有メモリーバッファを作成します。共有メモリーバッファは、オブジェクトとＩＰｖ４プロトコルスタック間のデータ交換に必要です。オブジェクトとプロトコルスタックは、必ずしも同一アドレス空間を共有していませんので、転送するデータへのポインタを交換することはできません。ＡｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって実装された共有メモリーバッファは、共通のメモリー領域を２つのオブジェクトのアドレス空間にマップします。共有メモリーバッファの作成方法は後述します。ＩＰＳｔａｃｋに送られるすべてのメッセージは、ａｎｔＥｎｖＭｓｇ構造体から継承しています。この構造体は、Ｓｅｎｄ（）やＣａｌｌ（）などの基本的なメッセージハンドリング関数を提供します。プロトコルが行う各サービスは、特有の継承したメッセージ型を持っています。例えば、ＴＣＰでデータ送信する要求はＴＣＰＥｎｄＰｏｉｎｔＳｅｎｄＭｓｇによって作成され、ＵＤＰコネクションをバインドする要求はＵＤＰＥｎｄＰｏｉｎｔＢｉｎｄＭｓｇによって作成されます。
【０３０５】
新エンドポイントを作成する
ＩＰスタック内のいずれかのプロトコルの新規のエンドポイントを作成するには、オブジェクトはａｎｔＥｎｖＣｒｅａｔｅＥｎｄｐｏｉｎｔＭｓｇをＩＰＳｔａｃｋに送ります。オブジェクトはａｎｔＥｎｖＣｒｅａｔｅＥｎｄｐｏｉｎｔＭｓｇのなかで、エンドポイントを必要とするプロトコルの種別と、エンドポイントのＳＤＵプールに割り当てるメモリー容量を指定します。ＩＰＳｔａｃｋは、指定されたプロトコルのための新規エンドポイントを作成し、ａｎｔＥｎｖＣｒｅａｔｅＥｎｄｐｏｉｎｔＭｓｇの結果メッセージを返します。このメッセージのなかのＭｏｄｕｌｅＲｅｆ仮引数には、新規のエンドポイントへの参照が格納されています。以下の例では、オブジェクトは新規のＴＣＰエンドポイントを作成します。この方法はＩＰＳｔａｃｋの他のプロトコルの場合も、オブジェクトが異なる型のエンドポイントを指定することを除き、全く同様です。
【０３０６】
最初に、以下のようにオブジェクトは新規のＴＣＰエンドポイントを要求するメッセージを作成します。

このとき、以下のエンドポイントの型が使用できます。
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＴＣＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＵＤＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＤＮＳ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＩＰ
この例のオブジェクトは、パケットサイズの４倍の大きさ（４＊ＰＡＣＫＥＴＳＩＺＥ）のＳＤＵプールを要求している。ＳＤＵプールは、データをプロトコルスタックに格納する内部ＡＮＴ構成体です。指針として、送信しようとする最大のパケットより少し大きいＳＤＵプールを常に作成することが好ましいです。例えば８ＫＢのパケットの場合は、約１０ＫＢのＳＤＵプールが必要です。
【０３０７】
オブジェクトは、メッセージをＩＰＳｔａｃｋに送ります。

Ｃａｌｌ（）は、ａｎｔＥｎｖＭｓｇから継承しています。ＩＰＳｔａｃｋを指すａｎｔＳｔａｃｋＲｅｆ（ＩＰＳｔａｃｋＲｅｆ）とメッセージの大きさを指定します。Ｃａｌｌ（）は同期型のメッセージパッシングを行うので、オブジェクトは結果メッセージを受け取るまで動作を中断します。結果メッセージを受け取ると、オブジェクトは新規のエンドポイントに対する参照を取得します。
【０３０８】
ｅｎｄｐｏｉｎｔ　＝　ｃｒｅａｔｅＭｓｇ．ｍｏｄｕｌｅＲｅｆ；
この参照によって、オブジェクトは、新規のエンドポイントと通信ができるようになります。オブジェクトはエンドポイント対してＴＣＰプロトコルの提供する、コネクション、リッスン、送信、受信、クローズなどのサービスを要求するメッセージを送ることができます。他のプロトコルでは提供するサービスは異なります。
【０３０９】
共有メモリーバッファを作成する
共有メモリーバッファはａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって実装されています。このバッファは、共有メモリー領域をオブジェクトとプロトコルスタックのアドレス空間にマップします。オブジェクトがプロトコルスタックとデータを交換する場合は、そのデータは共有バッファへのポインタとバッファ内のオフセットとによって識別されます。ａｎｔＳｈａｒｅｄＢｕｆｆｅｒは、図１９に示すとおり、このオフセットをオブジェクトのアドレス空間内のある位置に自動的に変換します。図１９には、共有メモリーバッファがメモリー領域をオブジェクトとプロトコルスタックのアドレス空間にマップする様子が示されている。これにより、データへのポインタのやりとりを可能にします。オブジェクトは、１個の共有バッファを作成しても、データの送信や受信のような特定の操作ごとに複数のバッファを作成してもかまいません。
【０３１０】
また、共有バッファの割当と開放は、共有メモリー管理ルーチンによって行われます。これらのルーチンは、実行に時間がかかります。したがって、共有バッファの作成及び削除は、必要なときのみ行い、できる限り既存のバッファを再使用するようにしてください。通常、個々の新規のエンドポイントごとに送信バッファと受信バッファを作成し、エンドポイントでの以後の送受信操作にはバッファを再使用します。共有バッファのサイズに関して、いくつかの制限事項があります。通常、要求されたサイズは、ＯＰＥＮ−Ｒ上のページサイズの一番近い倍数に切り上げられます。ＯＰＥＮ−Ｒのページサイズはメモリー保護モードの場合には４０９６バイトです。例えば、７０００バイトの共有バッファを要求すると、バッファは８１９２バイト（４０９６＊２）になります。共有バッファの使い方は様々ですが、個々のオブジェクトでの必要に応じて、どのように使用されるかが決まります。
【０３１１】
共有バッファを作成するには、オブジェクトは、バッファのサイズを指定してａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇをＩＰＳｔａｃｋに送ります。このときＩＰＳｔａｃｋは、共有バッファを作成し、ａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇに返事を返します。結果メッセージのｂｕｆｆｅｒ仮引数には、新規のａｎｔＳｈａｒｅｄＢｕｆｆｅｒへの参照が格納されています。その後、オブジェクトはａｎｔＳｈａｒｅｄＢｕｆｆｅｒ：：Ｍａｐ（）を呼び出して、バッファをそのアドレス空間にマップします。ａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇ及びａｎｔＳｈａｒｅｄＢｕｆｆｅｒについては、「第６章　ＡＮＴ環境リファレンス」を参照してください。
【０３１２】
以下の例では、ＴＣＰクライアントのオブジェクトは、２つの共有バッファを作成します。１つはデータ送信用であり、もう１つは、データ受信用です。最初に、オブジェクトは新規の共有バッファを要求するメッセージを作成します。
ａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇ　ｂｕｆｆｅｒＭｓｇ（ＰＡＣＫＥＴＳＩＺＥ）；
指定したバッファサイズは、バケットサイズと同一です。これは、オブジェクトとプロトコルスタックとのデータ交換は１回に１個のパケットで行われるためです。指針として、共有メモリーバッファは、オブジェクトが送受信する最大のパケットを保持する必要があります。
【０３１３】
ここで、オブジェクトはメッセージをＩＰＳｔａｃｋに送ります。

Ｃａｌｌ（）は、ａｎｔＥｎｖＭｓｇから継承しています。ＩＰＳｔａｃｋを指すａｎｔＳｔａｃｋＲｅｆ（ＩＰＳｔａｃｋＲｅｆ）とメッセージのサイズを指定します。Ｃａｌｌ（）は同期型のメッセージパッシングを行うので、オブジェクトは結果メッセージを受け取るまで動作を中断します。オブジェクトは返事を受け取ると、新規の共有バッファに対する参照を取得し、それを送信バッファとして定義します。
ｓｅｎｄＢｕｆｆｅｒ　＝　ｂｕｆｆｅｒＭｓｇ．ｂｕｆｆｅｒ；
最後に、オブジェクトは共有バッファを自分のアドレス空間にマップします。
ｓｅｎｄＢｕｆｆｅｒ．Ｍａｐ（）
受信バッファを作成するために、オブジェクトは、ＩＰＳｔａｃｋにａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇを再度送って、上記の手順を繰り返します。

オブジェクトがデータをプロトコルスタックに送信するとき、オブジェクトは、送信バッファ内のデータに対するポインタを送ります。プロトコルスタックからデータを受信するとき、受信バッファの該当データに対するポインタを受けとります。ＡｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体は、これらのポインタをオブジェクトまたはプロトコルスタックのアドレス空間の位置に自動的に変換します。
【０３１４】
ネットワークサービスを要求する
ＩＰプロトコルスタックのいずれかのプロトコルからのサービスを要求するには、オブジェクトはメッセージを作成し、それをＩＰＳｔａｃｋ内の該当するエンドポイントに送ります。メッセージの型によって、要求されているサービスを識別します。メッセージの内容には、サービスを実行するのに必要な情報（ＩＰアドレス、ポート番号、共有バッファ内のデータへのポインタなど）が含まれています。
【０３１５】
各プロトコルは、ａｎｔＥｎｖＭｓｇから継承したメッセージの独自のセットを提供します。これらのメッセージについては、「第２部　ＩＰｖ４リファレンスガイド」のＴＣＰ、ＵＤＰ、ＤＮＳ、ＩＰの項を参照してください。
【０３１６】
以下の例では、オブジェクトは他方のホストへのＴＣＰコネクションをオープンします。まず、オブジェクトは、コネクションを要求するメッセージを作成します。

最初の仮引数のｅｎｄｐｏｉｎｔは、メッセージが送られるＴＣＰエンドポイントを識別します。次の２つの仮引数（ゼロ）は、コネクションが確立されたときにローカルＩＰアドレスとポート番号を返します。最後の２つの仮引数は、コネクション先ホストのＩＰアドレスとポート番号を指定します。
【０３１７】
次に、オブジェクトは、このメッセージをＩＰＳｔａｃｋのＴＣＰエンドポイントへ送ります。

Ｃａｌｌ（）は、ａｎｔＥｎｖＭｓｇから継承しています。ＩＰＳｔａｃｋを指すａｎｔＳｔａｃｋＲｅｆ（ＩＰＳｔａｃｋＲｅｆ）とメッセージのサイズを指定します。Ｃａｌｌ（）は同期型のメッセージパッシングを行うので、オブジェクトは結果メッセージを受け取るまで動作を中断します。
【０３１８】
第２章　ＴＣＰガイド
この章では、ＯＰＥＮ−Ｒ上のＴＣＰプロトコルを紹介し、オブジェクトがＩＰｖ４プロトコルスタックの提供するＴＣＰサービスを使用する方法を説明します。
２．１　ＴＣＰ
ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ、伝送制御プロトコル）は、ＩＰｖ４プロトコルスタックのＩＰ層の上位で動作します。ＴＣＰは、オブジェクトに信頼性保証のあるバイトストリームサービスを提供します。ＴＣＰは、コネクション指向のプロトコルです。したがって、送受信するオブジェクトは、コネクションを確立してからデータ転送を行います。
【０３１９】
ＴＣＰネットワーク操作
ＯＰＥＮ−Ｒでは、ＩＰｖ４プロトコルスタックはオブジェクトに対して、以下のＴＣＰ操作を提供します。
Ｃｏｎｎｅｃｔ：別のホスト上のサーバ（プログラム）へのＴＣＰコネクションをオープンします。
Ｌｉｓｔｅｎ：コネクション要求のリッスンを開始します。主として、この操作はコネクション操作の代わりにサーバのオブジェクトによって実行されます。通常、サーバのオブジェクトは、クライアント（プログラム）からのＴＣＰコネクション要求を受け入れます。
Ｓｅｎｄ：オープンされたコネクションでデータを送ります。
Ｒｅｃｅｉｖｅ：オープンされたコネクションでデータを受け取ります。
Ｃｌｏｓｅ：ＴＣＰコネクションをクローズします。
オブジェクトは、ＩＰＳｔａｃｋのＴＣＰエンドポイントに特別のメッセージを送ることによって、これらの操作を実行します。これらのメッセージは、ＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｅｓｓａｇｅを継承し、さらに後者はａｎｔＥｎｖＭｓｇを継承しています。これらのメッセージについては「第７章　ＴＣＰリファレンス」を参照してください。
【０３２０】
オブジェクトがどのようにエンドポイントを作成し、ネットワークサービスを要求するかについては、「１．３　オブジェクトがプロトコルスタックと通信する方法」を参照してください。
【０３２１】
ＴＣＰエンドポイントのライフサイクル
図２０は、ＴＣＰエンドポイントのライフサイクルの状態遷移です。これらの遷移は、ＴＣＰコネクション中のイベントと操作の起こりうるシーケンスを示しています。図２０に示すメッセージの型については、「第２部　ＩＰｖ４リファレンスガイド」で詳しく説明しています。オブジェクトは、オープンされたネットワークコネクションごとに１つのエンドポイントを必要とします。コネクションが確立されている場合は、新規のコネクションを要求することはできません。オブジェクトは、まず新規のエンドポイントを作成する必要があります。エンドポイントは、同種の操作を一度に１回しか実行できません。例えば、ＴＣＰＥｎｄｐｏｉｎｔＬｉｓｔｅｎＭｓｇをすでにリッスンしているエンドポイントに送ると、そのエンドポイントはＴＣＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＢＵＳＹエラーまたはＴＣＰ＿ＯＰＥＲＡＴＩＯＮ＿ＩＮＶＡＬＩＤエラーを返します。しかし、送受信の操作を同時に行うことは可能です。
【０３２２】
２．２　ＴＣＰエンドポイントを作成する
ＴＣＰコネクションをオープンする前に、オブジェクトは新規のＴＣＰエンドポイントを作成する必要が有ります。オブジェクトは、オープンするＴＣＰコネクションごとに１つの新規のエンドポイントを必要とします。エンドポイントを作成する手順は、ＩＰスタック内のすべてのプロトコルについても同様です。
【０３２３】
２．３　コネクションを確立する（クライアント側）
クライアントのオブジェクトがサーバとＴＣＰコネクションを確立するには、ＴＣＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。このメッセージにおける仮引数には、以下のものがある。
ＩＰＡｄｄｒｅｓｓｌＡｄｄｒｅｓｓ：（出力）コネクションが確立されるとローカルＩＰアドレスを返す。
ＰｏｒｔｌＰｏｒｔ：（出力）コネクションが確立されるとクライアントのオブジェクトに割り当てられた一時的なポート番号を返す。
ＩＰＡｄｄｒｅｓｓｆＡｄｄｒｅｓｓ：（入力）コネクションするホストのＩＰアドレスである。
ＰｏｒｔｆＰｏｒｔ：（入力）コネクションするオブジェクトのポート番号ある。
コネクションが確立されると、ＴＣＰエンドポイントは、完全に特定されたＩＰアドレスとポート番号を返します。２つのホスト上のオブジェクトは、コネクションの確立後にデータの送受信を行うことができます。
【０３２４】
２．４　コネクション要求のリッスン（サーバ側）
サーバのオブジェクトは、クライアントのオブジェクトからのコネクション要求を受け入れます。そのためには、サーバのオブジェクトは要求を常時モニター（リッスン）して、要求を受け取ったときだけコネクションを確立する必要が有ります。通常は、特定のポート番号へのコネクション要求だけ受け入れます。例えば、ＦＴＰサーバはＦＴＰポート（２１）上のコネクションだけを受け入れます。サーバのオブジェクトが複数のクライアントを同時に扱うためには、２つ以上のリッスン操作を同時並行に実行する必要があります。各リッスン操作は同じポート番号上のコネクション要求を待ちます。サーバのオブジェクトは、各リッスン操作ごとに別々のエンドポイントが必要です。コネクション要求に対してリッスンを開始するには、サーバのオブジェクトはＴＣＰＥｎｄｐｏｉｎｔＬｉｓｔｅｎＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。
【０３２５】
このメッセージの仮引数には、以下のものがある。
ＩＰＡｄｄｒｅｓｓｌ　Ａｄｄｒｅｓｓ：（出力）コネクションが確立されたときに、ローカルＩＰアドレスを返す。
Ｐｏｒｔｌ　Ｐｏｒｔ：（入力）コネクション要求を受け入れるポート番号である。任意のポートへのコネクション要求を受け入れる場合は、ＩＰ＿ＰＯＲＴ＿ＡＮＹの値を指定する。
ＩＰＡｄｄｒｅｓｓｆ　Ａｄｄｒｅｓｓ：（出力）コネクションを要求したホストのＩＰアドレスを返す。
Ｐｏｒｔｆ　Ｐｏｒｔ：（出力）コネクションを要求したオブジェクトのポート番号を返す。
コネクション要求を受け取ると、ＴＣＰエンドポイントは、コネクションを確立して、完全に特定されたＩＰアドレスとポート番号を返します。
【０３２６】
２．５　データを送信する
オープンしたＴＣＰコネクションでデータを送信するには、オブジェクトはＴＣＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。このメッセージの仮引数は、以下の通りである。
ｂｕｆｆｅｒ：（入力）送信するデータへのポインタである。データは、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって定義された共有メモリーバッファに格納しておきます。
ｓｉｚｅ：（入力）送信するデータのサイズでバイト単位で表される。
ＴＣＰエンドポイントは、データがＩＰスタックによって処理されバッファが再使用できるようになったとき、このメッセージに返事を返します。
【０３２７】
２．６　データを受信する
オープンしたＴＣＰコネクションからデータを受信するには、オブジェクトはＩＰＳｔａｃｋのＴＣＰエンドポイントへＴＣＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇを送ります。以下に、このメッセージの仮引数を示す。
ｂｕｆｆｅｒ：（入力）着信データが書き込まれるメモリー領域へのポインタである。この領域は、共有メモリーバッファにあり、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって定義されています。
ｓｉｚｅＭｉｎ：（入力／出力）受信する最小バイト数を指定します。受信動作が完了し、エンドポイントがオブジェクトに返事を返すと、この仮引数は実際に受信したバイト数を返します。
ｓｉｚｅＭａｘ：　　　（入力／出力）　受信する最大バイト数を指定します。受信動作が完了し、エンドポイントがオブジェクトに返事を返すと、この仮引数は実際に受信したバイト数を返します。
【０３２８】
データが受信バッファにコピーされると、ＴＣＰエンドポイントは、このメッセージに返事を返します。しかし、伝送中の全てのデータが受信されていてＴＣＰコネクションがクローズされた場合は、最後の受信要求は、ｓｉｚｅＭｉｎの指定より少ないバイト数になる可能性がある。
【０３２９】
２．７　コネクションをクローズする
ＴＣＰコネクションは、以下の３つの方法でクローズすることができます。
・アクティブクローズ
オブジェクトが直接通信クローズの要求を送信するクローズである。オブジェクトが直接ＴＣＰコネクションのクローズを開始するとアクティブクローズが生じます。アクティブクローズを実行するには、オブジェクトは、ＴＣＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。オブジェクトがアクティブクローズを実行すると、データの送受信はできなくなります。コネクション先のオブジェクトは、残りの伝送データを受け取り、その後にコネクションがクローズされたという信号を受け取ります。他方のオブジェクトからみるとパッシブクローズが発生したことになります。
【０３３０】
・パッシブクローズ
コネクション先のオブジェクトが通信クローズの要求を送信するクローズである。ネットワークの相手側のオブジェクトがＴＣＰコネクションを（アクティブクローズを実行して）クローズすると、パッシブクローズが起こります。オブジェクトがすべてのデータ伝送を受信し終わると、ＴＣＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＣＬＯＳＥＤエラーが発生します。その際は、オブジェクトは、ＴＣＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇをＩＰＳｔａｃｋのエンドポイントに送って、パッシブクローズを完了する。
【０３３１】
・アボート
エラーが発生した時にコネクションが不意にクローズされることであり、ＴＣＰコネクションに予期しないことが発生するとアボートが発生します。アボードが起こる例としては、コネクションが切れてタイムアウトになったとき、コネクション要求の時間がかかりすぎたとき、要求しているオブジェクトによって切断されたとき、通常のアクティブクローズ或いはパッシブクローズに時間がかかりすぎたためオブジェクトの一方によって切断されたとき、オブジェクトがコネクションをアボートすると決定したとき等があげられる。アボートでは、共有バッファからすべてのデータを削除し、直ちにコネクションをクローズします。コネクションをアボートするには、オブジェクトは、ＴＣＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇをＩＰＳｔａｃｋのエンドポイントへ送ります。このメッセージは、ａｂｏｒｔと呼ばれるｂｏｏｌｅａｎの仮引数を持っています。この仮引数がＴＲＵＥの場合は、ＴＣＰコネクションは通常の方法で終了せずにアボートされます。
【０３３２】
２．８　ＴＣＰエコークライアントの例
この節では、ＴＣＰエコークライアントプログラムの例を取り上げて、ＴＣＰメッセージの使用方法について説明します。ＴＣＰエコークライアントは、ＴＣＰエコーサーバとコネクションを確立してデータを送信します。そして、サーバから返送されたデータを受信するとコネクションをクローズします。この例では、データの送受信を同時に行わなければなりません。したがって、必要な個所ではａｎｔＥｎｖＭｓｇのメンバー関数の非同期バージョンが使用されます。このとき、それらのメッセージを処理するスタブと、エントリポイントの番号が定義されていることが必要です。エントリポイントの番号の付け方は「エントリポイントの定義」を参照してください。
【０３３３】
変数の定義
変数の定義は、以下のように実行する。

【０３３４】
エントリポイントの定義
また、オブジェクトの初期化時、受信要求が完了時、送信要求が処理されたときにエントリポイントを定義する。ｓｔｕｂ．ｃｆｇには以下の記述が必要です。エントリポイントの定義方法の詳細は、「プログラマーズガイドの２．３　スタブ」のＥｘｔｒａ　ｅｎｔｒｙを参照してください。
Ｅｘｔｒａ　：　Ｉｎｉｔｉａｌｉｚｅ（）
Ｅｘｔｒａ　：　ＲｅｃｅｉｖｅＣｏｎｔ（）
Ｅｘｔｒａ　：　ＳｅｎｄＣｏｎｔ（）
ｓｔｕｂｇｅｎ２コマンドを実行するとｘｘｘＳｔｕｂ．ｃｃが生成され、以下が記述されます。

ここで、エントリポイントの番号は、ＯｂｊｅｃｔＥｎｔｒｙＴａｂｌｅ［］の要素の順番に応じて決まります。
【０３３５】
オブジェクトの初期化
この関数は、クライアントオブジェクトが起動する時に呼び出され、共有バッファの作成、ＴＣＰエンドポイントの作成、ＴＣＰエコーサーバへのコネクション確立操作を実行する。

【０３３６】
ＴＣＰ　コネクションのクローズ
以下の関数は、共有バッファを破棄してコネクションをクローズします。

【０３３７】
データの受信
以下の関数は、必要な量のデータが到着するまでデータを受信した後にＴＣＰコネクションをクローズします。非同期通信を実現するために関数を２個使用しています。ＤｏＲｅｃｅｉｖｅ（）は、１からＰＡＣＫＥＴＳＩＺＥ　ｂｙｔｅｓまでの受信を試みます。

【０３３８】
１回の受信要求が完了するとＲｅｃｅｉｖｅＣｏｎｔ（）　が呼ばれます。すべての送信したデータが受信されたとき、ＴＣＰコネクションは、クローズされます。それ以外の場合は、新規の受信要求が出されます。

【０３３９】
データの送信
この関数は、データをエコーサーバに送信します。ここでは非同期通信を実現するために、関数を２個使用しています。ＤｏＳｅｎｄ（）は、エコーサーバに　ＰＡＣＫＥＴＳＩＺＥ　バイトを送信します。

【０３４０】
送信バッファがＩＰスタックで処理されて、オブジェクトで再使用可能になると、ＳｅｎｄＣｏｎｔ（）が呼ばれます。さらにデータを送信するときは、新規の送信要求を出します。

【０３４１】
第３章　ＵＤＰガイド
この章では、ＯＰＥＮ−Ｒ上のＵＤＰプロトコルを紹介し、ＩＰｖ４プロトコルスタックが提供するＵＤＰサービスをオブジェクトがどのように使用できるかを説明します。
３．１　ＵＤＰ
ＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）は、ＩＰｖ４プロトコルスタックのＩＰ層の上位で動作するプロトコルです。ＵＤＰはデータのパケットつまりデータグラムをＩＰ層へ送り、ＩＰ層はパケットをネットワークの先へ送り届けます。ＵＤＰは、オブジェクトにコネクションレスの信頼性保証の無いデータグラム配送サービスを提供します。コネクションレスとは、送信／受信ホストはコネクションを確立しないという意味です。ＵＤＰは、ＴＦＴＰやＤＮＳ、ＮＦＳなどのアプリケーション層のプロトコルによって使用されます。
【０３４２】
・ＵＤＰネットワーク操作
ＯＰＥＮ−Ｒでは、ＩＰｖ４プロトコルスタックは、オブジェクトに以下のＵＤＰ操作を提供します。
Ｂｉｎｄ：ローカルコネクションパラメタを設定し、オブジェクトをＵＤＰパケットの宛先として識別します。バインド操作後は、オブジェクトは、パケットの宛先アドレスがバインドパラメタで指定したＩＰアドレス及びポート番号と同じ場合のみパケットを受信します。
Ｃｏｎｎｅｃｔ：オプション操作です。この操作でオブジェクトは外部コネクションパラメタを設定します。パケットは、コネクションパラメタのＩＰアドレスとポート番号によって指定されたホストのみと交換されるようになります。
Ｓｅｎｄ：データを送信します。
Ｒｅｃｅｉｖｅ：データを受信します。
Ｃｌｏｓｅ：ＢｉｎｄとＣｏｎｎｅｃｔで設定したパラメタを消去し、データの送受信を停止します。
オブジェクトは、特別なメッセージをＩＰＳｔａｃｋのＵＤＰエンドポイントに送ることによって、これらの操作をします。これらのメッセージは、ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｅｓｓａｇｅを継承しており、さらに後者はａｎｔＥｎｖＭｓｇを継承しています。これらのメッセージについては「第８章　ＵＤＰリファレンス」を参照してください。オブジェクトがどのようにエンドポイントを作成し、ネットワークサービスを要求するかについては「１−３　オブジェクトがプロトコルスタックと通信する方法」を参照してください。
【０３４３】
・ＵＤＰエンドポイントのライフサイクル
図２１は、ＵＤＰエンドポイントのライフサイクルの状態遷移を示しています。図２１に示すメッセージタイプについては「第２部　ＩＰｖ４リファレンスガイド」で詳しく説明しています。オブジェクトは、ＵＤＰコネクションごとに１つのエンドポイントを必要とします。エンドポイントは類似操作を一度に１回しか実行できません。例えば、ＵＤＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇを、すでにデータ送信中のエンドポイントに送ると、そのエンドポイントはＵＤＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＢＵＳＹエラーを返します。しかし、受信メッセージは、このエンドポイントに送れます。
【０３４４】
３．２　ＵＤＰエンドポイントを作成する
オブジェクトは、ＵＤＰでデータを送受信する前に、新ＵＤＰエンドポイントを作成する必要が有ります。オブジェクトは、ＵＤＰコネクションごとに新規のエンドポイントを必要とします。エンドポイントを作成する手順は、ＩＰスタックのすべてのプロトコルについても同様です。手順の詳細については、「１−３　オブジェクトがプロトコルスタックと通信する方法」を参照してください。
【０３４５】
３．３　エンドポイントをバインドする
オブジェクトは、エンドポイントの作成後、バインドを行なわねばなりません。バインドとは、ローカルコネクションパラメタを設定する手順です。ローカルコネクションパラメタは、ＵＤＰパケットを送信するときにエンドポイントが使用するポートを識別します。エンドポイントをバインドするには、オブジェクトはＵＤＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。以下に、このメッセージの仮引数を示す。
ａｄｄｒｅｓｓ：（入力／出力）ローカルホスト上の有効なＩＰアドレスです。ＩＰ＿ＡＤＤＲ＿ＡＮＹを指定すると、オブジェクトはローカルホスト上のどのＩＰアドレスに送られたパケットでも受信します。これは異なるアドレスで複数のインターフェイスをもつマルチホームのホストにとって有用です。ホストがマルチホームでない場合は、ローカルＩＰアドレスが返されます。マルチホームのホスト上では、オブジェクトがエンドポイントをバインドした後にコネクション操作をすると、ＩＰ＿ＡＤＤＲ＿ＡＮＹが特定のＩＰアドレスに更新されます。
【０３４６】
ｐｏｒｔ：（入力／出力）オブジェクトのポート番号です。ＩＰ＿ＰＯＲＴ＿ＡＮＹを指定すると、オブジェクトに一時的なポート番号が割り当てられ、エンドポイントがバインドされた時点で返されます。このポート番号は、１０２４またはそれ以上になります。エンドポイントがバインドされると、オブジェクトは、データの送受信ができます。オブジェクトが最初にコネクション操作（すべてのパケットの宛先指定）を実行していない限り、バケット毎に宛先のＩＰアドレスとポート番号を指定してください。コネクション操作についての詳細は、「３−４　外部コネクションパラメタを設定する（オプション）」を参照してください。
【０３４７】
３．４　外部コネクションパラメタを設定する（オプション）
エンドポイントをバインドした後、オブジェクトはコネクション操作を実行することもできます。この操作で、そのエンドポイント上でオブジェクトが送信するすべてのパケットの送信先のＩＰアドレスとポート番号を指定します。一度コネクションすると、オブジェクトはパケットを送信するたびに宛先を指定する必要がなくなります。コネクション操作のためには、オブジェクトは、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。以下に、このメッセージの仮引数を示す。
ａｄｄｒｅｓｓ：（入力）パケット送信先のホストのＩＰアドレスを指定します。
ｐｏｒｔ：（入力）パケット送信先のオブジェクトのポート番号を指定します。
【０３４８】
３．５　データを送信する
ＵＤＰでデータを送信するには、オブジェクトは、ＩＰＳｔａｃｋのエンドポイントにＵＤＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇを送ります。エンドポイントがバインドされていてもコネクションされていない場合は、このメッセージで宛先のＩＰアドレスとポート番号を指定します。エンドポイントがコネクションされている場合は、この情報は必要ありません。以下に、ＵＤＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇメッセージの仮引数を示す。
ａｄｄｒｅｓｓ：（入力）データの送り先ホストのＩＰアドレスです。オブジェクトがコネクション操作を済ませていると、この仮引数は無視され、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇで指定されているＩＰアドレスが使用されます。
ｐｏｒｔ：（入力）データの送り先のオブジェクトのポート番号です。オブジェクトがコネクション操作を済ませていると、この仮引数は無視され、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇで指定されているポート番号が使用されます。
ｂｕｆｆｅｒ：（入力）送られるデータへのポインタです。このデータは、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって定義された共有メモリーバッファに格納しておきます。
ｓｉｚｅ：（入力）送られるデータのサイズで、単位はバイトです。
データが共有バッファから削除されて送信されたとき、ＵＤＰエンドポイントはこのメッセージに対して返事を返します。
【０３４９】
３．６　データを受信する
ＵＤＰでデータを受信するには、オブジェクトは、ＵＤＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇをＩＰＳｔａｃｋのＵＤＰエンドポイントに送ります。以下に、このメッセージの仮引数を示す。
ａｄｄｒｅｓｓ：（出力）データを送ったホストのＩＰアドレスである。
ｐｏｒｔ：（出力）データを送ったオブジェクトのポート番号である。
ｂｕｆｆｅｒ：（入力）受信データを格納するバッファへのポインタである。このデータの格納先は、共有メモリーバッファであり、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって定義されています。
ｓｉｚｅ：（入力／出力）受け取るバイトの最大値を指定します。受信操作が完了し、エンドポイントがオブジェクトに返事を返すと、この仮引数は受け取った実際のバイト数を返します。受信したパケットが指定されたｓｉｚｅより大きいと余剰データは削除されます。ＵＤＰエンドポイントは、データが共有バッファにコピーされると、このメッセージに返事を返します。
【０３５０】
３．７　エンドポイントをクローズする
ＵＤＰエンドポイントをクローズするには、オブジェクトは、ＵＤＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。このメッセージは仮引数を持っていません。このメッセージを送った後は、オブジェクトはデータの送受信はできません。コネクションが完全にクローズすると、エンドポイントは返事を返します。
【０３５１】
３．８　ＵＤＰエコーサーバの例
ＵＤＰエコーサーバの例で、ＵＤＰメッセージの使い方を説明します。ＵＤＰエコーサーバはＵＤＰコネクションをオープンし、それをエコーポート（７）にバインドします。このコネクションで受け取ったデータはすべて送り返されます。エントリポイントの番号の付け方は「エントリポイントの定義」を参照してください。
【０３５２】
変数の定義
以下のように変数を定義する。

【０３５３】
エントリポイントの定義
ｓｔｕｂ．ｃｆｇに以下の記述が必要です。エントリポイントの定義方法の詳細は「プログラマーズガイドの２．３　スタブ」のＥｘｔｒａ　ｅｎｔｒｙを参照してください。
Ｅｘｔｒａ　：　Ｉｎｉｔｉａｌｉｚｅ（）
Ｅｘｔｒａ　：　ＲｅｃｅｉｖｅＣｏｎｔ（）
Ｅｘｔｒａ　：　ＳｅｎｄＣｏｎｔ（）
ｓｔｕｂｇｅｎ２コマンドを実行するとｘｘｘＳｔｕｂ．ｃｃが生成され、以下が記述されます。

ここでエントリポイントの番号は、ＯｂｊｅｃｔＥｎｔｒｙＴａｂｌｅ［］の要素の順番に応じて決まります。
【０３５４】
オブジェクトの初期化
クライアントオブジェクトが起動したとき、この関数が呼ばれます。この関数は、送信／受信用に共有バッファの作成、ＵＤＰエンドポイントの作成、エンドポイントをエコーポート（７）にバインドする、の３項目を実行します。

【０３５５】
データのエコー
これらの関数は、ＵＤＰデータグラムを受信するとともに送り元のＩＰアドレス、ポート番号を取得し、データを送り返します。ＤｏＲｅｃｅｉｖｅ（）は、ＰＡＣＫＥＴＳＩＺＥバイトまでを含むパケットに対する受信要求を行います。

【０３５６】
ＵＤＰデータグラムを受信したとき、ＲｅｃｅｉｖｅＣｏｎｔ（）が呼ばれます。この関数は、該当データの送り元にデータグラムを送り返します。

【０３５７】
データがＩＰＳｔａｃｋで処理されてバッファが再使用できる状態になったとき、ＳｅｎｄＣｏｎｔ（）が呼ばれます。次に新規の受信要求がでます。

【０３５８】
ＵＤＰコネクションをクローズする
Ｃｌｏｓｅ（）は、共有バッファをアンマップして廃棄する処理と、ＵＤＰコネクションをクローズする処理とを行う。

【０３５９】
第４章ＤＮＳガイド
この章ではＯＰＥＮ−Ｒ上のＤＮＳクライアントサポートを紹介し、ＩＰｖ４プロトコルスタックが提供するＤＮＳクライアントサービスを、オブジェクトがどのように使用できるかを説明します。
４．１　ＤＮＳの紹介
ＤＮＳ（ドメインネームシステム）は、ＩＰｖ４プロトコルスタック内のＵＤＰ上で動作するプロトコルです。インターネットのドメイン名とＩＰアドレスを設定、取得、変換するサービスを提供します。例えば、オブジェクトがＦＴＰを使用してファイルをｆｔｐｓｅｒｖｅｒ．ｙｏｕｒｄｏｍａｉｎ．ｃｏｍというドメイン名を持つホストに送りたいとき、オブジェクトはそのホストのＩＰアドレスを知っていなければなりません。このアドレスを決定するために、オブジェクトがＤＮＳに要求を送ると、ＤＮＳはｆｔｐｓｅｒｖｅｒ．ｙｏｕｒｄｏｍａｉｎ．ｃｏｍが１９２．１６８．１．２００というＩＰアドレスを持っているという返事を返します。この情報によって、オブジェクトはＦＴＰコネクションを実行し、ファイルをｆｔｐｓｅｒｖｅｒ．ｙｏｕｒｄｏｍａｉｎ．ｃｏｍに送り始めることができます。
【０３６０】
・ＤＮＳネットワーク操作
ＯＰＥＮ−Ｒでは、ＩＰｖ４プロトコルスタックはオブジェクトに以下のようなＤＮＳ操作を提供します。
ホストのＤＮＳサーバの設定及び取得：ホストが使用しているすべてのＤＮＳサーバのＩＰアドレスを設定または取得します。すべてのオブジェクトはＤＮＳサーバの定義を共有していることに注意してください。１つのオブジェクトがＤＮＳサーバの定義を変更すると、他のオブジェクトは自動的に変更された定義を使用することになります。
オブジェクトのデフォルトドメイン名の設定及び取得：ホストのデフォルトドメイン名を設定、取得します。
ＩＰアドレスまたはドメイン名による完全なホストエントリの取得：指定されたホストのＩＰアドレスとドメイン名のエイリアスとの完全なリストを取得します。
ホストのＩＰアドレスの取得：ホストが複数のアドレスを持っている場合は、ホストの有効なＩＰアドレスのいずれかを取得します。
ホストのドメイン名エイアスの取得：ドメイン名に複数のエイリアスがある場合は、ホストの有効なエイリアスのいずれかを取得します。
クローズ：オブジェクトのＤＮＳエンドポイントをクローズします。
【０３６１】
オブジェクトは、特別なメッセージをＩＰＳｔａｃｋのＤＮＳエンドポイントに送り、これらの操作を実行します。これらのメッセージはＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｅｓｓａｇｅを継承しており、さらに後者はａｎｔＥｎｖＭｓｇを継承しています。オブジェクトがどのようにエンドポイントを作成し、ネットワークサービスを要求するかについては「１−３オブジェクトがプロトコルスタックと通信する方法」を参照してください。
【０３６２】
・ＤＮＳエンドポイントのサイクル
図２２は、ライフサイクル期間のＤＮＳエンドポイントの状態遷移を示しています。図２２のメッセージの型について「ＩＰｖ４リファレンスガイド」で説明します。オブジェクトは、ＤＮＳコネクションごとに１つのエンドポイントを必要とし、１つのエンドポイントは一度に１つの操作しか実行できません。例えば、その操作をすでに実行している１つのエンドポイントにＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇを送ると、そのエンドポイントはＤＮＳ＿ＣＯＮＮＥＣＴＩＯＮ＿ＢＵＳＹエラーを返します。
【０３６３】
４．２　ＤＮＳエンドポイントを作成する
ＤＮＳとデータの送受信を行うには、オブジェクトは新規のＤＮＳエンドポイントを作成する必要が有ります。エンドポイントを作成する手順は、ＩＰスタックのすべてのプロトコルについても同様です。「１−３　オブジェクトがプロトコルスタックと通信する方法」を参照してください。可能ならば、ＤＮＳエンドポイントは１つのみオープンし、そのオブジェクトの使用中はそのエンドポイントを、すべてのＤＮＳ操作とクエリーに再使用するようにしてください。ＤＮＳクエリーをこれ以上行わないときのみ、エンドポイントをクローズしてください。ただし、オブジェクトが必要とする場合は、複数のＤＮＳエンドポイントを作成することは可能です。
【０３６４】
４．３　オブジェクトのＤＮＳサーバの設定と取得
オブジェクトの初期化時、オブジェクトは、ドメイン名とＩＰアドレスを解決するのに使用するすべてのＤＮＳサーバのリストを登録します。一度このリストが登録されると、クエリーはリストされているサーバにリストの順序にしたがって送られます。
・ＤＮＳサーバのＩＰアドレスを設定する
ＤＮＳサーバのＩＰアドレスのリストを登録するには、オブジェクトはＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。以下に、ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇの仮引数を示す。
ｎｓｃｏｕｎｔ：（入力）登録するＩＰアドレスの数である。
ａｄｄｒＬｉｓｔ［ＭＡＸＮＳ］：（入力）登録するＩＰアドレスのリストである。
・ＤＮＳサーバのＩＰアドレスを取得する
ホスト用に登録したＤＮＳサーバのリストを取得するには、オブジェクトはＤＮＳＥｎｄｐｏｉｎｔＧｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。以下に、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇの仮引数を示す。
ｎｓｃｏｕｎｔ：（出力）登録されたＩＰアドレスの数である。
ａｄｄｒＬｉｓｔ［ＭＡＸＮＳ］：（出力）ＩＰアドレスのリストである。
【０３６５】
４．４　オブジェクトのデフォルトドメイン名の設定と取得
初期化時に、オブジェクトは、そのデフォルトドメイン名を登録します。デフォルトドメイン名が登録された後は、名前が完全指定されていないすべてのホスト名にこのドメイン名が自動的に付加されます。
・デフォルトドメイン名を設定する
デフォルトドメイン名を設定するには、オブジェクトは、ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇ　をＩＰＳｔａｃｋにあるオブジェクトのエンドポイントに送ります。ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇは、１つの仮引数を持っており、この仮引数でドメイン名ｎａｍｅ［ＭＡＸＤＮＡＭＥ］を指定します。ドメイン名はｎｕｌｌ文字で終わらせてください。
・デフォルトドメイン名を取得する
デフォルトドメイン名を取得するには、オブジェクトはＤＮＳＥｎｄｐｏｉｎｔＧｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇは１つの仮引数を持っており、この仮引数がドメイン名ｎａｍｅ［ＭＡＸＤＮＡＭＥ］を指定します。ドメイン名はｎｕｌｌ文字で終端しています。
【０３６６】
４．５　ホストエントリを取得する
インターネット上のホストのＩＰアドレス、ドメイン名、ドメイン名のエイリアスを決定しようとするとき、オブジェクトはそのＤＮＳサーバの１つからホスト用のエントリを取得します。ホストエントリには図２３に示すように、通常、ホスト用のすべてのＩＰアドレスやドメイン名のエイリアスのリストが含まれます。ＯＰＥＮ−Ｒでは、オブジェクトがＤＮＳプロトコルにホストエントリを要求すると、そのエントリには、ホストエントリを返したＤＮＳサーバのアドレス、リストの最初のＩＰアドレス（正式なアドレス）及びホスト用のＩＰアドレスの総数、リストの最初のドメイン名（正式なドメイン名）及びホスト用ドメイン名のエイリアスの総数のみが含まれます。異なるＩＰアドレスまたはドメイン名のエイリアスの１つを取得したい場合は、明示的に要求します。詳細については、この章の後にでてくる「４−６　ホストのＩＰアドレスを取得する」及び「４−７　ホストのドメイン名のエイリアスを取得する」を参照してください。
【０３６７】
・ドメイン名でエントリを取得する
ホストのドメイン名或いはドメイン名のエイリアスしか分からない場合に、ホストエントリを取得するには、オブジェクトはＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。以下に、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇの仮引数を示す。
ｎａｍｅ［ＭＡＸＤＮＡＭＥ］：（入力／出力）エントリを取得しようとしているホストのドメイン名です。ドメイン名はｎｕｌｌ文字で終端させてください。ドメイン名のエイリアスを指定すると、ホストの正式なドメイン名を返します。
ｓｅｒｖｅｒ＿ａｄｄｒｅｓｓ：（出力）ホストエントリを送ったＤＮＳサーバのＩＰアドレスである。
ｈｏｓｔ＿ａｄｄｒｅｓｓ：（出力）ホストのＩＰアドレスです。ホストが複数のＩＰアドレスを持つ場合は、最初のＩＰアドレスを返します。
ｎ＿ａｄｄｒｅｓｓ　　：（出力）ホスト用のＩＰアドレスの個数である。
ｎ＿ａｌｉａｓ：（出力）ホスト用のドメイン名のエイリアスの個数である。
【０３６８】
・ＩＰアドレスでエントリを取得する
ホストのＩＰアドレスしか分からない場合に、ホストエントリを取得するには、オブジェクトはＤＮＳＥｎｄｐｏｉｎｔｇｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。以下に、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇの仮引数を示す。
ｈｏｓｔ＿ａｄｄｒｅｓｓ：（入力／出力）ホストのＩＰアドレスです。元のメッセージで異なるＩＰアドレスを指定しても、そのホストの最初のＩＰアドレスを返します。
ｓｅｒｖｅｒ＿ａｄｄｒｅｓｓ：（出力）ホストエントリを送ったＤＮＳサーバのＩＰアドレスである。
ｎａｍｅ［ＭＡＸＤＮＡＭＥ］：（出力）ホストの正式なドメイン名です。ドメイン名はｎｕｌｌ文字で終わります。
ｎ＿ａｄｄｒｅｓｓ　　：（出力）ホスト用のＩＰアドレスの個数です。
ｎ＿ａｌｉａｓ：（出力）ホスト用のドメイン名のエイリアスの個数です。
【０３６９】
４．６　ホストのＩＰアドレスを取得する
ホストの最初に登録したＩＰアドレスだけを取得したい場合は、「４．５　ホストエントリを取得する」を参照してください。ホストに登録した他のＩＰアドレスを取得したい場合は、この章で説明している操作を別途実行してください。ホストの別ＩＰアドレスの１つを取得するには、オブジェクトはＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。ただし、この操作をする前に、「４．５　ホストエントリを取得する」に従い、ホストエントリを取得しておく必要が有ります。以下に、ＤＮＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇの仮引数を示す。
ｉｎｄｅｘ：（入力）取得したいＩＰアドレスのインデックスです。このインデックスは、前にホストエントリを受信したときに返したｎ＿ａｄｄｒｅｓｓより小さな値でなければなりません。０を与えると、ホストエントリリストで最初のＩＰアドレスを返します。
ａｄｄｒｅｓｓ：（出力）ホストエントリでｉｎｄｅｘの位置にあるＩＰアドレスである。
【０３７０】
４．７　ホストのドメイン名のエイリアスを取得する
ホストの正式なドメイン名だけを取得したい場合は、「４．５　ホストエントリを取得する」を参照してください。ホストのドメイン名のエイリアスを取得したい場合は、この章で説明している操作を別途行ってください。ホストのドメイン名の、エイリアスの１つを取得するには、オブジェクトはＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。ただし、この操作をする前に、「４．５　ホストエントリを取得する」に従い、ホストエントリを取得しておく必要が有ります。以下に、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇの仮引数を示す。
ｉｎｄｅｘ：（入力）取得したいドメイン名のエイリアスのインデックスです。このインデックスは、その前にホストエントリを受け取ったときに返したｎ＿ａｌｉａｓより小さい値でなければなりません。０を与えると、ホストの公式なドメイン名を返します。
ｎａｍｅ［ＭＡＸＤＮＡＭＥ］：（出力）ホストエントリでｉｎｄｅｘの位置のドメイン名のエイリアスです。
【０３７１】
４．８　エンドポイントをクローズする
ＤＮＳエンドポイントをクローズするには、オブジェクトは、ＤＮＳＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。このメッセージは仮引数を持っていません。このメッセージを送った後は、オブジェクトはデータの送受信はできません。
【０３７２】
４．９　ＤＮＳクライアントの例
ＤＮＳクライアントの例は、ＤＮＳメッセージをどのように使用するかを示しています。ＤＮＳクライアントは、ＩＰスタックのＤＮＳサービスに対してエンドポイントをオープンし、ドメイン名やＩＰアドレスを検索するのに使用します。
【０３７３】
変数の定義
変数を以下のように定義する。

【０３７４】
エントリポイントの定義
ｓｔｕｂ．ｃｆｇには、以下の記述が必要です。エントリポイントの定義方法の詳細は「プログラマーズガイドの２．３　スタブ」のＥｘｔｒａ　ｅｎｔｒｙを参照してください。
Ｅｘｔｒａ　：　Ｉｎｉｔｉａｌｉｚｅ（）
【０３７５】

【０３７６】
エンドポイントのオープンとクローズ
Ｏｐｅｎ（）は、ＤＮＳエンドポイントを作成します。　そのエンドポイントを使用してＩＰスタックのＤＮＳサービスと通信します。

【０３７７】
ＤＮＳ機能を設定する
ＳｅｔＳｅｒｖｅｒｓ（）関数により、ＤＮＳプライマリーとＤＮＳセコンダリーサーバ、ローカルドメイン名を設定します。

【０３７８】

【０３７９】

【０３８０】
第５章ＩＰガイド
この章では、ＯＰＥＮ−Ｒ上のＩＰプロトコルを紹介し、ＩＰｖ４プロトコルスタックが提供するＩＰサービスをオブジェクトがどのように使用できるかを説明します。
５．１　ＩＰの紹介
ＩＰｖ４プロトコルスタックでは、インターネットプロトコル層（ＩＰ）がネットワークを経由してパケットを送信する役割をします。通常は、オブジェクトはＩＰとは直接通信せずに、ＩＰ上のＴＣＰまたはＵＤＰのような層に対してコネクションをオープンします。しかし、オブジェクトのなかにはＩＰ層を直接使用する必要があるものもあります。例えば、ＩＰＳｔａｃｋのプログラムを変更せずに新規のプロトコルを追加しようとする場合は、ＩＰ層と直接通信するオブジェクトとしてプロトコルを記述することができます。
【０３８１】
・ＩＰネットワーク操作
ＯＰＥＮ−Ｒでは、ＩＰｖ４プロトコルスタックは、オブジェクトに以下のようなＩＰ操作を提供します。
Ｂｉｎｄ：ＩＰエンドポイントを特定のプロトコルにバインドします。オブジェクトが、エンドポイントを経由して送受信したパケットは、すべて指定されたプロトコルから発したものとして扱われます。
Ｓｅｎｄ：データを送ります。
Ｒｅｃｅｉｖｅ：データを受け取ります。
Ｃｌｏｓｅ：データの送受信を中止し、エンドポイントを削除します。
オブジェクトは、特別なメッセージをＩＰＳｔａｃｋのＩＰエンドポイントに送ることによってこれらの操作を行います。これらのメッセージはＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｅｓｓａｇｅを継承していますが、さらに後者はａｎｔＥｎｖＭｓｇを継承しています。これらのメッセージについては「第１０章　ＩＰリファレンス」を参照してください。オブジェクトがどのようにエンドポイントを作成し、ネットワークサービスを要求するかについては、「１．３　オブジェクトがプロトコルスタックと通信する方法」を参照してください。
【０３８２】
・ＩＰエンドポイントのライフサイクル
図２４は、ライフサイクル期間のＩＰエンドポイントの状態遷移を示しています。図２４のメッセージの型については、「ＩＰｖ４リファレンスガイド」で説明します。オブジェクトは、ＩＰコネクションごとにエンドポイントを必要とし、１つのエンドポイントは同様な操作を一度に１回しか実行できません。例えば、ＩＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇをデータを送信中の１つのエンドポイントに送ると、そのエンドポイントはＩＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＢＵＳＹエラーを返します。しかし、ＩＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇをこのエンドポイントに送ることは可能です。
【０３８３】
５．２　ＩＰエンドポイントを作成する
ＩＰによってデータの送受信をする前に、オブジェクトは新規のＩＰエンドポイントを作成しておく必要があります。エンドポイントを作成する手順はＩＰスタックのすべてのプロトコルについても同様です。「１．３　オブジェクトがプロトコルスタックと通信する方法」を参照してください。
【０３８４】
５．３　エンドポイントをバインドする
オブジェクトは、エンドポイントが作成された後、そのエンドポイントを特定のプロトコルにバインドする必要が有ります。エンドポイント経由でオブジェクトが送受信するすべてのパケットは、指定されたプロトコルから発したものとして扱われます。エンドポイントをバインドするには、オブジェクトはＩＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。このメッセージはｐｒｏｔｏｃｏｌと呼ばれる１つの仮引数を持っています。この仮引数はエンドポイントにバインドするプロトコルを指定します。各プロトコルは、２５６未満の整数によって識別されます。ただし、エンドポイントがプロトコルスタックにバインドされていない限り、そのエンドポイントをＴＣＰプロトコルまたはＵＤＰプロトコルにバインドすることはできません。バインドしようとすると、ＩＰ＿ＩＮＶＡＬＩＤ＿ＰＲＯＴＯＣＯＬエラーが返されます。しかし、エンドポイントをＩＣＭＰにバインドすることはできます。ＩＣＭＰは、認識するパケットをすべて通常どおりに処理しますが、識別できないパケットはバインドされたエンドポイントへすべて転送します。
【０３８５】
５．４　データを送信する
ＩＰでデータを送信するには、オブジェクトはＩＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。以下に、ＩＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇメッセージの仮引数を示す。
ｔｙｐｅ：（入力）送信されるパケットの型です。通常のＩＰパケットはＩＰ＿ＤＡＴＡ型です。その他の型はＩＣＭＰパケット用として存在します。
ｂｕｆｆｅｒ：（入力）送られるパケットへのポインタである。このパケットは、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって定義された共有メモリーバッファに格納する。
ｓｉｚｅ：（入力）送られるパケットのサイズで単位はバイトです。
【０３８６】
データが共有バッファから削除されて送られると、ＩＰエンドポイントはこのメッセージに返事を返します。ＩＰパケットを送信する場合は、ＩＰパケットの各欄にデータを入力して完全なパケットにしてください。ＩＰヘッダーは、図２５のようになります。Ｃ＋＋クラスのＩＰＨｅａｄｅｒは、ＩＰＰｒｏｔｏｃｏｌ．ｈで定義されています。ＩＰパケットに値を入れるには、ＩＰＨｅａｄｅｒを使用してください。このクラスがすべてのエンディアン関係の面倒を見ます。ここで、以下のフィールドは、必須項目である。
８−ｂｉｔ　ｐｒｏｔｏｃｏｌ　ｆｉｅｌｄ　［ＩＰＨｅａｄｅｒ：：ｉｐ＿ｐＳｅｔ（ｂｙｔｅ　＿ｖａｌ）］
３２−ｂｉｔ　ｓｏｕｒｃｅ　ＩＰ　ａｄｄｒｅｓｓ　［ＩＰＨｅａｄｅｒ：：ｉｐ＿ｓｒｃＳｅｔ（ｕｉｎｔ３２　＿ｖａｌ）］
３２−ｂｉｔ　ｄｅｓｔｉｎａｔｉｏｎ　ＩＰ　ａｄｄｒｅｓｓ　［ＩＰＨｅａｄｅｒ：：ｉｐ＿ｄｓｔＳｅｔ（ｕｉｎｔ３２　＿ｖａｌ）］
【０３８７】
また、以下のフィールドは、オプションである。フィールドに０を記述すると、そのフィールドは未定義として扱われて、スタックによって上書きされます。
１６−ｂｉｔ　ｔｏｔａｌ　ｌｅｎｇｔｈ　（ｉｎ　ｂｙｔｅｓ）　［ＩＰＨｅａｄｅｒ：：ｉｐ＿ｌｅｎＳｅｔ（ｕｉｎｔ１６　＿ｖａｌ）］
４−ｂｉｔ　ｈｅａｄｅｒ　ｌｅｎｇｔｈ　［ＩＰＨｅａｄｅｒ：：ｉｐ＿ｈｌＳｅｔ（ｂｙｔｅ＿ｖａｌ）］
８−ｂｉｔ　ｔｙｐｅ　ｏｆ　ｓｅｒｖｉｃｅ　［ＩＰＨｅａｄｅｒ：：ｉｐ＿ｔｏｓＳｅｔ（ｂｙｔｅ　＿ｖａｌ）］
８−ｂｉｔ　ｔｉｍｅ　ｔｏ　ｌｉｖｅ　［ＩＰＨｅａｄｅｒ：：ｉｐ＿ｔｔｌＳｅｔ（ｂｙｔｅ　＿ｖａｌ）］
ＩＰパケットがブロードキャストパケットでない場合のみ、８−ｂｉｔ　ｔｉｍｅ　ｔｏ　ｌｉｖｅフィールドは、スタックによって上書きされます。ただし、以下のフィールドには値を設定しない。ＩＰスタックによって常に上書きされます。ＩＰＨｅａｄｅｒクラスの使用例については「５．７　ＩＰ−ｐｉｎｇの例」を参照してください。
４−ｂｉｔ　ｖｅｒｓｉｏｎ
１３−ｂｉｔ　ｆｒａｇｍｅｎｔ　ｏｆｆｓｅｔ
１６−ｂｉｔ　ｉｄｅｎｆｉｆｉｃａｔｉｏｎ
１６−ｂｉｔ　ｈｅａｄｅｒ　ｃｈｅｃｋｓｕｍ
【０３８８】
５．５　データを受信する
ＩＰでデータを受け取るには、オブジェクトは、ＩＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。以下に、このメッセージの仮引数を示す。
ｔｙｐｅ：（出力）受け取ったパケットの型です。通常のＩＰパケットはＩＰ＿ＤＡＴＡ型です。他の型はＩＣＭＰパケット用として存在します。
ｂｕｆｆｅｒ：（入力）受け取るパケットを格納する領域へのポインタである。この領域は、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって定義された共有バッファー内であることが必要です。
ｓｉｚｅ：（入力／出力）受け取るバイトの最大値を指定します。受信が完了し、エンドポイントがオブジェクトに返事を返すと、受け取ったバイトの実数を返します。受け取るパケットが共有バッファにとって大きすぎると、そのパケットの一部だけがバッファに格納され、ＩＰ＿ＰＡＣＫＥＴＳＩＺＥエラーが返されます。
ＩＰエンドポイントは、データが共有バッファにコピーされると、このメッセージに返事を返します。
【０３８９】
５．６　エンドポイントをクローズする
ＩＰエンドポイントをクローズするには、オブジェクトは、ＩＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇをＩＰＳｔａｃｋのエンドポイントに送ります。このメッセージは仮引数を持っていません。このメッセージを送った後は、オブジェクトは、データの送受信はできません。エンドポイントは、コネクションが完全にクローズすると返事を返します。
【０３９０】
５．７　ＩＰ　ｐｉｎｇの例
このＩＰ　ｐｉｎｇの例は、ＩＰメッセージの使用方法を示しています。ＩＰ　ｐｉｎｇプログラムはＩＣＭＰパケットをネットワーク上のホストに送り返事を待ちます。
【０３９１】

【０３９２】
エントリポイントの定義
ｓｔｕｂ．ｃｆｇに以下の記述が必要です。エントリポイントの定義方法の詳細は「プログラマーズガイドの２．３　スタブ」のＥｘｔｒａ　ｅｎｔｒｙを参照してください。
Ｅｘｔｒａ　：　Ｉｎｉｔｉａｌｉｚｅ（）
【０３９３】
オブジェクトの初期化
オブジェクトの初期化時に、この関数が呼ばれます。

【０３９４】
エンドポイントをオープンする
Ｏｐｅｎ（）関数によって、ＩＣＭＰパケットを送受信するための共有バッファ、ＩＰエンドポイントを作成します。また、エンドポイントをＩＣＭＰプロトコルにバインドします。

【０３９５】
Ｃｌｏｓｅ
Ｃｌｏｓｅ（）関数によって、共有バッファをアンマップして廃棄します。また、ＩＰエンドポイントを廃棄します。

【０３９６】
Ｐｉｎｇ
Ｐｉｎｇ（）は、実際のＩＣＭＰ＿ＥＣＨＯパケットを送受信します。最初に、Ｐｉｎｇ（）は共有バッファにＩＰ／ＩＣＭＰパケットを作成して、次にＩＰ／ＩＣＭＰパケットはＩＰスタックにネットワークに送られます。その後で、Ｐｉｎｇ（）はＩＣＭＰ＿ＥＣＨＯＲＥＰＬＹパケットが受信されるのを待ちます。

【０３９７】
第２部ＩＰｖ４リファレンスガイド
第６章　ＡＮＴ　環境リファレンス
この章では、エンドポイントや共有バッファの要求をＡＮＴ環境に対して送付するときに使用する構造体とメンバー関数について説明します。

ここでは、新規のエンドポイントを要求するメッセージを定義します。オブジェクトは、新規のエンドポイントが必要なとき、ａｎｔＥｎｖＣｒｅａｔｅＥｎｄｐｏｉｎｔＭｓｇを作成し、そのエンドポイントがどのプロトコルを必要とするか、及びそのエンドポイント用に作成されるべきＳＤＵプールのサイズを指定します。以下に、ここでの仮引数を示す。
ｅｒｒｏｒ：（出力）要求に対する結果を記述したエラーを返します。
ｐｒｏｔｏｃｏｌ：（入力）作成するエンドポイントの型です。この型は、使用可能なプロトコルに対応しています。
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＴＣＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＵＤＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＴＦＴＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＤＮＳ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＰＯＰ３
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＳＭＴＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＩＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＭＩＢＩＩ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＭＩＢ＿ＥＴＨＥＲＮＥＴ
ｐｏｏｌＳｉｚｅ：（入力）新規のエンドポイント用に作成されるＳＤＵプールのサイズです。ＳＤＵプールとは、プロトコルスタックのなかにデータを格納する内部ＡＮＴ構成体です。目安として、送信したいパケットの最大のものより若干大きいＳＤＵプールをいつも作成してください。例えば、８−ＫＢのパケットには約１０−ＫＢのＳＤＵプールが必要です。
ｍｏｄｕｌｅＲｅｆ：（出力）新規のエンドポイントへの参照
【０３９８】

ａｎｔＥｎｖＣｒｅａｔｅＥｎｄｐｏｉｎｔＭｓｇのインスタンスを作成します。メッセージを作成したら、ＡＮＴ環境へ送ってください。オブジェクトが応答メッセージを受け取ったしたとき、ａｎｔＥｎｖＣｒｅａｔｅＥｎｄｐｏｉｎｔＭｓｇの仮引数ｍｏｄｕｌｅＲｅｆには、新規のエンドポイントへの参照が格納されています。以下に、ここでの仮引数を示す。
ｐｒｏｔｏｃｏｌ：（入力）作成するエンドポイントの型です。この型は使用可能なプロトコルに対応しています。
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＴＣＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＵＤＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＴＦＴＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＤＮＳ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＰＯＰ３
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＳＭＴＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＩＰ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＭＩＢＩＩ
ＥｎｄｐｏｉｎｔＴｙｐｅ＿ＭＩＢ＿ＥＴＨＥＲＮＥＴ
ｐｏｏｌＳｉｚｅ：（入力）新エンドポイント用に作成するＳＤＵプールのサイズ
【０３９９】

ここでは、共有メモリーバッファを要求するメッセージを定義します。オブジェクトは新たな共有メモリーバッファを要求するとき、バッファのサイズを指定するａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇを作成します。以下に、ここでの仮引数を示す。
ｅｒｒｏｒ：（出力）要求の結果を記述したエラーを返します。
ｓｉｚｅ：（入力）バイト単位の共有バッファサイズである。
ｂｕｆｆｅｒ：（出力）作成された新規のバッファへの参照を示す。
【０４００】
ａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇ：：ａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇ（）
コンストラクターを以下に示す。
ａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇ（ｕｉｎｔ３２　＿ｓｉｚｅ）；
ａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇのインスタンスを作成します。メッセージを作成後、ＡＮＴ　環境へ送ってください。オブジェクトが応答を受け取ったとき、ａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇの仮引数ｂｕｆｆｅｒが新規のバッファへの参照を返します。以下に、ここでの仮引数を示す。
ｓｉｚｅ：（入力）バイト単位の共有バッファサイズである。
【０４０１】

ここでは、オブジェクトとＡＮＴ環境の間のデータ交換に使用される共有メモリーバッファを定義します。共有メモリーバッファは、共通のメモリー領域をオブジェクト及びＡＮＴ環境のアドレス空間にマップします。オブジェクトがＡＮＴ環境とデータを交換するとき、データはこの共有バッファへのポインタにより識別されます。ａｎｔＳｈａｒｅｄＢｕｆｆｅｒは、このポインタをオブジェクトとＡＮＴ環境のアドレス空間の間で変換します。共有バッファを作成するには、オブジェクトはＡＮＴ環境へバッファのサイズを指定してａｎｔＥｎｖＣｒｅａｔｅＳｈａｒｅｄＢｕｆｆｅｒＭｓｇを送ります。
【０４０２】
ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ：：Ｍａｐ（）
メンバーを以下に示す。
ａｎｔＥｒｒｏｒ　Ｍａｐ（）；
オブジェクトのアドレス空間へ共有メモリーバッファをマップします。この操作を行ってから、オブジェクトはＡＮＴ環境とデータ交換をしてください。以下に、このときの戻り値を示す。
ＡＮＴ＿ＳＵＣＣＥＳＳ：成功
ＡＮＴ＿ＦＡＩＬ：失敗
【０４０３】
ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ：：ＵｎＭａｐ（）
メンバーを以下に示す。
ａｎｔＥｒｒｏｒ　ＵｎＭａｐ（）；
オブジェクトのアドレス空間から共有メモリーバッファを削除します。共有バッファを破棄する前に、この操作を行ってください。また、このときの戻り値を以下に示す。
ＡＮＴ＿ＳＵＣＣＥＳＳ：成功
ＡＮＴ＿ＦＡＩＬ：失敗
【０４０４】
ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ：：ＧｅｔＡｄｄｒｅｓｓ（）
メンバーを以下に示す。
ｖｏｉｄ＊　ＧｅｔＡｄｄｒｅｓｓ（）；
共有メモリーバッファの基底アドレスを取得します。この操作を行う前に、オブジェクトは、バッファをそのアドレス空間にマップしている必要があります（ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ：：Ｍａｐ（）を参照）。このときの戻り値を以下に示す。
０：失敗
【０４０５】
ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ：：ＧｅｔＳｉｚｅ（）
メンバーを以下に示す。
ｕｉｎｔ３２　ＧｅｔＳｉｚｅ（）；
バイト単位で共有メモリーバッファのサイズを取得します。この操作を行う前に、オブジェクトは、バッファをそのアドレス空間にマップしている必要があります（ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ：：Ｍａｐ（）を参照）。
【０４０６】
第７章　ＴＣＰリファレンス
この章では、オブジェクトがＴＣＰサービスを要求する目的で、ＩＰＳｔａｃｋに送付するＴＣＰメッセージについて説明します。すべてのメッセージはＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。
ＴＣＰエラー
以下に、この章で説明されているメッセージが返すエラーリストを示す。エラー値は、列挙型ＴＣＰＥｎｄｐｏｉｎｔＥｒｒｏｒで定義されています。オブジェクトがネットワーク操作を要求し、ＴＣＰエンドポイントから応答を受けた際には、その要求のエラーフィールドを調べてください。（例えば、ＴＣＰＥｎｄｐｏｉｎｔＬｉｓｔｅｎＭｓｇ．ｅｒｒｏｒ）
ＴＣＰ＿ＢＵＦＦＥＲ＿ＩＮＶＡＬＩＤ：ＴＣＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇ或いはＴＣＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇで使用されたアドレスとサイズの引数は、共有バッファ内を示していません。
ＴＣＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＢＵＳＹ：コネクションがビジーで、要求した操作は未完了です。メッセージ送付先のＴＣＰエンドポイントは、すでに別の要求を処理中と考えられます。
ＴＣＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＣＬＯＳＥＤ：コネクションはクローズされました。
ＴＣＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＲＥＳＥＴ：コネクションはアボートされました。
ＴＣＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＴＩＭＥＯＵＴ：コネクションは時間切れとなりクローズされました。
ＴＣＰ＿ＦＡＩＬ：操作は失敗です（これ以上の情報はありません）。
ＴＣＰ＿ＨＯＳＴ＿ＵＮＲＥＡＣＨＡＢＬＥ：ＩＰスタックは、宛先アドレスへのルートを発見できませんでした。
ＴＣＰ＿ＭＥＳＳＡＧＥ＿ＴＯＯ＿ＬＯＮＧ：ＴＣＰ／ＩＰパケットが大きすぎて中間ルーターで処理できませんでした。
ＴＣＰ＿ＮＥＴＷＯＲＫ＿ＵＮＲＥＡＣＨＡＢＬＥ：ＩＰスタックが、宛先アドレスを含むネットワークへのルートを見つけられませんでした。
ＴＣＰ＿ＯＰＥＲＡＴＩＯＮ＿ＩＮＶＡＬＩＤ：要求した操作は、現在のエンドポイントの状態では許可されません。
ＴＣＰ＿ＯＰＥＲＡＴＩＯＮ＿ＵＮＫＮＯＷＮ：要求した操作は、ＴＣＰエンドポイントに認識されませんでした。
ＴＣＰ＿ＰＯＲＴ＿ＵＮＲＥＡＣＨＡＢＬＥ：コネクションを指定した宛先ポートでリッスンされていません。
ＴＣＰ＿ＰＲＯＴＯＣＯＬ＿ＵＮＲＥＡＣＨＡＢＬＥ：宛先ホストがＴＣＰを実装していません。
ＴＣＰ＿ＳＵＣＣＥＳＳ：操作は成功しました。
ＴＣＰ＿ＴＩＭＥ＿ＥＸＣＥＥＤＥＤ：ＩＰ組み立てキュー（ＩＰ　ｒｅａｓｓｅｍｂｌｙ　ｑｕｅｕｅ）が、時間切れになりました。
ＴＣＰ＿ＴＴＬ＿ＥＸＣＥＥＤＥＤ：宛先ホストが、発信元ホストからのＴＴＬホップを超えています（宛先ホストと発信元ホスト間のノードが多すぎます）。
【０４０７】
ＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ
以下のように定義する。

ここでは、ＩＰｖ４プロトコルスタック中のどのエンドポイントがＴＣＰサービスの要求を受け取るか、また、どのオブジェクトがその要求に対する応答を受け取るかを指定します。個々のネットワークサービスの要求はＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承したメッセージで送られます（この章で後述します）。以下に仮引数を示す。
ｍｏｄｕｌｅ：（入力）ターゲットエンドポイント
ｏｐｅｒａｔｉｏｎ　　：（入力）送信側のオブジェクトが要求した操作
ｅｒｒｏｒ：（出力）ＴＣＰエラーコードについては「ＴＣＰエラー」を参照してください。
戻り値のＴＣＰエラーコードについては「ＴＣＰエラー」を参照してください。またここでは関連項目として、ＴＣＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ、ＴＣＰＥｎｄｐｏｉｎｔＬｉｓｔｅｎＭｓｇ、ＴＣＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇ、ＴＣＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇ、ＴＣＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇがあげられる。
【０４０８】
ＴＣＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ
以下のように定義する。

ここでは、別のホストへのＴＣＰコネクションをオープンします。主として、ＴＣＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇはクライアントのオブジェクトによって発行されます。コネクションが完全に確立すると、ＴＣＰエンドポイントはこのメッセージに応答します。この応答には完全に特定されたローカル及び相手先のアドレスやポート番号が含まれています。ＴＣＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇはＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承しています。以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照である。
ｌＡｄｄｒｅｓｓ：（出力）コネクションが確立した場合は、ローカルＩＰアドレスを返します。
ｌＰｏｒｔ：（出力）コネクションが確立した場合は、クライアントのオブジェクトに割り当てられた一時的なポート番号を返します。
ｆＡｄｄｒｅｓｓ：（入力）コネクションしたいコンピューターのＩＰアドレスである。
ｆＰｏｒｔ：（入力）　コネクションしたいオブジェクトのポート番号である。
ここでの戻り値のＴＣＰエラーコードについては「ＴＣＰエラー」を参照してください。また、関連項目として、ＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇがあげられる。
【０４０９】
ＴＣＰＥｎｄｐｏｉｎｔＬｉｓｔｅｎＭｓｇ
以下のように定義する。

ここでは、コネクション要求に対しリッスンを開始します。通常、ＴＣＰＥｎｄｐｏｉｎｔＬｉｓｔｅｎＭｓｇは、サーバオブジェクトによって発行されます。コネクションが完全に確立すると、ＴＣＰエンドポイントは、このメッセージに応答します。この応答には、指定されたローカル及び相手先アドレスやポート番号が含まれています。サーバのオブジェクトは、複数のリッスン操作を行うことができ、それらはすべて同一ポート番号へのコネクション要求を受け付けます。各リッスン操作に対して別々のエンドポイントが必要です。ＴＣＰＥｎｄｐｏｉｎｔＬｉｓｔｅｎＭｓｇは、ＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承しています。以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照である。
ｌＡｄｄｒｅｓｓ：（出力）コネクションが確立した場合は、ローカルＩＰアドレスを返します。
ｌＰｏｒｔ：（入力）　コネクション要求を受理するポート番号です。任意のポートへの要求も受理する場合は、ＩＰ＿ＰＯＲＴ＿ＡＮＹの値を指定してください。
ｆＡｄｄｒｅｓｓ：（出力）コネクションを要求したコンピューターのＩＰアドレスを返します。
ｆＰｏｒｔ：（出力）コネクションを要求したオブジェクトのポート番号を返します。
戻り値のＴＣＰエラーコードについては、「ＴＣＰエラー」を参照してください。またここでは、関連項目としてＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇがあげられる。
【０４１０】
ＴＣＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇ
以下に、コンストラクターを説明する。

ここでは、オープンされたＴＣＰコネクション経由でデータを送信します。オブジェクトがプロトコルスタックに送信するすべてのデータは、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体により定義された共有メモリーバッファに格納してください。データが共有バッファからＩＰスタックの内部メモリーバッファにコピーさると、ＴＣＰエンドポイントはこのメッセージに応答します。ＴＣＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇはＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承しています。また、ここでの仮引数を以下に示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照を示す。
ｂｕｆｆｅｒ：（入力）送信中のデータが格納されている共有バッファである。
ｓｉｚｅ：（入力）バイト単位の送信中のデータサイズである。
戻り値のＴＣＰエラーコードについては、「ＴＣＰエラー」を参照してください。またここでの関連項目として、ＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＴＣＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４１１】
ＴＣＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇ
コンストラクターを以下に示す。

ここでは、オープンされたＴＣＰコネクションからデータを受信します。オブジェクトがプロトコルスタックより受信するすべてのデータは、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体により定義された共有メモリーバッファに格納されます。データが共有バッファへコピーされると、ＴＣＰエンドポイントはこのメッセージに応答します。伝送中のデータがすべて受信され、ＴＣＰコネクションがクローズされた場合は、最終の受信要求はｓｉｚｅＭｉｎの指定より少ないバイト数になる可能性があります。ＴＣＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇは、ＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承しています。以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照を示す。
ｂｕｆｆｅｒ：（入力）受信データ用の共有バッファである。
ｓｉｚｅＭｉｎ：（入出力）受信する最小バイト数を指定します。受信操作が完了しエンドポイントがオブジェクトに応答し終えると、この仮引数は受信したバイトの実際の数を返します。
ｓｉｚｅＭａｘ：（入出力）受信する最大バイト数を指定します。受信操作が完了しエンドポイントがオブジェクトに応答し終えると、この仮引数は受信したバイトの実際の数を返します。
戻り値のＴＣＰエラーコードについては「ＴＣＰエラー」を参照してください。また、関連項目として、ＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＣＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４１２】
ＴＣＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇ
以下に、コンストラクターを示す。

ＴＣＰコネクションをクローズします。ＴＣＰコネクションのクローズには、以下の３つの方法があります。
・アクティブクローズ
オブジェクトが直接にクローズ要求を送信します。コネクションの相手側のオブジェクトは伝送の残りのデータを受信し、次にコネクションがクローズされたことを示すエラーを受信します。相手側のオブジェクトからみると、パッシブクローズが起こったことになります。
・パッシブクローズ
コネクションの相手側のオブジェクトからクローズ要求が送信されます。こちら側のオブジェクトが伝送データすべてを受信した後で、ＴＣＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＣＬＯＳＥＤエラーが起こります。こちらのオブジェクトはＴＣＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇをＡＮＴ環境のなかのエンドポイントに送ることでパッシブクローズを完了します。
・アボート
エラーが発生すると、コネクションが不意にクローズされます。アボートは共有バッファのすべてのデータを消去して、即座にコネクションをクローズします。
コネクションが完全にクローズされると、ＴＣＰエンドポイントはこのメッセージに応答します。　ＴＣＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇはＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承しています。
【０４１３】
以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照を示す。
ａｂｏｒｔ：（入力）ＴＲＵＥの場合は、ＴＣＰコネクションは通常のやり方で停止されるかわりにアボートされます。
戻り値のＴＣＰエラーコードについては、「ＴＣＰエラー」を参照してください。また、関連項目としてＴＣＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇがあげられる。
【０４１４】
第８章　ＵＤＰリファレンス
この章では、オブジェクトがＵＤＰサービスを要求する目的でＩＰＳｔａｃｋに送付するＵＤＰメッセージについて説明します。すべてのメッセージはＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。
ＵＤＰエラー
以下に、この章で説明されているメッセージが返すエラーリストを示す。エラー値はＵＤＰＥｎｄｐｏｉｎｔＥｒｒｏｒで定義されています。オブジェクトがネットワーク操作を要求して、ＵＤＰエンドポイントより応答を受けた際には、その要求のエラーフィールドを調べてください（例えば、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ．ｅｒｒｏｒ）。
ＵＤＰ＿ＡＤＤＲＥＳＳＥＲＲＯＲ：指定されたＩＰアドレスとポート番号の組み合わせは無効です。
ＵＤＰ＿ＡＤＤＲＥＳＳＩＮＵＳＥ：指定されたＩＰアドレスとポート番号の組み合わせはすでに他のコネクションで使用されています。
ＵＤＰ＿ＢＵＦＦＥＲ＿ＩＮＶＡＬＩＤ：ＴＣＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇ或いはＴＣＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇのアドレスとサイズの引数は、共有バッファ内を示していません。
ＵＤＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＢＵＳＹ：コネクションがビジーで要求した操作は未完了です。メッセージ送信先のＵＤＰエンドポイントは、すでに別の要求を処理中と考えられます。
ＵＤＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＣＬＯＳＥＤ：エンドポイントはクローズされました。
ＵＤＰ＿ＦＡＩＬ：操作失敗です（これ以上の情報はありません）。
ＵＤＰ＿ＨＯＳＴ＿ＵＮＲＥＡＣＨＡＢＬＥ：ＩＰスタックが宛先アドレスへのルートを発見できませんでした。
ＵＤＰ−ＭＥＳＳＡＧＥ＿ＴＯＯ＿ＬＯＮＧ：ＵＤＰパケットが大きすぎて中間ルーターが処理できませんでした。
ＵＤＰ＿ＮＥＴＷＯＲＫ＿ＵＮＲＥＡＣＨＡＢＬＥ：ＩＰスタックが、宛先アドレスのあるネットワークへのルートを見つけられませんでした。
ＵＤＰ＿ＯＰＥＲＡＴＩＯＮ＿ＩＮＶＡＬＩＤ：要求した操作は、現在のエンドポイントの状態では許可されません。
ＵＤＰ＿ＯＰＥＲＡＴＩＯＮ＿ＵＮＫＮＯＷＮ：要求した操作は、ＵＤＰエンドポイントに認識されませんでした。
ＵＤＰ＿ＰＯＲＴ＿ＵＮＲＥＡＣＨＡＢＬＥ：コネクションの指定先のポートでリッスンされていません。
ＵＤＰ＿ＰＲＯＴＯＣＯＬ＿ＵＮＲＥＡＣＨＡＢＬＥ：宛先ホストがＵＤＰを実装していません。
ＵＤＰ＿ＳＵＣＣＥＳＳ：操作は成功しました。
ＵＤＰ＿ＴＩＭＥ＿ＥＸＣＥＥＤＥＤ：ＩＰ組み立てキュー（ＩＰ　ｒｅａｓｓｅｍｂｌｅ　ｑｕｅｕｅ）が時間切れになりました。
ＵＤＰ＿ＴＴＬ＿ＥＸＣＥＥＤＥＤ：宛先ホストが、発信元ホストからのＴＴＬ　ホップを超えています（宛先ホストと発信元ホスト間のノードが多すぎます）。
【０４１５】
ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ
以下のように定義する。

ここでは、ＩＰｖ４プロトコルスタック中のどのエンドポイントがＵＤＰサービス要求を受け取るか、またどのオブジェクトがその要求に対する応答を受け取るかを指定します。個々のネットワークサービスの要求は、ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承したメッセージで送られます。
【０４１６】
以下に、仮引数を示す。
ｅｒｒｏｒ：（出力）エンドポイントが返したＵＤＰＥｎｄｐｏｉｎｔＥｒｒｏｒです。エラーのリストは、上記記載を参照してください。
ｍｏｄｕｌｅ：（入力）ターゲットエンドポイントである。
ｏｐｅｒａｔｉｏｎ　　（入力）：送信側のオブジェクトが要求した操作である。
戻り値のＵＤＰエラーコードについては、「ＵＤＰエラー」を参照してください。また、関連項目として、ＵＤＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇ、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ、ＵＤＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇ、ＵＤＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇ、ＵＤＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇがあげられる。
【０４１７】
ＵＤＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇ
以下のように定義する。

ここでは、ローカルコネクションパラメタを設定します。ローカルコネクションパラメタは、オブジェクトをＵＤＰパケットの宛先として識別します。バインド操作を行なった後は、宛先アドレス及びポートがバインドパラメタにより指定されたＩＰアドレス及びポート番号と同一の場合のみ、オブジェクトはパケットを受信します。データ送信の際には、オブジェクトが最初にコネクション操作（すべてのパケットの宛先指定）を行っていない限り、パケット毎に宛先ＩＰアドレスとポート番号を指定してください。詳しくはＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇを参照してください。ＵＤＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇは　ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承しています。
【０４１８】
以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照を示す。
ａｄｄｒｅｓｓ：（入出力）ローカルホスト上の有効なＩＰアドレスです。ＩＰ＿ＡＤＤＲ＿ＡＮＹを指定すると、オブジェクトは、ローカルホスト上のどのＩＰアドレスに送信されたパケットでも受信します。これは、異なったアドレスで数個のインターフェイスをもつマルチホームホストにとっては有用です。ホストがマルチホームでない場合は、ローカルＩＰアドレスが返されます。マルチホームホスト上では、オブジェクトがエンドポイントをバインド後にコネクション操作を行うと、ＩＰ＿ＡＤＤＲ＿ＡＮＹが特定のＩＰアドレスに更新されます。
ｐｏｒｔ：（入出力）オブジェクトのポート番号。ＩＰ＿ＰＯＲＴ＿ＡＮＹを指定すると、一時的なポート番号がオブジェクトに割り当てられ、エンドポイントがバインドされた時点で一時的なポート番号が返されます。このポート番号は、１０２４以上となります。
戻り値のＵＤＰエラーコードについては、「ＵＤＰエラー」を参照してください。また、関連項目として、ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇがあげられる。
【０４１９】
ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ
以下のように定義する。

ここでは、オブジェクトが送信するあらゆるパケットに、宛先ＩＰアドレスとポート番号を指定します。この操作はＵＤＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇの送付後に実行してください。一度コネクションされると、オブジェクトはパケットを送信するたびに宛先を指定する必要がなくなります。ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇはＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。
【０４２０】
以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照を示す。
ａｄｄｒｅｓｓ：（入力）パケットの送信先であるコンピューターのＩＰアドレスを指定します。
ｐｏｒｔ：（入力）パケットの送信先であるオブジェクトのポート番号を指定します。
戻り値のＵＤＰエラーコードについては、「ＵＤＰエラー」を参照してください。また、関連項目として、ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＵＤＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇがあげられる。
【０４２１】
ＵＤＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇ
以下のように定義する。

ここでは、ＵＤＰエンドポイント経由でデータを送信します。オブジェクトがプロトコルスタックに送信するデータは、すべてａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体により定義された共有メモリーバッファに格納してください。データが共有バッファからＩＰスタック内部メモリーバッファにコピーされたときに、ＵＤＰエンドポイントがこのメッセージに応答します。ＵＤＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇはＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承しています。なお、ここで、エンドポイントがバインドされているがコネクションされていない場合は、このメッセージで宛先のＩＰアドレスとポート番号を指定してください。エンドポイントがＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇによりコネクションされている場合は、この情報は必要ありません。
【０４２２】
以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照を示す。
ａｄｄｒｅｓｓ：（入力）データの宛先コンピューターのＩＰアドレスです。オブジェクトがコネクション操作を済ませている場合は、この仮引数は無視され、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇで指定されたＩＰアドレスが使われます。
ｐｏｒｔ：（入力）データの宛先コンピューターのポート番号。オブジェクトがコネクション操作を済ませている場合は、この仮引数は無視され、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇで指定されたポート番号が使われます。
ｂｕｆｆｅｒ：（入力）送信のデータが格納されている（共有バッファ内の）位置である。
ｓｉｚｅ：（入力）バイト単位の送信データサイズである。
戻り値のＵＤＰエラーコードについては、「ＵＤＰエラー」を参照してください。また、関連項目として、ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４２３】
ＵＤＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇ
以下のように定義する。

ここでは、ＵＤＰエンドポイントよりデータを受信します。オブジェクトがプロトコルスタックより受信するすべてのデータは、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体により定義された共有メモリーバッファに格納されます。データが共有バッファへコピーされると、ＵＤＰエンドポイントがこのメッセージに応答します。受信操作が完了すると、仮引数ｓｉｚｅが受信したバイトの実際の数を返します。受信したパケットが指定されているｓｉｚｅより大きい場合は、余剰データは削除されます。ＵＤＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇはＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承しています。
【０４２４】
以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照を示す。
ｂｕｆｆｅｒ：（入力）受信データが格納される位置（共有バッファ内）です。
ｓｉｚｅ：（入力／出力）受信する最大バイト数を指定します。受信操作が完了すると、この仮引数は受信したバイトの実際の数を返します。受信したパケットがｓｉｚｅより大きい場合は、余剰データは削除されます。
ａｄｄｒｅｓｓ：（出力）受信データの発信元ＩＰアドレスである。
ｐｏｒｔ：（出力）受信データの発信元ポートである。
戻り値のＵＤＰエラーコードについては、「ＵＤＰエラー」を参照してください。またここで、関連項目として、ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＵＤＰＥｎｄｐｏｉｎｔＣｏｎｎｅｃｔＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４２５】
ＵＤＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇ
以下のように定義する。

ここでは、ＵＤＰエンドポイントをクローズします。このメッセージ送付後は、オブジェクトはデータの送受信ができません。コネクションが完全にクローズされると、エンドポイントが応答します。ＵＤＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇはＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇより継承したものです。
【０４２６】
以下に、ここでの仮引数を示す。
ｍｏｄｕｌｅ：宛先モジュールへの参照を示す。
戻り値のＵＤＰエラーコードに関する記述は、「ＵＤＰエラー」を参照してください。また、関連項目として、ＵＤＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇがあげられる。
【０４２７】
第９章　ＤＮＳリファレンス
本章では、オブジェクトがＤＮＳサービスを要求するとき、ＩＰＳｔａｃｋに送付するＤＮＳメッセージについて説明します。メッセージはすべてＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。
ＤＮＳエラー
以下に、この章で説明されているメッセージが返すエラーリストを示す。エラー値は、列挙型ＤＮＳＥｎｄｐｏｉｎｔＥｒｒｏｒで定義されます。オブジェクトがネットワーク操作を要求し、ＤＮＳエンドポイントから応答を受けた際には、その要求のエラーフィールドを調べて下さい（例えば、ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳＥｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇ．ｅｒｒｏｒ）。
ＤＮＳ＿ＢＵＦＦＥＲ＿ＩＮＶＡＬＩＤ：共有バッファの無効使用
ＤＮＳ＿ＣＯＮＮＥＣＴＩＯＮ＿ＢＵＳＹ：コネクションがビジーで、要求した操作は未完了です。メッセージの送付先であるＤＮＳエンドポイントはすでに別の要求を処理している可能性があります。
ＤＮＳ＿ＣＯＮＮＥＣＴＩＯＮ＿ＣＬＯＳＥＤ：コネクションがクローズされました。
ＤＮＳ＿ＦＡＩＬ：操作は失敗しました（これ以上の情報はありません）。
ＤＮＳ＿ＨＯＳＴ＿ＮＯＴ＿ＦＯＵＮＤ：指定されたホスト名ではバインド情報がありません。
ＤＮＳ＿ＩＮＤＥＸ＿ＩＮＶＡＬＩＤ：指定されたインデックスは存在しません。
ＤＮＳ＿ＮＯ＿ＤＡＴＡ：要求された型に相当するデータレコードは存在しません。
ＤＮＳ＿ＮＯ＿ＲＥＣＯＶＥＲＹ：回復不能のエラーが発生しました。
ＤＮＳ＿ＯＰＥＲＡＴＩＯＮ＿ＩＮＶＡＬＩＤ：現在の状態では、要求された操作は許可されません。
ＤＮＳ＿ＯＰＥＲＡＴＩＯＮ＿ＵＮＫＮＯＷＮ：要求された操作は、ＤＮＳエンドポイントによって認識されませんでした。
ＤＮＳ＿ＳＵＣＣＥＳＳ：操作は成功しました。
ＤＮＳ＿ＴＲＹ＿ＡＧＡＩＮ：要求されたホストは見つかりませんでした。もしくはサーバの要求は失敗しました。
【０４２８】
ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ
以下のように定義する。

ここでは、ＤＮＳネットワーク操作のあらゆる要求に対して基本メッセージを定義します。個々のネットワークサービスに対する要求は、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承したメッセージで送られます。本章で後述します。以下に、仮引数を示す。
ｅｒｒｏｒ：（出力）操作の結果を返します。
【０４２９】
また、関連項目として、ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇ、　ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇがあげられる。
【０４３０】
ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇ
以下のように定義する。

ここでは、オブジェクトがドメイン名とＩＰアドレスの解決を行なうために使用する、ＤＮＳサーバのリストを登録します。このリストはＤＮＳサーバをＩＰアドレスで指定します。リスト登録後は、検索はリスト順にサーバに送信されます。ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇはＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ．から継承しています。以下に、ここでの仮引数を示す。
ｎｓｃｏｕｎｔ：（入力）登録するＩＰアドレスの数である。
ａｄｄｒＬｉｓｔ［ＭＡＸＮＳ］：（入力）登録するＩＰアドレスのリストである。
戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。また、関連項目として、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４３１】
ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇ
以下のように定義する。

ここでは、オブジェクトがドメイン名とＩＰアドレスの解決を行なうために使用する、ＤＮＳサーバのリストを取得します。このリストはＤＮＳサーバをＩＰアドレスで示します。アドレスは事前にＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇで設定しておく必要が有ります。ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇは、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。以下に、ここでの仮引数を示す。
ｎｓｃｏｕｎｔ：（出力）登録されているＩＰアドレスの数である。
ａｄｄｒＬｉｓｔ［ＭＡＸＮＳ］：（出力）ＩＰアドレスのリストである。
戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。また、関連項目として、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＳｅｒｖｅｒＡｄｄｒｅｓｓｅｓＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４３２】
ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇ
以下のように定義する。

ここで、オブジェクト用に、デフォルトドメイン名を設定します。デフォルトドメイン名の登録後は、完全指定されていないホスト名にはすべてこのドメイン名が自動的に付加されます。ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇはＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。以下に、ここでの仮引数を示す。
ｎａｍｅ［ＭＡＸＤＮＡＭＥ］：（入力）デフォルトのドメイン名です。ドメイン名は、ｎｕｌｌで終わらせてください。
戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。また、関連項目として、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４３３】
ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇ
以下のように定義する。

ここで、オブジェクトに対するデフォルトドメイン名を取得します。ドメイン名は、あらかじめＤＮＳＥｎｄｐｏｉｎｔＳｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇで設定してください。ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇはＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。以下に、ここでの仮引数を示す。
ｎａｍｅ［ＭＡＸＤＮＡＭＥ］：（出力）デフォルトドメイン名です。ドメイン名は、ｎｕｌｌで終わっています。
戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。また、関連項目として、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＳｅｔＤｅｆａｕｌｔＤｏｍａｉｎＮａｍｅＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４３４】
ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇ
以下のように定義する。

ここでは、ドメイン名で指定されたホストのＩＰアドレスと、ドメイン名エイリアスとのリストを取得します。ホストエントリと呼ばれるこのリストには、ホストエントリを返したＤＮＳサーバのアドレス、リスト内の最初のＩＰアドレス（公式アドレス）、そしてそのホストに対するＩＰアドレスの総数、リスト内の最初のドメイン名（公式ドメイン名）、そしてそのホストに対するドメイン名エイリアスの総数が含まれている。異なるＩＰアドレスまたはドメイン名エイリアスの１つを取得したい場合には、それらを個別に要求してください。詳細は、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇ及びＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇを参照してください。ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇはＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。以下に、ここでの仮引数を示す。
ｎａｍｅ［ＭＡＸＤＮＡＭＥ］：（入力／出力）エントリを取得したいホストのドメイン名です。ドメイン名は、ｎｕｌｌで終わらせてください。ドメイン名エイリアスを指定した場合は、ホストの公式ドメイン名を返します。
ｓｅｒｖｅｒ＿ａｄｄｒｅｓｓ：（出力）ホストエントリを送信したＤＮＳサーバのＩＰアドレスである。
ｈｏｓｔ＿ａｄｄｒｅｓｓ：（出力）ホストのＩＰアドレスです。ホストが１つ以上のＩＰアドレスを使用している場合（マルチホーム）は、最初のＩＰアドレスを返します。
ｎ＿ａｄｄｒｅｓｓ：（出力）ホストのＩＰアドレスの個数である。
ｎ＿ａｌｉａｓ：（出力）ホストのドメイン名エイリアスの個数である。
戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。またここで、関連項目としてＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇ、　ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４３５】
ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇ
以下のように定義する。

ここでは、ＩＰアドレスで指定したホストに対する、ＩＰアドレスとドメイン名エイリアスとのリストを取得します。ホストエントリと呼ばれるこのリストには、そのホストエントリを返したＤＮＳサーバのアドレス、リスト内の最初のＩＰアドレス（公式アドレス）とそのホストに対するＩＰアドレスの総数、リスト内の最初のドメイン名（公式ドメイン名）とそのホストに対するドメイン名エイリアスの総数が含まれている。異なるＩＰアドレス、またはドメイン名エイリアスの１つを取得したい場合には、それらを個別に要求してください。詳細に関しては、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇとＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇを参照してください。ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇは、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。以下に、ここでの仮引数を示す。
ｈｏｓｔ＿ａｄｄｒｅｓｓ：（入力／出力）ホストのＩＰアドレスです。元のメッセージの異なるＩＰアドレスを指定しても、ホストの最初のＩＰアドレスを返します。
ｓｅｒｖｅｒ＿ａｄｄｒｅｓｓ：（出力）ホストエントリを送信したＤＮＳサーバのＩＰアドレスである。
ｎａｍｅ［ＭＡＸＤＮＡＭＥ］：（出力）ホストの公式ドメイン名です。ドメイン名はｎｕｌｌで終わります。
ｎ＿ａｄｄｒｅｓｓ：（出力）そのホストに対するＩＰアドレスの個数である。
ｎ＿ａｌｉａｓ：（出力）そのホストに対するドメイン名エイリアスの個数である。
戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。また、関連項目として、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇ、　ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４３６】
ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇ
以下のように定義する。

ここでは、指定したホストに対する登録ＩＰアドレスの１つを取得します。ただし、この操作を行う前にホストエントリを取得する必要がある。詳細に関しては、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇまたはＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇを参照してください。ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｄｄｒｅｓｓＭｓｇは、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。以下に、ここでの仮引数を示す。
ｉｎｄｅｘ：（入力）取得したいＩＰアドレスのインデックスです。このインデックスは、以前にそのホストエントリを受け取ったときにＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇまたはＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｅｒＭｓｇで返されたｎ−ａｄｄｒｅｓｓよりも小さい値でなければなりません。０を与えると、ホストエントリリストの最初のＩＰアドレスが返ります。
ａｄｄｒｅｓｓ：（出力）ホストエントリで、ｉｎｄｅｘの位置のＩＰアドレスである。
戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。また、関連項目として、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇ、　ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４３７】
ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇ
以下のように定義する。

ここでは、指定したホストに対するドメイン名のエイリアスの１つを取得します。ただし、この操作を行う前に、ホストエントリを取得してください。詳細に関しては、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇまたはＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇを参照してください。ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇは、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。以下に、ここでの仮引数を示す。
ｉｎｄｅｘ：（入力）取得したいドメイン名エイリアスのインデックスです。以前にそのホストエントリを受け取ったときにＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇまたはＤＮＳＥｎｄｐｏｉｎｔＢｙＡｄｄｒＭｓｇで返されたｎ−ａｌｉａｓよりも小さい値でなければなりません。０を与えると、ホストの公式ドメイン名を返します。
ｎａｍｅ［ＭＡＸＤＮＡＭＥ］：（出力）ホストエントリで、ｉｎｄｅｘの位置におけるドメイン名エイリアスである。
戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。関連項目としては、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＮａｍｅＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＨｏｓｔＢｙＡｄｄｒＭｓｇ、ＤＮＳＥｎｄｐｏｉｎｔＧｅｔＡｌｉａｓＭｓｇ、　ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４３８】
ＤＮＳＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇ
以下のように定義する。
ＤＮＳＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇ（）；
ここでは、ＤＮＳエンドポイントをクローズします。このメッセージの送付後は、オブジェクトはデータの送受信を行なえません。コネクションが完全にクローズしたとき、エンドポイントが返事を返します。ＤＮＳＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇはＢａｓｅＭｓｇから継承しています。戻り値のＤＮＳエラーコードについては、「ＤＮＳエラー」を参照してください。関連項目としては、ＤＮＳＥｎｄｐｏｉｎｔＢａｓｅＭｓｇがあげられる。
【０４３９】
第１０章　ＩＰリファレンス
オブジェクトがＩＰＳｔａｃｋに送付するＩＰメッセージについて説明します。このメッセージは、ネットワークサービスを要求するときに使用されます。メッセージは、すべてＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ．から継承しています。
ＩＰエラー
以下に、本章のメッセージが返すエラーリストを示す。エラー値は、ＩＰＥｎｄｐｏｉｎｔＥｒｒｏｒ列挙型で定義されています。オブジェクトがネットワーク操作を要求し、そのＩＰエンドポイントから応答を受けた際には、要求のエラーフィールドを調べてください（例えば、ＩＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇ．ｅｒｒｏｒ）。
ＩＰ＿ＢＵＦＦＥＲ＿ＩＮＶＡＬＩＤ：共有バッファの無効使用です。
ＩＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＢＵＳＹ：コネクションがビジーで、要求した操作は未完了です。メッセージの送信先であるＩＰエンドポイントはすでに別の要求を処理している可能性があります。
ＩＰ＿ＣＯＮＮＥＣＴＩＯＮ＿ＣＬＯＳＥＤ：コネクションがクローズされました。
ＩＰ＿ＦＡＩＬ：操作は失敗しました（これ以上の情報はありません）。
ＩＰ＿ＩＮＶＡＬＩＤ＿ＰＲＯＴＯＣＯＬ：指定したプロトコル識別子は有効ではありません。
ＩＰ＿ＯＰＥＲＡＴＩＯＮ＿ＩＮＶＡＬＩＤ：現在の状況では要求した操作は許可されません。
ＩＰ＿ＯＰＥＲＡＴＩＯＮ＿ＵＮＫＮＯＷＮ：要求した操作は、ＩＰエンドポイントによって認識されませんでした。
ＩＰ＿ＰＡＣＫＥＴＳＩＺＥ：指定したパケットサイズは正しくありません。
ＩＰ＿ＳＵＣＣＥＳＳ：操作は成功しました。
【０４４０】
ＩＰパケットタイプ
ＩＰエンドポイントは、以下に記載するように種々のパケットを送受信することが可能です。ただし、通常のＩＰパケットはＩＰ＿ＤＡＴＡ型です。これ以外の型はＩＣＭＰパケットに対するものです。
ＩＰ＿ＤＡＴＡ：通常のＩＰデータ
ＩＰ＿ＨＯＳＴ＿ＵＮＲＥＡＣＨＡＢＬＥ：（ＩＣＭＰパケット）ホストに到達できません。
ＩＰ＿ＭＥＳＳＡＧＥ＿ＴＯＯ＿ＬＯＮＧ：（ＩＣＭＰパケット）メッセージが長すぎるか、或いは伝送中にいずれかの地点で分割に失敗しました。
ＩＰ＿ＮＥＴＷＯＲＫ＿ＵＮＲＥＡＣＨＡＢＬＥ：（ＩＣＭＰパケット）ネットワークに到達できません。
ＩＰ＿ＰＯＲＴ＿ＵＮＲＥＡＣＨＡＢＬＥ：（ＩＣＭＰパケット）要求したポートに到達できませんでした。
ＩＰ＿ＰＲＯＴＯＣＯＬ＿ＵＮＲＥＡＣＨＡＢＬＥ：（ＩＣＭＰパケット）要求したプロトコルはターゲットホスト上にありませんでした。
ＩＰ＿ＴＩＭＥ＿ＥＸＣＥＥＤＥＤ：（ＩＣＭＰパケット）パケット組み立てがタイムアウトとなりました。
ＩＰ＿ＴＴＬ＿ＥＸＣＥＥＤＥＤ：（ＩＣＭＰパケット）パケットのＴＴＬが、伝送中に期限切れとなりました。
【０４４１】
ＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ
メンバーは、以下である。

ここでは、すべてのＩＰネットワーク操作の要求に対して、基本メッセージを定義します。個々のネットワークサービスに対する要求は、ＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承したメッセージで送られます。本章で後述します。以下に、仮引数を示す。
ｅｒｒｏｒ：（出力）操作の結果を返します。
戻り値のＩＰエラーコードの説明に関しては、「ＩＰエラー」を参照してください。関連項目としては、ＩＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇ、ＩＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇ、ＩＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇ、ＩＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇがあげられる。
【０４４２】
ＩＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇ
メンバーは、以下である。

ここでは、エンドポイントを特定のプロトコルにバインドします。このエンドポイントを経由してオブジェクトが送受信するパケットは、すべて指定のプロトコルから発するものとして扱われます。プロトコルがバインドされてＩＰパケットを送受信できるようになると、エンドポイントはこのメッセージに応答します。ＩＰＥｎｄｐｏｉｎｔＢｉｎｄＭｓｇはＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ．から継承しています。ただし、ＴＣＰプロトコルまたはＵＤＰプロトコルは、プロトコルスタック内ですでにバインド済みなので、エンドポイントをこれらのプロトコルにバインドすることはできません。バインドを試みても、エラーＩＰ＿ＩＮＶＡＬＩＤ＿ＰＲＯＴＯＣＯＬが返ります。エンドポイントをＩＣＭＰにバインドすることはできます。ＩＣＭＰは認識したパケットを通常通りすべて処理します。しかし、認識しなかったパケットはすべてバインド済みのエンドポイントに転送します。以下に、仮引数を示す。
ｐｒｏｔｏｃｏｌ：（入力）エンドポイントにバインドするプロトコルです。各プロトコルは２５６未満の整数によって識別されます。
戻り値のＩＰエラーコードについては、「ＩＰエラー」を参照してください。関連項目としては、ＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇがあげられる。
【０４４３】
ＩＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇ
メンバーは、以下である。

ここでは、ＩＰパケットを送信します。オブジェクトがプロトコルスタックに送信するデータは、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体で定義された共有メモリーバッファ内に格納してください。データが共有バッファからＩＰＳｔａｃｋ内部メモリーバッファにコピーされると、ＩＰエンドポイントはメッセージに応答します。ＩＰＥｎｄｐｏｉｎｔＳｅｎｄＭｓｇはＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ．から継承しています。以下に、ここでの仮引数を示す。
ｔｙｐｅ：（入力）送信するパケットのタイプ通常のＩＰパケットは、ＩＰ＿ＤＡＴＡタイプである。
ｂｕｆｆｅｒ：（入力）送信するパケットが格納されている位置（共有バッファ内）である。
ｓｉｚｅ：（入力）送信するパケットのサイズで、単位はバイトです。
戻り値のＩＰエラーコードについては、「ＩＰエラー」を参照してください。関連項目としては、ＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４４４】
ＩＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇ
メンバーは、以下である。

ここでは、ＩＰパケットを受信します。オブジェクトがプロトコルスタックから受信するデータはａｎｔＳｈａｒｅｄＢｕｆｆｅｒ構造体によって定義された共有メモリーバッファ内に格納されます。データの共有バッファへのコピーが完了すると、ＩＰエンドポイントはメッセージに応答します。Ｓｉｚｅ仮引数は、受信した実際のバイト数を返します。受信したパケットが共有バッファより大きい場合はパケットの一部だけがバッファ内に格納され、ＩＰ＿ＰＡＣＫＥＴＳＩＺＥエラーが返ります。ＩＰＥｎｄｐｏｉｎｔＲｅｃｅｉｖｅＭｓｇはＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ．から継承しています。以下に、ここでの仮引数を示す。
ｔｙｐｅ：（出力）受信したパケットの型です。通常のＩＰパケットはＩＰ＿ＤＡＴＡ型です。
ｂｕｆｆｅｒ：（入力）受信したパケットを格納されている位置（共有バッファ内）である。
ｓｉｚｅ：（入力／出力）受信する最大バイト数を指定します。受信操作が完了し、エンドポイントがオブジェクトに応答すると、仮引数は実際に受信したバイト数を返します。受信したパケットが共有バッファより大きい場合は、パケットの一部だけがバッファ内に格納され、ＩＰ＿ＰＡＣＫＥＴＳＩＺＥエラーが返ります。
戻り値のＩＰエラーコードについては、「ＩＰエラー」を参照してください。関連項目としては、ＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇ、ａｎｔＳｈａｒｅｄＢｕｆｆｅｒがあげられる。
【０４４５】
ＩＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇ
メンバーは、以下である。
ＩＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇ（）；
ここでは、ＩＰコネクションをクローズします。このメッセージを送った後は、オブジェクトはデータの送受信を行うことができません。コネクションが完全にクローズすると、エンドポイントは応答します。ＩＰＥｎｄｐｏｉｎｔＣｌｏｓｅＭｓｇはＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇから継承しています。
戻り値のＩＰエラーコードについては、「ＩＰエラー」を参照してください。関連項目としては、ＩＰＥｎｄｐｏｉｎｔＢａｓｅＭｓｇがあげられる。
【０４４６】
なお、以上のインターネットプロトコルに関する記載において、「ＡＮＴ環境」とは、オブジェクトにネットワークサービスを提供するＯＰＥＮ−Ｒシステム層のオブジェクトを示す。ＡＮＴ環境は、通常のメッセージパッシングを使用してオブジェクトと通信を行います。ＡＮＴ環境は、デバイスドライバーとも直接通信を行います。このデバイスドライバーは、物理ネットワーク上でデータ交換を行います。また、「ｄａｔａｇｒａｍ」とは、ＵＤＰプロトコルで、パケットに相当する。「ＤＮＳ」とは、ＩＰｖ４プロトコルスタックで、ＵＤＰレイヤーの上位で動作するプロトコルです。インターネットのドメイン名とＩＰアドレスの設定、取得、変換のサービスを提供します。また、「エンドポイント」とは、オブジェクトがメッセージパッシングでＡＮＴ環境と通信するためのものです。エンドポイントはプロトコルスタックの最上位に位置しています。オブジェクトは、オープンしたネットワークコネクション１つに対して１つのエンドポイントを持ちます。オブジェクトが新ネットワークコネクションを要求すると、エンドポイントは動的に作成されます。オブジェクトは新エンドポイントに対する要求をエンドポイントファクトリーに送付し、エンドポイントファクトリーがエンドポイントを作成します。
【０４４７】
また、「Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ（ＩＰ）」とは、ネットワーク越しにパケットを伝送する役割のネットワークプロトコルです。ＩＰｖ４プロトコルスタックで、ＩＰは最下層です。通常、オブジェクトはＩＰと直接通信しません。代わりに、オブジェクトはＴＣＰやＵＤＰといったＩＰの上位の層とのコネクションをオープンします。ただし、オブジェクトによっては直接ＩＰ層を使用することもできます。例えば、ＡＮＴ環境内のプログラミングを行うことなく新規のプロトコルを追加したい場合は、ＩＰ層と直接通信するオブジェクトとしてプロトコルを記述できます。Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ　ｖｅｒｓｉｏｎ　４（ＩＰｖ４）　Ｐｒｏｔｏｃｏｌ　ｓｔａｃｋでは、ＡＮＴ環境内のプロトコルスタックで、ＴＣＰ、ＵＤＰ、ＤＮＳ、ＩＰのネットワークプロトコルを提供します。
また、「ＳＤＵ（サービスデータユニット）」は、ＡＮＴ環境内の基本データコンテナーです。ＳＤＵは、ＳＤＵプール内の一連のデータセルに対するポインタです。ＳＤＵはネットワークへ送信されつつあるデータを収容しています。これはＯＳＩ標準では、プロトコルデータユニット（ＰＤＵ）と呼ばれています。「ＳＤＵプール」は、ＡＮＴ環境内のメモリーバッファで、プロトコルスタックによって処理されるデータを格納します。ＡＮＴ環境は、ＳＤＵプール内にサービスデータユニット（ＳＤＵ）を割り当てます。
【０４４８】
＜インストールガイド＞
第１章　　導入
１．１　準備
以上説明したＯＰＥＮ−Ｒ　ＳＤＫは、Ｗｉｎｄｏｗｓ２０００，Ｐｒｏｆｅｓｓｉｏｎａｌ／ＸＰ（何れも登録商標）のプラットホームで動作する。なお、ＯＰＥＮ−Ｒ　ＳＤＫはＷｉｎｄｏｗｓ環境以外の他のオペレーティングシステム上でも動作するが、そのためには、ｓｈ、ｃｐなどの標準Ｕｎｉｘコマンド、ｐｅｒｌ、ＧＮＵ　ｍａｋｅ、ＧＮＵ　ｂｉｎｕｔｉｌｓ、ｇｃｃ、ｎｅｗｌｉｂなどのｍｉｐｓクロス開発環境が必要となる。これらのツールは、通常のＵｎｉｘ環境と互換性があります。Ｗｉｎｄｏｗｓ上のＣｙｇｗｉｎで動作するこれらのｍｉｐｓクロス開発環境のバイナリーは、ＯＰＥＮ−Ｒ　ＳＤＫのｗｅｂサイトからダウンロードできます。これらのツールを他のＵｎｉｘ環境で動作させる場合は、「２．２　ｇｃｃ　」を参照してください。Ｗｉｎｄｏｗｓ環境以外では、ソースコードからバイナリーツールを自動的に生成するシェルスクリプトを提供しています。このスクリプトやＯＰＥＮ−Ｒ　ＳＤＫが、Ｌｉｎｕｘ上で正常動作することを確認済みです。
【０４４９】
また、ＯＰＥＮ−Ｒ　ＳＤＫを使用してソフト開発するためには、以下のハードウェアが必要である。ＣＰＵ：Ｐｅｎｔｉｕｍ　２３３ＭＨｚ以上、メモリ：６４ＭＢ以上、ハードディスク：２００ＭＢ以上の空き容量、メモリスティックリーダーライター：ＰＣに内蔵または外付け、ＡＩＢＯ　ＥＲＳ−２１０、ＥＲＳ−２２０、ＥＲＳ−２１０Ａ、ＥＲＳ−２２０Ａの何れか。また、無線ＬＡＮ環境として、ＰＣ側には、（ａ）ＩＥＥＥ８０２．１１ｂ準拠の無線ＬＡＮカード、（ｂ）有線ＬＡＮカードとＩＥＥＥ８０２．１１ｂ準拠のアクセスポイントの何れかを必要とする。また、ＡＩＢＯ側には、ＡＩＢＯワイヤレスＬＡＮカード（ＥＲＡ−２０１Ｄ１）及びＡＩＢＯプログラミングメモリスティックが必要である。なお、本ＯＰＥＮ−Ｒ　ＳＤＫを使用したソフト開発では、ＡＩＢＯプログラミングメモリスティック以外のメモリスティックは使用できないようになっている。
【０４５０】
１．２　ダウンロード
以下は、ダウンロードファイルのリストである。
・ＯＰＥＮ−Ｒ　ＳＤＫ
例えば、ＯＰＥＮ−Ｒ　ＳＤＫ本体（ＯＰＥＮ＿Ｒ＿ＳＤＫ−１．１．３−ｒ１．ｔａｒ．ｇｚ）、サンプルプログラム（ＯＰＥＮ＿Ｒ＿ＳＤＫ−ｓａｍｐｌｅ−１．１．３−ｒ１．ｔａｒ．ｇｚ）、日本語マニュアル（ＯＰＥＮ＿Ｒ＿ＳＤＫ−ｄｏｃＪ−１．１．３−ｒ１．ｔａｒ．ｇｚ）、英語マニュアル（ＯＰＥＮ＿Ｒ＿ＳＤＫ−ｄｏｃＥ−１．１．３−ｒ１．ｔａｒ．ｇｚ）に分けられて、インターネットによりダウンロードできるようになっている。
・Ｗｉｎｄｏｗｓ環境での開発ツール
また、この他にＷｉｎｄｏｗｓ環境での開発ツールとして、Ｃｙｇｗｉｎ（ｃｙｇｗｉｎ−ｐａｃｋａｇｅｓ−１．３．１０−ｂｉｎ．ｅｘｅ）、ＭＩＰＳクロス開発環境のツール（ｍｉｐｓｅｌ−ｄｅｖｔｏｏｌｓ−３．０．４−ｂｉｎ−ｒ１．ｔａｒ．ｇｚ）を必要とする。
・ＥＲＳ−２１０ユーザー用ユーティリティ
ｕｐｇｒａｄｅ−ＯＰＥＮ＿Ｒ−１．１．３−ｒ１．ｔａｒ．ｇｚ　・・・ＥＲＳ−２１０用のフラッシュ更新
・ソースファイル
ｃｙｇｗｉｎ−ｐａｃｋａｇｅｓ−１．３．１０−ｓｒｃ．ｔａｒ．ｇｚ　・・・Ｃｙｇｗｉｎのソース
ｂｉｎｕｔｉｌｓ−２．１２．ｔａｒ．ｇｚ　・・・ｂｉｎｕｔｉｌｓ　のソース
ｇｃｃ−３．０．４．ｔａｒ．ｇｚ　・・・ｇｃｃ　のソース
ｎｅｗｌｉｂ−１．９．０．ｔａｒ．ｇｚ　・・・ｎｅｗｌｉｂの　ソース
ｂｕｉｌｄ−ｄｅｖｔｏｏｌｓ−３．０．４−ｒ１．ｓｈ　・・・上記３個のファイルのビルド用のシェルスクリプト
なお、上述のファイル名における数値は、バージョン番号を表しています。ファイルが変更された場合はバージョン番号も変更されます。
【０４５１】
第２章　インストール
２．１　Ｃｙｇｗｉｎ
Ｗｉｎｄｏｗｓ環境の場合には、最初にＣｙｇｗｉｎをインストールします。Ｃｙｇｗｉｎを使用すると、Ｗｉｎｄｏｗｓ上で標準的なＵｎｉｘコマンドが動作します。以下の手順でＣｙｇｗｉｎをインストールする。
１．ｃｙｇｗｉｎ−ｐａｃｋａｇｅｓ−１．３．１０−ｂｉｎ．ｅｘｅをダブルクリックします。
２．Ｕｎｚｉｐを実行するフォルダーを指定し、［Ｕｎｚｉｐ］をクリックするとｃｙｇｗｉｎ−ｐａｃｋａｇｅｓ−１．３．１０ディレクトリが作成されるので、このなかにあるｓｅｔｕｐ．ｅｘｅを実行します。
３．ｓｅｔｕｐ．ｅｘｅのバージョンが表示されるので、［Ｎｅｘｔ−＞］をクリックします。
４．［Ｉｎｓｔａｌｌ　ｆｒｏｍ　Ｌｏｃａｌ　Ｄｉｒｅｃｔｏｒｙ］を選択し、［Ｎｅｘｔ−＞］をクリックします。
５．Ｃｙｇｗｉｎをインストールするディレクトリを指定します。特に必要が無い限り’Ｃ：￥ｃｙｇｗｉｎ’の指定のままにしてください。テキストファイル型に［Ｕｎｉｘ］を選択し、［Ｎｅｘｔ−＞］をクリックします。
６．ｓｅｔｕｐ．ｅｘｅがあるディレクトリを指定し、［Ｎｅｘｔ−＞］をクリックします。
７．パッケージ内容の選択画面が表示されます。デフォルトの設定のままにし、［Ｎｅｘｔ−＞］をクリックします。
【０４５２】
ただし、このパッケージにはＯＰＥＮ−Ｒ　ＳＤＫを使用するために必要な最小限のツールのみが含まれています。新規にツールを追加するには、ｓｅｔｕｐ．ｅｘｅを再実行し、手順４で［Ｉｎｓｔａｌｌ　ｆｒｏｍ　Ｉｎｔｅｒｎｅｔ］　を選択する。
【０４５３】
２．２　ｇｃｃ
Ｃｙｇｗｉｎ上の　／ｕｓｒ／ｌｏｃａｌ　（Ｃ：￥ｃｙｇｗｉｎ￥ｕｓｒ￥ｌｏｃａｌ）でパッケージを解凍します。以降の説明では、Ｃｙｇｗｉｎ上の／ｕｓｒ／ｌｏｃａｌのことを単に／ｕｓｒ／ｌｏｃａｌと記述し、ｃ：￥ｃｙｇｗｉｎ￥ｕｓｒ￥ｌｏｃａｌとは記述しません。以下の手順でｇｃｃをインストールする。以下では、ｍｉｐｓｅｌ−ｄｅｖｔｏｏｌｓ−３．０．４−ｂｉｎ−ｒ１．ｔａｒ．ｇｚを／ｕｓｒ／ｌｏｃａｌに置くと仮定します。
１．パッケージを解凍します。ここで、／ｘｘｘはダウンロードしたディレクトリです。
ｃｄ　／ｕｓｒ／ｌｏｃａｌ
ｔａｒ　ｘｚｆ　／ｘｘｘ／ｍｉｐｓｅｌ−ｄｅｖｔｏｏｌｓ−３．０．４−ｂｉｎ−ｒ１．ｔａｒ．ｇｚ
／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫ　ディレクトリが生成され、そのなかにｍｉｐｓｅｌ−ｌｉｎｕｘを対象とする以下のツールやライブラリがインストールされます。
ＧＮＵ　ｂｉｎｕｔｉｌｓ−２．１２
ＧＮＵ　ｇｃｃ−３．０．４
ｎｅｗｌｉｂ−１．９．０
なお、ここではｌｉｎｕｘを対象名としていますが、ＡＩＢＯ上でＬｉｎｕｘが動作する意味ではありません。　Ｕｎｉｘ環境を使用する場合は、ｂｕｉｌｄ−ｄｅｖｔｏｏｌｓ−３．０．４．ｓｈ　を実行すると自動的に開発環境を生成します。ｂｕｉｌｄ−ｄｅｖｔｏｏｌｓ−３．０．４．ｓｈと同じディレクトリに以下のファイルを置いて、　ｂｕｉｌｄ−ｄｅｖｔｏｏｌｓ−３．０．４．ｓｈ　を実行してください。
ｂｉｎｕｔｉｌｓ−２．１２．ｔａｒ．ｇｚ
ｇｃｃ−３．０．４．ｔａｒ．ｇｚ
ｎｅｗｌｉｂ−１．９．０．ｔａｒ．ｇｚ
【０４５４】
２．３　ＯＰＥＮ−Ｒ　ＳＤＫ
続いて、以下の手順でＯＰＥＮ−Ｒ　ＳＤＫ本体をインストールする。
１．パッケージを解凍します（／ｘｘｘはダウンロードしたディレクトリです）。
ｃｄ／ｕｓｒ／ｌｏｃａｌ
ｔａｒ　ｘｚｆ　／ｘｘｘ／ＯＰＥＮ＿Ｒ＿ＳＤＫ−１．１．３−ｒ１．ｔａｒ．ｇｚ
ここでは、／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫ／ＯＰＥＮ＿Ｒディレクトリが生成されます。
【０４５５】
２．４　サンプルプログラム
続いて、以下の手順でサンプルプログラムをインストールする。
任意のディレクトリに移動し、パッケージを解凍します（／ｍｙｄｉｒは任意のディレクトリ、／ｘｘｘはダウンロードしたディレクトリです）。
ｃｄ　／ｍｙｄｉｒ
ｔａｒ　ｘｚｆ　／ｘｘｘ／ＯＰＥＮ＿Ｒ＿ＳＤＫ−ｓａｍｐｌｅ−１．１．３−ｒ１．ｔａｒ．ｇｚ
ここでｓａｎｐｌｅディレクトリが生成され、そのなかに複数のサンプルプログラムがインストールされます。
【０４５６】
２．５　ＡＩＢＯ本体内蔵フラッシュＲＯＭの更新
ＯＰＥＮ−Ｒ　ＳＤＫで作成したプログラムを動作させるために、ＡＩＢＯ　ＥＲＳ−２１０では、フラッシュＲＯＭを更新する必要があります。ただし、ＡＩＢＯが　’ＯＰＥＮ−Ｒ　Ｖｅｒ．１．１．２’または　’ＯＰＥＮ−Ｒ　Ｖｅｒ．１．１．３’に対応している場合、または、ＥＲＳ−２２０、ＥＲＳ−２１０Ａ、ＥＲＳ−２２０Ａの場合は、フラッシュＲＯＭの更新の必要はありません。本体内蔵フラッシュＲＯＭの更新は、以下の手順にて行う。
１．任意のディレクトリに移動し、パッケージを解凍します（／ｍｙｄｉｒは任意のディレクトリ、／ｘｘｘはダウンロードしたディレクトリです）。
ｃｄ　／ｍｙｄｉｒ
ｔａｒ　ｘｚｆ　／ｘｘｘ／ｕｐｇｒａｄｅ−ＯＰＥＮ−Ｒ＿１．１．３−ｒ１．ｔａｒ．ｇｚ
ここで、Ｕｐｇｒａｄｅディレクトリが作成されます。フラッシュＲＯＭの更新手順は、ＵｐｇｒａｄｅディレクトリにあるＲＥＡＤＭＥ＿Ｊ．ＴＸＴに記述されています。
【０４５７】
第３章　ＨｅｌｌｏＷｏｒｌｄのビルドと実行
続いて、インストールが成功したことをサンプルプログラムのＨｅｌｌｏＷｏｒｌｄのビルドと実行で確認する。Ｈｅｌｌｏ　Ｗｏｒｌｄは、ＨＥＬＬＯ．ＢＩＮとＰＯＷＥＲＭＯＮ．ＢＩＮに対応するＯＰＥＮ−Ｒオブジェクトから構成され、’Ｈｅｌｌｏ　Ｗｏｒｌｄ’を無線コンソールに出力します（以降の説明ではＯＰＥＮ−Ｒオブジェクトのことをオブジェクトと記述します）。ＨｅｌｌｏＷｏｒｌｄディレクトリは、以下のサブディレクトリを含む。
ＨｅｌｌｏＷｏｒｌｄ／ＨｅｌｌｏＷｏｒｌｄ　：ＨｅｌｌｏＷｏｒｌｄオブジェクトのソース
ＨｅｌｌｏＷｏｒｌｄ／ＭＳ　：ＡＩＢＯプログラミングメモリスティックに置くファイルです。最初はＯＢＪＥＣＴ．ＣＦＧのみで、後に実行ファイルがコピーされます。
【０４５８】
３．１　ビルド
以下の手順でサンプルプログラムをビルドする。
１．実行ファイルをビルドします。
ｃｄ　ｓａｍｐｌｅ／ＨｅｌｌｏＷｏｒｌｄ
ｍａｋｅ
ｍａｋｅ　ｉｎｓｔａｌｌ
ここで、実行ファイルが生成され、ＭＳディレクトリにコピーされます。なお、本ＯＰＥＮ−Ｒ　ＳＤＫを／ｕｓｒ／ｌｏｃａｌ以外のディレクトリにインストールする場合は、以下の様にＯＰＥＮ−Ｒ　ＳＤＫディレクトリのパスを指定する。
（／ｍｙｄｉｒは、ＯＰＥＮ−Ｒ　　ＳＤＫをインストールしたディレクトリです）。
ｍａｋｅ　ＰＲＥＦＩＸ＝／ｍｙｄｉｒ／ＯＰＥＮ＿Ｒ＿ＳＤＫ
なお、ファイル名は、８＋３フォーマット（ｘｘｘｘｘｘｘｘ．ｘｘｘ）です。ファイルは、ｇｚｉｐされます。ｇｚｉｐは、必須ではありませんがＡＩＢＯプログラミングメモリスティック上のメモリを節約できます。
【０４５９】
３．２　実行
３．２．１　無線ＬＡＮ環境での実行
以下の手順で無線ＬＡＮ環境を設定しプログラムを実行する。
１．空のＡＩＢＯプログラミングメモリスティックに、以下の２個のＯＰＥＮ−Ｒディレクトリをコピーします（／ｍｙｄｉｒはサンプルプログラムをインストールしたディレクトリです）。
／ｕｓｒ／ｌｏｃａｌ／ＯＰＥＮ＿Ｒ＿ＳＤＫ／ＯＰＥＮ＿Ｒ／ＭＳ／ＷＣＯＮＳＯＬＥ／ｍｅｍｐｒｏｔ／ＯＰＥＮ−Ｒ
／ｍｙｄｉｒ／ｓａｍｐｌｅ／ＨｅｌｌｏＷｏｒｌｄ／ＭＳ／ＯＰＥＮ−Ｒ
２．ＡＩＢＯプログラミングメモリスティック上にあるＷＬＡＮＣＯＮＦ．ＴＸＴを編集して、ＡＩＢＯ側の無線ＬＡＮの設定を行います。詳細は「３．２．２　ＷＬＡＮＣＯＮＦ．ＴＸＴの設定」を参照してください。
３．ＡＩＢＯワイヤレスＬＡＮカードをＡＩＢＯに装着します。
４．ＰＣ側の無線ＬＡＮ環境を設定します。　ＰＣとＡＩＢＯを無線ＬＡＮで接続するには、アクセスポイントを使用する方法と使用しない方法があります。ＡＩＢＯがネットワークに接続されているか確認するには、以下のコマンドを実行するとよい。
ｐｉｎｇ　（ＡＩＢＯのＩＰアドレス）
５．ＰＣからＡＩＢＯの無線コンソールに接続するため、ＰＣ側で下記のようにｔｅｌｎｅｔプログラムを起動しておきます。ＡＩＢＯの無線コンソールはＴＣＰポート番号５９０００でｔｅｌｎｅｔプロトコルを使用します（他のｔｅｌｎｅｔプログラムを使用しても構いません）。
ｔｅｌｎｅｔ　（ＡＩＢＯのＩＰアドレス）　５９０００
６．ＡＩＢＯプログラミングメモリスティックをＡＩＢＯに挿入し、ＡＩＢＯを起動します。一連のシステム情報が出力された後に’！！！　Ｈｅｌｌｏ　Ｗｏｒｌｄ　！！！’の文字列が表示されれば正常に動作しています。
７．ＡＩＢＯのポーズボタンを押してシャットダウンしてください。
【０４６０】
３．２．２　ＷＬＡＮＣＯＮＦ．ＴＸＴの設定
ＡＩＢＯプログラミングメモリスティックの／ＯＰＥＮ−Ｒ／ＳＹＳＴＥＭ／ＣＯＮＦ／には、２種類の無線ＬＡＮ設定ファイル、ＷＬＡＮＤＦＬＴ．ＴＸＴとＷＬＡＮＣＯＮＦ．ＴＸＴがあります。ＷＬＡＮＤＥＬＴ．ＴＸＴは、ＡＩＢＯ無線ＬＡＮカードのデフォルトの設定がされているので編集しないでください。ＷＬＡＮＣＯＮＦ．ＴＸＴはユーザーの設定用のファイルです。ＡＩＢＯが起動するとＷＬＡＮＣＯＮＦ．ＴＸＴを最初に見にいき、ファイルが存在すればそのなかの情報を使います。ファイルが存在しないときはＷＬＡＮＤＦＬＴ．ＴＸＴの情報を使います。ＷＬＡＮＤＦＬＴ．ＴＸＴをＷＬＡＮＣＯＮＦ．ＴＸＴのファイル名でコピーして編集します。ＷＬＡＮＣＯＮＦ．ＴＸＴの内容は、デフォルトでは以下に設定されています。
ＨＯＳＴＮＡＭＥ＝ＡＩＢＯ
ＥＴＨＥＲ＿ＩＰ＝１０．０．１．１００
ＥＴＨＥＲ＿ＮＥＴＭＡＳＫ＝２５５．２５５．２５５．０
ＩＰ＿ＧＡＴＥＷＡＹ＝１０．０．１．１
ＥＳＳＩＤ＝ＡＩＢＯＮＥＴ
ＷＥＰＥＮＡＢＬＥ　＝１
ＷＥＰＫＥＹ　＝ＡＩＢＯ２
ＡＰＭＯＤＥ　＝２
ＣＨＡＮＮＥＬ＝３
各項目の意味は、以下の通りである。
ＨＯＳＴＮＡＭＥ：ＡＩＢＯに無線ネットワーク上で使用する名前を指定します。半角英数字で最大８文字の文字列を指定します。
ＥＴＨＥＲ＿ＩＰ：ＡＩＢＯが使用するＩＰアドレスを指定します。
ＥＴＨＥＲ＿ＮＥＴＭＡＳＫ：ＩＰサブネットマスクを指定します。
ＩＰ＿ＧＡＴＥＷＡＹ：ゲートウェイのＩＰアドレスを指定します。ネットワーク上にゲートウェイが存在しない場合は、ＥＴＨＥＲ＿ＩＰと同じＩＰアドレスを設定してください。
ＥＳＳＩＤ：無線ネットワークの名前を指定します。最大３２文字の半角英数字を指定します。
ＷＥＰＥＮＡＢＬＥ：ＷＥＰ（無線暗号システム）を使うかどうかを指定します。使用しない場合は、‘０’であり、使用する場合は‘１’である。
ＷＥＰＫＥＹ：（ＷＥＰｋｅｙ（無線暗号キー）を指定します。半角英数字５文字で指定する。
ＡＰＭＯＤＥ：ＡＩＢＯの無線ＬＡＮモードを指定します。Ａｄ　Ｈｏｃ　Ｄｅｍｏ　Ｍｏｄｅで接続する場合は‘０’、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　Ｍｏｄｅで接続する場合は‘１’、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　Ｍｏｄｅ、Ａｄ　Ｈｏｃ　Ｄｅｍｏ　Ｍｏｄｅの順で自動接続する場合は‘２’を指定する。
ＣＨＡＮＮＥＬ：Ａｄ　Ｈｏｃ　Ｄｅｍｏ　Ｍｏｄｅ時に使用するチャンネルを指定します。１−１１までの数値で指定してください。
【０４６１】
なお、無線ＬＡＮカードを挿入したＰＣとＡＩＢＯとをアクセスポイントを使用せず直接に接続する場合（ＩＢＳＳ　Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ　ＭｏｄｅまたはＡｄ　Ｈｏｃ　Ｄｅｍｏ　Ｍｏｄｅ）は、まず、ＥＳＳＩＤ、ＷＥＰＥＮＡＢＬＥ、ＷＥＰＫＥＹをＰＣと同じ設定にする。また、ＩＢＳＳ　Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ　Ｍｏｄｅで接続する場合は、ＡＰＭＯＤＥ＝１に指定する。Ａｄ　Ｈｏｃ　Ｄｅｍｏ　Ｍｏｄｅで接続する場合は、ＡＰＭＯＤＥ＝０に指定し、ＣＨＡＮＮＥＬは、ＰＣの設定に合せます。
【０４６２】
無線ＬＡＮアクセスポイントを使用して、ＰＣとＡＩＢＯを接続する場合には、ＥＳＳＩＤとＷＥＰＫＥＹは、アクセスポイントと同じ設定にする。ＡＩＢＯをＩｎｆｒａｓｔｒｕｃｔｕｒｅ　Ｍｏｄｅで動作させるため、ＡＰＭＯＤＥ＝１に指定します。
【０４６３】
＜ＥＲＳ−２１０＞
また、ＯＰＥＮ−Ｒ　ＳＤＫを用いてインタラクションが可能となる上記にＡＩＢＯ（登録商標）として説明したロボット装置の具体的仕様例を以下に示す。
第１章　ＥＲＳ−２１０外部仕様
１．１　ＥＲＳ−２１０外形
外観図及び外形寸法
本発明を適用するロボット装置の機種仕様例について図面を用いて説明する。
【０４６４】
このロボット装置は、頭部と上肢と体幹部と下肢とを備え、上肢及び下肢、又は下肢のみを移動手段とする脚式移動ロボットである。脚式移動ロボットには、４足歩行の動物の身体メカニズムやその動きを模倣したペット型ロボットや、下肢のみを移動手段として使用する２足歩行の動物の身体メカニズムやその動きを模倣したロボット装置があるが、本実施の形態として示すロボット装置は、４足歩行タイプの脚式移動ロボットである。なお、本明細書では説明していないが、当然のことながら本発明を２足歩行タイプの脚式移動ロボットに適用することもできる。
【０４６５】
図２６には、このロボット装置（以下、ＥＲＳ−２１０と記す。）の上面からの眺望、正面空の眺望及び側面からの眺望が示されている。以下、ＥＲＳ−２１０について図面を参照して説明する。ＥＲＳ−２１０は、図２６に示すように「動物」を模した形状のいわゆるペット型ロボットである。ＥＲＳ−２１０は、胴体部ユニットの前後左右に各脚部ユニットが連結され、胴体部ユニットの前端部に頭部ユニットが連結されて構成されている。また、胴体部ユニットの後端部には、尻尾部が設けられている。ＥＲＳ−２１０の外形寸法は、図２７及び図２８において説明している
このロボット装置は、住環境その他の日常生活上の様々な場面における人的活動を支援する実用ロボットであり、内部状態（怒り、悲しみ、喜び、楽しみ等）に応じて行動できるほか、４足歩行の動物が行う基本的な動作を表出できるエンターテインメントロボットである。このロボット装置は、特に、頭部、胴体部、上肢部、下肢部等を有している。各部の連結部分及び関節に相当する部位には、運動の自由度に応じた数のアクチュエータ及びポテンショメータが備えられており、制御部の制御によって目標とする動作を表出できる。
【０４６６】
さらに、このＥＲＳ−２１０は、周囲の状況を画像データとして取得するための撮像部や、外部から受ける作用を検出するための各種センサや、外部から受ける物理的な働きかけ等を検出するための各種スイッチ等を備えている。撮像部には、小型のＣＣＤ（Ｃｈａｒｇｅ−Ｃｏｕｐｌｅｄ　Ｄｅｖｉｃｅ）カメラを使用する。センサには、角速度を検出する角速度センサ、ＣＣＤカメラによって撮像された対象物までの距離を計測する距離センサ等がある。各種スイッチには、主としてユーザによる接触を検出する押下式スイッチ、ユーザからの操作入力が可能な操作スイッチ等がある。これら各種センサ及び各種スイッチは、ロボット装置外部又は内部の適切な箇所に設置されている。
【０４６７】
１．２　可動範囲
続いて、ＥＲＳ−２１０の可動部分に関して説明する。
１．２．１　頭部
図２９には、頭部における可動部分とその可動範囲が示されている。頭部では、首、耳、顎が可動である。各部の自由度は、首がパン、チルト、ロールの３自由度、各耳がそれぞれ１自由度、顎が１自由度となっており、頭部全体で合計６自由度を有している。
【０４６８】
１．２．２　脚部
図３０には、脚部における可動部分とその可動範囲が示されている。脚部は、腰、肩、膝が可動であって、各部の自由度は、前脚がそれぞれ３自由度（腰：１自由度、肩：１自由度、膝：１自由度）、後脚がそれぞれ３自由度（腰：１自由度、肩：１自由度、膝：１自由度）となっており、脚部全体で合計１２自由度を有している。
【０４６９】
１．２．３　尾部
図３１には、尾部におけるの可動範囲が示されている。尾部は、尻尾が可動であって、２自由度を有している。なお、初期位置は、１５度になるように制御されている。
【０４７０】
１．３　デバイス配置図
１．３．１　出力デバイス
ＥＲＳ−２１０の出力デバイスに関して説明する。図３２には、ＥＲＳ−２１０に設けられた出力デバイスの概略位置が示されている。ＥＲＳ−２１０の頭部には、モード及び状態を知らせるモードランプ、目ランプＬＥＤ（赤色４個、緑色２個）が設けられている。頭部正面位置にはスピーカ、胸部正面位置には胸ランプ（緑色、オレンジ色）が設けられている。さらに、尻尾には、尻尾ＬＥＤ（青色、オレンジ色）が設けられている。また、この他にも本体内部に、時刻表示用のＬＥＤ、メモリスティックアクセス確認ランプ、起動音及びシャットダウン音のための圧電ブザー等が設けられている。
【０４７１】
１．３．２　入力デバイス
ＥＲＳ−２１０の入力デバイスに関して説明する。図３３には、ＥＲＳ−２１０に設けられた入力デバイスの概略位置が示されている。ＥＲＳ−２１０の頭部には、頭部センサ、距離センサ、及び顎センサ、左右の耳位置にステレオマイクが設けられている。また、頭部正面位置には、カラーＣＣＤカメラ、胸部正面位置には、動作停止用のポーズボタンが設けられている。胴体部の背面には、背中センサ、脚部の足裏に肉球センサが設けられている。また、本体内部に、加速度センサ、振動センサ、温度センサ、時計（設定スイッチ）、ＰＣカード挿入口、メモリスティック挿入口が設けられている。
【０４７２】
１．４　各部の構成
１．４．１　ＥＲＳ−２１０全体
ＥＲＳ−２１０全体構成について説明する。図３４には、ＥＲＳ−２１０全体の組み付けの様子が示されている。ＥＲＳ−２１０は、ＯＰＥＮ−Ｒバス接続端子を備えた本体コアユニットに、頭部ユニット、左右前脚ユニット、左右後脚ユニット、尾部ユニットが組み付けられている。
【０４７３】
１．４．２　ＥＲＳ−２１０頭部
ＥＲＳ−２１０頭部ユニットについて説明する。図３５には、外部保護筐体を取り外したＥＲＳ−２１０頭部が示されている。ＥＲＳ−２１０の頭部には、頭部センサ、左右耳部、ＬＥＤ基板、カラーカメラ、首ロールのためのモータ、顎開閉のためのモータ、首パンのためのモータ、首チルトのためのモータ、動作停止のためのポーズボタンが設けられている。
【０４７４】
１．４．３　ＥＲＳ−２１０脚部
ＥＲＳ−２１０脚部ユニットについて説明する。図３６には、外部保護筐体を取り外したＥＲＳ−２１０脚部が示されている。ＥＲＳ−２１０の脚部には、腰（Ｊ１）、肩（Ｊ２）、膝（Ｊ３）の各関節毎に駆動用モータ及びポテンショメータが設けられている。また、足裏部には肉球センサが取り付けられている。なお、ＯＰＥＮ−Ｒバス接続端子は、脚部ユニットに設けられていてもよい。
【０４７５】
第２章　ＥＲＳ−２１０関節
２．１　ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒリスト
続いて、プログラムのコードを記述する際に使用する各部の名称を列挙する。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示す部位を示す。
頭部
ＰＲＭ：／ｒ１／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・首チルト
ＰＲＭ：／ｒ１／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・首パン
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・首ロール
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｃ４−Ｊｏｉｎｔ２：ｊ４・・・口
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ１−Ｓｅｎｓｏｒ：ｆ１・・・頭センサ（後）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ２−Ｓｅｎｓｏｒ：ｆ２・・・頭センサ（前）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｃ４／ｓ５−Ｓｅｎｓｏｒ：ｓ５・・・あごセンサ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｐ１−Ｓｅｎｓｏｒ：ｐ１・・・距離センサ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｍ１−Ｍｉｃ：Ｍ１・・・ステレオマイク
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｓ１−Ｓｐｅａｋｅｒ：Ｓ１・・・スピーカ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｉ１−ＦｂｋＩｍａｇｅＳｅｎｓｏｒ：Ｆ１・・・カラーカメラ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｅ１−Ｊｏｉｎｔ３：ｊ５・・・左耳
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｅ２−Ｊｏｉｎｔ３：ｊ６・・・右耳
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ１−ＬＥＤ２：ｌ１・・・目ランプ（左下）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ２−ＬＥＤ２：ｌ２・・・目ランプ（左中）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ３−ＬＥＤ２：ｌ３・・・目ランプ（左上）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ４−ＬＥＤ２：ｌ４・・・目ランプ（右下）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ５−ＬＥＤ２：ｌ５・・・目ランプ（右中）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ６−ＬＥＤ２：ｌ６・・・目ランプ（右上）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ７−ＬＥＤ２：ｌ７・・・モードランプ
【０４７６】
左前脚
ＰＲＭ：／ｒ２／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・腰関節
ＰＲＭ：／ｒ２／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・肩関節
ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・膝関節
ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・肉球センサ
左後脚
ＰＲＭ：／ｒ３／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・腰関節
ＰＲＭ：／ｒ３／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・肩関節
ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・膝関節
ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・肉球センサ
右前脚
ＰＲＭ：／ｒ４／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・腰関節
ＰＲＭ：／ｒ４／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・肩関節
ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・膝関節
ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・肉球センサ
右後脚
ＰＲＭ：／ｒ５／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・腰関節
ＰＲＭ：／ｒ５／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・肩関節
ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・膝関節
ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・肉球センサ
【０４７７】
尻尾
ＰＲＭ：／ｒ６／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・尻尾パン
ＰＲＭ：／ｒ６／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・尻尾チルト
ＲＰＭ：／ｒ６／ｌ１−ＬＥＤ２：ｌ１・・・尻尾ランプ（青）
ＲＰＭ：／ｒ６／ｌ２−ＬＥＤ２：ｌ２・・・尻尾ランプ（オレンジ）
ＰＲＭ：／ｒ６／ｔ１−Ｓｅｎｓｏｒ：ｔ１・・・温度センサ
ＰＲＭ：／ｒ６／ｓ１−Ｓｅｎｓｏｒ：ｓ１・・・背中センサ
【０４７８】
加速度センサ
ＰＲＭ：／ａ１−Ｓｅｎｓｏｒ：ａ１・・・ｙ軸（前後方向　前方向が正）
ＰＲＭ：／ａ２−Ｓｅｎｓｏｒ：ａ２・・・ｘ軸（左右方向　右方向が正）
ＰＲＭ：／ａ３−Ｓｅｎｓｏｒ：ａ３・・・ｚ軸（上下方向　上方向が正）
【０４７９】
続いて、ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａのインデックス番号とＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒとの対応を示す。以下では、インデックス番号に続いて、これに対応するＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示されている。
０　　　ＰＲＭ：／ｒ１／ｃ１−Ｊｏｉｎｔ２：ｊ１
１　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
２　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
３　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ１−Ｓｅｎｓｏｒ：ｆ１
４　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ２−Ｓｅｎｓｏｒ：ｆ２
５　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｐ１−Ｓｅｎｓｏｒ：ｐ１
６　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｃ４−Ｊｏｉｎｔ２：ｊ４
７　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｃ４／ｓ５−Ｓｅｎｓｏｒ：ｓ５
８　　　ＰＲＭ：／ｒ２／ｃ１−Ｊｏｉｎｔ２：ｊ１
９　　　ＰＲＭ：／ｒ２／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
１０　　　ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
１１　　　ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４
１２　　　ＰＲＭ：／ｒ３／ｃ１−Ｊｏｉｎｔ２：ｊ１
１３　　　ＰＲＭ：／ｒ３／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
１４　　　ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
１５　　　ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４
１６　　　ＰＲＭ：／ｒ４／ｃ１−Ｊｏｉｎｔ２：ｊ１
１７　　　ＰＲＭ：／ｒ４／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
１８　　　ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
１９　　　ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４
２０　　　ＰＲＭ：／ｒ５／ｃ１−Ｊｏｉｎｔ２：ｊ１
２１　　　ＰＲＭ：／ｒ５／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
２２　　　ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
２３　　　ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４
２４　　　ＰＲＭ：／ｒ６／ｃ１−Ｊｏｉｎｔ２：ｊ１
２５　　　ＰＲＭ：／ｒ６／ｃ２−Ｊｏｉｎｔ２：ｊ２
２６　　　ＰＲＭ：／ｒ６／ｔ１−Ｓｅｎｓｏｒ：ｔ１
２７　　　ＰＲＭ：／ｒ６／ｓ１−Ｓｅｎｓｏｒ：ｓ１
２８　　　ＰＲＭ：／ａ１−Ｓｅｎｓｏｒ：ａ１
２９　　　ＰＲＭ：／ａ２−Ｓｅｎｓｏｒ：ａ２
３０　　　ＰＲＭ：／ａ３−Ｓｅｎｓｏｒ：ａ３
【０４８０】
２．２　関節動作の制限値
２．２．１　単関節リミット
各関節のソフトリミットについて説明する。脚部Ｊ１のソフトリミットは、−１１７°〜１１７°であり、Ｊ２のソフトリミットは、−１１°〜８９°であり、Ｊ３のソフトリミットは、−２７°〜１４７°である。ただし、脚部Ｊ１のメカリミットは、−１２０°〜１２０°であり、脚部Ｊ２のメカリミットは、−１４°〜９２°であり、脚部Ｊ３のメカリミットは、−２７°〜１４７°である。
【０４８１】
頭部のソフトリミットは、首チルトが−８２°〜４３°であり、首パンが−８９．６°〜８９．６°であり、首ロールが−２９°〜２９°であり、口（顎）開閉が−４７°〜−３°である。但し、メカリミットは、首チルトが−８５°〜４６°であり、首パンが−９２．６°〜９２．６°であり、首ロールが−３２°〜３２°であり、口（顎）開閉が−５０°〜０°である。
【０４８２】
また、尻尾部のソフトリミットは、パンが−２２°〜２２°であり、チルトが−２２°〜２２°である。但し、メカリミットは、パンが−２５°〜２５°であり、チルトが−２５°〜２５°となっている。
【０４８３】
２．２．２　脚の２関節ソフトリミット
Ｊ１の角度が変化したときのＪ２前脚の角度リミットとＪ２後脚の角度リミットの最小値を図３７に示す。図において、単位は、度（°）である。
【０４８４】
２．２．３　頭部の４関節ソフトリミット
以下に頭部の各関節のリミットの関係を説明する。ロールと口（顎）の可動範囲は、図３８のチルト軸とパン軸のエリア内に定義された範囲内にする。首パンは、右側の場合、対称になる。但し、以下の記載では、単位は、度（°）とする。
Ａ領域であれば、−２５≦ｒｏｌｌ≦０　ａｎｄ　ｍｏｕｔｈ＝−３
Ｂ領域であれば、ｒｏｌｌ＝０　ａｎｄ　ｍｏｕｔｈ＝−３
Ｃ領域であれば、−１５≦ｒｏｌｌ≦１０　ａｎｄ　ｍｏｕｔｈ＝−３
Ｄ領域であれば、−２９≦ｒｏｌｌ２０　ａｎｄ　−３０≦ｍｏｕｔｈ−３
Ｅ領域であれば、−２０≦ｒｏｌｌ≦２９　ａｎｄ　−２０≦ｍｏｕｔｈ≦−３
Ｆ領域であれば、−２０≦ｒｏｌｌ≦２０　ａｎｄ　−３０≦ｍｏｕｔｈ≦−３
Ｇ領域であれば、−２０≦ｒｏｌｌ≦２９　ａｎｄ　−３０≦ｍｏｕｔｈ≦−３
Ｈ領域であれば、−２０≦ｒｏｌｌ≦２９　ａｎｄ　−４７≦ｍｏｕｔｈ≦−３
Ｉ領域であれば、−２９≦ｒｏｌｌ≦２９　ａｎｄ　−４７≦ｍｏｕｔｈ≦−３
Ｋ領域であれば、−１５≦ｒｏｌｌ≦２９　ａｎｄ　−３０≦ｍｏｕｔｈ≦−３
Ｌ領域であれば、−１３≦ｒｏｌｌ≦２９　ａｎｄ　−３０≦ｍｏｕｔｈ≦−３
Ｍ領域であれば、−１５≦ｒｏｌｌ≦２０　ａｎｄ　−１０≦ｍｏｕｔｈ≦−３
Ｎ領域であれば、２≦ｒｏｌｌ≦２０　ａｎｄ　−１０≦ｍｏｕｔｈ≦−３
Ｏ領域であれば、−７≦ｒｏｌｌ≦２９　ａｎｄ　−３０≦ｍｏｕｔｈ≦−３
【０４８５】
２．３　サーボゲイン
図３９には、ＥＲＳ−２１０の関節のデフォルトのサーボゲインが示されている。ここでは、ＰＳＨＩＦＴ、ＩＳＨＩＦＴ、ＤＳＨＩＦＴは、固定値であるため値を変更することはできない。
【０４８６】
第３章　出力デバイス
３．１　ＬＥＤ
続いて、プログラムのコードを記述する際に使用する出力デバイスの名称を列挙する。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示す部位（ＬＥＤデバイス）を示す。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ１−ＬＥＤ２：ｌ１・・・目ランプ（左下）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ２−ＬＥＤ２：ｌ２・・・目ランプ（左中）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ３−ＬＥＤ２：ｌ３・・・目ランプ（左上）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ４−ＬＥＤ２：ｌ４・・・目ランプ（右下）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ５−ＬＥＤ２：ｌ５・・・目ランプ（右中）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ６−ＬＥＤ２：ｌ６・・・目ランプ（右上）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ７−ＬＥＤ２：ｌ７・・・モードランプ
ＲＰＭ：／ｒ６／ｌ１−ＬＥＤ２：ｌ１・・・尻尾ランプ（青）
ＲＰＭ：／ｒ６／ｌ２−ＬＥＤ２：ｌ２・・・尻尾ランプ（オレンジ）
３．２　スピーカ
ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒは、ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｓ１−Ｓｐｅａｋｅｒ：Ｓ１である。このスピーカのサンプリング周波数は、８０００Ｈｚであり、量子化ビット数は、８ｂｉｔリニアＰＣＭであり、チャンネルは、１チャンネル（モノラル）である。また、ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（）　に設定可能なパラメータを以下に示す。

設定可能なサウンドタイプは、ｏｓｐｋｓｎｄＭＯＮＯ８Ｋ８Ｂ　（デフォルト）である。
【０４８７】
３．３　ＬＣＤ
ＬＣＤは、現在時刻、バッテリ残量、音量を表示する。
【０４８８】
第４章　入力デバイス
４．１　外部
４．１．１　頭センサ
続いて、プログラムのコードを記述する際に使用する入力デバイスの名称を示す。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示す部位（センサ）を示す。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ１−Ｓｅｎｓｏｒ：ｆ１・・・頭センサ（後）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ２−Ｓｅｎｓｏｒ：ｆ２・・・頭センサ（前）

【０４８９】
４．１．２　カラーカメラ
カラーカメラのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒを以下に示す。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｉ１−ＦｂｋＩｍａｇｅＳｅｎｓｏｒ：Ｆ１
カラーカメラの仕様
ＣＭＯＳ部：１／６インチ、出力画素数３５２（Ｈ）×２８８（Ｖ）、２５ＦＰＳ
レンズ部：Ｆ２．０、ｆ＝２．１８ｍｍ
画角：水平５７．６°、垂直４７．８°
デフォルト
ホワイトバランス　４３００Ｋ（固定）
シャッタ速度　　　１／１００ｓｅｃ固定
ゲイン　　　　　　０ｄＢ固定
また、ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（）　に設定可能なパラメータを以下に示す。
ホワイトバランス

【０４９０】
４．１．３　距離センサ
距離センサのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒは、ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｐ１−Ｓｅｎｓｏｒ：ｐ１である。ｖａｌｕｅの範囲は、１０００００であれば１０ｃｍ、９０００００であれば９０ｃｍを表す。
【０４９１】
４．１．４　ポーズボタン
バッテリ制御マイコンに接続されています。電源が切れた状態のとき、ポーズボタンを押すとシステムを起動します。
【０４９２】
４．１．５　ステレオマイク
ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒは、以下のようになっている。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｍ１−Ｍｉｃ：Ｍ１・・・マイク
サンプリング周波数は、１６０００Ｈｚであり、量子化ビット数は、１６ｂｉｔリニアＰＣＭであり、チャンネルは、２チャンネル（ステレオ）である。また、ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（）　に設定可能なパラメータを以下に示す。
単一指向性（ＵＮＩ）　／無指向性（ＯＭＮＩ）の切り替え
ｏｐｒｍｒｅｑＭＩＣ＿ＵＮＩ
ｏｐｒｍｒｅｑＭＩＣ＿ＯＭＮＩ
ここで指向性方向は、マイクユニットの長手方向を前方向とする。
ＡＬＣ（Ａｕｔｏｍａｔｉｃ　Ｌｉｍｉｔ　Ｃｏｎｔｒｏｌ）のＯＮ／ＯＦＦ切り替え
ｏｐｒｍｒｅｑＭＩＣ＿ＡＬＣ＿ＯＮ
ｏｐｒｍｒｅｑＭＩＣ＿ＡＬＣ＿ＯＦＦ
【０４９３】
４．１．６　スイッチ
続いて、プログラムのコードを記述する際に使用するスイッチの名称を示す。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示すスイッチを示す。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｃ４／ｓ５−Ｓｅｎｓｏｒ：ｓ５・・・顎センサ
ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・肉球センサ（左前脚）
ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・肉球センサ（左後脚）
ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・肉球センサ（右前脚）
ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・肉球センサ（右後脚）
ＰＲＭ：／ｒ６／ｓ１−Ｓｅｎｓｏｒ：ｓ１・・・背中センサ
【０４９４】
４．２　内部
４．２．１　加速度センサ
プログラムのコードを記述する際に使用する加速度センサの名称を示す。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示す加速度センサを示す。
ＰＲＭ：／ａ１−Ｓｅｎｓｏｒ：ａ１・・・ｙ軸（前後方向、前方向が正）
ＰＲＭ：／ａ２−Ｓｅｎｓｏｒ：ａ２・・・ｘ軸（左右方向、右方向が正）
ＰＲＭ：／ａ３−Ｓｅｎｓｏｒ：ａ３・・・ｚ軸（上下方向、上方向が正）
ｖａｌｕｅの範囲は、以下の通りである。
−１９６１３３００　　　−１９．６１３３　ｍ／ｓ^２　　　−２．０Ｇ
＋１９６１３３００　　　＋１９．６１３３　ｍ／ｓ^２　　　＋２．０Ｇ
【０４９５】
４．２．２　振動センサ
バッテリ制御マイコンに接続されています。ブートコンディションにｏｂｃｂＶＩＢＲＡＴＩＯＮ＿ＤＥＴＥＣＴＥＤが設定されている場合は、バッテリ制御マイコンが振動を検出するとシステムを起動します。
【０４９６】
＜ＥＲＳ−２２０＞
続いて、ロボット装置（ＡＩＢＯ（登録商標））の別の仕様に関して説明する。
第１章　ＥＲＳ−２２０外部仕様
１．１　ＥＲＳ−２２０外形
１．１．１．　外観図
図４０には、このロボット装置（以下、ＥＲＳ−２２０と記す。）の上面からの眺望、正面空の眺望及び側面からの眺望が示されている。以下、ＥＲＳ−２２０について図面を参照して説明する。ＥＲＳ−２２０は、ＥＲＳ−２１０同様、図４０に示すように「動物」を模した形状のいわゆるペット型ロボットである。ＥＲＳ−２２０は、胴体部ユニットの前後左右に各脚部ユニットが連結され、胴体部ユニットの前端部に頭部ユニットが連結されて構成されている。また、胴体部ユニットの後端部には、尻尾部が設けられている。ＥＲＳ−２２０の外形寸法は、図４１及び図４２において説明している
【０４９７】
１．２　可動範囲
続いて、ＥＲＳ−２２０の可動部分に関して説明する。
【０４９８】
１．２．１　頭部
図４３には、頭部における可動部分とその可動範囲が示されている。頭部では、首、角、顎が可動である。各部の自由度は、首がパン、チルト、ロールの３自由度、角が１自由度、顎が１自由度となっており、頭部全体で合計４自由度を有している。
【０４９９】
１．２．２　脚部
図４４には、脚部における可動部分とその可動範囲が示されている。脚部は、腰、肩、膝が可動であって、各部の自由度は、前脚がそれぞれ３自由度（腰：１自由度、肩：１自由度、膝：１自由度）、後脚がそれぞれ３自由度（腰：１自由度、肩：１自由度、膝：１自由度）となっており、脚部全体で合計１２自由度を有している。
【０５００】
１．３　デバイス配置図
１．３．１　出力デバイス
ＥＲＳ−２２０の出力デバイスに関して説明する。図４５には、ＥＲＳ−２２０に設けられた出力デバイスの概略位置が示されている。ＥＲＳ−２２０の頭部には、モード及び状態を知らせるモードランプ、フェイスサイドランプ、フェイスフロントランプ、リトラクタブルヘッドライトが設けられている。頭部正面位置にはスピーカ、胸部正面位置には動作ランプが設けられている。さらに、背部に背中マルチランプ、尾部にテールランプが設けられている。また、この他にも本体内部に、時刻表示用のＬＥＤ、メモリスティックアクセス確認ランプ、起動音及びシャットダウン音のための圧電ブザー等が設けられている。
【０５０１】
１．３．２　入力デバイス
ＥＲＳ−２２０の入力デバイスに関して説明する。図４６には、ＥＲＳ−２２０に設けられた入力デバイスの概略位置が示されている。ＥＲＳ−２２０の頭部には、フェイスタッチセンサ、距離センサ、ヘッドタッチセンサ、左右の耳位置にステレオマイクが設けられている。また、頭部正面位置には、カラーカメラ、胸部正面位置には、動作停止用のポーズボタンが設けられている。胴体部の背面には、背中タッチセンサ及びテールタッチセンサ、脚部の足裏にフットタッチセンサが設けられている。また、本体内部に、加速度センサ、振動センサ、温度センサ、時計（設定スイッチ）、ＰＣカード挿入口、メモリスティック挿入口が設けられている。
【０５０２】
１．４　各部の構成
１．４．１　ＥＲＳ−２２０全体
ＥＲＳ−２２０全体構成について説明する。図４７には、ＥＲＳ−２２０全体の組み付けの様子が示されている。ＥＲＳ−２２０は、ＯＰＥＮ−Ｒバス接続端子を備えた本体コアユニットに、頭部ユニット、左右前脚ユニット、左右後脚ユニット、尾部ユニットが組み付けられている。
【０５０３】
１．４．２　ＥＲＳ−２２０頭部
ＥＲＳ−２２０頭部ユニットについて説明する。図４８には、外部保護筐体を取り外したＥＲＳ−２２０頭部が示されている。ＥＲＳ−２２０の頭部には、リトラクタブルヘッドライト、距離センサ、ヘッドタッチセンサ、左右耳部のステレオマイク、ＬＥＤ等のプリント基板、カラーカメラ、首ロールのためのモータ、首パンのためのモータ、首チルトのためのモータ、動作停止のためのポーズボタンが設けられている。
【０５０４】
１．４．３　ＥＲＳ−２２０脚部
ＥＲＳ−２２０脚部ユニットについて説明する。図４９には、外部保護筐体を取り外したＥＲＳ−２２０脚部が示されている。ＥＲＳ−２２０の脚部には、腰（Ｊ１）、肩（Ｊ２）、膝（Ｊ３）の各関節毎に駆動用モータ及びポテンショメータが設けられている。また、足裏部には肉球センサが取り付けられている。なお、ＯＰＥＮ−Ｒバス接続端子は、脚部ユニットに設けられていてもよい。
【０５０５】
第２章　ＥＲＳ−２２０関節
２．１　ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒリスト
続いて、プログラムのコードを記述する際に使用する各部の名称を列挙する。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示す部位を示す。
ＰＲＭ：／ｒ１／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・首チルト
ＰＲＭ：／ｒ１／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・首パン
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・首ロール
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ１−ＬＥＤ２：ｌ１・・・頭フェイスサイドランプ（左前）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ２−ＬＥＤ２：ｌ２・・・頭フェイスサイドランプ（左中央）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ３−ＬＥＤ２：ｌ３・・・頭フェイスサイドランプ（左後）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ４−ＬＥＤ２：ｌ４・・・頭フェイスサイドランプ（右前）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ５−ＬＥＤ２：ｌ５・・・頭フェイスサイドランプ（右中央）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ６−ＬＥＤ２：ｌ６・・・頭フェイスサイドランプ（右後）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ７−ＬＥＤ２：ｌ７・・・頭モードランプ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ８−ＬＥＤ２：ｌ８・・・フェイスフロントランプＢ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ９−ＬＥＤ２：ｌ９・・・フェイスフロントランプＡ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌａ−ＬＥＤ２：ｌａ・・・フェイスフロントランプＣ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌｂ−ＬＥＤ２：ｌｂ・・・リトラクタブルヘッドライト
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ１−Ｓｅｎｓｏｒ：ｆ１・・・ヘッドタッチセンサ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ２−Ｓｅｎｓｏｒ：ｆ２・・・ヘッドタッチセンサ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｃ４／ｓ５−Ｓｅｎｓｏｒ：ｓ５・・・フェイスタッチセンサ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｐ１−Ｓｅｎｓｏｒ：ｐ１・・・距離センサ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｍ１−Ｍｉｃ：Ｍ１・・・ステレオマイク
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｓ１−Ｓｐｅａｋｅｒ：Ｓ１・・・スピーカ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｉ１−ＦｂｋＩｍａｇｅＳｅｎｓｏｒ：Ｆ１・・・カラーカメラ
【０５０６】
左前脚
ＰＲＭ：／ｒ２／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・腰関節
ＰＲＭ：／ｒ２／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・肩関節
ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・膝関節
ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・フットタッチセンサ
左後脚
ＰＲＭ：／ｒ３／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・腰関節
ＰＲＭ：／ｒ３／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・肩関節
ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・膝関節
ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・フットタッチセンサ
右前脚
ＰＲＭ：／ｒ４／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・腰関節
ＰＲＭ：／ｒ４／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・肩関節
ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・膝関節
ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・フットタッチセンサ
右後脚
ＰＲＭ：／ｒ５／ｃ１−Ｊｏｉｎｔ２：ｊ１・・・腰関節
ＰＲＭ：／ｒ５／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２・・・肩関節
ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３・・・膝関節
ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・フットタッチセンサ
【０５０７】
尻尾
ＰＲＭ：／ｒ６／ｓ１−Ｓｅｎｓｏｒ：ｓ１・・・背中タッチスイッチ
ＰＲＭ：／ｒ６／ｔ１−Ｓｅｎｓｏｒ：ｔ１・・・温度センサ
ＰＲＭ：／ｒ６／ｓ２−Ｓｅｎｓｏｒ：ｓ２・・・テールタッチセンサ　（左）
ＰＲＭ：／ｒ６／ｓ３−Ｓｅｎｓｏｒ：ｓ３・・・テールタッチセンサ　（中央）
ＰＲＭ：／ｒ６／ｓ４−Ｓｅｎｓｏｒ：ｓ４・・・テールタッチセンサ　（右）
ＰＲＭ：／ｒ６／ｌ１−ＬＥＤ２：ｌ１・・・背中タッチセンサ（左から１番目）
ＰＲＭ：／ｒ６／ｌ２−ＬＥＤ２：ｌ２・・・背中タッチセンサ（左から２番目）
ＰＲＭ：／ｒ６／ｌ３−ＬＥＤ２：ｌ３・・・背中タッチセンサ（左から３番目）
ＰＲＭ：／ｒ６／ｌ４−ＬＥＤ２：ｌ４・・・背中タッチセンサ（右から３番目）
ＰＲＭ：／ｒ６／ｌ５−ＬＥＤ２：ｌ５・・・背中タッチセンサ（右から２番目）
ＰＲＭ：／ｒ６／ｌ６−ＬＥＤ２：ｌ６・・・背中タッチセンサ（右から１番目）
ＰＲＭ：／ｒ６／ｌ７−ＬＥＤ２：ｌ７・・・テールタッチセンサ（中央）
ＰＲＭ：／ｒ６／ｌ８−ＬＥＤ２：ｌ８・・・テールタッチセンサ（右）
ＰＲＭ：／ｒ６／ｌ９−ＬＥＤ２：ｌ９・・・テールタッチセンサ（左）
【０５０８】
加速度センサ
ＰＲＭ：／ａ１−Ｓｅｎｓｏｒ：ａ１・・・ｙ軸（前後方向、前方向が正）
ＰＲＭ：／ａ２−Ｓｅｎｓｏｒ：ａ２・・・ｘ軸（左右方向、右方向が正）
ＰＲＭ：／ａ３−Ｓｅｎｓｏｒ：ａ３・・・ｚ軸（上下方向、上方向が正）
【０５０９】
続いて、ＯＳｅｎｓｏｒＦｒａｍｅＶｅｃｔｏｒＤａｔａのインデックス番号とＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒとの対応を示す。以下では、インデックス番号に続いて、これに対応するＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示されている。
０　　　ＰＲＭ：／ｒ１／ｃ１−Ｊｏｉｎｔ２：ｊ１
１　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
２　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
３　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｐ１−Ｓｅｎｓｏｒ：ｐ１
４　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ１−Ｓｅｎｓｏｒ：ｆ１
５　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ２−Ｓｅｎｓｏｒ：ｆ２
６　　　ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｃ４／ｓ５−Ｓｅｎｓｏｒ：ｓ５
７　　　ＰＲＭ：／ｒ２／ｃ１−Ｊｏｉｎｔ２：ｊ１
８　　　ＰＲＭ：／ｒ２／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
９　　　ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
１０　　　ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４
１１　　　ＰＲＭ：／ｒ３／ｃ１−Ｊｏｉｎｔ２：ｊ１
１２　　　ＰＲＭ：／ｒ３／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
１３　　　ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
１４　　　ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４
１５　　　ＰＲＭ：／ｒ４／ｃ１−Ｊｏｉｎｔ２：ｊ１
１６　　　ＰＲＭ：／ｒ４／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
１７　　　ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
１８　　　ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４
１９　　　ＰＲＭ：／ｒ５／ｃ１−Ｊｏｉｎｔ２：ｊ１
２０　　　ＰＲＭ：／ｒ５／ｃ１／ｃ２−Ｊｏｉｎｔ２：ｊ２
２１　　　ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３−Ｊｏｉｎｔ２：ｊ３
２２　　　ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４
２３　　　ＰＲＭ：／ｒ６／ｔ１−Ｓｅｎｓｏｒ：ｔ１
２４　　　ＰＲＭ：／ｒ６／ｓ１−Ｓｅｎｓｏｒ：ｓ１
２５　　　ＰＲＭ：／ｒ６／ｓ２−Ｓｅｎｓｏｒ：ｓ２
２６　　　ＰＲＭ：／ｒ６／ｓ３−Ｓｅｎｓｏｒ：ｓ３
２７　　　ＰＲＭ：／ｒ６／ｓ４−Ｓｅｎｓｏｒ：ｓ４
２８　　　ＰＲＭ：／ａ１−Ｓｅｎｓｏｒ：ａ１
２９　　　ＰＲＭ：／ａ２−Ｓｅｎｓｏｒ：ａ２
３０　　　ＰＲＭ：／ａ３−Ｓｅｎｓｏｒ：ａ３
【０５１０】
２．２　関節動作の制限値
２．２．１　単関節リミット
各関節のソフトリミットについて説明する。脚部Ｊ１のソフトリミットは、−１１７°〜１１７°であり、Ｊ２のソフトリミットは、−１１°〜８９°であり、Ｊ３のソフトリミットは、−２７°〜１４７°である。ただし、脚部Ｊ１のメカリミットは、−１２０°〜１２０°であり、脚部Ｊ２のメカリミットは、−１４°〜９２°であり、脚部Ｊ３のメカリミットは、−２７°〜１４７°である。
【０５１１】
頭部のソフトリミットは、首チルトが−８２°〜４３°であり、首パンが−８９．６°〜８９．６°であり、首ロールが−２９°〜２９°である。但し、メカリミットは、首チルトが−８５°〜４６°であり、首パンが−９２．６°〜９２．６°であり、首ロールが−３２°〜３２°である。
【０５１２】
６．２．２　脚の２関節ソフトリミット
Ｊ１の角度が変化したときのＪ２前脚の角度リミットとＪ２後脚の角度リミットの最小値を図５０に示す。図において、単位は、度（°）である。
【０５１３】
６．２．３　頭部の４関節ソフトリミット
以下に頭部の各関節のリミットの関係を説明する。ロールの可動範囲は、図５１のチルト軸とパン軸のエリア内に定義された範囲内にする。首パンは、右側の場合、対称になる。但し、以下の記載では、単位は、度（°）とする。
Ａ領域であれば、−２５≦ｒｏｌｌ≦０
Ｂ領域であれば、ｒｏｌｌ＝０
Ｃ領域であれば、−１５≦ｒｏｌｌ≦１０
Ｄ領域であれば、−２９≦ｒｏｌｌ２０
Ｅ領域であれば、−２０≦ｒｏｌｌ≦２９
Ｆ領域であれば、−２０≦ｒｏｌｌ≦２０
Ｇ領域であれば、−２０≦ｒｏｌｌ≦２９
Ｈ領域であれば、−２０≦ｒｏｌｌ≦２９
Ｉ領域であれば、−２９≦ｒｏｌｌ≦２９
Ｋ領域であれば、−１５≦ｒｏｌｌ≦２９
Ｌ領域であれば、−１３≦ｒｏｌｌ≦２９
Ｍ領域であれば、−１５≦ｒｏｌｌ≦２０
Ｎ領域であれば、２≦ｒｏｌｌ≦２０
Ｏ領域であれば、−７≦ｒｏｌｌ≦２９
【０５１４】
２．３　サーボゲイン
図５２には、ＥＲＳ−２２０の関節のデフォルトのサーボゲインが示されている。ここでは、ＰＳＨＩＦＴ、ＩＳＨＩＦＴ、ＤＳＨＩＦＴは、固定値であるため値を変更することはできない。
【０５１５】
第３章　出力デバイス
３．１　ＬＥＤ
続いて、プログラムのコードを記述する際に使用する出力デバイスの名称を列挙する。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示す部位（ＬＥＤデバイス）を示す。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ１−ＬＥＤ２：ｌ１・・・フェイスサイドランプ（前左）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ２−ＬＥＤ２：ｌ２・・・フェイスサイドランプ（中央左）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ３−ＬＥＤ２：ｌ３・・・フェイスサイドランプ（後左）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ４−ＬＥＤ２：ｌ４・・・フェイスサイドランプ（前右）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ５−ＬＥＤ２：ｌ５・・・フェイスサイドランプ（中央右）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ６−ＬＥＤ２：ｌ６・・・フェイスサイドランプ（後右）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ７−ＬＥＤ２：ｌ７・・・モードランプ
ＰＲＭ：／ｒ６／ｌ１−ＬＥＤ２：ｌ１・・・背中タッチセンサ（左から１番目）
ＰＲＭ：／ｒ６／ｌ２−ＬＥＤ２：ｌ２・・・背中タッチセンサ（左から２番目）
ＰＲＭ：／ｒ６／ｌ３−ＬＥＤ２：ｌ３・・・背中タッチセンサ（左から３番目）
ＰＲＭ：／ｒ６／ｌ４−ＬＥＤ２：ｌ４・・・背中タッチセンサ（右から３番目）
ＰＲＭ：／ｒ６／ｌ５−ＬＥＤ２：ｌ５・・・背中タッチセンサ（右から２番目）
ＰＲＭ：／ｒ６／ｌ６−ＬＥＤ２：ｌ６・・・背中タッチセンサ（右から１番目）
ＰＲＭ：／ｒ６／ｌ７−ＬＥＤ２：ｌ７・・・テールタッチセンサ（中央）
ＰＲＭ：／ｒ６／ｌ８−ＬＥＤ２：ｌ８・・・テールタッチセンサ（右）
ＰＲＭ：／ｒ６／ｌ９−ＬＥＤ２：ｌ９・・・テールタッチセンサ（左）
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ８−ＬＥＤ２：ｌ８・・・フェイスフロントランプＢ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌ９−ＬＥＤ２：ｌ９・・・フェイスフロントランプＡ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌａ−ＬＥＤ２：ｌａ・・・フェイスフロントランプＣ
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｌｂ−ＬＥＤ２：ｌｂ・・・リトラクタブルヘッドライト
【０５１６】
３．２　スピーカ
ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒは、ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｓ１−Ｓｐｅａｋｅｒ：Ｓ１である。このスピーカのサンプリング周波数は、８０００Ｈｚであり、量子化ビット数は、８ｂｉｔリニアＰＣＭであり、チャンネルは、１チャンネル（モノラル）である。また、ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（）　に設定可能なパラメータを以下に示す。

設定可能なサウンドタイプは、ｏｓｐｋｓｎｄＭＯＮＯ８Ｋ８Ｂ　（デフォルト）である。
【０５１７】
３．３　ＬＣＤ
ＬＣＤは、現在時刻、バッテリ残量、音量を表示する。
【０５１８】
第４章　入力デバイス
４．１　外部
４．１．１　頭センサ
続いて、プログラムのコードを記述する際に使用する入力デバイスの名称を示す。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示す部位（センサ）を示す。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ１−Ｓｅｎｓｏｒ：ｆ１・・・頭センサ１
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｆ２−Ｓｅｎｓｏｒ：ｆ２・・・頭センサ２
ｖａｌｕｅ　の出力は、図５３に示す。ヘッドタッチセンサを後ろに倒した場合は、倒した角度により、例えば、「通常→後１→後２→後３→後２→後１→通常」の順に値が変化する。
【０５１９】
４．１．２　カラーカメラ
カラーカメラのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒを以下に示す。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｉ１−ＦｂｋＩｍａｇｅＳｅｎｓｏｒ：Ｆ１
カラーカメラの仕様
ＣＭＯＳ部：１／６インチ、出力画素数３５２（Ｈ）×２８８（Ｖ）、２５ＦＰＳ
レンズ部：Ｆ２．０、ｆ＝２．１８ｍｍ
画角：水平５７．６°、垂直４７．８°
デフォルト
ホワイトバランス　４３００Ｋ（固定）
シャッタ速度　　　１／１００ｓｅｃ固定
ゲイン　　　　　　０ｄＢ固定
また、ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（）　に設定可能なパラメータを以下に示す。

【０５２０】
４．１．３　距離センサ
距離センサのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒは、ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｐ１−Ｓｅｎｓｏｒ：ｐ１である。
ｖａｌｕｅの範囲は、１０００００であれば１０ｃｍ、９０００００であれば９０ｃｍを表す。
【０５２１】
４．１．４　ポーズボタン
バッテリ制御マイコンに接続されています。電源が切れた状態のとき、ポーズボタンを押すとシステムを起動します。
【０５２２】
４．１．５　ステレオマイク
ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒは、以下のようになっている。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｍ１−Ｍｉｃ：Ｍ１・・・マイク
サンプリング周波数は、１６０００Ｈｚであり、量子化ビット数は、１６ｂｉｔリニアＰＣＭであり、チャンネルは、２チャンネル（ステレオ）である。また、ＯＰＥＮＲ：：ＣｏｎｔｒｏｌＰｒｉｍｉｔｉｖｅ（）　に設定可能なパラメータを以下に示す。
単一指向性（ＵＮＩ）　／無指向性（ＯＭＮＩ）の切り替え
ｏｐｒｍｒｅｑＭＩＣ＿ＵＮＩ
ｏｐｒｍｒｅｑＭＩＣ＿ＯＭＮＩ
ここで指向性方向は、マイクユニットの長手方向を前方向とする。
ＡＬＣ（Ａｕｔｏｍａｔｉｃ　Ｌｉｍｉｔ　Ｃｏｎｔｒｏｌ）のＯＮ／ＯＦＦ切り替え
ｏｐｒｍｒｅｑＭＩＣ＿ＡＬＣ＿ＯＮ
ｏｐｒｍｒｅｑＭＩＣ＿ＡＬＣ＿ＯＦＦ
【０５２３】
４．１．６　スイッチ
続いて、プログラムのコードを記述する際に使用するスイッチの名称を示す。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示すスイッチを示す。
ＰＲＭ：／ｒ１／ｃ１／ｃ２／ｃ３／ｃ４／ｓ５−Ｓｅｎｓｏｒ：ｓ５・・・フェイスタッチセンサ
ＰＲＭ：／ｒ２／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・フットタッチセンサ（左前脚）
ＰＲＭ：／ｒ３／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・フットタッチセンサ（左後脚）
ＰＲＭ：／ｒ４／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・フットタッチセンサ（右前脚）
ＰＲＭ：／ｒ５／ｃ１／ｃ２／ｃ３／ｃ４−Ｓｅｎｓｏｒ：ｓ４・・・フットタッチセンサ（右前脚）
ＰＲＭ：／ｒ６／ｓ１−Ｓｅｎｓｏｒ：ｓ１・・・背中タッチセンサ
ＰＲＭ：／ｒ６／ｓ２−Ｓｅｎｓｏｒ：ｓ２・・・テールタッチセンサ（左）
ＰＲＭ：／ｒ６／ｓ３−Ｓｅｎｓｏｒ：ｓ３・・・テールタッチセンサ（中央）
ＰＲＭ：／ｒ６／ｓ４−Ｓｅｎｓｏｒ：ｓ４・・・テールタッチセンサ（右）
【０５２４】
４．２　内部
４．２．１　加速度センサ
プログラムのコードを記述する際に使用する加速度センサの名称を示す。以下では、ＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒに続けてこのＣＰＣ　Ｐｒｉｍｉｔｉｖｅ　Ｌｏｃａｔｏｒが示す加速度センサを示す。
ＰＲＭ：／ａ１−Ｓｅｎｓｏｒ：ａ１・・・ｙ軸（前後方向、前方向が正）
ＰＲＭ：／ａ２−Ｓｅｎｓｏｒ：ａ２・・・ｘ軸（左右方向、右方向が正）
ＰＲＭ：／ａ３−Ｓｅｎｓｏｒ：ａ３・・・ｚ軸（上下方向、上方向が正）
ｖａｌｕｅの範囲は、以下の通りである。
−１９６１３３００　　　−１９．６１３３　ｍ／ｓ^２　　　−２．０Ｇ
＋１９６１３３００　　　＋１９．６１３３　ｍ／ｓ^２　　　＋２．０Ｇ
【０５２５】
４．２．２　振動センサ
バッテリ制御マイコンに接続されています。ブートコンディションにｏｂｃｂＶＩＢＲＡＴＩＯＮ＿ＤＥＴＥＣＴＥＤが設定されている場合は、バッテリ制御マイコンが振動を検出するとシステムを起動します。
【０５２６】
【発明の効果】
以上詳細に説明したように、本発明に係るロボット装置のインターフェイスは、ソフトウェアに基づいて外部情報や外部からの働きかけに応じた動作及び／又は内部状態に基づく自律的動作を実行するロボット装置のシステム層とアプリケーション層との間のインターフェイスであって、ソフトウェアがオブジェクト指向に基づいて部品化され、部品化されたソフトウェアの各部品としてのオブジェクトがそれぞれ並行動作することにより、エンターテインメントロボットのソフトウェア開発に必要なシステム層とアプリケーション層との間のインターフェイス仕様を規定することにより、エンターテインメント性や社会適合性を必要に応じて進化させるロボットのハードウェアやソフトウェアの開発が効率良く行なえる。
【図面の簡単な説明】
【図１】本発明の具体例として示すアプリケーションソフトウェアの概念図である。
【図２】本発明の具体例として示すアプリケーションソフトウェアにおけるオブジェクト間通信を説明する概念図である。
【図３】本発明の具体例として示すアプリケーションソフトウェアにおけるオブジェクトを表現するためのＣ＋＋のクラスを説明する概念図である。
【図４】本発明の具体例として示すアプリケーションソフトウェアにおけるオブジェクト間通信の例を説明する概念図である。
【図５】本発明の具体例として示すアプリケーションソフトウェアにおいて、オブジェクトをビルドし、実行ファイルを作成する手順を説明する図である。
【図６】本発明の具体例として示すアプリケーションソフトウェアのディレクトリ構成を説明する図である。
【図７】本具体例において関数ｅｎｔｒｙ＿ｐｏｉｎｔ０から順にｆｕｎｃ１，ｆｕｎｃ２が呼び出されｆｕｎｃ２のアドレス（ａ）を実行中のスタック状態を示す図である。
【図８】本具体例においてＣＰＵ例外の種類とオブジェクトの特定を説明する図である。
【図９】本具体例においてアセンブリ命令の特定を説明する図である。
【図１０】本発明の具体例として示すアプリケーションソフトウェアにおいて、ＥＭＯＮ．ＣＦＧで使用するコマンド（ｅｘｃｅｐｔｉｏｎ）の実行例を説明する図である。
【図１１】本発明の具体例として示すアプリケーションソフトウェアにおいて、ＥＭＯＮ．ＣＦＧで使用するコマンド（ｃｐ０）の実行例を説明する図である。
【図１２】本発明の具体例として示すアプリケーションソフトウェアにおいて、ＥＭＯＮ．ＣＦＧで使用するコマンド（ｃｐ１）の実行例を説明する図である。
【図１３】本発明の具体例として示すアプリケーションソフトウェアにおいて、ＥＭＯＮ．ＣＦＧで使用するコマンド（ｏｂｊｓ）の実行例を説明する図である。
【図１４】本発明の具体例として示すアプリケーションソフトウェアにおいて、ＥＭＯＮ．ＣＦＧで使用するコマンド（ｓｔａｃｋ、ｄｓｔａｃｋ）の実行例を説明する図である。
【図１５】本発明の具体例として示すアプリケーションソフトウェアにおいて、ＥＭＯＮ．ＣＦＧで使用するコマンド（ｔｌｂ）の実行例を説明する図である。
【図１６】本発明の具体例として示すアプリケーションソフトウェアにおいて、ＥＭＯＮ．ＣＦＧで使用するコマンド（ｄｕｍｐ）の実行例を説明する図である。
【図１７】本発明の具体例として示すアプリケーションソフトウェアのＩＰｖ４プロトコルスタックを説明する図である。
【図１８】本具体例において、オブジェクトとプロトコルスタックとの通信の様子を示す模式図である。
【図１９】本具体例において、共有メモリ領域をオブジェクトとプロトコルスタックのアドレス空間にマッピングする様子を説明する模式図である。
【図２０】本具体例におけるエンドポイントの状態遷移図である。
【図２１】本具体例におけるＵＤＰエンドポイントの状態遷移図である。
【図２２】本具体例におけるＤＮＳエンドポイントの状態遷移図である。
【図２３】本具体例においてインターネット上から取得されるホストエントリの例を示す図である。
【図２４】本具体例におけるＩＰエンドポイントの状態遷移図である。
【図２５】本具体例におけるＩＰヘッダの内容の一例を説明する図である。
【図２６】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の外観図である。
【図２７】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の外形寸法を示す図である。
【図２８】本具体例に適用されるロボット装置（ＥＲＳ−２１０）頭部の外形寸法を示す図である。
【図２９】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の頭部の可動範囲を説明する図である。
【図３０】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の脚部の可動範囲を説明する図である。
【図３１】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の尾部の可動範囲を説明する図である。
【図３２】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の出力デバイスの概略配置を説明する外観図である。
【図３３】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の入力デバイスの概略配置を説明する外観図である。
【図３４】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の全体構成の組み付けを説明する斜視図である。
【図３５】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の頭部構成を説明する斜視図である。
【図３６】本具体例に適用されるロボット装置（ＥＲＳ−２１０）の脚部構成を説明する斜視図である。
【図３７】本具体例に適用されるロボット装置（ＥＲＳ−２１０）において、Ｊ１の角度が変化したときのＪ２前脚の角度リミットとＪ２後脚の角度リミットの最小値とを示す図である。
【図３８】本具体例に適用されるロボット装置（ＥＲＳ−２１０）における頭部４関節の最適な対応関係を示す図である。
【図３９】本具体例に適用されるロボット装置（ＥＲＳ−２１０）における関節のデフォルトのサーボゲインを示す図である。
【図４０】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の外観図である。
【図４１】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の外形寸法を示す図である。
【図４２】本具体例に適用されるロボット装置（ＥＲＳ−２２０）頭部の外形寸法を示す図である。
【図４３】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の頭部の可動範囲を説明する図である。
【図４４】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の脚部の可動範囲を説明する図である。
【図４５】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の出力デバイスの概略配置を説明する外観図である。
【図４６】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の入力デバイスの概略配置を説明する外観図である。
【図４７】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の全体構成の組み付けを説明する斜視図である。
【図４８】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の頭部構成を説明する斜視図である。
【図４９】本具体例に適用されるロボット装置（ＥＲＳ−２２０）の脚部構成を説明する斜視図である。
【図５０】本具体例に適用されるロボット装置（ＥＲＳ−２２０）において、Ｊ１の角度が変化したときのＪ２前脚の角度リミットとＪ２後脚の角度リミットの最小値とを示す図である。
【図５１】本具体例に適用されるロボット装置（ＥＲＳ−２２０）における頭部４関節の最適な対応関係を示す図である。
【図５２】本具体例に適用されるロボット装置（ＥＲＳ−２２０）における関節のデフォルトのサーボゲインを示す図である。
【図５３】本具体例に適用されるロボット装置（ＥＲＳ−２２０）における頭部センサの出力値を説明する図である。
【符号の説明】
１　アプリケーションソフトウェア、１１，１２，１３　オブジェクト、ＥＲＳ−２１０　ロボット装置、ＥＲＳ−２２０　ロボット装置[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a robot device interface, and more particularly, to a robot device interface in which software is hierarchized and optimized.
[0002]
[Prior art]
Recently, practical robots have been developed which support life as a human partner, that is, support human activities in various situations in a living environment and other daily lives. Unlike an industrial robot, such a practical robot has the ability to learn a human being having different personalities individually or a method of adapting to various environments in various aspects of a human living environment. For example, a "pet-type" robot that simulates the body mechanism and movement of a four-legged animal such as a dog or cat, or a human that is modeled on the body mechanism or movement of an animal that walks upright on two legs Legged mobile robots such as a humanoid robot are already being put to practical use.
[0003]
These legged mobile robots can perform various operations that emphasize entertainment properties as compared with industrial robots, and are therefore sometimes referred to as entertainment robots.
[0004]
[Problems to be solved by the invention]
However, even if the entertainment robot as described above is designed by adding necessary functions, it can be used only for a predetermined application, and its application range is limited. Therefore, it is necessary to evolve entertainment properties and social compatibility as needed, and it is necessary to hierarchize and optimize these so that robot hardware and software can be efficiently developed.
[0005]
Therefore, the present invention has been proposed in view of such a conventional situation, and has as its object to specify interface specifications between a system layer and an application layer required for software development of an entertainment robot.
[0006]
[Means for Solving the Problems]
In order to achieve the above-described object, an interface of a robot device according to the present invention is provided with a robot device that executes an operation according to external information or an external action based on software and / or an autonomous operation based on an internal state. An interface between a system layer and an application layer, wherein software is made into components based on object orientation, and objects as components of the componentized software operate in parallel.
[0007]
Here, the objects are operated in parallel while communicating with each other.
[0008]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. OPEN-R described in this specification is a trademark or registered trademark of Sony Corporation. Further, Memory Stick, AIBO, and the like are trademarks of Sony Corporation. Note that 'TM' is not specified in the text. Other system names, product names, service names, and company names appearing in this document are generally trademarks or registered trademarks of the respective manufacturers. In this specification, regarding the OPEN-R SDK which is an interface of the entertainment robot system which is a specific example of the present invention, <Programmer's Guide>, <Reference Guide>, <Internet Protocol>, <Installation Guide>, <ERS-210> , <ERS-220>.
[0009]
<Programmer's Guide>
Chapter 1 Basic Knowledge
1.1 OPEN-R
OPEN-R is the interface of the entertainment robot system proposed by Sony to expand the world of entertainment robots. These interfaces are hierarchized and optimized to enable efficient development of robot hardware and software. The OPEN-R SDK discloses an interface specification between a system layer and an application layer necessary for software development of an entertainment robot. The OPEN-R software has the following features.
[0010]
-Software componentization and inter-object communication
OPEN-R software is made into parts (modules) based on object orientation. Each module is called an object (OPEN-R object). In OPEN-R, the software for operating the robot is realized in a form in which multiple objects having various functions are operated in parallel, and the objects perform processing while communicating with each other (communication between objects). The connection relationship between objects is described in a file managed by the system, and the system secures and sets a communication path at startup. Since the connection port for inter-object communication is identified by the service name, it is highly independent as a component and can be easily replaced.
[0011]
Software hierarchical structure and system layer providing service: The OPEN-R system layer provides services such as sound data input, sound data output, image data input, joint control output, and various sensor data inputs as an interface to the application layer. You. This interface is also realized by inter-object communication. By using these services, application layer objects can use the functions of the robot without having detailed knowledge of the hardware devices that make up the robot. The system layer also provides an interface for the TCP / IP protocol stack. This allows you to create a network communication application using a wireless LAN.
[0012]
1.2 Objects
FIG. 1 is a diagram showing a configuration of OPEN-R application software. The OPEN-R application software 1 includes a plurality of OPEN-R objects 2 to 4. In the following description, the “OPEN-R object” is simply described as “object”. The concept of an object is similar to the process of a Unix or Windows operating system in the following ways: One object corresponds to one executable file. Objects are concepts that exist only at runtime. Each object corresponds to an executable generated at compile time. The executable is created by compiling and linking the source code and placed on an AIBO programming memory stick. When the robot starts up, the system software loads the executable file and starts executing as an object. Each object works in parallel with other objects. Each object has one dedicated thread of execution and runs in parallel with other objects.
[0013]
The following are object-specific features that are different from processes. Objects exchange information by message communication. Objects can send messages to other objects. A message consists of data and a selector. The selector is an ID that identifies the process performed on the object on the receiving side of the message. When the object receives the message, the function corresponding to the selector is called, and the data in the message is passed as an argument. Functions corresponding to selectors are called methods. An important feature of objects is that they are single-threaded. This allows an object to process only one message at a given moment. If an object receives one message while processing one message, the message received later is kept in a queue and executed later.
[0014]
The following is the processing cycle of the object.
1. Loaded by the system.
2. Wait for a message to be received.
3. When a message is received, the method corresponding to the selector described in the message is executed. During execution, it may send messages to other objects.
4. After executing the method, the process returns to 2.
This cycle is an infinite loop. Once loaded, an object is persistent and never ends.
[0015]
Objects have multiple entry points. In a normal program environment, a program holds one entry point of main (), but an OPEN-R object can hold multiple entry points. Each entry point is associated with a selector as described above. Some of the entry points are used for system-defined purposes, such as initialization and termination. Other entry points are used for object-specific purposes. Objects also have a special entry point called Prologue (). This is done only once when the object is loaded by the system. Prologue () initializes and calls the C ++ global variable constructor.
[0016]
1.3 Inter-object communication
The software that operates the entertainment robot advances processing while multiple objects with various functions such as image recognition, voice recognition, behavior control, and motion generation communicate with each other. Communication between objects is called inter-object communication in OPEN-R.
[0017]
Communication between subjects and observers
By using inter-object communication, each object can be created and connected independently, enabling efficient development. In inter-object communication, the sender of data is called the subject, and the receiver of data is called the observer. Send NotifyEvent from the subject to the observer. NotifyEvent contains the data to be communicated. The ReadyEvent is sent from the observer to the subject. ReadyEvent contains information about whether the observer is ready to receive. If the observer cannot receive, data will not be sent from the subject to the observer.
[0018]
FIG. 2 shows a state in which the subject of the object A and the observer of the object B communicate. In order for the observer to receive the data, it is necessary to notify the subject of the observer status as preprocessing. When the observer is ready to receive data, the observer sends an ASSERT-READY message to the subject. On the other hand, when the observer is not ready to receive data, the observer sends a DEASSERT-READY message to the subject. When the subject receives ASSERT-READY from the observer, it sends data to the observer. When the observer can receive the next data after receiving the data, it sends ASSERRT-READY to the subject again.
[0019]
Chapter 2 OPEN-R Programming
2.1 Development Flow
Development using the OPEN-R SDK proceeds in the following procedure.
(1) Object design: Design the functions of newly created objects and the flow of data between objects. For example, in the case of "designing an object to track a pink ball", it receives image data, detects the position of the pink ball, and sends command data to move the head in that direction.
(2) Data type design for inter-object communication: Design data types for communicating with other objects. For example, "Receive OFbkImageVectorData as input data and send OCommandVectorData as output data".
(3) stub. Description of cfg: A connection between an entry point for an object to receive a message from the outside and a member function of a core class implemented in the object is defined as a stub. Describe in cfg (Stub Configuration) file. stub. cfg also describes services for sending and receiving data to and from other objects. By executing the stubgen2 command, the stub. The necessary intermediate files are generated from cfg when compiling.
(4) Core class implementation: Implement the core class of the object. stub. It also implements the member functions specified by cfg, the four Doxxx () member functions that must be implemented in the core class, and other member functions.
(5). ocf configuration settings: Set the runtime configuration of the object.
(6) Build: Link and build the required libraries.
(7) Edit setting file: Edit the setting file required at the time of execution. For example:
OBJECT. The CFG enumerates the objects to execute.
CONNECT. CFG describes the connections between objects.
DESIGNDB. The CFG describes the files that the object will access at runtime, with paths.
(8) Execution on AIBO: Copy the following files to the specified location on the AIBO Programming Memory Stick.
-OPEN-R directory where system files are stored
・ Executable file (.BIN)
・ Edited setting file
・ Data files such as motion and sound
Build a wireless LAN environment, connect AIBO to a PC, insert an AIBO programming memory stick into AIBO, and start AIBO.
(9) Debug: From the message displayed on the wireless LAN console, investigate the cause of the bug and debug by referring to the debug statement such as OSSYSPRINT and OSSYSLOG1 described in the source code and other error information. .
[0020]
2.2 Core Class
Figure 3 shows the core class. Core classes are C ++ classes that represent objects. Only one core class can be defined per object. Objects maintain multiple entry points for receiving messages. As shown in Figure 3, each entry point corresponds to an object method, and the method corresponds to a core class member function.
[0021]
The core class has the following features. The core class inherits from Object. The core class implements DoInit (), DoStart (), DoStop (), DoDestroy (). The core class holds the required number of OSObjects and OOServers.

[0022]
Core class member functions have specific methods that correspond to them. The methods are as follows:
(1) Method called at startup or shutdown
Init method: Called at startup. Initialize instances and variables.
Start method: Called after DoInit () has been executed on all objects at startup.
Stop method: Called when shutting down.
Destroy method: Called at shutdown after DoStop () is executed on all objects. Annihilate the subject and observer instances.
The Init method, Start method, Stop method, and Destroy method correspond to the core classes DoInit (), DoStart (), DoStop (), DoDestroy (), respectively.
(2) Method used when receiving a message from another object Method used for subject
Control method: Receives the connection result between the subject and the observer of another object.
Ready method: Subject receives ASSERT-READY or DEASSERT-READY from the observer of another object.
Methods used for observers
Connect method: Receives the connection result between the observer and the subject of another object.
Notify method: Observer receives data from the subject of another object.
[0023]
These methods have the following characteristics:
(A) Member functions corresponding to the Control method, Ready method, Connect method, and Notify method are stub. Describe in cfg.
(B) The member function that receives the message is stub. cfg, the member function to send the message is stub. There is no need to describe in cfg. As an example, we define SampleClass1 as a core class. SampleClass1 inherits OOObject and defines four member functions for OPEN-R. The following is the definition of SampleClass1.

This is an example of SampleClass2 communicating with other objects. Define as many OSObjects and OOservers as you need. The required number is stub. Describe in cfg. The following is a definition example using OSObject and OOServer when performing inter-object communication.

[0024]
2.3 Stub
Stubs are used to connect object entry points to core class member functions. The stub is xxxStub. Defined in cc. xxxStub. cc is transmitted to stub.cc by a stub generator (stubgen2 command). Automatically generated from cfg. Also, xxxStub. Within cc, only one instance of the core class is created as a global variable.
stub. The following items are described in cfg.
・ Number of subjects and number of observers
-Services used for inter-object communication
Subjects and observers provide services for inter-object communication. Services have unique service names that can be distinguished from other services. To connect the service of the subject of an object to the service of the observer of another object, the service name of each other is CONNECT. Describe in CFG.
[0025]
Hereinafter, stub. Here is a description example of cfg.
ObjectName: SampleClass
NumOfOSubject: 1
NumOfOOServer: 2
Service: 'SampleClass. Func1. Data1. S ', Control (), Ready ()
Service: 'SampleClass. Func2. Data2. O ', Connect (), Notify1 ()
Service: 'SampleClass. Func3. Data2. O ', null, Notify2 ()
Extra: UpdatePowerStatus ()
Each item has the following meaning.
ObjectName
Core class name.
NumOfOSubject
The number of subjects. Specify a number greater than one. If you do not need a subject, register one dummy subject.
NumOfOOServer
Number of observers. Specify a number greater than one. If you do not need an observer, register one dummy observer.
Service
Describes the communication service for the object. Describe one service for each subject and observer.
The following are the service configuration items. '(Connection name)', (member function 1), (member function 2)
・ Connection name
The connection name is composed of an object name, a sub name, a data name, and a service type. Each connection name is as follows.
Object name: You can specify any name, but it is usually the name of the core class.
Subname: The name of the service, using a unique name. No two services can have the same name.
Data name: Name corresponding to the data type used in inter-object communication.
Service type: Specify either S (subject) or O (observer).
[0026]
The member functions are as follows.
・ Member function 1
Member function called when receiving a connection result. Member function 1 can be named freely. Member function 1 is implemented in the core class. If member function 1 is not required, write null.
・ Member function 2
For observer services, this is a member function that is called when a message is received from the subject. Or, in the case of a subject service, this is a member function called when ASSERT-READY or DEASSERT-READY is received from the observer. The name of member function 2 can be freely named. Member function 2 is implemented in the core class. Write null if member function 2 is not required.
[0027]
The following is sample code when a dummy subject exists.
Service: 'SampleClass. DummySubject. DontConnect. S ', null, null
If there are multiple services, they can also share the same member function. Below is the sample code.
Service: 'SampleClass. Out1. Data1. S ', Control (), Ready ()
Service: 'SampleClass. Out2. Data1. S ', Control (), Ready ()
Control () and Ready () are member functions common to the two services.
[0028]
Extra entry
If you need an entry point other than the Init, Start, Stop, Destroy, Control, Ready, Connect, and Notify methods, add an entry point to the Extra entry. Below is the sample code. For example, this is the callback function used during network communication.
Extra: NewExtra1 ()
Extra: NewExtra2 ()
stub. Based on the description example of cfg, the message transmission and reception between the subject a of the object A and the observer b of the object B will be described using FIGS.
[0029]
The following is the stub. This is cfg.
ObjectName: ObjectA
NumOfOSubject: 1
NumOfOOServer: 1
Service: 'Object A. SendString. char. S ', null, subject_a ()
Service: 'Object A. DummyObserver. DontConnect. O ', null, null
The following is the stub. This is cfg.
ObjectName: ObjectB
NumOfOSubject: 1
NumOfOOServer: 1
Service: 'ObjectB. DummySubject. DontConnect. S ', null, null
Service: 'ObjectB. ReceiveString. char. O ', null, observer_b ()
The connection between the service of the subject a and the service of the observer b is CONNECT. Suppose the following is written in CFG.
Object A. SendString. char. S Object B. ReceiveString. char. O
At this time, the procedure for sending and receiving messages is as follows.
[0030]
Figure 4 shows the procedure for sending and receiving messages.
(1) Send ASSERT-READY to the subject of object A from DoStart () of object B. This notification reaches the subject_a () of the core class of object A.
(2) subject_a () sends a message to the subject. This notification reaches the core class observer_b () of object B.
(3) When observer b wants to send the next message from subject A, it sends ASSERT-READY to the subject.
[0031]
2.4 DoInit (), DoStart (), DoStop (), DoDestroy ()
Override DoInit (), DoStart (), DoStop (), DoDestroy () with the core class and describe the processing unique to each core class.
DoInit ()
DoInit () is called at startup. DoInit () registers the communication service. The following is a macro to simplify the description.
NEW_ALL_SUBJECT_AND_OBSERVER
Register the required number of subjects and observers.
REGISTER_ALL_ENTRY
Create a connection with the service of another object.
SET_ALL_READY_AND_NOTIFY_ENTRY
Set an entry to receive the message.
The following is sample code using macros.

[0032]
DoStart ()
Called after DoInit () has been performed on all objects. Normally, each observer sends ASSERT-READY to the connected subject. DoStart () is called only once after DoInit (). If you want to delay the timing of sending ASSERT-READY to a specific observer, you can send it to the subject in another member function instead of DoStart (). The following is a macro to simplify the description.
ENABLE_ALL_SUBJECT
Enable the subject of the core class.
ASSERT_READY_TO_ALL_OBSERVER
Send ASSERT_READY to all connected subjects.
The following is sample code using macros.

[0033]
DoStop ()
Called when shutting down. Each observer usually sends a DEASSERT-READY to the connected subject. The following is a macro to simplify the description.
DISABLE_ALL_SUBJECT
Invalidate the subject of the core class.
DEASSERT_READY_TO_ALL_OBSERVER
Sends DEASSERT_READY to all connected subjects.
The following is sample code using macros.

[0034]
DoDestroy ()
Called at shutdown, after calling DoStop () on all objects. The following is a macro to simplify the description.
DELETE_ALL_SUBJECT_AND_OBSERVER
Clear all subjects and observers.
The following is sample code using macros.

[0035]
2.5 Data transmission and reception
When the observer can receive the data, it sends an ASSERT-READY message to the subject.

Upon receiving an ASSERT-READY message from the observer, the subject sends data to the observer.

If the observer can receive data again after receiving data from the subject, it sends ASSERT-READY to the subject.

Here, objFunc1 and sbjFunc2 are IDs for specifying an observer and a subject. def. h.
[0036]
Chapter 3 Build
Figure 5 shows the procedure for building an object and creating an executable file.
3.1. ocf
. Files with the extension of .off are used to describe object settings. The following is. This is the format of the OCF file.
object OBJECT_NAME STACK_SIZE HEAP_SIZE SCHED_PRIORITY CACHE TLB MODE
The following is. This is the sample code of OCF.
object helloWorld 3072 16384 128 cache tlb user
The following is. This is an oct parameter.
OBJECT_NAME
The name of the object.
STACK_SIZE
Stack size in bytes. The stack is not expanded at runtime. The result is undefined if the object uses a stack larger than the specified size (for example, if you declare many auto variables or make a deeply nested function call).
[0037]
HEAP_SIZE
When the object runs out of heap space, the heap is expanded by the size specified here (in bytes). The heap is an area for securing memory required by malloc () and new operator. If the value of HEAP_SIZE is small, the object will expand the heap frequently, leading to a decrease in execution speed.
[0038]
SCHED_PRIORITY
Specifies the scheduling priority of the object as an 8-bit unsigned positive number. The upper 4 bits indicate the scheduling class. Objects with a lower scheduling class are not executed during execution of objects with a higher scheduling class. The recommended value of the scheduling class for normal applications is 128 or less. The lower 4 bits control the execution rate between objects of the same scheduling class. The higher this value, the more time the object has to run.
[0039]
CACHE
Specify cache or nocache. When "nocache" is specified, the cache memory of the processor is invalidated during the execution of the object. Normally, specify cache.
[0040]
TLB
Specify tlb or notlb. It is recommended to specify tlb. When user is specified for MODE, specify tlb. When tlb is specified, a memory area for the object is allocated in the virtual address space. When notlb is specified, the memory area for the object is secured in the physical address space (KSEG0 or 1). This value is ignored when the nomprot configuration described later is used.
[0041]
MODE
Specify kernel or user. When user is specified, the execution mode of the processor is set to user mode when the object is executed. When kernel is specified, the object is executed in kernel mode. This value is ignored when the nomprot configuration is used and the object always runs in kernel mode.
[0042]
3.2 Stub generator
The intermediate file for connecting the method of the object and the member function of the core class is created by the stungen2 command. Generated from cfg. Def. In the intermediate file There is h. The following is def. Here is the sample code for h.
const int sbjFunc1 = 0;
const int obsFunc2 = 0;
sbj and obs are available at stub. It is added to the beginning of the sub name described in cfg.
The following is a sample class. It is the definition in h.
OSSubject * subject [numOfSubject];
OOserver * observer [numOfObserver];
sbjFunc1 and obsFunc2 are descriptions of IDs for specifying subjects and observers (example: subject [sbjFunc1] observer [obsFunc2]).
[0043]
3.3 Compiling and assembling
Compile or assemble using the following command. Commands are common to C ++ source files (.cc) and assembly language source files (.s).
/ Usr / local / OPEN_R_SDK / bin / mipsel-linux-gcc-c [other options] FILE
This creates an object file. The name of the object file is the extension of the source file. It will be changed to o. Be sure to specify the -c option. Without -c, gcc proceeds to the link phase and fails. In OPEN-R SDK, it is not possible to link using the gcc command. Use the mkbin command instead. See the gcc manual for details on other options. If necessary, use the -I option and specify the directory where the header file is located. The following options allow you to use an OPEN-R header file.
-I / usr / local / OPEN_R_SDK / OPEN_R / include / R4000
-I / usr / local / OPEN_R_SDK / OPEN_R / include
[0044]
3.4 Links
Use the following command to link object files.
/ Usr / local / OPEN_R_SDK / OPEN_R / bin / mkbin-oXXX. bin XXX. ocf
[Other options] AAA. o BBB. o CCC. o
This is the object file AAA. o, BBB. o, CCC. o. . . Is linked to the executable file XXX. Create a bin. extension. The file with OCF is a file for describing the settings of the object. Other options of mkbin, except for those listed below, are passed to the linker that mkbin calls internally. See the GNU ld manual for options that can be passed to the linker. In addition to the options specified on the command line, mkbin passes options to the linker to link with the default library. By executing mkbin with the -v flag, you can check the options passed to the linker. mkbin creates some intermediate files, but they are not deleted automatically. The name of the intermediate file is determined as follows based on the name of the executable file to be created.
1. Extension is. If bin, remove it.
2. Next, one of the following character strings is added to the end.
. snap. cc,. snap. o,. nosnap. elf,. snap. elf,. rel. elf
The following is a list of options processed by mkbin.
-O PATH
Specify the path of the executable file to be created. The default value is a. This is bin.
-M PATH
. Specify the path of OCF. PATH. If it ends with OCF. -M can be omitted.
-P PATH
Specify the directory where OPEN-R SDK is installed. The default value is / usr / local / OPEN_R_SDK.
--- nodefaultlib
Disable linking of default library.
--- nocrt
Prohibit the link of startup routine processing. If you do not specify this option, the following files are automatically linked:
crtbegin. o
crtend. o
--- novm
Specifies that the executable file to be created is used in the configuration of nomemprot. The effect is. It is the same as specifying notlb for TLB and kernel for MODE in the ocf file.
-V
Prints verbose messages.
[0045]
Chapter 4 Execution
4.1 Selection of OPEN-R Configuration
The following OPEN-R configurations are available. The OPEN-R directory corresponding to each configuration is located in the / usr / local / OPEN_R_SDK / OPEN_R / MS / directory. To execute the object with the robot, copy one of the OPEN-R directory and the object created by the user to the AIBO programming memory stick and use it.
BASIC / meprot / OPEN-R /
BASIC / nameprot / OPEN-R /
WLAN / memprot / OPEN-R /
WLAN / nameprot / OPEN-R /
WCONSOLE / memprot / OPEN-R /
WCONSOLE / nomemprot / OPEN-R /
[0046]
4.1.1 Difference between BASIC / WLAN / WCONSOLE
Select from the following according to your purpose.
BASIC
When not using a wireless LAN environment
WLAN
When not using the wireless console in a wireless LAN environment
WCONSOLE
When using a wireless LAN environment and wireless console
[0047]
4.1.2 memprot / nomeprot
Select from the following according to your purpose.
memprot enables memory protection. Objects can be operated in user / tlb mode. Please refer to “3.1.off” for the user / tlb mode. The memory used by objects in user / tlb mode is located in a virtual address space that uses a TLB (translation lookaside buffer). It has the following advantages and disadvantages.
Pros: Objects running in user mode cannot access the memory space of other objects. This makes it easier to find bugs caused by using the wrong value pointer. In the virtual address space, multiple memory areas that are not physically contiguous can be used as contiguous memory areas. As a result, memory utilization efficiency is improved.
Disadvantages: The unit for securing shared memory is 4096 bytes. Therefore, if a large amount of small shared memory is secured, the efficiency of memory usage will decrease. There is some overhead on program execution speed in the following ways: (A) Conversion from a virtual address to a physical address when a TLB miss occurs; (b) Securing and releasing a shared memory; attaching to another object
nomprot disables memory protection. All objects operate in kernel / notlb mode. It has advantages and disadvantages opposite to memprot. Under the nomprot environment, one object can access the memory area of another object without using shared memory. However, the source code can be shared with the memprot environment by using the API for shared memory even in the nomprot environment. Under the nomprot environment, the API for shared memory is implemented as a dummy function that does almost nothing and operates at high speed.
[0048]
4.2 Configuration file
To execute an object on AIBO, edit multiple configuration files. OBJECT. CFG, CONNECT. CFG, DESIGNDB. Shows how to write CFG. These files are located on the AIBO Programming Memory Stick in the / OPEN-R / MW / CONF directory.
[0049]
4.2.1 OBJECT. CFG
List the executable file name corresponding to the object you want to execute.
/ MS / OPEN-R / MW / OBJS / XXX. BIN
/ MS / OPEN-R / MW / OBJS / YYY. BIN
/ MS / represents the root directory of the AIBO Programming Memory Stick.
[0050]
4.2.2 CONNECT. CFG
Describes the connection between the subject and the observer.
Class1. Func1. Data1. S Class2. Func2. Data1. O
Class1. Func3. Data2. S Class3. Func4. Data2. O
Each line is described as follows.
'Subject service (.S)', 'Space', 'Observer service (.O)'
The data name of the subject service and the observer service must be the same.
[0051]
4.2.3 DESIGNDB. CFG
Files to be referenced in the program can be switched depending on the robot model. Enter a keyword to search for the file.
#
# DESIGNDB. CFG
#
[ERS-210]
KEYWORD1 / MS / OPEN-R / MW / CONF / ERS-210. TXT
KEYWORD2 / MS / OPEN-R / MW / DATA / P / 210. WAV
[ERS-220]
KEYWORD1 / MS / OPEN-R / MW / CONF / ERS-220. TXT
KEYWORD2 / MS / OPEN-R / MW / DATA / P / 220. WAV
/ MS / represents the root directory of the AIBO Programming Memory Stick.
KEYWORD1 is a tag for file identification. KEYWORD1 is used when reading a data file using the OPEN-R API.
OPENR :: FindDesignData ('KEYWORD1',
(ODesignDataID *) & memID, & addr, &size);
[0052]
4.3 Execution on AIBO
4.3.1 Creating AIBO Programming Memory Stick
First, copy the OPEN-R directory to the root directory of the AIBO Programming Memory Stick. Next, copy the executable file (xxx.bin) to the AIBO Programming Memory Stick. Copy the executable to the following directory:
/ OPEN-R / MW / OBJS /
Copy the LED, motion and sound content data to the following directory on the AIBO Programming Memory Stick.
/ OPEN-R / MW / DATA / P /
Figure 6 shows the directory structure of OPEN-R.
[0053]
4.3.1 Executing AIBO Programming Memory Stick
Insert the AIBO Programming Memory Stick with the OPEN-R directory and the setting file into AIBO, and press the pause button.
[0054]
Chapter 5 Debug
5.1 Error log output
When outputting a character string for debugging, you can use C / C ++ printf or cout, but in an OPEN-R environment where multiple objects operate in parallel, the displayed character string is displayed in a mixed manner. You. It is recommended to use OSSYSPRINT, OSSYSDEBUG, and OSSYSLOG1 macros to avoid this problem.
OSYSPRINT () and OSYSDEBUG () can specify the same arguments as printf (). OSYSDEBUG () is expanded to an empty string when OPENR_DEBUG is not defined. OPENR_DEBUG is defined by the compiler flag DOPENR_DEBUG as shown below.
OSSYSPRINT (('test:% d \ n', x, y));
OSYSDEBUG (('Hello @ n'));
The maximum length of the display string of OSSYSPRINT and OSYSDEBUG is 243 characters including the null character added at the end.
[0055]
OSSYSLOG1 is a macro for error display. The first argument defines the error level. In OSSYSLOG1, a line feed code is automatically added after the character string.
OSSYSLOG1 ((osyslogERROR, 'This is error!'));
The following character string is displayed for the result of OSSYSLOG1.
[Oid: 80000043, prio: 1] This is error!
The number following “prio:” is the error level specified by the first argument. The following error levels can be specified as the first argument of OSSYSLOG1.
Display of prio oid and prio prio value
osyslogERROR Display 1
ossyslogWARNING display 2
ossyslogINFO display 3
[0056]
5.2 Investigation of CPU exception
If a program performs an erroneous operation (such as referencing an illegal address or executing an illegal instruction), a CPU exception may occur and execution of the program may be forcibly terminated. At the time of forced termination, a specific buzzer sounds and information necessary for analyzing the cause of the CPU exception is written to the Memory Stick. This section describes how to analyze the cause of a CPU exception based on that information. The CPU used in AIBO is a MIPS processor. Analyzing the cause of a CPU exception requires knowledge of the MIPS architecture.
[0057]
5.2.1 Basic knowledge required for analysis
・ OPEN-R operation mode
CPU operates in 32-bit mode, little endian.
.CPU exception that causes the system to be forcibly terminated
TLB exception
Address error exception
Reserved instruction exception
Floating-point operation exception
Coprocessor unavailable exception
Bus error exception
[0058]
・ How to use compiler registers
There are 32 general-purpose registers of the MIPS CPU. The name in parentheses is convention name.
r0 (zero)
A register whose value is always 0.
[0059]
r2, r3 (v0, v1)
Used to hold the return value of a subroutine. v1 is used to return a 64-bit value.
[0060]
r4-r7 (a0-a3)
Used to hold arguments when calling a subroutine. If the argument is 5 or more, it is pushed on the stack. When calling the C ++ member function, a0 becomes the this pointer.
[0061]
r8-r15, r24, r25 (t0-t7, t8, t9)
Use without saving the value in the subroutine. Therefore, the value when returning after calling another subroutine is not guaranteed. For example, when the value of t0 is set to 1 and another subroutine is called and returned, there is no guarantee that the value of t0 is 1.
[0062]
r16-r23, r30 (s0-s7, s8)
Use it temporarily in a subroutine, but save the value before using it. Therefore, the value when returning after calling another subroutine is guaranteed. For example, when the value of s0 is set to 1 and another subroutine is called and returned, the value of s0 is 1.
[0063]
r28 (gp)
At the beginning of the subroutine, set to point to the address at the time of execution of symbol _gp. Used to determine the runtime address of another symbol.
[0064]
r29 (sp)
Stack pointer. For subroutines that use the stack, reduce the value of the stack pointer by the size used at the beginning of the subroutine, and increase the stack pointer to its original position before returning from the subroutine.
3c8: 27bdffc8 addi sp, sp, -56
440: 03e00008 jr ra
444: 27bd0038 addiu sp, sp, 56
[0065]
r31 (ra)
Used to hold the subroutine return address. If a subroutine is called using a jump instruction with a link (jal, jarr), the return address is two instructions ahead of this instruction. And the last instruction in a subroutine is typically jara. If you want to call another subroutine within a subroutine, save ra on the stack.
[0066]
Some of the system control coprocessor registers are:
Status
Holds the state of the operating mode and interrupt mask.
Cause
Holds cause information for CPU exceptions.
BadVAddr
When a CPU exception (TLB exception, address error exception) occurs by referencing a virtual address, the virtual address that caused the exception is retained.
EPC
Holds the address of the instruction being executed when a CPU exception occurs.
[0067]
How the compiler uses the stack
Subroutine calls and subroutines that use registers s0-s8 use the stack to save the original values of the registers used. The stack is sometimes used as storage for auto variables. When calling a subroutine, the OPEN-R SDK compilers gcc and g ++ store the current ra at the top word address of the stack.
An example is shown below.

Figure 7 shows the state of the stack that is called func1 and func2 in order from the function entry_point0, and is executing the address (a) of func2.
[0068]
For more information on the MIPS architecture, refer to the following literature. See MIPS Run (author: Dominic Sweetman, publisher: Morgan Kaufmann Publishers, ISBN: 1558604103), MIPS RISC Architecture (author: Gerry Kane, J.R.E. R3000-(author: Gerry Kane, translator: Maekawa Mamoru, publisher: Kyoritsu Shuppan, ISBN: 432239899)
[0069]
5.2.2 System operation when CPU exception occurs
The system terminates. If a CPU exception occurs, the system starts the Exception Monitor with all objects stopped. At this time, the operation of the wireless console also stops. Exception Monitor is available on AIBO Programming Memory Stick at / OPEN-R / SYSTEM / CONF / EMON. After executing the command written in CFG, turn off the power of AIBO.
[0070]
5.2.2.1 Default EMON. CFG
EMON. CFG files are located in the following directory.
/ OPEN-R / SYSTEM / CONF /
EMON. Contents of CFG
play exception
play warning
exception> / MS / OPEN-R / EMON. LOG
cp0 >> // MS / OPEN-R / EMON. LOG
cp1 >> // MS / OPEN-R / EMON. LOG
objs >> // MS / OPEN-R / EMON. LOG
dstack -max 0x4000 -r 0x40 >> // MS / OPEN-R / EMON. LOG
play finish
[0071]
/ MS / represents the root directory of the AIBO Programming Memory Stick. The output of the five commands exception, cp0, cp1, objs, and dstack is output from the / OPEN-R / EMON. Written on LOG. The sound is played by the play command from the start of the Exception Monitor to the end of the system. While the sound is sounding, writing to the Memory Stick is in progress.
[0072]
5.2.3 CPU exception types and object identification
The type of CPU exception is EMON. Examine the LOG and look for the exception code display that the exception command outputs last. To identify the object, use the value of [object info] context and the information of [object list]. For example, EMON. If the LOG is written as shown in Fig. 8, the object crash is the cause of the CPU exception.
[0073]
5.2.4 Specifying assembly instructions
When a TLB exception or address error exception occurs, first check the value of BadVAddr. In the case of an address error exception, BadVAddr holds the address where memory reference failed, such as an unaligned address.
[0074]
In the case of a TLB exception, BadVAddr holds the virtual address for which address translation failed. Then check the value of EPC. If the value of EPC is the same as the value of BadVAddr, it is considered that a jump to an invalid address has caused a CPU exception. If the value of ra is a valid address, check the assembly instruction at that address as follows. If the value of EPC is different from the value of BadVAddr, check the assembly instruction at the address of the value of EPC. It may be the data area or the stack area. It is a state that jumped to the data area or stack area by mistake somewhere and accidentally caused a CPU exception. At that time, the assembly instruction is checked with the value of ra that knows the address before jumping there.
[0075]
How to check assembly instructions
Since the address found by the Exception Monitor is an address determined at the time of execution, to check an assembly instruction, calculate the corresponding link-time address. Do the following calculation.
<Address at the time of link> =
<Address at execution> − <value of gp register> + <address of symbol_gp>
The value of the gp register is EMON. Examine the value of LOG [general register] gp: r28 :.
The address of the symbol _gp at the time of linking is. In the directory where you created the bin file, run the following command to find out:

The second value displayed is 0x00466490 in this example.
[0076]
Once this calculation gives the link address, execute the following command:
% Mipsel-linux-objdump-d-C <object name>. nosnap. elf
The disassembly result of this object is displayed. Check the assembly instructions and function names around the link address. For example, in the following example, if the address you want to know is 4003d8, and the above command is executed, the execution result shown in Fig. 9 will be output.
[0077]
Here we can see that the location is in the function access_null_data_pointer (). Once the function name is known, search the source code and match the disassembly result with the source code to identify the problem. If there is no address you want to know in the disassembly result, check if the address is a text area from the execution result of the following command.
% Mipsel-linux-nm-n-C <object name>. nosnap. elf
Check the contents of the data area from the execution result of the following command.
% Mipsel-linux-objdump-st-C <object name>. nosnap. elf
EMON. Also check the contents of the stack from [stack info] and [stack dump] of LOG.
[0078]
5.2.5 EMON. Commands that can be used in CFG
exception
This command outputs information on the object that caused the CPU exception and the contents of the general-purpose registers when the exception occurred.
Format: exception
Execution example: An execution example of exception is shown in FIG.
[0079]
cp0
This command displays the contents of the registers of coprocessor 0 (system control coprocessor).
Format: cp0
Execution example: An execution example of cp0 is shown in FIG.
[0080]
cp1
This command displays the contents of the coprocessor 1 (floating point unit) registers.
Format: cp1
Execution example: An execution example of cp1 is shown in FIG.
[0081]
objs
This command displays a list of objects that existed when the CPU exception occurred.
From the output of this command, you can check the correspondence between the object name and the context ID.
Format: objs
Execution example: An execution example of obis is shown in FIG.
[0082]
stack, dstack
The stack command displays the stack information of the object that caused the CPU exception, and the dstack command displays the contents of the stack. When executed without arguments, the dstack command dumps the stack from the address pointed to by sp. The maximum size to be dumped can be specified with the option -max. If the option -r is added, the dump will start from the address lower than sp for the specified size. Both commands can also display the stack information of another object by specifying the context ID of the object as an argument.

[0083]
tlb
The tlb command displays the contents of TLB.
Format: tlb
Execution Example: An execution example of tlb is shown in FIG.
[0084]
dump
The dump command displays the memory contents in hexadecimal. Specify the address as an argument. If no size is specified, the size will be displayed as 0x100. When the option -w is specified, the display is every 2 bytes, and when the -l is specified, the display is every 4 bytes. ASCII characters are displayed for each byte on the right side of the hexadecimal display. For characters that cannot be displayed, a period '.'' It is displayed. This character display does not change depending on the options -l and -w.
Format: dump [-w | -l] addr [size]
Example of execution (dump 0x804600238 0x40): An example of execution of dump is shown in FIG.
[0085]
play
Use this command to play a sound. Select the melody to play with the argument.
Syntax: play melody Argument melody description
exception: For launching the Exception Monitor.
Warning: Warning for writing to Memory Stick. This melody loops automatically.
Finish: Used to end writing to the Memory Stick.
[0086]
A. Library functions
The following functions can be used in programs created with the OPEN-R SDK. The libraries that define these functions are automatically linked by the mkbin command.
[0087]
A. 1 File system
You can access the file system using the following functions: The write () and read () functions are also used to access the terminal. The following functions work almost the same as the UNIX API of the same name. Functions: open, close, read, write, lseek, fstat, stat, unlink, isatty, mkdir, rmdir, opendir, closedir, readdir, rewinddir
The following describes the operations specific to the OPEN-R SDK.
File descriptors less than 3 represent terminal devices (telnet terminals).
There is no difference between descriptors 0, 1, and 2. File descriptors are common throughout the system. You can use file descriptors opened by one object by another.
The following are restrictions on file system paths:
・ The directory separator is indicated by /.
・ The pass must start with / MS /. / MS / represents the root of the AIBO programming memory stick. Relative paths cannot be used.
・ File name is 8 + 3 format.
An example
BASENAME. EXT (correct)
BASENAMEEXT (wrong)
The symbol that distinguishes the file name and extension is'. 'is.
・ The following are the characters that can be used. Lowercase letters are automatically converted to uppercase.
[0088]
abcdefghhijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
＄ &# ｛｝ ￣% '()-＠ ＾ ｀! _
The following flags can be used with open ().
O_RDONLY, O_WRONLY, O_RDWR, O_APPEND, O_CREATE, O_TRUNC, O_EXCL
open () ignores mode_t type arguments. An already opened file can be reopened only if O_RDONLY is specified in both open () calls. isatty () returns 1 if the file descriptor is less than 3. Otherwise it returns 0.
[0089]
The following are the member variables of the structure returned by stat () and fstat (). Members other than those below have undefined values.
st_size: File size. This value may not show the correct value while the file is open.
st_mode: The access right is always 0777. For a file, the S_IFREG bit is set to 1. For a directory, the S_IFDIR bit is set to 1.
mkdir () ignores mode_t type arguments. The maximum number of entries that can be read using readdir () is 682. In the direct structure returned by readdir (), only the d_name field is valid. The values of other fields are undefined. In the d_name field, the name of the directory entry is stored as a null-terminated character string. readdir () does not return volume label and long file name entries.
[0090]
A. 2C standard library
OPEN-R SDK uses newlib-1.9.0 for C library. The following describes the operation specific to the OPEN-R SDK.
The following functions that depend on the UNIX API do not work.
execve, fork, getpid, gettimeofday, kill, link, times, wait, fcntl
The following functions apply to this:
clock, fdopen, raise, signal, system, mkstep, mktemp, tempnam, tmpfile, tmpnam.
The following functions that depend on the UNIX API have behavior specific to the OPEN-R SDK, as described in the previous section.
open, close, read, write, lseek, fstat, stat, unlink, isatty
The following functions apply to this:
fclose, fflush, fgetc, fgetpos, fgets, fileno, fiprintf, fopen, fprintf, fputc, fputs, fread, freopen, fseek, fsetpos, ftell, fwrite, getc, getchar, getopt, gets, getw, iprintf, perror, printf, putc, putchar, puts, putw, remove, rewind, setbuf, setvbuf, ungetc, vfiprintf, vfprintf, vprintf, scanf, fscanf
The following functions do not use the newlib implementation.
• exit () stops the execution of the object. The object enters message waiting state. C ++ static variable destructors are not called.
・ Exitit () does nothing.
-Abort () displays a message that abort () has been called. Then abort () stops the execution of the object. The object enters message waiting state.
• rename () changes the path of a file or directory. See the previous section for restrictions on paths.
-Use dlmalloc library version 2.7.0 instead of 2.6.4 in newlib to implement memory allocation / release such as malloc () and free ().
[0091]
A. 3 C ++ standard library
OPEN-R SDK uses libstdc ++-v3 included in the gcc package as a C ++ standard library. Since this library calls newlib functions internally, the above description also applies to C ++ features.
[0092]
B. stub. cc
The source code of the object must satisfy the following items. Please note the following items only when you are not using the stub generator. The code created by the stub generator automatically satisfies the following items:
[0093]
ObjectEntryTable
The object waits for a structure named ObjectEntryTable. This structure specifies the correspondence between selector numbers and entry points. ObjectEntryTable has the following format.

SELECTOR_NUMBER is a non-negative integer. ENTRY_POINT is called when the object receives a message with selector number SELECTOR_NUMBER. For ENTRY_POINT, specify a function defined using the GEN_ENTRY macro described later.
[0094]
GEN_ENTRY macro
The GEN_ENTRY macro takes two arguments, ENTRYNAME and FUNNAME, and defines an entry point function with the name specified by ENTRYNAME. This function is a wrapper function. This function sets some registers and calls the function specified by FUNNAME. All functions registered in the ObjectEntryTable are defined using this macro. The function FUNNAME has C linkage and takes one argument of type void * indicating the data of the received message. The GEN_ENTRY macro is an apsys. h.
[0095]
PrologueEntry
The following line must be in the source code of the object:
GEN_ENTRY (Prologue Entry, Prologue);
It defines the entry point function PrologueEntry (). This function is called when the object has been loaded. PrologueEntry () is libapsys. Call Prologue () defined in a. libapsys. a is automatically linked to the object with the mkbin command. Prologue () does some initialization and calls the C ++ global variable constructor.
[0096]
Code example
The following is a code example that satisfies the above conditions.

<Reference Guide>
Subsequently, the base class of the object used in this specific example will be described.
[0097]
Chapter 1 Base Class
1.1 OObject class
OOObject is the base class for objects. Init (), Start (), Stop (), Destroy () are associated with the entry of entryEntry, entrySTART, entrySTOP, entryDESTROY of the object. When a message is sent from the ObjectManager to oentryINIT, oentrySTART, oentrySTOP, and oentryDESTROY, Init (), Start (), Stop (), Destroy () are activated, and DoInit (), DoStartDrop (), DoStartDrop (), and DoStartDrop (), respectively. Start (). In the inheritance class of OObject, DoInit (), DoStart (), DoStop (), DoDestroy () describe the processing unique to the object. OOObject has myOID_ in the protected member and can be used in inherited classes. myOID_ is initialized by OOObject :: OOObject ().
[0098]
The header file is “#include <OPENR / OOObject.h>”, and the library is “libOPENR.a”. The classes are shown below.

[0099]
In addition, the OObject class has the following member functions.
・ Init ()
The syntax is void Init (const OSSystemEvent & event), which is called from OOObjectManager when the object is initialized. At the time of Init, the event is passed from the ObjectManager to the object. Init () starts DoInit (), and notifies the return value of DoInit () to OOObjectManager. The dummy argument is event (event information of Init). There is no return value.
[0100]
・ Start ()
The syntax is void Start (const OSSystemEvent & event), which is called from OOObjectManager when the object starts. At Start, the event is passed from the ObjectManager to the object. Start () invokes DoStart () and notifies OOObjectManager of the return value of DoStart (). The dummy argument is event (event information of Start). There is no return value.
[0101]
・ Stop ()
The syntax is void Stop (const OSSystemEvent & event), which is called from OOObjectManager when the object stops. At Stop, the event is passed from the ObjectManager to the object. Stop () invokes DoStop () and notifies the ObjectManager of the return value of DoStop (). The formal argument is event (event information of Stop). There is no return value.
[0102]
・ Destroy ()
The syntax is void Destroy (const OSSystemEvent & event), which is called from OObjectManager when the object is destroyed. During Destroy, the event is passed from the ObjectManager to the object. Destroy () invokes DoDestroy () and notifies OObjectManager of the return value of DoDestroy (). The dummy argument is event (event information of Destroy), and has no return value.
[0103]
・ DoInit ()
The syntax is OSStatus DoInit (const OSSystemEvent & event), which is invoked from Init (). Override in the inherited class to write your own processing. event is the same as passed in Init (). The return value of DoInit () is reported to ObjectManager in Init (). The dummy argument is event (event information of Init), and return values include oSUCCESS (success) and other (in the case of failure, return other than oSUCCESS). The return value can be set freely with DoInit () to be overridden.
[0104]
・ DoStart ()
The syntax is OSStatus DoStart (const OSSystemEvent & event), which is invoked from Start (). Override in the inherited class to write your own processing. event is the same as the one passed in Start (). The return value of DoStart () is notified to OOObjectManager in Start (). The formal argument is event (event information of Start), and return values include oSUCCESS (success) and other (in the case of failure, a value other than oSUCCESS is returned). The return value can be set freely with DoStart () to be overridden.
[0105]
・ DoStop ()
The syntax is OSStatus DoStop (const OSSystemEvent & event), which is invoked from Stop (). Override in the inherited class to write your own processing. event is the same as passed in Stop (). The return value of DoStop () is reported to ObjectManager in Stop (). The dummy argument is event (event information of Stop), and the return value includes oSUCCESS (success) and other (in the case of failure, a value other than oSUCCESS is returned), and the return value is DoStop () to be overridden. Can be set freely.
[0106]
・ DoDestroy ()
The syntax is OSStatus DoDestroy (const OSSystemEvent & event), which is invoked from Destroy (). Override in the inherited class to write your own processing. event is the same as passed in Destroy (). The return value of DoDestroy () is notified to OOObjectManager in Destroy (). The dummy argument is event (event information of Destroy), and return values include oSUCCESS (success) and other (in the case of failure, return other than oSUCCESS). The return value can be set freely with DoDestroy () to be overridden.
[0107]
・ RegisterServiceEntry ()
The syntax is Status RegisterServiceEntry (const OSServiceEntry & entry, const char * name), and register the service entry. Formal arguments are entry (service entry) and name (service name), and return values are oSUCCESS (success), oALREADY_EXIST (a service entry with the same name is already registered), and oFAIL (failure). .
[0108]
Chapter 2 Communication between Objects
2.1 OSObject class
The Object class has the following member functions.
・ OSObject ()
The syntax is OSObject (void), which is a constructor. There are no dummy arguments or return values.
[0109]
・ ￣OSubject ()
The syntax is $ Object (), which is a destructor. There are no dummy arguments or return values.
[0110]
・ SetReadyEntry ()
The syntax is OSStatus SetReadyEntry (const OSServiceEntry & entry), which sets the entry for the subject to receive an ASSERT-READY message or a DEASSERT-READY message. This setting is made in DoInit (). The dummy argument is entry (an entry for receiving an ASSERT-READY message or a DEASSERT-READY message). Return values include oSUCCESS (success) and other than the above (failure).
[0111]
・ GetID ()
The syntax is const SubjectID & GetID (void) const, and gets the subject ID of the subject. SubjectID is a unique value for each subject. There are no dummy arguments. The return value includes the Subject ID.
[0112]
・ SetBufferSize ()
The syntax is
OSStatus SetBufferSize (size_t size), which sets the maximum buffer size prepared for each observer in the subject. This setting is performed in DoInit (). The dummy argument is size (maximum buffer size for each observer), and return values include oSUCCESS (success) and other than the above (failure).
[0113]
・ GetBufferSize ()
The syntax is size_t GetBufferSize (void) const, which returns the buffer size set by DoInit (). There are no dummy arguments. The return value is the current buffer size.
[0114]
・ SetNotifyUnitSize ()
The syntax is OSStatus SetNotifyUnitSize (size_t size), which sets the number of SetData () that constitutes the minimum unit of transmission data. For example, when certain data is composed of a header and a body, and SetData () is executed separately and NotifyObservers () is executed, the value to be set is 2. Call this function to calculate the size of the buffer that the subject should prepare. To set this value, do it in DoInit (). If not set, the default value is 1. This corresponds to the case where SetData () and NotifyObservers () are called alternately once each. The dummy argument is size (the number of SetData () required to constitute the minimum unit of transmission data). Return values include oSUCCESS (success) and other than the above (failure).
[0115]
・ GetNotifyUnitSize ()
The syntax is size_t GetNotifyUnitSize (void) const, which returns the number of SetData () required to form the smallest unit of transmitted data. There are no dummy arguments. The return value is the number of SetData () required for one transmission.
[0116]
・ SetData ()
The syntax is OSStatus SetData (const void * buf, size_t size), which sets the data (address and size) in the buffers for all observers. The specified data is copied to the shared memory area, so the area pointed to by buf can be overwritten after calling this function. On overflow, the oldest data for transmission is overwritten with the current data. Use RemainBuffer () to know the overflow in advance. The formal arguments are buf (pointer to the area where data is located) and size (data size), and return values include oSUCCESS (success) and other than the above (failure).
[0117]
・ SetData ()
The syntax is OSStatus SetData (const ObserverInfo & info, const void * buf, size_t size), which sets data (address and size) in the specified observer buffer. This function is more efficient than SetData (const ObserverID &, const void *, size_t), as the call to FindObserver () can be omitted. In this function, the specified data is copied to the shared memory area, so after calling this function, the area pointed to by buf can be overwritten. On overflow, the oldest data for transmission is overwritten with the current data. Use RemainBuffer () to know the overflow in advance. Formal arguments are info (observer information. ObserverInfo type can be obtained by accessing data pointed to by ObserverConstIterator type obtained by calling, for example, OSObject :: begin ()), buf (area with data Pointer), and size (size of data). Return values include oSUCCESS (success) and other than the above (failure).
[0118]
・ SetData ()
The syntax is OSStatus SetData (const ObserverID & id, const void * buf, size_t size), and this function works exactly as SetData (* FindObserver (id), buf, size). That is, data (address and size) is set in the specified observer buffer. In this function, the specified data is copied to the shared memory area, so after calling this function, the area pointed to by buf can be overwritten. In case of overflow, the oldest data for transmission is overwritten. Use RemainBuffer () to know the overflow in advance. The formal parameters are id (ObserverID. If id is invalid for this subject, the result or effect of this function is undefined), buf (pointer to the area where data is located), and size (size of data). . Return values include oSUCCESS (success) and other than the above (failure).
[0119]
・ SetData ()
The syntax is OSStatus SetData (RCRegion * region), which sets the shared memory area specified by the region argument in all observer buffers. In case of overflow, the oldest data for transmission is overwritten. Use RemainBuffer () to know the overflow in advance. Within this function, RCRegion :: AddReference () is called, and the reference counter for the specified area is incremented. Do not overwrite or change the specified area until it is available again. Use RCRegion :: NumberOfReference () to check if the area is available. The dummy argument is a region (a pointer to a shared memory area with a reference counter). Return values include oSUCCESS (success) and other than the above (failure).
[0120]
・ SetData ()
The syntax is OSStatus SetData (const ObserverInfo & info, RCRegion * region), which sets the shared memory area specified by the region argument in the buffer for the specified observer. This function is more efficient than SetData (const ObserverID &, RCRegion * region), because the call to FindObserver () can be omitted. In case of overflow, the oldest data for transmission is overwritten. Use RemainBuffer () to know the overflow in advance. Within this function, RCRegion :: AddReference () is called, and the reference counter for the specified area is incremented. Do not overwrite or change the specified area until it is available again. Use RCRegion :: NumberOfReference () to check if the area is available. Formal arguments are info (observer information. ObserverInfo type can be obtained by accessing data pointed to by ObserverConstIterator type obtained by calling OSObject :: begin (), for example), region (shared with reference counter) Pointer to a memory area). Return values include oSUCCESS (success) and other than the above (failure).
[0121]
・ SetData ()
The syntax is OSStatus SetData (const ObserverID & id, RCRegion * region), and this function works the same as SetData (* FindObserver (id), region). That is, the shared memory area specified by the region argument is set in the specified observer buffer. In case of overflow, the oldest data for transmission is overwritten. Use RemainBuffer () to know the overflow in advance.
Within this function, RCRegion :: AddReference () is called, and the reference counter for the specified area is incremented. Do not overwrite the specified area until it becomes available again. Use RCRegion :: NumberOfReference () to check if the area is available. The formal arguments are id (Observer ID. If id is invalid for the subject, the result and effect of the function are undefined) and region (pointer to the shared memory area with reference counter). Return values include oSUCCESS (success) and other than the above (failure).
[0122]
・ SetData ()
The syntax is OSStatus SetData (const OShmPtrBase & p), which sets the shared memory area pointed to by the specified pointer in all observer buffers. On overflow, the oldest data for transmission is overwritten. Use RemainBuffer () to know the overflow in advance. The dummy argument is p (a pointer that points to a shared memory area with a reference counter). Return values include oSUCCESS (success) and other than the above (failure).
[0123]
・ SetData ()
The syntax is OSStatus SetData (const ObserverInfo & info, const OShmPtrBase & p), which sets the shared memory area pointed to by the specified pointer in the specified observer buffer. This function is more efficient than SetData (const ObserverID &, const OShmPtrBase & p), because the call to FindObserver () can be omitted. In case of overflow, the oldest data for transmission is overwritten. Use RemainBuffer () to know the overflow in advance. Formal arguments are info (observer information. ObserverInfo type can be obtained by accessing data pointed to by ObserverConstIterator type obtained by calling OSObject :: begin (), for example), p (shared with reference counter) Pointer to the memory area). Return values include oSUCCESS (success) and other than the above (failure).
[0124]
・ SetData ()
The syntax is OSStatus SetData (const ObserverID & id, const OShmPtrBase & p), which sets the shared memory area pointed to by the specified pointer in the specified observer buffer. In case of overflow, the oldest data for transmission is overwritten. Use RemainBuffer () to know the overflow in advance. This function performs the same operation as SetData (* FindObserver (id), p). The dummy arguments are id (Observer ID. If the id is invalid for the subject, the result or effect of this function is undefined) and region (a pointer to a shared memory area with a reference counter). Return values include oSUCCESS (success) and other than the above (failure).
[0125]
・ NotifyObserver ()
The syntax is OSStatus NotifyObserver (const ObserverInfo & observer), which sends the data held in the buffer to the specified observer. If the observer is in the ASSERT-READY state, the data is sent immediately. If the observer is in the DEASSERT-READY state, delete the data. If the observer is not in the ASSERT-READY state or the DEASSERT-READY state, hold the data in the buffer and transmit as soon as the observer enters the ASSERT-READY state. The dummy argument is observer (observer information. The ObserverInfo type can be obtained by accessing data indicated by the ObserverConstIterator type obtained by calling, for example, OSObject :: begin ()). Return values include oSUCCESS (success) and other than the above (failure).
[0126]
・ NotifyObserver ()
The syntax is OSStatus NotifyObserver (const ObserverID & id), which sends the data held in the buffer to the specified observer. If the observer is in the ASSERT-READY state, the data is sent immediately. If the observer is in the DEASSERT-READY state, delete the data. If the observer is not in the ASSERT-READY state or the DEASSERT-READY state, hold the data in the buffer and transmit as soon as the observer enters the ASSERT-READY state. The same processing as NotifyObserver (* FindObserver (id)) is included, so it includes the overhead of FindObserver () The dummy argument is id (ObserverID). Return values include oSUCCESS (success) and other than the above (failure).
[0127]
・ NotifyObservers ()
The syntax is OSStatus NotifyObservers (void), which sends buffered data to all observers. If the observer is in the ASSERT-READY state, the data is sent immediately. If the observer is in the DEASSERT-READY state, discard the data. If the observer is not in the ASSERT-READY state or the DEASSERT-READY state, hold the data in a buffer and transmit it as soon as the observer enters the ASSERT-READY state. There are no dummy arguments. Return values include oSUCCESS (success) and other than the above (failure).
[0128]
・ RemainBuffer ()
The syntax is size_t RemainBuffer (const ObserverInfo & observer) const, which returns the remaining number of buffers for the specified observer. If SetData () is called more times than the return value, old data stored in the buffer will be deleted. The dummy argument is observer (observer information. The ObserverInfo type can be obtained by accessing data indicated by the ObserverConstIterator type obtained by calling, for example, OSObject :: begin ()). The return value is the remaining number of buffers.
[0129]
・ RemainBuffer ()
The syntax is size_t RemainBuffer (const ObserverID & id) const, which returns the remaining number of buffers for the specified observer. If SetData () is called more times than the return value, old data stored in the buffer will be deleted. This function performs the same operation as MainBuffer (* FindObserver (id)). The dummy argument is id (observer ID), and the return value is the remaining number of buffers.
[0130]
・ RemainBuffer ()
The syntax is size_t RemainBuffer (void) const, which returns the remaining number of buffers for the observer. If SetData () is called more times than the return value, old data stored in the buffer will be deleted. There are no dummy arguments. The return value is the remaining number of buffers.
[0131]
・ ClearBuffer ()
The syntax is OSStatus ClearBuffer (void), which clears all observer transmit buffers. There are no dummy arguments. Return values include oSUCCESS (success) and other than the above (failure).
[0132]
・ ClearBuffer ()
The syntax is OSStatus ClearBuffer (const ObserverInfo & info), which clears the transmit buffer for the specified observer. The dummy argument is info (observer information). Return values include oSUCCESS (success) and other than the above (failure).
[0133]
・ ClearBuffer ()
The syntax is OSStatus ClearBuffer (const ObserverID & id), which clears the transmit buffer for the specified observer. Performs the same operation as ClearBuffer (* FindObserver (id)). The dummy argument is id (observer ID). Return values include oSUCCESS (success) and other than the above (failure).
[0134]
・ NumberOfObservers ()
The syntax is int NumberOfObservers (void) const, which returns the number of observers connected to the subject. There are no dummy arguments. The return value is the number of observers connected to the subject.
[0135]
・ Begin ()
The syntax is ObserverConstIterator begin (void) const, which returns an iterator pointing to the first observer in the list of observers attached to the subject. There are no dummy arguments. The return value is an iterator pointing to the first observer.
[0136]
・ End ()
The syntax is ObserverConstIterator end (void) const, which returns an invalid iterator pointing to the list of observers attached to the subject, after the last observer. There are no dummy arguments. The return value is an invalid iterator pointing after the last observer.
[0137]
・ FindObserver ()
The syntax is ObserverConstIterator FindObserver (const ObserverID & id) const, which returns an iterator pointing to the observer specified by id. If no observer with id can be found, return an invalid iterator. There are no dummy arguments. The return value is an iterator pointing to the specified observer.
[0138]
・ IsAllReady ()
The syntax is int IsAllReady (void) const, which checks whether all observers are in the ASSERT-READY state or the DEASSERT-READY state. There are no dummy arguments. If the return value is other than 0, all observers must hold either the ASSERT-READY state or the DEASSERT-READY state, and at least one observer is in the ASSERT-READY state. Executing NotifyObserver () in this state immediately sends the message to all observers that need the message. If it is 0, there is at least one observer that is not in the ASSERT-READY state or the DEASSERT-READY state, or all observers are in the DEASSERT-READY state.
[0139]
・ IsAnyReady ()
The syntax is int IsAnyReady (void) const, which checks if there is an observer in ASSERT-READY state. There are no dummy arguments. If the return value is other than 0, there is at least one observer in the ASSERT-READY state. If it is 0, there is no observer in the ASSERT-READY state.
[0140]
・ IsReady ()
The syntax is int IsReady (const ObserverInfo & info) const, which checks if the specified observer is in ASSERT-READY state. The dummy argument is info (observer information. The ObserverInfo type can be obtained by accessing data pointed to by the ObserverConstIterator type obtained by calling OSObject :: begin (), for example). If the return value is other than 0, the specified observer is in the ASSERT-READY state. If 0, the specified observer is not in ASSERT-READY state.
[0141]
・ IsReady ()
The syntax is int IsReady (const ObserverID & id) const, which checks whether the specified observer is in ASSERT-READY state. Performs the same operation as IsReady (* FindObserver (id)). The dummy argument is id (Observer ID). If the return value is other than 0, the specified observer is in the ASSERT-READY state. If the return value is 0, the specified observer is not in the ASSERT-READY state.
[0142]
・ ReadyStatus ()
The syntax is int ReadyStatus (const ObserverInfo & info) const, which returns the state of the specified observer. The dummy argument is info (observer information. The ObserverInfo type can be obtained by accessing data pointed to by the ObserverConstIterator type obtained by calling OSObject :: begin (), for example). If the return value is a positive number, it indicates that the ASSERT-READY message has been received from the observer specified by the subject (ASSERT-READY state). If the return value is 0, the observer specified by the subject has not yet transmitted a message. Indicates that the status is unknown. A negative value indicates that the subject has received a DEASSERT-READY message from the observer specified by the subject (DEASSERT-READY state).
[0143]
・ ReadyStatus ()
The syntax is int ReadyStatus (const ObserverID & id) const, which returns the state of the specified observer. Performs the same operation as ReadyStatus (* FindObserver (id)). The dummy argument is id (Observer ID). If the return value is a positive number, it indicates that an ASSERT-READY message has been received from the observer specified by the subject (ASSERT-READY state), and if the return value is 0, the subject has not yet transmitted a message from the specified observer. If the status is unknown, a negative number indicates that the subject has received a DEASSERT-READY message from the specified observer (DEASSERT-READY status).
[0144]
・ ControlHandler ()
The syntax is void ControlHandler (const OControlMessage & msg, OSStatus status = oSUCCESS), and the subject is set according to the received OControlMessage. Called during the connection phase of the object. The formal parameters are msg (OControlMessage received from observer) and status (user-defined status). The default value specifies oSUCCESS. Connection is rejected if not oSUCCESS. For example, if initialization or resource allocation fails with a user-defined hook method, specify oFAIL. There is no return value.
[0145]
・ ReadyHandler ()
The syntax is void ReadyHandler (const OReadyMessage & msg), which receives and processes the OReadyMessage. The dummy argument is msg (OReadyMessage received from the observer) and has no return value.
[0146]
2.2 OReadyEvent class
The OReadyEvent class has the following member functions.
・ SbjIndex ()
The syntax is int SbjIndex (void) const and returns the index of the subject receiving the OReadyEvent. There are no dummy arguments. The return value is the subject index.
[0147]
・ SenderID ()
The syntax is const ObserverID & SenderID (void) const, which returns the ObserverID of the observer that sent the OReadyEvent. There are no dummy arguments. The return value is ObserverID.
[0148]
・ IsAssert ()
The syntax is boolean IsAssert (void) const, which checks if the OReadyMessage is an ASSERT-READY message. There are no dummy arguments. Return values include true (ASSERT-READY message) and false (other than the above).
[0149]
・ IsDeassert ()
The syntax is bool Is Deassert (void) const, which checks if the OReadyMessage is a DEASSERT-READY message. There are no dummy arguments. Return values include true (DEASSERT-READY message) and false (other than the above).
[0150]
2.3 OOserver class
The OOServer class has the following member functions.
・ OObserver ()
The syntax is OOServer (void), which is a constructor. There are no dummy arguments or return values.
・ ￣OObserver ()
The syntax is $ OOServer (), which is a destructor. There are no dummy arguments or return values.
[0151]
・ SetNotifyEntry ()
The syntax is OSStatus SetNotifyEntry (const OSServiceEntry & entry), which sets the entry for the observer to receive a NOTIFY message. This setting is made in DoInit (). The dummy argument is entry (entry for receiving a NOTIFY message). Return values include oSUCCESS (success) and other than the above (failure).
[0152]
・ GetID ()
The syntax is const ObserverID & GetID (void) const, which returns the observer's Observer ID. ObserverID takes a unique value for each observer. There are no dummy arguments. The return value is a value specific to each observer.
[0153]
・ SetBufCtrlParam ()
The syntax is void SetBufCtrlParam (size_t skip, size_t min, size_t max), and sets the necessary control parameters for the observer buffer held by the subject. This setting is made in DoInit ().
Formal arguments are skip (specify data skip (sampling interval) to reduce the number of data received. Default value is 0, no subsampling), min (subject sends NOTIFY message to observer) Specify the minimum number of data to be sent. The default value is set to 1. By setting this parameter appropriately, you can reduce the frequency of receiving data without losing data.), Max (Specifies the maximum buffer size for transmission that the subject must hold in the buffer before the observer enters the ASSERT-READY state. This parameter must be set to min or more. The default value is 1 In that case, only the data for the last transmission is held in the buffer. .) A. There is no return value.
[0154]
・ SetSkip ()
The syntax is void SetSkip (size_t skip), which sets the necessary control parameters for the observer buffer held by the subject. Make this setting at DoInit. This function is provided only for compatibility with the past, and performs the same operation as SetBufCtrParam (skip, 1,1). The dummy argument is skip (specify the data skip (sampling interval) to reduce the number of data to be received. The default value is 0, no subsampling). There is no return value.
[0155]
・ AssertReady ()
The syntax is OSStatus AssertReady (void), which sends an ASSERT-READY to all connected subjects. There are no dummy arguments. Return values include oSUCCESS (success) and other than the above (failure).
[0156]
・ AssertReady ()
The syntax is OSStatus AssertReady (const SubjectID & id), which sends an ASSERT-READY message only to the specified subject. The formal argument is id (ID of the message destination subject). The return value is oSUCCESS (success) and other than the above (failure).
[0157]
・ AssertReady ()
The syntax is OSStatus AssertReady (const SubjectInfo & info), which sends an ASSERT-READY message only to the specified subject. The dummy argument is info (ID information of the subject of the message transmission destination). Return values include oSUCCESS (success) and other than the above (failure).
[0158]
・ DeassertReady ()
The syntax is OSStatus DeassertReady (void), which sends a DEASSERT-READY message to all connected subjects. There are no dummy arguments. Return values include oSUCCESS (success) and other than the above (failure).
[0159]
・ DeassertReady ()
The syntax is OSStatus DeassertReady (const SubjectID & id), and sends the DEASSERT-READY message only to the specified subject. The formal argument is id (ID of the message destination subject). Return values include oSUCCESS (success) and other than the above (failure).
[0160]
・ DeassertReady ()
The syntax is OSStatus DeassertReady (const SubjectInfo & info), which sends a DEASSERT-READY message only to the specified subject. The dummy argument is info (ID information of the subject of the message transmission destination). Return values include oSUCCESS (success) and other than the above (failure).
[0161]
・ NumberOfSubjects ()
The syntax is int NumberOfObjects (void) const and returns the number of subjects connected to the observer. There are no dummy arguments. The return value is the number of subjects connected to the observer.
[0162]
・ Begin ()
The syntax is SubjectConstIterator begin (void) const, which returns an iterator pointing to the first subject in the list of subjects connected to the observer. There are no dummy arguments. The return value is an iterator pointing to the first subject.
[0163]
・ End ()
The syntax is: SubjectConstIterator end (void) const; which returns an invalid iterator pointing to the end of the list of subjects connected to the observer, after the last subject. There are no dummy arguments. The return value is an invalid iterator pointing to the end of the last subject.
[0164]
・ ConnectHandler ()
The syntax is void ConnectHandler (const OConnectMessage & msg, OSStatus status = oSUCCESS), and sets the observer according to the received OConnectMessage. Called on the connection face of the object. The dummy arguments are msg (OConnectMessage notified from OSServiceManager) and status (indicating the state of a user-defined initialization or resource securing function). The default value is oSUCCESS. Connection is rejected except for oSUCCESS. There is no return value.
[0165]
・ NotifyHandler ()
The syntax is void NotifyHandler (const OnNotifyMessage & msg, OnNotifyEvent * pEvent), which sets and initializes the NotifyEvent according to the received NotifyMessage. This function is called stub. Called automatically by cc. The formal parameters are msg (ONNotifyMessage received from the subject) and pEvent (pointer to ONNotifyEvent type data corresponding to the received ONNotifyMessage). There is no return value.
[0166]
2.4 OnNotifyEvent class
The OnNotifyEvent class has the following member functions.
・ ObsIndex ()
The syntax is int ObsIndex (void) const, which returns the index of the observer to which the OnNotifyEvent is sent. There are no dummy arguments. The return value is the index of the destination observer.
[0167]
・ SenderID ()
The syntax is const SubjectInfo & SenderID (void) const and returns the ID information of the subject that sent the OnNotifyEvent. There are no dummy arguments. The return value is the ID information of the source subject.
[0168]
・ NumOfData ()
The syntax is int NumOfData (void) const and returns the number of data received. There are no dummy arguments. The return value is the number of data received.
[0169]
・ NumOfNotify ()
The syntax is int NumOfNotify (void) const, which returns the number of times NotifyObserver () has been executed on the transmitted data. There are no dummy arguments. The return value is the number of times the subject has executed NotifyObserver ().
[0170]
・ Data ()
The syntax is const void * Data (int i) const and returns the address of the i-th data among the received data. This pointer is invalidated immediately upon sending an ASSERT-READY or DEASSERT-READY message to the subject. The formal argument is i (the index of the data to be processed). The return value is the start address of the i-th data.
[0171]
・ Data ()
The syntax is const void ** Data (void) const and returns an array of pointers to the data received. There are no dummy arguments. The return value is an array of pointers.
[0172]
・ RCData ()
The syntax is RCRegion * RCData (int i) const, which returns a pointer to the shared memory area with the reference counter corresponding to the i-th data among the received data. The dummy argument is i (the index of the data to be processed). The return value is a pointer to the shared memory area with the reference counter corresponding to the i-th data.
[0173]
2.5 RCRegion class
This class holds a pointer to the shared memory area and controls the memory area reference counter. RCRegion class has the following member functions. This class cannot be created on the stack.
・ RCRegion ()
The syntax is RCRegion (void), a constructor. Generate an instance that points to NULL. There are no dummy arguments or return values.
[0174]
・ RCRegion ()
The syntax is RCRegion (size_t size), which secures a shared memory area of the specified size and creates an instance pointing to this memory area. The dummy argument is size (size of shared memory to be allocated (unit is byte)), and has no return value.
[0175]
・ RCRegion ()
The syntax is RCRegion (MemoryRegionID memID, size_t offset, void * baseAddr = NULL, size_t size = 0), and creates an instance that points to the specified memory area. Since memory is not allocated, secure the corresponding memory area beforehand. Formal arguments are memID (ID of the shared memory area holding the data), offset (offset of baseAddr from the base address of the shared memory area specified by memID), baseAddr (base address of data (head address)), size (Data size) with no return value.
[0176]
・ ￣RCRegion ()
The syntax is $ RCRegion () and this function cannot be called directly. RCRegion is located on the heap, not on the local stack. The area cannot be destroyed. The reason is that this area may be referenced by others. The only thing you can do instead of calling the destructor is to call RCRegion :: RemoveReference (). There are no dummy arguments or return values.
[0177]
・ AddReference ()
The syntax is void AddReference (void), which increments the reference counter in a shared memory area with a reference counter. There are no dummy arguments or return values.
[0178]
・ RemoveReference ()
The syntax is void RemoveReference (void), which decrements the reference counter in the shared memory area with the reference counter. If all references to an area are lost, the area is automatically destroyed. If you are the area owner, the shared memory area is deleted. There are no dummy arguments or return values.
[0179]
・ NumberOfReference ()
The syntax is int NumberOfReference (void) const, which returns the number of reference counters. If the return value is 1, only the user is referring to the area, so the owner of the area can rewrite the data. If the return value is greater than 1, do not perform any operations other than reading. If the return value is 0, do not access because the area is destroyed. There are no dummy arguments. The return value is the number of the reference counter.
[0180]
・ Base ()
The syntax is char * Base (void) const. Returns the base address of the data stored in the shared memory area. There are no dummy arguments. The return value is the base address of the data held in the shared memory area.
[0181]
・ Size ()
The syntax is size_t Size (void) const, which returns the size of the data stored in the shared memory area. There are no dummy arguments. The return value is the size of the data held in the shared memory area.
[0182]
・ MemID ()
The syntax is MemoryRegionID MemID (void) const, which returns the ID of the shared memory area. There are no dummy arguments. The return value is the ID of the shared memory area.
[0183]
・ Offset ()
The syntax is size_t Offset (void) const, which returns the offset of the data area. The offset is the number of bytes from the base address obtained by the ID of the shared memory area to the start address of the data. There are no dummy arguments. The return value is the offset of the data area.
[0184]
・ SetSize ()
The syntax is void SetSize (size_t size), which sets the value returned by RCRegion :: Size () to the value of the dummy argument. This function is used when performing optimization by user-specific memory allocation processing. The dummy argument is size (same value as returned by RCRegion :: Size ()). There is no return value.
[0185]
・ ReserveSharedMemory ()
The syntax is OSStatus ReserveSharedMemory (size_t size), which is a static member function of the RCRegion class. This function is intended to avoid unexpected memory allocation at runtime. This function guarantees that at least the size bytes of the shared memory area are available for the libObjectComm library. If there is not enough shared memory at the time the function is called, the required memory will be allocated. The allocated shared memory area is used when executing SetData (ptr, size). You do not need to call this function when using SetData (region). The reason is that the SetData (region) function can freely control the generation timing of the RCRegion class. The dummy argument is size (the size reserved here as a memory area used when calling SetData (ptr, size)). Return values include oSUCCESS (success) and other than the above (failure).
[0186]
2.6 OShmPtrBase class
Base class for shared memory area. This class is a capsule class of RCRegion and performs automatic reference counting. The OShmPtrBase class has the following member functions.
・ OShmPtrBase ()
The syntax is OShmPtrBase (void), which generates an invalid OShmPtrBase. There are no dummy arguments or return values.
[0187]
・ OShmPtrBase ()
The syntax is OShmPtrBase (const OShmPtrBase & p), which generates an OShmPtrBase that refers to the same area as the specified OShmPtrBase. The dummy argument is p (OShmPtrBase of the copy source). There is no return value.
[0188]
・ OShmPtrBase ()
The syntax is OShmPtrBase (RCRegion * region), which generates an OShmPtrBase that refers to the specified area. The dummy argument is a region (a shared memory area with a reference counter). There is no return value.
[0189]
・ ￣OShmPtrBase ()
The syntax is $ OShmPtrBase (), which destroys OShmPtrBase and decrements the reference counter. There are no dummy arguments or return values.
[0190]
・ Operator = ()
The syntax is OShmPtrBase & operator = (const OShmPtrBase & p), and changes the reference destination so that it refers to the same area as the specified OShmPtrBase. The dummy argument is p (the copy source of OShmPtrBase), and the return value is * this.
[0191]
・ Deallocate ()
The syntax is void Deallocate (void), which decrements the reference counter and invalidates OShmPtrBase. There are no dummy arguments or return values.
[0192]
・ Base ()
The syntax is char * Base (void) const, which returns the base address of the data held in the shared memory area. There are no dummy arguments. The return value is the base address of the data held in the shared memory area.
[0193]
・ Size ()
The syntax is size_t Size (void) const, which returns the size of the data held in the shared memory area. There are no dummy arguments. The return value is the size of the data held in the shared memory area.
[0194]
・ MemID ()
The syntax is MemoryRegionID MemID (void) const, which returns the ID of the shared memory area. There are no dummy arguments. The return value is the ID of the shared memory area.
[0195]
・ Offset ()
The syntax is size_t Offset (void) const, which returns the offset of the data area. The offset is the number of bytes from the base address obtained by the ID of the corresponding shared memory area to the start address of the data. There are no dummy arguments. The return value is the offset of the data area.
[0196]
・ RCRPtr ()
The syntax is RCRegion * RCRPtr (void) const, which returns a pointer to the corresponding RCRegion. There are no dummy arguments. The return value is a pointer to the corresponding RCRegion.
[0197]
2.7 OShmPtr class
Pointer to the shared memory area. Unlike OShmPtrBase, this class is a template class. The OshmPtr class has the following member functions.
・ OShmPtr ()
The syntax is OShmPtr (void), which creates an invalid instance of type OShmPtr <T>. There are no dummy arguments or return values.
[0198]
・ OShmPtr ()
The syntax is OShmPtr (const OShmPtrBase & p), which creates an instance of the OShmPtr <T> type that refers to the area referenced by the specified OShmPtrBase. The dummy argument is p (OShmPtrBase of the copy source). There is no return value.
[0199]
・ OShmPtr ()
The syntax is OShmPtr (RCRegion * region), which creates an instance of OShmPtr <T> type that refers to the specified area. The dummy argument is a region (a pointer to a shared memory area with a reference counter). There is no return value.
[0200]
・ OShmPtr ()
The syntax is OShmPtr (size_tn), which secures a shared memory area of sizeof (T) * n and generates an array of n elements of OShmPtr <T>. This function internally calls Allocate (n). No constructor of type T is called. The dummy argument is n (the number of elements of the array of OShmPtr <T>), and there is no return number.
[0201]
・ ￣OShmPtr ()
The syntax is $ OShmPtr (), which destroys OShmPtr <T> and decrements the reference counter. There are no dummy arguments or return values.
[0202]
・ Operator = ()
The syntax is OShmPtr <T>& operator = (const OShmPtrBase & p), which changes the reference to the same area as the specified OShmPtrBase. The dummy argument is p (OShmPtrBase of the copy source). The return value is * this.
[0203]
・ Allocate ()
The syntax is void Allocate (int n), which secures a shared memory area of sizeof (T) * n, and allocates n elements and an array of type T. The newly created shared memory area is controlled by the reference counter. No constructor of type T is called. The dummy argument is n (the number of elements of the array of type T) and there is no return value.
[0204]
・ NumOfElement ()
The syntax is size_t NumOfElement (void) const and returns the maximum number of elements in the array. There are no dummy arguments. The return value is the number of elements in the array.
[0205]
・ Operator * ()
The syntax is const T & operator * (void) const, which returns a reference to the first element of the array. There are no dummy arguments. The return value is a reference to the first element of the array.
[0206]
・ Operator * ()
The syntax is OShmPtr <T> :: Proxy operator * (void), which returns the first element of the array. If an attempt is made to overwrite an element from another while this element is being referenced, the contents of the area that holds the element are copied to the newly allocated area, and the newly allocated area is overwritten. There are no dummy arguments. The return value is the first element, indicating the first element of the array.
[0207]
・ Operator [] ()
The syntax is const T & operator [] (int i) const and returns a reference to the ith element of the array. The dummy argument is i (the index of the element of the array). The return value indicates a reference to the ith element of the array.
[0208]
・ Operator [] ()
The syntax is OShmPtr <T> :: Proxy operator [] (int i), which returns the ith element of the array. If an attempt is made to overwrite an element from another while this element is being referenced, the contents of the area that holds the element are copied to the newly allocated area, and the newly allocated area is overwritten. The dummy argument is i (the index of the element of the array), and the return value is the i-th element of the array.
[0209]
・ Operator-> ()
The syntax is const T * operator-> (void) const, which returns a pointer to the first element of the array. There are no dummy arguments. The return value is a pointer to the first element of the array.
[0210]
Chapter 3 Services
3.1 OVirtualRobotComm
The service of OVirtualRobotComm will be described below.
-OVirtualRobotComm. Effector. OCommandVectorData. O
This service receives joint commands and LED commands. The data structure to receive is OCommandVectorData. OCommandVectorData secures shared memory using OPENR :: NewCommandVectorData (). When the output of the received OCommandVectorData is completed, READY EVENT is transmitted.
-OVirtualRobotComm. Sensor. OSsensorFrameVectorData. S
This service sends all sensor data that can be used by the robot. The data structure to be sent is OSensorFrameVectorData. Four frames (32 ms) of data are sent in one transmission.
-OVirtualRobotComm. FbkImageSensor. OFbkImageVectorData. S
This service sends camera image data. The data structure to send is OFbkImageVectorData. Three YCrCb images and one CDT image are sent as OFbkImage for accessing image data.
[0211]
3.2 OVirtualRobotAudioComm
Hereinafter, the service of OVirtualRobotAudioComm will be described.
-OVirtualRobotAudioComm. Mic. OSoundVectorData. S
This service transmits sound data from a microphone. Data is sent every 32ms. The sound data format is 16kHz, 16bit stereo PCM data.
-OVirtualRobotAudioComm. Speaker. OSoundVectorData. O
This service receives sound data. The structure of the data to be received is OsoundVectorData. OSoundVectorData secures a shared memory with OPENR :: NewSoundVectorData (). When the output of the received OSoundVectorData is completed, a READY EVENT is transmitted.
[0212]
Chapter 4 Data Types
4.1 Common header
・ ODataVectorInfo
ODataVectorInfo is an OCommandVectorData, an OSensorFrameVectorData, an OFbkImageVectorData, an OSoundVectorData, a header element of information about the size of the information element, a common element of the memory, and the number of data elements, a common element of the memory, and an information element of the data. The structure is shown below.

[0213]
The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
memRegionID: ID of the shared memory area holding the data
physAddr: Set to the physical address of the shared memory for OFbkImageVectorData and OSoundVectorData, and set to 0 for other data.
offset: offset
totalSize: size of shared memory holding data
type: Data type and corresponding data structure
The relationship between the type of data and the structure of this data is as follows.
[0214]
OCommandCOMMAND_VECTOR for OCommandVectorData
OsensorSENSOR_FRAME_VECTOR for OSensorFrameVectorData
For OFbImageImageVectorData, odataFBKIMAGE_VECTOR
OdataSOUND_VECTOR for OSoundVectorData
For OCdtVectorData, odataCDT_VECTOR
infoOffset: Offset from the start address of data to the array of element information blocks (192 bytes)
maxNumData: maximum number of elements of data that can be held
numData: number of valid data elements
syncKey: synchronization key
wait: Waits for command and sound output for the frame (8 msec) specified by wait.
optOffset: Offset of valid data in optional area
optSize: size of valid data in optional area
padding [3]: margin for adjusting the total number of bytes
optional [dataOPTION_MAX]: Used to transfer information between the object that sends OCommandVectorData and OSoundVectorData and the object that receives OSsensorFrameVectorData. The data specified by optionOffset and optionSize in the option [] data is updated, and the data is copied to option [] of OSoundFrameVectorData.
[0215]
4.2 Communication with OVirtualRobotComm
The following three data are used for communication with OVirtualRobotComm.
OCommandVectorData: Command data
OSensorFrameVectorData: Sensor data
OFbkImageVectorData: Image data
These data are created on shared memory. The content of each data is placed in the order of ODataVectorInfo of common header, array of information block of each element, and array of data body.
[0216]
4.2.1 OCommandVectorData
OCommandVectorData is a data structure that holds joint commands and LED commands. VectorInfo. is followed by vectorInfo. An array of OCommandInfo of maxNumData number and an array of OCommandData are arranged. The type of each command is specified by the type of OCommandInfo. A single OCommandVectorData can hold multiple different types of commands. The structure is as follows.

The header file is #include <OPENR / ODataFormats. h>.
[0219]
・ OCommandInfo
OCommandVectorData element type, OPrimitiveID, number of command frames,
Holds the offset to the command. The structure is shown below.

[0218]
The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
type: command type (dataJOINT_COMMAND2, dataLED_COMMAND2)
primitiveID: ID of CPC Primitive that specifies the command
frameNumber: The frame number at the time of processing the first frame of the command is stored.
numFrames: The number of valid frames of command data held by OCommandData. In OCommandData, only numFrames data of the maximum commandMAX_FRAMES (= 16) frames is processed.
The size of one frame of command data held by frameSize OCommandData (8 bytes)
dataOffset: Offset of OCommandData corresponding to OCommandInfo. Shows the offset from the start address of OCommandVectorData.
dataSize: Data size of OCommandData corresponding to OCommandInfo (128 bytes)
padding [1]: margin for adjusting the total number of bytes
[0219]
・ OCommandData
The body of command data. OCommandValue is a structure of general-purpose data for one frame. In the case of a joint command, cast to OJointCommandValue2, in the case of an ear plunger, to OJointCommandValue3, and in the case of an LED command, cast to OLEDCommandValue. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h> and the members are:
value [commandMAX_FRAMES]: Command data. OCommandData can hold data for a maximum of commandMAX_FRAMES (= 16) frames. The number of valid frames is specified by numFrames of OCommandInfo.
[0220]
・ OJointCommandValue2
OJointCommandValue2 is joint command data for one frame. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: the indicated value to the joint. The unit is microradian (10 ^-6 rad), which is 3141592 in the case of 360 °.
padding: space for adjusting the total number of bytes
[0221]
・ OJointCommandValue3
OJointCommandValue3 is command data of the plunger operation of the ear, and has the following structure.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: the indicated value of the plunger. Specify joint3-STATE0 or joint3-STATE1.
reserved: Reserved
padding: space for adjusting the total number of bytes
[0222]
・ OLEDCommandValue2
OLEDCommandValue2 is command data for controlling the LED. LED control is specified by ON, OFF and the time. The minimum unit of time that can control LED ON and OFF is 8 ms. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
led: Specify ON / OFF of LED. Specify oledON or oledOFF.
period: Specify the duration of the LED status. The minimum unit of time is 8 ms.
reserved: Reserved
[0223]
4.2.2 OSsensorFrameVectorData
A data structure that holds data for various sensors such as joints, acceleration sensors, and switches. VectorInfo. is followed by vectorInfo. The array of OSEncoderFrameInfo of the number of maxNumData and the array of OSensorFrameData are arranged. The type of each sensor data is specified by the type of OSsensorFrameInfo. One OSsensorFrameVectorData can hold multiple sensor data of different types. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>.
[0224]
・ OSensorFrameInfo
OSsensorFrameInfo holds the element type of OSsensorFrameVectorData, OPrimitiveID, the number of frames of sensor data, and the offset to sensor data. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
type: type of sensor data. A list of types can be found in ODataFormats. h.
PrimitiveID: ID number of CPC Primitive that obtained sensor data
frameNumber: the frame number of the corresponding OSsensorFrameData at the time of the first data acquisition
numFrames: Number of valid frames of sensor data held by OSsensorFrameData
frameSize: The size of sensor data for one frame held by OSsensorFrameData (16 bytes)
dataOffset: Offset of OSsensorFrameData corresponding to OSsensorFrameInfo. This is the offset from the start address of OSensorFrameVectorData.
dataSize: Data size of OSsensorFrameData corresponding to OSsensorFrameInfo (128 bytes)
padding [1]: margin for adjusting the total number of bytes
[0225]
・ OSensorFrameData
OSensorFrameData is the main body of sensor data. OSensorValue is a general-purpose data structure for one frame. Use by casting to various sensor data. For example, cast to OJointValue for joint data and OAcceleration for accelerometer. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h> and the members are:
frame [osensorframeMAX_FRAMES]: It is sensor data. OSsensorFrameData can hold data for a maximum of oscillatorframeMAX_FRAMES (= 16) frames. The number of valid frames is specified by numFrames of OSsensorFrameInfo.
[0226]
・ OAcceleration
OAcceleration is acceleration, and the unit is 10 ^-6 m / sec ² is. The structure is shown below.
[0227]

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: A value obtained by converting a signal value obtained from the acceleration sensor using a calibration table. The unit is 10 ^-6 m / sec ² is.
signal: AD signal value obtained from the acceleration sensor
padding [5]: margin for adjusting the total number of bytes
[0228]
・ OAngularVelocity
OAngularVelocity is an angular velocity, and the unit is 10 ^-6 rad / s. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: A value obtained by converting a signal value obtained from the angular velocity sensor using a calibration table. The unit is 10 ^-6 rad / s.
signal: AD signal value obtained from the angular velocity sensor
padding [5]: margin for adjusting the total number of bytes
[0229]
・ OTemperature
OTemperature is temperature, unit is 10 ^-6 ° C. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: A value obtained by converting a signal value obtained from the temperature sensor using a calibration table. The unit is 10 ^-6 ° C.
signal: AD signal value obtained from the temperature sensor
padding [5]: margin for adjusting the total number of bytes
[0230]
・ OForce
OForce is power, and the unit is 10 ^-6 N. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: A value obtained by converting a signal value obtained from the sensor using a calibration table. The unit is 10 ^-6 N.
signal: AD signal value obtained from the sensor
padding [5]: margin for adjusting the total number of bytes
[0231]
・ OPressure
OPressure is pressure, and the unit is 10 ^-6 Pa (N / m ² )is. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: A value obtained by converting a signal value obtained from the pressure sensor using a calibration table. The unit is 10 ^-6 Pa.
signal: AD signal value obtained from the pressure sensor
padding [5]: margin for adjusting the total number of bytes
[0232]
・ OLength
OLength is a length, and the unit is 10 ^-6 m. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: A value obtained by converting a signal value obtained from the sensor using a calibration table. The unit is 10 ^-6 m.
signal: AD signal value obtained from the sensor
padding [5]: margin for adjusting the total number of bytes
[0233]
・ OSswitchStatus
OSswitchStatus is the state of the switch. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: the state of the switch obtained by converting the AD signal value obtained from the switch. oswitchON or oswitchOFF.
signal: AD signal value obtained from the switch
padding [5]: margin for adjusting the total number of bytes
[0234]
・ OJointValue
OJointValue is a joint value, and the unit is 10 for a rotating joint. ^-6 rad. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
value: The value obtained by converting the joint feedback signal using the calibration table. The unit is 10 for a rotating joint. ^-6 rad.
signal: feedback signal of the joint
pwmDuty: PWM signal value
refValue: The indicated value at the time of sensor data acquisition. The unit is microradian.
refSignal: 10-bit value after calibration conversion
padding [1]: margin for adjusting the total number of bytes
[0235]
4.2.3 OFbkImageVectorData
OFbkImageVectorData is image data, and has the following structure.

The header file is #include <OPENR / ODataFormats. h>.
[0236]
・ OFbkImageInfo
OFbkImageInfo is image information and is a data structure that holds a YCrCb image and a CDT image. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h> and the members are:
type: data type. It is odataFBK_YCrCb or odataFBK_CDT.
PrimitiveID: PrimitiveID of FbkImageSensor to set image data
frameNumber: frame number at the time of image acquisition
dataOffset: Offset of the image data from the start address of the shared memory
dataSize: size of image data
width: number of horizontal pixels of image data
height: the number of vertical pixels of the image data
padding [1]: margin for adjusting the total number of bytes
[0237]
・ OFbkImage
OFbkImage is a class for accessing each Y, Cr, Cb, and CDT image of OFbkImageVectorData. The header file is #include <OPENR / OFbkImage. h>, and the library is libOPENR. a.
The syntax is OFbkImage (OFbkImageInfo * info, byte * data, OFbkImageBand band), which is a constructor of OFbkImage. For info and data, specify the pointer obtained from OFbkImageVectorData :: GetInfo () and OFbkImageVectorData :: GetData (). OFbkImageVectorData :: GetInfo (), if the argument of OFbkImageVectorData :: GetData () is ofbkimageLAYER_H, ofbkimageLAYER_M, of ofbkimageLAYER_L, specify ofbkimageBAND_Y, ofbkimageBAND_Cr, one of the ofbkimageBAND_Cb to the band. In the case of offbimageLAYER_C, specify offbimageBAND_CDT. Formal arguments are info (a pointer to OFbkImageInfo), data (a pointer to image data), and band (a band for image data).
[0238]
・ IsValid ()
The syntax is boolean IsValid (), which checks if OFbkImage is valid. False is returned when the constructor is called with an invalid formal parameter. There are no dummy arguments. Return values include true (valid) and false (invalid).
[0239]
・ Pointer ()
The syntax is byte * Pointer (), which returns a pointer to the image data. There are no dummy arguments. The return value is a pointer to the image data.
[0240]
・ Width ()
The syntax is int Width (), which returns the width of the image. There are no dummy arguments. The return value is the width of the image.
[0241]
・ Height ()
The syntax is int Height (), which returns the height of the image. There are no dummy arguments. The return value is the height of the image.
[0242]
・ Skip ()
The syntax is int Skip (), which returns the number of bytes to skip when advancing the pointer to the next line of image data. There are no dummy arguments. The return value is the number of skip bytes to the next line of the image data.
[0243]
・ Pixel ()
The syntax is byte Pixel (int x, int y), which returns the pixel value of the image data at coordinates (x, y). The origin of the coordinates is the upper left point. The temporary arguments are x (X coordinate of image data) and y (Y coordinate of image data). The return value is a pixel value of the image data at the coordinates (x, y).
[0244]
・ FieldCounter ()
The syntax is word FieldCounter (), and the counter number is described in the last line of the image data of each layer. The counter number is incremented for each image. FieldCounter () returns this counter number. There are no dummy arguments. The return value is a counter value of the image.
[0245]
・ ColorFrequency ()
The syntax is byte ColorFrequency (OCdtChannel chan), which describes the color frequency information of the number of pixels detected / 16 in the last line of the image data of each layer. ColorFrequency () returns this color frequency. The dummy argument is chan (CDT channel). The return value is the detected color frequency (number of pixels / 16).
[0246]
4.3 Communication with OVirtualRobotAudioComm
The data used for communication with the OVirtualRobotAudioComm is one of the “OSoundVectorData sound data”. Data is created on shared memory. The content of data is placed in the order of ODataVectorInfo of common header, array of information block of each element, and array of data body.
[0247]
4.3.1 OSoundVectorData
OSoundVectorData is a data structure that holds sound data. vectorInfo. followed by vectorInfo. OSNoundInfo array of maxNumData number and sound data byte string are arranged. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>.
[0248]
・ OSoundInfo
OSoundInfo is a data structure that holds information about sound data. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
type: data type. odataSOUND is entered.
PrimitiveID: ID number of CPC Primitive for inputting and outputting sound data. If you want to output sound, set the OPrimitiveID of the speaker. When inputting a sound, set the OPrimiveID of the microphone.
frameNumber: When outputting sound, the frame number when processing the frame of the first sound. When inputting sound, the frame number when inputting data.
frameSize: size of sound data for one frame
dataOffset: Offset to a byte string of sound data corresponding to OSoundInfo.
Indicates the offset from the start address of OSoundVectorData.
maxDataSize: maximum size of a byte string of sound data corresponding to OSoundInfo
dataSize: The size of a valid sound data byte string
format: sound data format. Currently, only soundformatPCM is supported.
channel: number of sound data channels
samplingRate: sampling rate
bitsPerSample: the number of bits per sample of sound data
actualDataSize: The size of sound data transferred from the device.
padding [6]: margin for adjusting the total number of bytes
[0249]
4.4 Other
In addition, there is “OCdtVectorData CDT table data”. This data is created on shared memory. The content of data is placed in the order of ODataVectorInfo of common header, array of information block of each element, and array of data body.
[0250]
4.4.1 OCdtVectorData
OCdtVectorData is a data structure that holds the color detection table. A table of maximum octtNUM_CHANNELS (= 8) can be stored. Specify the number of valid OCdtInfo in ODataVectorInfo :: numData. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>.
[0251]
・ OCdtInfo
The color detection table divides Y (luminance signal) into 32 segments, and specifies Crmax, Crmin, Cbmax, and Cbmin for each segment. The values of Cr and Cb are offset binary and can be specified in the range of 0x0 to 0xff. The structure is shown below.

The header file is #include <OPENR / ODataFormats. h>, and the members include the following.
type: data type. odataCDT is included.
primitiveID: PrimitiveID of OFbkImageSensor setting CDT
channel: CDT channel for setting the table
table [octdtMAX_Y_SEGMENT]: array of table data
padding: space for adjusting the total number of bytes
[0252]
Chapter 5 OPEN-R API
The OPEN-R API is shown below.
・ OPENR :: OpenPrimitive ()
The syntax is OSStatus OPENR :: OpenPrimitive (const char * locator, OPrimitiveID * primitiveID), which opens the CPC Primitive and gets the OPrimitiveID. If it fails, primitiveID_UNDEF is returned to primitiveID. The dummy arguments are a locator (CPC Primitive Locator) and a primitive ID (CPC Primitive ID). Also, return values are oSUCCESS (success), oNOT_FOUND (there is no CPC Primitive corresponding to the locator), oOPEN_FAILURE (failed to open the CPC Primitive), oINVALID_ARG (locator is NULL pointer), and oFA where the locator is NULL pointer.
[0253]
・ OPENR :: ClosePrimitive ()
The syntax is OSStatus OPERN :: ClosePrimitive (OPrimitiveID primitiveID), which closes the CPC Primitive. Return values include oSUCCESS (success) and oINVALID_PRIMITIVE_ID (illegal primitiveID).
[0254]
・ OPENR :: ControlPrimitive ()
The syntax is OSStatus OPENR :: ControlPrimitive (OPprimitiveID primitiveID, OPlimitiveRequest request, void * param, size_paramSize, void_resize, and size_resize_resize). param, paramSize, result, and resultSize are specified by request. If there is no need to specify, specify 0. The following are the types of requests.
oprmreqSPEAKER_MUTE_ON
oprmreqSPEAKER_MUTE_OFF
oprmreqMIC_UNI
oprmreqMIC_OMNI
oprmreqMIC_ALC_ON
oprmreqMIC_ALC_OFF
oprmreqCAM_SET_WHITE_BALANCE
oprmreqCAM_SET_GAIN
oprmreqCAM_SET_SHUTTER_SPEED
[0255]
Also, set as follows.
/ * Mute ON * /
OPENR :: ControlPrimitive (speakerID, opermreqSPAKEER_MUTE_ON, 0,0,0,0);
/ * Mute OFF * /
OPENR :: ControlPrimitive (speakerID, oprmreqSPEAKE_MUTE_OFF, 0,0,0,0);
/ * UNI MIC * /
OPENR :: ControlPrimitive (micID, oprmreqMIC_UNI, 0, 0, 0, 0);
/ * OMNI MIC * /
OPENR :: ControlPrimitive (micID, prmreqMIC_OMNI, 0, 0, 0, 0);
/ * ALC ON * /
OPENR :: ControlPrimitive (micID, oprmreqMIC_ALC_ON, 0, 0, 0, 0);
/ * ALC OFF * /
OPENR :: ControlPrimitive (micID, oprmreqMIC_ALC_OFF, 0, 0, 0, 0);
/ * White balance setting * /
OPrimitiveControl_CameraParam wb (ocamparamWB_OUTDOOR_MODE);
OPENR :: ControlPrimitive (prmID, prmreqCAM_SET_WHITE_BALANCE, & wb, sizeof (wb), 0, 0);
/ * Camera gain * /
OPrimitiveControl_CameraParam gain (ocamparamGAIN_MID);
OPENR :: ControlPrimitive (prmID, oprmreqCAM_SET_GAIN, & gain, sizeof (gain), 0, 0);
/* shutter speed */
OPrimitiveControl_CameraParam shutter (ocamparam SHUTTER_FAST);
OPENR :: ControlPrimitive (prmID, prmreqCAM_SET_SHUTTER_SPEED, & shutter, sizeof (shutter), 0, 0);
[0256]
The formal arguments are primitiveID (OPrimitiveID), request (control request), param (parameter data), paramSize (parameter data size), result (result data), and resultSize (result data size). Return values include oSUCCESS (success), oINVALID_PRIMITIVE_ID (illegal primitiveID), and oINVALID_ARG (illegal request, param).
[0257]
-OPENR :: NewCommandVectorData ()
The syntax is OSStatus OPERN :: NewCommandVectorData (size_t numCommands, MemoryRegionID * memID, OCommandVectorData ** baseAddr), and secures the OCommandMemory for the sharedCommand memory. vectorInfo. numData is initialized to 0. Set the number of valid elements using SetNumData (). The dummy arguments are numCommands (the number of elements of OCommandData), memID (MemoryRegionID of the shared memory of OCommandVectorData), and baseAddr (pointer to the OCommandCommandData for the OCommandCommandData). ).
[0258]
-OPENR :: DeleteCommandVectorData ()
The syntax is OSStatus OPERN :: DeleteCommandVectorData (MemoryRegionID memID), which releases the shared memory of OCommandVectorData. The formal argument is memID (MemoryRegionID of the shared memory of OCommandVectorData). Return values include oSUCCESS (success) and oFAIL (failure).
[0259]
-OPENR :: NewSoundVectorData ()
The syntax is OSStatus NewSoundVectorData (size_t numSounds, size_t dataSize, MemoryRegionID * memID, OSoundVectorData ** baseAddr is the memory that is shared with the DataAddr). vectorInfo. numData is initialized to 0. Set the number of valid elements using SetNumData ().
The dummy arguments are numSounds (number of elements of audio data), dataSize (size of each audio data), memID (MemoryRegionID of the shared memory of OSoundVectorData), and baseAddr (pointer to OSoundVectorData). Return values include oSUCCESS (success) and oNO_MEMORY (failure to secure shared memory).
[0260]
-OPENR :: DeleteSoundVectorData ()
The syntax is OSStatus DeleteSoundVectorData (MemoryRegionID memID), which releases the shared memory of OSoundVectorData. The formal argument is memID (MemoryRegionID of the shared memory of OSoundVectorData), and return values include oSUCCESS (success), oINVALID_ARG (invalid memID), and oFAIL (failure).
[0261]
-OPENR :: NewCdtVectorData ()
The syntax is OSStatus NewCdtVectorData (MemoryRegionID * memID, OCdtVectorData ** baseAddr), which secures the shared memory of OCdtVectorData. vectorInfo. numData is initialized to 0. Set the number of valid elements using SetNumData (). The dummy arguments are memID (MemoryRegionID of the shared memory of OCdtVectorData) and baseAddr (pointer of OCdtVectorData). Return values include oSUCCESS (success) and oNO_MEMORY (failure to secure shared memory).
[0262]
-OPENR :: DeleteCdtVectorData ()
The syntax is OSStatus DeleteCdtVectorData (MemoryRegionID memID), which releases the shared memory of OCdtVectorData. The dummy argument is memID (MemoryRegionID of the shared memory of OCdtVectorData), and return values include oSUCCESS (success) and oFAIL (failure).
[0263]
-OPENR :: SetCdtVectorData ()
The syntax is OSStatus SetCdtVectorData (MemoryRegionID memID) and sets OCdtVectorData to FbkImageSensor. The dummy argument is memID (MemoryRegionID of the shared memory of OCdtVectorData), and the return value is oSUCCESS (success), oINVALID_ARG (invalid OCdtInfo :: channel), oINVALID_PRIMIVEVITID_itDATA is not validVIDAVALID_iDATAVID_IDVIDAIVAL_IDVIDAIVALID_iVIPIDVITEID_valid_valid_VIPIDVID_VID_IDVID_VID_IDVIDIDVID_VID_IDVIDIDVITAIDVIDIDVIDIDVITID_IDVIDIDVIDIDVIDIDVIDIDVITIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDIDVIDID_IDVIDID_IDVIDID is not a valid parameter. .) And oFAIL (failures other than the above).
[0264]
-OPENR :: EnableJointGain ()
The syntax is OSStatus EnableJointGain (OPrimitiveID primitiveID), which enables the joint gain. When OPENR :: SetJointGain () or OPENR :: SetDefaultJointGain () is executed while the gain is valid, the PID gain is set to the servo device. If you specify primitiveID_UNDEF for primitiveID, the gain of the joint opened by OPENR :: OpenPrimitive () will be enabled. The formal argument is primitiveID (OPrimitiveID or jointID_UDEF of the joint). Also, return values include oSUCCESS (success), oINVALID_PRIMITIVE_ID (incorrect primitiveID), and oALERT_JOINT_UNCONTROLLLABLE (potential is disconnected and cannot be controlled).
[0265]
・ OPENR :: DisableJointGain ()
The syntax is OSStatus DisableJointGain (OPrimitiveID primitiveID), which sets the joint gain to 0 and disables the gain. If "primitiveID" is specified as "primitiveID_UNDEF", the gain of the Joint opened by OPENR :: OpenPrimitive () is set to 0, and the gain is invalidated. The dummy argument is a primitiveID (OPprimitiveID or primitiveID_UDEF of the joint). Return values include oSUCCESS (success), oINVALID_PRIMIVEIVE_ID (incorrect primitiveID), and oFAIL (failure).
[0266]
-OPENR :: SetJointGain ()
The syntax is OSStatus SetJointGain (OPprimitiveID primitiveID, word pg, word ig, word dg, word ps, word is, word ds) and sets the joint gain. If the gain is invalid, oGAIN_DISABLED is returned without setting the gain. When primitiveID_UNDEF is specified for primitiveID, the gain of all joints for which OPENR :: OpenPrimitive () is open is set. Returns oSUCCESS if the joint gain setting is successful. The formal arguments are primitiveID (OPrimitiveID or primitiveID_UDEF of the joint), pg (PGAIN coefficient), ig (IGAIN coefficient), dg (DGAIN coefficient), ps (PSHIFT coefficient), is (ISHIFT coefficient), and ds (DSHIFT coefficient). . Return values include oSUCCESS (success), oINVALID_PRIMIVEIVE_ID (primitiveID is invalid), oGAIN_DISABLED (gain invalid state), oALERT_JOINT_UNCONTROLLABLE (potential is disconnected and cannot be controlled), and oFAIL (failure).
[0267]
-OPENR :: RegisterDefaultJointGain ()
The syntax is OSStatus RegisterDefaultJointGain (OPrimitiveID primitiveID, word pg, word ig, word dig, word ps, word is, word ds). If you specify primitiveID_UNDEF for primitiveID, the default gain is registered to all joints opened with OPENR :: OpenPrimitive (). The dummy arguments are: primitiveID (OPrimitiveID or JointID_UDEF of Joint), pg (PGAIN coefficient), ig (IGAIN coefficient), dg (DGAIN coefficient), ps (PSHIFT coefficient), is (ISHIFT coefficient), and ds (DSHIFT coefficient). . The return value is oSUCCESS (success), oINVALID_PRIMITIVE_ID (illegal primitiveID).
[0268]
-OPENR :: SetDefaultJointGain ()
The syntax is OSStatus SetDefaultJointGain (OPrimitiveID primitiveID), which sets the registered default gain for the joint. If the gain is invalid, oGAIN_DISABLED is returned without setting the gain. Specifying primitiveID_UNDEF for primitiveID sets the gain of all joints opened with OPENR :: OpenPrimitive (). Returns oSUCCESS if the joint gain setting is successful.
The dummy argument is a primitiveID (OPrimitiveID or JointID_UDEF of a Joint), and return values are oSUCCESS (success), oINVALID_PRIMITIVE_ID (invalid primitiveID, and LINEACTION_BREAKLINE_ERROR). , OFAIL (failure).
[0269]
-OPENR :: GetJointValue ()
The syntax is OSStatus GetJointValue (OpriitiveID primitiveID, OJointValue * value), which gets the current value of the Joint. The formal arguments are primitiveID (OPrimitiveID of the joint) and value (current value of the joint). Return values include oSUCCESS (success) and oINVALID_PRIMITIVE_ID (illegal primitiveID).
[0270]
・ OPENR :: GetSensorValue ()
The syntax is OSStatus GetJoinValue (OpriitiveID primitiveID, OSensorValue * value), which gets the current value of the sensor. The formal arguments are primitiveID (OPrimitiveID of the sensor) and value (current value of the sensor). Return values include oSUCCESS (success) and oINVALID_PRIMITIVE_ID (illegal primitiveID).
[0271]
・ OPENR :: NewSyncKey ()
The syntax is OSStatus OPERN :: NewSyncKey (OVRSyncKey * syncKey), which is used to synchronize the LED, sound, and motion at the start. The synchronization key is issued by OPENR :: NewSyncKey (), and the number of objects is used by dividing the number of objects by using OPENR :: DivisionSyncKey (). The maximum number of synchronization keys is eight. If the number exceeds the maximum number, syncKey contains ovrsynckey UNDEF and returns oNO_SYNC_KEY. The dummy argument is a syncKey (synchronization key). Return values include oSUCCESS (success) and oNO_SYNC_KEY (up to eight synchronization keys have been issued).
[0272]
-OPENR :: CancelSyncKey ()
The syntax is OSStatus OPENR :: CancelSyncKey (OVRSyncKey syncKey), which cancels the synchronization key. The dummy argument is syncKey (synchronization key), and return values include oSUCCESS (success) and oINVALID_SYNC_KEY (invalid syncKey).
[0273]
-OPENR :: DividSyncKey ()
The syntax is OSStatus OPENR :: DividSyncKey (OVRSyncKey syncKey, OVRSyncKey * key1, OVRSyncKey * key2), which divides the synchronization key. The dummy arguments are syncKey (a synchronization key before division), key1, and key2 (a synchronization key after division). Return values include oSUCCESS (success) and oFAIL (failure).
[0274]
・ OPENR :: SetMotorPower ()
The syntax is OSStatus OPERN :: SetMotorPower (OPower power), which controls the motor power. Specify "powerON" or "powerOFF" for "power". The dummy argument is power (powerON or powerOFF). Return values include oSUCCESS (success) and oFAIL (failure).
[0275]
・ OPENR :: Shutdown ()
The syntax is OSStatus OPERN :: Shutdown (const OBootCondition & bootCondition), which sets the specified bootCondition and starts the shutdown process. The dummy argument is bootCondition (boot condition), and return values include oSUCCESS (success), oFAIL (failure), and oNOT_FOUND (system object does not exist).
[0276]
・ OPENR :: GetBootCondition ()
The syntax is OSStatus OPERN :: GetBootCondition (OBootCondition * bootCondition), and gets the activation factor.

Here, the activation factor is stored in bitmap. bootTime, batteryCapacityLow, and vibrationLevel will be 0. The types of activation factors are as follows.
obcbBOOT_TIMER = 0x0001; activated in time
obcbVIBRATION_DETECTED = 0x0002; start by vibration
obcbPAUSE_SW = 0x0004; activated by pause button
obbcbSTATION_CONNECTED = 0x0008; Starts with station connection
obbcSTATION_DISCONNECTEDD = 0x0010; When station is disconnected
obcbBATTERY_CAPACITY_FULL = 0x0020; charging completed
obcbREQ_FROM_STATION = 0x0040; future use
The formal argument is bootCondition (startup factor), and return values include oSUCCESS (success), oFAIL (failure), and oNOT_FOUND (system object does not exist).
[0277]
・ OPENR :: GetPowerStatus ()
The syntax is OSStatus OPENR :: GetPowerStatus (OPPowerStatus * powerStatus), and gets the power status defined by the following structure.

Use the following units.
remainingCapacity: Remaining battery capacity (1% / bit, 0-100%)
temperature: battery temperature (0.1 Kelvin / bit, 0-500.0 Kelvin)
fullyChargedCapacity: Capacity at full charge (mAh)
voltage: battery voltage (1 mV / bit, 0-65535 mV)
current: battery current (1 mA / bit, -32768-32767 mA)
timeDif: Time difference from UTC (Universal Coordinated Time)
volume: any of volume 0, 1, 2, 3
The formal argument is powerStatus (power status), and return values include oSUCCESS (success), oFAIL (failure), and oNOT_FOUND (system object does not exist).
[0278]
-OPENR :: ObservePowerStatus ()
The syntax is OSStatus OPERN :: ObservePowerStatus (const OPowerStatus & notifyStatus, const OSServiceEntry & entry), and if there is a change in the parameter specified in notifyStatus, the entry specified in notifyStatus will be changed. Of the NotifyStatus, fullyChargedCapacity, voltage, and current cannot be monitored for changes. robotStatus and batteryStatus are notified if the specified bit is changed. In addition, regarding the remaining capacity, temperature, timeDif, and volume, see OPower. The following symbolic constants are defined in h, opso * _NOTIFY_EVERY_CHANGE will notify you if there is a change, opso * _NOT_NOTIFY will not notify you, and other values will notify you when the specified value is reached. The structure of the notified message is OPowerStatusMessage.
[0279]
OPower. Symbolic constants defined by h include:
const word opsoTEMPERATURE_NOTIFY_EVERY_CHANGE = 0xFFFF;
const word opsoTEMPERATURE_NOT_NOTIFY = 0xFFFE;
const word opso REMAINING_CAPATY_NOTIFY_EVERY_CHANGE = 0xFFFF;
const word opso REMAINING_NOT_NOTIFY = 0xFFFE;
const byte opsoTIME_DIF_NOTIFY_EVERY_CHANGE = 0xFF;
const byte opsoTIME_DIF_NOT_NOTIFY = 0xFE;
const byte opsoVOLUME_NOTIFY_EVERY_CHANGE = 0xFF;
const byte opsoVOLUME_NOT_NOTIFY = 0xFE;
[0280]
Once ObservePowerStatus () is executed, it will be notified when the specified notifyStatus is reached until OPENR :: UnobservePowerStatus () is executed. For each bit of robotStatus and batteryStatus of notifyStatus, notify is notified at both rising and falling edges. For retainingCapacity, temperature, timeDif, and volume, you will be notified when the value is changed or when it reaches the specified value. If you specify a value, you will be notified when that value is reached, and you will not be notified if you change from that value. Also, you will not be notified if the specified value is not changed.
[0281]
Here, the formal arguments are notifyStatus (an OPowerStatus structure specifying a parameter for which a change is to be notified) and entry (an entry for which a change is notified), and return values include oSUCCESS (success), oFAIL (failure), and There is oNOT_FOUND (the system object does not exist).
[0282]
-OPENR :: UnobservePowerStatus ()
The syntax is OSStatus OPENR :: UnobservPowerPowerStatus (const OSServiceEntry & entry), which cancels the monitoring request of OPENR :: ObservePowerStatus (). The formal argument is entry (entry for canceling the monitoring request). Return values include oSUCCESS (success), oFAIL (failure), oNOT_FOUND (system object does not exist), and oINVALID_ARG (invalid entry).
[0283]
-OPENR :: FindDesignData ()
The syntax is OSStatus OPENR :: FindDesignData (const char * keyword, ODesignDataID * dataID, byte ** data, size_t * size), which is a file corresponding to the keyword in the design database. If found, read it to shared memory and return ODesignDataID and start address. Calling the argument with the reserved keyword “SYS_CPUINFO” allows you to obtain the operating frequency of the CPU. Returns the start address of OCPUInfo. This keyword 'SYS_CPUINFO' is assigned to DESIGNDB. It can be used even if it is not registered in CFG.

The formal arguments are keyword (keyword for searching the design database), dataID (design data ID), data (head address of design data), and size (size of design data), and the return value is oSUCCESS (success). , ONOT_FOUND (keyword or design data entity does not exist), oDESSIGNDATA_SIZE_ZERO (design data file size is 0), oNO_MEMORY (insufficient memory), and oFAIL (failure).
[0284]
-OPENR :: DeleteDesignData ()
The syntax is OSStatus OPENR :: DeleteDesignData (ODeignDataID dataID), which releases the memory for design data. The temporary argument is dataID (ID of design data). Return values include oSUCCESS (success), oINVALID_ARG (incorrect dataID), and oFAIL (failure).
[0285]
-OPENR :: GetRobotDesign ()
The syntax is OSStatus OPERN :: GetRobotDesign (char * robotDesign) and gets the robot design. The dummy argument is robotDesign (robot design). Return values include oSUCCESS (success) and oFAIL (failure).
[0286]
・ OPENR :: GetMemoryStickStatus ()
The syntax is OSStatus OPENR :: GetMemoryStickStatus (OMMemoryStickStatus * status), which checks the status of the memory stick. If the memory stickNOT_EXIST, it indicates that there is no memory stick. If it is memory stick WRITE_PROTECTED, it indicates that the write protect switch is ON. If the memory stick is WRITE WRITE, it indicates that the write protect switch is OFF. The dummy argument is status (memory stick state). Return values include oSUCCESS (success) and oFAIL (failure).
[0287]
・ OPENR :: Fatal ()
The syntax is OSStatus OPENR :: Fatal (OFal fatal). The buzzer of the BMN microcomputer sounds a warning sound before turning off the power. Specify the type of warning sound with fatal. The dummy argument is fatal (a type of warning sound. Currently, only officialMEMORY_STICY is supported.), OfficialUNDEF indicates Toccata and Fugue, oftalMEMORY_STICK is a memory stick destruction error sound, and officialPAUSE_SW is silent. is there. The return value is oSUCCESS (success).
[0288]
・ OPENR :: SetTime ()
The syntax is OSStatus OPERN :: SetTime (const OTime & time), which sets the RTC time to the time specified by time. If time is a value between -12 and +12 and a time difference that is different from the current time difference is set, the time difference is also set in the BMN microcomputer. The dummy argument is time (time and time difference). Return values include oSUCCESS (success), oFAIL (failure), and oNOT_FOUND (system object does not exist).
[0289]
・ OPENR :: GetTime ()
The syntax is OSStatus OPERN :: GetTime (OTTime * time), which gets the time and time difference. The dummy argument is time (a structure of time and time difference). Return values include oSUCCESS (success), oFAIL (failure), and oNOT_FOUND (system object does not exist).
[0290]
-OPENR :: SetTimeDifference ()
The syntax is OSStatus OPERN :: SetTimeDifference (sbyte timeDifference), which sets the time difference. The formal argument is timeDifference (time difference), and return values include oSUCCESS (success), oFAIL (failure), and oNOT_FOUND (system object does not exist).
[0291]
-OPENR :: GetTimeDifference ()
The syntax is OSStatus OPERN :: GetTimeDifference (sbyte * timeDifference) and gets the time difference. The formal argument is timeDifference (time difference), and return values include oSUCCESS (success), oFAIL (failure), and oNOT_FOUND (system object does not exist).
[0292]
・ OPENR :: SetVolumeSwitch ()
The syntax is OSStatus SetVolumeSwitch (OVolumeSwitch volSW), which sets the volume switch level. The formal argument is volSW (volume switch level), and there are ovolSW0, ovolSW1, ovolSW2, and ovolSW3. The return values are oSUCCESS (success) and oFAIL (failure).
[0293]
・ OPENR :: GetVolumeSwitch ()
The syntax is OSStatus GetVolumeSwitch (OVolumeSwitch * volSW), which gets the level of the volume switch. The formal argument is volSW (volume switch level), and there are ovolSW0, ovolSW1, ovolSW2, and ovolSW3. Return values include oSUCCESS (success) and oFAIL (failure).
[0294]
<Internet Protocol>
Next, I will explain the Internet Protocol Version 4 (IPv4) implemented in OPEN-R that is running OPEN-R 1.1.3. This version of IPv4 includes the client side of four network protocols: TCP, UDP, IP and DNS. This book is composed of two parts: IPv4 Programmer's Guide and IPv4 Reference Guide.
The IPv4 Programmer's Guide is an introduction to networking on OPEN-R and the IPv4 protocol stack. Details how the OPEN-R object uses TCP, UDP, DNS, and IP services in the stack. Also, the IPv4 Reference Guide is a detailed description of all classes and messages, errors and operations. These are needed when writing objects that communicate with the IPv4 protocol stack.
[0295]
In the following description, the OPEN-R object is simply called an object. If the remote side is not OPEN-R in communication, for example, in the case of Unix, it is more appropriate to call it a process instead of an object, but here the term object is used collectively.
[0296]
IPv4 Programmer's Guide
Chapter 1 IPv4 Protocol Stack
This chapter describes each protocol included in the current version of the IPv4 protocol stack, introduces IPStack, an implementation on OPEN-R, and describes how to communicate between objects and the protocol stack.
[0297]
1.1 Protocol of IPv4 protocol stack
Internet Protocol (IP) is a protocol for data transmission between hosts used on the Internet. IP version 4 (IPv4) is currently the most widely used and is available on OPEN-R. The IPv4 protocol stack on OPEN-R contains several protocols that supplement the basic IP protocol. The current version of the IPv4 protocol stack includes the following protocols:
[0298]
(1) IP (Internet Protocol): A basic protocol that plays a role in transmitting datagrams over the Internet. A packet-oriented, connectionless protocol that transfers IP datagrams without guaranteeing reliability.
[0299]
(2) TCP (Transmission Control Protocol): Operates on the IP protocol. Provides connection-oriented and reliable byte stream services for objects.
[0300]
(3) UDP (User Datagram Protocol): Operates on the IP protocol. Provides an unreliable datagram delivery service for an object.
[0301]
(4) DNS (Domain Name System): A service that maps a domain name to an IP address or an IP address to a domain name.
[0302]
1.2 IPv4 protocol stack
In OPEN-R, the IPv4 protocol stack is implemented using Aperios Networking Toolkit (ANT). At runtime, the protocol stack resides in the IPStack, which also contains the ANT runtime environment. IPStack is an object of the OPEN-R system layer. IPStack also communicates with objects and device drivers using message passing. FIG. 17 below shows a network service of IPStack on OPEN-R.
[0303]
1.3 How objects communicate with the protocol stack
Objects can use the network services provided by the IPv4 protocol stack. Objects communicate with the protocol stack by sending and receiving special messages to and from IPStack using normal message passing. The first thing the object does is ask the IPStack to create an endpoint. An endpoint is a special ANT construct at the top of the protocol stack, responsible for communication between objects and the stack. Objects typically require one endpoint per network connection. For example, an object that sends data over a TCP connection and a UDP connection requires two endpoints (see Figure 18). The same is true for sending data over two TCP connections, where an object requires two endpoints. We will see later how to create a new endpoint. FIG. 18 illustrates how an object sends a network service request to an endpoint of the IP stack and uses the endpoint to access the IPv4 protocol stack.
[0304]
In addition to endpoints, objects create one or more shared memory buffers. Shared memory buffers are required for data exchange between objects and the IPv4 protocol stack. Objects and protocol stacks do not necessarily share the same address space, so pointers to the data to be transferred cannot be exchanged. The shared memory buffer implemented by the AntSharedBuffer structure maps a common memory area into the address space of the two objects. The method of creating a shared memory buffer is described later. All messages sent to IPStack inherit from the antEnvMsg structure. This structure provides basic message handling functions such as Send () and Call (). Each service performed by the protocol has a specific inherited message type. For example, a request to send data using TCP is created by TCPEndPointSendMsg, and a request to bind a UDP connection is created by UDPEndPointBindMsg.
[0305]
Create a new endpoint
To create a new endpoint for any protocol in the IP stack, the object sends antEnvCreateCreateEndpointMsg to IPStack. The object specifies the type of protocol that requires the endpoint and the amount of memory allocated to the SDU pool of the endpoint in antEnvCreateEndpointMsg. IPStack creates a new endpoint for the specified protocol and returns a result message of antEnvCreateEndpointMsg. The ModuleRef dummy argument in this message contains a reference to the new endpoint. In the following example, the object creates a new TCP endpoint. This method is exactly the same for other protocols of IPStack, except that the objects specify different types of endpoints.
[0306]
First, the object creates a message requesting a new TCP endpoint as follows:

At this time, the following endpoint types can be used.
EndpointType_TCP
EndpointType_UDP
EndpointType_DNS
EndpointType_IP
The object in this example requests an SDU pool that is four times the packet size (4 * PACKETSIZE). The SDU pool is an internal ANT structure that stores data in the protocol stack. As a guide, it is preferable to always create an SDU pool that is slightly larger than the largest packet you are trying to send. For example, for an 8 KB packet, an SDU pool of about 10 KB is required.
[0307]
The object sends a message to IPStack.

Call () is inherited from antEnvMsg. Specify antStackRef (IPStackRef) indicating IPStack and message size. Call () performs synchronous message passing, so the object suspends operation until it receives a result message. Upon receiving the result message, the object gets a reference to the new endpoint.
[0308]
endpoint = createMsg. moduleRef;
This reference allows the object to communicate with the new endpoint. Objects can send messages to endpoints requesting services such as connection, listen, send, receive, and close provided by the TCP protocol. Other protocols offer different services.
[0309]
Create a shared memory buffer
The shared memory buffer is implemented by the antSharedBuffer structure. This buffer maps the shared memory area into the object and protocol stack address space. When an object exchanges data with the protocol stack, that data is identified by a pointer to a shared buffer and an offset into the buffer. antSharedBuffer automatically translates this offset to a location in the object's address space, as shown in Figure 19. FIG. 19 shows how the shared memory buffer maps the memory area to the address space of the object and the protocol stack. This allows the exchange of pointers to data. An object can create a single shared buffer or multiple buffers for a particular operation, such as sending or receiving data.
[0310]
Allocating and freeing shared buffers is done by shared memory management routines. These routines take a long time to execute. Therefore, create and delete shared buffers only when necessary, and reuse existing buffers whenever possible. Typically, you create a send buffer and a receive buffer for each new endpoint, and reuse the buffer for subsequent send and receive operations on the endpoint. There are some restrictions on the size of the shared buffer. Usually, the requested size is rounded up to the nearest multiple of the page size on OPEN-R. The OPEN-R page size is 4096 bytes in the memory protection mode. For example, if you request a 7000 byte shared buffer, the buffer will be 8192 bytes (4096 * 2). There are many uses for shared buffers, but each object's needs determine how it is used.
[0311]
To create a shared buffer, the object sends antEnvCreateSharedBufferMsg to IPStack, specifying the size of the buffer. At this time, IPStack creates a shared buffer and returns a reply to antEnvCreateSharedBufferMsg. The reference to the new antSharedBuffer is stored in the buffer dummy argument of the result message. The object then calls antSharedBuffer :: Map () to map the buffer into its address space. For more information about antEnvCreateSharedBufferMsg and antSharedBuffer, see "Chapter 6 ANT Environment Reference."
[0312]
In the following example, the TCP client object creates two shared buffers. One is for data transmission and the other is for data reception. First, the object creates a message requesting a new shared buffer.
antEnvCreateSharedBufferMsg bufferMsg (PACKETSIZE);
The specified buffer size is the same as the bucket size. This is because the data exchange between the object and the protocol stack is done one packet at a time. As a guide, a shared memory buffer should hold the largest packet an object sends or receives.
[0313]
Here, the object sends a message to IPStack.

Call () is inherited from antEnvMsg. AntStackRef (IPStackRef) that points to IPStack and message size are specified. Call () performs synchronous message passing, so the object suspends operation until it receives a result message. When the object receives a reply, it gets a reference to the new shared buffer and defines it as a send buffer.
sendBuffer = bufferMsg. buffer;
Finally, the object maps the shared buffer into its address space.
sendBuffer. Map ()
To create a receive buffer, the object repeats the above procedure, sending antEnvCreateSharedBufferMsg to IPStack again.

When an object sends data to the protocol stack, it sends a pointer to the data in the send buffer. When receiving data from the protocol stack, it receives a pointer to the corresponding data in the receive buffer. The AntSharedBuffer structure automatically translates these pointers into object or protocol stack address space locations.
[0314]
Request network service
To request a service from any protocol in the IP protocol stack, the object creates a message and sends it to the appropriate endpoint in the IPStack. The type of message identifies the service being requested. The content of the message contains the information needed to perform the service (IP address, port number, pointer to data in shared buffer, etc.).
[0315]
Each protocol provides its own set of messages inherited from antEnvMsg. For details on these messages, refer to TCP, UDP, DNS, and IP in "Part 2 IPv4 Reference Guide".
[0316]
In the following example, the object opens a TCP connection to the other host. First, the object creates a message requesting a connection.

The first formal parameter, endpoint, identifies the TCP endpoint to which the message will be sent. The next two dummy arguments (zero) return the local IP address and port number when the connection is established. The last two formal arguments specify the IP address and port number of the destination host.
[0317]
The object then sends this message to the IPStack TCP endpoint.

Call () is inherited from antEnvMsg. AntStackRef (IPStackRef) that points to IPStack and message size are specified. Call () performs synchronous message passing, so the object suspends operation until it receives a result message.
[0318]
Chapter 2 TCP Guide
This chapter introduces the TCP protocol on OPEN-R and explains how objects use the TCP services provided by the IPv4 protocol stack.
2.1 TCP
TCP (Transmission Control Protocol) operates above the IP layer of the IPv4 protocol stack. TCP provides a reliable byte stream service for objects. TCP is a connection-oriented protocol. Therefore, the sending and receiving objects establish a connection before transferring data.
[0319]
TCP network operation
In OPEN-R, the IPv4 protocol stack provides the following TCP operations on objects.
Connect: Opens a TCP connection to a server (program) on another host.
Listen: Starts listening for connection requests. Primarily, this operation is performed by a server object instead of a connection operation. Normally, server objects accept TCP connection requests from clients (programs).
Send: Sends data on an open connection.
Receive: Receives data on an open connection.
Close: Close the TCP connection.
Objects perform these operations by sending special messages to the IPStack TCP endpoint. These messages inherit from TCPEndpointBaseMessage, and the latter inherits from antEnvMsg. Refer to "Chapter 7 TCP Reference" for these messages.
[0320]
For more information on how objects create endpoints and request network services, see 1.3 How objects communicate with the protocol stack.
[0321]
TCP endpoint life cycle
Figure 20 shows the state transition of the life cycle of the TCP endpoint. These transitions indicate the possible sequence of events and operations during a TCP connection. The message types shown in FIG. 20 are described in detail in "Part 2 IPv4 Reference Guide". The object requires one endpoint for each open network connection. If a connection has been established, a new connection cannot be requested. The object must first create a new endpoint. An endpoint can perform the same operation only once at a time. For example, sending TCPEndpointListMsg to an endpoint that is already listening will return a TCP_CONNECTION_BUSY or TCP_OPERATION_INVALID error. However, sending and receiving operations can be performed simultaneously.
[0322]
2.2 Create TCP endpoint
Before opening a TCP connection, the object must create a new TCP endpoint. The object needs one new endpoint for each open TCP connection. The procedure for creating an endpoint is similar for all protocols in the IP stack.
[0323]
2.3 Establish connection (client side)
To establish a TCP connection with the server, the client object sends TCPEndpointConnectMsg to the IPStack endpoint. The dummy arguments in this message are as follows.
IPAddresslAddress: (Output) Returns the local IP address when the connection is established.
PortlPort: (Output) Returns the temporary port number assigned to the client object when the connection is established.
IPAddressfAddress: (input) The IP address of the host to be connected.
PortfPort: (input) The port number of the object to be connected.
When the connection is established, the TCP endpoint returns a fully specified IP address and port number. Objects on the two hosts can send and receive data after the connection is established.
[0324]
2.4 Listening for connection requests (server side)
The server object accepts connection requests from client objects. To do so, the server object must constantly monitor (listen) for requests and establish a connection only when it receives a request. Normally, it accepts only connection requests to a specific port number. For example, an FTP server only accepts connections on the FTP port (21). In order for a server object to handle multiple clients simultaneously, two or more listen operations must be performed concurrently. Each listen operation waits for a connection request on the same port number. The server object requires a separate endpoint for each listen operation. To start listening for connection requests, the server object sends a TCPEndpointListenMsg to the IPStack endpoint.
[0325]
The formal parameters of this message include:
IPAddressl Address: (Output) Returns the local IP address when the connection is established.
Portl Port: (Input) This is a port number for receiving a connection request. When accepting a connection request to an arbitrary port, the value of IP_PORT_ANY is specified.
IPAddressf Address: (Output) Returns the IP address of the host that requested the connection.
Portf Port: (Output) Returns the port number of the object that requested the connection.
Upon receiving a connection request, the TCP endpoint establishes a connection and returns a fully specified IP address and port number.
[0326]
2.5 Send data
To send data over an open TCP connection, the object sends TCPEndpointSendMsg to the IPStack endpoint. The dummy arguments of this message are as follows.
buffer: (input) Pointer to data to be transmitted. Data is stored in the shared memory buffer defined by the antSharedBuffer structure.
size: (input) The size of data to be transmitted, expressed in bytes.
The TCP endpoint replies to this message when data has been processed by the IP stack and the buffer is available for reuse.
[0327]
2.6 Receiving data
To receive data from an open TCP connection, the object sends TCPEndpointReceiveMsg to the IPStack TCP endpoint. The following shows the formal parameters of this message.
buffer: (input) A pointer to a memory area in which incoming data is written. This area is in the shared memory buffer and is defined by the antSharedBuffer structure.
sizeMin: (Input / Output) Specify the minimum number of bytes to receive. When the receiving operation is completed and the endpoint replies to the object, this dummy argument returns the number of bytes actually received.
sizeMax: (Input / Output) Specify the maximum number of bytes to receive. When the receiving operation is completed and the endpoint replies to the object, this dummy argument returns the number of bytes actually received.
[0328]
The TCP endpoint replies to this message once the data has been copied to the receive buffer. However, if all data being transmitted has been received and the TCP connection is closed, the last reception request may have fewer bytes than the sizeMin designation.
[0329]
2.7 Close the connection
A TCP connection can be closed in three ways:
・ Active close
A close in which the object sends a request for a direct communication close. Active close occurs when the object directly initiates the closing of the TCP connection. To perform an active close, the object sends TCPEndpointCloseMsg to the IPStack endpoint. When an object performs an active close, data cannot be sent or received. The connected object receives the rest of the transmitted data and then receives a signal that the connection has been closed. From the viewpoint of the other object, a passive close has occurred.
[0330]
・ Passive close
This is a close in which the connection destination object transmits a communication close request. Passive close occurs when the object on the other side of the network closes the TCP connection (by performing an active close). When the object has received all data transmissions, a TCP_CONNECTION_CLOSED error occurs. In that case, the object sends TCPEndpointCloseMsg to the IPStack endpoint to complete the passive close.
[0331]
·abort
A connection is unexpectedly closed when an error occurs, and an abort occurs when something unexpected occurs on a TCP connection. Examples of aborting occur when the connection times out and times out, when the connection request takes too long, when the requesting object disconnects, and when the normal active or passive close takes too long. Therefore, when the object is disconnected by one of the objects, when the object determines to abort the connection, or the like. Abort removes all data from the shared buffer and closes the connection immediately. To abort the connection, the object sends TCPEndpointCloseMsg to the IPStack endpoint. This message has a boolean dummy argument called abort. If this parameter is TRUE, the TCP connection will be aborted without terminating normally.
[0332]
2.8 Example of TCP echo client
This section describes how to use TCP messages, using the example of a TCP echo client program. The TCP echo client establishes a connection with the TCP echo server and sends data. Then, upon receiving the data returned from the server, the connection is closed. In this example, data must be sent and received simultaneously. Therefore, where needed, asynchronous versions of the antEnvMsg member functions are used. At this time, the stub that processes those messages and the number of the entry point must be defined. For details on how to number entry points, see "Defining entry points".
[0333]
Variable definitions
The definition of the variables is performed as follows.

[0334]
Defining entry points
In addition, entry points are defined when an object is initialized, when a reception request is completed, and when a transmission request is processed. stub. The following description is required for cfg. For details on how to define an entry point, refer to Extra entry in "2.3 Stubs of Programmer's Guide".
Extra: Initialize ()
Extra: ReceiveCont ()
Extra: SendCont ()
When the stubgen2 command is executed, xxxStub. A cc is generated and describes:

Here, the entry point number is determined according to the order of the elements of the ObjectEntryTable [].
[0335]
Object initialization
This function is called when the client object starts up, and executes operations for creating a shared buffer, creating a TCP endpoint, and establishing a connection to the TCP echo server.

[0336]
Close TCP connection
The following function destroys the shared buffer and closes the connection.

[0337]
Receiving data
The following function closes the TCP connection after receiving data until the required amount of data arrives. Two functions are used to realize asynchronous communication. DoReceive () will try to receive from 1 to PACKETSIZE bytes.

[0338]
When one reception request is completed, ReceiveCont () is called. When all transmitted data has been received, the TCP connection is closed. Otherwise, a new receive request is issued.

[0339]
Transmission of data
This function sends data to the echo server. Here, two functions are used to realize asynchronous communication. DoSend () sends a PACKETSIZE byte to the echo server.

[0340]
SendCont () is called when the send buffer has been processed by the IP stack and can be reused in the object. To send more data, issue a new send request.

[0341]
Chapter 3 UDP Guide
This chapter introduces the UDP protocol on OPEN-R and describes how objects can use the UDP services provided by the IPv4 protocol stack.
3.1 UDP
UDP (User Datagram Protocol) is a protocol that operates above the IP layer of the IPv4 protocol stack. UDP sends packets of data, or datagrams, to the IP layer, which sends the packets beyond the network. UDP provides a connectionless, unreliable datagram delivery service for objects. Connectionless means that the sending / receiving host does not establish a connection. UDP is used by application layer protocols such as TFTP, DNS, and NFS.
[0342]
・ UDP network operation
In OPEN-R, the IPv4 protocol stack provides the following UDP operations on objects.
Bind: Set local connection parameters and identify objects as destinations for UDP packets. After the bind operation, the object receives the packet only when the destination address of the packet is the same as the IP address and port number specified in the bind parameter.
Connect: Optional operation. With this operation, the object sets the external connection parameters. Packets will be exchanged only with the host specified by the IP address and port number in the connection parameters.
Send: Send data.
Receive: Receive data.
Close: Deletes the parameters set in Bind and Connect, and stops sending and receiving data.
The object performs these operations by sending a special message to the IPStack's UDP endpoint. These messages inherit from UDPEndpointBaseMessage, and the latter inherits from antEnvMsg. Please refer to "Chapter 8 UDP Reference" for these messages. For details on how objects create endpoints and request network services, see "1-3 How Objects Communicate with the Protocol Stack."
[0343]
・ UDP endpoint life cycle
Figure 21 shows the state transition of the life cycle of a UDP endpoint. The message types shown in FIG. 21 are described in detail in "Part 2 IPv4 Reference Guide". The object requires one endpoint for each UDP connection. An endpoint can perform a similar operation only once at a time. For example, if you send UDPEndpointSendMsg to an endpoint that is already sending data, that endpoint will return a UDP_CONNECTION_BUSY error. However, incoming messages can be sent to this endpoint.
[0344]
3.2 Create a UDP endpoint
Objects need to create a new UDP endpoint before sending and receiving data over UDP. The object requires a new endpoint for each UDP connection. The procedure for creating an endpoint is similar for all protocols in the IP stack. For details on the procedure, see "1-3 How Objects Communicate with the Protocol Stack."
[0345]
3.3 Binding endpoints
Objects must be bound after the endpoint is created. Binding is the procedure for setting local connection parameters. The local connection parameters identify the port used by the endpoint when sending UDP packets. To bind the endpoint, the object sends a UDPEndpointBindMsg to the IPStack endpoint. The following shows the formal parameters of this message.
address: (input / output) A valid IP address on the local host. If you specify IP_ADDR_ANY, the object will receive packets sent to any IP address on the local host. This is useful for multi-homed hosts with multiple interfaces at different addresses. If the host is not multihomed, the local IP address is returned. On a multi-homed host, if the object performs a connection operation after binding the endpoint, IP_ADDR_ANY will be updated to the specific IP address.
[0346]
port: (input / output) The port number of the object. If you specify IP_PORT_ANY, the object will be assigned a temporary port number and will be returned when the endpoint is bound. This port number can be 1024 or higher. Once the endpoint is bound, the object can send and receive data. Specify the destination IP address and port number for each bucket unless the object has first performed a connection operation (specifying all packet destinations). For details on the connection operation, see "3-4 Setting external connection parameters (optional)."
[0347]
3.4 Setting external connection parameters (optional)
After binding the endpoint, the object can also perform connection operations. This specifies the IP address and port number to which all packets sent by the object on that endpoint will be sent. Once connected, the object does not need to specify the destination each time it sends a packet. For connection operations, the object sends an UDPEndpointConnectMsg to the IPStack endpoint. The following shows the formal parameters of this message.
address: (input) Specify the IP address of the host to which the packet is sent.
port: (input) Specifies the port number of the object to which the packet is sent.
[0348]
3.5 Send data
To send data over UDP, the object sends a UDPEndpointSendMsg to the IPStack endpoint. If the endpoint is bound but not connected, specify the destination IP address and port number in this message. This information is not needed if the endpoint is connected. The following shows the dummy arguments of the UDPEndpointSendMsg message.
address: (input) The IP address of the host to which data is sent. If the object has completed the connection operation, this dummy argument will be ignored and the IP address specified in UDPEndpointConnectMsg will be used.
port: (input) The port number of the data destination object. If the object has completed the connection operation, this dummy argument will be ignored and the port number specified in UDPEndpointConnectMsg will be used.
buffer: (input) Pointer to the data to be sent. This data is stored in the shared memory buffer defined by the antSharedBuffer structure.
size: (input) The size of the data to be sent, in bytes.
The UDP endpoint replies to this message when the data has been removed from the shared buffer and sent.
[0349]
3.6 Receiving data
To receive data over UDP, the object sends UDPEndpointReceiveMsg to the UDP endpoint of IPStack. The following shows the formal parameters of this message.
address: (output) The IP address of the host that sent the data.
port: (output) The port number of the object that sent the data.
buffer: (input) Pointer to a buffer for storing received data. The storage location for this data is a shared memory buffer, defined by the antSharedBuffer structure.
size: (input / output) Specifies the maximum number of bytes to receive. When the receiving operation is completed and the endpoint replies to the object, this dummy argument returns the actual number of bytes received. If the received packet is larger than the specified size, the surplus data will be deleted. The UDP endpoint replies to this message when the data has been copied to the shared buffer.
[0350]
3.7 Close Endpoint
To close a UDP endpoint, the object sends a UDPEndpointCloseMsg to the IPStack endpoint. This message has no dummy arguments. After sending this message, the object cannot send or receive data. When the connection is completely closed, the endpoint replies.
[0351]
3.8 UDP echo server example
The example of UDP echo server explains how to use UDP message. The UDP echo server opens a UDP connection and binds it to echo port (7). All data received on this connection will be sent back. For details on how to number entry points, see "Defining entry points".
[0352]
Variable definitions
Define the variables as follows.

[0353]
Defining entry points
stub. The following description is required for cfg. For details on how to define entry points, refer to Extra entry in "2.3 Stubs of Programmer's Guide".
Extra: Initialize ()
Extra: ReceiveCont ()
Extra: SendCont ()
When the stubgen2 command is executed, xxxStub. A cc is generated and describes:

Here, the entry point number is determined according to the order of the ObjectEntryTable [] elements.
[0354]
Object initialization
This function is called when the client object starts. This function does three things: create a shared buffer for sending / receiving, create a UDP endpoint, and bind the endpoint to the echo port (7).

[0355]
Echo data
These functions receive the UDP datagram, get the source IP address and port number, and send back the data. DoReceive () makes a reception request for a packet containing up to PACKETSIZE bytes.

[0356]
ReceiveCont () is called when a UDP datagram is received. This function sends the datagram back to the source of the data.

[0357]
SendCont () is called when the data has been processed by IPStack and the buffer is ready for reuse. Next, a new reception request appears.

[0358]
Close UDP connection
Close () performs a process of unmapping and discarding the shared buffer and a process of closing the UDP connection.

[0359]
Chapter 4 DNS Guide
This chapter introduces DNS client support on OPEN-R and describes how objects can use the DNS client services provided by the IPv4 protocol stack.
4.1 Introduction to DNS
DNS (Domain Name System) is a protocol that runs on UDP in the IPv4 protocol stack. Provides a service for setting, obtaining, and converting Internet domain names and IP addresses. For example, if the object uses FTP to save the file to ftpserver. yourdomain. When sending to a host with the domain name com, the object must know the IP address of that host. When the object sends a request to DNS to determine this address, DNS sends ftpserver. yourdomain. com has an IP address of 192.168.1.200. With this information, the object makes an FTP connection and saves the file to ftpserver. yourdomain. com.
[0360]
・ DNS network operation
In OPEN-R, the IPv4 protocol stack provides the following DNS operations on objects.
Set and get DNS server for host: Set or get the IP address of all DNS servers used by the host. Note that all objects share a DNS server definition. If one object changes the definition of the DNS server, the other objects will automatically use the changed definition.
Set and get default domain name of object: Set and get the default domain name of the host.
Get Complete Host Entry by IP Address or Domain Name: Get a complete list of IP addresses and domain name aliases for the specified host.
Obtain a host's IP address: If the host has multiple addresses, obtain one of the host's valid IP addresses.
Get host domain name alias: If the domain name has multiple aliases, get one of the valid aliases for the host.
Close: Closes the object's DNS endpoint.
[0361]
The object performs these operations by sending a special message to the IPStack's DNS endpoint. These messages inherit from DNSEndpointBaseMessage, and the latter inherits from antEnvMsg. See "1-3 How Objects Communicate with the Protocol Stack" for more information on how objects create endpoints and request network services.
[0362]
・ DNS endpoint cycle
Figure 22 shows the state transition of the DNS endpoint during the life cycle. The message types in Fig. 22 are explained in the "IPv4 Reference Guide". Objects require one endpoint per DNS connection, and one endpoint can perform only one operation at a time. For example, if you send a DNSEndpointSetServerAddressesMsg to one endpoint that has already performed the operation, that endpoint will return a DNS_CONNECTION_BUSY error.
[0363]
4.2 Create a DNS endpoint
To send and receive data to and from the DNS, the object must create a new DNS endpoint. The procedure for creating an endpoint is similar for all protocols in the IP stack. See “1-3 How Objects Communicate with the Protocol Stack”. If possible, open only one DNS endpoint and try to reuse that endpoint for all DNS operations and queries while using the object. Only close the endpoint if you are not doing any more DNS queries. However, you can create multiple DNS endpoints if your object requires them.
[0364]
4.3 Setting and Obtaining DNS Server for Objects
At object initialization, the object registers a list of all DNS servers used to resolve domain names and IP addresses. Once this list has been registered, queries are sent to the listed servers in the order of the list.
・ Set the IP address of the DNS server
To register a list of DNS server IP addresses, the object sends DNSEndpointSetServerAddressesMsg to the IPStack endpoint. The following is a dummy argument of DNSEndpointSetServerAddressesMsg.
nscount: (input) The number of IP addresses to be registered.
addrList [MAXNS]: (input) A list of IP addresses to be registered.
・ Obtain the IP address of the DNS server
To get a list of DNS servers registered for the host, the object sends DNSEndpointGetServerAddressesMsg to the IPStack endpoint. The following is a dummy argument of DNSEndpointGetServerAddressesMsg.
nscount: (output) This is the number of registered IP addresses.
addrList [MAXNS]: (output) A list of IP addresses.
[0365]
4.4 Setting and Getting the Default Domain Name of an Object
Upon initialization, the object registers its default domain name. After the default domain name is registered, it is automatically added to all host names that are not fully qualified.
・ Set the default domain name
To set a default domain name, the object sends a DNSEndPointSetDefaultDomainNameMsg to the object's endpoint in IPStack. DNSEndpointSetDefaultDomainNameMsg has one formal parameter, which specifies the domain name name [MAXDNAME]. Domain names must end with null characters.
・ Get the default domain name
To get the default domain name, the object sends DNSEndpointGetDefaultDomainNameMsg to the IPStack endpoint. DNSEndpointGetDefaultDomainNameMsg has one formal parameter, which specifies the domain name name [MAXDNAME]. Domain names are terminated by a null character.
[0366]
4.5 Get Host Entry
When trying to determine the IP address, domain name, or alias of a domain name for a host on the Internet, the object gets an entry for the host from one of its DNS servers. A host entry typically contains a list of all IP addresses and domain name aliases for the host, as shown in FIG. In OPEN-R, when an object requests a host entry from the DNS protocol, the entry includes the address of the DNS server that returned the host entry, the first IP address (official address) in the list, and the total number of IP addresses for the host. , Only the first domain name in the list (the official domain name) and the total number of aliases for the host domain name. If you want to get one of the aliases for a different IP address or domain name, explicitly request it. For details, see "4-6 Obtain the IP address of the host" and "4-7 Obtain the alias of the host domain name" later in this chapter.
[0367]
・ Get entry by domain name
To retrieve a host entry when only the domain name or alias of the domain name is known, the object sends DNSEndpointGetHostByNameMsg to the IPStack endpoint. The following is a dummy argument of DNSEndpointGetHostByNameMsg.
name [MAXDNAME]: (Input / Output) The domain name of the host whose entry you are trying to get. Terminate the domain name with null characters. Given a domain name alias, returns the official domain name of the host.
server_address: (output) The IP address of the DNS server that sent the host entry.
host_address: (output) This is the IP address of the host. If the host has multiple IP addresses, return the first IP address.
n_address: (output) The number of IP addresses for the host.
n_alias: (output) The number of aliases of the domain name for the host.
[0368]
・ Get entry by IP address
To get a host entry when only the IP address of the host is known, the object sends DNSEndpointgetHostByAddrMsg to the IPStack endpoint. The following is a dummy argument of DNSEndpointGetHostByAddrMsg.
host_address: (input / output) The IP address of the host. Returns the first IP address of the host, even if you specify a different IP address in the original message.
server_address: (output) The IP address of the DNS server that sent the host entry.
name [MAXDNAME]: (Output) The official domain name of the host. Domain names end with a null character.
n_address: (output) The number of IP addresses for the host.
n_alias: (output) The number of domain name aliases for the host.
[0369]
4.6 Obtain IP address of host
If you want to get only the first registered IP address of the host, see "4.5 Get Host Entry". If you want to obtain another IP address registered with the host, perform the operations described in this chapter separately. To get one of the host's other IP addresses, the object sends a DNSEndPointGetAddressMsg to the IPStack endpoint. However, before performing this operation, it is necessary to obtain a host entry according to “4.5 Obtaining a Host Entry”. The following shows the dummy arguments of DNEndpointGetAddressMsg.
index: (input) The index of the IP address to be acquired. This index must be less than the n_address returned when the host entry was previously received. If 0 is given, returns the first IP address in the host entry list.
address: (output) The IP address at the index position in the host entry.
[0370]
4.7 Get Host Domain Name Alias
If you want to get only the official domain name of the host, see "4.5 Get Host Entry." If you want to obtain an alias for the host's domain name, perform the operations described in this chapter separately. To get one of the aliases for the host's domain name, the object sends DNSEndpointGetAliasMsg to the IPStack endpoint. However, before performing this operation, it is necessary to obtain a host entry according to “4.5 Obtaining a Host Entry”. The dummy arguments of DNSEndpointGetAliasMsg are shown below.
index: (input) The index of the alias of the domain name you want to get. This index must be less than the n_alias returned when the host entry was previously received. If 0 is given, returns the official domain name of the host.
name [MAXDNAME]: (Output) Alias of the domain name at the index position in the host entry.
[0371]
4.8 Closing the endpoint
To close a DNS endpoint, the object sends a DNSEndpointCloseMsg to the IPStack endpoint. This message has no dummy arguments. After sending this message, the object cannot send or receive data.
[0372]
4.9 Example of DNS Client
The DNS client example shows how to use DNS messages. The DNS client is used to open an endpoint for DNS services in the IP stack and search for a domain name or IP address.
[0373]
Variable definitions
Define the variables as follows:

[0374]
Defining entry points
stub. The following description is required for cfg. For details on how to define entry points, refer to Extra entry in "2.3 Stubs of Programmer's Guide".
Extra: Initialize ()
[0375]

[0376]
Opening and closing endpoints
Open () creates a DNS endpoint. It uses that endpoint to communicate with the DNS service of the IP stack.

[0377]
Set the DNS function
Use the SetServers () function to set the DNS primary, DNS secondary server, and local domain name.

[0378]

[0379]

[0380]
Chapter 5 IP Guide
This chapter introduces the IP protocol on OPEN-R and explains how objects can use the IP services provided by the IPv4 protocol stack.
5.1 Introduction to IP
In the IPv4 protocol stack, the Internet Protocol layer (IP) is responsible for sending packets through the network. Typically, objects do not communicate directly with IP, but rather open connections to layers such as TCP or UDP over IP. However, some objects need to use the IP layer directly. For example, if you want to add a new protocol without changing the IPStack program, you can describe the protocol as an object that communicates directly with the IP layer.
[0381]
・ IP network operation
In OPEN-R, the IPv4 protocol stack provides objects with the following IP operations.
Bind: Binds an IP endpoint to a specific protocol. All packets sent and received by the object through the endpoint are treated as if they originated from the specified protocol.
Send: Send data.
Receive: Receive data.
Close: Stop sending and receiving data and delete the endpoint.
Objects perform these operations by sending special messages to IPStack's IP endpoints. These messages inherit IPEndpointBaseMessage, but the latter inherits antEnvMsg. Refer to "Chapter 10 IP Reference" for these messages. For more information on how objects create endpoints and request network services, see 1.3 How objects communicate with the protocol stack.
[0382]
・ IP endpoint life cycle
FIG. 24 shows the state transition of the IP endpoint during the life cycle period. The message types in Fig. 24 will be explained in the "IPv4 Reference Guide". An object requires an endpoint for each IP connection, and one endpoint can perform the same operation only once at a time. For example, if you send an IPEndpointSendMsg to one endpoint that is sending data, that endpoint will return an IP_CONNECTION_BUSY error. However, it is possible to send IPEndpointReceiveMsg to this endpoint.
[0383]
5.2 Create an IP endpoint
Before sending or receiving data over IP, the object must create a new IP endpoint. The procedure for creating an endpoint is similar for all protocols in the IP stack. See “1.3 How Objects Communicate with the Protocol Stack”.
[0384]
5.3 Binding the endpoint
The object needs to bind the endpoint to a specific protocol after the endpoint has been created. All packets sent or received by the object through the endpoint are treated as originating from the specified protocol. To bind an endpoint, the object sends IPEndpointBindMsg to the IPStack endpoint. This message has one formal parameter called protocol. This dummy argument specifies the protocol to bind to the endpoint. Each protocol is identified by an integer less than 256. However, unless the endpoint is bound to the protocol stack, it cannot be bound to the TCP or UDP protocol. Attempting to bind returns an IP_INVALID_PROTOCOL error. However, you can bind an endpoint to ICMP. ICMP processes all recognized packets as normal, but forwards all unidentified packets to the bound endpoint.
[0385]
5.4 Send data
To send data over IP, the object sends an IPEndpointSendMsg to the IPStack endpoint. The following shows the formal parameters of the IPEndpointSendMsg message.
type: (input) The type of packet to be sent. Normal IP packets are of type IP_DATA. Other types exist for ICMP packets.
buffer: (input) Pointer to the packet to be sent. This packet is stored in the shared memory buffer defined by the antSharedBuffer structure.
size: (input) The size of the packet to be sent, in bytes.
[0386]
The IP endpoint replies to this message when data has been removed from the shared buffer and sent. When sending an IP packet, enter data in each field of the IP packet to make it a complete packet. The IP header looks like Figure 25. The C ++ class IPHeader is available from IPProtocol. h. Use IPHeader to populate IP packets. This class takes care of all endian relationships. Here, the following fields are required items.
8-bit protocol field [IPHeader :: ip_pSet (byte_val)]
32-bit source IP address [IPHeader :: ip_srcSet (uint32_val)]
32-bit destination IP address [IPHeader :: ip_dstSet (uint32_val)]
[0387]
Also, the following fields are optional. If you write 0 in a field, the field will be treated as undefined and will be overwritten by the stack.
16-bit total length (in bytes) [IPHeader :: ip_lenSet (uint16_val)]
4-bit header length [IPHeader :: ip_hlSet (byte_val)]
8-bit type of service [IPHeader :: ip_tosSet (byte_val)]
8-bit time to live [IPHeader :: ip_ttlSet (byte_val)]
The 8-bit time to live field is overwritten by the stack only if the IP packet is not a broadcast packet. However, do not set values in the following fields. Always overwritten by the IP stack. Refer to "5.7 Example of IP-ping" for an example of using the IPHeader class.
4-bit version
13-bit fragment offset
16-bit identification
16-bit header checksum
[0388]
5.5 Receiving data
To receive data over IP, the object sends IPEndpointReceiveMsg to the IPStack endpoint. The following shows the formal parameters of this message.
type: (output) The type of the received packet. Normal IP packets are of type IP_DATA. Other types exist for ICMP packets.
buffer: (input) A pointer to an area for storing a packet to be received. This area must be in a shared buffer defined by the antSharedBuffer structure.
size: (input / output) Specifies the maximum number of bytes to receive. When reception is complete and the endpoint replies to the object, it returns the real number of bytes received. If the packet received is too large for the shared buffer, only a portion of the packet will be buffered and an IP_PACKETSIZE error will be returned.
The IP endpoint replies to this message when the data has been copied to the shared buffer.
[0389]
5.6 Close Endpoint
To close an IP endpoint, the object sends an IPEndpointCloseMsg to the IPStack endpoint. This message has no dummy arguments. After sending this message, the object cannot send or receive data. The endpoint responds when the connection is completely closed.
[0390]
5.7 Example of IP ping
This IP ping example shows how to use IP messages. The IP ping program sends ICMP packets to hosts on the network and waits for a reply.
[0391]

[0392]
Defining entry points
stub. The following description is required for cfg. For details on how to define entry points, refer to Extra entry in "2.3 Stubs of Programmer's Guide".
Extra: Initialize ()
[0393]
Object initialization
This function is called when the object is initialized.

[0394]
Open endpoint
The Open () function creates a shared buffer and an IP endpoint for sending and receiving ICMP packets. It also binds the endpoint to the ICMP protocol.

[0395]
Close
Use the Close () function to unmap and discard the shared buffer. Also, discard the IP endpoint.

[0396]
Ping
Ping () sends and receives the actual ICMP_ECHO packet. First, Ping () creates an IP / ICMP packet in a shared buffer, and then the IP / ICMP packet is sent to the IP stack over the network. After that, Ping () waits for the ICMP_ECHOREPLY packet to be received.

[0397]
Part 2 IPv4 Reference Guide
Chapter 6 ANT Environment Reference
This chapter describes the structure and member functions used to send endpoint and shared buffer requests to the ANT environment.

Here you define a message requesting a new endpoint. The object creates an antEnvCreateCreateEndpointMsg when a new endpoint is needed, specifying which protocols the endpoint requires, and the size of the SDU pool to be created for that endpoint. The following shows the dummy arguments here.
error: (Output) Returns an error describing the result for the request.
protocol: (input) The type of endpoint to create. This type corresponds to the available protocols.
EndpointType_TCP
EndpointType_UDP
EndpointType_TFTP
EndpointType_DNS
EndpointType_POP3
EndpointType_SMTP
EndpointType_IP
EndpointType_MIBII
EndpointType_MIB_ETHERNET
poolSize: (Input) The size of the SDU pool created for the new endpoint. The SDU pool is an internal ANT structure that stores data in the protocol stack. As a guide, always create an SDU pool slightly larger than the largest of the packets you want to send. For example, an 8-KB packet requires about a 10-KB SDU pool.
moduleRef: (output) reference to the new endpoint
[0398]

Create an instance of antEnvCreateEndpointMsg. After creating the message, send it to the ANT environment. When the object receives the response message, the formal parameter moduleRef of antEnvCreateEndpointMsg contains a reference to the new endpoint. The following shows the dummy arguments here.
protocol: (input) The type of endpoint to create. This type corresponds to the available protocols.
EndpointType_TCP
EndpointType_UDP
EndpointType_TFTP
EndpointType_DNS
EndpointType_POP3
EndpointType_SMTP
EndpointType_IP
EndpointType_MIBII
EndpointType_MIB_ETHERNET
poolSize: (input) the size of the SDU pool to create for the new endpoint
[0399]

Here we define a message requesting a shared memory buffer. When an object requests a new shared memory buffer, it creates an antEnvCreateSharedBufferMsg that specifies the size of the buffer. The following shows the dummy arguments here.
error: (Output) Returns an error describing the result of the request.
size: (input) The shared buffer size in bytes.
buffer: (output) Indicates a reference to the newly created buffer.
[0400]
antEnvCreateSharedBufferMsg :: antEnvCreateSharedBufferMsg ()
The constructor is shown below.
antEnvCreateSharedBufferMsg (uint32_size);
Create an instance of antEnvCreateSharedBufferMsg. After creating the message, send it to the ANT environment. When the object receives the response, the formal parameter buffer of antEnvCreateSharedBufferMsg returns a reference to the new buffer. The following shows the dummy arguments here.
size: (input) The shared buffer size in bytes.
[0401]

This defines the shared memory buffer used to exchange data between the object and the ANT environment. The shared memory buffer maps a common memory area to the object and the address space of the ANT environment. When an object exchanges data with the ANT environment, the data is identified by a pointer to this shared buffer. antSharedBuffer translates this pointer between the object and the address space of the ANT environment. To create a shared buffer, an object sends antEnvCreateSharedBufferMsg to the ANT environment, specifying the size of the buffer.
[0402]
antSharedBuffer :: Map ()
The members are shown below.
antError Map ();
Maps a shared memory buffer into the object's address space. After performing this operation, the object should exchange data with the ANT environment. The return value at this time is shown below.
ANT_SUCCESS: Success
ANT_FAIL: failed
[0403]
antSharedBuffer :: UnMap ()
The members are shown below.
antError UnMap ();
Removes a shared memory buffer from the object's address space. Do this before destroying the shared buffer. The return value at this time is shown below.
ANT_SUCCESS: Success
ANT_FAIL: failed
[0404]
antSharedBuffer :: GetAddress ()
The members are shown below.
void * GetAddress ();
Get the base address of the shared memory buffer. Before performing this operation, the object must map a buffer into its address space (see antSharedBuffer :: Map ()). The return value at this time is shown below.
0: failed
[0405]
antSharedBuffer :: GetSize ()
The members are shown below.
uint32 GetSize ();
Gets the size of the shared memory buffer in bytes. Before performing this operation, the object must map a buffer into its address space (see antSharedBuffer :: Map ()).
[0406]
Chapter 7 TCP Reference
This section describes the TCP messages that an object sends to IPStack for the purpose of requesting TCP services. All messages inherit from TCPEndpointBaseMsg.
TCP error
The following is a list of errors returned by the messages described in this chapter. Error values are defined in the enumeration type TCPEndpointError. When an object requests a network operation and receives a response from the TCP endpoint, examine the error field of the request. (For example, TCPEndpointListenMsg.error)
TCP_BUFFER_INVALID: The address and size arguments used in TCPEndpointSendMsg or TCPEndpointReceiveMsg do not indicate in the shared buffer.
TCP_CONNECTION_BUSY: The connection is busy and the requested operation has not been completed. It is assumed that the TCP endpoint to which the message was sent is already processing another request.
TCP_CONNECTION_CLOSED: Connection closed.
TCP_CONNECTION_RESET: Connection has been aborted.
TCP_CONNECTION_TIMEOUT: The connection has expired and has been closed.
TCP_FAIL: Operation failed (no more information available).
TCP_HOST_UNREACHABLE: The IP stack could not find a route to the destination address.
TCP_MESSAGE_TOO_LONG: The TCP / IP packet was too large to be processed by the intermediate router.
TCP_NETWORK_UNREACHABLE: The IP stack could not find a route to the network containing the destination address.
TCP_OPERATION_INVALID: The requested operation is not allowed in the current endpoint state.
TCP_OPERATION_UNKNOWN: The requested operation was not recognized by the TCP endpoint.
TCP_PORT_UNREACHABLE: The connection is not listening on the specified destination port.
TCP_PROTOCOL_UNREACHABLE: Destination host does not implement TCP.
TCP_SUCCESS: Operation was successful.
TCP_TIME_EXCEEDED: The IP reassembly queue has timed out.
TCP_TTL_EXCEEDED: Destination host has exceeded TTL hops from source host (too many nodes between destination host and source host).
[0407]
TCPEndpointBaseMsg
It is defined as follows.

Here you specify which endpoints in the IPv4 protocol stack will receive requests for TCP services and which objects will receive responses to those requests. Requests for individual network services are sent in messages inherited from TCPEndpointBaseMsg (described later in this section). The dummy arguments are shown below.
module: (input) target endpoint
operation: (input) operation requested by the sending object
error: (output) For details on the TCP error code, see "TCP Error".
See "TCP Error" for the TCP error code of the return value. Further, here, as related items, TCPEndpointConnectMsg, TCPEndpointListenMsg, TCPEndpointSendMsg, TCPEndpointReceiveMsg, and TCPEndpointCloseMsg are listed.
[0408]
TCPEndpointConnectMsg
It is defined as follows.

Here, a TCP connection to another host is opened. Primarily, TCPEndpointConnectMsg is emitted by the client object. When the connection is fully established, the TCP endpoint will respond to this message. This response contains the fully specified local and destination addresses and port numbers. TCPEndpointConnectMsg is inherited from TCPEndpointBaseMsg. The following shows the dummy arguments here.
module: Reference to the destination module.
lAddress: (Output) Returns local IP address if connection is established.
lPort: (Output) If a connection is established, returns the temporary port number assigned to the client object.
fAddress: (input) The IP address of the computer to be connected.
fPort: (input) The port number of the object to be connected.
Refer to "TCP error" for the TCP error code of the return value here. A related item is TCPEndpointBaseMsg.
[0409]
TCPEndpointListenMsg
It is defined as follows.

Here we start listening for connection requests. Normally, TCPEndpointListMsg is issued by the server object. When the connection is fully established, the TCP endpoint will respond to this message. This response includes the specified local and destination addresses and port numbers. A server object can perform multiple listening operations, all accepting connection requests on the same port number. A separate endpoint is required for each listen operation. TCPEndpointListMsg is inherited from TCPEndpointBaseMsg. The following shows the dummy arguments here.
module: Reference to the destination module.
lAddress: (Output) Returns local IP address if connection is established.
lPort: (input) The port number that receives the connection request. To accept requests to any port, specify the value of IP_PORT_ANY.
fAddress: (Output) Returns the IP address of the computer that requested the connection.
fPort: (Output) Returns the port number of the object that requested the connection.
Refer to "TCP Error" for the TCP error code of the return value. Also, here, the related item is TCPEndpointBaseMsg.
[0410]
TCPEndpointSendMsg
The constructor is described below.

Here, data is sent via an open TCP connection. All data that the object sends to the protocol stack should be stored in a shared memory buffer defined by the antSharedBuffer structure. The TCP endpoint responds to this message when data is copied from the shared buffer to the IP stack's internal memory buffer. TCPEndpointSendMsg is inherited from TCPEndpointBaseMsg. The dummy arguments here are shown below.
module: Indicates a reference to the destination module.
buffer: (input) a shared buffer in which data being transmitted is stored.
size: (input) The data size during transmission in bytes.
Refer to "TCP Error" for the TCP error code of the return value. The related items here include TCPEndpointBaseMsg, TCPEndpointConnectMsg, and antSharedBuffer.
[0411]
TCPEndpointReceiveMsg
The constructor is shown below.

Here, data is received from the opened TCP connection. All data the object receives from the protocol stack is stored in a shared memory buffer defined by the antSharedBuffer structure. The TCP endpoint responds to this message when data is copied to the shared buffer. If all data being transmitted is received and the TCP connection is closed, the final receive request may have fewer bytes than sizeMin specifies. TCPEndpointReceiveMsg is inherited from TCPEndpointBaseMsg. The following shows the dummy arguments here.
module: Indicates a reference to the destination module.
buffer: (input) A shared buffer for received data.
sizeMin: (input / output) Specify the minimum number of bytes to receive. When the receive operation is complete and the endpoint has responded to the object, this dummy argument returns the actual number of bytes received.
sizeMax: (input / output) Specify the maximum number of bytes to receive. When the receive operation is complete and the endpoint has responded to the object, this dummy argument returns the actual number of bytes received.
See "TCP Error" for the TCP error code of the return value. Related items include TCPEndpointBaseMsg, CPEndpointConnectMsg, and antSharedBuffer.
[0412]
TCPEndpointCloseMsg
The following shows the constructor.

Close the TCP connection. There are the following three methods for closing the TCP connection.
・ Active close
The object sends a close request directly. The object at the other end of the connection receives the rest of the transmission, and then receives an error indicating that the connection has been closed. From the point of view of the opponent object, a passive close has occurred.
・ Passive close
A close request is sent from the object on the other side of the connection. A TCP_CONNECTION_CLOSED error occurs after the near object receives all the transmitted data. This object completes passive close by sending TCPEndpointCloseMsg to the endpoint in the ANT environment.
·abort
If an error occurs, the connection is closed unexpectedly. Abort erases all data in the shared buffer and closes the connection immediately.
When the connection is completely closed, the TCP endpoint will respond to this message. TCPEndpointCloseMsg is inherited from TCPEndpointBaseMsg.
[0413]
The following shows the dummy arguments here.
module: Indicates a reference to the destination module.
abort: (in) If TRUE, the TCP connection will be aborted instead of being stopped in the usual way.
Refer to "TCP Error" for the TCP error code of the return value. A related item is TCPEndpointBaseMsg.
[0414]
Chapter 8 UDP Reference
This chapter describes the UDP messages that objects send to IPStack to request UDP services. All messages are inherited from UDPEndpointBaseMsg.
UDP error
The following is a list of errors returned by the messages described in this chapter. Error values are defined in UDPEndpointError. When an object requests a network operation and receives a response from the UDP endpoint, check the error field of the request (eg, UDPEndpointConnectMsg.error).
UDP_ADDRESSERROR: Combination of specified IP address and port number is invalid.
UDP_ADDRESSINUSE: The specified combination of IP address and port number is already being used by another connection.
UDP_BUFFER_INVALID: The address and size arguments of TCPEndpointSendMsg or TCPEndpointReceiveMsg do not indicate in the shared buffer.
UDP_CONNECTION_BUSY: The operation requested by the connection is busy has not been completed. The UDP endpoint to which the message was sent is probably already processing another request.
UDP_CONNECTION_CLOSED: The endpoint has been closed.
UDP_FAIL: Operation failed (no more information available).
UDP_HOST_UNREACHABLE: The IP stack could not find a route to the destination address.
UDP-MESSAGE_TOO_LONG: The UDP packet was too large for the intermediate router to process.
UDP_NETWORK_UNREACHABLE: The IP stack could not find a route to the network with the destination address.
UDP_OPERATION_INVALID: The requested operation is not allowed in the current endpoint state.
UDP_OPERATION_UNKNOWN: The requested operation was not recognized by the UDP endpoint.
UDP_PORT_UNREACHABLE: Not listening on the port specified for the connection.
UDP_PROTOCOL_UNREACHABLE: Destination host does not implement UDP.
UDP_SUCCESS: The operation was successful.
UDP_TIME_EXCEEDED: The IP assembly queue has timed out.
UDP_TTL_EXCEEDED: Destination host has exceeded TTL hops from source host (too many nodes between destination host and source host).
[0415]
UDPEndpointBaseMsg
It is defined as follows.

Here you specify which endpoints in the IPv4 protocol stack will receive the UDP service request and which objects will receive a response to that request. Requests for individual network services are sent in messages inherited from UDPEndpointBaseMsg.
[0416]
The following shows the dummy arguments.
error: (Output) The UDPEndpointError returned by the endpoint. See above for a list of errors.
module: (input) target endpoint.
operation (input): operation requested by the transmitting object.
Please refer to "UDP error" for the UDP error code of the return value. Related items include UDPEndpointBindMsg, UDPEndpointConnectMsg, UDPEndpointSendMsg, UDPEndpointReceiveMsg, and UDPEndpointCloseMsg.
[0417]
UDPEndpointBindMsg
It is defined as follows.

Here, set the local connection parameters. Local connection parameters identify the object as the destination of the UDP packet. After performing the bind operation, the object receives the packet only if the destination address and port are the same as the IP address and port number specified by the bind parameters. When sending data, specify the destination IP address and port number for each packet, unless the object has first performed a connection operation (specifying the destination of all packets). See UDPEndpointConnectMsg for more information. UDPEndpointBindMsg inherits from UDPEndpointBaseMsg.
[0418]
The following shows the dummy arguments here.
module: Indicates a reference to the destination module.
address: (input / output) A valid IP address on the local host. If you specify IP_ADDR_ANY, the object will receive packets sent to any IP address on the local host. This is useful for multihomed hosts with several interfaces at different addresses. If the host is not multihomed, the local IP address is returned. On a multi-homed host, if the object performs a connection operation after binding the endpoint, IP_ADDR_ANY is updated to a specific IP address.
port: (input / output) port number of the object. Specifying IP_PORT_ANY assigns a temporary port number to the object and returns a temporary port number when the endpoint is bound. This port number is 1024 or more.
Please refer to "UDP error" for the UDP error code of the return value. The related items include UDPEndpointBaseMsg and UDPEndpointConnectMsg.
[0419]
UDPEndpointConnectMsg
It is defined as follows.

Here you specify the destination IP address and port number for every packet sent by the object. Please execute this operation after sending UDPEndpointBindMsg. Once connected, the object does not need to specify the destination each time it sends a packet. UDPEndpointConnectMsg is inherited from UDPEndpointBaseMsg.
[0420]
The following shows the dummy arguments here.
module: Indicates a reference to the destination module.
address: (input) Specifies the IP address of the computer to which the packet is sent.
port: (input) Specifies the port number of the object that is the destination of the packet.
Please refer to "UDP error" for the UDP error code of the return value. The related items include UDPEndpointBaseMsg and UDPEndpointBindMsg.
[0421]
UDPEndpointSendMsg
It is defined as follows.

Here, data is sent via the UDP endpoint. All data sent by the object to the protocol stack should be stored in the shared memory buffer defined by the antSharedBuffer structure. The UDP endpoint responds to this message when data has been copied from the shared buffer to the IP stack internal memory buffer. UDPEndpointSendMsg inherits from UDPEndpointBaseMsg. If the endpoint is bound but not connected, specify the destination IP address and port number in this message. This information is not required if the endpoint is connected via UDPEndpointConnectMsg.
[0422]
The following shows the dummy arguments here.
module: Indicates a reference to the destination module.
address: (input) The IP address of the destination computer for the data. If the object has completed the connection operation, this dummy argument is ignored, and the IP address specified by UDPEndpointConnectMsg is used.
port: (input) port number of the destination computer for the data. If the object has completed the connection operation, this dummy argument is ignored, and the port number specified in UDPEndpointConnectMsg is used.
buffer: The position (in the shared buffer) where the data of the (input) transmission is stored.
size: (input) The transmission data size in byte units.
Please refer to "UDP error" for the UDP error code of the return value. The related items include UDPEndpointBaseMsg, UDPEndpointConnectMsg, and antSharedBuffer.
[0423]
UDPEndpointReceiveMsg
It is defined as follows.

Here, data is received from the UDP endpoint. All data that the object receives from the protocol stack is stored in a shared memory buffer defined by the antSharedBuffer structure. The UDP endpoint responds to this message when the data has been copied to the shared buffer. When the receive operation is completed, the actual number of bytes received by the dummy argument size returns the actual number of bytes received. If the received packet is larger than the specified size, the surplus data will be deleted. UDPEndpointReceiveMsg is inherited from UDPEndpointBaseMsg.
[0424]
The following shows the dummy arguments here.
module: Indicates a reference to the destination module.
buffer: (input) This is the location (in the shared buffer) where the received data is stored.
size: (input / output) Specify the maximum number of bytes to receive. Upon completion of the receive operation, this dummy argument returns the actual number of bytes received. If the received packet is larger than the size, the surplus data will be deleted.
address: (output) The source IP address of the received data.
port: (output) The source port of the received data.
Please refer to "UDP error" for the UDP error code of the return value. Also, here, the related items include UDPEndpointBaseMsg, UDPEndpointConnectMsg, and antSharedBuffer.
[0425]
UDPEndpointCloseMsg
It is defined as follows.

Here, we close the UDP endpoint. After sending this message, the object cannot send or receive data. The endpoint responds when the connection is completely closed. UDPEndpointCloseMsg inherits from UDPEndpointBaseMsg.
[0426]
The following shows the dummy arguments here.
module: Indicates a reference to the destination module.
For a description of the UDP error code returned, see "UDP Error." A related item is UDPEndpointBaseMsg.
[0427]
Chapter 9 DNS Reference
This chapter describes the DNS messages sent to IPStack when an object requests a DNS service. All messages are inherited from DNSEndpointBaseMsg.
DNS error
The following is a list of errors returned by the messages described in this chapter. Error values are defined in the enumeration type DNSEndpointError. When an object requests a network operation and receives a response from a DNS endpoint, examine the error field of the request (eg, DNSEndpointSetSERverAddressesMsg.error).
DNS_BUFFER_INVALID: Invalid use of shared buffer
DNS_CONNECTION_BUSY: The connection is busy and the requested operation has not been completed. The DNS endpoint to which the message was sent may already be processing another request.
DNS_CONNECTION_CLOSED: Connection closed.
DNS_FAIL: Operation failed (no further information is available).
DNS_HOST_NOT_FOUND: There is no binding information for the specified host name.
DNS_INDEX_INVALID: The specified index does not exist.
DNS_NO_DATA: There is no data record corresponding to the requested type.
DNS_NO_RECOVERY: An unrecoverable error has occurred.
DNS_OPERATION_INVALID: The requested operation is not allowed in the current state.
DNS_OPERATION_UNKNOWN: The requested operation was not recognized by the DNS endpoint.
DNS_SUCCESS: The operation was successful.
DNS_TRY_AGAIN: The requested host was not found. Or the server request failed.
[0428]
DNSEndpointBaseMsg
It is defined as follows.

This defines the basic message for every request for DNS network operation. Requests for individual network services are sent in messages inherited from DNSEndpointBaseMsg. See later in this chapter. The following shows the dummy arguments.
error: (output) Returns the result of the operation.
[0429]
In addition, as a related item, DNSEndpointSetServerAddressesMsg, DNSEndpointGetServerAddressesMsg, DNSEndpointSetDefaultDomainNameMsg, DNSEndpointGetDefaultDomainNameMsg, DNSEndpointGetHostByNameMsg, DNSEndpointGetHostByAddrMsg, DNSEndpointGetAddressMsg, DNSEndpointGetAliasMsg, is DNSEndpointCloseMsg the like.
[0430]
DNSEndpointSetServerAddressesMsg
It is defined as follows.

Here, register a list of DNS servers that the object will use to resolve domain names and IP addresses. This list specifies DNS servers by IP address. After listing, searches are sent to the server in list order. DNSEndpointSetServerAddressMsg is a DNSEndpointBaseMsg. Inherited from The following shows the dummy arguments here.
nscount: (input) The number of IP addresses to be registered.
addrList [MAXNS]: (input) A list of IP addresses to be registered.
Refer to "DNS Error" for the DNS error code of the return value. Related items include DNSEndpointBaseMsg, DNSEndpointGetServerAddressesMsg, and antSharedBuffer.
[0431]
DNSEndpointGetServerAddressesMsg
It is defined as follows.

Here we get a list of DNS servers that the object will use to resolve domain names and IP addresses. This list shows DNS servers by IP address. The address must be set in advance with DNSEndpointSetServerAddressesMsg. DNSEndpointGetServerAddressesMsg is inherited from DNSEndpointBaseMsg. The following shows the dummy arguments here.
nscount: (output) The number of registered IP addresses.
addrList [MAXNS]: (output) A list of IP addresses.
Refer to "DNS Error" for the DNS error code of the return value. Related items include DNSEndpointBaseMsg, DNSEndpointSetServerAddressesMsg, and antSharedBuffer.
[0432]
DNSEndpointSetDefaultDomainNameMsg
It is defined as follows.

Here you set the default domain name for the object. After registering the default domain name, any host name that is not fully specified will be automatically appended with this domain name. DNSEndpointSetDefaultDomainNameMsg is inherited from DNSEndpointBaseMsg. The following shows the dummy arguments here.
name [MAXDNAME]: (input) Default domain name. Domain names must end with null.
Refer to "DNS Error" for the DNS error code of the return value. Related items include DNSEndpointBaseMsg, DNSEndpointGetDefaultDomainNameMsg, and antSharedBuffer.
[0433]
DNSEndpointGetDefaultDomainNameMsg
It is defined as follows.

Now, get the default domain name for the object. Set the domain name in advance using DNSEndpointSetDefaultDomainNameMsg. DNSEndpointGetDefaultDomainNameMsg is inherited from DNSEndpointBaseMsg. The following shows the dummy arguments here.
name [MAXDNAME]: (Output) Default domain name. Domain names end in null.
Refer to "DNS Error" for the DNS error code of the return value. Related items include DNSEndpointBaseMsg, DNSEndpointSetDefaultDomainNameMsg, and antSharedBuffer.
[0434]
DNSEndpointGetHostByNameMsg
It is defined as follows.

Here, the list of the IP address of the host specified by the domain name and the domain name alias are acquired. This list, called the host entry, contains the address of the DNS server that returned the host entry, the first IP address in the list (official address), and the total number of IP addresses for that host, the first domain name in the list (official domain). Name), and the total number of domain name aliases for that host. If you want to get one of the different IP addresses or domain name aliases, please request them individually. For more information, see DNSEndpointGetAddressMsg and DNSEndpointGetAliasMsg. DNSEndpointGetHostByNameMsg is inherited from DNSEndpointBaseMsg. The following shows the dummy arguments here.
name [MAXDNAME]: (Input / Output) The domain name of the host whose entry you want to get. Domain names must end with null. If a domain name alias is specified, returns the official domain name of the host.
server_address: (output) The IP address of the DNS server that transmitted the host entry.
host_address: (output) This is the IP address of the host. If the host uses more than one IP address (multihomed), it returns the first IP address.
n_address: (output) The number of IP addresses of the host.
n_alias: (output) The number of domain name aliases of the host.
Refer to "DNS Error" for the DNS error code of the return value. Also, here, DNSEndpointBaseMsg, DNSEndpointGetHostByAddrMsg, DNSEndpointGetAddressMsg, DNSEndpointGetAliasMsg, and antSharedBuffer are related items.
[0435]
DNSEndpointGetHostByAddrMsg
It is defined as follows.

Here, a list of IP addresses and domain name aliases for the host specified by the IP address is obtained. This list, called the host entry, contains the address of the DNS server that returned the host entry, the first IP address in the list (official address) and the total number of IP addresses for that host, the first domain name in the list (official domain). Name) and the total number of domain name aliases for that host. If you want to get a different IP address or one of the domain name aliases, please request them individually. See DNSEndpointGetAddressMsg and DNSEndpointGetAliasMsg for more information. DNSEndpointGetHostByAddrMsg is inherited from DNSEndpointBaseMsg. The following shows the dummy arguments here.
host_address: (input / output) The IP address of the host. Returns the first IP address of the host, even if you specify a different IP address in the original message.
server_address: (output) The IP address of the DNS server that transmitted the host entry.
name [MAXDNAME]: (Output) The official domain name of the host. Domain names end with null.
n_address: (output) The number of IP addresses for the host.
n_alias: (Output) The number of domain name aliases for the host.
Refer to "DNS Error" for the DNS error code of the return value. Related items include DNSEndpointBaseMsg, DNSEndpointGetHostByNameMsg, DNSEndpointGetAddressMsg, DNSEndpointGetAliasMsg, and antSharedBuffer.
[0436]
DNSEndpointGetAddressMsg
It is defined as follows.

Here, one of the registered IP addresses for the specified host is obtained. However, you need to get the host entry before performing this operation. For more information, see DNSEndpointGetHostByNameMsg or DNSEndpointGetHostByAddrMsg. DNSEndPointGetAddressMsg is inherited from DNSEndpointBaseMsg. The following shows the dummy arguments here.
index: (input) The index of the IP address to be acquired. This index must be less than the n-address returned by DNSEndpointGetHostByNameMsg or DNSEndpointGetHostByByMersg when the host entry was previously received. If 0 is given, the first IP address in the host entry list will be returned.
address: (output) This is a host entry, and is an IP address of an index position.
Refer to "DNS Error" for the DNS error code of the return value. In addition, as related items, DNSEndpointBaseMsg, DNSEndpointGetHostByNameMsg, DNSEndpointGetHostByAddrMsg, DNSEndpointGetAliasMsg, and antSharedBuffer.
[0437]
DNSEndpointGetAliasMsg
It is defined as follows.

Here, we get one of the domain name aliases for the specified host. However, before doing this, get the host entry. For more information, see DNSEndpointGetHostByNameMsg or DNSEndpointGetHostByAddrMsg. DNSEndpointGetAliasMsg is inherited from DNSEndpointBaseMsg. The following shows the dummy arguments here.
index: (input) The index of the domain name alias you want to get. Must be less than the n-alias returned by DNSEndpointGetHostByNameMsg or DNSEndpointByAddrMsg when the host entry was previously received. If 0 is given, returns the official domain name of the host.
name [MAXDNAME]: (output) Host entry, which is a domain name alias at the index position.
Refer to "DNS Error" for the DNS error code of the return value. Related items include DNSEndpointBaseMsg, DNSEndpointGetHostByNameMsg, DNSEndpointGetHostByAddrMsg, DNSEndpointGetAliasMsg, and antSharedBuffer.
[0438]
DNSEndpointCloseMsg
It is defined as follows.
DNSEndpointCloseMsg ();
Here, we close the DNS endpoint. After sending this message, the object cannot send or receive data. The endpoint replies when the connection is completely closed. DNSEndpointCloseMsg is inherited from BaseMsg. Refer to "DNS Error" for the DNS error code of the return value. A related item is DNSEndpointBaseMsg.
[0439]
Chapter 10 IP Reference
Describes the IP message that the object sends to IPStack. This message is used when requesting network services. All messages are IPEndpointBaseMsg. Inherited from
IP error
The following is the error list returned by the messages in this chapter. Error values are defined in the IPEndpointError enumeration. When an object requests a network operation and receives a response from its IP endpoint, examine the error field of the request (eg, IPEndpointBindMsg.error).
IP_BUFFER_INVALID: Invalid use of shared buffer.
IP_CONNECTION_BUSY: The connection is busy and the requested operation has not been completed. The IP endpoint to which the message was sent may already be processing another request.
IP_CONNECTION_CLOSED: Connection closed.
IP_FAIL: Operation failed (no more information available).
IP_INVALID_PROTOCOL: The specified protocol identifier is not valid.
IP_OPERATION_INVALID: The requested operation is not allowed in the current situation.
IP_OPERATION_UNKNOWN: The requested operation was not recognized by the IP endpoint.
IP_PACKETSIZE: The specified packet size is incorrect.
IP_SUCCESS: Operation was successful.
[0440]
IP packet type
IP endpoints can send and receive various packets as described below. However, normal IP packets are of the IP_DATA type. Other types are for ICMP packets.
IP_DATA: normal IP data
IP_HOST_UNREACHABLE: (ICMP packet) Unable to reach host.
IP_MESSAGE_TOO_LONG: (ICMP packet) message too long or failed to split at any point during transmission.
IP_NETWORK_UNREACHABLE: (ICMP packet) The network cannot be reached.
IP_PORT_UNREACHABLE: (ICMP packet) The requested port could not be reached.
IP_PROTOCOL_UNREACHABLE: (ICMP packet) The requested protocol was not on the target host.
IP_TIME_EXCEEDED: (ICMP packet) Packet assembly timed out.
IP_TTL_EXCEEDED: (ICMP packet) The TTL of the packet expired during transmission.
[0441]
IPEndpointBaseMsg
Members are:

Here, a basic message is defined for all IP network operation requests. Requests for individual network services are sent in messages inherited from IPEndpointBaseMsg. See later in this chapter. The following shows the dummy arguments.
error: (output) Returns the result of the operation.
See "IP Error" for an explanation of the returned IP error code. Related items include IPEndpointBindMsg, IPEndpointSendMsg, IPEndpointReceiveMsg, and IPEndpointCloseMsg.
[0442]
IPEndpointBindMsg
Members are:

Here we bind the endpoint to a specific protocol. All packets sent or received by the object through this endpoint are treated as originating from the specified protocol. The endpoint responds to this message when the protocol is bound so that it can send and receive IP packets. IPEndpointBindMsg is an IPEndpointBaseMsg. Inherited from However, endpoints cannot be bound to TCP or UDP protocols because they are already bound in the protocol stack. Even if you try to bind, the error IP_INVALID_PROTOCOL is returned. Endpoints can be bound to ICMP. ICMP processes all recognized packets as usual. However, it forwards all unrecognized packets to the bound endpoint. The following shows the dummy arguments.
protocol: (input) The protocol to bind to the endpoint. Each protocol is identified by an integer less than 256.
Please refer to "IP Error" for the return value IP error code. A related item is IPEndpointBaseMsg.
[0443]
IPEndpointSendMsg
Members are:

Here, the IP packet is sent. Data sent by the object to the protocol stack should be stored in the shared memory buffer defined by the antSharedBuffer structure. When data is copied from the shared buffer to the IPStack internal memory buffer, the IP endpoint responds to the message. IPEndpointSendMsg is an IPEndpointBaseMsg. Inherited from The following shows the dummy arguments here.
type: (input) type of packet to be transmitted A normal IP packet is of the IP_DATA type.
buffer: (input) The position where the packet to be transmitted is stored (in the shared buffer).
size: (input) The size of the packet to send, in bytes.
Please refer to "IP Error" for the return value IP error code. Related items include IPEndpointBaseMsg and antSharedBuffer.
[0444]
IPEndpointReceiveMsg
Members are:

Here, the IP packet is received. The data that the object receives from the protocol stack is stored in a shared memory buffer defined by the antSharedBuffer structure. When the data has been copied to the shared buffer, the IP endpoint responds to the message. The Size parameter returns the actual number of bytes received. If the received packet is larger than the shared buffer, only part of the packet will be stored in the buffer and an IP_PACKETSIZE error will be returned. IPEndpointReceiveMsg is the IPEndpointBaseMsg. Inherited from The following shows the dummy arguments here.
type: (output) The type of the received packet. Normal IP packets are of type IP_DATA.
buffer: (input) The position where the received packet is stored (in the shared buffer).
size: (input / output) Specify the maximum number of bytes to receive. When the receive operation completes and the endpoint responds to the object, the dummy argument returns the number of bytes actually received. If the received packet is larger than the shared buffer, only part of the packet will be stored in the buffer and an IP_PACKETSIZE error will be returned.
Please refer to "IP Error" for the return value IP error code. Related items include IPEndpointBaseMsg and antSharedBuffer.
[0445]
IPEndpointCloseMsg
Members are:
IPEndpointCloseMsg ();
Here, close the IP connection. After sending this message, the object cannot send or receive data. When the connection is completely closed, the endpoint responds. IPEndpointCloseMsg is inherited from IPEndpointBaseMsg.
Please refer to "IP Error" for the return value IP error code. A related item is IPEndpointBaseMsg.
[0446]
In the above description regarding the Internet protocol, the “ANT environment” indicates an OPEN-R system layer object that provides a network service to the object. The ANT environment communicates with objects using normal message passing. The ANT environment also communicates directly with device drivers. This device driver exchanges data over the physical network. “Datagram” is a UDP protocol and corresponds to a packet. "DNS" is an IPv4 protocol stack that operates above the UDP layer. Provides services for setting, obtaining, and converting Internet domain names and IP addresses. The "endpoint" is for the object to communicate with the ANT environment by message passing. Endpoints are at the top of the protocol stack. An object has one endpoint for each open network connection. Endpoints are created dynamically as objects request new network connections. The object sends a request for a new endpoint to the endpoint factory, which creates the endpoint.
[0447]
"Internet Protocol (IP)" is a network protocol that plays a role in transmitting packets over a network. In the IPv4 protocol stack, IP is the lowest layer. Usually, objects do not communicate directly with IP. Instead, the object opens a connection to a higher layer of IP, such as TCP or UDP. However, depending on the object, you can use the IP layer directly. For example, if you want to add a new protocol without programming in the ANT environment, you can describe the protocol as an object that communicates directly with the IP layer. Internet Protocol version 4 (IPv4) Protocol stack is a protocol stack in the ANT environment and provides TCP, UDP, DNS and IP network protocols.
"SDU (Service Data Unit)" is a basic data container in the ANT environment. An SDU is a pointer to a series of data cells in the SDU pool. The SDU contains the data being sent to the network. This is called a Protocol Data Unit (PDU) in the OSI standard. The "SDU pool" is a memory buffer in the ANT environment that stores data processed by the protocol stack. The ANT environment allocates service data units (SDUs) in an SDU pool.
[0448]
<Installation Guide>
Chapter 1 Introduction
1.1 Preparation
The OPEN-R SDK described above operates on a Windows 2000, Professional / XP (all are registered trademarks) platform. The OPEN-R SDK runs on other operating systems other than the Windows environment. For this purpose, standard Unix commands such as sh and cp, and mips cross development such as perl, GNU make, GNU binutils, gcc, and newlib are used. Environment is required. These tools are compatible with the normal Unix environment. Binaries of these mips cross development environments that run on Cygwin on Windows can be downloaded from the OPEN-R SDK website. To run these tools in another Unix environment, see "2.2 gcc". Other than the Windows environment, we provide a shell script that automatically generates a binary tool from source code. This script and OPEN-R SDK have been confirmed to work properly on Linux.
[0449]
Further, in order to develop software using the OPEN-R SDK, the following hardware is required. CPU: Pentium 233 MHz or more, Memory: 64 MB or more, Hard Disk: Free space of 200 MB or more, Memory Stick Reader Writer: Internal or external to PC, AIBO ERS-210, ERS-220, ERS-210A, ERS-220A . Further, as the wireless LAN environment, the PC needs one of (a) a wireless LAN card compliant with IEEE802.11b, (b) a wired LAN card and an access point compliant with IEEE802.11b. On the AIBO side, an AIBO wireless LAN card (ERA-201D1) and an AIBO programming memory stick are required. In the software development using the OPEN-R SDK, memory sticks other than the AIBO programming memory stick cannot be used.
[0450]
1.2 Download
Below is a list of download files.
・ OPEN-R SDK
For example, the OPEN-R SDK body (OPEN_R_SDK-1.1.3-r1.tar.gz), a sample program (OPEN_R_SDK-sample-1.1.3-r1.tar.gz), a Japanese manual (OPEN_R_SDK-docJ) -1.1.3-r1.tar.gz) and an English manual (OPEN_R_SDK-docE-1.1.3-r1.tar.gz), which can be downloaded via the Internet.
・ Development tool in Windows environment
In addition, as development tools in the Windows environment, Cygwin (cygwin-packages-1.3.10-bin.exe) and a tool in the MIPS cross development environment (mipsel-devtools-3.0.4-bin-r1) .Tar.gz).
-ERS-210 user utility
upgrade-OPEN_R-1.1.3-r1. tar. gz ... Flash update for ERS-210
·source file
cygwin-packages-1.3.10-src. tar. gz ... source of Cygwin
binutils-2.12. tar. gz ... source of binutils
gcc-3.0.4. tar. gz ... source of gcc
newlib-1.9.0. tar. gz ... newlib source
build-devtools-3.0.4-r1. sh ... Shell script for building the above three files
The numbers in the above file names indicate the version numbers. If the file changes, the version number changes.
[0451]
Chapter 2 Installation
2.1 Cygwin
If you have a Windows environment, install Cygwin first. With Cygwin, standard Unix commands work on Windows. Install Cygwin by the following procedure.
1. cygwin-packages-1.3.10-bin. Double-click exe.
2. When a folder for executing Unzip is specified and [Unzip] is clicked, a cygwin-packages-1.3.10 directory is created. Execute exe.
3. setup. exe version is displayed. Click [Next->].
4. Select [Install from Local Directory] and click [Next->].
5. Specify the directory to install Cygwin. Unless otherwise required, keep the specification of 'C: \ cygwin'. Select [Unix] for the text file type and click [Next->].
6. setup. Specify the directory where the exe is located and click [Next->].
7. The package contents selection screen is displayed. Leave the default settings and click Next->.
[0452]
However, this package contains only the minimum tools required to use the OPEN-R SDK. To add a new tool, setup. exe, and select [Install from Internet] in step 4.
[0453]
2.2 gcc
Unzip the package with / usr / local (C: \ cygwin \ usr \ local) on Cygwin. In the following description, / usr / local on Cygwin will be simply described as / usr / local, and will not be described as c: \ cygwin \ usr \ local. Install gcc according to the following procedure. In the following, mapsel-devtools-3.0.4-bin-r1. tar. Suppose you put gz in / usr / local.
1. Unzip the package. Here, / xxx is the downloaded directory.
cd / usr / local
tar xzf /xxx/mipsel-devtools-3.0.4-bin-r1. tar. gz
/ Usr / local / OPEN_R_SDK directory is created, and the following tools and libraries for mipel-linux are installed in it.
GNU binutils-2.12
GNU gcc-3.0.4
newlib-1.9.0
Although Linux is used as the target name here, it does not mean that Linux runs on AIBO. When using the Unix environment, build-devtools-3.0.4. Executing sh automatically generates a development environment. build-devtools-3.0.4. The following files are placed in the same directory as sh. build-devtools-3.0.4. Please execute sh.
binutils-2.12. tar. gz
gcc-3.0.4. tar. gz
newlib-1.9.0. tar. gz
[0454]
2.3 OPEN-R SDK
Subsequently, the OPEN-R SDK body is installed in the following procedure.
1. Unzip the package (/ xxx is the downloaded directory).
cd / usr / local
tar xzf /xxx/OPEN_R_SDK-1.1.1.3-r1. tar. gz
Here, the / usr / local / OPEN_R_SDK / OPEN_R directory is created.
[0455]
2.4 Sample program
Next, install the sample program according to the following procedure.
Move to the directory of your choice and unzip the package (/ mydir is the directory of your choice, / xxx is the directory where you downloaded it).
cd / mydir
tar xzf /xxx/OPEN_R_SDK-sample-1.1.3-r1. tar. gz
Here, a sample directory is created, and several sample programs are installed in it.
[0456]
2.5 Updating the flash ROM built into AIBO
In order to run the program created with OPEN-R SDK, it is necessary to update the flash ROM in AIBO ERS-210. However, the AIBO is' OPEN-R Ver. 1.1.2 'or' OPEN-R Ver. Flash ROM does not need to be updated if it corresponds to 1.1.3 'or ERS-220, ERS-210A, and ERS-220A. Update the built-in flash ROM in the following procedure.
1. Move to the directory of your choice and unzip the package (/ mydir is the directory of your choice, / xxx is the directory where you downloaded it).
cd / mydir
tar xxf /xxx/upgrade-OPEN-R_1.1.3-r1. tar. gz
Here, the Upgrade directory is created. The procedure for updating the flash ROM is described in README_J. It is described in TXT.
[0457]
Chapter 3 Building and Running HelloWorld
Subsequently, the success of the installation is confirmed by building and executing HelloWorld of the sample program. Hello World is HELLO. BIN and POWERMON. It consists of an OPEN-R object corresponding to the BIN and outputs 'Hello World' to the wireless console (the OPEN-R object is described as an object in the following description). The HelloWorld directory contains the following subdirectories:
HelloWorld / HelloWorld: Source of HelloWorld object
HelloWorld / MS: A file to be placed on the AIBO programming memory stick. At first OBJECT. Only the CFG will copy the executable file later.
[0458]
3.1 Build
Build the sample program according to the following procedure.
1. Build the executable.
cd sample / HelloWorld
make
make install
Here, the executable is generated and copied to the MS directory. When the OPEN-R SDK is installed in a directory other than / usr / local, the path of the OPEN-R SDK directory is specified as follows.
(/ Mydir is the directory where OPEN-R SDK is installed).
make PREFIX = / mydir / OPEN_R_SDK
The file name is in 8 + 3 format (xxxxxxxxx.xxx). The files are gzip'd. gzip saves memory on the AIBO Programming Memory Stick, although it is not required.
[0459]
3.2 Execution
3.2.1 Execution in wireless LAN environment
Set the wireless LAN environment and execute the program according to the following procedure.
1. Copy the following two OPEN-R directories to an empty AIBO programming memory stick (/ mydir is the directory where the sample program is installed).
/ Usr / local / OPEN_R_SDK / OPEN_R / MS / WCONSOLE / memprot / OPEN-R
/ Mydir / sample / HelloWorld / MS / OPEN-R
2. WLANCONF. On the AIBO programming memory stick. Edit TXT and configure the AIBO side wireless LAN settings. For details, refer to “3.2.2 Setting WLANCONF.TXT”.
3. Attach the AIBO wireless LAN card to AIBO.
4. Set the wireless LAN environment on the PC. There are two ways to connect a PC and AIBO via wireless LAN: one with an access point and one without. To check whether the AIBO is connected to the network, the following command may be executed.
ping (AIBO IP address)
5. To connect to the AIBO wireless console from a PC, start the telnet program on the PC as follows. AIBO's wireless console uses the telnet protocol on TCP port number 59000 (other telnet programs may be used).
telnet (AIBO IP address) 59000
6. Insert the AIBO programming memory stick into AIBO and launch AIBO. After a series of system information is output '! ! ! Hello World! ! ! If the 'character string is displayed, it is working properly.
7. Press AIBO's pause button to shut down.
[0460]
3.2.2 WLANCONF. TXT settings
Two types of wireless LAN setting files, WLANDFLT.COM, are stored in / OPEN-R / SYSTEM / CONF / of the AIBO programming memory stick. TXT and WLANCONF. There is TXT. WLANDELT. Do not edit TXT because the default setting of AIBO wireless LAN card is set. WLANCONF. TXT is a file for user settings. When AIBO starts up, WLANCONF. First look at TXT and use the information in the file if it exists. If the file does not exist, WLANDFLT. Use TXT information. WLANDFLT. TXT to WLANCONF. Copy and edit with the TXT file name. WLANCONF. The contents of TXT are set as follows by default.
HOSTNAME = AIBO
ETHER_IP = 10.0.1.100
ETHER_NETMASK = 255.255.255.0
IP_GATEWAY = 10.0.1.1
ESSID = AIBONET
WEPENABLE = 1
WEPKEY = AIBO2
APMODE = 2
CHANNEL = 3
The meaning of each item is as follows.
HOSTNAME: Specify the name to be used on the wireless network for AIBO. Specify a character string of up to 8 alphanumeric characters.
ETHER_IP: Specify the IP address used by AIBO.
ETHER_NETMASK: Specify the IP subnet mask.
IP_GATEWAY: Specify the IP address of the gateway. If there is no gateway on the network, set the same IP address as ETHER_IP.
ESSID: Specify the name of the wireless network. Specify up to 32 alphanumeric characters.
WEPENABLE: Specify whether to use WEP (wireless encryption system). The value is “0” when not used, and “1” when used.
WEPKEY: (Specifies the WEPkey (wireless encryption key). Specify with 5 single-byte alphanumeric characters.
APMODE: Specify the wireless LAN mode of AIBO. Specify "0" for connection in Ad Hoc Demo Mode, "1" for connection in Infrastructure Mode, "2" for automatic connection in the order of Infrastructure Mode, Ad Hoc Demo Mode.
CHANNEL: Specify the channel to be used in Ad Hoc Demo Mode. Please specify a numerical value from 1-11.
[0461]
In a case where the PC in which the wireless LAN card is inserted and AIBO are directly connected without using an access point (IBSS Peer-to-Peer Mode or Ad Hoc Demo Mode), first, ESSID, WEPENABLE, and WEPKEY are connected to PC. Make the same settings. When the connection is performed in the IBSS Peer-to-Peer Mode, APMODE = 1 is specified. When connecting with Ad Hoc Demo Mode, specify APMODE = 0 and CHANNEL should match the PC setting.
[0462]
When connecting a PC and AIBO using a wireless LAN access point, the ESSID and WEPKEY are set to the same settings as the access point. Specify APMODE = 1 to operate AIBO in Infrastructure Mode.
[0463]
<ERS-210>
Further, a specific specification example of the robot device described above as AIBO (registered trademark) that enables interaction using the OPEN-R SDK is shown below.
Chapter 1 ERS-210 External Specifications
1.1 ERS-210 outline
External view and external dimensions
An example of a model specification of a robot device to which the present invention is applied will be described with reference to the drawings.
[0464]
This robot device is a legged mobile robot that includes a head, an upper limb, a trunk, and a lower limb, and uses only the upper limb and the lower limb or only the lower limb as a moving means. The legged mobile robot includes a pet-type robot that simulates the body mechanism and movement of a four-legged animal, and a robot device that simulates the body mechanism and movement of a bipedal animal that uses only lower limbs as a means of movement. However, the robot device shown as the present embodiment is a quadruped walking type legged mobile robot. Although not described in this specification, it is needless to say that the present invention can also be applied to a biped walking type legged mobile robot.
[0465]
FIG. 26 shows a view from the top, a view from the front of the sky, and a view from the side of the robot apparatus (hereinafter referred to as ERS-210). Hereinafter, the ERS-210 will be described with reference to the drawings. The ERS-210 is a so-called pet robot having a shape imitating an "animal" as shown in FIG. The ERS-210 is configured such that each leg unit is connected to the front, rear, left and right of the body unit, and a head unit is connected to the front end of the body unit. A tail portion is provided at the rear end of the body unit. The outer dimensions of the ERS-210 are described in FIGS. 27 and 28.
This robot device is a practical robot that supports human activities in various situations in the living environment and other everyday life, and can act according to the internal state (anger, sadness, joy, enjoyment, etc.), and walk on four legs. It is an entertainment robot that can express basic actions performed by animals. This robot apparatus particularly has a head, a body, an upper limb, a lower limb, and the like. A number of actuators and potentiometers corresponding to the degree of freedom of movement are provided at a portion corresponding to a connection portion and a joint of each portion, and a target operation can be expressed by control of the control unit.
[0466]
Further, the ERS-210 includes an imaging unit for acquiring a surrounding situation as image data, various sensors for detecting an externally applied action, and various types for detecting a physical action and the like externally received. A switch and the like are provided. A small CCD (Charge-Coupled Device) camera is used for the imaging unit. The sensors include an angular velocity sensor for detecting an angular velocity, a distance sensor for measuring a distance to an object imaged by a CCD camera, and the like. The various switches include a push-type switch that mainly detects contact by the user, an operation switch that allows an operation input from the user, and the like. These various sensors and various switches are installed at appropriate locations outside or inside the robot device.
[0467]
1.2 Movable range
Next, the movable part of the ERS-210 will be described.
1.2.1 Head
FIG. 29 shows a movable portion of the head and its movable range. On the head, the neck, ears, and jaw are movable. The degree of freedom of each part is such that the neck has three degrees of freedom of pan, tilt, and roll, each ear has one degree of freedom, and the chin has one degree of freedom. The entire head has a total of six degrees of freedom.
[0468]
1.2.2 Legs
FIG. 30 shows a movable portion of the leg and its movable range. The legs have movable hips, shoulders, and knees. The degrees of freedom of each part are three degrees of freedom for the front legs (waist: one degree of freedom, shoulders: one degree of freedom, knees: one degree of freedom), and hind legs are three degrees of freedom. Each has three degrees of freedom (waist: one degree of freedom, shoulder: one degree of freedom, knee: one degree of freedom), and the entire leg has a total of 12 degrees of freedom.
[0469]
1.2.3 Tail
FIG. 31 shows the movable range of the tail. The tail has a movable tail and two degrees of freedom. Note that the initial position is controlled to be 15 degrees.
[0470]
1.3 Device layout diagram
1.3.1 Output device
The output device of the ERS-210 will be described. FIG. 32 shows a schematic position of an output device provided in the ERS-210. The head of the ERS-210 is provided with a mode lamp and an eye lamp LED (4 red, 2 green) for informing the mode and state. A speaker is provided at the front position of the head, and a chest lamp (green or orange) is provided at the front position of the chest. Further, the tail is provided with a tail LED (blue, orange). In addition, an LED for time display, a memory stick access confirmation lamp, a piezoelectric buzzer for a start-up sound and a shutdown sound, and the like are provided inside the main body.
[0471]
1.3.2 Input device
The input device of the ERS-210 will be described. FIG. 33 shows a schematic position of the input device provided in the ERS-210. The head of the ERS-210 is provided with a head sensor, a distance sensor, a chin sensor, and stereo microphones at left and right ear positions. A color CCD camera is provided at the front position of the head, and a pause button for stopping operation is provided at the front position of the chest. A back sensor is provided on the back of the body, and a meat ball sensor is provided on the sole of the leg. Further, an acceleration sensor, a vibration sensor, a temperature sensor, a clock (setting switch), a PC card insertion slot, and a memory stick insertion slot are provided inside the main body.
[0472]
1.4 Configuration of each part
1.4.1 ERS-210 whole
The overall configuration of the ERS-210 will be described. FIG. 34 shows how the entire ERS-210 is assembled. In the ERS-210, a head unit, left and right front leg units, left and right rear leg units, and a tail unit are assembled to a main body core unit having an OPEN-R bus connection terminal.
[0473]
1.4.2 ERS-210 head
The ERS-210 head unit will be described. FIG. 35 shows the ERS-210 head from which the external protective housing has been removed. The head of ERS-210 has a head sensor, left and right ears, LED board, color camera, motor for neck roll, motor for opening and closing the chin, motor for neck pan, motor for neck tilt , A pause button for stopping the operation is provided.
[0474]
1.4.3 ERS-210 leg
The ERS-210 leg unit will be described. FIG. 36 shows the ERS-210 leg from which the external protective housing has been removed. A drive motor and a potentiometer are provided for each joint of the waist (J1), shoulder (J2), and knee (J3) on the legs of the ERS-210. A foot ball sensor is attached to the sole of the foot. The OPEN-R bus connection terminal may be provided in the leg unit.
[0475]
Chapter 2 ERS-210 Joint
2.1 CPC Primitive Locator List
Next, the names of the respective parts used when describing the code of the program are listed. In the following, the site indicated by the CPC Primitive Locator is shown after the CPC Primitive Locator.
head
PRM: / r1 / c1-Joint2: j1 ... neck tilt
PRM: / r1 / c1 / c2-Joint2: j2 ... neck pan
PRM: / r1 / c1 / c2 / c3-Joint2: j3 ... neck roll
PRM: / r1 / c1 / c2 / c3 / c4-Joint2: j4 ... mouth
PRM: / r1 / c1 / c2 / c3 / f1-Sensor: f1 Head sensor (rear)
PRM: / r1 / c1 / c2 / c3 / f2-Sensor: f2 ... head sensor (front)
PRM: / r1 / c1 / c2 / c3 / c4 / s5-Sensor: s5 ... chin sensor
PRM: / r1 / c1 / c2 / c3 / p1-Sensor: p1 Distance sensor
PRM: / r1 / c1 / c2 / c3 / m1-Mic: M1 ... stereo microphone
PRM: / r1 / c1 / c2 / c3 / s1-Speaker: S1 ... Speaker
PRM: / r1 / c1 / c2 / c3 / i1-FbkImageSensor: F1 ... color camera
PRM: / r1 / c1 / c2 / c3 / e1-Joint3: j5 ... left ear
PRM: / r1 / c1 / c2 / c3 / e2-Joint3: j6 ... right ear
PRM: / r1 / c1 / c2 / c3 / 11-LED2: 11: eye lamp (lower left)
PRM: / r1 / c1 / c2 / c3 / 12-LED2: 12 ... Eye lamp (middle left)
PRM: / r1 / c1 / c2 / c3 / 13-LED2: 13 ... Eye lamp (upper left)
PRM: / r1 / c1 / c2 / c3 / 14-LED2: 14 ... Eye lamp (lower right)
PRM: / r1 / c1 / c2 / c3 / 15-LED2: 15 ... Eye lamp (middle right)
PRM: / r1 / c1 / c2 / c3 / 16-LED2: 16 ... Eye lamp (upper right)
PRM: / r1 / c1 / c2 / c3 / 17-LED2: 17 ... mode lamp
[0476]
Left front leg
PRM: / r2 / c1-Joint2: j1 ... hip joint
PRM: / r2 / c1 / c2-Joint2: j2 ... shoulder joint
PRM: / r2 / c1 / c2 / c3-Joint2: j3 ... knee joint
PRM: / r2 / c1 / c2 / c3 / c4-Sensor: s4 ... meat ball sensor
Left hind leg
PRM: / r3 / c1-Joint2: j1 ... hip joint
PRM: / r3 / c1 / c2-Joint2: j2 ... shoulder joint
PRM: / r3 / c1 / c2 / c3-Joint2: j3 ... knee joint
PRM: / r3 / c1 / c2 / c3 / c4-Sensor: s4 ... meat ball sensor
Right front leg
PRM: / r4 / c1-Joint2: j1 ... hip joint
PRM: / r4 / c1 / c2-Joint2: j2 ... shoulder joint
PRM: / r4 / c1 / c2 / c3-Joint2: j3 ... knee joint
PRM: / r4 / c1 / c2 / c3 / c4-Sensor: s4 ... meat ball sensor
Right hind leg
PRM: / r5 / c1-Joint2: j1 ... hip joint
PRM: / r5 / c1 / c2-Joint2: j2 ... shoulder joint
PRM: / r5 / c1 / c2 / c3-Joint2: j3 ... knee joint
PRM: / r5 / c1 / c2 / c3 / c4-Sensor: s4 ... meat ball sensor
[0477]
tail
PRM: / r6 / c1-Joint2: j1 ... tail bread
PRM: / r6 / c2-Joint2: j2 ... tail tilt
RPM: / r6 / 11-LED2: 11: tail lamp (blue)
RPM: / r6 / 12-LED2: 12 ... Tail lamp (orange)
PRM: / r6 / t1-Sensor: t1 Temperature sensor
PRM: / r6 / s1-Sensor: s1 ... back sensor
[0478]
Acceleration sensor
PRM: / a1-Sensor: a1... Y-axis (front-back direction, front direction is positive)
PRM: / a2-Sensor: a2 ... x-axis (right and left direction is positive)
PRM: / a3-Sensor: a3... Z-axis (vertical direction, upper direction is positive)
[0479]
Subsequently, the correspondence between the index number of OSsensorFrameVectorData and CPC Primitive Locator is shown. In the following, following the index number, the corresponding CPC Primitive Locator is shown.
0 PRM: / r1 / c1-Joint2: j1
1 PRM: / r1 / c1 / c2-Joint2: j2
2 PRM: / r1 / c1 / c2 / c3-Joint2: j3
3 PRM: / r1 / c1 / c2 / c3 / f1-Sensor: f1
4 PRM: / r1 / c1 / c2 / c3 / f2-Sensor: f2
5 PRM: / r1 / c1 / c2 / c3 / p1-Sensor: p1
6 PRM: / r1 / c1 / c2 / c3 / c4-Joint2: j4
7 PRM: / r1 / c1 / c2 / c3 / c4 / s5-Sensor: s5
8 PRM: / r2 / c1-Joint2: j1
9 PRM: / r2 / c1 / c2-Joint2: j2
10 PRM: / r2 / c1 / c2 / c3-Joint2: j3
11 PRM: / r2 / c1 / c2 / c3 / c4-Sensor: s4
12 PRM: / r3 / c1-Joint2: j1
13 PRM: / r3 / c1 / c2-Joint2: j2
14 PRM: / r3 / c1 / c2 / c3-Joint2: j3
15 PRM: / r3 / c1 / c2 / c3 / c4-Sensor: s4
16 PRM: / r4 / c1-Joint2: j1
17 PRM: / r4 / c1 / c2-Joint2: j2
18 PRM: / r4 / c1 / c2 / c3-Joint2: j3
19 PRM: / r4 / c1 / c2 / c3 / c4-Sensor: s4
20 PRM: / r5 / c1-Joint2: j1
21 PRM: / r5 / c1 / c2-Joint2: j2
22 PRM: / r5 / c1 / c2 / c3-Joint2: j3
23 PRM: / r5 / c1 / c2 / c3 / c4-Sensor: s4
24 PRM: / r6 / c1-Joint2: j1
25 PRM: / r6 / c2-Joint2: j2
26 PRM: / r6 / t1-Sensor: t1
27 PRM: / r6 / s1-Sensor: s1
28 PRM: / a1-Sensor: a1
29 PRM: / a2-Sensor: a2
30 PRM: / a3-Sensor: a3
[0480]
2.2 Limit value of joint movement
2.2.1 Single joint limit
The soft limit of each joint will be described. The soft limit of the leg J1 is −117 ° to 117 °, the soft limit of J2 is −11 ° to 89 °, and the soft limit of J3 is −27 ° to 147 °. However, the mechanical limit of the leg J1 is −120 ° to 120 °, the mechanical limit of the leg J2 is −14 ° to 92 °, and the mechanical limit of the leg J3 is −27 ° to 147 °. It is.
[0481]
The soft limit of the head is −82 ° to 43 ° for the neck tilt, −89.6 ° to 89.6 ° for the pan, −29 ° to 29 ° for the neck roll, and the mouth (chin). ) Opening and closing is from -47 ° to -3 °. However, as for the mechanical limits, the neck tilt is -85 ° to 46 °, the neck pan is −92.6 ° to 92.6 °, the neck roll is −32 ° to 32 °, and the mouth (chin) Opening and closing is -50 ° to 0 °.
[0482]
The soft limits of the tail portion are -22 to 22 degrees for pan and -22 to 22 degrees for tilt. However, as for the mechanical limit, the pan is −25 ° to 25 °, and the tilt is −25 ° to 25 °.
[0483]
2.2.2 Soft Joint Limit of Two Legs
FIG. 37 shows the minimum values of the angle limit of the J2 front leg and the angle limit of the J2 rear leg when the angle of J1 changes. In the figure, the unit is degree (°).
[0484]
2.2.3 4-joint soft limit of head
The relationship between the limits of each joint of the head will be described below. The movable range of the roll and the mouth (jaw) is set within the range defined in the area of the tilt axis and the pan axis in FIG. The neck pan is symmetrical on the right. However, in the following description, the unit is degrees (°).
In the area A, -25 ≦ roll ≦ 0 and mouse = −3
In the case of the B region, roll = 0 and mouse = −3
In the case of the C region, −15 ≦ roll ≦ 10 and mouse = −3
In the case of the D region, -29 ≦ roll20 and −30 ≦ moth-3
In the E region, −20 ≦ roll ≦ 29 and −20 ≦ moth ≦ −3
In the F region, −20 ≦ roll ≦ 20 and −30 ≦ mouse ≦ −3
In the G region, −20 ≦ roll ≦ 29 and −30 ≦ moth ≦ −3
In the case of the H region, −20 ≦ roll ≦ 29 and −47 ≦ moth ≦ -3
In the case of the I region, -29≤roll≤29 and -47≤moth≤-3
In the case of the K region, −15 ≦ roll ≦ 29 and −30 ≦ moth ≦ −3
In the L region, −13 ≦ roll ≦ 29 and −30 ≦ moth ≦ −3
In the case of the M region, −15 ≦ roll ≦ 20 and −10 ≦ moth ≦ −3
In the N region, 2 ≦ roll ≦ 20 and −10 ≦ moth ≦ −3
In the O region, −7 ≦ roll ≦ 29 and −30 ≦ moth ≦ −3
[0485]
2.3 Servo gain
FIG. 39 shows the default servo gain of the joint of the ERS-210. Here, the values of PSHIFT, ISHIFT, and DSHIFT cannot be changed because they are fixed values.
[0486]
Chapter 3 Output Devices
3.1 LED
Next, the names of output devices used when describing the code of the program are listed. In the following, following the CPC Primitive Locator, a portion (LED device) indicated by the CPC Primitive Locator is shown.
PRM: / r1 / c1 / c2 / c3 / 11-LED2: 11: eye lamp (lower left)
PRM: / r1 / c1 / c2 / c3 / 12-LED2: 12 ... Eye lamp (middle left)
PRM: / r1 / c1 / c2 / c3 / 13-LED2: 13 ... Eye lamp (upper left)
PRM: / r1 / c1 / c2 / c3 / 14-LED2: 14 ... Eye lamp (lower right)
PRM: / r1 / c1 / c2 / c3 / 15-LED2: 15 ... Eye lamp (middle right)
PRM: / r1 / c1 / c2 / c3 / 16-LED2: 16 ... Eye lamp (upper right)
PRM: / r1 / c1 / c2 / c3 / 17-LED2: 17 ... mode lamp
RPM: / r6 / 11-LED2: 11: tail lamp (blue)
RPM: / r6 / 12-LED2: 12 ... Tail lamp (orange)
3.2 Speaker
The CPC Primitive Locator is PRM: / r1 / c1 / c2 / c3 / s1-Speaker: S1. The sampling frequency of this speaker is 8000 Hz, the number of quantization bits is 8-bit linear PCM, and the channel is one channel (monaural). The parameters that can be set in OPENR :: ControlPrimitive () are shown below.

The sound types that can be set are ospksndMONO8K8B (default).
[0487]
3.3 LCD
The LCD displays the current time, remaining battery power, and volume.
[0488]
Chapter 4 Input Devices
4.1 External
4.1.1 Head sensor
Next, the names of the input devices used when writing the code of the program will be described. In the following, following the CPC Primitive Locator, the site (sensor) indicated by the CPC Primitive Locator is shown.
PRM: / r1 / c1 / c2 / c3 / f1-Sensor: f1 Head sensor (rear)
PRM: / r1 / c1 / c2 / c3 / f2-Sensor: f2 ... head sensor (front)

[0489]
4.1.2 Color camera
The CPC Primitive Locator of the color camera is shown below.
PRM: / r1 / c1 / c2 / c3 / i1-FbkImageSensor: F1
Color camera specifications
CMOS unit: 1/6 inch, number of output pixels 352 (H) × 288 (V), 25 FPS
Lens part: F2.0, f = 2.18mm
Angle of view: 57.6 ° horizontal, 47.8 ° vertical
Default
White balance 4300K (fixed)
Shutter speed fixed at 1/100 sec
Gain fixed at 0dB
The parameters that can be set in OPENR :: ControlPrimitive () are shown below.
White balance

[0490]
4.1.3 Distance sensor
The CPC Primitive Locator of the distance sensor is PRM: / r1 / c1 / c2 / c3 / p1-Sensor: p1. The value range is 10 cm for 100,000 and 90 cm for 9000000.
[0490]
4.1.4 Pause button
Connected to the battery control microcomputer. When the power is off, press the pause button to wake up the system.
[0492]
4.1.5 Stereo microphone
The CPC Primitive Locator is as follows.
PRM: / r1 / c1 / c2 / c3 / m1-Mic: M1... Microphone
The sampling frequency is 16000 Hz, the number of quantization bits is 16-bit linear PCM, and the channel is two channels (stereo). The parameters that can be set in OPENR :: ControlPrimitive () are shown below.
Switching between unidirectional (UNI) and omnidirectional (OMNI)
oprmreqMIC_UNI
oprmreqMIC_OMNI
Here, the directivity direction is set such that the longitudinal direction of the microphone unit is the front direction.
ON / OFF switching of ALC (Automatic Limit Control)
oprmreqMIC_ALC_ON
oprmreqMIC_ALC_OFF
[0493]
4.1.6 Switch
Next, the names of the switches used when writing the code of the program are shown. In the following, a switch indicated by the CPC Primitive Locator is shown after the CPC Primitive Locator.
PRM: / r1 / c1 / c2 / c3 / c4 / s5-Sensor: s5 ... jaw sensor
PRM: / r2 / c1 / c2 / c3 / c4-Sensor: s4 ... Fat ball sensor (left front leg)
PRM: / r3 / c1 / c2 / c3 / c4-Sensor: s4 ... ball sensor (left hind leg)
PRM: / r4 / c1 / c2 / c3 / c4-Sensor: s4 ... Fat ball sensor (right front leg)
PRM: / r5 / c1 / c2 / c3 / c4-Sensor: s4 ... Football sensor (right hind leg)
PRM: / r6 / s1-Sensor: s1 ... back sensor
[0494]
4.2 Inside
4.2.1 Acceleration sensor
Indicates the name of the acceleration sensor used when writing the program code. In the following, the acceleration sensor indicated by the CPC Primitive Locator is shown after the CPC Primitive Locator.
PRM: / a1-Sensor: a1... Y-axis (forward and backward, forward is positive)
PRM: / a2-Sensor: a2... X-axis (positive in the left-right direction and right direction)
PRM: / a3-Sensor: a3... Z-axis (vertical direction, upward direction is positive)
The range of the value is as follows.
-19613300 -19.6133 m / s ² -2.0G
+19613300 +19.6133 m / s ² + 2.0G
[0495]
4.2.2 Vibration sensor
Connected to the battery control microcomputer. If obcbVIBRATION_DETECTED is set in the boot condition, the system starts when the battery control microcomputer detects vibration.
[0496]
<ERS-220>
Next, another specification of the robot device (AIBO (registered trademark)) will be described.
Chapter 1 ERS-220 External Specifications
1.1 ERS-220 outline
1.1.1. External view
FIG. 40 shows a view from the top, a view from the front of the sky, and a view from the side of the robot apparatus (hereinafter referred to as ERS-220). Hereinafter, the ERS-220 will be described with reference to the drawings. The ERS-220 is a so-called pet-type robot having a shape imitating an “animal” as shown in FIG. 40, like the ERS-210. The ERS-220 is configured such that each leg unit is connected to the front, rear, left and right of the body unit, and a head unit is connected to the front end of the body unit. A tail portion is provided at the rear end of the body unit. The outer dimensions of the ERS-220 are described in FIGS. 41 and 42.
[0497]
1.2 Movable range
Next, the movable part of the ERS-220 will be described.
[0498]
1.2.1 Head
FIG. 43 shows a movable portion of the head and its movable range. On the head, the neck, horn, and jaw are movable. The degree of freedom of each part is such that the neck has three degrees of freedom of pan, tilt, and roll, the angle has one degree of freedom, and the chin has one degree of freedom, and the entire head has a total of four degrees of freedom.
[0499]
1.2.2 Legs
FIG. 44 shows a movable portion of the leg and its movable range. The legs have movable hips, shoulders, and knees. The degrees of freedom of each part are three degrees of freedom for the front legs (waist: one degree of freedom, shoulders: one degree of freedom, knees: one degree of freedom), and hind legs are three degrees of freedom. Each has three degrees of freedom (waist: one degree of freedom, shoulder: one degree of freedom, knee: one degree of freedom), and the entire leg has a total of 12 degrees of freedom.
[0500]
1.3 Device layout diagram
1.3.1 Output device
The output device of the ERS-220 will be described. FIG. 45 shows a schematic position of an output device provided in the ERS-220. The head of the ERS-220 is provided with a mode lamp, a face side lamp, a face front lamp, and a retractable headlight for notifying a mode and a state. A speaker is provided at the front position of the head, and an operation lamp is provided at the front position of the chest. In addition, a multi-back lamp is provided on the back, and a tail lamp is provided on the tail. In addition, an LED for time display, a memory stick access confirmation lamp, a piezoelectric buzzer for a start-up sound and a shutdown sound, and the like are provided inside the main body.
[0501]
1.3.2 Input device
The input device of the ERS-220 will be described. FIG. 46 shows a schematic position of the input device provided in the ERS-220. The head of the ERS-220 is provided with a face touch sensor, a distance sensor, a head touch sensor, and stereo microphones at left and right ear positions. A color camera is provided at the front position of the head, and a pause button for stopping operation is provided at the front position of the chest. A back touch sensor and a tail touch sensor are provided on the back of the body, and a foot touch sensor is provided on the sole of the leg. Further, an acceleration sensor, a vibration sensor, a temperature sensor, a clock (setting switch), a PC card insertion slot, and a memory stick insertion slot are provided inside the main body.
[0502]
1.4 Configuration of each part
1.4.1 Overall ERS-220
The overall configuration of the ERS-220 will be described. FIG. 47 shows how the entire ERS-220 is assembled. In the ERS-220, a head unit, left and right front leg units, left and right rear leg units, and a tail unit are assembled to a main body unit having an OPEN-R bus connection terminal.
[0503]
1.4.2 ERS-220 head
The ERS-220 head unit will be described. FIG. 48 shows the ERS-220 head with the external protective housing removed. The head of the ERS-220 has retractable headlights, a distance sensor, a head touch sensor, left and right ear stereo microphones, printed boards such as LEDs, a color camera, a motor for a neck roll, a motor for a neck pan, A motor for tilting the neck and a pause button for stopping the operation are provided.
[0504]
1.4.3 ERS-220 leg
The ERS-220 leg unit will be described. FIG. 49 shows the ERS-220 leg with the external protective housing removed. A drive motor and a potentiometer are provided on the legs of the ERS-220 for each joint of the waist (J1), shoulder (J2), and knee (J3). A foot ball sensor is attached to the sole of the foot. The OPEN-R bus connection terminal may be provided in the leg unit.
[0505]
Chapter 2 ERS-220 Joint
2.1 CPC Primitive Locator List
Next, the names of the respective parts used when describing the code of the program are listed. In the following, the site indicated by the CPC Primitive Locator is shown after the CPC Primitive Locator.
PRM: / r1 / c1-Joint2: j1 ... neck tilt
PRM: / r1 / c1 / c2-Joint2: j2 ... neck pan
PRM: / r1 / c1 / c2 / c3-Joint2: j3 ... neck roll
PRM: / r1 / c1 / c2 / c3 / 11-LED2: 11: Head face side lamp (front left)
PRM: / r1 / c1 / c2 / c3 / 12-LED2: 12: Head face side lamp (center left)
PRM: / r1 / c1 / c2 / c3 / 13-LED2: 13 ... Head face side lamp (rear left)
PRM: / r1 / c1 / c2 / c3 / 14-LED2: 14 ... Head face side lamp (front right)
PRM: / r1 / c1 / c2 / c3 / 15-LED2: 15: Head face side lamp (center right)
PRM: / r1 / c1 / c2 / c3 / 16-LED2: 16 ... Head face side lamp (right rear)
PRM: / r1 / c1 / c2 / c3 / 17-LED2: 17 ... Head mode lamp
PRM: / r1 / c1 / c2 / c3 / 18-LED2: 18 ... Face front lamp B
PRM: / r1 / c1 / c2 / c3 / 19-LED2: 19 ... Face front lamp A
PRM: / r1 / c1 / c2 / c3 / la-LED2: la: face front lamp C
PRM: / r1 / c1 / c2 / c3 / lb-LED2: lb ... Retractable headlight
PRM: / r1 / c1 / c2 / c3 / f1-Sensor: f1 ... Head touch sensor
PRM: / r1 / c1 / c2 / c3 / f2-Sensor: f2 ... Head touch sensor
PRM: / r1 / c1 / c2 / c3 / c4 / s5-Sensor: s5 ... face touch sensor
PRM: / r1 / c1 / c2 / c3 / p1-Sensor: p1 Distance sensor
PRM: / r1 / c1 / c2 / c3 / m1-Mic: M1 ... stereo microphone
PRM: / r1 / c1 / c2 / c3 / s1-Speaker: S1 ... Speaker
PRM: / r1 / c1 / c2 / c3 / i1-FbkImageSensor: F1 ... color camera
[0506]
Left front leg
PRM: / r2 / c1-Joint2: j1 ... hip joint
PRM: / r2 / c1 / c2-Joint2: j2 ... shoulder joint
PRM: / r2 / c1 / c2 / c3-Joint2: j3 ... knee joint
PRM: / r2 / c1 / c2 / c3 / c4-Sensor: s4 ... Foot touch sensor
Left hind leg
PRM: / r3 / c1-Joint2: j1 ... hip joint
PRM: / r3 / c1 / c2-Joint2: j2 ... shoulder joint
PRM: / r3 / c1 / c2 / c3-Joint2: j3 ... knee joint
PRM: / r3 / c1 / c2 / c3 / c4-Sensor: s4 ... Foot touch sensor
Right front leg
PRM: / r4 / c1-Joint2: j1 ... hip joint
PRM: / r4 / c1 / c2-Joint2: j2 ... shoulder joint
PRM: / r4 / c1 / c2 / c3-Joint2: j3 ... knee joint
PRM: / r4 / c1 / c2 / c3 / c4-Sensor: s4 ... foot touch sensor
Right hind leg
PRM: / r5 / c1-Joint2: j1 ... hip joint
PRM: / r5 / c1 / c2-Joint2: j2 ... shoulder joint
PRM: / r5 / c1 / c2 / c3-Joint2: j3 ... knee joint
PRM: / r5 / c1 / c2 / c3 / c4-Sensor: s4 ... Foot touch sensor
[0507]
tail
PRM: / r6 / s1-Sensor: s1 Back touch switch
PRM: / r6 / t1-Sensor: t1 Temperature sensor
PRM: / r6 / s2-Sensor: s2 ... Tail touch sensor (left)
PRM: / r6 / s3-Sensor: s3 ... Tail touch sensor (center)
PRM: / r6 / s4-Sensor: s4 ... Tail touch sensor (right)
PRM: / r6 / 11-LED2: 11: Back touch sensor (first from left)
PRM: / r6 / 12-LED2: 12 ... back touch sensor (second from left)
PRM: / r6 / 13-LED2: 13 ... Back touch sensor (third from left)
PRM: / r6 / 14-LED2: 14 ... Back touch sensor (third from right)
PRM: / r6 / 15-LED2: 15 ... back touch sensor (second from right)
PRM: / r6 / 16-LED2: 16 ... back touch sensor (first from right)
PRM: / r6 / 17-LED2: 17 ... Tail touch sensor (center)
PRM: / r6 / 18-LED2: 18 ... Tail touch sensor (right)
PRM: / r6 / 19-LED2: 19 ... Tail touch sensor (left)
[0508]
Acceleration sensor
PRM: / a1-Sensor: a1... Y-axis (forward and backward, forward is positive)
PRM: / a2-Sensor: a2... X-axis (positive in the left-right direction and right direction)
PRM: / a3-Sensor: a3... Z-axis (vertical direction, upward direction is positive)
[0509]
Subsequently, the correspondence between the index number of OSsensorFrameVectorData and CPC Primitive Locator is shown. In the following, following the index number, the corresponding CPC Primitive Locator is shown.
0 PRM: / r1 / c1-Joint2: j1
1 PRM: / r1 / c1 / c2-Joint2: j2
2 PRM: / r1 / c1 / c2 / c3-Joint2: j3
3 PRM: / r1 / c1 / c2 / c3 / p1-Sensor: p1
4 PRM: / r1 / c1 / c2 / c3 / f1-Sensor: f1
5 PRM: / r1 / c1 / c2 / c3 / f2-Sensor: f2
6 PRM: / r1 / c1 / c2 / c3 / c4 / s5-Sensor: s5
7 PRM: / r2 / c1-Joint2: j1
8 PRM: / r2 / c1 / c2-Joint2: j2
9 PRM: / r2 / c1 / c2 / c3-Joint2: j3
10 PRM: / r2 / c1 / c2 / c3 / c4-Sensor: s4
11 PRM: / r3 / c1-Joint2: j1
12 PRM: / r3 / c1 / c2-Joint2: j2
13 PRM: / r3 / c1 / c2 / c3-Joint2: j3
14 PRM: / r3 / c1 / c2 / c3 / c4-Sensor: s4
15 PRM: / r4 / c1-Joint2: j1
16 PRM: / r4 / c1 / c2-Joint2: j2
17 PRM: / r4 / c1 / c2 / c3-Joint2: j3
18 PRM: / r4 / c1 / c2 / c3 / c4-Sensor: s4
19 PRM: / r5 / c1-Joint2: j1
20 PRM: / r5 / c1 / c2-Joint2: j2
21 PRM: / r5 / c1 / c2 / c3-Joint2: j3
22 PRM: / r5 / c1 / c2 / c3 / c4-Sensor: s4
23 PRM: / r6 / t1-Sensor: t1
24 PRM: / r6 / s1-Sensor: s1
25 PRM: / r6 / s2-Sensor: s2
26 PRM: / r6 / s3-Sensor: s3
27 PRM: / r6 / s4-Sensor: s4
28 PRM: / a1-Sensor: a1
29 PRM: / a2-Sensor: a2
30 PRM: / a3-Sensor: a3
[0510]
2.2 Limit value of joint movement
2.2.1 Single joint limit
The soft limit of each joint will be described. The soft limit of the leg J1 is −117 ° to 117 °, the soft limit of J2 is −11 ° to 89 °, and the soft limit of J3 is −27 ° to 147 °. However, the mechanical limit of the leg J1 is −120 ° to 120 °, the mechanical limit of the leg J2 is −14 ° to 92 °, and the mechanical limit of the leg J3 is −27 ° to 147 °. It is.
[0511]
The soft limits of the head are -82 to 43 degrees for neck tilt, -89.6 to 89.6 degrees for neck pan, and -29 to 29 degrees for neck roll. However, as for the mechanical limits, the neck tilt is −85 ° to 46 °, the neck pan is −92.6 ° to 92.6 °, and the neck roll is −32 ° to 32 °.
[0512]
6.2.2 Soft joint limit of two legs
FIG. 50 shows the minimum values of the angle limits of the J2 front leg and the J2 rear leg when the angle of J1 changes. In the figure, the unit is degree (°).
[0513]
6.2.3 4-joint soft limit of head
The relationship between the limits of each joint of the head will be described below. The movable range of the roll is within the range defined in the tilt axis and pan axis areas in FIG. The neck pan is symmetrical on the right. However, in the following description, the unit is degrees (°).
In the case of the A region, −25 ≦ roll ≦ 0
If the area is B, roll = 0
In the case of the C region, −15 ≦ roll ≦ 10
In the case of the D region, -29 ≦ roll20
In the case of the E region, -20 ≦ roll ≦ 29
In the F region, -20 ≦ roll ≦ 20
In the case of the G region, -20 ≦ roll ≦ 29
In the case of the H region, −20 ≦ roll ≦ 29
In the case of the I region, -29 ≦ roll ≦ 29
In the case of the K region, −15 ≦ roll ≦ 29
For the L region, -13 ≦ roll ≦ 29
In the case of the M region, −15 ≦ roll ≦ 20
For N region, 2 ≦ roll ≦ 20
In the O region, −7 ≦ roll ≦ 29
[0514]
2.3 Servo gain
FIG. 52 shows the default servo gain of the joint of the ERS-220. Here, the values of PSHIFT, ISHIFT, and DSHIFT cannot be changed because they are fixed values.
[0515]
Chapter 3 Output Devices
3.1 LED
Next, the names of output devices used when describing the code of the program are listed. In the following, following the CPC Primitive Locator, a portion (LED device) indicated by the CPC Primitive Locator is shown.
PRM: / r1 / c1 / c2 / c3 / 11-LED2: 11: Face side lamp (front left)
PRM: / r1 / c1 / c2 / c3 / 12-LED2: 12 ... Face side lamp (center left)
PRM: / r1 / c1 / c2 / c3 / 13-LED2: 13 ... Face side lamp (rear left)
PRM: / r1 / c1 / c2 / c3 / 14-LED2: 14 ... Face side lamp (front right)
PRM: / r1 / c1 / c2 / c3 / 15-LED2: 15 ... Face side lamp (center right)
PRM: / r1 / c1 / c2 / c3 / 16-LED2: 16 ・ ・ ・ Face side lamp (rear right)
PRM: / r1 / c1 / c2 / c3 / 17-LED2: 17 ... mode lamp
PRM: / r6 / 11-LED2: 11: Back touch sensor (first from left)
PRM: / r6 / 12-LED2: 12 ... back touch sensor (second from left)
PRM: / r6 / 13-LED2: 13 ... Back touch sensor (third from left)
PRM: / r6 / 14-LED2: 14 ... Back touch sensor (third from right)
PRM: / r6 / 15-LED2: 15 ... back touch sensor (second from right)
PRM: / r6 / 16-LED2: 16 ... back touch sensor (first from right)
PRM: / r6 / 17-LED2: 17 ... Tail touch sensor (center)
PRM: / r6 / 18-LED2: 18 ... Tail touch sensor (right)
PRM: / r6 / 19-LED2: 19 ... Tail touch sensor (left)
PRM: / r1 / c1 / c2 / c3 / 18-LED2: 18 ... Face front lamp B
PRM: / r1 / c1 / c2 / c3 / 19-LED2: 19 ... Face front lamp A
PRM: / r1 / c1 / c2 / c3 / la-LED2: la: face front lamp C
PRM: / r1 / c1 / c2 / c3 / lb-LED2: lb ... Retractable headlight
[0516]
3.2 Speaker
The CPC Primitive Locator is PRM: / r1 / c1 / c2 / c3 / s1-Speaker: S1. The sampling frequency of this speaker is 8000 Hz, the number of quantization bits is 8-bit linear PCM, and the channel is one channel (monaural). The parameters that can be set in OPENR :: ControlPrimitive () are shown below.

The sound types that can be set are ospksndMONO8K8B (default).
[0517]
3.3 LCD
The LCD displays the current time, remaining battery power, and volume.
[0518]
Chapter 4 Input Devices
4.1 External
4.1.1 Head sensor
Next, the names of the input devices used when writing the code of the program will be described. In the following, following the CPC Primitive Locator, the site (sensor) indicated by the CPC Primitive Locator is shown.
PRM: / r1 / c1 / c2 / c3 / f1-Sensor: f1 head sensor 1
PRM: / r1 / c1 / c2 / c3 / f2-Sensor: f2 ... head sensor 2
The output of value is shown in FIG. When the head touch sensor is tilted backward, the value changes in the order of, for example, “normal → back 1 → back 2 → back 3 → back 2 → back 1 → normal” according to the tilt angle.
[0519]
4.1.2 Color camera
The CPC Primitive Locator of the color camera is shown below.
PRM: / r1 / c1 / c2 / c3 / i1-FbkImageSensor: F1
Color camera specifications
CMOS unit: 1/6 inch, number of output pixels 352 (H) × 288 (V), 25 FPS
Lens part: F2.0, f = 2.18mm
Angle of view: 57.6 ° horizontal, 47.8 ° vertical
Default
White balance 4300K (fixed)
Shutter speed fixed at 1/100 sec
Gain fixed at 0dB
The parameters that can be set in OPENR :: ControlPrimitive () are shown below.

[0520]
4.1.3 Distance sensor
The CPC Primitive Locator of the distance sensor is PRM: / r1 / c1 / c2 / c3 / p1-Sensor: p1.
The value range is 10 cm for 100,000 and 90 cm for 9000000.
[0521]
4.1.4 Pause button
Connected to the battery control microcomputer. When the power is off, press the pause button to wake up the system.
[0522]
4.1.5 Stereo microphone
The CPC Primitive Locator is as follows.
PRM: / r1 / c1 / c2 / c3 / m1-Mic: M1... Microphone
The sampling frequency is 16000 Hz, the number of quantization bits is 16-bit linear PCM, and the channel is two channels (stereo). The parameters that can be set in OPENR :: ControlPrimitive () are shown below.
Switching between unidirectional (UNI) and omnidirectional (OMNI)
oprmreqMIC_UNI
oprmreqMIC_OMNI
Here, the directivity direction is set such that the longitudinal direction of the microphone unit is the front direction.
ON / OFF switching of ALC (Automatic Limit Control)
oprmreqMIC_ALC_ON
oprmreqMIC_ALC_OFF
[0523]
4.1.6 Switch
Next, the names of the switches used when writing the code of the program are shown. In the following, a switch indicated by the CPC Primitive Locator is shown after the CPC Primitive Locator.
PRM: / r1 / c1 / c2 / c3 / c4 / s5-Sensor: s5 ... face touch sensor
PRM: / r2 / c1 / c2 / c3 / c4-Sensor: s4 ... Foot touch sensor (left front leg)
PRM: / r3 / c1 / c2 / c3 / c4-Sensor: s4 ... foot touch sensor (left rear leg)
PRM: / r4 / c1 / c2 / c3 / c4-Sensor: s4 ... foot touch sensor (right front leg)
PRM: / r5 / c1 / c2 / c3 / c4-Sensor: s4 ... foot touch sensor (right front leg)
PRM: / r6 / s1-Sensor: s1 ... Back touch sensor
PRM: / r6 / s2-Sensor: s2 ... Tail touch sensor (left)
PRM: / r6 / s3-Sensor: s3 ... Tail touch sensor (center)
PRM: / r6 / s4-Sensor: s4 ... Tail touch sensor (right)
[0524]
4.2 Inside
4.2.1 Acceleration sensor
Indicates the name of the acceleration sensor used when writing the program code. In the following, the acceleration sensor indicated by the CPC Primitive Locator is shown after the CPC Primitive Locator.
PRM: / a1-Sensor: a1... Y-axis (forward and backward, forward is positive)
PRM: / a2-Sensor: a2... X-axis (positive in the left-right direction and right direction)
PRM: / a3-Sensor: a3... Z-axis (vertical direction, upward direction is positive)
The range of the value is as follows.
-19613300 -19.6133 m / s ² -2.0G
+19613300 +19.6133 m / s ² + 2.0G
[0525]
4.2.2 Vibration sensor
Connected to the battery control microcomputer. If obcbVIBRATION_DETECTED is set in the boot condition, the system starts when the battery control microcomputer detects vibration.
[0526]
【The invention's effect】
As described in detail above, the interface of the robot apparatus according to the present invention is a system of a robot apparatus that executes an operation according to external information or an external action based on software and / or an autonomous operation based on an internal state. An interface between the application layer and the application layer. Software is made into parts based on object orientation, and the objects as each part of the software made into parts operate in parallel. By defining the interface specifications between the system layer and the application layer, it is possible to efficiently develop robot hardware and software that evolve entertainment and social compatibility as needed.
[Brief description of the drawings]
FIG. 1 is a conceptual diagram of application software shown as a specific example of the present invention.
FIG. 2 is a conceptual diagram illustrating inter-object communication in application software shown as a specific example of the present invention.
FIG. 3 is a conceptual diagram illustrating a C ++ class for expressing an object in application software shown as a specific example of the present invention.
FIG. 4 is a conceptual diagram illustrating an example of inter-object communication in application software shown as a specific example of the present invention.
FIG. 5 is a diagram illustrating a procedure for building an object and creating an execution file in application software shown as a specific example of the present invention.
FIG. 6 is a diagram illustrating a directory configuration of application software shown as a specific example of the present invention.
FIG. 7 is a diagram showing a stack state in which func1 and func2 are called in order from the function entry_point0 and the address (a) of the func2 is being executed in this specific example.
FIG. 8 is a diagram illustrating the type of CPU exception and the specification of an object in this specific example.
FIG. 9 is a diagram illustrating the specification of an assembly instruction in this specific example.
FIG. 10 shows an example of application software shown as a specific example of the present invention. FIG. 9 is a diagram for describing an execution example of a command (exception) used in the CFG.
FIG. 11 shows application software shown as a specific example of the present invention. FIG. 9 is a diagram for describing an execution example of a command (cp0) used in CFG.
FIG. 12 is a diagram illustrating application software shown as a specific example of the present invention. FIG. 9 is a diagram illustrating an execution example of a command (cp1) used in CFG.
FIG. 13 shows application software shown as a specific example of the present invention in EMON. FIG. 9 is a diagram illustrating an execution example of a command (objs) used in CFG.
FIG. 14 is a diagram illustrating application software shown as a specific example of the present invention. FIG. 9 is a diagram illustrating an example of execution of commands (stack, dstack) used in CFG.
FIG. 15 is a diagram illustrating application software shown as a specific example of the present invention. FIG. 9 is a diagram for describing an execution example of a command (tlb) used in CFG.
FIG. 16 is a diagram illustrating application software shown as a specific example of the present invention. FIG. 9 is a diagram illustrating an execution example of a command (dump) used in CFG.
FIG. 17 is a diagram illustrating an IPv4 protocol stack of application software shown as a specific example of the present invention.
FIG. 18 is a schematic diagram showing a state of communication between an object and a protocol stack in this specific example.
FIG. 19 is a schematic diagram illustrating a manner in which a shared memory area is mapped to an address space of an object and a protocol stack in this specific example.
FIG. 20 is a state transition diagram of an endpoint in this specific example.
FIG. 21 is a state transition diagram of a UDP endpoint in this specific example.
FIG. 22 is a state transition diagram of a DNS endpoint in this specific example.
FIG. 23 is a diagram showing an example of a host entry obtained from the Internet in this specific example.
FIG. 24 is a state transition diagram of an IP endpoint in this specific example.
FIG. 25 is a diagram illustrating an example of the contents of an IP header in this specific example.
FIG. 26 is an external view of a robot device (ERS-210) applied to this example.
FIG. 27 is a diagram illustrating the external dimensions of a robot device (ERS-210) applied to this specific example.
FIG. 28 is a diagram showing the external dimensions of the head of a robot device (ERS-210) applied to this specific example.
FIG. 29 is a diagram illustrating the movable range of the head of a robot device (ERS-210) applied to this specific example.
FIG. 30 is a diagram illustrating a movable range of a leg of a robot device (ERS-210) applied to the specific example.
FIG. 31 is a diagram illustrating a movable range of a tail portion of a robot device (ERS-210) applied to this specific example.
FIG. 32 is an external view illustrating a schematic arrangement of output devices of a robot device (ERS-210) applied to the specific example.
FIG. 33 is an external view illustrating a schematic arrangement of input devices of a robot apparatus (ERS-210) applied to the specific example.
FIG. 34 is a perspective view illustrating the assembling of the overall configuration of the robot apparatus (ERS-210) applied to this example.
FIG. 35 is a perspective view illustrating a head configuration of a robot device (ERS-210) applied to this specific example.
FIG. 36 is a perspective view illustrating a leg configuration of a robot device (ERS-210) applied to this specific example.
FIG. 37 is a diagram showing the angle limit of the J2 front leg and the minimum value of the angle limit of the J2 rear leg when the angle of J1 changes in the robot apparatus (ERS-210) applied to this specific example.
FIG. 38 is a diagram showing an optimal correspondence between four joints of the head in a robot apparatus (ERS-210) applied to this specific example.
FIG. 39 is a diagram showing a default servo gain of a joint in the robot apparatus (ERS-210) applied to this specific example.
FIG. 40 is an external view of a robot device (ERS-220) applied to this specific example.
FIG. 41 is a diagram showing the external dimensions of a robot device (ERS-220) applied to this specific example.
FIG. 42 is a diagram showing the external dimensions of the head of a robot device (ERS-220) applied to this specific example.
FIG. 43 is a diagram illustrating the movable range of the head of a robot device (ERS-220) applied to this specific example.
FIG. 44 is a diagram illustrating a movable range of a leg of a robot device (ERS-220) applied to this specific example.
FIG. 45 is an external view illustrating a schematic arrangement of output devices of a robot apparatus (ERS-220) applied to the specific example.
FIG. 46 is an external view illustrating a schematic arrangement of input devices of a robot apparatus (ERS-220) applied to the specific example.
FIG. 47 is a perspective view illustrating the assembling of the overall configuration of the robot device (ERS-220) applied to this example.
FIG. 48 is a perspective view illustrating a head configuration of a robot device (ERS-220) applied to this specific example.
FIG. 49 is a perspective view illustrating a leg configuration of a robot device (ERS-220) applied to this specific example.
FIG. 50 is a diagram showing the angle limit of the J2 front leg and the minimum value of the angle limit of the J2 rear leg when the angle of J1 changes in the robot apparatus (ERS-220) applied to this specific example.
FIG. 51 is a diagram showing an optimal correspondence between four head joints in a robot apparatus (ERS-220) applied to this specific example.
FIG. 52 is a diagram showing a default servo gain of a joint in the robot apparatus (ERS-220) applied to this specific example.
FIG. 53 is a diagram illustrating output values of a head sensor in a robot device (ERS-220) applied to the specific example.
[Explanation of symbols]
1 Application software, 11, 12, 13 objects, ERS-210 robot, ERS-220 robot

Claims (2)

An interface between a system layer and an application layer of a robot device that performs an operation according to external information or an external action based on software and / or performs an autonomous operation based on an internal state,
An interface of a robot apparatus, wherein the software is made into parts based on object orientation, and objects as each part of the made-to-part software operate in parallel. 2. The interface according to claim 1, wherein the objects are operated in parallel while communicating with each other.

Images