[openrtm-users 01233] Fwd: Re: Re: Howto check for data port buffer full error

Geoffrey Biggs geoffrey.biggs ＠ aist.go.jp
2010年 5月 20日 (木) 20:04:05 JST 

It looks like I forgot to send this last mail to the list. For the
benefit of anyone else struggling with the same issue...

Geoff

-------- Original Message --------
Subject: Re: [openrtm-users 01226] Re: Howto check for data port buffer
full 	error
Date: Tue, 18 May 2010 17:53:32 +0900
From: Geoffrey Biggs <geoffrey.biggs ＠ aist.go.jp>
To: Steffen Wittmeier <steffen.wittmeier ＠ in.tum.de>

Hi Steffen

The callbacks themselves are implemented as functors. Look in
ConsoleIn.h in the examples. The ConnListener class implements a
callback functor that can then be placed into any callback slot, as
shown on lines 62 to 94 of ConsoleIn.cpp. Because it's a functor object,
you're not limited to just the operator() method, but can put anything
you like into it to support the behaviour you need.

I hope that answers your question.

Geoff

On 18/05/10 17:45, Steffen Wittmeier wrote:
> Hi Geoff,
> 
> my problem basically is that I can not see where the callback of the
> listener is defined. The ConnectorListener class only implements a
> toString method and the operator(). So what method would be called in
> the case of an error?
> 
> 
> Steffen
> 
> On 05/18/2010 10:36 AM, Geoffrey Biggs wrote:
>> Hi Steffen,
>>
>> The callback is invoked during the processing of the port, which may
>> happen in a parallel task to your component's execution depending on the
>> publishing policy you are using. For example, with the Periodic
>> publishing policy, there is a task running in parallel to your component
>> who's job it is to move data between the buffer of the output port and
>> the actual connection to the other component(s). This publisher can
>> detect several different error conditions; one of them is that the
>> inport's buffer is full. When it detects that the buffer is full, it
>> will call the "buffer full" callback of any attached listeners.
>>
>> Or at least, I think that's what it's supposed to do. I just checked the
>> code (PublisherPeriodic.cpp, line 186) and noticed that it's not
>> actually calling the callback at that point.
>>
>> Dr Ando: Is it the correct behaviour to not call the callback when an
>> inport buffer is full? Currently the publisher only calls the callback
>> for the local buffer being full.
>>
>> Geoff
>>
>> On 18/05/10 17:14, Steffen Wittmeier wrote:
>>> Dear Ando-san,
>>>
>>> thanks for the quick reply. However, maybe I am wrong but the example
>>> shows how to add a data listener to the port. How is the callback evoked
>>> and how can I define the corresponding actions (e.g. wait and retry
>>> send)?
>>>
>>>
>>> Thanks again,
>>> Steffen
>>>
>>> On 05/18/2010 10:08 AM, Ando Noriaki wrote:
>>>> Dear Sttefen-san
>>>>
>>>>
>>>> 2010/5/18 Steffen Wittmeier<steffen.wittmeier ＠ in.tum.de>:
>>>>> Dear Ando-san,
>>>>>
>>>>> we are only using the RTSystemEditor for visualizing the current RTC
>>>>> setup
>>>>> and checking port properties. The entire startup of all components
>>>>> and the
>>>>> creation of the connections is handled directly in the code. So I
>>>>> have to
>>>>> find a way of setting all required properties within the code.
>>>>>
>>>>> What I tried now is to disable the overwrite mode of the buffer and
>>>>> to set
>>>>> the blocking timeout by:
>>>>>
>>>>> CORBA_SeqUtil::push_back(prof.properties, NVUtil::newNV(
>>>>> "dataport.buffer.write.timeout", "0.1"));
>>>>>
>>>>> CORBA_SeqUtil::push_back(prof.properties,
>>>>> NVUtil::newNV("dataport.buffer.write.full_policy", "block"));
>>>>>
>>>>>
>>>>> That works - the remaining question now is: How do I define the
>>>>> callback in
>>>>> case the timeout occured when blocking? The ConnectorListener class
>>>>> is an
>>>>> abstract class. Do I have to derive my own listener class? How do I
>>>>> define
>>>>> the callback then?
>>>>
>>>> Please forgive me for not providing enough documentation.
>>>> An example of Connector(Data)Listener is here.
>>>> http://openrtp.jp/openrtm/svn/OpenRTM-aist/tags/RELEASE_1_0_0/OpenRTM-aist/examples/SimpleIO/ConsoleIn.cpp
>>>>
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Noriaki Ando
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Steffen
>>>>>
>>>>> On 05/18/2010 06:59 AM, Ando Noriaki wrote:
>>>>>>
>>>>>> Dear Steffen-san
>>>>>>
>>>>>> Please use new callbacks defined in ConnectorListener.h in that case.
>>>>>> Two types of callback (listener) are provided in this scheme.  One is
>>>>>> ConnectorDataListener, which receives data from somewhere, and other
>>>>>> is ConnectorListener, which does not receive any data.
>>>>>>
>>>>>> ConnecotrDataListener is as follows.
>>>>>>      * - ON_BUFFER_WRITE:          At the time of buffer write
>>>>>>      * - ON_BUFFER_FULL:           At the time of buffer full
>>>>>>      * - ON_BUFFER_WRITE_TIMEOUT:  At the time of buffer write
>>>>>> timeout
>>>>>>      * - ON_BUFFER_OVERWRITE:      At the time of buffer overwrite
>>>>>>      * - ON_BUFFER_READ:           At the time of buffer read
>>>>>>      * - ON_SEND:                  At the time of sending to InPort
>>>>>>      * - ON_RECEIVED:              At the time of finishing
>>>>>> sending to
>>>>>> InPort
>>>>>>      * - ON_RECEIVER_FULL:         At the time of bufferfull of
>>>>>> InPort
>>>>>>      * - ON_RECEIVER_TIMEOUT:      At the time of timeout of InPort
>>>>>>      * - ON_RECEIVER_ERROR:        At the time of error of InPort
>>>>>>
>>>>>> ConnectorListener is as follows.
>>>>>>      * - ON_BUFFER_EMPTY:       At the time of buffer empty
>>>>>>      * - ON_BUFFER_READTIMEOUT: At the time of buffer read timeout
>>>>>>      * - ON_BUFFER_EMPTY:       At the time of empty of OutPort
>>>>>>      * - ON_SENDER_TIMEOUT:     At the time of timeout of OutPort
>>>>>>      * - ON_SENDER_ERROR:       At the time of error of OutPort
>>>>>>      * - ON_CONNECT:            At the time of connection
>>>>>>      * - ON_DISCONNECT:         At the time of disconnection
>>>>>>
>>>>>> However, ON_BUFFER_FULL and other _FULL callbacks are never called by
>>>>>> default.  Because overwrite mode is enabled in the default ring
>>>>>> buffer.  So DataPort never returns buffer-full error.
>>>>>>
>>>>>> RTSystemEditor, which will be released soon, will provide
>>>>>> functionality in order to specify detail DataPort connector's
>>>>>> properties.
>>>>>>
>>>>>> Please newest version of RTsystemEditor from
>>>>>>
>>>>>> http://www.openrtm.org/pub/OpenRTM-aist/dailybuild/tools/1.0.0/rtmtools-r114-1005061834.zip
>>>>>>
>>>>>>
>>>>>> and try it.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Noriaki Ando
>>>>>>
>>>>>>
>>>>>> 2010/4/27 Steffen Wittmeier<wittmeis ＠ in.tum.de>:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I was looking for the onOverflow callback method as I know it from
>>>>>>> OpenRTM
>>>>>>> 0.42 but I could not find it in version 1.0. Did it move to some
>>>>>>> other
>>>>>>> class?
>>>>>>>
>>>>>>> Maybe I will try the 2nd option using the connectors in the
>>>>>>> meantime.
>>>>>>>
>>>>>>>
>>>>>>> Steffen
>>>>>>>
>>>>>>> On 04/27/2010 12:28 AM, Geoffrey Biggs wrote:
>>>>>>>>
>>>>>>>> One possibility is using the OnOverflow callback on your port.
>>>>>>>> When a
>>>>>>>> buffer overflow occurs, this callback should be called. You can
>>>>>>>> register
>>>>>>>> a functor to this callback for the port in your component.
>>>>>>>>
>>>>>>>> Aside from that, it's possible the status is not being propagated
>>>>>>>> correctly. The buffer is not held directly in the port object.
>>>>>>>> It is
>>>>>>>> held in the connection between the two ports - think of it as the
>>>>>>>> buffer
>>>>>>>> floating in the ether mystically. You could try exposing the
>>>>>>>> connectors
>>>>>>>> and checking their status directly to see if it's being propagated
>>>>>>>> properly.
>>>>>>>>
>>>>>>>> Geoff
>>>>>>>>
>>>>>>>> On 26/04/10 22:17, Steffen Wittmeier wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> how can I check whether a data port buffer is full and sleep for a
>>>>>>>>> retry?
>>>>>>>>>
>>>>>>>>> I tried to get the DataPortStatusList and iterated over the
>>>>>>>>> list to
>>>>>>>>> check the individual status. However, I always received PORT_OK,
>>>>>>>>> even
>>>>>>>>> when the buffer must have been full as I did not receive all
>>>>>>>>> data on
>>>>>>>>> the
>>>>>>>>> other end of the connection. I also received PORT_OK when there
>>>>>>>>> was no
>>>>>>>>> connection between the provider and the consumer data port.
>>>>>>>>>
>>>>>>>>> Any help is appreciated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Steffen Wittmeier
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Steffen Wittmeier
>>>>> Lehrstuhl für Informatik VI
>>>>> Technische Universität München
>>>>> Boltzmannstraße 3, 85748 Garching
>>>>>
>>>>> Telefon : +89 289-18100
>>>>> Telefax : +89 289-18107
>>>>> E-Mail  : steffen.wittmeier ＠ in.tum.de
>>>>> Internet: http://www6.in.tum.de/
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>

openrtm-users メーリングリストの案内