# Other block as parameter in GRC **URL:** \ **Category:** GNU Radio\ **Created:** [August 19, 2014, 1:08pm UTC](https://www.ruby-forum.com/t/other-block-as-parameter-in-grc/231616 "2014-08-19T13:08:54Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [August 19, 2014, 1:08pm UTC](https://www.ruby-forum.com/t/other-block-as-parameter-in-grc/231616/1 "2014-08-19T13:08:54Z")
Hi, how can I pass an other block from my flowgraph to a self written block in the gnuradio-companion? What I want to do is invoking a method of that passed block in my own one (or maybe there’s an other way to do that?). I have tried passing the ID of the block to a parameter of type “raw”, but it says Param - \(param\_key): Value “\” cannot be evaluated: name ‘\’ is not defined in the block properties in the GRC. I thought that is what raw was for? What I exactly want to do is switching filters or, what I am trying with the above, change the taps of one filter, at runtime. So if you have any suggestions for that, please also tell me. Cheers Julius ---
**Author:** ![Julius\_Durst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/f14d63/32.png) [@Julius\_Durst](https://www.ruby-forum.com/u/Julius_Durst)\ **Post date:** [August 19, 2014, 2:26pm UTC](https://www.ruby-forum.com/t/other-block-as-parameter-in-grc/231616/2 "2014-08-19T14:26:43Z")
On 08/19/2014 01:07 PM, Julius Durst wrote: > name ‘\’ is not defined in the block properties in > the GRC. > > I thought that is what raw was for? > > What I exactly want to do is switching filters or, what I am trying with > the above, change the taps of one filter, at runtime. So if you have any > suggestions for that, please also tell me. raw is for python code. Blocks are not instantiated at design time so they are not in the namespace when GRC does the FG validation. Consider putting those taps in variable and use a callback. Or, if your tap update is triggered from within the flowgraph, use message passing. ---
**Author:** ![Julius\_Durst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/f14d63/32.png) [@Julius\_Durst](https://www.ruby-forum.com/u/Julius_Durst)\ **Post date:** [August 19, 2014, 3:34pm UTC](https://www.ruby-forum.com/t/other-block-as-parameter-in-grc/231616/3 "2014-08-19T15:34:11Z")
On 19.08.2014 14:25, Koslowski, Sebastian (CEL) wrote: > > Param - \(param\_key): > > raw is for python code. Blocks are not instantiated at design time so > they are not in the namespace when GRC does the FG validation. Consider > putting those taps in variable and use a callback. Or, if your tap > update is triggered from within the flowgraph, use message passing. Thanks, now I understand the purpose of raw. For using a callback I would have to change the variable in the top\_block, which is AFAIK not easily possible (Function Probe is a possibility, but I do not really want any polling). Correct me if I’m wrong. For using message passing I would have to create a custom filter block (that updates upon messages). I will consider that if there is no easier solution. Is there any way to pass that block-ID in the GRC and avoid an error in the FG validation? Because the FG works after correcting the python code generated by the GRC by putting the block-ID/object into the parameters of the other one. I just realize that this of course requires the filter-block to be instanciated first. Which is probably the reason why it is not such a good idea to let the companion do it. Cheers Julius ---
**Author:** ![Julius\_Durst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/f14d63/32.png) [@Julius\_Durst](https://www.ruby-forum.com/u/Julius_Durst)\ **Post date:** [August 19, 2014, 5:02pm UTC](https://www.ruby-forum.com/t/other-block-as-parameter-in-grc/231616/4 "2014-08-19T17:02:51Z")
On 08/19/2014 03:32 PM, Durst, Julius Moritz Stephan wrote: > For using message passing I would have to create a custom filter block > (that updates upon messages). I will consider that if there is no easier > solution. > Why not write a patch to the existing filter block(s): add the message > port, set it to be hidden by default and add parameter to show it on > demand. Could make a nice contribution =) > Is there any way to pass that block-ID in the GRC and avoid an error in > the FG validation? Because the FG works after correcting the python code > generated by the GRC by putting the block-ID/object into the parameters > of the other one. I just realize that this of course requires the > filter-block to be instanciated first. Which is probably the reason why > it is not such a good idea to let the companion do it. > Right. I could create a custom param type for that. Check if the id is > in the fg. Only considering the GRC part, the message passing solution > is nicer, though, because the information flow is clearly visible in the > fg and not “hidden”. ---
**Author:** ![Julius\_Durst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/f14d63/32.png) [@Julius\_Durst](https://www.ruby-forum.com/u/Julius_Durst)\ **Post date:** [August 19, 2014, 5:21pm UTC](https://www.ruby-forum.com/t/other-block-as-parameter-in-grc/231616/5 "2014-08-19T17:21:41Z")
On 08/19/2014 05:01 PM, Sebastian Koslowski wrote: > Right. I could create a custom param type for that. Check if the id is > in the fg. > See if that works for you (untested): > [grc: adding new param type 'block\_id' to reference other blocks · skoslowski/gnuradio@c90e2dd · GitHub](https://github.com/skoslowski/gnuradio/commit/c90e2ddf1cea38ee2400ef56b234758048d980bf) ---
**Author:** ![Julius\_Durst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/f14d63/32.png) [@Julius\_Durst](https://www.ruby-forum.com/u/Julius_Durst)\ **Post date:** [August 19, 2014, 5:44pm UTC](https://www.ruby-forum.com/t/other-block-as-parameter-in-grc/231616/6 "2014-08-19T17:44:45Z")
Thank you very much for your effort. I will have a look into it. I came up with an other idea. I put my block and the filter-block in one hier-block (written in python, not in the GRC of course), in which I can pass the filter-block as parameter to my block, and use only that hier-block in the companion. That works. ---
**Author:** ![Julius\_Durst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/f14d63/32.png) [@Julius\_Durst](https://www.ruby-forum.com/u/Julius_Durst)\ **Post date:** [August 19, 2014, 5:53pm UTC](https://www.ruby-forum.com/t/other-block-as-parameter-in-grc/231616/7 "2014-08-19T17:53:16Z")
On 08/19/2014 05:43 PM, Durst, Julius Moritz Stephan wrote: > Thank you very much for your effort. I will have a look into it. > > I came up with an other idea. I put my block and the filter-block in one > hier-block (written in python, not in the GRC of course), in which I can > pass the filter-block as parameter to my block, and use only that > hier-block in the companion. That works. > Somehow I had pictured your trigger block way down in the processing > chain. =)