discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] ControlPort setup_rpc function not called for pur


From: Martin Luelf
Subject: Re: [Discuss-gnuradio] ControlPort setup_rpc function not called for pure message passing blocks
Date: Mon, 7 Mar 2016 19:57:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 04.03.2016 18:05, Tom Rondeau wrote:
On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf <address@hidden <mailto:address@hidden>> wrote:

    Dear mailing list,

    we are trying to create a status overview of our receiver by using
    the control ports feature. For most of our custom made blocks this
    works very well and we can see the exported variables.

    But for a few blocks the exported variables do not show up in the
    control port monitor. After putting tracing lines in these blocks
    we found out that the setup_rpc function is not called. The only
    difference we could see between the blocks were the setup_rpc
    function is called and the ones where it is not is that the latter
    have no stream in- or output. Instead they only use the message
    passing API to process data, like the mesage debug block from
    GNURadio.

    A minimal working example of a block whichs setup_rpc() method is
    not called can be found at http://pastebin.com/cBFJCnW7 with
    private and public header files at http://pastebin.com/35WhFqQ0
    and http://pastebin.com/zb4jBRAw

    If we run this block and feed messages to it, we get the following
    output:
    constructor()
    ControlPort Monitor running.
    INFO: Apache Thrift: -h localhost -p 40444
    monitor::endpoints() = -h localhost -p 40444
    process frame()
    process frame()
    [...]
    process frame()
    process frame()
    running: ['gr-ctrlport-monitor', 'localhost', '40444']
    process frame()
    process frame()
    [...]
    process frame()
    process frame()

    We would expect to see an additional line at the beginning saying
    "setup_rpc()" (see line 71 of the c++ code) and consequently see
    the variable "testval" in the control port monitor, like it does
    for our working blocks.

    The above output is generated with GNURadio version
    3.7.8.1-229-g51c0426a manually compiled from source on an Ubuntu
    trusty system (64 bit).

    The only difference we could find between the blocks working as
    expected and the ones that do not, is that they use streaming for
    data transport, i.e. that their work or general_work function has
    some actual data processing and their gr::io_signature is not set
    to (0,0,0).

    I kindly ask for your help to find out why the setup_rpc function
    is not called for our example block posted above and what we can
    do to change this.

    Yours sincerely
    Martin Luelf


Martin,

This definitely sounds like a bug for a case that wasn't planned for initially. Can you open up a bug report with this information on our Issue tracker on gnuradio.org <http://gnuradio.org>?

Thanks,
Tom


I created a new bug #907 that can be viewed at http://gnuradio.org/redmine/issues/907

Thanks for your support.
Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]