On Thursday, April 17, 2008, at 10:05AM, "Peter Soetens" <peter.soetens at fmtc [dot] be> wrote:
>On Wednesday 16 April 2008 16:47:47 snrkiwi wrote:
>> I see a number of patches in the last couple of months, but I was wondering
>> what the overall state is? We have Orocos 1.4.1 and the data ports are not
>> working over Corba - we get similar problems that I think Sylvain saw with
>> http://www.orocos.org/node/619. The task browser gives us {{{
>> W(U) double data 32.534 [ ERROR ][CorbaPort] Can not
>> create remote porti connection without local port. }}}
>>
>> with a local/producer process with a write port "data", and a
>> remote/consumer process with a read port "data". If this example should
>> work, are the necessary patches in the trunk but not in v1.4.1 then?
>
>These patches will not be ported to v1.4.x because they are not binary
>compatible. The improved (read: working) CORBA ports implementation will be
>part of v1.6. If you use ports over CORBA, you are advised to switch to
>trunk/rtt and trunk/ocl or wait for RTT/OCL 1.6.0.
>
>The (U) in the error example above means that the port is unconnected. This
>could also be a reason why the task browser gives you that error. Anyway, as
>noted in Bugzilla, RTT 1.4.x does not do the CORBA+ports job right.

Ok, exactly what I needed to know. Thanks! So the trunk has working Corba/Ports now? Are there many more known problems with the Corba/Ports implementation that will be fixed for v1.6? Just trying to get an idea of what you already know are issues ... also, got any idea for a release date for v1.6? :-)

On Thursday April 17 2008 16:19:57 S Roderick wrote:
> On Thursday, April 17, 2008, at 10:05AM, "Peter Soetens"
<peter.soetens at fmtc [dot] be> wrote:
> >On Wednesday 16 April 2008 16:47:47 snrkiwi wrote:
> >> I see a number of patches in the last couple of months, but I was
> >> wondering what the overall state is? We have Orocos 1.4.1 and the data
> >> ports are not working over Corba - we get similar problems that I think
> >> Sylvain saw with http://www.orocos.org/node/619. The task browser gives
> >> us {{{
> >> W(U) double data 32.534 [ ERROR ][CorbaPort] Can not
> >> create remote porti connection without local port. }}}
> >>
> >> with a local/producer process with a write port "data", and a
> >> remote/consumer process with a read port "data". If this example should
> >> work, are the necessary patches in the trunk but not in v1.4.1 then?
> >
> >These patches will not be ported to v1.4.x because they are not binary
> >compatible. The improved (read: working) CORBA ports implementation will
> > be part of v1.6. If you use ports over CORBA, you are advised to switch
> > to trunk/rtt and trunk/ocl or wait for RTT/OCL 1.6.0.
> >
> >The (U) in the error example above means that the port is unconnected.
> > This could also be a reason why the task browser gives you that error.
> > Anyway, as noted in Bugzilla, RTT 1.4.x does not do the CORBA+ports job
> > right.
>
> Ok, exactly what I needed to know. Thanks! So the trunk has working
> Corba/Ports now? Are there many more known problems with the Corba/Ports
> implementation that will be fixed for v1.6? Just trying to get an idea of
> what you already know are issues ... also, got any idea for a release date
> for v1.6? :-)

We are using corba-ports (using rtt/trunk and ocl/trunk)in one of our newest
applications and do not experience any problems at the moment.

Ruben

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

On Thursday 17 April 2008 16:19:57 S Roderick wrote:
>
> Ok, exactly what I needed to know. Thanks! So the trunk has working
> Corba/Ports now? Are there many more known problems with the Corba/Ports
> implementation that will be fixed for v1.6? Just trying to get an idea of
> what you already know are issues ... also, got any idea for a release date
> for v1.6? :-)

The main reason they did not work in 1.4 was that they were not unit tested
using CORBA. On trunk/rtt, 3 big unit tests were added testing all kinds of
use scenarios and connections. AFAIK, It now works and behaves as expected.

I'm finishing of the 1.6 buglist in Bugzilla, of which the most important are:
488 AnalogIn/OutInterface is an atrocity.
516 [Scripting]No conversions available from int -> double ->float etc.

Which have bitten users in RTT 1.4 (and before). 1.6.0 would be nice to finish
these off as well, but they are not critical.

I really want 1.6.0 out (so many features, so little users !) I'll branch asap
and try to release before the end of this month.

Peter

On Apr 17, 2008, at 11:48 , Peter Soetens wrote:

> On Thursday 17 April 2008 16:19:57 S Roderick wrote:
>>
>> Ok, exactly what I needed to know. Thanks! So the trunk has working
>> Corba/Ports now? Are there many more known problems with the Corba/
>> Ports
>> implementation that will be fixed for v1.6? Just trying to get an
>> idea of
>> what you already know are issues ... also, got any idea for a
>> release date
>> for v1.6? :-)
>
> The main reason they did not work in 1.4 was that they were not unit
> tested
> using CORBA. On trunk/rtt, 3 big unit tests were added testing all
> kinds of
> use scenarios and connections. AFAIK, It now works and behaves as
> expected.

