- Pulse intensity decreases drastically at XTD2 across the train

- the visualisation of our beam therfore needs to be compensated adjusting transmission

- beam shape and uniformity is different than previous days and it is unclear how much of this is related to real changes in the beam or an effect of the slope in the train. We are therefore spending more time than usual to investigate and align becuse we cannot correct the slope.

>50 pulses was requested for alignment explicitly as this is needed to setup the instrument for measurment.

The late shift on the 13th fixed remaining problems with the DLD and the calibration pipeline.

The night shift was then able to collect data on O2 using the two-color mode. Systematic studies were done at different photon energies for both colors. This was done for full FEL intensity and 10%.

The day shift started to investigate if we see an effect changing the delay between the two colors. This turned out to be difficult because we lost the second color when changing the delay. BKR retuned for us with a delay.

Afterward, we asked BKR (Mathias and Mark) to re-tune the two color setup for short pulses.

Upcoming late and night shift should collect more data using the short pulses. Keep in mind to check and record the single pulse FEL spectrum upon each change on the undulator settings.

Staff: JK, CK, KL, AS

X-ray delivery

• 8.4 keV, up to 260 pulses at 1.1MHz, 3.5 mJ

Optical laser delivery

• No laser

Achievements/Observations

• Direct beam path confirmed (MKB_MVP supporting structure issue)
• NKB focus optimized
• Two power slits (MKB_PSLIT and EHU_PSLIT) optimized

Issues

• 7.8 keV is not reachable due to limited motion of undulator gap; 8.4 keV, the used X-ray energy, corresponds to 11mm SA1 undulator gap
• AGIPD chiller issue not solved.

Instrument status

• AGIPD HV off.
• AGIPD's Chiller is off.
• AGIPD gate valve closed and pinned.
• Attenuators set to thickest diamond.

To do for next shift

• If possible, fix AGIPD ciller issue
• If AGIPD will be available, install mirrors for PP laser and continue IHR program

Attch 1: We were having trouble focusing at IRU chamber. After multiple attempts the best we could achieve was 2.9-3.1 um beam.

Attch 2: We then wanted to test if this was caused by the SASE 3 background, after them changing from >350 pulses to 1, we saw an instant improvement of ~0.5um down to 2.3 um beamsize.

Attch 3: After optimizing without SASE 3 background, we got down to 1.9 um (1 um less then with SASE 3).

Attch 4: Finally, after SASE 3 changing back to their <350 pulses the beam now changed from 1.9 to 3.9 um! (instead of the previous 3.1um)

This because the SASE1+SASE3 focus =/= SASE1 focus....

We did not have much time to tune the beam without SASE 3 background, we should think about managing this tomorrow during alignment, and also for data collection...

Staff: DM, CK, KK

X-ray delivery

• 7.8keV, 2.4mj, stable delivery, homogeneos intra train energy most of the time.
• SASE 3 background

Optical laser delivery

• no laser used

Achievements/Observations

• Aligned until IRU, until before full beam test

Issues

• Valve after AGIPD was disconnected elog:12718
• SASE 3 background affecting beam focus at IRU elog 12722
• AGIPD scattering, could not solve fully with slits, to be improved tomorrow

Instrument status

• AGIPD HV off.
• AGIPD gate valve closed and pinned.
• Attenuators set to thickest diamond.
• Vacuum valves closed.

To do for next shift

• Continue with alignment, then experiment.
• Check slits or other solution for AGIPD scattering
• Confirm the beam focus impact from SASE 3 background, after we moved NKB coating (verify if it remains)

Staff: DM, CK, KK, JB, SR (SEC), LW (Uppsala university), MM (GU)

X-ray delivery

• 7.8keV, 2.4mj, stable delivery, homogeneos intra train energy most of the time.

Optical laser delivery

• ns laser for particle imaging

Achievements/Observations

• AGIPD BG optimized by opening Q2 & Q4 quadrants a few pixels and adding Pb shield on IRU_SLIT4
• NKB focused optimized
• Data (75 nm Ag cube) and gas BG (no sample) measured with two different gases (N2 and He)

Issues

• AGIPD BG near the center (1-2 pixels) were quite strong even with tight sliting, but issue solved by opening two quadrants (Q2 & Q4) and moving CSS about 1-2 pixels (elog:12731)
• Found additional AGIPD BG in Q2M1 module (mid-Q range), but issue solved by adding Pd shield on IRU_SLIT4 (elog:12734)

Instrument status

• AGIPD HV off.
• AGIPD gate valve closed and pinned.
• Attenuators set to thickest diamond.
• Vacuum valves closed.

To do for next shift

• Check focus and slit position and continue the program (data measurement).

There was a leak in the Solid Attenuator that increased on Saturday morning when SPB moved the arm number 4 (see last entry ID 236).

We were lucky that a balance developed between the leak and the pumping of the ion pumps, so by setting the setpoints of the three most affected ionpumps to 5x10-5 mbar we could survive the weekend and save the beamtime. 

On Monday Maik and I then entered the tunnel to fix the leak. The need of breaking the interlock to bring a dewar and a pumpcart was already discussed on Saturday/Sunday with the PRC (Jan Grünert) and BKR. So Maik and I could enter on Monday afternoon at around 13:20. We found out that the bellow of the arm number 4 is the leaky one which we removed then and put a blind flange. So the XTD 2 solid attenuator has two removed arms now (see photo).

