PIXIE DAQ SOFTWARE
The DAQ system works on a client-server basis, between a FIC 8234 processor (Creative Electronicx System) on the client side and an IBM compatible PC running Linux Redhat 7.2 on the server side.
A script (called Dixi) is used to launch the server program (Dixiserver) while another script (Dixi4launcher) makes an automatic telnet connection to the client machine using the Expect tool.
Dixi4launcher also calls the client program Dixi4 running on the FIC.
The server program runs independently on the PC in a continuous loop and has to be manually closed when no more needed.
Dixi4 (the client program) starts by showing a list of possible sequences to load in the SEQSI according to a predefined set of run types.
The program requires input parameters as:
- type of run: pedestal, real data or test run.
- number of events to acquire.
Through a TCP/IP connection to the PC this information, plus a global ID number, is sent to the server program, then the sequence starts. The SEQSI drives the sequence levels and signals to the ASIC chip and the clock signal to the ADC synchronized with the chip analog out.
For each event, the digitized data of all channels and the event Id are stored (as short integers) in the FIC RAM memory. A total of 250 events can be loaded in the RAM before transferring them to the PC hard disk through a new connection with the server (the correct size of the each data packet is controlled).
The full process is looped until the total number of requested events is reached.
The last data packet can contain less 250 events depending on the total number of events that have be acquired; in this case the packet size will be shorter.
At the end of data taking the program returns to the beginning asking for a new sequence.
The server program has been written using forked processes in order to speed up the acquisition process.
At the very beginning only the father process runs, waiting for a connection; once the connection is established, it expects some primary information on the run: the global ID, the type of run (pedestal, real data or test), the total number of events and, eventually, a 4 characters string to add to the final file name as a prefix.
Then the connection is closed and the program waits for a new one, to receive the actual buffer.
At this second connection the server is forked and the child process deals with the client while the father returns in listen mode for a new connection. This is done since the process of transferring data through the network is much faster than writing them on the hard disk. So, when the transfer ends (and data are saved on the PC RAM memory) the connection is closed by the child and the client (the FIC) is free to start a new acquisition run of 250 events. In the meanwhile the child writes the buffer on file. During the receiving process there are checks on the size of the transferred data that have to match the expected size of a buffer, i.e. 2101(pixels) short integers +1 (for the event number) times 250 events.
A maximum of 10 child servers can run simultaneously (this number is chosen to not overload the system memory too much, but it could be bigger).
Once this number is reached the father WAITS for a system signal from each child process (and eventually terminates them for not leaving zombie processes running) before allowing new connections.
All the operating child processes will write their buffer on the same file (previously created by the father process) in the same order as they try to access it: it is the operating system itself that takes care of this concurrent behavior by pipelining the processes that try to access the same file table resource. So, there is no need to add system semaphores.
This job is looped until the total number of events is reached, then only the father server remains active. It closes the final data file, renames it depending on the type of run and on a progressive number internally generated and saves it in a specified directory. Then the server returns in listen mode for a new acquisition run.
The data file is a binary file in which the events are stored sequentially.
Each event block has the following format:
o total number of pixels (ushort)
o total number of events (ushort)
o global ID (int)
o ADC value for each for pixel (ushort)
o event number (ushort)
o dummy write (ushort)
For further info: