安川電機 横山 様。

お世話になっております。
産総研 栗原です。

RTCTemplateでのサービスポート指定方法に関してですが、
"Ports:"欄には以下のように指定して下さい。

PortName: サービスポートの名前(任意)
Name: interface名(任意でいいのですが、ここで与える
名前はProvider,Consumerで揃える必要があります。)
Type: IDLで記述したinterface名(以下の場合、MyService)

下記のIDLファイルですと、
PortName: MyServiceProvider
Name: myservice
Type: MyService
でよろしいかと思います。

※ 上記の場合、このサービスプロバイダーポートに対する
サービスコンシュマーポートでは、Nameをmyserviceに
TypeをMyServiceにそれぞれ指定して下さい。

以上、宣しくお願い致します。

> 安川電機の横山です。
>
> Eclipse のプラグイン RTCTemplate でサービスポートを実装したRTCを定義
> しようとしていますが、躓いております。
>
> OpenRTMのサンプルプログラムにあった下記のIDLファイルを利用して
> 雛形ソースファイルを生成しようとしているのですが、
> IDL Pathに、IDLファイルを設定しただけでは駄目なようで
> 「Service Provider Port を入力してください」というエラーが
> 発生してしまいます。
>
> Service Provider Definition のPorts にどのような値を設定すれば
> 良いかをお教え願えませんでしょうか？
>
> typedef sequence EchoList;
> typedef sequence ValueList;
> interface MyService
> {
> string echo(in string msg);
> EchoList get_echo_history();
> void set_value(in float value);
> float get_value();
> ValueList get_value_history();
> };
>

いつも御世話になります。宇田＠NECシステムテクノロジーです

詳細な経緯のご説明をどうもありがとうございます。既に改良をご検討されて
いらっしゃるとのことで、とても安心しました。

Ringbufferにつきましては、こちらでも気づいた点などを随時フィードバック
させて頂きたいと思いますので、今後ともよろしくお願い申し上げます。

