Metadata-Version: 2.1
Name: larpix-daq
Version: 0.2.1
Summary: LArPix DAQ system
Home-page: UNKNOWN
Author: Sam Kohn, LBNL Neutrino Group
Author-email: skohn@lbl.gov
License: UNKNOWN
Keywords: dune larpix
Platform: UNKNOWN
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Science/Research
Classifier: Programming Language :: Python
Classifier: Topic :: Scientific/Engineering :: Physics
Classifier: Topic :: Scientific/Engineering
Description-Content-Type: text/markdown
Requires-Dist: xylem-daq (~=0.3.2)
Requires-Dist: flask (>=1.0.0)
Requires-Dist: flask-socketio (>=3.0)
Requires-Dist: eventlet (>=0.24)
Requires-Dist: requests (~=2.18)
Requires-Dist: larpix-control (~=2.3.0)

# larpix-daq

[![Documentation
Status](https://readthedocs.org/projects/larpix-daq/badge/?version=stable)](https://larpix-daq.readthedocs.io/en/stable/?badge=stable)

LArPix DAQ is the data acquisition system for LArPix. It handles the
data flow between the "data boards" and offline storage and includes
data monitoring and operator control functionality built on the xylem
DAQ framework.

LArPix DAQ consists of a set of scripts which are responsible for
individual parts of the DAQ system's functionality, as well as an
operator interface API which can be run in an interactive python session
or used as a basis for a more sophisticated interactive program. The
scripts can be run from the same or from different computers, as long as
the IP addresses of the various computers are known.


### System states

There are three states the system can be in: ``READY``, ``RUN``, and
``STOP``. The state is controlled through the ``Operator`` object using
the methods ``prepare_run`` (transition to ``READY``), ``begin_run``
(transition to ``START``), and ``end_run`` (transition to ``STOP``).

- ``STOP``: Default state on startup. All components are not expecting
  data.
- ``READY``: Components should prepare to receive data. Data may arrive
  at the component before the instruction to transition to the ``RUN``
  state (though this is expected to be rare). The component should treat
  that data as if it were received in the ``RUN`` state.
- ``RUN``: Components should expect to receive data. Data should not be
  produced in any other state.

To mark the start and end of a run in the data flow, the ``producer.py`` script
produces ``INFO`` messages with contents ``"Beginning run"`` and
``"Ending run"``, respectively.


## Operator

The LArPix DAQ Operator module provides the interface into the DAQ core
for all DAQ operations.

Operator methods interact with the DAQ core to accomplish the
desired behavior. For the simplest interactions, a single request
and response exchange occurs, and the result is returned.
(TODO!!! unify this interface) For most interactions, there are
multiple responses for a single request - e.g. an immediate
acknowledgement of receipt and then the eventual result. The
methods implementing these interactions return [generator
iterators](https://docs.python.org/3/glossary.html#term-generator)
rather than values. The way to call these functions usually looks like

```python
o = Operator()
final_responses = []
for response in o.run_routine('example'):
    print(response)
    # interact with response object within loop
# When the loop ends, the last response received is still saved in
# the response object
final_responses.append(response)
```


