is there a way to set the order of block instantiations in GNU Radio
companion?
The reason I am asking is, that I want to pass one block as a parameter
to another block to get access to its methods. Is there an easier way to
do this?
Somehow related: Variables configured in GRC are defined before the
block instantiations. Is it possible to tell GRC where in the final
python script a variable should be defined?
is there a way to set the order of block instantiations in GNU Radio
companion?
The reason I am asking is, that I want to pass one block as a parameter
to another block to get access to its methods. Is there an easier way to
do this?
I think the order is either 1) alphabetical or 2) the z dimension of the
blocks in the flowgrah.
Somehow related: Variables configured in GRC are defined before the
block instantiations. Is it possible to tell GRC where in the final
python script a variable should be defined?
The variable blocks are sorted by order of dependency amongst each
other.
is there a way to set the order of block instantiations in GNU Radio
companion?
The reason I am asking is, that I want to pass one block as a parameter
to another block to get access to its methods. Is there an easier way to
do this?
Just for future reference, I found out that, at least for my purposes,
there already exists an elegant way to access a block’s methods. It is
possible to define a “function probe” in GNU Radio companion which
periodically calls a block’s method and saves the result as a variable.
is there a way to set the order of block instantiations in GNU Radio
companion?
The reason I am asking is, that I want to pass one block as a parameter
to another block to get access to its methods. Is there an easier way to
do this?
Just for future reference, I found out that, at least for my purposes,
there already exists an elegant way to access a block’s methods. It is
possible to define a “function probe” in GNU Radio companion which
periodically calls a block’s method and saves the result as a variable.
Sorry, should have mentioned that too!
Function probe gets around this by having a try/catch in its loop so the
block to be probed doesnt have to yet be instantiated when the thread
starts.
-josh
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.