pcdshub / mec

mec

Repository for mec-specific code

mec's Issues

Time delay between X-ray and optical lasers

Feature Request

Define functions to delay the X-ray pulse vs an optical laser before interacting with a sample.

Existing Alternatives

I did not find any similar functions in the current mecpython version. The alternative is set several DG645 boxe's channels or VITARA target time manually, everytime that a different time is required. Incorrect values can be potentially set which could be detrimental to the laser systems (the VITARA could go out of range and pose issues for locking, bucket could be jumped for long pulse laser sysems, ...).

Context

While this request is linked to MEC, some of the functions are relevant for short pulse duration laser systems available in the other hutches. At MEC, we have a long pulse laser system whose delay vs the LCLS is achieved by changing delays on channels of an SRS box, and a short pulse laser system whose delay vs the LCLS is achieved by changing the target time of the VITARA. Changing timing in these devices is risky so controlling it by the use of a script helps to secure safe operation by the staff or the users. In the past, similar type of functions have been developed (old versions as *.py files are attached to this issue) but are now missing in the new hutch python implementation.

Suggestions
There should be two types of function implemented, as a function of the laser system in use:

> xray_delay_vs_spl
> xray_delay_vs_lpl

where spl stands for short pulse laser (a short pulse duration is ps or fs) and lplstands for long pulse laser (a long pulse duration is ns). From the user perspective, it makes more sense to start naming these functions by xray_delay since in a pump-probe experiment at an FEL, the FEL is usually used as a probe with the optical laser used to excite the sample (whether it is used in bio, condensed material or high energy density science). Of course, we know that the X-ray arrival time on sample cannot be changed and that we actually change the optical laser timing. But in a python implementation, this should be transparent to users to avoid confusion.

Each function should have a set of common attribute like:

> xray_delay_vs_spl.get_delay() or xray_delay_vs_spl.status()
> xray_delay_vs_spl.set_t0()
> xrat_delay_vs_spl.mvr()

Each of these attributes are important for the operation, here are their description and common use:

def get_delay(self, verbose=False):
     ```
     For the short pulse laser (xray_delay_vs_spl), print the current delay like:
     > X-rays are delayed by 300 fs with respect to the short pulse laser
     If verbose is True, display more information concerning the actual value of the VITARA target time.
     For the short pulse laser (xray_delay_vs_lpl), print the current delay like:
     > X-rays are delayed by 5 ns from the long pulse laser
     If verbose is True, display more information concerning the actual values of the channels in the SRS box.
     Additionally, if a delay is `positive`, it means that the X-rays arrive **after** the optical laser, while when the
 delay is `negative` the X-rays arrive **before** the optical laser. So, if one entered `xray_delay_vs_spl(300e-15)`, the delay text could read:
     > X-rays arrive 300 fs after the short pulse laser.
     while, if `xray_delay_vs_spl(-300e-15)`, the delay text could read:
     > X-rays arrive 300 fs before the short pulse laser.
     The **after** and **before** could have a bold type of some specific colors as a plus.
     ```
     code

def set_t0(self, val):
     ```
     Extract the current values of the VITARA target time or the various relevant channels in the SRS box or use 
the **absolute** value and use it/them as a relative time overlap (`t0`) between the X-rays and the optical laser.
 The values could be stored in a PV or whatever makes sense to allow for easy access later. On the VITARA 
output example attached to this issue, the target value is pushed to 1020.57020 ns:
     > xray_delay_vs_spl.set_t0(1020.57020e-9) # or
     > xray_delay_vs_spl.set_t0()
     ```
     code

def mvr(self):
     ```
     Change the delay **relatively** vs the current delay. The current delay could be `t0` or any other delay. The 
value can be positive or negative, with units in `seconds` so that probing 100 fs later than the current delay 
value would be:
     > xray_delay_vs_spl.mvr(100e-15) # this would remove 100fs to the VITARA target time
     > xray_delay_vs_npl.mvr(10e-9) # this would remove 10e-9 to a specific channel in a SRS box
     > xray_delay_vs_npl.mvr(-2e-9) # this would add 2e-9 to a specific channel in a SRS box
     ```
     code

def xray_delay_vs_spl(self, val):
     ```
     Change the delay between the X-ray and the optical laser, setting the actual experimental value rather than 
the electronic value. It does change the delay vs the `t0` set earlier. Essentially, it would 'push' the `t0` - `val` 
directly to a channel/target field. The value can be positive or negative, with units in `seconds`. On the VITARA 
example attached to the issue, if a user wants to send the X-rays 300 fs later vs the optical laser, the command
 would read:
     > xray_delay_vs_spl(300e-15) # the value pushed to the VITARA would be 1020.57020e-9 - 300e-15 = 
1020.56990e-9, which will effectively trigger the optica laser 300 fs before the X-rays.
     ```
     code

MEC Implementation
The various relevant parameters for MEC are the following:

• for the lpl: the SRS DG box MEC:LAS:DDG:03, channel A, C, E and G needs to be changed. So, for example, if
  the values shown in the file dg_lpl.png are the t0for the lpl, then using xray_delay_vs_lpl.set_t0() would store the values:
  • 0.000875848 (chA),
  • 0.0000689354 (chC),
  • 0.0000689354 (chE),
  • 0.00010184933 (chG)
    Then, using xray_delay_vs_lpl.get_delay() would produce something like:
  • > X-rays are delayed by 0 ns from the long pulse laser
    And if the users want to probe with the X-ray 3.0 ns later than the optical laser, using xray_delay_vs_lpl(3.0e-9) would set the values of the SRS DG box MEC:LAS:DDG:03 to:
  • 0.000875845 (chA),
  • 0.0000689324 (chC),
  • 0.0000689324 (chE),
  • 0.00010184633 (chG)
    Finally, using xray_delay_vs_lpl.get_delay() would produce something like:
  • > X-rays are delayed by 3.0 ns from the long pulse laser #or
  • > X-rays arrive 3.0 ns after the long pulse laser
