How to read Train IDs at FLASH
- How to read Train IDs at FLASH
- Train ID reading with local ID reader (Advanced ID Server) recommended
- What does Advanced ID Server do?
- Direct reading of Train ID
- Train ID sender program (TIDS) obsolete
- Train ID Yelling server (TIDY)
- Known Issues
- Short presentation by Fini
- Old stuff / details on Train ID
Table of Contents
At FLASH photons are delivered with a special pulse structure:
Recording this Train ID on the user side allows the correlation of data acquired by the user with all the data saved at FLASH in the DOOCS system, especially with the photon intensity data measured by the GMD system.
Within DOOCS the Train ID is a 32-bit number. For the users it is transmitted via a socket connection over ethernet - TCP socket. The ID is set 20 ms before the train starts and stays 80 ms after the train. To read the Train ID by the user there are 2 options provided by FLASH:
- using a provided program (AdvancedIDServer.exe) running on the user's machine, that synchronizes with the Train ID sender and uses the local clock of the user computer to lower the jitter in reading the ID significantly. The user program connects then locally to the AdvancedIDServer program to get the ID ...
- direct reading of the ID via TCP socket
See also this sketch of the sequence with miliseconds attached to it, to see when the ID updates relative to the beam.
Note: If the central Train ID server crashes it will not resume the ID numbers where it was. In most times it will restart with ID 0, sometimes it is set to some high number by hand. For this reason you will see Train IDs with some high bit not as often as expected.
Train ID reading with local ID reader (Advanced ID Server) recommended
What does Advanced ID Server do?
It connects to the TCP based TIDY or TIDS server and continuously gets the Ethernet packets with the IDs. These packets are time stamped with microsecond resolution and stored. This runs all the time. Because we have a lot of data we can correlate the local time on that machine (that generated the local time stamps) and the IDs. If the Ethernet connection lags sometimes, chokes, hick ups and messes around with our packets, even drops some... Who cares. By closely monitoring all data we can define a function to calculate the Train ID from the local time on that machine.
Here it is running on Windows, but of course you can also use it on your Linux machine (build it from the source).
Hint: Do NOT enable "fast shutter eventIDs" in the Train ID sender program if you intend to use the Advanced ID Server! Or use a TIDY server.
You need to specify a suitable TIDY server for your experimental location on invocation like so:
- AdvancedIDServer-inline.vi: Example how to use the Advanced ID Server with Labview (LV11)
- AdvancedIDServer on github
Direct reading of Train ID
Receiving the Train ID via ethernet is rather simple. Just open a TCP socket to the one of the servers and read from it.
The returned string has the following format: YYMMDD HHMMSS.mmm EVENTID
Please see also the sample code for C and LabView 14. Example how to embed the ethernet Train ID code into your Labview project (LV 8.6): BunchID-inline.vi. We have also C++ code which can be used to be integrate into existing projects.
The time and date have leading zeros as necessary to ensure a constant field width. The ID number is not zero padded and thus has a varying field width.
Train ID sender program (TIDS) obsolete
The sender program is currently running on hasfhvctrl.desy.de. It can be restarted if there are problems (Event_ID_Server). It can be changed to continuously delivers Train IDs (uncheck "fast shutter eventIDs") or deliver IDs only if the fast shutter is open at this moment (check "fast shutter eventIDs" as in the example below).
Do not enable "fast shutter eventIDs" if you want to use the Advanced ID Server.
The TIDY: known issues also apply here.
Train ID Yelling server (TIDY)
As alternative to the Train ID sender you can use this server. These are the differences:
- If you write code to read the train-ID please make sure you close the socket properly. Otherwise it can happen that you eat up all available connections.
- If you can not guaranty that the socket will be closed properly the best solution is to use always the same (client-)port number.
- You can also change your system-settings to let the OS handle it (see tcp_keepalive_time).
- 20.9.18: The .exe always try hasfhvctrl.desy.de first. So start with additional parameter via the commandline.