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.

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