喜多様
安藤です
> RTC Builder により、サービスポートを上下左右を指定して配置しても、
> RT System Editor で読み込むと、すべてのサービスポートが
> 同じ側（デフォルトの右側）に表示されてしまいます。
> RT System Editor においても、指定した位置に表示されるべきかと
> 思いますが、いかがでしょうか。
確かにおっしゃるとおりです。
RTCのバイナリ自体は現状ではポートの場所の情報を持っていませんので、
Builderで指定したようには表示されません。
というのも、ポートの場所指定自体はRTCBuilder（≠RtcTemplate）から機能ですので、
それより前にリリースされた0.4.2のコンポーネントにはその情報は含まれていません。
1.0ではおそらく含めると思います。
以上、よろしくお願いいたします。
> 喜多 伸之
安藤様、喜多様、
産総研 末廣です。
Ando Noriaki さんは書きました:
>
>> RTC Builder により、サービスポートを上下左右を指定して配置しても、
>> RT System Editor で読み込むと、すべてのサービスポートが
>> 同じ側（デフォルトの右側）に表示されてしまいます。
>> RT System Editor においても、指定した位置に表示されるべきかと
>> 思いますが、いかがでしょうか。
>
> 確かにおっしゃるとおりです。
>
> RTCのバイナリ自体は現状ではポートの場所の情報を持っていませんので、
> Builderで指定したようには表示されません。
> というのも、ポートの場所指定自体はRTCBuilder（≠RtcTemplate）から機能ですので、
> それより前にリリースされた0.4.2のコンポーネントにはその情報は含まれていません。
> 1.0ではおそらく含めると思います。
「ポートの場所」というのは表示の問題ですので、コンポーネントに
その情報を持たせるのは誤りではないかと思います。
逆にRTCBuilderでポートの配置を指定できるということは非常な驚きです。
こういうことはやらない方が良いのではないでしょうか？
同じRTCでも、システムの中での使われ方によってポートの表示場所を
変えたいということもあると思います。
ご検討、よろしくお願いいたします。
末廣様
安藤です
仰る通り、ポートの場所はRTCのプロファイルに
含めるべき情報ではありません。
ポートの場所に関する情報は、RTCProfileの拡張プロファイルに
含まれています。拡張プロファイルはRTCのプロファイルには
本来含まれないが、ツール等で補助的に利用するなど、利便性のため
含めたいような情報を入れるために設けられたプロファイルです。
詳細は、RTCProfileのver0.1仕様書をご覧ください。
> 安藤様、喜多様、
>
> 産総研 末廣です。
>
> Ando Noriaki さんは書きました:
>>
>>> RTC Builder により、サービスポートを上下左右を指定して配置しても、
>>> RT System Editor で読み込むと、すべてのサービスポートが
>>> 同じ側（デフォルトの右側）に表示されてしまいます。
>>> RT System Editor においても、指定した位置に表示されるべきかと
>>> 思いますが、いかがでしょうか。
>>
>> 確かにおっしゃるとおりです。
>>
>> RTCのバイナリ自体は現状ではポートの場所の情報を持っていませんので、
>> Builderで指定したようには表示されません。
>> というのも、ポートの場所指定自体はRTCBuilder（≠RtcTemplate）から機能ですので、
>> それより前にリリースされた0.4.2のコンポーネントにはその情報は含まれていません。
>> 1.0ではおそらく含めると思います。
>
> 「ポートの場所」というのは表示の問題ですので、コンポーネントに
> その情報を持たせるのは誤りではないかと思います。
>
> 逆にRTCBuilderでポートの配置を指定できるということは非常な驚きです。
> こういうことはやらない方が良いのではないでしょうか？
> 同じRTCでも、システムの中での使われ方によってポートの表示場所を
> 変えたいということもあると思います。
>
> ご検討、よろしくお願いいたします。
安藤様、
末廣です。
Ando Noriaki さんは書きました:
> 仰る通り、ポートの場所はRTCのプロファイルに
> 含めるべき情報ではありません。
>
> ポートの場所に関する情報は、RTCProfileの拡張プロファイルに
> 含まれています。拡張プロファイルはRTCのプロファイルには
> 本来含まれないが、ツール等で補助的に利用するなど、利便性のため
> 含めたいような情報を入れるために設けられたプロファイルです。
>
> 詳細は、RTCProfileのver0.1仕様書をご覧ください。
とりあえず了解しました。
でも、拡張プロファイルであっても、
ツールやシステムによって変わるような情報を
RTCの側に持たせるというのは、すっきりしないと
思っています。
極端な話、コンポーネントを６角形で表示する
ツールがあったらどうします？
RTルームなどで、RTCを部屋ごとに表示する場合は、
拡張プロファイルに部屋情報を持たせるのでしょうか？
末廣様
安藤です
ご指摘ありがとうございます。
> 安藤様、
>
> 末廣です。
>
> Ando Noriaki さんは書きました:
>
>> 仰る通り、ポートの場所はRTCのプロファイルに
>> 含めるべき情報ではありません。
>>
>> ポートの場所に関する情報は、RTCProfileの拡張プロファイルに
>> 含まれています。拡張プロファイルはRTCのプロファイルには
>> 本来含まれないが、ツール等で補助的に利用するなど、利便性のため
>> 含めたいような情報を入れるために設けられたプロファイルです。
>>
>> 詳細は、RTCProfileのver0.1仕様書をご覧ください。
>
> とりあえず了解しました。
>
> でも、拡張プロファイルであっても、
> ツールやシステムによって変わるような情報を
> RTCの側に持たせるというのは、すっきりしないと
> 思っています。
今のところ、拡張プロファイルはRTCが直にもつ予定はありません。（OpenRTM-aistでは。）
RTCのconfファイルに書けばツール側からそれらの情報をとれるような仕組みを考えています。
それらの情報は、get_component_profile() で取得できる RTCProfile.properties や
get_port_profile() で取得できるPortProfile.properties? (でしたっけ？) に、
confで与えた情報を埋め込むという方法で実現しようと思っています。
したがって、confファイルに何も書かなければ、
ツール側ではポートの表示位置等のような情報はとれませんし、
書けばきれいに表示されるようにするというスタンスです。
構造化された状態で取得できる基本情報はあくまでOMG RTC Specification
に準拠したデータのみです。
ポートの表示位置や、ポートに関連付けられる変数名などは、
RTCにとっては本質的な情報ではないことは理解していますし、
私もRTCProfileにそういった情報を付加するのはちょっと違和感があります。
ただし、実際のツールのユーザからのフィードバックには、サービスポートの
位置が片方によっているのは見づらいとか、すべてのコンポーネントが、
四角で表示されるのは見づらいといった声があります。
こういった問題を解決する方法として、ツールでサポートしてやったり、
どんな情報でも入れていいことになっているNVListのPropertiesを利用するのは
ある意味理にかなっていると考えたため、このような仕様になっています。
> 極端な話、コンポーネントを６角形で表示する
> ツールがあったらどうします？
> RTルームなどで、RTCを部屋ごとに表示する場合は、
> 拡張プロファイルに部屋情報を持たせるのでしょうか？
それもありだとは思います。
6角形なら、たとえばN, NE, SE, S, SW, NW といった情報が
Portのpropertiesから取得できて、うまく表示できれば見やすいかもしれません。
あるいは、コンポーネントの長方形内部にconfファイルで指定したアイコンを
表示できれば、コンポーネントの数が多いシステムなどでは見やすいかもしれません。
そして、それに対応するツールは、RTCProfileの拡張プロファイルには
完全には準拠していないツールという位置づけになるだけだと思います。
あくまで拡張プロファイルはオプショナルな情報なので、Basic Profileにのみ
準拠しているだけでも、RTCProfileに準拠したツールということはできます。
RTSystemEditorでの見やすさというのは主に、設計時の問題で、
実際に運用する場合には、それはどうでもいい情報なので、
confファイルからそれらの情報を削除すればRTCは余計な情報を持たずに済みます。
というわけで、RTCのソースに拡張Profile情報は埋め込まれませんが
上述のように、confファイルで与えれば、アプリやツールが
そういった情報を引き出し利用するという使い方はありだとは思います。
いかがでしょうか？
安藤様、
末廣です。
安藤さんの考えは大筋了解、賛成します。
そうすると後は、RTC仕様記述方式v0.1の書き方の問題ですね。
ツール用に好きに使って良い部分があるということはメタな記述
としてそこに書いて良いと思うのですが、ツールが使う具体的な
記述はツール側のマニュアルに書くのが良いのではないでしょうか。
v0.1は知能化プロジェクト用という位置漬けのようなので
とりあえずこれで良いとして、v0.2ではこの辺の書き方を
工夫していただけると助かります。
安藤様、末廣様
議論に水を指すつもりではありませんが、もともとの
わたしの要望の発端は、まさに、
> ただし、実際のツールのユーザからのフィードバックには、サービスポートの
> 位置が片方によっているのは見づらいとか、すべてのコンポーネントが、
> 四角で表示されるのは見づらいといった声があります。
です。つまり、特に位置の指定をしたいというのではなく、サービスポートが
持っている属性、ProvidedかRequiredかにしたがって、アプリ（RT System
Editor）が、記号を変えたり、位置を変えたり（例えばProvidedは
DataInPortと同じ側、RequiredはDataOutPortと同じ側）して表示して
欲しいということでした。これなら、すぐできる？
喜多 伸之
喜多様
安藤です
> 安藤様、末廣様
>
> 議論に水を指すつもりではありませんが、もともとの
> わたしの要望の発端は、まさに、
>
>> ただし、実際のツールのユーザからのフィードバックには、サービスポートの
>> 位置が片方によっているのは見づらいとか、すべてのコンポーネントが、
>> 四角で表示されるのは見づらいといった声があります。
>
> です。つまり、特に位置の指定をしたいというのではなく、サービスポートが
> 持っている属性、ProvidedかRequiredかにしたがって、アプリ（RT System
> Editor）が、記号を変えたり、位置を変えたり（例えばProvidedは
> DataInPortと同じ側、RequiredはDataOutPortと同じ側）して表示して
> 欲しいということでした。これなら、すぐできる？
サービスポートにProvidedかRequiredのインターフェースがどちらかしか
ない場合には、喜多さんのおっしゃるルールでうまく表示できるのですが、
一つのポートにProvidedインターフェースとRequiredインターフェースは、
複数持たせられるので、その場合には単純にはいかないのです。
ProvidedとRequired I/Fを多数決して表示場所を決めるというのもあり、
とは思うのですが。。。。
それでよければ、そんなに難しくはないと思います。
安藤様
> ProvidedとRequired I/Fを多数決して表示場所を決めるというのもあり、
> とは思うのですが。。。。
>
> それでよければ、そんなに難しくはないと思います。
これで結構です。
我々のローカルルールでは、１サービスポートに１インタフェースと
していますので。いまのところ。
喜多 伸之
安藤様、喜多様、
末廣です。
Nobuyuki Kita さんは書きました:
>
>> ProvidedとRequired I/Fを多数決して表示場所を決めるというのもあり、
>> とは思うのですが。。。。
>>
>> それでよければ、そんなに難しくはないと思います。
>
> これで結構です。
私としては反対です。
RTCBuilderで指定するのもやはり少し変です。それより
RTSystemEditorのView情報として保存してほしい気がします。
ポートの位置だけでなく、RTCの場所なども保存したくないですか？
末廣様、喜多様
安藤です
ご意見ありがとうございます。
> 安藤様、喜多様、
>
> 末廣です。
>
> Nobuyuki Kita さんは書きました:
>>
>>> ProvidedとRequired I/Fを多数決して表示場所を決めるというのもあり、
>>> とは思うのですが。。。。
>>>
>>> それでよければ、そんなに難しくはないと思います。
>>
>> これで結構です。
>
> 私としては反対です。
> RTCBuilderで指定するのもやはり少し変です。それより
> RTSystemEditorのView情報として保存してほしい気がします。
> ポートの位置だけでなく、RTCの場所なども保存したくないですか？
現在のところ、RTCの表示位置についてはRTSProfileの拡張に含まれております。
これにポートの位置を追加するというのも一つの理に適ったやり方かと思います。
＃そうするとRTSystemEditorですべてのポートの位置を
＃マウスでチクチク直してやる必要があるのでかなり面倒だとは思いますが。。。。
ただ、コンポーネントの作者の意図として、ProvidedとRequired両インターフェースを
もつポートだが、Required側は単なるコールバックでありポートの役割としては
Providedとしたい、といった様々な状況も考えられますので、RTCのProfileに
ポートの向きの情報を持たせるのもあながち見当はずれとは言えない場合もあります。
＃あと、RTSystemEditorで変えられるようにすると、同じRTCでも、
＃違う形に見えるようにいくらでもいじることができるので、それもどうかなと思います。
RTCやRTSをどういった視点からとらえるかによって、どの情報をどこに
含めるかといったことも変わってくると思います。
ご意見をいろいろ頂けるのは、こちらとしても大変ありがたいのですが、
違う使い方、違う見方をされる別のユーザもおられるので、
いただいたご意見がそのままツールに反映されるとは限らないことをご了解ください。
というわけで、方向性としては、両方とも対応できるようにして、
ユーザによってお好きな方使っていただく方向で考えたいと思いますが、
RTCBuilder、RTSystemEditorは外注で作っておりますので、予算と実装スケジュール
の関係からすべてできるとは限りませんことを予めご了承ください。
ちなみにこれらのツールはすでに1.0版を発注済で、仕様もver0.2が
ほぼ固まっていますので、ご意見が反映されるのはその後のバージョンになります。
もちろん、著作権を破棄した差分コードをご提供いただけるのであれば、
歓迎いたしますし、その場合は比較的すぐにツールに反映できると思います。
以上、よろしくお願いいたします。
安藤様、
産総研 末廣です。
Ando Noriaki さんは書きました:
> 詳細は、RTCProfileのver0.1仕様書をご覧ください。
結構、危うい仕様になっていますね。
たとえばP35、2.5.3.1 varname：当該DataPortの変数名
となっていますが、これはRTC実装側で使う変数名ですよね。
そうすると、
・実装言語や名前空間の扱いは大丈夫でしょうか、
・変数でアクセスされる実体はなんでしょうか、
DataPortのオブジェクトリファレンス？
DataPortオブジェクトの実装？
OpenRTM-aistのみで用いられる内部からDataPortへ
アクセスするための補助クラスのインスタンス？
など、よくわからないし、ここに記述すべきかどうか
疑問に思えるものになっています。
私もいろいろ経験があるのでRTCBuilderとして
この情報が必要なのは分かります。
でもこれはRTCBuilder側に記述されるべき取り決めであって
RTC仕様記述方式で定めるものには見えないのですが
いかがでしょうか。
ご検討、よろしくお願いします。
安藤様、
末廣です。少し考えてみました。
Takashi Suehiro さんは書きました:
>
> 私もいろいろ経験があるのでRTCBuilderとして
> この情報が必要なのは分かります。
> でもこれはRTCBuilder側に記述されるべき取り決めであって
> RTC仕様記述方式で定めるものには見えないのですが
> いかがでしょうか。
RTCの仕様記述を類別すると以下のようなものになると考えています。
1. 外部から使うための記述
1-1 基本（PIM、アプリ非依存）
1-2 拡張１（PSM、OpenRTM拡張、アプリ非依存）
1-3 拡張２（アプリ依存）
たとえば、RTSystemEditorとかRTSpaceMonitor(今はないけど)、
RT作業プログラムシステム(今はないけど)、など
2. 実装のための記述
2-1 実装ツール非依存、アプリ非依存
1-1、1-2
2-2 実装ツール非依存、アプリ依存
1-3（RTSystemEditorでのPortの表示位置など）のように
アプリ依存だが実装非依存なもの
2-3 実装ツール依存
DataPortの変数名など
1-1、1-2（2-1）はOpenRTMにおけるRTC仕様記述として
まとめても良いと思います。（これが改め基本かな）
1-3（2-2）はアプリ用ですので、たとえばRTSystemEditorにおける
RTC記述として限定するべきでしょう。RTC仕様記述方式として
一般的に定めるのは疑問が残ります。
（これを拡張と呼ぶなら、いろいろなアプリに拡張できるような
メタな決め方にしておく必要があるのではないでしょうか）
2-3はどうでしょうか？完全にOpenRTM-aist(C++版)とRTCBuilderに
依存することになります。
DataPortの変数名のようなものを標準的に含めようとするならば
その前にRTCの実装側およびプロキシ側の言語マッピングを
定める必要があると思います。
現状のver0.1仕様書では上記のような区別が不十分に
見えますがいかがでしょうか。
末廣様
安藤です
ご意見ありがとうございます。
> RTCの仕様記述を類別すると以下のようなものになると考えています。
>
> 1. 外部から使うための記述
> 1-1 基本（PIM、アプリ非依存）
> 1-2 拡張１（PSM、OpenRTM拡張、アプリ非依存）
> 1-3 拡張２（アプリ依存）
> たとえば、RTSystemEditorとかRTSpaceMonitor(今はないけど)、
> RT作業プログラムシステム(今はないけど)、など
>
> 2. 実装のための記述
> 2-1 実装ツール非依存、アプリ非依存
> 1-1、1-2
> 2-2 実装ツール非依存、アプリ依存
> 1-3（RTSystemEditorでのPortの表示位置など）のように
> アプリ依存だが実装非依存なもの
> 2-3 実装ツール依存
> DataPortの変数名など
>
> 1-1、1-2（2-1）はOpenRTMにおけるRTC仕様記述として
> まとめても良いと思います。（これが改め基本かな）
>
> 1-3（2-2）はアプリ用ですので、たとえばRTSystemEditorにおける
> RTC記述として限定するべきでしょう。RTC仕様記述方式として
> 一般的に定めるのは疑問が残ります。
> （これを拡張と呼ぶなら、いろいろなアプリに拡張できるような
> メタな決め方にしておく必要があるのではないでしょうか）
｛外部利用|実装｝｛基本|拡張｝｛実装ツール非依存|依存｝｛アプリ非依存|依存｝
の組わせで考えよということでしょうか？
この分け方だと分類は奇麗なのですが、実際に仕様記述を何に使用するか
といった観点がいささかぼけてしまうような気がします。
仕様書の一番後ろを読んでいただければわかると思うのですが、
RTCProfileを策定する時点では、
- RTC仕様記述フォーマットとしての利用
- コード生成のための情報として利用
- システム構成時に利用
- RTCリポジトリにおける検索情報として利用
- 既存仕様の再利用
- ドキュメントとして利用
といった利用方法を想定して仕様を考えてあります。
＃他の利用方法も考えられますが、キリがないのでこう決めました。
そこから、
・RTCの本質的な情報：Basic Profile
・ドキュメント情報：Doc Profile
・ツール等で利用する拡張情報：Ext Profile
の3つに分割しました。
Basic Profile はRTCを外部から見たときどのように見えるかといった情報が含まれます。
OMG RTCからは多少情報は増やしてありますが、これはOpenRTM-aistの仕様に
合わせてあるためです。
上記の利用方法では基本的にこのBasic Profileのみで足りると思います。
ただし、ドキュメント記述に関しては、文書を記述する関係から、
Doc Profileとして、別パッケージとして分離しました。
それ以外の仕様でかつツールに依存する要素はExt Profileに分離しました。
特に、ツールに対する要望をできるだけ取り入れ、かつ本質的な情報と混じらない
ように切り分けるためには、Ext Profileがどうしても必要となってきます。
ツールといっても現状存在するツールはRTCBuilderとRTSystemEditorで、
RTCDebuggerやRTRipositoryもできつつありますが、こちらの手元にはないので
これらのツール用の情報は明示的にはまだ含まれていません。
（ツール作者からご意見は伺っていますが。）
ただ、RTCBuilderやSystemEditor用の情報は他のツールでも使えるかも
しれないので、仕様書に文書として明記ししました。
> 2-3はどうでしょうか？完全にOpenRTM-aist(C++版)とRTCBuilderに
> 依存することになります。
> DataPortの変数名のようなものを標準的に含めようとするならば
> その前にRTCの実装側およびプロキシ側の言語マッピングを
> 定める必要があると思います。
今のところ、OMG RTCにもOpenRTMにも、実装側のAPI標準というのは
ありませんし、美しい標準を目指すのであれば、仰ることはごもっともです。
しかしながら、現状OMG RTCの実装は、C++、Java、Python、.NETともに
1種類づつしかないので、API標準まで決める必要性は感じません。
また、RTCProfileとAPIのマッピングはまた別の問題だと思います。
＃私個人的の中でのプライオリティは
＃「使いやすくちゃんと動く実装」＞「美しく標準に沿った実装」
＃です。標準化はメリットもありますが、時間も手間もかかりますので。。。
なお、変数名は拡張プロファイルですので、先ほどのメールにも書きましたように
どのツールがどのように使おうと自由です。したがって、コードジェネレータが
使うも使わないも自由です。
「もしvarnameがあれば、ジェネレータはその値を変数名に利用することができる」
程度の意味で、かつ
「varnameはもしかしたらないかもしれないので、その時はジェネレータが考えて変数名をつけてね」
という意味でもあります。
実際、これまでのRtcTemplateではポートの名前を使用し、
変数名には：m_portname, ポートオブジェクトインスタンスは：m_portname(In|Out)
のようにしています。
ただ、これが気に入らないとい方もいたので、別名を与えられるようにしたまでです。
> 現状のver0.1仕様書では上記のような区別が不十分に
> 見えますがいかがでしょうか。
現状、これらの仕様に準拠した形でRTCBuilderとRTSystemEditorが
両方とも動作し、連携できているので仕様的に不整合がある等の問題は見つかっておりません。
区別についても、上記の理由、つまり「RTCBuilderとRTSystemEditorの間の連携を行うため」
という目的においては、現状の区別で不便はとくに感じていません。
もし他のツールがこのRTCProfileもしくはRTSProfileを使う上で、
必要な情報が含まれていないといったご要望があれば次のバージョンで
改善したいと考えています。
ちなみに、この仕様書はOMGフォーマットでPIM、PSMが記述されていますが、
これをそのままOMGに持っていくわけでも、その予定もありません。
＃もしそういう機会があれば、参考にはするかもしれませんが。。。
もし持っていくとしても、DocとExtは標準仕様化するのは結構難しいと感じています。
RTCProfileとRTSProfileはあくまでBuilderやSystemEditorなど、今あるツールを
連携させるための仕様です。
以上をご理解いただければと存じます。
末廣様
安藤です
> 安藤様、
>
> 産総研 末廣です。
>
> Ando Noriaki さんは書きました:
>
>> 詳細は、RTCProfileのver0.1仕様書をご覧ください。
>
> 結構、危うい仕様になっていますね。
RTCProfileおよびRTSProfileは基本的には、RTCBuilderとRTSystemEditorの
入出力ファイルのスキーマを仕様書に落としたものとなっています。
これは、NEDOの知能化PJで知能モジュール仕様記述方式および
システム仕様記述方式を定める必要があり、これらの詳細な議論は
WGで行われる予定であるため、そのたたき台として作成したものです。
ですので、ver0.1としてプロジェクト内部に公開しました。
＃OpenRTM-usersでNEDO知能化PJに関係のない方はすみません。
＃ある程度固まったところ（おそらくver0.2）でOpenRTM-aistのWebにも公開いたします。
というわけで、この仕様はあくまでツール間の連携を取るための仕様ですので。。。
> たとえばP35、2.5.3.1 varname：当該DataPortの変数名
> となっていますが、これはRTC実装側で使う変数名ですよね。
> そうすると、
> ・実装言語や名前空間の扱いは大丈夫でしょうか、
> ・変数でアクセスされる実体はなんでしょうか、
> DataPortのオブジェクトリファレンス？
> DataPortオブジェクトの実装？
> OpenRTM-aistのみで用いられる内部からDataPortへ
> アクセスするための補助クラスのインスタンス？
> など、よくわからないし、ここに記述すべきかどうか
> 疑問に思えるものになっています。
これ（varname）は、コードジェネレータが好きに使っていい名前です。
特にこうしなければならないというルールは決まっていませんし、
あくまで拡張プロファイルなので、ツールは無視しても構いません。
> 私もいろいろ経験があるのでRTCBuilderとして
> この情報が必要なのは分かります。
> でもこれはRTCBuilder側に記述されるべき取り決めであって
> RTC仕様記述方式で定めるものには見えないのですが
> いかがでしょうか。
拡張プロファイルはツールのための情報ですので、使いたいツールは
使えばいいし、使いたくなければ使わなくてもいいというスタンスです。
そもそも、拡張プロファイル自体はオプショナルな情報ですので、
存在すらしない場合も考えられます。
というわけで、varnameなどツールで使う情報を拡張プロファイルに
含めることは特に問題ないように思います。
| 2.0.0-RELESE | Download page |
| RT-Component | 153.5 |
| RT-Middleware | 35 |
| Tools | 22 |
| Documentation | 2 |
Motion editor/Dynamics simulator
Dynamics simulator
Integrated Development Platform
RT-Components collection by AIST
Tokyo Opensource Robotics Association
Middleware for DAQ (Data Aquisition) by KEK
RTC Builder により、サービスポートを上下左右を指定して配置しても、
RT System Editor で読み込むと、すべてのサービスポートが
同じ側（デフォルトの右側）に表示されてしまいます。
RT System Editor においても、指定した位置に表示されるべきかと
思いますが、いかがでしょうか。
喜多 伸之