Desired parameters where reached for radiation measurments of the SPB OPT and SPB EXP hutches. Radiaiton could not be detected inside the hutch with the beam shutters open and beam verified hitting the target, therefore it was not deemed necessary to take radiation measurments outside the hutches. As a result there are no additional access restrictions in SASE 1.

Do to repairs that need to be made with the cold compressor. We will be unable to perform Radiation Hutch Commissioning for SASE 1 this week. We will attempt to reschedule the Measurments for Thursday or Friday (10.08 or 11.08) of next week, depending on if it can be coordinated with all involved parties.

There is no restricted access to SASE 1 until then.

The control room thinks that they will be able to very easily provide us the desired parameters for commissioning  the FXE EXP Hutch this coming Monday. If that is the case we will be restricting access in SASE 1 in accordance to the attached presentation from 8:00 am until completion of the radiation measurements. A SASE 1 log book entry will be made when restrictions go into effect and are lifted.

We should find out Sunday evening from the control room if they don't think they can provide us with the proper parameters. If this happens I will send out an email informing you that the measurements have been canceled.  If you don't receive an email from me Sunday evening, assume that the measurements will be taking place beginning at 8:00 on Monday morning and will be in effect for most of the day.

Sorry for the short notice.

Dear All,

We have just changed the time that the Radiation Protection Measurements will take place on Monday. This will now begin at 15:00. The time has been pushed back so that the DESY Radiation Protection group will be able to also be there.

I will inform you if anything changes.

Radiaiton Measurements are complete for SASE 1 Normal access is restored.

The FXE beamshutter key has been installed into the interlock system after satisfactory completion of the FXE Chicane and Radiation Protection Sticker Checklist. The FXE Experiment hutch is now ready to receive xfel beam as required by the FXE instrument group.

However, the bunch mode MUST be limited to 1 or 2 bunches until the new user chicane is tested with thirty bunches using the copper target. This can be done whenever the parameters can be practically put into place. The test will be similar to the hutch commissioning where once it has been confirmed that the beam is on target. I will take radiation measurements at the chicane. This is the only place where radiation measurements will be required. Please provide me as much notice as possible prior to the date and time that 30 bunches will be brought into the FXE Experiment hutch.

I have also place 3 additional area monitoring dosimeters in the FXE Experiment. One on the robot arm where the D3 pandora place holder is. One above the old user chicane on the D.05 side and one inside the new user chicane on the control room side.

Dear all,

we are experiencing constantly crashes with the photonic science camera in the SA1 imager FR. We found now out

- If the pixel format is set to Mono16 the camera will most likely crash, go in error.

- Before instantiation the camera may show Mono16. During connection Karabo but gets a fresh update and the field in the scene switches to Mono8.

Please don't apply Mono16 again.

Best wishes, Dennis

Hi,

the FXE Mono's won't be available via Karabo from 15.30 onwards due to an update from CAS (karabo) and ITDM (server).

Best, Dennis

The GUI crashes reported by FXE will be fixed with the hotfix release coming ~tomorrow.

It is related to very high or low values in plotting widgets scratching the maximum floating point number (1e308 ~ infinity).

-- Wajid & Dennis

Contacted at home 21:30 19.05. Request for support starting SA1_XTD2_MCP/CDC/MCP3 on cppServer/sa1_utca_17.

Located project and device server. Attempted to start SA1_XTD2_MCP/CDC/MCP3. Issue was missing fastAdc plugin. Found info on sa1_utca_17 in commissioning guidelines: say server is exflutc106.

Tried to ssh in to exflutc106 unsuccessfully. Phoned back 23:49 to give status. Informed that accelerator not running due to lightning. Suggested that if I couldn't fix issue soon they should contact next OCD person from 8:00.

Tried further to fix problem. Found section in commissioning guidelines: tried ssh -Y -l xctrl.Still couldn't access exflutc106. Wrote up notes. Sent to next contact. Stopped work 1:45.

* Apparently the device installation failed with ansible on utca_17. Even worse, the requested  utca_18 is not even know, cannot be pinged and nothing is documented.

** Global problem: Karabo develop, checkout and install both return zero exit status from git.

** Device problem: The dependency was declared wrong in the fastAdc

