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