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: [email protected] [mailto:[email protected]] On Behalf Of Nemanja Savic Sent: 05 November 2015 12:20 To: Marcus Müller <[email protected]> Cc: GNURadio Discussion List <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected]<mailto:[email protected]> 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 ---------------------------------------------------------------------------------------
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