• for the spl: the VITARA (LAS:FS6:VIT) target channel is the only value to change. Using xray_delay_vs_spl.set_t0() would store 1020.57020e-9 in a PV or something like that. Then, using xray_delay_vs_lpl.get_delay() would produce something like:
  • > X-rays are delayed by 0 fs from the short pulse laser
    And if the users want to probe with the X-ray 500.0 fs later than the optical laser, using xray_delay_vs_spl(500.0e-15) would set the target value of the VITARA (LAS:FS6:VIT) to 1020.569700e-9 and xray_delay_vs_spl.get_delay() would produce something like:
  • > X-rays are delayed by 500.0 fs from the short pulse laser #or
  • > X-rays arrive 500.0 fs after the short pulse laser.

MEC running out of PVs (preset related)

Feature Request
We are running out of PVs. Since we use them mainly for target presets, it would be good to know the status of the new approach to presets mentioned by Silke and being tested to XPP/XCS.

Existing Alternatives
Erasing existing already allocated PVs, which is not ideal.

Context
Our PVs are mainly used to set presets for target positions (calibrants or fiducial for alignment). We know that we are going away from this method of having presets, but we don't know when, while we are expanding our list of calibrant (the number of PVs being fixed). When can we try the new preset way? If not yet available, is there a way to expand our PV list by x2?

NSL rate (sync marker)

Feature Request
To accomodate a new operation script that take advantage of the VISAR that can be saved in the DAQ, we would need to run the sync marker at 1Hz before calling x.nsl.shot.

Existing Alternatives
For now there is none since the value is protected and set to 10 Hz. At the moment and at this rate, it will take one image, and the rest will be damaged. Not a show stopper but it brings instability to the DAQ.

Context
In the script we use to take VISAR references, the rate in the x.nsl.shot plan is set to 10 Hz, to match the one needed for the long pule laser. However, the VISAR cannot run this fast. 1 Hz is kind of the optimum rate. Since we are combining the X-ray only with the visar reference, I would like to set the rate at 1 Hz so that the VISAR doesn't get damaged events when taking say, 10 events (which would produce 10 visar references). Technically, I should just update the dictionary of the config function like x.nsl.rate=1 or x.nsl.config['rate']=1 , but it seems that my call is overwritten somewhere else. I think it is overwritten because the long pulse laser needs the sync mark at 10 Hz to run properly. But we don't use it in this script.

Just to be clear: the long pulse laser NEEDS to run on the 10 Hz sync marker, but when we take references we only use the VISAR and the X-ray laser so this restriction is not necessary, and we would prefer to run on the 1Hz sync marker to prevent VISAR damage event.

If you lift the restriction completely, we need to know that to make sure we force 10 Hz before we take a driven shot (not a big deal, just one line of code).

Happi Database Entries

The MEC beamline file is pretty cluttered. Some devices that should always be available, such as the event sequencer, are defined in the beamline file.

Time tool improvement

Feature Request

Add the time compensation at the time tool delay stage when changing the pump-probe delay between x-rays and optical laser.

Existing Alternatives

Do this manually on the delay stage itself. Can make mistakes and slow down operation.

Context

I don't have all the time I wanted to write a more detailed request but this should be fairly straightforward. The time tool is used to measure the arrival time jitter between the xrays and the optical laser. However, when the delay between the pump and the probe is changed, this also change the time tool delay since it is slaved to the optical laser itself. As a result, a delay stage is implemented in the optical beampath of the time tool which is used to compensate the delay introduced at TCC. It means that when pushing a delay value on the VITARA target time, we should move a this stage to compensate this delay by a specific amount and direction. The motor to consider is MEC:LAS:MMN:19from the Newport controller XPS_3 (TimeTool): mcn-mec-las3.

For example, when the target time on the VITARA is moved negative (moving the optical laser earlier than the t0) by say t=1 ps, the delay stage should be moved in order to lengthen the beam path to catch back the Xrays in the viewing window. Since the delay stage has a 'trombone' of mirrors (2 mirrors at 90° from each other), it means that when the stage moves by a distance d negative (the orientation of the stage and the settings of its direction are set such that going positive shorten the beam path), it will lengthen the beam path and increase the arrival time by the value t*c/2 with c is the speed of light. When adding the units, d = (t * (2.99792458e8 * 1.e3))/2. with t given in s and c has been converted to provide d in mm, the units directly input to the stage. So, for t = +1ps, the delay stage needs to move by -0.15 mm to compensate for the delay. When the delay introduced in the fstiming function is negative, say t = -2ps, the delay stage needs to move by +0.3 mm.

In the command used to change the VITARA timing (fstiming.mv()), we need to add the line that compute the change in position on the stage (with the equation described above), and then push the value to the stage. We can directly use the input value given to the command, but the value needs to be converted to provide second s for the distance calculation. These few lines could also be added to the fstiming.mvr() but since we use this function mainly to find the t0, which could be initially off by ns, we should not move the delay stage at the same time. So I would not add these lines to the fstiming.mvr() function.

Standardize (?) MEC Time Tool Compensation

I wrote a quick function for MEC LV25 to help them do timetool compensation for this experiment. This is an issue to remind us to go back and look at this when there is a little more time to do so.

As @silkenelson points out, we should investigate if MEC can use one of the standard pcdsdevices written for this purpose in other hutches. MEC is different enough that it is not immediately clear that this will work without going through the code, which I have not done.

Assigning this to myself for now, since I am the reason for this non-standard-ness in the first place.