Re: single pad sink hier block fails but similar two output block works

The two flow graphs of two hier blocks in the attached screen captures
appear functionally identical to me. They were both generated and copied
to ~/.grc_gnuradio / .  The block in null_hier.pdf works but the other
does not (same main flow graph in both cases).  Are there any
suggestions out there on what could cause this?


On 2024-11-29 17:22, aardric via "GNU Radio, the Free & Open-Source
Toolkit for Software Radio" wrote:
> My hier block runs if I add a second output pad connected to a null source:
>
>         gr.hier_block2.__init__(
>             self, "null output hier",
>                 gr.io_signature(0, 0, 0),
>                 gr.io_signature.makev(2, 2, [gr.sizeof_float*1,
> gr.sizeof_float*1]),
>         )
>
>
> However, the single output pad:
>
>         gr.hier_block2.__init__(
>             self, "Hx_code_source",
>                 gr.io_signature(0, 0, 0),
>                 gr.io_signature(1, 1, gr.sizeof_float*1),
>         )
>
>
> generates an error:
>
> ine 125, in __init__
>     self.HxCodes_0 = HxCodes(
>                      ^^^^^^^^
> TypeError: HxCodes.__init__() got an unexpected keyword argument
> 'HxCode_file'
>
> >>> Done (return code 1)
>
>
> Other than the second null output, these two hier blocks are identical.
> I assume that a single output hier block allowed so is there an obvious
> explanation for this?
>
>
> Rick
>
>
> On 2024-11-29 15:47, Rick Smegal wrote:
>> I may have created my own problems by editing and saving the file under
>> a new name. I created the hier block flow graph from a blank slate
>> following the tutorial step by step and now have a completely different
>> problem which appears to be the result of something stupid, like a typo
>> in a parameter box.  I'll work on this and update this thread with
>> either the solution or a real issue.
>>
>>
>> Rick
>>
>>
>> On 2024-11-29 11:27, aardric via "GNU Radio, the Free & Open-Source
>> Toolkit for Software Radio" wrote:
>>> Version: 3.10.11.0-1
>>>
>>> I have a simple hier block with two output pad sinks that works as
>>> expected. These two outputs are nearly identical but independent
>>> streams. I created a very similar hier block with only a single stream
>>> and one output pad sink.  Executing a flow graph containing the latter
>>> hier block generates the error:
>>>
>>> ".local/lib64/python3.11/site-packages/gnuradio/gr/hier_block2.py", line
>>> 126, in connect
>>>     self.primitive_connect(*args)
>>> ValueError: port number 0 exceeds max of (none)
>>>
>>> The offending line 126:
>>>
>>>     def connect(self, *args):
>>>         """
>>>         Connect two or more block endpoints.  An endpoint is either a
>>> (block, port)
>>>         tuple or a block instance.  In the latter case, the port number
>>> is assumed
>>>         to be zero.
>>>
>>>         To connect the hierarchical block external inputs or outputs to
>>> internal block
>>>         inputs or outputs, use 'self' in the connect call.
>>>
>>>         If multiple arguments are provided, connect will attempt to
>>> wire them in series,
>>>         interpreting the endpoints as inputs or outputs as appropriate.
>>>         """
>>>         self.primitive_connect(*args)
>>>
>>>
>>> Working two output block init:
>>>
>>>     def __init__(self, E6bCode_file='0', E6cCode_file='0'):
>>>         gr.hier_block2.__init__(
>>>             self, "E6bc_code_source",
>>>                 gr.io_signature(0, 0, 0),
>>>                 gr.io_signature.makev(2, 2, [gr.sizeof_float*1,
>>> gr.sizeof_float*1]),
>>>         )
>>>
>>>
>>> errant single output block init:
>>>
>>>     def __init__(self, HxCode_file='0'):
>>>         gr.hier_block2.__init__(
>>>             self, "Hx_code_source",
>>>                 gr.io_signature(0, 0, 0),
>>>                 gr.io_signature(1, 1, gr.sizeof_float*1),
>>>         )
>>>
>>>
>>> Is there a place I should look for the root of the problem? I am
>>> struggling to understand this. I thought to ask now in anticipation of
>>> still struggling at the end of the day.
>>>
>>>
>>> Rick
>>>
>>>
>>>
>>>
>