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.
Jared On Oct 12, 2013 2:59 PM, "Johannes Demel" <uf...@student.kit.edu> 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 > > <jared.cleme...@gmail.com <mailto: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 > > <mailto: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 <mailto:Discuss-gnuradio@gnu.org> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org <mailto: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
