Hi,
i read some tutorials about creating new blocks.
Iam asking my self a simple question and i think i couldnt find the
answer:
How is it possible to fill a python grc variable block with data from
another block C++ variable.
I know between C++ and python is the SWIG Framework. What to program in
the C++ file and what to program in the xml file. The way of the C++
variable through the swig to the python workflow is not clear to me.
I know that the grc editor creates a variable section from variables of
all grc blocks in the workflow in the project .py file.
Andy
Dear Andreas,
How is it possible to fill a python grc variable block with data from
another block C++ variable.
not really. GRC variables are a concept that doesn’t exist in the flow
graph or, really, in the python file that GRC generates. They just are
python variables used when setting up the block, and if they are used in
a field for which the block specified a callback method, that method
will be included in a python function that gets called by blocks that
GRC knows can change variables (e.g. GUI input elements); this mechanism
of calling the callbacks doesn’t really work without special glue; if
you really really want, you can use he gr::feval magic to call python
code from C++ which might then call python methods the same way that the
code would do that GRC creates. It’s been over 5 years since I used
feval, and I don’t recommend doing that.
I heartily invite you to do this the “GNU Radio way”: Using message
passing as the way to exchange information between blocks inherently
solves the multithreading problems that otherwise would arise (for
example, assume you’d be able to change the taps of a FIR whilst that
FIR’s work() function is working; what’s the correct behaviour? How do
you avoid segmentation faults when the new taps are shorter than the old
ones?). Also, it lets users understand where data/commands flow rather
than hiding that behind a variable name.
Best regards,
Marcus
Hi Marcus,
Dear Andreas,
How is it possible to fill a python grc variable block with data from
another block C++ variable.
not really. GRC variables are a concept that doesn’t exist in the flow
graph or, really, in the python file that GRC generates. They just are
python variables used when setting up the block
Setting up means to insert the block in the flow graph and configure
them ?!
, and if they are used in
a field for which the block specified a callback method, that method
will be included in a python function that gets called by blocks that
GRC knows can change variables (e.g. GUI input elements); this mechanism
of calling the callbacks doesn’t really work without special glue;
ok and this glue (swig file) is produced by a process triggered by the
make command in a gr_modtools environment ?
How can i tell gr_modtools or make to produce a callback function or
howto program a callback function in the C++ code and the xml
tag in the block xml file myself for my own block so a grc python
variable name from flow graph could be inserted in a field of my new
block later when configuring my new block in the flow graph ?
I heartily invite you to do this the “GNU Radio way”: Using message
passing as the way to exchange information between blocks inherently
solves the multithreading problems that otherwise would arise (for
example, assume you’d be able to change the taps of a FIR whilst that
FIR’s work() function is working; what’s the correct behaviour? How do
you avoid segmentation faults when the new taps are shorter than the old
ones?). Also, it lets users understand where data/commands flow rather
than hiding that behind a variable name.
Yes i read the message passing chapter and the pmt and will go in detail
later.
Best regards,
Marcus
regards und thanks,
Andy
Hi Andreas,
On 06/05/2015 12:51 PM, Andreas L. wrote:
, and if they are used in
a field for which the block specified a callback method, that method
will be included in a python function that gets called by blocks that
GRC knows can change variables (e.g. GUI input elements); this mechanism
of calling the callbacks doesn’t really work without special glue;
ok and this glue (swig file) is produced by a process triggered by the
make command in a gr_modtools environment ?
There’s more glue involved than just swig here. Again, all the magic
that happens behind the curtain can be found when you read the generated
python code.
You’ll notice that for some graphical input elements, there are
functions defined that these input widgets get instructed to inform as
soon as things change. That works because the GUI toolkits allow for
this kind of callback-emulation.
How can i tell gr_modtools or make to produce a callback function or
howto program a callback function in the C++ code and the
xml tag in the block xml file myself for my own block so a grc python
variable name from flow graph could be inserted in a field of my new
block later when configuring my new block in the flow graph ?
Not at all. You’ll need to analyze the way the XML blocks for example of
the qtgui widgets are written, and what the generated python code looks
like, and then you’ll have to manually copy that.
detail later.
Really, do it sooner than later; I do like variables as a means of
thinking when constructing my flow graph, they are O.K. for GUI widgets,
but things get ugly the moment you really want to use them from within a
block – as you might have noticed 
GRC variables originally were
really meant only to be used by python during flow graph creation, and
the whole dynamic reconfigurability of variables at run time came later,
but before message passing worked the way it does now – if I may throw
in wild speculation, I’d assume that if GRC was re-invented today, it
would just set up a message handler for each block using a variable, and
just allow the block author to specify what happens in that message
handler, as well as forcing every variable-changing block to have a
message output port; but: GRC has been around for quite some time, and
its maintenance is a remarkable effort, plus people get slightly
irritated when their block XML stops working.
Is there a particular reason why you wouldn’t use messages?
If you need to use a block that doesn’t take instructions via messages,
write a hier block that accepts messages from the blocks inside of it,
and translates them into getter/setter calls on other blocks; or, better
even, if you think the block you want to use would profit generally from
having a message port for commands/settings, fix that up-stream. There’s
virtually no overhead to having a message port/handler!
Best regards,
Marcus