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
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, 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
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
|
|