DXP Record

Contents

• Overview
• Device Address Fields
• Array Fields
• Fields to Start and Stop Data Acquisition
• Task Control Fields
• High-level Control and Readback Fields
• High-Level Run Statistics Fields
• Single Channel Analyzer (SCA) Fields
• Low-level Fields
• Record Processing
• Debugging
• Implementation Details
• Future Plans
• Graphical Displays

Overview

Record Processing

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.

Debugging

There are 3 types of debugging messages that can be enabled for the DXP software:

1. Record level debugging. To print out debugging messages from the dxpRecord code type the following at the IOC prompt. On Windows or Linux:

   var dxpRecordDebug 10
   

   On vxWorks

   dxpRecordDebug=10
   

2. EPICS device support and driver level debugging. To turn on these messages type the following at the IOC prompt (assuming your DXP asyn server is called DXP1):

   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.
3. Handel debugging. To turn on informational messages from the XIA Handel and Xerxes software type the following command at the IOC prompt:

   xiaSetLogLevel(3)
   

   The logging level can be set to 1=error, 2=warning, 3=information, 4=debug.

Implementation Details

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.

Future Plans

The following are some future plans for the DXP record:

• Implement multi-threading for multi-element detectors. Although Handel is not thread-safe, the EPICS mutex described above allows multiple threads (e.g. one thread per detector element) to call Handel. When one thread is done reading a spectrum, for example, it can be computing ROIs while the next thread is doing a DMA read of its hardware via Handel. It is not clear if this would result in a significant performance improvement.
• Implement the on-the-fly MCA scanning mode with the mapping version of the xMAP firmware.
• Implement the on-the-fly SCA scanning mode with the timing versions of the xMAP, Saturn and DXP2X firmware.
• Implement the list mode readout of the new DXP-XMAP PXI hardware when it is released.

Graphical Displays

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.

single_dxp_top.adl

Main control screen for single-element detector.

dxp.adl

Complete screen for low-level DXP parameters and control.

dxp_sca.adl

Screen for SCA display and control.

mca.adl

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.

dxp_baseline.adl

Screen to display the baseline histogram and control its update rate.

dxp_baseline_history.adl

Screen to display the baseline history and control its update rate.

dxp_trace.adl

Screen to display the ADC trace, and control the time per point and update rate.