---

WINDOW: set a readout window

Actors: udas_window client; udas_camera server; camera.

Outline: the client invokes the WINDOW action. The server works out what this new windowing means both for the readout pattern in the camera and for the data-handling in the server. The server gives the camera new instructions for readout.

Normal course of events:

1. Client invokes the WINDOW action on server, with these arguments:
• Argument1 is the window number; numbers 1..4 are valid.
• Argument2 is the window specification, set to "[1201:1500,1:4200]".
2. Server interprets the new window as starting at pixel 1201 in x and pixel 1 in y, and being 300 by 4200 pixels in size.
3. Server validates the arguments. It checks that the window number is in range, and that the window.
4. Server recomputes the readout format that the camera must follow. It checks that the format can be expressed in the limited memory available to camera.
5. Server tells camera the new format.
6. Camera acknowleges the new format.
7. Server works out how to map the new readout format to image regions, and store the map.
8. Server returns good status to client.
9. Server and camera use the changed format in subsequent readouts.

• Argument1 is "disable". Server computes and applies a format that excludes the nominated window.
• Argument2 is "enable". Server computes and applies a format that includes the nominated window, using the size and position set by some previous call to the action. If the size and position have not been set since server was rebooted, then the exact results are undefined, but server is still able to do readouts successfully.
• The action fails. Server sends and error message to client and returns to client one of these stati:
• arguments are invalid:                                   UDAS__BADWINDOW;
• format will not fit in camera's memory:    UDAS__ROFORMATTOOBIG;
• camera rejects the format:                           UDAS__CAMCMDFAIL;
• camera does not reply:                                   UDAS__CAMLINKDOWN.