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_name>(param_key):
Value “<ID_of_ohter_block>” cannot be evaluated:
name ‘<ID_of_ohter_block>’ 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
On 08/19/2014 01:07 PM, Julius Durst wrote:
name ‘<ID_of_ohter_block>’ 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.
On 19.08.2014 14:25, Koslowski, Sebastian (CEL) wrote:
Param - <param_name>(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
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”.
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
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.
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. =)