> 宇田様、
> 　つくばにあります高エネルギー加速器研究機構（KEK)の安と申します。
> InPort/OutPortのバッファリングについてコメントさせていただきたいと思います。
>
> 私たちのアプリケーションは実はロボットとは直接関係ない、加速器を用いた実
> 験で検出器からのデータ収集の分野です。組み込み系に分類されるかもしれませ
> ん。宇田様が議論されているInPort/OutPortのバッファリングについては、私た
> ちのアプリケーションでは大変重要な点です。ロボットの分野では周期的なク
> ロックに同期したデータ通信方法を取る場合が多いようですが、私たちのアプリ
> ケーションでは（実は組み込み系でも同じだと思うのですが）、データが利用で
> きるようになったイベントに同期して通信する方法をとります。ですから、
> InPort/OutPortのバッファリングで言えば、 empty/fullでブロックさせるた
> め、pthead_cond_timedwaitメソッドを使ってRingBufferを作成します。
> timedwaitを使うのはバッファ内で無限ループに陥らないようにするためです。
>
> 実は以前のRTミドルウエアは独自のRingBufferを実装できるようにはなっていま
> せんでした。すでに２年以上になりますが、加速器を用いた実験で検出器からの
> データ収集にＲＴミドルウエアを適用するために、KEKと産総研で共同研究を続
> けています。安藤さん、神徳さん、平野さん、たちとの議論を通じで
> InPort/OutPortのバッファリングの重要性を理解していただいています。安藤さ
> んの努力のおかげで、独自のRingBufferを実装できるようになりました。また、
> CORBAばかりでなくTCP socketを用いたデータ通信の手段も実装していただきま
> した。細かいところでは、まだ改良の余地があります。宇田様が「InPortでデー
> タが引き取られたことをOutPortにフィードバックする機構があると、ハンド
> シェークが行えるのでデータの取りこぼしが防げるかもしれません」と言われて
> いる点が改良点の１つです。暫定的ですが、それを防ぐ方法を実装しました。
> RingBufferばかりでなくＲＴミドルウエアのいろいろなコードの修正が必要でし
> た。安藤さんに検討していただいておりますので、ＲＴミドルウエアにいずれ反
> 映することになると思います。
>
> 今後ともよりよいＲＴミドルウエアになるように微力ながら協力してゆきたいと
> 思っています。
>
>
> Akio Uda さんは書きました:
> > To: 産総研　安藤様
> >
> > いつも御世話になります。宇田＠NECシステムテクノロジーです
> >
> > 早速のご回答をどうもありがとうございます。
> >
> >
> >> 宇田様
> >>
> >> 安藤です
> >>
> >> いつもお世話になっております。
> >>
> >>
> >>> OpenRTM-aist-0.4.1のOutPortのバッファリングについてご教授下さい。
> >>>
> >>> OutPortにおいて、ブロックモードでのデータ書き込みを行いたいのですが、
> >>> OutPort.hを拝見しますと、write()メソッドの中で
> >>>
> >>> virtual bool write(const DataType& value)
> >>> {
> >>> ...
> >>> while (m_writeBlock && this->isFull())
> >>> {
> >>> /* フル状態解消待ち */
> >>> }
> >>> ...
> >>> }
> >>>
> >>> のようにバッファフルの解消待ちをされているものの、RingBuffer.h では
> >>> isFull()が常にfalseを返すように見受けられるのですが、0.4.1 ではまだ
> >>> ブロックモードには対応されていないのでしょうか？
> >>>
> >> RingBuffer.hで定義されているバッファはフル状態にならないバッファですので、
> >> ブロッキングをONに設定してもブロッキングされません。
> >>
> >> OutPort(とInPort)はテンプレートの引数として、バッファを取ることができ、
> >> これにより、コンポーネント開発者は独自の機能を持つバッファを
> >> OutPortもしくはInPortで使用することができるようになっています。
> >>
> >> ですので、BufferBaseを継承した独自のバッファがisFullでtrueを返す場合
> >> 一応ブロッキングされるはずです。
> >>
> >
> > 了解致しました。では、独自バッファでの実装も検討したいと思います。
> >
> >
> >
> >> ただ、この機能はまだ十分にデバッグされておらず、
> >> 有効に機能するかどうかはこちらではちょっとわかりません。
> >>
> >>
> >>> またバッファクリアを行いたいのですが、この場合は setReadBlock()で非
> >>> ブロックモードを指定した後、read() を false が返るまで繰り返せばよろ
> >>> しいでしょうか？（m_readTimeout はデフォルト値 0 を想定しています）
> >>>
> >> 現在のRingBufferでは、常に最新値を読むので、
> >> ご希望のバッファクリアに相当する動作はおそらくしないものと思われます。
> >>
> >
> > この場合、OutPortのread()の使い方としては、例えば最後に書き込んだ
> > データの確認などを想定されていますでしょうか？
> >
> >
> >
> >> 大変申し訳ないのですが、InPortおよびOutPortの特にバッファ周りは、
> >> いま一つ完成度が低く、次のバージョンでは構造的に大幅に見直す可能性があります。
> >>
> >> 問題の一つとして、0.2.0では一つのOutPortから複数のInPortに
> >> つないだ場合、すべてにデータが送信されるのに対して、0.4.0では
> >> SubscriptionTypeの組合せによっては、うまくすべてにデータが
> >> 送信されないなど、バッファ周りの設計の不備による問題点が明らかになっております。
> >>
> >> 次期バージョンでは、このあたりの問題をきちんと解決したいと考えております。
> >>
> >> 何か、ご意見やアイディアなどございましたら、お教えいただけないでしょうか。
> >> よろしくお願いいたします。
> >>
> >
> > 了解致しました。
> >
> > OutPortからInPortへのブロードキャストは多用する可能性がありますので、
> > 対応して頂けると助かります。ただ、１つのブロードキャスト内で異なる
> > SubscriptionTypeを混在させるシーンは、今のところ思い浮かびません。
> >
> > また、InPortでデータが引き取られたことをOutPortにフィードバックする
> > 機構があると、ハンドシェークが行えるのでデータの取りこぼしが防げる
> > かもしれません（ブロードキャストの場合は難しそうですが）。
> >
> > あと、次期バージョンの大まかなご予定など、もし決まっていましたら
> > 教えて頂けますでしょうか？
> >
> >