AD2 ready state recovery

[Torfey]

Working on Debian 8.6 in python 2.7, trying to figure out what the 'ready' state of the AD2 means and how I can get back to running mode.

We configure the AD2 to run continuously, collecting multiple subtraces and combining them into a larger trace. The system happily runs, sometimes for hours or days, reporting states of 'arm', 'triggered', and 'done' repeatedly. But at some point with an unknown-to-me cause, it flips to a 'ready' state and our data collection stops. I don't know what FDwf python command to issue to get it back to triggering and taking data.  As it is, I close and delete the python AnalogDiscovery object and create a new object, thus re-initializing our AD2 connection. But my guess is that I shouldn't have to do this to start up again.

Can someone tell me to proper way to get back to taking data after getting bumped out to 'ready' state?

Thanks.

[attila]

Hello,

The AnalogIn state changes to Ready after any FDwfAnalogIn#Set or FDwfAnalogInReset or FDwfAnalogInConfigure without start (=false).
To start acquisition call FDwfAnalogInConfigure with start (=true) argument.

In case you are not calling the earlier mentioned functions I'm not sure why are you getting to Ready state.
You could check the return value of functions to see if something went wrong, like communication error due to device disconnect...

if dwf.FDwfAnalogInConfigure(hdwf, c_int(0), c_int(1)) != 1 :
# or 
if dwf.FDwfAnalogInStatus(hdwf, c_int(1), byref(sts)) != 1 :
    print "ERROR:"
    szerr = create_string_buffer(512)
    dwf.FDwfGetLastErrorMsg(szerr)
    print szerr.value

[Torfey]

Thank you.  I hadn't seen in the docs that the return value of FDwfAnalogInConfigure was testable, so thanks for suggesting that.

We call FDwfAnalogInConfigure with start=true, then loop on FDwfAnalogInStatus, waiting for 'done' state, but with a timeout of 2s (our external trigger runs at ~10 Hz). Code is modeled on samples/py/AnalogIn_Acquisition.py.

In this loop is when I normally see the 'armed', 'triggered', and finally 'done'. When we have trouble, the system goes to 'ready' and stays there until it hits my 2s timeout . 

I've just now added a test of FDwfAnalogInConfigure's return value before I enter my loop, but in a short test, it appears the return value must equal 1, because I'm not getting the extra log messages I added if the 'return_value != 1'.

So even though we're triggering 10x a second, we're not going to 'armed', etc, within my 2 second timeout window. Sometimes.

Fwiw, over a 5 day test, average time till getting stuck on 'ready' was 40min. Shortest was 10s. Longest 4h. Not sure if it's related to load on the system causing usb timeouts. But the load is only background linux, x-windows, and drawing results of this data collection to screen on an Intel NUC i5.