Hi Steven,

thanks for the compliments, and yeah, I can fully understand it's
somewhat frustrating to not find the root cause of something, and I
surely would have enjoyed to reproduce the issue, but if you need to
move on, I can completely comprehend.

Thanks, and keep up the good work,

Marcus


On 01/13/2017 01:53 AM, Steven Knudsen wrote:
> Hi all,
>
> Getting stuck means you have to try something else…
>
> Marcus and i thought it can’t hurt to try and create from scratch a
> new message-only block and test it. 
>
> Long story short (and good news), that worked just fine. I even
> changed the new OOT message block to have ports with the same names as
> the offending block below — worked in GRC and in a unit test.
>
> The next obvious thing was to recreate my desired message-only block,
> tossing the old one into the bit bucket. Everything just worked.
>
> So, what could have been the problem? Not sure, especially since the
> original block worked flawlessly in GRC and never worked in the python
> unit test. 
>
> I hate “solutions” like this, but I suppose that if anyone ever sees
> something like this again, we can hope they see these posts and cut
> straight to making a clean block using gr_modtool.
>
> Time to move on!
>
> Thanks for your help, Marcus.
>
> steven
>
>> On Jan 12, 2017, at 09:11, Steven Knudsen <ee.k...@gmail.com
>> <mailto:ee.k...@gmail.com>> wrote:
>>
>> Thanks very much, Marcus, for the help.
>>
>> As requested, I used
>>
>>         self.tb.msg_connect((self.blocks_message_strobe_0,
>> pmt.string_to_symbol('strobe')), (self.jitc_random_sequenced_pdu_0,
>> pmt.string_to_symbol('generate')))
>>
>> Sadly, no change in that the “Could not find port” problem persists.
>>
>> To be sure, I also applied your suggestion with the gr-blocks
>> random_pdu block in the same source (much as I did below) and used
>>
>>         self.tb.msg_connect((self.blocks_message_strobe_0,
>> pmt.string_to_symbol('strobe')), (self.jitc_random_pdu_0,
>> pmt.string_to_symbol('generate')))
>>
>> which worked just fine.
>>
>> I’ll continue to compare the gr-blocks implementation with my OOT
>> module. I would still like to think there is a difference somewhere
>> in the source or a script or something, but I can’t see how that
>> would explain why my OOT works fine in GRC.
>>
>> Last, I did try to follow the logic/code that tracks the registered
>> ports starting with gnuradio-runtime/lib/flowgraph.cc
>> <http://flowgraph.cc/>, but I became a bit lost as things moved
>> through swig…
>>
>> BTW, my GR version is 3.7.10.1
>>
>> Again, thanks for your help!
>>
>> steven
>>
>>
>>> On Jan 12, 2017, at 03:39, Marcus Müller <marcus.muel...@ettus.com
>>> <mailto:marcus.muel...@ettus.com>> wrote:
>>>
>>> Hi Steven,
>>>
>>> On 12.01.2017 02:21, Steven Knudsen wrote:
>>>> You worry me with your “various ways” comment :-/
>>> That's what I do: I comment and worry people. And I just finished my
>>> comment.
>>> No, really, I was just surprised that a) it doesn't work and b) it
>>> claims "a is not in set {a,b}". That feels ever so slightly wrong.
>>>>
>>>> All I have done is extended the random_pdu from gr-blocks by
>>>> including a sequence number in the PDU. So, the constructor is
>>>> where the message ports are registered and is identical to the
>>>> random_pdu constructor. I’ve attached a snippet
>>>> (rsp_constructor.snippet) that contains my exact code.
>>> Thanks, OK the most relevant line here is
>>>
>>>       message_port_register_in(pmt::mp("generate"));
>>>
>>> which looks right; I really sense shenanigans here. So, to narrow
>>> this down:
>>>
>>> Can you do a
>>>
>>>         self.tb.msg_connect((self.blocks_message_strobe_0,
>>> pmt.string_to_symbol('strobe')), (self.jitc_random_sequenced_pdu_0,
>>> pmt.string_to_symbol('generate')))
>>>
>>> to rule out any strangenesses that the whole behind-the-scenery PMT
>>> conversion does?
>>>
>>> Best regards,
>>> Marcus
>>>
>>>>
>>>> My version works the same as the original when run from GRC. I’ve
>>>> attached a screencap of the simple flowgraph used to verify this.
>>>> I’ve also attached the generated python. 
>>>>
>>>> I took the main code from that generated python and added to my
>>>> unit test and modified only by changing ‘self’ to self.tb’. When I
>>>> run that code, I get the could not find port error. 
>>>>
>>>> If I modify that code to connect only the output of the Message
>>>> Strobe to the print port of the Message Debug, it works.
>>>>
>>>> That is, this does not work,
>>>>         self.tb.msg_connect((self.blocks_message_strobe_0,
>>>> 'strobe'), (self.jitc_random_sequenced_pdu_0, 'generate'))
>>>> #        self.tb.msg_connect((self.blocks_message_strobe_0,
>>>> 'strobe'), (self.blocks_message_debug_0, 'print'))
>>>>         self.tb.msg_connect((self.jitc_random_sequenced_pdu_0,
>>>> 'pdus'), (self.blocks_message_debug_0, 'print'))
>>>>
>>>>
>>>> But this does work
>>>>
>>>> #        self.tb.msg_connect((self.blocks_message_strobe_0,
>>>> 'strobe'), (self.jitc_random_sequenced_pdu_0, 'generate'))
>>>>         self.tb.msg_connect((self.blocks_message_strobe_0,
>>>> 'strobe'), (self.blocks_message_debug_0, 'print'))
>>>> #        self.tb.msg_connect((self.jitc_random_sequenced_pdu_0,
>>>> 'pdus'), (self.blocks_message_debug_0, 'print'))
>>>>
>>>> Last observation is that if I replace my random_sequenced_pdu with
>>>> block’s random_pdu,it all works. So, it’s definitely something with
>>>> my module. Is something not generated via/by swig maybe? I tried
>>>> digging into gr-blocks to look for differences, but so far none
>>>> that I can see.
>>>>
>>>> Sorry this is kind of long, but it’s a weird problem, weird because
>>>> my stuff works fine in GRC!?!
>>>>
>>>> regards, and thanks,
>>>>
>>>> steven
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From*:   Marcus Müller
>>>>> *Subject*:        Re: [Discuss-gnuradio] Python Unit Test with message
>>>>> ports - "Could not find port"
>>>>> *Date*:   Wed, 11 Jan 2017 14:49:40 +0100
>>>>> *User-agent*:     Mozilla/5.0 (X11; Linux x86_64; rv:45.0)
>>>>> Gecko/20100101 Thunderbird/45.2.0
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> Hi Steven, 
>>>>>
>>>>> that's strange indeed. In various ways. 
>>>>>
>>>>> Could you tell us:
>>>>>
>>>>> 1. where do you register the message port? Could you copy&paste
>>>>> that exact line?
>>>>> 2. could you copy&paste both message_connect lines from the
>>>>> GRC-generated and your unit test python?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Marcus
>>>>>
>>>>> On 01/11/2017 01:35 AM, Steven Knudsen wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I am trying to write a unit test for a message-only block, let’s
>>>>>> call it “foo”, that has an input message port “generate". When I
>>>>>> use the block in GRC, everything is fine. I can connect its
>>>>>> message ports to standard GNU Radio message blocks, like
>>>>>> message_strobe and message_debug with no problems.
>>>>>>
>>>>>> However, when I try and do the same in a Python unit test, I get
>>>>>> the message
>>>>>>
>>>>>> Could not find port: generate in:
>>>>>> generate
>>>>>> system
>>>>>>
>>>>>> If, for example, in the same unit test I connect the
>>>>>> message_strobe with message_debug, all is well.
>>>>>>
>>>>>> If I then connect message_strobe to foo, I get the error above.
>>>>>>
>>>>>> I double checked that the message port declarations are the same
>>>>>> as you find in a block like message_strobe. 
>>>>>>
>>>>>> I double checked the syntax of msg_connect, making sure it looks
>>>>>> exactly the same as it does in the GRC generated Python file.
>>>>>>
>>>>>> Anyone seen this recently? I have found some references by
>>>>>> searching online, but nothing that has helped.
>>>>>>
>>>>>> Thanks very much!
>>>>>>
>>>>>> steven
>>>>>
>>>>
>>>
>>
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to