Tim,
Glad to see that works for you. For me that ended up leaving things
in a bad state. The destructor (in C++) of one of my modules wasn't called
unless I set the flowgraph to None and then re-initialized it. I'll have
to give that a try for my case at some point.
-Dave
On Fri, Jul 8, 2016 at 4:17 PM, Tim Castiglia <cas...@rpi.edu> wrote:
> I found a workaround that's not so pretty, but it works. Setting the
> flowgraph to None does not work for me because it makes my other python
> threads that are running throw errors. The problem turns out is more of a
> low level hardware problem, or at least that's the case for when I use my
> specific hardware driver.
>
> The file descriptor my hardware was open on was closed, but an error
> occurred when restarting the flowgraph in closing and reopening the file
> descriptor. I cannot track down what exactly is causing the error, but
> instead of fixing it, I just took out the close(fileDescriptor) line in my
> code. This doesn't harm the system because the same file descriptor is use
> anyway when the flowgraph is restarted.
>
> I also realized that having a global flowgraph will be difficult to change
> within python, so I made a wrapper class that holds the flowgraph as a
> member variable, and made the class global instead. On top of this, when I
> restart the flowgraph, I change the wrappers flowgraph, and then set a
> member variable flowgraph in the socket class to be equal to the wrapper's
> flowgraph. This might be overkill, but it works.
>
> #I import that object into my server code
> import flowgraphInit from flowgraph
> #I can also import my other flowgraph
> import newFlowgraphConstructor from flowgraph2
>
> class wrapper():
> __init__(self):
> self.flowgraph = flowgraph
>
> #At global level
> flowgraph = flowgraphInit()
> flowgraph.start()
> wr = wrapper()
>
> class ClientSocketConnection
> __init__(self):
> self.flowgraph = wr.flowgraph
> #other functions
> def onMessage(payload):
> #Parse message
> #If we need to change to a different flowgraph
> wr.flowgraph.stop()
> wr.flowgraph.wait()
> time.sleep(5)
> self.resetFlowgraph()
>
> def resetFlowgraph(self):
> wr.flowgraph = newFlowgraphConstructor()
> wr.flowgraph.start()
> self.flowgraph = wr.flowgraph
>
> def main():
> #create socket factory so we can allow many connections
>
>
> On Fri, Jul 8, 2016 at 10:35 AM, Dave NotTelling <dmp250...@gmail.com>
> wrote:
>
>> Tim,
>>
>> One thing I have found with the Python stuff is that you need to set
>> the flow graph variable to None for resource to be released. moo =
>> myGraph(); moo.start(); time.sleep(10); moo.stop(); moo.wait(); moo = None;
>> moo = myGraph(); moo.start() .....
>>
>> -Dave
>>
>> On Thu, Jul 7, 2016 at 6:14 PM, Tim Castiglia <cas...@rpi.edu> wrote:
>>
>>> First I should give some context on my project. What we are trying to
>>> build is a python server that utilizes gnuradio's blocks to get information
>>> from hardware and send it outbound, as well as receiving requests from
>>> clients to the server about configuration of flowgraph. More specifically,
>>> right now, I have:
>>>
>>> Oscom Source -->Log Power FFT --> Vector Probe
>>>
>>> For simplicity, I am using the RTL-SDR for testing purposes. In the
>>> future, we will be using our own device driver created within the SoapySDR
>>> framework, hence why we are using the oscom block.
>>>
>>> The problem starts with the fact that this may not be the only flowgraph
>>> we utilize. The hardware we are using may start pumping out FFT values
>>> instead of IQ values. Which means we would need a flowgraph that looks more
>>> like:
>>>
>>> Oscom Source --> Vector Probe
>>> (Ignore the fact that this is not possible with the oscom block
>>> currently, we will cross that bridge in the future)
>>>
>>> So I need to be able to stop my current running flowgraph, and start a
>>> new one. This is where I run into trouble. I can stop my flowgraph
>>> perfectly fine with:
>>>
>>> flowgraph.stop()
>>> flowgraph.wait()
>>> time.sleep(5)
>>>
>>> But I would like to keep the variable the same in my python code even
>>> when I change the flowgraph. So I try:
>>>
>>> flowgraph = newFlowgraphConstructor()
>>>
>>> But this causes a python error at the flowgraph.stop() line: "variable
>>> mentioned before instantiated"
>>>
>>> To get around this, I made a resetFlowgraph function:
>>> def resetFlowgraph():
>>> flowgraph = newFlowgraphConstructor()
>>> flowgraph.start()
>>>
>>> and call things in this order:
>>> flowgraph.stop()
>>> flowgraph.wait()
>>> time.sleep(5)
>>> resetFlowgraph()
>>>
>>> The flowgraph starts successfully, but fails to "claim" the RTL-SDR from
>>> the old flowgraph. I have also tried the same with only my device plugged
>>> in, and a similar problem occurs. Is there a way to force the flowgraph to
>>> relinquish its hold on the hardware? Our python server code needs to
>>> continue running, so I need to be able to do this restart without ending
>>> the program (The idea is to have the server always be running and not be
>>> manned most of the time).
>>>
>>> Here's some pseudo code to give you an idea of how the code is
>>> structured:
>>>
>>> #First I have a premade object generated from gnuradio-companion
>>> #I import that object into my server code
>>> import flowgraphInit from flowgraph
>>> #I can also import my other flowgraph
>>> import newFlowgraphConstructor from flowgraph2
>>>
>>> #At global level
>>> flowgraph = flowgraphInit()
>>> flowgraph.start()
>>>
>>> class ClientSocketConnection
>>> ...#init and other functions
>>> def onMessage(payload):
>>> #Parse message
>>> #If we need to change to a different flowgraph
>>> flowgraph.stop()
>>> flowgraph.wait()
>>> time.sleep(5)
>>> resetFlowgraph()
>>>
>>> def resetFlowgraph():
>>> flowgraph = newFlowgraphConstructor()
>>> flowgraph.start()
>>>
>>> def main():
>>> #create socket factory so we can allow many connections
>>> #So there is only one flowgraph, but many people can see it and
>>> potentially change it
>>>
>>> (I have seen this question asked before here
>>> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-01/msg00411.html
>>> but there was no solution in the thread)
>>>
>>> Any help is appreciated!
>>>
>>> _______________________________________________
>>> 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