The Corba unit tests all work for me with trunk/rtt and trunk/ocl.
That's great! Problem is, the small Corba test client/server programs
we wrote aren't behaving right - suspect we have something incorrectly
setup, though no idea what. Have compared to online doc's plus the
Corba unit tests.

I've attached a zip file with the client and server test programs, and
the output logs of each. We are simply trying to access the data ports
of a remote task. To do this we setup a local task, connect the data
ports of the local and remote through Corba, and then get the local
task to update the data porti (and hence the remote task). If this
basic approach is wrong, please let me know. When we start the server,
its periodic loop starts outputting a data value to the log. When we
bring up the client, the remote tasks update loop stops, the client
starts modifying the local data port value, and nothing happens at the
server end. Huh!?

We also tried this with a taskbrowser in the client, and manipulating
the data port that way. Very sporadic results, and we found that the
server also stopped updating once the taskbrowser was running, _but_
the server would update whenever we did an "ls" on the taskbrowser (on
the remote or the local task). Weird!?

If using data ports is not the recommended methodi to get data from a
local program (think GUI) to a remote program (think robot
controller), then what do you recommend? NB we will be using commands,
etc, for other data between the two programs, but the streamed data
seems to make sense to go over a data port ....

Running on Ubuntu Gutsy with Tao 1.4.7. Pulled trunk/rtt,ocl,kdl this
morning.

Any help appreciated.
Stephen

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

On Friday 18 April 2008 16:02:19 S Roderick wrote:
>
> The Corba unit tests all work for me with trunk/rtt and trunk/ocl.
> That's great! Problem is, the small Corba test client/server programs
> we wrote aren't behaving right - suspect we have something incorrectly
> setup, though no idea what. Have compared to online doc's plus the
> Corba unit tests.

I can reproduce your case. Really strange. I'm on it.

Peter

>
> I've attached a zip file with the client and server test programs, and
> the output logs of each. We are simply trying to access the data ports
> of a remote task. To do this we setup a local task, connect the data
> ports of the local and remote through Corba, and then get the local
> task to update the data porti (and hence the remote task). If this
> basic approach is wrong, please let me know. When we start the server,
> its periodic loop starts outputting a data value to the log. When we
> bring up the client, the remote tasks update loop stops, the client
> starts modifying the local data port value, and nothing happens at the
> server end. Huh!?
>
> We also tried this with a taskbrowser in the client, and manipulating
> the data port that way. Very sporadic results, and we found that the
> server also stopped updating once the taskbrowser was running, _but_
> the server would update whenever we did an "ls" on the taskbrowser (on
> the remote or the local task). Weird!?
>
> If using data ports is not the recommended methodi to get data from a
> local program (think GUI) to a remote program (think robot
> controller), then what do you recommend? NB we will be using commands,
> etc, for other data between the two programs, but the streamed data
> seems to make sense to go over a data port ....
>
> Running on Ubuntu Gutsy with Tao 1.4.7. Pulled trunk/rtt,ocl,kdl this
> morning.
>
> Any help appreciated.
> Stephen
>
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Hi Stephen,

Found your problem. It's a classical 'call-back-to-client' problem. If your
client program lets the server-side call back (such as serving a data porti
from 'Sender' in client and calling Get() in server.), it needs to run an orb
as well. Since your client code did no run an orb, the server blocked when
calling back the client. You can fix your code by doing client-side:

1. include <rtt/corba/ControlTaskServer.hpp>

And instead of the usleep(...) code:

ControlTaskServer::RunOrb();

These two lines did the trick for me. Clearly, this needs to be documented.
But in your case: Receiver's Get() goes over the network each time, while
Sender's Set() is a local, real-time call.

In case Receiver should read the data in real-time, you better setup the
connection in the other direction by changing

 connectPorts( &basic, receiver ) // creates the data object at basic's side.

into

 connectPorts( receiver, &basic ) // creates the data object at receiver's 

side.

This allows you to drop the RunOrb() again in the client code, as the client
sends the data over the network, and the server reads locally.

However, this second fix seems to reveil a bug: the server receives an
exception when the client cleans up. That's not what we want. I'll have to
dig into that.

In case you want to test corba applications, I recommend testing them first in
a single program (using both ControlTaskServer and ControlTaskProxy in
main() ), which also eases debugging. When that application works, you can
start splitting in client and server programs.

HTH,
Peter

