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