-
Notifications
You must be signed in to change notification settings - Fork 2
Emulator
A separate software program exists which allows emulating a detector controller. This allows testing and development of host software such as the COO Detector Controller Server, scripts or other client applications that may use the detector controller server, without the need of having a live detector controller.
The emulator is a stand-alone program apart from the detector controller server, although it was designed to work in conjunction with the detector controller server. It is essentially a "software-controller" -- a piece of software that behaves like a controller behaves. One would connect the emulator just as if connecting to an actual controller.
The emulator performs no logging (just as a detector controller does not) but it will write some messages to standard error, mostly error messages but a few progress messages are shown during potentially long operations such as exposure and readout delays.
There are no changes made to the detector controller server to use the emulator; the same software is used when connecting to the emulator as would be when connecting to a real detector controller. Only the configuration file (§3.2) needs to be changed, in order to instruct the server to connect to the emulated controller instead of the actual controller.
Currently, the emulator only emulates an Archon controller; ARC ("Leach") controller emulation has not yet been implemented.
Although the emulator is a stand-alone program it is included with the detector controller server package, and shares some of the same code for convenience. The emulator is automatically built along with the detector controller server package when the "make" command is used (which defaults to "make all"). Alternatively, "make emulator" will compile only the emulator software. See also Build Instructions, §3.6.2.
The emulator uses the same configuration file used by the detector controller server. Two additional configuration keys are required, as shown in Table 5.
Table 5. Emulator configuration keywords
| KEY | Description | |
|---|---|---|
| EMULATOR_PORT | Port number for emulator | |
| EMULATOR_SYSTEM | System file representing Archon modules | (Archon-only) |
For example,
EMULATOR_PORT=8001
EMULATOR_SYSTEM=/home/user/Software/sandbox/emulator.system
The EMULATOR_PORT is a port number that the emulator will listen to. Specifying the emulator port like this, as opposed to having the emulator "borrow" the port number from the missing hardware, is done to make it possible for multiple instances of the emulator to run on the same computer (which might be useful for emulating multiple Archons, for example). The EMULATOR_SYSTEM file is described in the following section (§10.4).
Note that when running the emulator with the detector controller server, the ARCHON_IP keyword must point to the address of the machine which is running the emulator (or "localhost" if run locally) and the ARCHON_PORT keyword must be the same as the EMULATOR_PORT chosen above. This is because the detector controller server is now going to communicate with emulator instead of the Archon. For all intents and purposes, the emulator is an Archon.
The Archon controller accepts a number of different types of modules which are addressed by their slot number. To properly emulate the hardware, the emulator must be configured with the specific hardware that is to be emulated. This is done with the file specified by the EMULATOR_SYSTEM keyword. Note that there are no requirements on the filename for this file but by convention it is suggested that ".system" be used. The .system file is an ASCII text file formatted as follows:
[SYSTEM]
BACKPLANE_REV=x
BACKPLANE_TYPE=x
BACKPLANE_VERSION=x.x.xxx
MOD_i__REV=x
MOD_i__TYPE=xx
MOD_i__VERSION=x.x.xxx
MOD_j__REV=x
MOD_j__TYPE=x
MOD_j__VERSION=x.x.xxxx
: : :
: : :
etc. where (i,j,...) are the slot numbers, and x represents the respective revision, type and version of the specified modules.
This file can be generated manually, by hand; or, if a live Archon is available with the desired hardware configuration, the detector controller server command systemfile (§4.3.39) can generate the required file.
It is suggested that the emulator be run in the foreground of its own terminal window because it writes messages to standard error which may be useful to watch. Alternatively, it can be run in the background and standard error can be redirected as best suits the operator. If the program were compiled as,
[developer@localhost camera-interface]$ cd build
[developer@localhost build]$ rm -Rf *
[developer@localhost build]$ cmake ..
[developer@localhost build]$ make
then the emulator could then be run with:
[developer@localhost build]$ ../bin/emulator <file.cfg>
where <file.cfg> is the configuration file to be shared with the detector controller server.
The following commands provide full, emulated responses:
SYSTEM
STATUS
TIMER
FRAME
FETCH
WCONFIG
RCONFIG
LOADPARAM
FASTLOADPARAM
The following commands are accepted and return immediately as though they were completed successfully:
FETCHLOG
LOCK_n_
CLEARCONFIG
APPLYALL
POWERON
POWEROFF
LOADTIMING
LOADPARAMS
PREPPARAM
FASTPREPPARAM
RESETTIMING
HOLDTIMING
RELEASETIMING
APPLYMOD
APPLYDIO
APPLYCDS
POLLOFF
POLLON
The requested delay (exptime, §4.3.14) is accurately emulated. The COO Detector Controller Server uses the Archon's own internal timer to time the exposure delays (TIMER, see Archon manual). Since the emulator emulates the TIMER command, it automatically can be used for timing exposure delays.
The emulator doesn't read, analyze, or in any way try to execute the waveforms, but it does try to mimic the frame time when filling its internal buffer with "pixels" just as the Archon would when reading a real device, in order to provide a reasonably accurate timed behavior. The frame-read time is already specified in the configuration file (READOUT_TIME) so the emulator uses this for timing. The emulator assumes that READOUT_TIME was specified as an upper limit for time-out purposes and produces lines at a rate commensurate with a frame time 90% of the specified READOUT_TIME, rounded down to the nearest 100 µsec.
Since the reading of data is performed via TCP/IP (from the emulator to the host software) just as it would from the actual Archon, the timing here should be inherently accurate.
An image of the dimensions specified by the ACF file is created and can be read by the FETCH command. Currently the data is "junk", but a future enhancement would be to fill this buffer with something meaningful.
The emulator uses internal databases to store parameters and configuration keys in the same fashion that Archon does. This means that RCONFIG and WCONFIG access actual memory and, perhaps of more general interest, the detector controller server commands getp (§4.3.18) and setp (§4.3.35) also access actual memory. The user can therefore interact with their ACF file and parameters in the same fashion as is done on an actual Archon.
Not yet implemented.