On Friday 18 April 2008 16:02:19 S Roderick wrote:
> On Apr 17, 2008, at 11:48 , Peter Soetens wrote:
> > On Thursday 17 April 2008 16:19:57 S Roderick wrote:
> >> Ok, exactly what I needed to know. Thanks! So the trunk has working
> >> Corba/Ports now? Are there many more known problems with the Corba/
> >> Ports
> >> implementation that will be fixed for v1.6? Just trying to get an
> >> idea of
> >> what you already know are issues ... also, got any idea for a
> >> release date
> >> for v1.6? :-)
> >
> > The main reason they did not work in 1.4 was that they were not unit
> > tested
> > using CORBA. On trunk/rtt, 3 big unit tests were added testing all
> > kinds of
> > use scenarios and connections. AFAIK, It now works and behaves as
> > expected.
>
> The Corba unit tests all work for me with trunk/rtt and trunk/ocl.
> That's great! Problem is, the small Corba test client/server programs
> we wrote aren't behaving right - suspect we have something incorrectly
> setup, though no idea what. Have compared to online doc's plus the
> Corba unit tests.
>
> I've attached a zip file with the client and server test programs, and
> the output logs of each. We are simply trying to access the data ports
> of a remote task. To do this we setup a local task, connect the data
> ports of the local and remote through Corba, and then get the local
> task to update the data port (and hence the remote task). If this
> basic approach is wrong, please let me know. When we start the server,
> its periodic loop starts outputting a data value to the log. When we
> bring up the client, the remote tasks update loop stops, the client
> starts modifying the local data port value, and nothing happens at the
> server end. Huh!?
>
> We also tried this with a taskbrowser in the client, and manipulating
> the data port that way. Very sporadic results, and we found that the
> server also stopped updating once the taskbrowser was running, _but_
> the server would update whenever we did an "ls" on the taskbrowser (on
> the remote or the local task). Weird!?
>
> If using data ports is not the recommended methodi to get data from a
> local program (think GUI) to a remote program (think robot
> controller), then what do you recommend? NB we will be using commands,
> etc, for other data between the two programs, but the streamed data
> seems to make sense to go over a data port ....
>
> Running on Ubuntu Gutsy with Tao 1.4.7. Pulled trunk/rtt,ocl,kdl this
> morning.
>
> Any help appreciated.
> Stephen
>
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

On Sunday 20 April 2008 00:44:08 Peter Soetens wrote:
> Hi Stephen,
>
> Found your problem. It's a classical 'call-back-to-client' problem. If your
> client program lets the server-side call back (such as serving a data porti
> from 'Sender' in client and calling Get() in server.), it needs to run an
> orb as well. Since your client code did no run an orb, the server blocked
> when calling back the client. You can fix your code by doing client-side:
>
> #include <rtt/corba/ControlTaskServer.hpp>
>
> And instead of the usleep(...) code:
>
> ControlTaskServer::RunOrb();
>
> These two lines did the trick for me. Clearly, this needs to be
> documented. But in your case: Receiver's Get() goes over the network each
> time, while Sender's Set() is a local, real-time call.
>
> In case Receiver should read the data in real-time, you better setup the
> connection in the other direction by changing
>
> connectPorts( &basic, receiver ) // creates the data object at basic's
> side. into
> connectPorts( receiver, &basic ) // creates the data object at receiver's
> side.
>
> This allows you to drop the RunOrb() again in the client code, as the
> client sends the data over the network, and the server reads locally.
>
> However, this second fix seems to reveil a bug: the server receives an
> exception when the client cleans up. That's not what we want. I'll have to
> dig into that.

The reason why this second fix did not work was because the Sender has a write
data port and the receiver a read data port. Read data ports can not create
connection data objects, hence, no matter how you wrote connectPorts(a,b), a
connection would always be made from writer to reader. You must set the
Receiver to use a plain data port (RTT::DataPort), such that it can construct
a local data object, and then connectPorts() will behave as expected and your
server can keep running while the client connects/disconnects/connects/...
etc.

The C++ exception we were seeing should be caught by the receiver nevertheless
and disconnect the port and clean up the connection.

Peter

>The reason why this second fix did not work was because the Sender has a write
>data porti and the receiver a read data port. Read data ports can not create
>connection data objects, hence, no matter how you wrote connectPorts(a,b), a
>connection would always be made from writer to reader. You must set the
>Receiver to use a plain data port (RTT::DataPort), such that it can construct
>a local data object, and then connectPorts() will behave as expected and your
>server can keep running while the client connects/disconnects/connects/...
>etc.
>
>The C++ exception we were seeing should be caught by the receiver nevertheless
>and disconnect the port and clean up the connection.
>
>Peter

Got it. Verified the fixes you noted. Thanks for getting on this so quickly!

It's not clear from the Corba examples, but is the best approach to streaming data to remote components to use a local component that is connected to a proxy of a remote component (like this example we've been working on)? There doesn't seem to be any other straight forward methodi to write to a port in a remote component. Is this correct?

Thanks!
Stephen

On Monday 21 April 2008 21:54:05 S Roderick wrote:
>
> Got it. Verified the fixes you noted. Thanks for getting on this so
> quickly!

Showing example code always works for tricking developers into fixing
your/their bugs :-)

>
> It's not clear from the Corba examples, but is the best approach to
> streaming data to remote components to use a local component that is
> connected to a proxy of a remote component (like this example we've been
> working on)? There doesn't seem to be any other straight forward methodi to
> write to a porti in a remote component. Is this correct?

Yes. But you can even set up two proxies to two standalone components A and B
and call

 proxyA.connectPorts(proxyB);

Hence allowing both component A and B to run as separate ControlTaskServer
executables which don't know of each other.

Peter