DataPorts templates

Hi,

I would like to know what kind of template I can use in a DataPort??
I tried to create a WriteDataPort (WriteDataPort count;) with a long int as a template, but it didn't work.

Thanks

DataPorts templates

On Fri, Jul 03, 2009 at 12:40:32AM +0200, diegos [..] ... wrote:

> I would like to know what kind of template I can use in a DataPort??
> I tried to create a WriteDataPort (WriteDataPort<long int> count;) with a long int as a template, but it didn't work.

You'll need to be more specific. What exactly did you do, what did not
work, which error messages did you get, which version, platform...

Best regards
Markus

Re: [Orocos-Dev] DataPorts templates

Hi,

I'm using the RTT and OCL-1.8.2 with RTAI/Linux.

I only want to make a DataPort with a long int type. I create a component with this type of DataPort and in the updateHook function, I set it with a value. Then, I use the deployer to start the system with this component and the ReporterFile. The ReporterFile is connected to my component to report that DataPort. But the reporter don't log this port. Using the TaskBrowser, I can see the DataPort in my component as:

Data Flow Ports:
W(C) unknown_t Count = (unknown_t)

If I try this, a error occurs:

In Task Sampler[R]. (Status of last Command : none )
(type 'ls' for context info) :Count.Set(1)
Got :Count.Set(1)
Wrong type of argument provided for argument number 1 in call of function "this.Set". Expected type unknown_t const&, got type int.

This is the code:
How I declare the port
WriteDataPort count;

How I initialize the port
count("Count",0),

How I add the port
this->ports()->addPort(&count);

How I write to port
void Sampler::updateHook()
{
long int a=4;
count.Set(a);
}

DataPorts templates

On Fri, Jul 3, 2009 at 20:40, <diegos [..] ...> wrote:
> Hi,
>
> I'm using the RTT and OCL-1.8.2 with RTAI/Linux.
>
> I only want to make a DataPort with a long int type. I create a component with this type of DataPort and in the updateHook function, I set it with a value. Then, I use the deployer to start the system with this component and the ReporterFile. The ReporterFile is connected to my component to report that DataPort. But the reporter don't log this port. Using the TaskBrowser, I can see the DataPort in my component as:
>
> Data Flow Ports:
>  W(C)   unknown_t Count           = (unknown_t)

This means the 'long int' type is not known to the Orocos type system.
If int is not what you want, you need to add 'long int' yourself. As
described in http://www.orocos.org/stable/documentation/rtt/v1.8.x/doc-xml/orocos-too...

You'll also need to specify constructors and type conversions in order
to integrate it with the other types. For example, the scripting will
read '12' always as an int, so 'var long ml = 3' won't work
automatically. If you only want reporting + display using the
TaskBrowser, just add

&#10;RTT::types()-&gt;addType( new RTT::TemplateTypeInfo&lt;long int,true&gt;(&quot;long&quot;);&#10;

In the constructor of a component you load early on.

Peter

DataPorts templates

On Jul 22, 2009, at 06:49 , Peter Soetens wrote:

> On Fri, Jul 17, 2009 at 19:23, S Roderick<kiwi [dot] net [..] ...> wrote:
>> On Jul 14, 2009, at 05:49 , Peter Soetens wrote:
>>
>>> On Fri, Jul 3, 2009 at 20:40, <diegos [..] ...> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm using the RTT and OCL-1.8.2 with RTAI/Linux.
>>>>
>>>> I only want to make a DataPort with a long int type. I create a
>>>> component
>>>> with this type of DataPort and in the updateHook function, I set
>>>> it with a
>>>> value. Then, I use the deployer to start the system with this
>>>> component and
>>>> the ReporterFile. The ReporterFile is connected to my component
>>>> to report
>>>> that DataPort. But the reporter don't log this port. Using the
>>>> TaskBrowser,
>>>> I can see the DataPort in my component as:
>>>>
>>>> Data Flow Ports:
>>>> W(C) unknown_t Count = (unknown_t)
>>>
>>> This means the 'long int' type is not known to the Orocos type
>>> system.
>>> If int is not what you want, you need to add 'long int' yourself. As
>>> described in
>>> http://www.orocos.org/stable/documentation/rtt/v1.8.x/doc-xml/orocos-too...
>>
>> On a similar note, why is it that "int" is not a known type to the
>> type/property system? And that "short" is known to the type/
>> property system,
>> and can be converted to "int" properties transparently.
>
>>
>> A colleague has just spent hours tracking down a bug, that simply
>> turned out
>> to be an "int" property in the class but that needed to be a
>> "short" type in
>> the XML property file. When they put "int" as a property, the XML
>> type
>> reading system doesn't complain of the type but complains that it
>> can't find
>> the property instead
>
> Didn't Xerces trap the 'int' mistake in the XML file ? It does
> validation and 'int' is not valid. We use the CORBA property format
> dtd, which uses the CORBA naming conventions for types. ie
> 'short'/'long' is known, 'int' is not.
> The RTT code converts 'short' *and* 'long' to 'int' during the
> demarshalling. We'll be getting into trouble on 64 bit systems...

