Dear Marcus, So, I'm very unfamiliar with what *message connections* are so we'll go with a no. I'll describe exactly what I've done and perhaps we can workout where I've gone wrong.
I have constructed a flowgraph which contains 5 blocks total. Two of them are custom ones I've managed to hack together. 1) Options block (default) 2) Variable block (default) 3) An OOT UDP Broadcast block written in Python. No inputs or outputs. This block has been written to send out a UDP packet to a piece of hardware. This block does exactly what I want it to do and does every inside of the *__init__* method. It simply utilises the *socket* library and sends a packet using .sendto(MESSAGE, (UDP_IP, UDP_PORT)). I'm quite new to UDP programming work so I wonder if the fact I haven't closed the socket is a problem. Another issue I'm starting to wonder is that I removed this block's inputs and outputs from the XML, but haven't changed anything in the python code. the *general_work* method still takes *(self, input_items, output_items). *Is there a name for blocks which have no inputs / outputs? This could be an issue. 4) An OOT UDP Server block written in Python. One output This block was made with gr_modtool as a source. The purpose of this block is to read incoming packets and kill the flowgraph upon receiving a "stop" command. In the *__init__* method,* .bind((UDP_IP, UDP_PORT))* is called, setting up the server. The *work *method gets blocked as the block waits for an incoming packet with the *.recvfrom* method (but I don't think this should be an issue). I finally have an *if* statement which returns *-1* should "stop" be received. 5) A null sink. I suppose this could be anything. Hopefully this reply isn't an incoherent mess and you understand what I'm trying to accomplish. Having written this, I am wondering if the fact that my UDP Broadcast block still wants to take input and output, but isn't is the issue. Many thanks David On Mon, Dec 19, 2016 at 5:34 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hey David, > > no, more bleeding edge than 3.7.10.1 wouldn't sound recommendable. > > At the moment, I don't have much idea what could be wrong with your > UDP-based source. What else is in the flow graph, or is it just the null > sink? Any message connections? > > Best regards, > > Marcus > > On 19.12.2016 16:59, David Kersh wrote: > > Dear Marcus, > > Excellent news! > > I've just installed 3.7.10.1 and my flow graph still doesn't appear to end > (but my UDP server block stops because it won't receive anymore packets > after returning -1). Currently I have a basic flowgraph which has my server > block running alongside a symbol noise source and frequency visualisation > sink. > > Do you recommend using one of the bleeding edge releases? > > Many Thanks > David > > On Mon, Dec 19, 2016 at 1:08 PM, Marcus Müller <marcus.muel...@ettus.com> > wrote: > >> Hi David, >> >> that worked :) >> >> yep, returning -1 (which is the magical value for "there's nothing coming >> anymore, you can shut down") would normally end a flow graph. >> >> However, we've had (still have) problems with the shutdown logic, but >> people recently patched a lot of things – so whatever you do, please make >> sure you're using the current release of GNU Radio. Which is it that you're >> currently using? >> >> Best regards, >> >> Marcus >> >> On 19.12.2016 12:45, David Kersh wrote: >> >> Hello all, >> >> I've created a custom out of tree source block which listens for UDP >> packets and does different things depending on the received packet. It is >> connected to a NULL sink because I haven't quite worked out how to make a >> standalone UDP Server (and I've found the tutorials to be very confusing >> unfortunately). >> >> When the packet is "stop", I would like the flowgraph to be stopped. I've >> seen from researching different forums that if *-1* is returned, the >> flowgraph is supposed to stop but I only find that this stops my block from >> running, the rest of the flowgraph continues running. >> >> Is there not a simple command which I can use to kill the whole >> flowgraph? >> >> An alternative solution I tried to implement was to access these values >> using a *vector sink* block and the .data() method from the top_block.py >> This didn't seem to work correctly as Python's UDP calls block. >> >> Thank you, hopefully I've made this post properly. I'm quite new to >> programming with GNURADIO. >> >> David >> >> >> _______________________________________________ >> Discuss-gnuradio mailing >> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> _______________________________________________ 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
