Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[Nemanja Savic]

Hello,

I didn't deal with this since my post, still use good ol' 3.6.5.1, but I will try what u have suggested. Maybe my module was not built correctly.

Nemanja

On Mon, Nov 30, 2015 at 11:31 PM, David Halls <address@hidden> wrote:

Hi Nemanja, Marcus,

 

Did you get anywhere with this issue?

 

We have an equivalent problem that sprung up with one of our flow graphs, seemingly randomly. We’re not sure what changed…! We then found that *any* of our blocks that used MSG input or output ports gave equivalent errors when in even the simplest of flowgraphs. The same does not happen with GR blocks.

 

By rebuilding our whole out of tree module, the problem seems to have gone away. For now. Strange…

 

Also strange is when I click ‘reload blocks’, all MSG connection arrows are deleted and have to be redrawn.

 

Regards,

 

David

 

From: discuss-gnuradio-bounces+david.halls=address@hidden [mailto:discuss-gnuradio-bounces+david.halls=address@hidden] On Behalf Of Nemanja Savic
Sent: 05 November 2015 12:20
To: Marcus Müller <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

 

Hi,

here is a simple photo representing my block. The block is hierarchical and consists of a few deframers. When deframers decode correct message, they are supposed to send message to db_logger who write information from the message into a database. Deframers are written in c++ while db_logger is written in python. All deframers have output port whose name is hardcoded to "out_port", while db_logger has input port whose name was hardcoded as "in_port"

In previous case, self is db_logger. I have shown there how the message port inside that block was defined.

Inside hier block where everything is packed I have lines like this
self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger, in_port)

here self references hier block.

Cheers,

Nemanja

 

On Wed, Nov 4, 2015 at 10:49 PM, Marcus Müller <address@hidden> wrote:

I've lost oversight.. is self a hier block, in this case?

 

On 11/04/2015 06:49 PM, Nemanja Savic wrote:

So, a block called db_logger is written in python and port is defined in following way:
self.message_port_register_in(pmt.pmt_intern(in_port))

Well, I am not sure, this works fine in older version.

 

On Wed, Nov 4, 2015 at 6:41 PM, Marcus Müller <address@hidden> wrote:

What does your message_port_register_in call look like?
Or is it a message_port_register_hier_in call? (should it be?)

Cheers,
Marcus

 

On 11/04/2015 06:37 PM, Nemanja Savic wrote:

Hi,

ok thanks. Does it matter how I everything is declared, but it is clear that something changed since 3.6.5.1.

So i have hier block written in python where i define

in_port = 'in_port'

out_port='out_port'

These arguments are passed in the following way:

in_port is receiving port of a block that receives messages from blocks which have registered out_block as their transmitting port.

out_port is passed to constructors of all transmitting blocks. They are passed as type const char*. Blocks have member d_msg_out_port defined as string. So something like this:
d_msg_out_port(msg_out_port)
...

body of constructor:
message_port_register_out(pmt::mp(d_msg_out_port));

So, later on, at the end of hier block I call:
self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger, in_port)

Could it be that problem is something with strings (I am not sure is null character is passed, no idea)?

Nemanja

 

On Wed, Nov 4, 2015 at 6:26 PM, Marcus Müller <address@hidden> wrote:

Hi,

not really, what it says is really "I can't find <element> in <list of elements>", with that list being the names of the registered ports.
So, the interesting thing is that seemingly,comparin pmt::symbol("in_port") with pmt::symbol("in_port") doesn't quite work well.

I'd have to look into what pmt::comparator looks like; it's my first suspect for why that might fail.

Best regards,
Marcus

On 11/04/2015 06:20 PM, Nemanja Savic wrote:

Hi,

hm, could just tell me if I am thinking wrong, but this looks like some of my blocks is also called in_port?

Nemanja

 

On Wed, Nov 4, 2015 at 6:14 PM, Marcus Müller <address@hidden> wrote:

Hi Nemanja,

a blind suspicion: as "system" is a port that should be registered by the runtime for each block, there might be some confusion happening.
Does it work better when you rename your block to something else?

Best regards,
Marcus

 

On 11/04/2015 06:05 PM, Nemanja Savic wrote:

Hi all guys,

I recently installed 3.7.8, and before that I had 3.6.5.1.

I was using message passing in some of my blocks, but now I get error which is following:

Could not find port: in_port in:
in_port
system

Traceback (most recent call last):
  File "./top_block.py", line 178, in <module>
    tb = top_block()
  File "./top_block.py", line 124, in __init__
    self.TPMS_univ_TPMS_rec2_0 = TPMS.univ_TPMS_rec2("WBX_proba", samp_rate, 0.5, 45, "localhost", 2, "TEST_TRACK_TPMS", "nemanja", "nemanja", "det_id_proba", "detectors")
  File "/scr1/nemanja/install/lib64/python2.6/site-packages/TPMS/univ_TPMS_rec2.py", line 145, in __init__
    self.msg_connect(self.SEL_90518407_pkt_def.SCHRADER_def, out_port, self.db_logger, in_port)
  File "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py", line 59, in wrapped
    func(self, src.to_basic_block(), srcport, dst.to_basic_block(), dstport)
  File "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/hier_block2.py", line 131, in msg_connect
    self.primitive_msg_connect(*args)
  File "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/gr/runtime_swig.py", line 3043, in primitive_msg_connect
    return _runtime_swig.hier_block2_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

 

I see that there is a function for checking whether the ports are valid, but don't get what's wrong with my ports. Namely, I have hier block and a few blocks are sending messages to a single blocks where the messages are decoded and written to darabase. I tried to hardcode names of the blocks and that also didn't help.

Thanx,

--

Nemanja Savić

 

_______________________________________________

Discuss-gnuradio mailing list

address@hidden

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

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

--

Nemanja Savić

 

--

Nemanja Savić

 

--

Nemanja Savić

 

--

Nemanja Savić

---

NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl

---

This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com

---

--

Nemanja Savić