Hi David, well, the -1 (WORK_DONE) has to propagate through the flow graph; in other words, there must be a stream path between the block that says "I can't / won't do any more", and the rest of the flow graph. Again, sharing the flow graphs you use for easy reproduction of the problem would be a necessary step. I think I've explained that extensively enough. No matter how interesting your problem is, we're neither sitting in front of your PC nor in your head, so you must not only vaguely explain what you're doing, but actually make the problem 100% understandable for us. Right now, I'm wondering what your flow graphs look like, and that's the same feeling that I had for 8 of the 9 emails you sent to this list, not including the few you've sent privately to me only.
Best regards, Marcus On 06.01.2017 13:03, David Kersh wrote: > Hi Marcus, > > I've definitely found that the QT Gui doesn't die once I've returned > -1. I tried this with a Noise generator -> QT Frequency sink, for example. > > Today I tried using my code (without a GUI) with a simple flowgraph > which only has a UHD: USRP Source -> FILE SINK blocks and it continued > to write to a file even when my ServerSource block returned -1 (!) > > So I actually feel like I'm back where I started. I never expected it > to be /this/ difficult to get GNURadio to stop remotely. > > Apologies if I'm missing something frustratingly simple. The help has > been much appreciated. You have my code now so I imagine you can > verify that my serverSource block doesn't stop other blocks (and thus, > doesn't stop the flowgraph from running). > > David > > On Wed, Jan 4, 2017 at 1:43 PM, Marcus Müller > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: > > Well, don't have that buffer in the first place, then. Instead, > write a block with no stream in- and no stream outputs, and have > it emit a "stop" message to the "system" message port of any > existing block within your flow graph, e.g. the vector sink. > > The QT Gui should die by itself once you use any graphical sink > within a flow graph, if I remember correctly. > > Best regards, > > Marcus > > > On 01/04/2017 02:40 PM, David Kersh wrote: >> Ah! Thank you so much Marcus! I've managed to transplant this >> correction into my bigger flow graph and now everything works as >> intended. >> >> >You're using a hard-coded port of 58 in your server. That >> probably means you're running GNU Radio as root (because >> classically, normal users can't bind to sockets <1024). I changed >> that to 1200. >> >> Yes, that isn't a coincidence but I did not know that users >> cannot bind to ports <1024 without root. I'll play with that. >> >> > I know this is just an example, but to point this out now: your >> server source should return the number of items you produced. >> Right now, you always fill as much buffer as there is, but you >> probably want to receive your UDP packet into a buffer that's >> stored within your class, then copy as much content of the UDP >> packet as fits into the output buffer `out`, and return the >> number of floats you've copied. Notice that UDP transports bytes, >> but you produce 4-Byte-floats – make sure you keep at 4B >> boundaries when copying. If there's less space in the output >> buffer than you've received via UDP (yes, that can and will >> happen), you need to store the remainder of that UDP data for the >> next call to work(). Only if that "leftover buffer" is empty you >> should do a `recvfrom` to re-fill that buffer. >> >> Yeah I'm pretty confused with how this works to be honest. The >> serverSource block is literally just to parse a "stop" command, >> otherwise it should remain dormant, listening for that packet. >> How would I go about stopping it from writing to the buffer? It's >> just wasted processing. >> >> > The way you're writing your broadcaster seems to be OK. >> >> Excellent :) >> >> > If you're writing a network application from scratch, I'd >> recommend you look into using the ZMQ blocks – ZeroMQ is like >> sockets done right :) The architecture you'd aim for is a "ZMQ * >> Message Source" (with * being something like SUB or PULL, >> see zeromq.org <http://zeromq.org/> for a tutorial on these types >> of sockets), which gives you one GNU Radio message per packet you >> receive. You could then have multiple of these sockets - one for >> control ("ZMQ * Message Source"), one for stream data ("ZMQ * >> Source"). The ZMQ blocks have the advantage of being able to pass >> tags, if you happen to connect two remote flow graphs! And: ZMQ >> takes care of things like flow control, even in a >> multi-producer/single-consumer kind of network architecture, so >> your GNU Radio flow graph could "slow down" whoever is sending >> samples in case things get congested in GNU Radio due to high load. >> >> I'll definitely investigate this - thank you. >> >> I suppose a final question is, how do I kill the QtGUI thread if >> I do want a GUI? >> >> Many thanks, >> David >> >> On Wed, Jan 4, 2017 at 12:54 PM, Marcus Müller >> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: >> >> Dear David, >> >> using your gr-research OOT, I was able to notice the following: >> >> It shuts down just fine! >> >> A few notes: >> >> * You're using the Qt GUI build mode, which gives you a GUI >> window. That GUI thread then lingers. As soon as you change >> your build mode to "No GUI"/"Run To Completion" in the >> options block, it just works as expected for me >> >> * You're using a hard-coded port of 58 in your server. That >> probably means you're running GNU Radio as root (because >> classically, normal users can't bind to sockets <1024). I >> changed that to 1200. >> >> * Your example grc sends the message "STOP", but you check >> for "stop"... so that doesn't really work. >> >> * I know this is just an example, but to point this out now: >> your server source should return the number of items you >> produced. Right now, you always fill as much buffer as there >> is, but you probably want to receive your UDP packet into a >> buffer that's stored within your class, then copy as much >> content of the UDP packet as fits into the output buffer >> `out`, and return the number of floats you've copied. Notice >> that UDP transports bytes, but you produce 4-Byte-floats – >> make sure you keep at 4B boundaries when copying. If there's >> less space in the output buffer than you've received via UDP >> (yes, that can and will happen), you need to store the >> remainder of that UDP data for the next call to work(). Only >> if that "leftover buffer" is empty you should do a `recvfrom` >> to re-fill that buffer. >> >> * The way you're writing your broadcaster seems to be OK. >> >> * If you're writing a network application from scratch, I'd >> recommend you look into using the ZMQ blocks – ZeroMQ is like >> sockets done right :) The architecture you'd aim for is a >> "ZMQ * Message Source" (with * being something like SUB or >> PULL, see zeromq.org <http://zeromq.org> for a tutorial on >> these types of sockets), which gives you one GNU Radio >> message per packet you receive. You could then have multiple >> of these sockets - one for control ("ZMQ * Message Source"), >> one for stream data ("ZMQ * Source"). The ZMQ blocks have the >> advantage of being able to pass tags, if you happen to >> connect two remote flow graphs! And: ZMQ takes care of things >> like flow control, even in a multi-producer/single-consumer >> kind of network architecture, so your GNU Radio flow graph >> could "slow down" whoever is sending samples in case things >> get congested in GNU Radio due to high load. >> >> * Nabble really seems to be making it hard for you to answer >> on-list. Please simply abandon Nabble, it bears no advantage >> whatsoever. You use a GMail account – it's really easy to use >> that to directly subscribe to the mailing list via >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> and >> GMail has excellent "filter emails like this" functionality >> that allows you to automatically skip your inbox for mailing >> list emails that aren't directly part of discussion that >> involve you and add a mailing list tag. >> >> Best regards, >> >> Marcus >> >> On 01/04/2017 12:03 PM, David Kersh wrote: >>> Okay, these are what you want. >>> >>> dkblocks has the udpBroadcast block >>> research (as in, me messing about) has the udpServer block >>> >>> Thanks again >>> David >>> >>> On Wed, Jan 4, 2017 at 10:51 AM, Marcus Müller >>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> >>> wrote: >>> >>> The whole directory "gr-davidsmodulename" >>> >>> >>> On 04.01.2017 11:45, David Kersh wrote: >>>> Hi Marcus, >>>> >>>> I made these using the gr_modtool. >>>> >>>> I don't know what the "whole module" refers to. You can >>>> generate the exact same directory as me by using the >>>> gr_modtool I think. >>>> >>>> Even if you get my flowgraph running however, you'll >>>> need some software to send a "stop" packet to the >>>> computer so the flowgraph will attempt to stop. I have >>>> some hardware in place which does this for me. >>>> >>>> Apologies for the incomplete set of files. >>>> >>>> Thank you >>>> David >>>> >>>> On Wed, Jan 4, 2017 at 10:40 AM, Marcus Müller >>>> <marcus.muel...@ettus.com >>>> <mailto:marcus.muel...@ettus.com>> wrote: >>>> >>>> Hi David, >>>> >>>> did you write these blocks "free-standing" or >>>> generated them from with in an OOT with gr_modtool? >>>> >>>> Really, I want to locally reproduce your problem, >>>> but I'm not overly eager to first manually fiddle >>>> your xml files into my system, place the python >>>> files in a directory where python looks for them, >>>> then note down what I'd have to clean up later, >>>> just to be able to run your example. That's why I >>>> asked for the *whole* module. >>>> >>>> Best regards, >>>> Marcus >>>> >>>> >>>> On 04.01.2017 11:28, David Kersh wrote: >>>>> Hi Marcus, >>>>> >>>>> I've attached the python source for the two blocks >>>>> I made, their respective .xml files, the .grc file >>>>> for the flow graph, and the top_block.py >>>>> >>>>> Many thanks, >>>>> David >>>>> >>>>> On Wed, Jan 4, 2017 at 10:19 AM, Marcus Müller >>>>> <marcus.muel...@ettus.com >>>>> <mailto:marcus.muel...@ettus.com>> wrote: >>>>> >>>>> Can you really share your whole Out-Of-Tree >>>>> module including an example .grc or python >>>>> flow graph? >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Marcus >>>>> >>>>> >>>>> On 04.01.2017 10:53, David Kersh wrote: >>>>>> Hi Marcus, >>>>>> >>>>>> The 'stop' comparison definitely triggers as >>>>>> the appropriate text is printed to the GRC >>>>>> console. >>>>>> >>>>>> I think you're right about my UDP >>>>>> broadcaster. I want it to be one of those >>>>>> types of blocks similar to the two default >>>>>> blocks in a flowgraph: /Options /and >>>>>> /Variable/. I think the way I've created it >>>>>> is wrong as I essentially just removed the >>>>>> input and output terminals in the .xml file >>>>>> and added arguments for IP address, port and >>>>>> message packet. So actually I plan /not/ to >>>>>> use the inputs and outputs later on, I just >>>>>> don't really know what I'm doing / don't know >>>>>> how to remove the input / output related code >>>>>> from the python file. >>>>>> >>>>>> Apart, from the two blocks I mentioned >>>>>> earlier and the Options and Variable blocks, >>>>>> the serverSource blocks outputs to the >>>>>> pre-defined Vector Sink block. >>>>>> >>>>>> Thank you >>>>>> David >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 4, 2017 at 12:34 AM, Marcus >>>>>> Müller <marcus.muel...@ettus.com >>>>>> <mailto:marcus.muel...@ettus.com>> wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> are you sure the 'stop' comparison ever >>>>>> triggers? >>>>>> >>>>>> I'm not quite sure your UDP broadcaster >>>>>> /should/ be a GNU Radio block – >>>>>> it doesn't have any in- or outputs (but I >>>>>> presume you plan to add these >>>>>> later on). >>>>>> >>>>>> What's the whole Flow graph you're using? >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Marcus >>>>>> >>>>>> On 03.01.2017 09:53, davidk wrote: >>>>>> > Dear Marcus, Happy new year! >>>>>> > >>>>>> > Here is my UDP Server Block Python Code: >>>>>> > >>>>>> > /import numpy >>>>>> > import socket >>>>>> > from gnuradio import gr >>>>>> > from gnuradio import blocks >>>>>> > >>>>>> > UDP_IP = "192.168.10.2" >>>>>> > UDP_PORT = 58 >>>>>> > >>>>>> > sock = socket.socket(socket.AF_INET, >>>>>> socket.SOCK_DGRAM) >>>>>> > >>>>>> > class serverSource(gr.sync_block): >>>>>> > def __init__(self): >>>>>> > >>>>>> > >>>>>> >>>>>> gr.sync_block.__init__(self,name="serverSource",in_sig=None,out_sig=[numpy.float32]) >>>>>> > print "Setting up server" >>>>>> > sock.bind((UDP_IP, UDP_PORT)) >>>>>> > >>>>>> > def work(self, input_items, >>>>>> output_items): >>>>>> > out = output_items[0] >>>>>> > data, addr = sock.recvfrom(1024) >>>>>> > packetString = repr(data) >>>>>> > >>>>>> > packetString = >>>>>> packetString.replace('\\x00','') >>>>>> > packetString = >>>>>> packetString.replace('\'','') >>>>>> > >>>>>> > print "message received: ", >>>>>> packetString >>>>>> > print "address: ", addr >>>>>> > >>>>>> > if packetString == 'stop': >>>>>> > return -1 >>>>>> > >>>>>> > return len(output_items[0])/ >>>>>> > >>>>>> > and here is my UDP Broadcast block: >>>>>> > >>>>>> > /import numpy >>>>>> > import socket >>>>>> > from gnuradio import gr >>>>>> > >>>>>> > class udpBroadcast(gr.basic_block): >>>>>> > def __init__(self, ip, port, message): >>>>>> > >>>>>> > >>>>>> >>>>>> gr.basic_block.__init__(self,name="udpBroadcast",in_sig=[numpy.float32],out_sig=[numpy.float32]) >>>>>> > print "Setting up UDP Message" >>>>>> > >>>>>> > UDP_IP = ip >>>>>> > UDP_PORT = port >>>>>> > MESSAGE = message >>>>>> > >>>>>> > sock = >>>>>> socket.socket(socket.AF_INET, >>>>>> socket.SOCK_DGRAM) >>>>>> > sock.sendto(MESSAGE, (UDP_IP, >>>>>> UDP_PORT))/ >>>>>> > >>>>>> > Hopefully you can make out what I'm >>>>>> aiming for here. >>>>>> > >>>>>> > Many thanks >>>>>> > David >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > View this message in context: >>>>>> >>>>>> http://gnuradio.4.n7.nabble.com/How-to-kill-flowgraph-with-a-custom-block-tp62332p62402.html >>>>>> >>>>>> <http://gnuradio.4.n7.nabble.com/How-to-kill-flowgraph-with-a-custom-block-tp62332p62402.html> >>>>>> > Sent from the GnuRadio mailing list >>>>>> archive at Nabble.com. >>>>>> > >>>>>> > >>>>>> _______________________________________________ >>>>>> > Discuss-gnuradio mailing list >>>>>> > Discuss-gnuradio@gnu.org >>>>>> <mailto:Discuss-gnuradio@gnu.org> >>>>>> > >>>>>> >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
