pixieplugin

Returns an inventory of the modules configured into the DDASReadout(-extclk) program. On success, the status will be 0 and there will be an additional number on the returned line. This number is the number of modules configured into the Readout. For each configured module a line will follow. The lines will be in module number order (thus the first additional line contains a description of module 0).

Each line that follows has the following integer fields in order:

• PXI crate slot in which the module lives.

• Module firmware revision number.

• Module serial number.

• Number of bits of resolution in the flash ADC.

• Flash ADC sampling rate in Mega-Hertz.

For example a module with serial number 123 in crate slot 5 that is a 500MHz 14 bit module revision f will have a description line like:

5 15 123 14 500
                            

Reloads/Resets the firmware for the module module-index (an integer module number). Initial DSP parameters are gotten from the settings file specified by the cfgPixie Be very careful using this operation because:

• Since the assumption is that you are doing this to clear a hung module, you are allowed to boot an active module. Be sure you are not doing this on an active run.

• If you are using INFINITY_CLOCK, note that a time synchrzonization will note be performed unless it is forced via DDASReadout's ddas_sync command.

As the modules boot, the XIA API outputs text to its stdout to display progress.

Reads a channel level parameter from module number module-index's channel channel number. parameter-name is a text string that determines which parameter is read. See the table on page 60-61 of the Pixie16 programmer's manual for a list of the parameter names and their meanings.

On success the double precision parameter value is returned on the same line as the status. The transaction below shows the request and reply for module 0, channel 0 TRIGGER_RISETIME

Request:

Readchanpar 0 0 TRIGGER_RISETIME

Reply (if the rise time is 400ns):
0 0.4
                        

Reads a module level paramter from the module specified by module-index (an integer). The actual parameter value read is specified by the text string parameter-name which can be chosen from the table on page 62 of the Pixie16 programmer's manual.

On success, integer parameter value is returned on the same line as the status. The transaction below shows the request and reply for module 0, FAST_FILTER_RANGE

Request:

Readchanpar 0 FAST_FILTER_RANGE

Reply (if the rang is 3):

0 3
                        

This operation is only legal for modules that are not actively taking data. If the plugin is being used used in e.g. DDASReadout the run must be halted to use this request.

Writes the value of a channel level parameter. As for Readchanpar module-index and channel select the module and channel operated on while value is the new double-precision value. No additional information is returned on the status line.

Here's an example of a successful request to set the trigger rise time of module 0's channel 0 to 500ns.

Request:

Writechanpar  0 0 TRIGGER_RISETIME 0.5

Successful Response:

0
                        

This operation is only legal for modules that are not actively taking data. If the plugin is being used e.g. DDASReadout the run must be halted to use this request.

The request writes a module level parameter. As with Readmodpar module-index selects the module and parameter-name the parameter to modify. value is a new proposed value for the parameter. All module level parameters are integers.

Here's a successful request/response that sets the FAST_FILTER_RANGE to 4.

Request:

Writemodpar 0 FAST_FILTER_RANGE 4

Successful Reply:

0
                        

This operation is only legal if all modules are not actively taking data.

The XIA API has the ability to create a snapshot of all DSP Parameters of all modules in the system into a file. This file can then be used to rapidly reload the DSP parameters at a later time. These files are called .set files. This request uses that API capability to save the current DSP parameters into the file set-filename.

Several important points:

• The contents of .set files are specific to the digitzer models in the crate. Thus if you have saved a set file and later change the module in slot 2 from a 250MHz digitizer to a 500MHz digitizer he configuration of that digitizer will not be correct in the .set file and must be regenerated.

  This is because .set files are essentially dumps of the DSP parameter memory of each digitizer which contains the DSP parameters in device units, which vary from digitizer model to digitizer model.

• More subtly, the set-filename parameter is interpreted in the context of the server not the client. It is also written by the server and therefore the effective user under which the server is running must have write access to the directory and, file into which the set file is being written.

Sample successful creation of a set file:

Request:

Saveparams /projects/separator/setfiles/meaningful-name.set

Successful reply:

0
                        

This request can only be successfully performed if all configured digizers are idle (not taking data).

This request loads the contents of a .set file into the DSP parameter memories of all configured modules. Note that all of the important points described in Saveparams apply with respect to settings non-portability and filename interpretation, with the exception that the server only requires read access to the set file.

Sample successfl load oa set file:

Request:

Loadparams /projects/separator/setfiles/meaningful-name.set

Successful reply:

0
                        

This request performs an ADJUST_OFFSET run on the specified digitizer module (by number not slot).

Request:

AdjustOffsets 0

Successful reply:

0