Acquisition modules have 2 modes of operation: the synchronous (or blocking) mode, and the asynchronous (or non-blocking mode). The curves displayed in the graphical user interface are based on the asynchronous operation.
The working principle in synchronous mode is the following:
setup(**kwds): kwds can be used to specify new attribute values (otherwise, the current values are used)
(optional) curve_ready(): returns True if the acquisition is finished, False otherwise.
curve(timeout=None): returns a curve (numpy arrays). The function only returns when the acquisition is done, or a timeout occurs. The parameter timeout (only available for scope and specan) has the following meaning:
timeout>0: timeout value in seconds
timeout<=0: returns immediately the current buffer without checking for trigger status.
timeout is None: timeout is auto-set to twice the normal curve duration
No support for averaging, or saving of curves is provided in synchronous mode
The asynchronous mode is supported by a sub-object “run” of the module. When an asynchronous acquisition is running and the widget is visible, the current averaged data are automatically displayed. Also, the run object provides a function save_curve to store the current averaged curve on the hard-drive.
The full API of the “run” object is the following.
—> I also wonder if we really want to keep the running_state/running_continuous property (will be uniformized) inside the _setup_attribute. Big advantage: no risk of loading a state with a continuous acquisition running without noticing/big disadvantage: slaving/restoring a running module would also stop it...