Dear all, I've done some debugging in gnuradio-runtime and made the following observations:
- When not connecting the message ports in my example, gnuradio-runtime flattens the hier block, so that only the child blocks remain in the flattened flowgraph. This behavior is correct. - Connecting the message port of the hier_block2 results in the flattening process to only partly succeed. The flatten_aux function fails to determine that the message ports of the hier_block2 are hierarchical, and therefore the message ports (and hier block itself) remain in the flattened graph as normal connections instead of being resolved. The output ports of the hier block are furthermore disconnected (I'm not sure why exactly) which causes the flowgraph validation to fail. - Tracing back why flatten_aux determines that the message ports are not hierarchical, I found the following lines in hier_block2_detail.cc: -- bool hier_out = (d_owner == src.get()) && src->message_port_is_hier_out (srcport);; bool hier_in = (d_owner == dst.get()) && dst->message_port_is_hier_in (dstport); -- At first it seemed to me that this was a small error because d_owner is always top_block for the connections of my hier_block2 and therefore the expression will evaluate to false. Changing these lines to the following resolves the problem I described above: --- bool hier_out = (d_owner != src.get()) && src->message_port_is_hier_out (srcport); bool hier_in = (d_owner != dst.get()) && dst->message_port_is_hier_in (dstport); --- Now, the ports are correctly determined to be hierarchical, and flatten_aux flattens the hier block in the example I provided (I can also successfully connect a debug_message() block residing within the hier_block2 to the message_prober). However, one QA test related to the hier block now fails, so this is probably not an ideal approach and I need to do some further digging to resolve this matter. Kind regards, Pieter Robyns 2015-09-27 19:09 GMT+02:00 Pieter ROBYNS <[email protected]>: > Dear all, > > While experimenting with hier_block2 I noticed that connecting an input > message port appears to disconnect an unrelated stream output port. I've > attached a simple example Python script to show what I mean. > > Basically, the example script creates a hier_block2 with a null source and > throttle block. The hier_block2 is then connected to a null sink. > Furthermore, it has an input message_port for control messages. The script > runs fine when the input message_port is not connected. However, when > connecting the message_port, the following error is returned: > > RuntimeError: hier_block_test(2): insufficient connected output ports (1 > needed, 0 connected) > > Am I missing something or might this be a bug? If I change the hier_block2 > to have 0 stream outputs (in the output signature), the error goes away, > but in my use case I need to have one stream output and one control message > input. > > > Kind regards, > Pieter Robyns > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
