connecting ports added during configureHook()

In what is probably another example of me abusing the tool… I'm trying to use a deployment XML file to connect to some ports that are added during the configureHook of a component. But order of operations isn't my friend.

So I have ComponentA. It has a property, and based on that property, an OutputPort is added for a given type. I only want one OutputPort for ComponentA, named "ReadPort", so that I can make my deployment XMLs and scripts type-agnostic. The ulterior motive here is that I can reuse ComponentA for different data types, by only changing which property file is loaded. I also have ComponentB and it wants to connect to ComponentA's OutputPort.

If I'm using a deployer script (either in ops or Lua), I can easily call ComponentA.configure() before I connect ComponentB to ComponentA's port. (It's up to me to ensure that ComponentA's property and ComponentB's port type match.) However, when using a deployment XML, this doesn't work:

/**
[ ERROR ][DeploymentComponent::loadComponents] Component 'ComponentA' does not have a Port 'ReadPort'.
**/

This is because, as far as I can tell, XML style deployments attempt to assign ports to connection policies before configure is called.

Do I really have to have a unique ComponentA-style component for each data type or force ComponentA to have an OutputPort of each data type (thus forcing my deployments to be typed as well)?

--
Dustin Gooding
NASA/JSC Robotics

connecting ports added during configureHook()

Il giorno lun, 13/02/2012 alle 15.29 -0600, Gooding, Dustin R.
(JSC-ER411) ha scritto:
> In what is probably another example of me abusing the tool… I'm trying
> to use a deployment XML file to connect to some ports that are added
> during the configureHook of a component. But order of operations
> isn't my friend.
>
>
> So I have ComponentA. It has a property, and based on that property,
> an OutputPort is added for a given type. I only want one OutputPort
> for ComponentA, named "ReadPort", so that I can make my deployment
> XMLs and scripts type-agnostic. The ulterior motive here is that I
> can reuse ComponentA for different data types, by only changing which
> property file is loaded. I also have ComponentB and it wants to
> connect to ComponentA's OutputPort.
>
>
> If I'm using a deployer script (either in ops or Lua), I can easily
> call ComponentA.configure() before I connect ComponentB to
> ComponentA's port. (It's up to me to ensure that ComponentA's
> property and ComponentB's port type match.) However, when using a
> deployment XML, this doesn't work:
>
>
> /**
> [ ERROR ][DeploymentComponent::loadComponents] Component 'ComponentA'
> does not have a Port 'ReadPort'.
> **/
>
>
> This is because, as far as I can tell, XML style deployments attempt
> to assign ports to connection policies before configure is called.
>
>
> Do I really have to have a unique ComponentA-style component for each
> data type or force ComponentA to have an OutputPort of each data type
> (thus forcing my deployments to be typed as well)?
>
> --
> Dustin Gooding
> NASA/JSC Robotics
Hi Dustin,
i solved i similar problem with a state machine (old fashion)
in my case i needed a value written in a port to configure the following
component...
in your case i suppose that instead of "M_sim_robot.configure" you have
to connect ports...

a snippet of the code:
-----------------------------------------------------
StateMachine Master
{
var array f;
initial state M_joint
{
entry
{
//components that can be started independently

M_join_contr.configure;
M_join_contr.start;
}

// guard this transition: go on only if a sample is written
transition if M_sim_robot.IP_Qr.read (f)!=NoData &&
M_o1a.ip_q.read(f)!=NoData
then select M_sim_rob

}
state M_sim_rob
{
entry
{
M_sim_robot.configure;
M_sim_robot.start;
M_o1a.configure;
M_o1a.start;
}
// guard this transition go on only if a sample is written
transition if M_o2.ip_q.read (f)!=NoData then
select M_o2_start
}
......etc etc
----------------------------------------

Cheers, Gianni.

connecting ports added during configureHook()

On Feb 13, 2012, at 16:29 , Gooding, Dustin R. (JSC-ER411) wrote:

> In what is probably another example of me abusing the tool… I'm trying to use a deployment XML file to connect to some ports that are added during the configureHook of a component. But order of operations isn't my friend.
>
> So I have ComponentA. It has a property, and based on that property, an OutputPort is added for a given type. I only want one OutputPort for ComponentA, named "ReadPort", so that I can make my deployment XMLs and scripts type-agnostic. The ulterior motive here is that I can reuse ComponentA for different data types, by only changing which property file is loaded. I also have ComponentB and it wants to connect to ComponentA's OutputPort.
>
> If I'm using a deployer script (either in ops or Lua), I can easily call ComponentA.configure() before I connect ComponentB to ComponentA's port. (It's up to me to ensure that ComponentA's property and ComponentB's port type match.) However, when using a deployment XML, this doesn't work:
>
> /**
> [ ERROR ][DeploymentComponent::loadComponents] Component 'ComponentA' does not have a Port 'ReadPort'.
> **/
>
> This is because, as far as I can tell, XML style deployments attempt to assign ports to connection policies before configure is called.
>
> Do I really have to have a unique ComponentA-style component for each data type or force ComponentA to have an OutputPort of each data type (thus forcing my deployments to be typed as well)?

We ran into the same problem with the v1 deployer also. We went with custom components in the end, as we didn't have many to do. But I suspect you _might_ be able to get around this, depending on your system architecture, by deploying in multiple stages (same as we do for logging, using the "-s" option to the deployer). If one of your earlier deployment files creates the component with the dynamic ports, and a later deployment file makes the connections, then everything should be created in the correct sequence. This is a hack.

This problem is a huge limitation on the scalability of the deployment system. I looked into it a couple of years back when we first hit this issue, and concluded that you'd want to add something like a pre-/self-configure step to a task context, or modify the deployer to provide something similar. I'm sure others will have alternative points of view … ;-)
S

Ruben Smits's picture

connecting ports added during configureHook()

On Mon, Feb 13, 2012 at 11:46 PM, S Roderick <kiwi [dot] net [..] ...> wrote:

> On Feb 13, 2012, at 16:29 , Gooding, Dustin R. (JSC-ER411) wrote:
>
> > In what is probably another example of me abusing the tool… I'm trying
> to use a deployment XML file to connect to some ports that are added during
> the configureHook of a component. But order of operations isn't my friend.
> >
> > So I have ComponentA. It has a property, and based on that property, an
> OutputPort is added for a given type. I only want one OutputPort for
> ComponentA, named "ReadPort", so that I can make my deployment XMLs and
> scripts type-agnostic. The ulterior motive here is that I can reuse
> ComponentA for different data types, by only changing which property file
> is loaded. I also have ComponentB and it wants to connect to ComponentA's
> OutputPort.
> >
> > If I'm using a deployer script (either in ops or Lua), I can easily call
> ComponentA.configure() before I connect ComponentB to ComponentA's port.
> (It's up to me to ensure that ComponentA's property and ComponentB's port
> type match.) However, when using a deployment XML, this doesn't work:
> >
> > /**
> > [ ERROR ][DeploymentComponent::loadComponents] Component 'ComponentA'
> does not have a Port 'ReadPort'.
> > **/
> >
> > This is because, as far as I can tell, XML style deployments attempt to
> assign ports to connection policies before configure is called.
> >
> > Do I really have to have a unique ComponentA-style component for each
> data type or force ComponentA to have an OutputPort of each data type (thus
> forcing my deployments to be typed as well)?
>
> We ran into the same problem with the v1 deployer also. We went with
> custom components in the end, as we didn't have many to do. But I suspect
> you _might_ be able to get around this, depending on your system
> architecture, by deploying in multiple stages (same as we do for logging,
> using the "-s" option to the deployer). If one of your earlier deployment
> files creates the component with the dynamic ports, and a later deployment
> file makes the connections, then everything should be created in the
> correct sequence. This is a hack.
>
> This problem is a huge limitation on the scalability of the deployment
> system. I looked into it a couple of years back when we first hit this
> issue, and concluded that you'd want to add something like a
> pre-/self-configure step to a task context, or modify the deployer to
> provide something similar. I'm sure others will have alternative points of
> view … ;-)
>

When we ran into this problem we left the path of deploying our
applications using XML files and started using scripts instead, the
scripting gave us a lot more possibilities to change the fixed deployement
procedure with the XML files.

> S
>

Ruben

> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

connecting ports added during configureHook()

2012/2/14 Ruben Smits <ruben [dot] smits [..] ...>

>
>
> On Mon, Feb 13, 2012 at 11:46 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>
>> On Feb 13, 2012, at 16:29 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>> > In what is probably another example of me abusing the tool… I'm trying
>> to use a deployment XML file to connect to some ports that are added during
>> the configureHook of a component. But order of operations isn't my friend.
>> >
>> > So I have ComponentA. It has a property, and based on that property,
>> an OutputPort is added for a given type. I only want one OutputPort for
>> ComponentA, named "ReadPort", so that I can make my deployment XMLs and
>> scripts type-agnostic. The ulterior motive here is that I can reuse
>> ComponentA for different data types, by only changing which property file
>> is loaded. I also have ComponentB and it wants to connect to ComponentA's
>> OutputPort.
>> >
>> > If I'm using a deployer script (either in ops or Lua), I can easily
>> call ComponentA.configure() before I connect ComponentB to ComponentA's
>> port. (It's up to me to ensure that ComponentA's property and ComponentB's
>> port type match.) However, when using a deployment XML, this doesn't work:
>> >
>> > /**
>> > [ ERROR ][DeploymentComponent::loadComponents] Component 'ComponentA'
>> does not have a Port 'ReadPort'.
>> > **/
>> >
>> > This is because, as far as I can tell, XML style deployments attempt to
>> assign ports to connection policies before configure is called.
>> >
>> > Do I really have to have a unique ComponentA-style component for each
>> data type or force ComponentA to have an OutputPort of each data type (thus
>> forcing my deployments to be typed as well)?
>>
>> We ran into the same problem with the v1 deployer also. We went with
>> custom components in the end, as we didn't have many to do. But I suspect
>> you _might_ be able to get around this, depending on your system
>> architecture, by deploying in multiple stages (same as we do for logging,
>> using the "-s" option to the deployer). If one of your earlier deployment
>> files creates the component with the dynamic ports, and a later deployment
>> file makes the connections, then everything should be created in the
>> correct sequence. This is a hack.
>>
>> This problem is a huge limitation on the scalability of the deployment
>> system. I looked into it a couple of years back when we first hit this
>> issue, and concluded that you'd want to add something like a
>> pre-/self-configure step to a task context, or modify the deployer to
>> provide something similar. I'm sure others will have alternative points of
>> view … ;-)
>>
>
> When we ran into this problem we left the path of deploying our
> applications using XML files and started using scripts instead, the
> scripting gave us a lot more possibilities to change the fixed deployement
> procedure with the XML files.
>
>
>> S
>
>
+1 ! I run into the problem some years ago and I remember the answer being
: "if you want order in deployment, choose the scrip" (with is logical in
the end).

