Re: #1, if the block's xml is malformed then GRC will basically show
nothing (that grey flowgraph page you describe). Are you defining $ports in
the make node? Compare to a similar block to make sure everything is
defined properly.
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_streams_to_stream.xml

I'm not sure of a way to debug what section might be wrong, so compare
against other blocks with message ports too.



On Sat, Oct 12, 2013 at 12:58 PM, Jared Clements
<jared.cleme...@gmail.com>wrote:

> 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
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to