After about half an hour of pumping both ion pumps on the Solid Attenuator were already in the good 10-6 mbar range. We also set back the setpoint of the three pumps P10160I, P10170I and P10180I to the default value 5x10-6 mbar and put the bridge for the end switch on the connector (see picture). The whole work including cleanup in the tunnel could be finished around 19:15 and the tunnel search crew could then set the interlock back.

So the acute problem with the leak could be solved for first now, but there was no time for the activation of the NEC pump. This should be kept in mind for the next shutdown, when we hopefully have spare parts and can anyway replace the arms number 4 and 5. 

We packed the removed actuator and diamond plate in foil and they are next to the radiation protection release box now and waiting for release (see photo). Email was sent to radiation protection officer.

Thanks to Maik for help and a nice working time yesterday and to Michaela for helping us to bring all the things to the XHE3 shaft building! Thanks also to Raul for talking to BKR as PRC and arranging the final tunnel access appointment!

After going in and reconnecting the camera, we observe att. 1.

According to logs the camera device server was restarted around 11pm, however the camera instance was never reinstantiated after the restart. The Karabo GUI did not indicate that properly, instead showed a frozen image that looked as if the camera works properly.

(see history of camera state in att. 2)

Device Server log shows that after camera connection was lost, the device server restarted?! Was this restart done on purpose?

2023-11-23T23:02:22.499 ERROR  karabo.AravisBasler2Camera  : SQS_AQS_UPP/CAM/A2A1920_2: Could not synchronize timestamp: GigEVision write_memory timeout
2023-11-23T23:02:27.504 ERROR  karabo.AravisCamera  : SQS_AQS_UPP/CAM/A2A1920_2: arv_device_get_float_feature_value failed: GigEVision read_memory timeout
2023-11-23T23:02:30.007 WARN  karabo.AravisCamera  : SQS_AQS_UPP/CAM/A2A1920_2: Control of the camera exflqr50765 is lost
INFO  Successfully loaded plugin: "libslsDetectors.so"
INFO  Successfully loaded plugin: "libaravisCameras.so"
2023-11-23T23:02:33.773 INFO  openMq  : Opened TCP connection to broker %s:%d.
2023-11-23T23:02:33.775 INFO  openMq  : Connection ping enabled (ping interval = %d second).
2023-11-23T23:02:33.778 INFO  openMq  : Connection connected to broker
2023-11-23T23:02:33.778 INFO  karabo.net.JmsConnection  : Opened TCP connection to broker tcp://sa3-br-sys-broker-2:7777
2023-11-23T23:02:33.779 INFO  karabo.core.DeviceServer  : Logfiles are written to: "/scratch/xctrl/karabo/var/log/cppServer/sqs_nqs_vmi_cam/device-server.log"
2023-11-23T23:02:34.785 INFO  karabo.xms.SignalSlotable  : Instance starts up in topic 'SQS' as 'cppServer/sqs_nqs_vmi_cam' - Karabo 2.16.6
2023-11-23T23:02:34.786 INFO  cppServer/sqs_nqs_vmi_cam  : DeviceServer starts up with id: cppServer/sqs_nqs_vmi_cam
2023-11-23T23:02:34.786 INFO  cppServer/sqs_nqs_vmi_cam  : Updated list of devices available: AlarmService,AravisBasler2Camera,AravisBaslerCamera,AravisCamera,AravisPhotonicScienceCamera,CameraImageSource,DataLoggerManager,FileDataLogger,FileLogReader,Gotthard2Control,Gotthard2Receiver,GotthardControl,GotthardReceiver,GuiServerDevice,ImageSource,InfluxDataLogger,InfluxLogReader,JungfrauControl,JungfrauReceiver,PropertyTest
2023-11-23T23:02:34.934 INFO  karabo.core.DeviceServer  : Sending instance update as new device plugins are available: AravisBasler2Camera,AravisBaslerCamera
2023-11-23T23:02:34.934 INFO  cppServer/sqs_nqs_vmi_cam  : Keep watching directory: "/scratch/xctrl/karabo/plugins" for Device plugins
2023-11-23T23:02:34.934 INFO  cppServer/sqs_nqs_vmi_cam  : Starting Karabo DeviceServer (pid: 235604) on host: sqs-rr-sys-con-cams-1, serverId: cppServer/sqs_nqs_vmi_cam, Broker: tcp://sa3-br-sys-broker-2:7777
2023-11-23T23:02:35.073 INFO  karabo.core.DeviceServer  : Successfully connected to time server 'SQS_RR_UTC/TSYS/TIMESERVER'

==> Status of Taylor Cone unknown for runs 334 - 401

We had to physically unplug and replug the ethernet cable to the camera to get it to work again.

On 27th of July, it was reported that arm 5 of the solid attenuator did not stay in 'out' position when retracted, but moved in immediately again.

Reason was, that the limit switch for the 'out'-position did not trigger, and thus the actuator was in error state. Default for error state is 'in'. In order to keep the arm removed, the default was changed on PLC level for the time being.

Today, 30th of July, we did ZZ to investigate the issue. It was found that the bar that accommodates the upper and lower limit switches had become loose and the limit switches were pressed out of the way by the motion, rather than being triggered.

The reason for the bar becoming loose, probably is a not ideal alignment of pneumatic actuator, guiding rod and limit switch bar, which resulted in a small relative motion between the three. This was fixed and limit switches were again aligned and trigger in both 'in' and 'out' position.

We believe, this will remain stable until WMP, but should be investigated more thoroughly, as we could not reach very well all connections in situ.