>
>>
> Ruben
>
>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

connecting ports added during configureHook()

Thanks all.

We had been using various OPS and Lua scripts to deploy up until this point, only because we hadn't delved into the (relatively simple) XML format for the deployer. Now that we have, and now that we see it's best used for straight-forward deployments… we'll just stick with scripted deployments. Thanks.

--
Dustin Gooding
NASA/JSC Robotics

On Feb 14, 2012, at 2:46 AM, Willy Lambert wrote:

2012/2/14 Ruben Smits <ruben [dot] smits [..] ...<mailto:ruben [dot] smits [..] ...>>

On Mon, Feb 13, 2012 at 11:46 PM, S Roderick <kiwi [dot] net [..] ...<mailto:kiwi [dot] net [..] ...>> wrote:
On Feb 13, 2012, at 16:29 , Gooding, Dustin R. (JSC-ER411) wrote:

> In what is probably another example of me abusing the tool… I'm trying to use a deployment XML file to connect to some ports that are added during the configureHook of a component. But order of operations isn't my friend.
>
> So I have ComponentA. It has a property, and based on that property, an OutputPort is added for a given type. I only want one OutputPort for ComponentA, named "ReadPort", so that I can make my deployment XMLs and scripts type-agnostic. The ulterior motive here is that I can reuse ComponentA for different data types, by only changing which property file is loaded. I also have ComponentB and it wants to connect to ComponentA's OutputPort.
>
> If I'm using a deployer script (either in ops or Lua), I can easily call ComponentA.configure() before I connect ComponentB to ComponentA's port. (It's up to me to ensure that ComponentA's property and ComponentB's port type match.) However, when using a deployment XML, this doesn't work:
>
> /**
> [ ERROR ][DeploymentComponent::loadComponents] Component 'ComponentA' does not have a Port 'ReadPort'.
> **/
>
> This is because, as far as I can tell, XML style deployments attempt to assign ports to connection policies before configure is called.
>
> Do I really have to have a unique ComponentA-style component for each data type or force ComponentA to have an OutputPort of each data type (thus forcing my deployments to be typed as well)?

We ran into the same problem with the v1 deployer also. We went with custom components in the end, as we didn't have many to do. But I suspect you _might_ be able to get around this, depending on your system architecture, by deploying in multiple stages (same as we do for logging, using the "-s" option to the deployer). If one of your earlier deployment files creates the component with the dynamic ports, and a later deployment file makes the connections, then everything should be created in the correct sequence. This is a hack.

This problem is a huge limitation on the scalability of the deployment system. I looked into it a couple of years back when we first hit this issue, and concluded that you'd want to add something like a pre-/self-configure step to a task context, or modify the deployer to provide something similar. I'm sure others will have alternative points of view … ;-)

When we ran into this problem we left the path of deploying our applications using XML files and started using scripts instead, the scripting gave us a lot more possibilities to change the fixed deployement procedure with the XML files.

S

+1 ! I run into the problem some years ago and I remember the answer being : "if you want order in deployment, choose the scrip" (with is logical in the end).

Ruben

--
Orocos-Users mailing list
Orocos-Users [..] ...<mailto:Orocos-Users [..] ...>
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

--
Orocos-Users mailing list
Orocos-Users [..] ...<mailto:Orocos-Users [..] ...>
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

--
Orocos-Users mailing list
Orocos-Users [..] ...<mailto:Orocos-Users [..] ...>
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users