IIRC xerces is optional? Isn't it possible to use an alternative,
though less capable, XML tool? The only error they got is that
"ERROR ... property int XXX not found in source" listed below.

64-bit ... I would think that some of us would already be there and
would already have hit problems?

>> {{{
>> 5.725 [ ERROR ][refreshProperties] Could not find Property int XXX
>> in
>> source.
>> 5.725 [ ERROR ][refreshProperties] Could not find Property int YYY
>> in
>> source.
>> }}}
>>
>> I vaguely remember seeing commented out code for either "int" or
>> "long int"
>> within the type/property system, and I'm curious what the cause of
>> the
>> omission was.
>
> I can't recall :-) Probablythe implementation was not finished. Each
> new type requires a load of new functions and convertors to be
> carefully added. Probably I didn't need long, so we didn't
> complete/add it.

It looked like this, yes, if my aging and overloaded brain is
remembering correctly ...
S

DataPorts templates

On Wed, Jul 22, 2009 at 13:46, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> On Jul 22, 2009, at 06:49 , Peter Soetens wrote:
>
>> On Fri, Jul 17, 2009 at 19:23, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>
>>> On Jul 14, 2009, at 05:49 , Peter Soetens wrote:
>>>
>>>> On Fri, Jul 3, 2009 at 20:40, <diegos [..] ...> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm using the RTT and OCL-1.8.2 with RTAI/Linux.
>>>>>
>>>>> I only want to make a DataPort with a long int type. I create a
>>>>> component
>>>>> with this type of DataPort and in the updateHook function, I set it
>>>>> with a
>>>>> value. Then, I use the deployer to start the system with this component
>>>>> and
>>>>> the ReporterFile. The ReporterFile is connected to my component to
>>>>> report
>>>>> that DataPort. But the reporter don't log this port. Using the
>>>>> TaskBrowser,
>>>>> I can see the DataPort in my component as:
>>>>>
>>>>> Data Flow Ports:
>>>>>  W(C)   unknown_t Count           = (unknown_t)
>>>>
>>>> This means the 'long int' type is not known to the Orocos type system.
>>>> If int is not what you want, you need to add 'long int' yourself. As
>>>> described in
>>>>
>>>> http://www.orocos.org/stable/documentation/rtt/v1.8.x/doc-xml/orocos-too...
>>>
>>> On a similar note, why is it that "int" is not a known type to the
>>> type/property system? And that "short" is known to the type/property
>>> system,
>>> and can be converted to "int" properties transparently.
>>
>>>
>>> A colleague has just spent hours tracking down a bug, that simply turned
>>> out
>>> to be an "int" property in the class but that needed to be a "short" type
>>> in
>>> the XML property file. When they put "int" as a property, the XML type
>>> reading system doesn't complain of the type but complains that it can't
>>> find
>>> the property instead
>>
>> Didn't Xerces trap the 'int' mistake in the XML file ? It does
>> validation and 'int' is not valid. We use the CORBA property format
>> dtd, which uses the CORBA naming conventions for types. ie
>> 'short'/'long' is known, 'int' is not.
>> The RTT code converts 'short' *and* 'long' to 'int' during the
>> demarshalling. We'll be getting into trouble on 64 bit systems...
>
> IIRC xerces is optional? Isn't it possible to use an alternative, though
> less capable, XML tool? The only error they got is that "ERROR ... property
> int XXX not found in source" listed below.

It is optional, but you'll need to write correct XML files then. the
alternative does not do validation, so the error is only detected
later on. At least, I think this is what bite you...