FastAdc installed by hand, dependency built by hand.

Devices can now be instantiated. For the record, with the following problem

INFO  SA1_XTD2_MCP/ADC/MCP2  : Reset simply calls initialize() method now.
INFO  SA1_XTD2_MCP/ADC/MCP2  : Connecting to hardware driver, setting up the device's namespace...
ERROR  SA1_XTD2_MCP/ADC/MCP2  : Cannot create IibusMap object for /dev/pciedevs6 and maps in /home/utcaadm/maps since:
1. Exception =====>  {
    Exception Type....:  IO Exception
    Message...........:  Open '/dev/pciedevs6' : No such file or directory
    File..............:  /[...]/src/IibusMapImpl.cc
    Function..........:  utca::IibusMapImpl::IibusMapImpl(const string&, const string&, bool)
    Line Number.......:  32
    Timestamp.........:  2017-May-21 14:59:57.856975
}


INFO  SA1_XTD2_MCP/ADC/MCP2  : Reset simply calls initialize() method now.
INFO  SA1_XTD2_MCP/ADC/MCP2  : Connecting to hardware driver, setting up the device's namespace...
ERROR  SA1_XTD2_MCP/ADC/MCP2  : Cannot create IibusMap object for /dev/pciedevs6 and maps in /home/utcaadm/maps since:
1. Exception =====>  {
    Exception Type....:  IO Exception
    Message...........:  Open '/dev/pciedevs6' : No such file or directory
    File..............:  /[...]/src/IibusMapImpl.cc
    Function..........:  utca::IibusMapImpl::IibusMapImpl(const string&, const string&, bool)
    Line Number.......:  32
    Timestamp.........:  2017-May-21 15:56:50.638370
}
 

 For record, the last message was me (DG)

 A deeper look into the dev namespace provides only pciedev0 and pciedevs3 are available. (DG)

Hello everyone,

The main Timing System at DESY, which distributes all timing information to our systems, is right now configured to generate 1Hz trigger signals on Event #16. This is the trigger that is deliver to most detectors/cameras on our site.

DESY is testing a new Gun and wanted to use a slower trigger frequency during this evaluation.

We were not inform in advance about this reconfiguration. After a few colleagues from SPB approach us reporting this problem, we contacted DESY and got the update. We will take steps to make sure that future Timing changes done by DESY are communicated to XFEL ahead of time.

The MicroTCA crate used in rack 3.4 (XTD10) has been replaced. The system is up and running. Timing information is properly distributed from this system to the MicroTCA system in rack 3.2 and XGMXTD10.

Dear all,

an update of the Timing boards firmware and doocs server is require. This operation should not take more than 10 minutes per device; during this time no timing signals will be generate (clocks/triggers/bunch patterns/etc.). Naturally, problems may occur during this update which will lead to increase down time.

I will perform this necessary update in the devices locates in SASE1 and SASE3 tunnels today at 11H30. If somebody sees a problem please contact me.

Concerning the devices in the Experiment Rack Rooms, I will contact a responsible person to schedule a time slot where this update can be perform. If are one of these people contact me.

Hi everyone,

after talking with the responsabile people, here's the timetable for the Timing firmware/server update:

In the meantime, all of SASE1 and SASE3 machines have been updated (with exception of the MicroTCA in the SASE1 Balcony room) with no problems.

Dear all,

with the exception of one board, all boards in SASE1, SASE3, FXE, SPB and PPL have been successfully updated. All Timing boards are now running firmware v1.24.0. The doocs-x2timer-server has also been updated in all CPUs; running version is 7.8.

The problem occur in the Timing System of rack 1.2 located at XTD2. The MCH board is not reachable via ssh/telnet/web interface; thus I am not able to power cycle the timing board, which would make the hardware load the latest version. The board is currently running (i.e. generating all the timing signals) but with an older hardware version. During the next week this problem will be tackle this problem with a quick visit to the rack.

Cheers.

Dear all, 

following up from the message #449, the MicroTCA Crate in rack 1.2 has been rebooted. Timing system hardware is now running firmware v1.24.0.

Dear all,

I communicated today on the 13h meeting that the Trigger #16 was back to 10Hz; this is no longer the case, the trigger signal is back to 1Hz.