srenblad
/
artiq
forked from M-Labs/artiq
1
0
Fork 0
Code Pull Requests Activity

Scheduler documentation: interaction between experiments (#1320)

This commit is contained in:
Marius Weber 2019-05-14 13:38:54 +01:00 committed by Sébastien Bourdeauducq
parent c2b4f0cfe3
commit 1e01e6b834
1 changed files with 5 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/manual/management_system.rst
View File

@ -54,6 +54,11 @@ Experiments are divided into three phases that are programmed by the user:
The three phases of several experiments are then executed in a pipelined manner by the scheduler in the ARTIQ master: experiment A executes its preparation stage, then experiment A executes its running stage while experiment B executes its preparation stage, and so on. The three phases of several experiments are then executed in a pipelined manner by the scheduler in the ARTIQ master: experiment A executes its preparation stage, then experiment A executes its running stage while experiment B executes its preparation stage, and so on.
.. note::
The next experiment (B) may start :meth:`~artiq.language.environment.Experiment.run` ing before all events placed into (core device) RTIO buffers by the previous experiment (A) have triggered. These events can then trigger when experiment B is :meth:`~artiq.language.environment.Experiment.run` ing. Using :meth:`~artiq.coredevice.core.Core.reset` clears the RTIO buffers, discarding untriggered events, including those left over from A.
Interactions between events of different experiments, can be avoided by preventing the :meth:`~artiq.language.environment.Experiment.run` method of experiment A from returning before all events have triggered. This can be achieved using :meth:`~artiq.coredevice.core.Core.wait_until_mu`. In most cases, :func:`~artiq.language.core.now_mu` will return an appropriate timestamp.
Priorities and timed runs Priorities and timed runs
------------------------- -------------------------