>
> 64-bit ... I would think that some of us would already be there and would
> already have hit problems?

CORBA says short = 16 bit, long = 32 bit, long long = 64 bit. We only
'support' short and long and map both to 'int' which is 32 or 64 bit.
On the other hand, we write int as CORBA 'long' to disk, which is
wrong on 64bit systems.

Peter

DataPorts templates

> > 64-bit ... I would think that some of us would already be there and would
> > already have hit problems?
I've been bitten by it, but simply made orogen forcefully reject XML
marshalling of anything that includes 64 bit types -- due to lack of
time/laziness of my part to add 64 bits to the Orocos type system.

> CORBA says short = 16 bit, long = 32 bit, long long = 64 bit. We only
> 'support' short and long and map both to 'int' which is 32 or 64 bit.
> On the other hand, we write int as CORBA 'long' to disk, which is
> wrong on 64bit systems.
No, it is right on all systems. "long" changes size between 32 and 64 bits
systems, not "int". I guess they did that so that all programs that were
assuming that int was 32bit would still work on 64 bits ...

DataPorts templates

On Jul 14, 2009, at 05:49 , Peter Soetens wrote:

> On Fri, Jul 3, 2009 at 20:40, <diegos [..] ...> wrote:
>> Hi,
>>
>> I'm using the RTT and OCL-1.8.2 with RTAI/Linux.
>>
>> I only want to make a DataPort with a long int type. I create a
>> component with this type of DataPort and in the updateHook
>> function, I set it with a value. Then, I use the deployer to start
>> the system with this component and the ReporterFile. The
>> ReporterFile is connected to my component to report that DataPort.
>> But the reporter don't log this port. Using the TaskBrowser, I can
>> see the DataPort in my component as:
>>
>> Data Flow Ports:
>> W(C) unknown_t Count = (unknown_t)
>
> This means the 'long int' type is not known to the Orocos type system.
> If int is not what you want, you need to add 'long int' yourself. As
> described in http://www.orocos.org/stable/documentation/rtt/v1.8.x/doc-xml/orocos-too...

On a similar note, why is it that "int" is not a known type to the
type/property system? And that "short" is known to the type/property
system, and can be converted to "int" properties transparently.

A colleague has just spent hours tracking down a bug, that simply
turned out to be an "int" property in the class but that needed to be
a "short" type in the XML property file. When they put "int" as a
property, the XML type reading system doesn't complain of the type but
complains that it can't find the property instead

{{{
5.725 [ ERROR ][refreshProperties] Could not find Property int XXX in
source.
5.725 [ ERROR ][refreshProperties] Could not find Property int YYY in
source.
}}}

I vaguely remember seeing commented out code for either "int" or "long
int" within the type/property system, and I'm curious what the cause
of the omission was.

FYI
S

DataPorts templates

Hi Diego,

On Fri, Jul 03, 2009 at 08:40:40PM +0200, diegos [..] ... wrote:

> I'm using the RTT and OCL-1.8.2 with RTAI/Linux.
>
> I only want to make a DataPort with a long int type. I create a
> component with this type of DataPort and in the updateHook function,
> I set it with a value. Then, I use the deployer to start the system
> with this component and the ReporterFile. The ReporterFile is
> connected to my component to report that DataPort. But the reporter
> don't log this port. Using the TaskBrowser, I can see the DataPort
> in my component as:
>
> Data Flow Ports:
> W(C) unknown_t Count = (unknown_t)

Ok, I see. It seems that the current scripting layer does not support
long types, which are commented out in
StateMachineProcessor:144. Maybe Peter can comment on this.

> If I try this, a error occurs:
>
> In Task Sampler[R]. (Status of last Command : none )
> (type 'ls' for context info) :Count.Set(1)
> Got :Count.Set(1)
> Wrong type of argument provided for argument number 1 in call of function "this.Set". Expected type unknown_t const&, got type int.
>
>
> This is the code:
> How I declare the port
> WriteDataPort<long int> count;
>
> How I initialize the port
> count("Count",0),
>
> How I add the port
> this->ports()->addPort(&count);
>
> How I write to port
> void Sampler::updateHook()
> {
> long int a=4;
> count.Set(a);
> }

This look ok. Maybe you can use "unsigned int" as a temporary
workaround?

Best regards
Markus