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

[Ando Noriaki]

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/
>
>



-- 
安藤慶昭＠独立行政法人産業技術総合研究所 知能システム研究部門
    統合知能研究グループ 主任研究員, 博士(工学)
    〒305-8568 つくば市梅園1-1-1 中央第2
    e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
    OpenRTM-aist: http://www.openrtm.org

Noriaki Ando, Ph.D.
    Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
    AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
    e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
    OpenRTM-aist: http://www.openrtm.org