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 <david.ha...@toshiba-trel.com> 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=toshiba-trel....@gnu.org > [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org] *On > Behalf Of *Nemanja Savic > *Sent:* 05 November 2015 12:20 > *To:* Marcus Müller <marcus.muel...@ettus.com> > *Cc:* GNURadio Discussion List <discuss-gnuradio@gnu.org> > *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 <marcus.muel...@ettus.com> > 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 <marcus.muel...@ettus.com> > 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 <marcus.muel...@ettus.com> > 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 <marcus.muel...@ettus.com> > 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 > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > 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ć
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
