Present: A. Butterworth, D. Cotte, H. Damerau, R. Gorbonosov, M. Jaussi, V. Kain, G. Kruk, A. Lasheen, K. Li, A. Rey, M. Suminski
Introduction (Heiko)
- Heiko gave a general introduction into the concept of linked timings. It is based on a hierarchical structure, the so-called trees, between timing devices tied together by parent-child relationships. Additionally a simple set of rules controls enable and disable of a timing according to the conditioning of its parent, as well as relative delays of the timings with respect to each other.
- Linked timings alow to comfortable handle a large number of timings to control complex processes, e.g. RF manipulations, programmed with timings.
- Existing implementations of linked timings at CERN and ongoing developments are the PS LkTim (operational), the VXS linked timing used in ELENA and LEIR (PSB-type RF beam control, operational) and the ongoing ATIM development for the SPS.
- Heiko pointed out that it was important to avoid implementing a similar functionality multiple times for each accelerator. Long-term availability of linked timings was important to be assured.
Timings - needs for SPS use cases (Kevin)
- Kevin explained the needs for linked timings with the new SPS LLRF system, which before was only possible by static configuration of load events.
- In the post-LS2 era this should be embedded in LSA with the flexibility to manage timing hierarchies dynamically via LSA settings. For the control of the LLRF an ATIM class to program internal timing events at the firmware level is being developed. It will provide dynamic relationships between ATIM events in the same frontend.
- The timing hierarchies shall then be managed by a dedicated application to display the trees. All settings will be managed by LSA.
- With the implementation presently foreseen by RF, the timings in the same linked structure must presently all be ATIMs in the same front-end. This would be a limitation for the PS where the devices are spread over several front-ends.
- Since each ATIM device has one single parameter which indicates its parent device, each ATIM can, by definition, never be attached to more than one tree at the same time. This excludes multiple tree structures as in the PS, but removes the risk of potential overlap between trees.
LkTim - OP considerations (Denis)
- Denis showed some remarks from the operations point of view concerning the PS LkTim.
- The present implementation of LKTim is fully operational since LS1 (with the previous, conceptually identical implementation even since 1995). A generic application allows to manipulate timing trees and to change their structure).
- Timing trees are virtual devices in LSA. They only contain virtual LSA properties describing their structure and status. The three structure is non-PPM since trees belong to a specific process, e.g. longitudinal blow-up or triple splitting.
- Adding a node (timing) to the non-PPM tree structure hence requires that the specific node is added for all cycles which has implications on performance. Heiko pointed out that structural changes to a tree were rather rare and only performed by specialists in the PS. They are normally required after hardware changes and when introducing a new or changed RF manipulation.
- However, also changing the status of the tree ('activate') requires an internal check that none of its timing nodes are already attached to any other tree, which may cause slow response.
- Partial PPM copy of timings belonging to a linked structure may also cause inconsistencies.
- In the PS a tree structure is related directly to a process or (RF) manipulation. For example the same tree for triple splitting is active on all cycles requiring this manipulation. Although a performance issue, the propagation mechanism with non-PPM trees assures that all processes using the triple splitting tree are and remain rigorously identical.
- Heiko remarked that the complex overlap check was not needed in case of a single PPM timing tree per cycle. However, an additional mechanism would then be required to propagate structural changes to multiple users. Verena commented that this could be handled the future by the improved parameter management.
LkTim - the Good, the Bad and the Ugly (Grzegorz)
- Grzegorz gave an inside view on the underlying software to control the PS LkTim. He explained that LkTim was conceptually simple and powerful. It uses LSA standard concepts to keep the structure without dedicated database tables. This keeps the history of changes and all modifications are transactional.
- The LkTim system relies on the existence of virtual LSA parameters and trimming, as well as copying settings with generic LSA tools leads to inconsistencies.
- The fact that an LTIM node can only be in one single active tree significantly complicates the logic.
- A change of the tree structure requires recalculation of the tree status on all cycles.
- Grzegorz showed some suggestions for a new LkTim to avoid the aforementioned issues.
- The tree structure could be build and kept in a similar way as with the present implementation, but based on tables in a FESA class like the LHCMTG
- Node attributes (delay, enabled, permitted) could be kept in virtual PPM properties of the tree (and not of the node timing). This would be a way to remove the for all overlap checks, the same timing would just be part of multiple trees and, in case, trigger multiple times in the cycle.
- Although this seems an interesting concept, it would require timing receivers which would be able to trigger the same timing channel multiple times per cycle. This is presently not the case for most devices in trees.
Timing group in RF VXS LLRF (Michael)
- Michael introduced the concept of the linked timings at the FESA class level which are operational in ELENA and LEIR (PSB-type beam control). Functionally, these linked timings are used for the same applications as the LkTim in the PS to control RF processes.
- Andy added that the ongoing development of linked ATIM timings for the SPS was actually based on the ideas from the PSB-style beam control.
- Again the implementation is limited to the internal timings of one front-end. Since the tree structures in ELENA and LEIR a comparably simple, no application to pilot it has been written so far.
- Nonetheless Michael showed with an example that the operation of the FESA level linked trees is conceptually identical to operating the PS LkTim. There are the same propagation rules for delay and the enable status.
Discussion outcome (All)
- The concept of linked timings implemented in LTIMs at the FESA level limited to node timings in a single front-end satisfies the immediate needs for the LLRF upgrade of the SPS.
- However, it would not be sufficient for the PS, since trees are a combination of node timings in multiple front-ends and, after the LLRF renovation also of multiple device classes.
- The PS use cases suggest to complete split the structure of the timing trees from the actual device nodes. This also assures that the application controlling the tree does not depend on the specific device class of the nodes it is controlling.
- It was therefore suggested that timing trees based on ATIM devices could become sub-branches of a timing tree hierarchies at a higher abstraction layer. In this case the application software would manage these sub-branches, presenting them in a transparent way to the user (order of timing tree?).
- It was therefore agreed to continue with the present concept of linked timings based on ATIMs for the immediate needs of the SPS. Once a first prototype application to view and manipulate the SPS-style timing trees becomes available, possible evolutions for the PS (and other) use case(s) will be discussed to extend these timing trees to a more general base (multiple device classes of nodes distributed over several front-end).
- The overlap checks required for the PS LkTim complicates the software and has implications on performance. Therefore, it will be checked if new concepts for linked timing in the PS can be found to avoid these overlap checks.
- One proposal for the PS are PPM trees per cycle where each timing points to its parent instead of the tree to which it belongs. Implications for the operation of the PS linked timings must be checked thoroughly, in particular on the consistency and propagation of the tree structures between cycles using the same RF manipulation.