CERN Accelerating science

R1a
OK I understand you want to send an event within 100ms, but what is the meaning of "events" here ? Do you mean an event table. This would be problematic because the event table needs to be loaded into the CTG module, but the module is already containing an event table that we need to wait to complete before loading another. So yes to an event within
100ms, but an event table within 100ms is another matter.

Event within 100 ms - not a strcitly real time requirement.

Event table - for example the ramp - preloaded - starting on request within 1-2 seconds should be OK. Going to have to watch having to wait for executing table to finish in certain circumstances.

Request to issue event while table executing also required.

R1b
An event request, but what about the "or events" from R1a

greater than 1 event to be sent at the same time.

R2a
Tables of events are associated with the machine mode: This strongly suggests that selecting the MODE determines the event tables sent out.
Aborting a table would then mean changing MODE. For example aborting the ramp by switching from RAMPING to FILLING. Note this would be a disaster if the LSA sequencer screwed up and did it while there was beam in the machine !! (We could impose a state machine in the CBCM to disallow illegal MODE transitions)

NO - we take care of mode - you execute the tables we ask you to. You abort the tables we ask you to. If we lose the beams at the start of the ramp - there is no point in going on with the ramp table. If we switch mode to recover, the first thing we will do is ask the CBCM to abort all executing tables.

Also changing MODE may have latency because event tables are loaded into the hardware etc, so the abort may have to wait some time to finish what it was doing and then change mode at a point in time that may me quantized into say, 1.2S periods.

As above - we change the mode.

What are the modes anyway can we agree on a state diagram, I suggest the following ....
OFF, STANBY, PRE-INJECT, INJECT-PLATEAUX, FILLING, RAMPING-UP, FLAT-TOP, MD, PHYSICS, DUMP, RAMPING-DOWN
Can you give me a simple state diagram with the exact modes you want, their names and what they do, and what transitions are allowed. What is the state after RAMPING-DOWN for example.

As above - we control mode changes - the timing system does not need to know the details. Take it from me - this will be a lot easier for you.

What is the difference between STOP and ABORT, why do we need them both?

Stop - continue table to end and cease any repeat. Abort - stop immediately

If a Forewarning has gone out surely the warning and actual event must go out in all cases, even if aborted.
The tables of events, how long are they, IE what is the time window covered, are they small tables of a few seconds that repeat, or do they last for hours.

Second, few seconds, ramp is 26 minutes.

R2b
Event tables correspond to MODES, so while the CBCM is in a given mode it will continue to send the timing tables for that mode. The problem is
looping over multiple tables that are not of equal length, there could be no time that the MODE could terminate cleanly as one or more of the
tables may still be running while others terminate. If there is a constraint that the event tables are all of durations that have an
integer number of basic periods then clean termination is always possible.

Event tables do not necessarily correspond to modes. We will stay in ramp mode after the end of the ramp and the end of the ramp event table.

What do you mean by nested tables, don't you mean concurrently executing tables ?

OK - skip nested tables - but yes to concurrently executing tables?

R2c
Today this is done via CTIM. Is the existing method for setting up timing for the SPS and other injectors sufficient. Can we use the same method for the LHC timing if we declare the LHC timings on the CBCM to be multiplexed on MODE. To know how this works check out Virtual and the corresponding Key event families in the API paper you have. Again the 100ms constraint would be very difficult to meet here.

We are not multiplexing on mode. We pre-load a table of time/events - we give the table a name, we ask the CBCM to play the table. We should be able to read back the contents of the table. We should be able to modify the table - possibly by reloading the whole thing.

R3
If you have two clients RF and POW for the StartRamp event, but one is delayed, then it is far better to implement the delay at the client end by using the CTR counters than to have the central timing send two events at different times. This helps keep the central timing simple, and allows clients to Enable/Disable these LTIM timings and play around
with delays as they like. This means that LSA would look after these LTIM settings. This scheme of using LOCAL rather than CENTRAL control completely removes the need for system identifiers in the payload, and also event pools are no longer needed as the LOCAL LTIM timings can be enabled or disabled as needed in any combination.

Impelementation details. What is so complicated about send out two different events at different times?

R4
Your R4 is not a requirement, its an implementation. All this stuff about grouping power converters is really nothing to do with the timing, its about Settings Management. If we have LOCAL timings, then the Settings can control all the groupings. What is needed is an LSA program to collect LTIMs together into groups and play with the Delays and
Enable/Disable. The CBCM sends out one single timing StartRamp for everyone, then clients do what they want with it.

