Hi all,
In my application I always want that my components check their input port
connectivity. But not their output port. (the reason of this is that you
don't care when you publish, you need input to be well connected unless you
can't do your job).
I would like to do it automatically in the configureHook when calling my
checkInputsPorts function.
My problem is that I can't determine the port "gender" when I get it from
the port list. Here is my code example which is checking all port connection
(in and out), what should I use to test the gender ?
bool ARDTaskContext::checkInputsPorts()
{
bool res = true;
DataFlowInterface::Ports portsVector = ports()->getPorts();
DataFlowInterface::Ports::iterator it;
for(it = portsVector.begin(); it != portsVector.end(); it++)
{
if( (*it)->connected() == false )
{
LOG(Error) << "checkInputsPorts : " << (*it)->getName() << " is
not connected !" << endlog();
res &= false;
}
}
return res;
}
Automatically checks input port connection
Hi Willy,
On Sun, May 08, 2011 at 04:53:06PM +0200, Willy Lambert wrote:
> Hi all,
>
> In my application I always want that my components check their input port
> connectivity. But not their output port. (the reason of this is that you don't
> care when you publish, you need input to be well connected unless you can't do
> your job).
> I would like to do it automatically in the configureHook when calling my
> checkInputsPorts function.
>
> My problem is that I can't determine the port "gender" when I get it from the
> port list. Here is my code example which is checking all port connection (in
> and out), what should I use to test the gender ?
>
>
> bool ARDTaskContext::checkInputsPorts()
> {
> bool res = true;
> DataFlowInterface::Ports portsVector = ports()->getPorts();
> DataFlowInterface::Ports::iterator it;
>
> for(it = portsVector.begin(); it != portsVector.end(); it++)
> {
> if( (*it)->connected() == false )
> {
> LOG(Error) << "checkInputsPorts : " << (*it)->getName() << " is
> not connected !" << endlog();
> res &= false;
> }
>
> }
>
> return res;
> }
Do you really need the check _inside_ of the component? Couldn't you
perform this validation outside of the component? For instance, using
rttlua you could do the following:
running this example outputs:
$ rttlua-gnulinux checkports.lua
0.047 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for non-privileged users..
0.047 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for non-privileged users..
0.047 [ Info ][DeploymentComponent::loadComponent] HelloWorld manually raises LogLevel to 'Info' (5). See also file 'orocos.log'.
0.047 [ Info ][DeploymentComponent::loadComponent] **** Starting the 'Hello' component ****
0.047 [ Info ][DeploymentComponent::loadComponent] Adding hello as new peer: OK.
0.047 [ ERROR ][rttlua-gnulinux::main()] InputPort hello.the_buffer_port is unconnected!
checking hello: false
0.047 [ Info ][DeploymentComponent::connectPorts] Connected Port hello.the_results to hello.the_buffer_port.
rechecking hello: true
0.048 [ Info ][Logger] Orocos Logging Deactivated.
$
If you do think you must do it inside the component, then the only way
I can think of would be to dynamic_cast to an InputPortInterface and
check wether the reusult is null.
Best regards
Markus
Automatically checks input port connection
On Mon, 9 May 2011, Markus Klotzbuecher wrote:
> Hi Willy,
>
> On Sun, May 08, 2011 at 04:53:06PM +0200, Willy Lambert wrote:
>> Hi all,
>>
>> In my application I always want that my components check their input port
>> connectivity. But not their output port. (the reason of this is that you don't
>> care when you publish, you need input to be well connected unless you can't do
>> your job).
>> I would like to do it automatically in the configureHook when calling my
>> checkInputsPorts function.
>>
>> My problem is that I can't determine the port "gender" when I get it from the
>> port list. Here is my code example which is checking all port connection (in
>> and out), what should I use to test the gender ?
>>
>>
>> bool ARDTaskContext::checkInputsPorts()
>> {
>> bool res = true;
>> DataFlowInterface::Ports portsVector = ports()->getPorts();
>> DataFlowInterface::Ports::iterator it;
>>
>> for(it = portsVector.begin(); it != portsVector.end(); it++)
>> {
>> if( (*it)->connected() == false )
>> {
>> LOG(Error) << "checkInputsPorts : " << (*it)->getName() << " is
>> not connected !" << endlog();
>> res &= false;
>> }
>>
>> }
>>
>> return res;
>> }
>
> Do you really need the check _inside_ of the component? Couldn't you
> perform this validation outside of the component? For instance, using
> rttlua you could do the following:
>
>
>
> running this example outputs:
>
> $ rttlua-gnulinux checkports.lua
> 0.047 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for non-privileged users..
> 0.047 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for non-privileged users..
> 0.047 [ Info ][DeploymentComponent::loadComponent] HelloWorld manually raises LogLevel to 'Info' (5). See also file 'orocos.log'.
> 0.047 [ Info ][DeploymentComponent::loadComponent] **** Starting the 'Hello' component ****
> 0.047 [ Info ][DeploymentComponent::loadComponent] Adding hello as new peer: OK.
> 0.047 [ ERROR ][rttlua-gnulinux::main()] InputPort hello.the_buffer_port is unconnected!
> checking hello: false
> 0.047 [ Info ][DeploymentComponent::connectPorts] Connected Port hello.the_results to hello.the_buffer_port.
> rechecking hello: true
> 0.048 [ Info ][Logger] Orocos Logging Deactivated.
> $
>
> If you do think you must do it inside the component, then the only way
> I can think of would be to dynamic_cast to an InputPortInterface and
> check wether the reusult is null.
Some remarks:
- it makes sense to do Connection chekcing outside of a Component.
- it _also_ makes sense _inside_ a Component, to check whether a Port is
ready to read data from.
- both are _not_ the same thing, necessarily. Certainly not when a
component is deployed on a platform that has a shaky Communication
infrastructure.
My trade-off in this matter would be the following:
- the internal state machine of a Component should wait for an event of its
Coordinator, giving the "go ahead" to start the Computation inside a
Component.
- that Computation doesn't care about the "liveliness" of the Ports its
works with.
- _if_ the Communication is not reliable, or changes often, the _system_
has to foresee a "Communication checking" Component, that fires the
appropriate "Port Ready"/"Port Not Ready" events, to which the
Component's internal state machine can/should react.
I think this is the most decoupled design that can still run efficiently,
whenever possible.
> Best regards
> Markus
Herman
Automatically checks input port connection
On Mon, May 09, 2011 at 11:27:22AM +0200, Herman Bruyninckx wrote:
> On Mon, 9 May 2011, Markus Klotzbuecher wrote:
>
> > Hi Willy,
> >
> > On Sun, May 08, 2011 at 04:53:06PM +0200, Willy Lambert wrote:
> >> Hi all,
> >>
> >> In my application I always want that my components check their input port
> >> connectivity. But not their output port. (the reason of this is that you don't
> >> care when you publish, you need input to be well connected unless you can't do
> >> your job).
> >> I would like to do it automatically in the configureHook when calling my
> >> checkInputsPorts function.
> >>
> >> My problem is that I can't determine the port "gender" when I get it from the
> >> port list. Here is my code example which is checking all port connection (in
> >> and out), what should I use to test the gender ?
> >>
> >>
> >> bool ARDTaskContext::checkInputsPorts()
> >> {
> >> bool res = true;
> >> DataFlowInterface::Ports portsVector = ports()->getPorts();
> >> DataFlowInterface::Ports::iterator it;
> >>
> >> for(it = portsVector.begin(); it != portsVector.end(); it++)
> >> {
> >> if( (*it)->connected() == false )
> >> {
> >> LOG(Error) << "checkInputsPorts : " << (*it)->getName() << " is
> >> not connected !" << endlog();
> >> res &= false;
> >> }
> >>
> >> }
> >>
> >> return res;
> >> }
> >
> > Do you really need the check _inside_ of the component? Couldn't you
> > perform this validation outside of the component? For instance, using
> > rttlua you could do the following:
> >
> >
> >
> > running this example outputs:
> >
> > $ rttlua-gnulinux checkports.lua
> > 0.047 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for non-privileged users..
> > 0.047 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for non-privileged users..
> > 0.047 [ Info ][DeploymentComponent::loadComponent] HelloWorld manually raises LogLevel to 'Info' (5). See also file 'orocos.log'.
> > 0.047 [ Info ][DeploymentComponent::loadComponent] **** Starting the 'Hello' component ****
> > 0.047 [ Info ][DeploymentComponent::loadComponent] Adding hello as new peer: OK.
> > 0.047 [ ERROR ][rttlua-gnulinux::main()] InputPort hello.the_buffer_port is unconnected!
> > checking hello: false
> > 0.047 [ Info ][DeploymentComponent::connectPorts] Connected Port hello.the_results to hello.the_buffer_port.
> > rechecking hello: true
> > 0.048 [ Info ][Logger] Orocos Logging Deactivated.
> > $
> >
> > If you do think you must do it inside the component, then the only way
> > I can think of would be to dynamic_cast to an InputPortInterface and
> > check wether the reusult is null.
>
> Some remarks:
> - it makes sense to do Connection chekcing outside of a Component.
> - it _also_ makes sense _inside_ a Component, to check whether a Port is
> ready to read data from.
> - both are _not_ the same thing, necessarily. Certainly not when a
> component is deployed on a platform that has a shaky Communication
> infrastructure.
>
> My trade-off in this matter would be the following:
> - the internal state machine of a Component should wait for an event of its
> Coordinator, giving the "go ahead" to start the Computation inside a
> Component.
> - that Computation doesn't care about the "liveliness" of the Ports its
> works with.
> - _if_ the Communication is not reliable, or changes often, the _system_
> has to foresee a "Communication checking" Component, that fires the
> appropriate "Port Ready"/"Port Not Ready" events, to which the
> Component's internal state machine can/should react.
> I think this is the most decoupled design that can still run efficiently,
> whenever possible.
I fully agree with these two different requirements of
"connectiveness".
Markus
Automatically checks input port connection
On Mon, 9 May 2011, Markus Klotzbuecher wrote:
> On Mon, May 09, 2011 at 11:27:22AM +0200, Herman Bruyninckx wrote:
>> On Mon, 9 May 2011, Markus Klotzbuecher wrote:
>>
>>> Hi Willy,
>>>
>>> On Sun, May 08, 2011 at 04:53:06PM +0200, Willy Lambert wrote:
>>>> Hi all,
>>>>
>>>> In my application I always want that my components check their input port
>>>> connectivity. But not their output port. (the reason of this is that you don't
>>>> care when you publish, you need input to be well connected unless you can't do
>>>> your job).
>>>> I would like to do it automatically in the configureHook when calling my
>>>> checkInputsPorts function.
>>>>
>>>> My problem is that I can't determine the port "gender" when I get it from the
>>>> port list. Here is my code example which is checking all port connection (in
>>>> and out), what should I use to test the gender ?
>>>>
>>>>
>>>> bool ARDTaskContext::checkInputsPorts()
>>>> {
>>>> bool res = true;
>>>> DataFlowInterface::Ports portsVector = ports()->getPorts();
>>>> DataFlowInterface::Ports::iterator it;
>>>>
>>>> for(it = portsVector.begin(); it != portsVector.end(); it++)
>>>> {
>>>> if( (*it)->connected() == false )
>>>> {
>>>> LOG(Error) << "checkInputsPorts : " << (*it)->getName() << " is
>>>> not connected !" << endlog();
>>>> res &= false;
>>>> }
>>>>
>>>> }
>>>>
>>>> return res;
>>>> }
>>>
>>> Do you really need the check _inside_ of the component? Couldn't you
>>> perform this validation outside of the component? For instance, using
>>> rttlua you could do the following:
>>>
>>>
>>>
>>> running this example outputs:
>>>
>>> $ rttlua-gnulinux checkports.lua
>>> 0.047 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for non-privileged users..
>>> 0.047 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for non-privileged users..
>>> 0.047 [ Info ][DeploymentComponent::loadComponent] HelloWorld manually raises LogLevel to 'Info' (5). See also file 'orocos.log'.
>>> 0.047 [ Info ][DeploymentComponent::loadComponent] **** Starting the 'Hello' component ****
>>> 0.047 [ Info ][DeploymentComponent::loadComponent] Adding hello as new peer: OK.
>>> 0.047 [ ERROR ][rttlua-gnulinux::main()] InputPort hello.the_buffer_port is unconnected!
>>> checking hello: false
>>> 0.047 [ Info ][DeploymentComponent::connectPorts] Connected Port hello.the_results to hello.the_buffer_port.
>>> rechecking hello: true
>>> 0.048 [ Info ][Logger] Orocos Logging Deactivated.
>>> $
>>>
>>> If you do think you must do it inside the component, then the only way
>>> I can think of would be to dynamic_cast to an InputPortInterface and
>>> check wether the reusult is null.
>>
>> Some remarks:
>> - it makes sense to do Connection chekcing outside of a Component.
>> - it _also_ makes sense _inside_ a Component, to check whether a Port is
>> ready to read data from.
>> - both are _not_ the same thing, necessarily. Certainly not when a
>> component is deployed on a platform that has a shaky Communication
>> infrastructure.
>>
>> My trade-off in this matter would be the following:
>> - the internal state machine of a Component should wait for an event of its
>> Coordinator, giving the "go ahead" to start the Computation inside a
>> Component.
>> - that Computation doesn't care about the "liveliness" of the Ports its
>> works with.
>> - _if_ the Communication is not reliable, or changes often, the _system_
>> has to foresee a "Communication checking" Component, that fires the
>> appropriate "Port Ready"/"Port Not Ready" events, to which the
>> Component's internal state machine can/should react.
>> I think this is the most decoupled design that can still run efficiently,
>> whenever possible.
>
> I fully agree with these two different requirements of
> "connectiveness".
>
They come "for free" (at least, _conceptually_:-) with the new "BRICS
Component Model" :-) We (= BRICS project) plan to publish a White Paper
about these ideas within two weeks; readers of this mailinglist will not be
too surprised, I guess.
> Markus
Herman
Automatically checks input port connection
+1 for doing outside the components and in the deployment system you are
using (whichever it is)
Sylvain
Automatically checks input port connection
2011/5/9 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> +1 for doing outside the components and in the deployment system you are
> using (whichever it is)
>
hum, to be honest I didn't thought about doing this in deployment system.
Isn't it a component knownledge to say if it has all it needs to work ?
That's why I do it in the configureHook of every component since a
configureHook allows me to return "false" and let him "ls" in the task
browser to check if everything is ok.
Do you mean that a component should work event with disconnected ports ?
My global assertion is that if some input ports are not connected, things
are going wrong (often because in complex deployment it's easy to break the
system without seing it). So I want the user to know this as soon as
possible,
Could you please detail why it seems so logic for you two to do it in the
deployment system ?
I don't mind doing this in deployment-system but then my problem will be to
create something that check is the deployment was ok. Is the "Valid"
attribute of the deployment done for this ? I didn't find any comments on
it, but it is use in "group" deployment functions. BTW, if this "deployment"
success checking (including load,addPeer,configure,connectPort,
checkAllPortconnected, start, ...) is recurrent, I will be nice for user to
have a wiki page or an example somewhere with the "best praticde" (or better
having a deployer doing this).
@ Markus : I am very please to see lua coming in place or next to RTT
scripts, espacially because it'll allows to code more easilly; But it is one
more language to learn (rtt script is basicly C syntax) and it seems to be
still in progress :
http://www.orocos.org/wiki/orocos/toolchain/orocostoolchainluacookbook
(some section are still "TBD", and I am waiting this to go into
http://www.orocos.org/wiki/orocos/toolchain/toolchain-reference-manuals for
using it).
I'll have a try at this in a month or two, cause we have a deadline soon.
> Sylvain
>
Automatically checks input port connection
On 05/09/2011 11:22 AM, Willy Lambert wrote:
> hum, to be honest I didn't thought about doing this in deployment
> system. Isn't it a component knownledge to say if it has all it needs to
> work ? That's why I do it in the configureHook of every component since
> a configureHook allows me to return "false" and let him "ls" in the task
> browser to check if everything is ok.
>
> Do you mean that a component should work event with disconnected ports ?
I agree that it depends on the components themselves (i.e. it is a
component knowledge). In Rock (i.e. orogen), I am planning to add a
required_input flag for input ports that would declare what ports are
really required.
> My global assertion is that if some input ports are not connected,
> things are going wrong (often because in complex deployment it's easy to
> break the system without seing it). So I want the user to know this as
> soon as possible,
Fully agreed. The thing is: you can check that outside of the component
and forbid configuration (what is going to happen in rock).
> Could you please detail why it seems so logic for you two to do it in
> the deployment system ?
Because it is done at a generic level (done once for all components),
and can be checked even before configureHook is called. Moreover, you
can make it context-dependent -- not for your application, obviously,
but on a generic architectural level it is nice.
Automatically checks input port connection
2011/5/9 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 05/09/2011 11:22 AM, Willy Lambert wrote:
>
>> hum, to be honest I didn't thought about doing this in deployment
>> system. Isn't it a component knownledge to say if it has all it needs to
>> work ? That's why I do it in the configureHook of every component since
>> a configureHook allows me to return "false" and let him "ls" in the task
>> browser to check if everything is ok.
>>
>> Do you mean that a component should work event with disconnected ports ?
>>
> I agree that it depends on the components themselves (i.e. it is a
> component knowledge). In Rock (i.e. orogen), I am planning to add a
> required_input flag for input ports that would declare what ports are really
> required.
>
>
> My global assertion is that if some input ports are not connected,
>> things are going wrong (often because in complex deployment it's easy to
>> break the system without seing it). So I want the user to know this as
>> soon as possible,
>>
> Fully agreed. The thing is: you can check that outside of the component and
> forbid configuration (what is going to happen in rock).
>
>
> Could you please detail why it seems so logic for you two to do it in
>> the deployment system ?
>>
> Because it is done at a generic level (done once for all components), and
> can be checked even before configureHook is called. Moreover, you can make
> it context-dependent -- not for your application, obviously, but on a
> generic architectural level it is nice.
>
Agree this makes sense for me with the "required" flag, owned by components.
I agree on the "best way to do it".
But AFAIK, I don't think the standard ocl deployer allows this kind of
functionnalities (extract of Markus's LUA code):
tc:getPortNames()
local info = p:info()
if info.porttype == 'in'
So I'll need to create a new addRequiredPort and private:requiredPortList in
my top MyTaskContext, derivate the existing deployer, add a check Required
ports to it. This is quite lot of stuff since I am doing it currently in 5
lines :)
At the end it's the LUA deployer who's scoring points because it has access
to more functionnalities than the standard ocl deployer
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
Automatically checks input port connection
On May 9, 2011, at 07:52 , Willy Lambert wrote:
>
>
> 2011/5/9 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 05/09/2011 11:22 AM, Willy Lambert wrote:
> hum, to be honest I didn't thought about doing this in deployment
> system. Isn't it a component knownledge to say if it has all it needs to
> work ? That's why I do it in the configureHook of every component since
> a configureHook allows me to return "false" and let him "ls" in the task
> browser to check if everything is ok.
>
> Do you mean that a component should work event with disconnected ports ?
> I agree that it depends on the components themselves (i.e. it is a component knowledge). In Rock (i.e. orogen), I am planning to add a required_input flag for input ports that would declare what ports are really required.
>
>
> My global assertion is that if some input ports are not connected,
> things are going wrong (often because in complex deployment it's easy to
> break the system without seing it). So I want the user to know this as
> soon as possible,
> Fully agreed. The thing is: you can check that outside of the component and forbid configuration (what is going to happen in rock).
>
>
> Could you please detail why it seems so logic for you two to do it in
> the deployment system ?
> Because it is done at a generic level (done once for all components), and can be checked even before configureHook is called. Moreover, you can make it context-dependent -- not for your application, obviously, but on a generic architectural level it is nice.
>
> Agree this makes sense for me with the "required" flag, owned by components. I agree on the "best way to do it".
>
> But AFAIK, I don't think the standard ocl deployer allows this kind of functionnalities (extract of Markus's LUA code):
> tc:getPortNames()
> local info = p:info()
> if info.porttype == 'in'
> So I'll need to create a new addRequiredPort and private:requiredPortList in my top MyTaskContext, derivate the existing deployer, add a check Required ports to it. This is quite lot of stuff since I am doing it currently in 5 lines :)
I agree. While the theoretical benefit for doing this "properly" within the deployment system (which BTW, makes little sense to me) might be evident to some, it seems like a lot of extra work vs Peter's practical suggestion of simply being able to idenity port types at runtime.
And we check the required connectedness of _all_ our input ports, within each individual component, similar to Willy's suggestion. The component itself is the only one who has the necessary knowledge to do this AFAICT.
S
Automatically checks input port connection
Hi Willy,
On Mon, May 09, 2011 at 11:22:04AM +0200, Willy Lambert wrote:
>
> @ Markus : I am very please to see lua coming in place or next to RTT scripts,
> espacially because it'll allows to code more easilly; But it is one more
> language to learn (rtt script is basicly C syntax) and it seems to be still in
> progress :
I agree it is something new - again. But it is also so simple that
anyone who can deal with C++ will have no problem at all.
Note that the Lua bindings themselves are already very stable, only
the docs are in progress :-)
> http://www.orocos.org/wiki/orocos/toolchain/orocostoolchainluacookbook
> (some section are still "TBD", and I am waiting this to go into http://
> www.orocos.org/wiki/orocos/toolchain/toolchain-reference-manuals for using it).
> I'll have a try at this in a month or two, cause we have a deadline soon.
Great!
Markus
Automatically checks input port connection
On Mon, May 09, 2011 at 11:45:00AM +0200, Markus Klotzbuecher wrote:
> On Mon, May 09, 2011 at 11:22:04AM +0200, Willy Lambert wrote:
> >
> > @ Markus : I am very please to see lua coming in place or next to RTT scripts,
> > espacially because it'll allows to code more easilly; But it is one more
> > language to learn (rtt script is basicly C syntax) and it seems to be still in
> > progress :
>
> I agree it is something new - again. But it is also so simple that
> anyone who can deal with C++ will have no problem at all.
>
> Note that the Lua bindings themselves are already very stable, only
> the docs are in progress :-)
I found this use case of runtime system validation an excellent
example for the non-realtime use of Lua, so I added a slightly cleaned
up and generalized version of it to the LuaCookbook:
http://www.orocos.org/wiki/orocos/toolchain/luacookbook#toc40
It also illustrates the (IMHO tremendously useful) mappeers function.
Best regards
Markus
Automatically checks input port connection
2011/6/6 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> On Mon, May 09, 2011 at 11:45:00AM +0200, Markus Klotzbuecher wrote:
> > On Mon, May 09, 2011 at 11:22:04AM +0200, Willy Lambert wrote:
> > >
> > > @ Markus : I am very please to see lua coming in place or next to RTT
> scripts,
> > > espacially because it'll allows to code more easilly; But it is one
> more
> > > language to learn (rtt script is basicly C syntax) and it seems to be
> still in
> > > progress :
> >
> > I agree it is something new - again. But it is also so simple that
> > anyone who can deal with C++ will have no problem at all.
> >
> > Note that the Lua bindings themselves are already very stable, only
> > the docs are in progress :-)
>
> I found this use case of runtime system validation an excellent
> example for the non-realtime use of Lua, so I added a slightly cleaned
> up and generalized version of it to the LuaCookbook:
>
> http://www.orocos.org/wiki/orocos/toolchain/luacookbook#toc40
>
> It also illustrates the (IMHO tremendously useful) mappeers function.
>
>
great I'll try it as I'll soon try lua
> Best regards
> Markus
>
Automatically checks input port connection
On Mon, 9 May 2011, Willy Lambert wrote:
> 2011/5/9 Sylvain Joyeux <sylvain [dot] joyeux [..] ...sylvain [dot] joyeux [..] ...>>
> +1 for doing outside the components and in the deployment system you are
> using (whichever it is)
>
>> hum, to be honest I didn't thought about doing this in deployment system.
>> Isn't it a component knownledge to say if it has all it needs to work ?
>> That's why I do it in the configureHook of every component since a
>> configureHook allows me to return "false" and let him "ls" in the task
>> browser to check if everything is ok.
>>
>> Do you mean that a component should work event with disconnected ports ?
Maybe this could make sense, in some cases. Maybe not in others. For
example, if your Component is responsible to control a piece of hardware,
it might be responsible to keep this hardware safely alive and controlled,
even though it has not received new command setpoints from its "master" for
some time...?
Anyway, it makes sense to decouple the following things in the "ports":
- the Connection: has it been established or not?
- the Service(s) that can be deployed on top of a Connection: which one is
doing okay, and which one not?
- the Port, which is the connection between the internal Computation of a
Component and the Service(s) that use/provide in/output between
Components.
Each of them should, ideally, have its own "state checking". Currently, RTT
is not discriminative enough in what it checks (or allows to check).
> My global assertion is that if some input ports are not connected, things
> are going wrong (often because in complex deployment it's easy to break
> the system without seing it). So I want the user to know this as soon as
> possible,
"The user" might be behind another Port and/or Connection, so impossible to
reach, maybe. Anyway, the really important thing is what the _internal
Computation_ does, and your use case (of letting the Component inform "the
user" of potential communication problems) is certainly an important one.
> Could you please detail why it seems so logic for you two to do it in the
> deployment system ?
Because the "deployment" is responsible for establishing the "Connections",
and for starting/stopping Services on them. The only responsibility of a
Component is to do the Computations that provide/consume the data that
reach it through its Ports.
> I don't mind doing this in deployment-system but then my problem will be
> to create something that check is the deployment was ok. Is the "Valid"
> attribute of the deployment done for this ? I didn't find any comments on
> it, but it is use in "group" deployment functions. BTW, if this
> "deployment" success checking (including
> load,addPeer,configure,connectPort, checkAllPortconnected, start, ...) is
> recurrent, I will be nice for user to have a wiki page or an example
> somewhere with the "best praticde" (or better having a deployer doing
> this).
>
> @ Markus : I am very please to see lua coming in place or next to RTT
> scripts, espacially because it'll allows to code more easilly; But it is
> one more language to learn (rtt script is basicly C syntax) and it seems
> to be still in progress :
> http://www.orocos.org/wiki/orocos/toolchain/orocostoolchainluacookbook
> (some section are still "TBD", and I am waiting this to go into
> http://www.orocos.org/wiki/orocos/toolchain/toolchain-reference-manuals
> for using it).
> I'll have a try at this in a month or two, cause we have a deadline soon.
> Sylvain
>
Herman
Automatically checks input port connection
On Sunday 08 May 2011 16:53:06 Willy Lambert wrote:
> Hi all,
>
> In my application I always want that my components check their input port
> connectivity. But not their output port. (the reason of this is that you
> don't care when you publish, you need input to be well connected unless you
> can't do your job).
> I would like to do it automatically in the configureHook when calling my
> checkInputsPorts function.
>
> My problem is that I can't determine the port "gender" when I get it from
> the port list. Here is my code example which is checking all port
> connection (in and out), what should I use to test the gender ?
You'll have to check ( dynamic_cast<InputPortInterface*>(*it) != 0 ) to find
out if it is an input port.
We could add a virtual to PortInterface.hpp that discloses the type too, with
an enum.
>
>
> bool ARDTaskContext::checkInputsPorts()
> {
> bool res = true;
> DataFlowInterface::Ports portsVector = ports()->getPorts();
> DataFlowInterface::Ports::iterator it;
>
> for(it = portsVector.begin(); it != portsVector.end(); it++)
> {
> if( (*it)->connected() == false )
> {
> LOG(Error) << "checkInputsPorts : " << (*it)->getName() << "
> is not connected !" << endlog();
> res &= false;
> }
>
> }
>
> return res;
> }
Peter