Now, if someone can get rid of spammers, we wouldn't need to do this...
Tom
On 03/04/16 18:05, Tom Rondeau wrote:
On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf <address@hidden
<mailto:address@hidden>
<mailto: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>
<http://gnuradio.org>?
Thanks,
Tom