Because the DXP record can perform so many different tasks, and because it is designed for high performance, it behaves differently from typical simple EPICS records like ai and ao. Processing the record does not actually do anything unless one has written to one of the fields in the record that has the Process Passive attribute. For example, writing a 1 to the .READ_HISTOGRAM field will cause the record to process, and to read the baseline histogram array from the hardware. Similarly, to read the DXP parameters write a 1 to the .READ_PARAMS field, and to read the ADC trace, write a 1 to the .READ_TRACE field. Writing to any high-level parameter such as the peaking time (.PKTIM), or to any low-level parameter (e.g. .A01V) will cause the record to read back all of the parameters, as if the .READ_PARAMS field had been set to 1. The .VAL field of the DXP record exists, but it is not used.
There are 3 types of debugging messages that can be enabled for the DXP software:
var dxpRecordDebug 10On vxWorks
asynSetTraceMask("DXP1",0,255) asynSetTraceIOMask("DXP1",0,2)The second parameter in these commands is the asyn "address" which is the channel number in the system. For a system with 16 dxp records on port DXP1 the parameter must be in the range 0-15.
xiaSetLogLevel(3)The logging level can be set to 1=error, 2=warning, 3=information, 4=debug.
The DXP record has associated device support. This device support is closely coupled to the record and is intended to support all DXP models. It is not expected that there will be a need for additional device support.
The EPICS software communicates with the XIA Handel software through an asyn server. This server provides a single thread that is used for all calls to the Handel library. For the MCA record the server implements standard asyn interfaces like asynInt32, asynInt32Array, and asynFloat64. The server makes calls to Handel in these interface methods.
The DXP device support uses the asyn server by connecting to it, and queuing asyn requests via that server. However, the DXP device support callback does not use the asyn interfaces provided by the asyn server. Rather, the callback routine directly calls the Handel functions. This is perfectly OK to do, and is much simpler than trying to provide interfaces in the asyn server for all of the functions that the device support needs. By using a single asyn server (single thread) for both the MCA and DXP records it is guaranteed that they will not conflict. There is also an EPICS mutex that is used to protect all calls to the Handel library. This is necessary even with the single asyn server thread because the init_record routine makes some Handel calls directly, and this can conflict with the asyn server thread that is already running when init_record is still being called.
The DXP and MCA records communicate only through the Handel API, they do not call any Xerxes functions directly. Handel calls Xerxes, which in turn calls the machine-dependent functions, which are specific to a particular operating system and hardware model. For the Saturn on Windows the DXP software uses the standard XIA machine dependent support. For Linux and vxWorks there is a new md_epics.c file that implements the low-level drivers for the parallel port (Linux) and CAMAC (vxWorks).
Information on how to install, configure and run the EPICS DXP software is given in the general EPICS DXP documentation.
The following are some future plans for the DXP record:
The following are screen shots of the medm screens provided for the DXP application on a single-element detector, such as the Saturn. These screens display and control EPICS process variables that are provided in the files dxp.db and mca.db. These include records other than just the DXP record itself.
Main control screen for single-element detector.
Complete screen for low-level DXP parameters and control.
Screen for SCA display and control.
Screen to display the spectral data and control acquisition. Note that this screen is provided in the EPICS MCA application, not in the DXP application.
Screen to display the baseline histogram and control its update rate.
Screen to display the baseline history and control its update rate.
Screen to display the ADC trace, and control the time per point and update rate.