THIS IS REQUIREMENT. Either different events need to go out, or the payload needs to change. It is nothing to do with settings management. LTIMs are a implementation detail.

R5
No the machine MODE uses a completely different mechanism. The SBF system is hardware based, the MODE belongs to the LHC telegram and is
sent out regularly each basic period. Incidentally this implies that MODE changes always occur on basic period boundaries.

So we have LHC telegrams now? The mode is critically important for some equipment - I would imagine it is a SBP.

R6
Beam type is an inherited parameter from the injector chain, it will be distributed in the same way as the MODE (=telegram) Beam Energy, Intensity, and SafeBeam and BeamPresent flags (all per ring) are distributed across the SafeBeam Hardware mechanism. This mechanism contains hardware watch dogs and customized timing receiver
hardware. The timing system sends the Safe Beam Parameters whenever the Acquisition at the BCT is made and arrives at the CBCM (Pumped by Etienne), this is true for intensity. Changing the beam type is done when the system commits to an injection as it must be available BEFORE the beam arrives, later the BeamPresent flag indicates if the beam is in
the machine.

The circulating beam type is what it says it is. The injectors don't necessarily know what it is. The to-be-injected beam type must go out to the RF and BI.

R7
The SB parameters also contain the flags, SafeBeam, BeamPresent and others. What is collimator state ? What has it to do with the Safe Beam Mechanism ? Adding this will require hardware changes. How dose this state get sent into the SB hardware and to the CBCM, how is it acquired, how often, and how is it to be transmitted.

The state of certain collimators dictate whether or not it is safe to injection beam of a certain intensity e.g. if the TDI is not in then injection of high intensity is forbidden.

You tell me how this data will be injected into the timing system.

R8
What data ?

Collimator state, intensity etc,

R9
???

R10
What is the difference between the incoming beam type and the beam type?

For example (again) - standard OP sequence which I have been through N times

Circulating beam: pilot

Incoming beam: intermediate 12 bunches of 10^10

4.1
.
. The beam is always dumped unless there is a correct and prompt request from the LHC sequencer
.
.
. It shall not serve other users such as CNGS. That is an operational policy, and they are the ones to decide on what to do with the SPS during LHC filling. There are NO constraints built into the timing to stop them doing interleaved fills should they decide one day to do it.

4.2 SEQUENCE
In fact there needs to be many sequences programmed for the LHC. Pilot, Intermediate, and Nominal sequences. These sequences are today
controlled through the sequence manager. If possible this is the way things will stay.

Injection Master of the LHC. I can't see how the LHC can be master of injection, after talking with Philippe Baudringen we worked out that the
LHC injection timing is the slave of the SPS extraction timing. The moment of SPS extraction is determined the moment you specify the target ring and bucket in the LHC and can not be moved, the LHC just sits there like a baby with its mouth open waiting to be spoon fed.

The LHC decides where the spoon puts the food.

R10
The request must be made promptly, if you are out of the acceptable time window, the request is ignored, it is not put in a queue for the next
super-cycle, the request is totally ignored. Only by requesting in the acceptable time window will the injector chain make a beam. After the
measure at the flat top a prompt request for extraction to the LHC will permit the beam to be sent to the LHC, otherwise the default action is
to dump it. It makes no sense to talk about aborting a request, an SPS cycle can not be aborted, once the cycle starts it must complete, but, if you request
extraction in the good time window, there is no way to abort, its too late, time constraints on the SPS flat top are severe.

R2
This is just the SafeBeam system. This system includes the CBCM and it is monitored by a hardware watch dog.

R3
To target the Ti8 and Ti2 lines with dumps in place is an operational situation that needs a different cycle in the SPS, with the real LHC cycles different conditions are needed and a different SPS cycle. So his way of operating the SPS would look just like say a CNGS super cycle.

Extraction into the lines, for tests, will be done on using the real LHC cycle. The external conditions as reference in R2 will allow extraction if the dump is in.

R4
Sure if you ask for beam and the interlocks are down the CBCM could condition its response, but surely it is the LSA sequencer that should be doing this, and then it can decide or not to issue a request. Admittedly the CBCM dose this for all the other CERN machines, but as you want to be in total control, in the case of the LHC the CBCM is
working in slave mode and dose just what you tell it to do.