I'll confirm that #2 is either a bug or merely unexpected behavior.  I work
around it by prototyping hier blocks as custom GRC blocks, then using that
to build an OOT module block that actually works.  Being unable to enter
parameters at run time is severely limiting.

I've not experienced #1, that functionality seems to work once I get the
python file and the GRC file matching.  I was getting the same errors for a
while until I found the right idiom.

Jared
On Oct 12, 2013 11:18 AM, "Johannes Demel" <uf...@student.kit.edu> wrote:

> Hi list,
>
> I discovered 2 problems with GRC recently.
>
> 1. I have a custom block with a message port (with a fixed port name)
> and some stream ports which include a <nports>...</nports> definition.
> The whole thing works fine as long as I have a fixed number of ports.
> Each declared separately. But as soon as I use a nport statement GRC
> won't display this block correctly [1]. Even worse if I enter values
> which affect the number of ports, the whole flowgraph will disappear.
> Just a grey flowgraph page.
>
> 2. To make things easier for me (and to not create a well known kind of
> artwork) I use hier blocks. This works fine as long as I have fixed size
> vector ports. But adding a parameter block, say vlen, for vector size to
> dynamically change the hier block doesn't work. The python generator
> does not generate the hier block python file with vlen as vector size.
> Instead it puts in the default value. A parameter block without default
> value results in an error. A hard coded vector size is not exactly
> helpful in this case.
>
> I didn't have time to dig into it yet. Thus I thought I share my
> experience with you. Maybe I am not the only one with this problem and
> someone already knows how to fix it.
>
> Happy hacking
> Johannes
>
> [1]
> <sink>
>   <name>msg</name>
>   <type>message</type>
>   <optional>1</optional>
> </sink>
>
> <sink>
>   <name>in</name>
>   <type>complex</type>
>   <vlen>$vlen</vlen>
>   <nports>$ports</nports>
> </sink>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to