Check the order, there's apparently only one tag order that works. I brought it up last week and was told it was known behavior.
On Oct 12, 2013 2:59 PM, "Johannes Demel" <
address@hidden> wrote:
Hi Nathan,
My guess is that the problem is a bit more tricky.
The XML block definition works fine as long as the message port is not
present. I can use nports as shown in stream_to_streams.
It also works fine as long as the nports statement is not used and a
message port is defined. This means copy and paste the stream port
definition for every port. Assign a port name manually etc.
Nevertheless the combination using nports and message ports in one XML
definition fails. I hope that clarifies my problem description.
Johannes
On 12.10.2013 13:43, West, Nathan wrote:
> 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
> <address@hidden <mailto:address@hidden>> 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" <address@hidden
> <mailto:address@hidden>> 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
> address@hidden <mailto:address@hidden>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <mailto:address@hidden>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio