5.2 The readout process

This page is part of the ING document INS-DAS-31 Design notes for UltraDAS

Delegated commands

In the abstract, the readout process reduces to creating a Readout object and absorbing it into a Run object. By extension, the Run object is put in control of the operation, and the method Run::readout_run is the entry point for invoking a readout.

Run objects are really decorated Piles of Readouts, and they don't know about low-level, device-proxy objects like Camera-i/fs. They do know that Iterator objects are good at organizing camera operations, and that Pixel-stream objects disgorge pixels if used correctly, so the Runs delegate. The Interator in turn is ignorant of the Camera-i/fs, but knows how to use Clocks and Shutter objects. The Clocks and Shutter objects (and the Pixel-streams) know how to talk to the Camera-i/fs, and they know what to say to the camera, but not how to send the command. The Camera-i/fs know how to forward requests from, e.g. Pixel-streams to the camera itself. (Note that the factoring is weak here. It would look better if the Camera-i/fs abstracted the content of messages to the camera as well as the transmission mechanism.) Figure 5.2.1 shows the chain of delegation.

Figure 5.2.1: delegation during readout.

Note the low number of commands between objects. Whatever else may be wrong with this scheme, the coupling has been kept low.

Trading of the Mosaic; creation of the Readout

One detail is central to this process: the Mosaic object in figure 5.2.1 changes ownership during the readout. While pixels are arriving from the camera, the Mosaic is a part of the Pixel-stream. After readout, the Run asks for and is given the Mosaic. The Run uses the Mosaic to build a new radout, and swallows it, adding the Readout to its Pile. The Pixel-stream has no further claim on the Mosaic. Figure 5.2.2 shows this.

Figure 5.2.2: transfer of ownership of a Mosaic while making a new Readout

This scheme works well enough when there is only a single Camera-i/f and hence only one Pixel-stream. If ING had a camera that needed more than one detector controller, the camera-server would need to run more than one Pixel-stream. At present, there is no provision for this. Figure 5.3.2 suggests that the Mosaics drawn from all the Pixel-streams should be combined (which would need a new method on the Mosaic class) before being stored inside a single Readout object.