# Question developing a new block

**URL:** <https://www.ruby-forum.com/t/question-developing-a-new-block/242215>\
**Category:** GNU Radio\
**Created:** [June 4, 2015, 10:44pm UTC](https://www.ruby-forum.com/t/question-developing-a-new-block/242215 "2015-06-04T22:44:03Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [June 4, 2015, 10:44pm UTC](https://www.ruby-forum.com/t/question-developing-a-new-block/242215/1 "2015-06-04T22:44:03Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![andreas\_l](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/7bcc69/32.png) [@andreas\_l](https://www.ruby-forum.com/u/andreas_l)\
**Post date:** [June 4, 2015, 11:35pm UTC](https://www.ruby-forum.com/t/question-developing-a-new-block/242215/2 "2015-06-04T23:35:27Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![andreas\_l](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/7bcc69/32.png) [@andreas\_l](https://www.ruby-forum.com/u/andreas_l)\
**Post date:** [June 5, 2015, 12:53pm UTC](https://www.ruby-forum.com/t/question-developing-a-new-block/242215/3 "2015-06-05T12:53:31Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![andreas\_l](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/7bcc69/32.png) [@andreas\_l](https://www.ruby-forum.com/u/andreas_l)\
**Post date:** [June 6, 2015, 6:13am UTC](https://www.ruby-forum.com/t/question-developing-a-new-block/242215/4 "2015-06-06T06:13:23Z")

</div>

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