Storage Ring application(s) in the past

This page contains information about the applications that were used to operate storage rings (=ESR) with the old control system until 2016.

The goal here is to document the functionalities and workflows which were available to storage ring operators via the dedicated UIs. This information can be used e.g. to compare the functionalities/workflows of the new application with those of the past, check if important features are missing, get an idea which concepts the users are already familiar with, etc.

Updates to this page

• On February 14, 2019, a meeting was held in which most questions regarding the "flow control" aspect were answered.
  • Participants: W. Geithner F. Herfurth, C. Hillbricht, S. Litvinov, M. Steck, A. Walter
  • The results/answers were incorporated into this wiki page in the various sections for answered questions and additional information.

Old applications

ESR Modi

Defining a Supercycle

• The user could create a new supercycle by entering the numbers of the desired machines/virtual accelerators as a comma separated list in the upper yellow text field, e.g. "2,4,10,5..."
• The numbers were fixed for the different types of machines, e.g. 8 was always "Extraction". The operators/machine experts who worked on ESR often knew the numbering system by heart.
• Required machines (manipulation machine 1 at the beginning and reset machine 14 at the end) were added automatically and were not presented as available (so the used did not have to specify them).
• The user could define a name for the super cycle.
• AW: Elaborate: According to M. Steck (14.02.), this application was meant to be the "main" point for the user to interact with/influence the cycle. The ESR Pulszentrale was more of a monitoring application (or used for very specific interactions).

Answered Questions/Additional information

Meeting 14.02.

• There was no way to "pre-configure" supercycles for later use.
• The "Speichern" and "Löschen" Buttons were implemented for storing and retrieving settings. However, that functionality was broken after a while and therefore hardly used.
• There was no way to edit the current supercycle's structure from "Superzyklus zusammenstellen". Using this form, you always created a new supercycle which was always initialized with default settings. If you made an "export" (printout etc.) of the settings of the previous cycle, you could enter them again manually, which was very cumbersome and error-prone.
  • ESR experts and Cryring experts agreed that the new system should provide ways to do something like "modify the current supercycle and keep as many of its settings as possible" (e.g. via setting import/export/transfer, or modifying (copies of) existing patterns, etc. - the exact implementation is not that important, what matters is that they want to be able to do something like that)
  • It will have to be discussed which settings exactly should be kept/transferred, e.g. only top-level target settings (compare to ParamModi import/export) or all settings (including non-top level and correction, especially for commissioning (this is currently important for Cryrin))
• In the new application, we would probably have some slightly different "building blocks" (e.g. M. Steck said that there was no need to have two "HF Stacking" machines, a single "Injection" building block would probably suffice).

Open Questions

• AW: Clarify: I understood from Petra and Sergey that there was no way to "pre-configure" supercycles for later use, however there are Save and Delete buttons on this screenshot. What were they used for? If it WAS possible to pre-configure supercycles, was there a Load button somewhere as well?
• AW: Did the "Setzen" button make the cycle "resident"? If not, what did it do?
• AW: What happens in the following scenario: A supercycle containing machines "2,4,10" is currently "resident".
  • If we now go to "Superzyklus zusammenstellen", are "2,4,10" already entered in the input field, or is it blank? (-> is there a way to "edit" the current cycle instead of creating a completely new one? Would it make a difference?)
  • Do the machines retain changes to their settings from one supercycle to the next, or are there always recreated from some baseline? E.g. if we set the energy in "Beschleunigung 2" from 30 MeV /u to 29 in one supercycle, and then create a new supercycle containing "Beschleunigung 2", which energy value does it have?
• AW: Did the user have to enter any settings when creating the supercycle, e.g. energy? Or did the machines always contain all necessary settings? How were changes to the energy etc. handled? (Compare to chain/pattern creation in SchedulingApp today!) -> How would users like to do that in the future?

Modifying settings

• The user could modify the settings for the various machines here. The UI for entering and editing settings seems kind of similar to what we do today in ParamModi.
• Every settings change stopped the current cycle when it has finished.
• Changing a setting in a machine of the normal cycle had no effect until the cycle was stopped and started again. Performing a change in the manipulation machine also led to executing the manipulation machine, for that the cycle would be stopped and then remain stopped. The normal cycle had to restarted manually in either case.

Answered Questions/Additional information

Meeting 14.02.

• "OK" and "Setzen" were used interchangeably: "Save/Apply settings". It was unclear why there were two buttons, probably for historical reasons. It is possible that one of the two buttons closed or minimized the window while the other did not.
• "Zurück" and "Abbruch" were used interchangeably: "Discard unsaved changes". It was unclear why there were two buttons, probably for historical reasons. It is possible that one of the two buttons closed or minimized the window while the other did not.
• The user could modify settings at any time. If the cycle was currently running when the user pressed "Setzen"/"OK", the cycle was stopped normally. Then the settings were sent to the devices. The user had to wait while this was done (it was not possible to trim multiple times and have all the changes applied at once, application was blocked). The application did not know when the cycle/PZ was stopped, but did know when settings were successfully sent. Only then the UI would become enabled/unblocked again. The cycle/PZ was not restarted automatically, the user had to restart it explicitly.
  • It might be a nice-to-have in the future to be able to choose between automatic restarting (e.g. like ParamModi handles trims right now: stop, send settings, start again) and explicit restarting.

Open Questions

• AW: Clarify: Could the user access those pages and modify settings at any time? If the cycle was currently running when the user pressed "Setzen", what happened (was the cycle stopped and the settings applied then? Did the user have to wait for that? etc.)?
  • AW: Clarify: Was is possible to trim multiple time while the cycle was running, and have all the changes applied to the cycle once it had reached its end?

Flow Control: "PZ-Abbruch"

• "PZ-Abbr." was available from ESR Modi (upper right area). For an explanation what "PZ-Abbr.", see below.

Open questions

• AW: Why was "PZ-Abbr." available from ESR Modi, not from ESR Pulszentrale?

ESR Pulszentrale

Flow control

• The configured machines for the current cycle are displayed in rows starting from the top left (always Manipulation machine). Each machine is represented by a rectangle containing some information.
• The manipulation machine is special: It is not truly part of the cycle, but only ever played in alternation. So usually, when the cycle runs, its (e.g.) machines 2-14. If the manipulation machine is requested to run, it will run exactly once instead of the rest of the cycle (2-14). Then, the PZ will be stopped, allowing the user to decide between manipulating again or starting the execution of the the rest of the cycle (here: 2-14) again.
• Machines with a green background were activated, machines with a red background were deactivated (= skipped). The system allowed all kinds of machines to be deactivated/skipped, even those that performed e.g. ramping. Skipping ramping machines could cause problems (e.g. beam loss) if the operator did not know very well what they were doing.
• A red border marked the machine that was currently being executed. It would "hop" from machine to machine when the cycle was running.
• The white number below the machines signifies the number of executions for a machine. The count would be dynamically decremented to show the remaining number of executions while the cycle was running (e.g. the Reset machine has no more executions remaining).
  • Apparently there also was a way to skip the remaining number of repetitions.
• The letter(s) above the machine on the left described the "requested" state of the machine (R=requested, NR=not requested). Usually, the manipulation machine was NR and the rest of the cycle was R (or vice versa), because the manipulation machine was always played in alternation with the rest of the cycle.
• Not pictured: In case of an interlock, symbols marking the affected machines would appear below the affected machines (e.g. red 'B's on each side of the execution count). ( AW: Correct?)
• In the top right corner, there were multiple controls for halting, resuming, stopping and starting cycle execution. For details on what they did, see below.

Answered Questions/Additional information

Meeting 14.02.

• Users could use the "Edit" button to manipulate the activation/deactivation and the execution count of a machine. This could be done when the PZ was stopped or when the cycle was paused. Usually, it was done when the PZ was stopped (this was considered to be much safer).
• The manipulation machine always ran exactly once to apply its changes. Then, the PZ remained stopped. It was up to the user to decide if he wanted to manipulate again (causing the manipulation machine to run exactly once again) or to start the cycle again.
• It was possible to "skip" the remaining number of executions for a machine by pausing and changing the execution count to 0. However, for the next cycle execution, the user had to manually change the execution count back to the original value. This was cumbersome, and according to M. Steck, this was not done very often.
  • M. Steck stated that "PZ-Abbruch" always caused remaining executions of the currently running machine to be skipped, and that that would be sufficient at least for the start of the storage ring operation with the new concept. This was used much more often than explicitly skipping remaining executions only for the currently executed machine.
• If the user hit "Pause", there was no way to "Unpause" before the pause was actually reached. (A feature like this would be nice-to-have in the future.) The wait time was unproblematic, because it was at maximum 16 seconds before the PZ was stopped (because that was the maximum length for machines, and the PZ would stop after the current machine execution/repetition.)
• It was not possible to "rearrange" the machines in the supercycle from ESR PZ. Machines could be deleted, but M. Steck stated that that was rather "dangerous" (error-prone etc., "usually fatal") and therefore not usually done, because the machines could be simply deactivated instead. It was very unusual to delete machines from a paused state, but I may have been done from stopped state.
• Once the user clicked "Stop", he had no other way of interacting with the cycle before the stopped state was reached (so he could not go into pauses etc. while waiting for the PZ to stop).

Open questions

• AW: Clarify: When/how could users modify the activation/deactivation of a machine? (When: Only in pause/stopped state, or always?)
• AW: Clarify: When/how could users modify the execution count of a machine? (When: Only in pause/stopped state, or always?)
• AW: Clarify: When/how could users modify the requested state of a machine? (When: Only in pause/stopped state, or always?)
  • It was suggested to ask P. Kainberger about this.
• AW: Clarify: Was there a way to skip the remaining number of repetitions? If so, when/how could users do that? What was that feature used for (and how urgent is it for future Storage Ring operation - no specific concept yet??) (When: Only in pause/stopped state, or always?) Could remaining repetitions be skipped for measuring machines?
• AW: Clarify: If the user hit "Pause", was it possible to "Unpause" before the pause was actually reached?
• AW: Clarify: Was it possible to "rearrange" the machines in the supercycle from ESR PZ?
• AW: Clarify: What did the request state of the machines mean? Was it possible to "unrequest" certain machines, or was the state always the same for all machines in the supercycle (except for the manip machine, which always had the other state)?
  • Was it possible for both the manip machine and all the other machines to be NOT requested at the same time? (Both requested at the same time was not possible!)
  • Paraphrased from CH: Was Stop/Abbruch basically the same (at least conceptually) as "unrequesting" beam for ESR ("Pattern should come to a stop and then not receive beam again")? Or was it something different?
  • How was beam request for ESR set?
  • It was suggested to ask P. Kainberger about this.
    • According to P. Kainberger ESR request was implicitly set by assigning a SIS machine targetted to ESR and activating. SIS and ESR Pulszentrale handled the synchronization details (19.02.19).

General Notes

Variations of "stopping"

There seem to be multiple variants of "stopping":

1. Pause/Continue: The execution of the cycle is temporarily halted (Pause) and can be resumed by the user (Continue). No events were played while the cycle is paused ( AW: Correct?) Pauses could be triggered between all machines.
   1. AW: Could the user only pause at the "next possible time", or was there a way to pre-configure a pause at a specific point? Would users like to pre-configure pauses?
      • 14.02.: The user could only pause at the "next possible time" (after the next repetition or before the next machine). A "break point" feature for pre-configuring pauses would be nice-to-have.
   2. AW: Clarify: Was it possible to pause inbetween repetitions of a machine? If so, did that mean that the user had to pause while the machine was executing a repetition, or was there a way to pre-configure it?
      • 14.02.: It was possible to pause between repetitions of a machine. There was no way to pre-configure it, the user had to click at the correct time.
   3. AW: Ask P. Kainberger if there might have been Command events being played during pauses.
2. Stop/Start: With (Stop), the execution of the cycle stops when the current cycle is finished (that is when all its activated (!) machines up to and including the Reset machine (if it was part of the cycle) have run for the configured number of times), and does not automatically restart. The (Start) can be triggered explicitly later and starts the cycle from the beginning (-> first machine after manipulation machine, unless manipulation machine was requested).
   => "Finish the current execution normally, then do not start again."
3. PZ-Abbruch: The execution of the cycle is finished as fast as possible: all activated machines that can safely be skipped (see below) are skipped. (Start) can be triggered explicitly later. The cycle then automatically starts over.
   => "Finish the current execution as fast as possible when preserving magnetic history, then do start again."
   • This feature was used e.g. when beam was lost, and the user wanted to have the remainder of the current cycle to be as short as possible to be able to return to a state where beam was back in the facility as fast as possible.

General Questions

Answered Questions/Additional information

Meeting 14.02.

• All machines could be at maximum 16 seconds long. According to M. Steck, this will not change at least for the next few years because the hardware that imposes the maximum time limit will not be replaced during that time.
• Manipulation machine
  • The manipulation machine was used to manipulate the state of the devices between cycles. It manipulated the current state of devices at that time.
    • This was the only way for manipulating the beam while it was in the facility, there was no other way.
    • Addendum 01.04.: If the cycle was configured to end with beam in the machine ("real" storage ring operation), that meant that the beam could be manipulated freely. The stored beam was "killed" when the next cycle was started (because the magnets that inject the new beam into the ring also "kill" the old beam). A "real" storage ring cycle that kept beam in the machine usually had no ramps for accelerations/deceleration after injection, the machine remaine/returned to injection level.
  • It was only ever used after the end of a cycle / before the new cycle (= the new cycle's injection machine) - it was not possible to trigger its execution at any other time.
  • It was used for bringing all devices to injection level (from 0), and back down (to 0) at the end. Between those times, it always brought the devices from their last state (which they currently had!) to the next, newly configured state (which they would then have).
  • It was only ever used in alternation with the rest of the cycle. M. Steck explained that it is kind of misleading that the manipulation machine is part of the cycle: It is used almost as if it was an "alternative cycle" to the rest of the supercycle.
  • It always ran exactly once, then the PZ was stopped. The user could then decide to manipulate again (running the manip machine exactly once again) as often as he wants, or go on to execute the rest of the cycle again.
  • The difference between using the manipulation machine and stopping & trimming the cycle was that the manip machine changed the current state of the devices at a specific point in time (before the next injection), possibly while beam was in the ring. A normal trim usually changed settings for devices in machines that would be played at a later time, it did not change the current state of the devices. What is the same is that both normal trims and the manip machine could only actually send their settings when the PZ was stopped.
  • It was not a problem that the manipulation machine, like all other machines, could only have a maximum duration of 16 seconds: That was always long enough for the manipulations that were performed, there was no "slow ramping" or anything like that that would have taken longer.
• Deactivation/Skipping of machines
  • Only "self-continuous" machines could be safely deactivated/skipped. The system allowed the user to deactivate non-self-continuous machines, but, according to M. Steck, that usually did not work (could not work) because the missing ramps would lead to jumps (Sollwertsprünge) for the devices, causing e.g. the AEG to stop working correctly.
    • Something that was possible is that a user explicitly trimmed the usually non-self-continuous machines (e.g. a deceleration machine) to be self-continuous/constant. Then the user could deactivate the machine without causing setting jumps for the devices. This was sometimes done e.g. when the user noticed that he does not need two deceleration machines after all - he could then trim one of the deceleration machines flat and then deactivate it. (Note: In the new system, trimming a ramp to be flat should also be possible. Then, it should also be short enough to be hardly noticeable even when it is not "deactivated"/does run (~100 ms according to R. Müller).
    • It did not matter if machines were fully "constant" machines (----) or only had the same start/end points (--^--) - the latter was sufficient for being able to safely skip it.
  • M. Steck stated that he does not think that skipping of non-self-continuous should be supported by the new concept/system.
  • M. Steck stated that in the scenario where a use noticed that she did not require all the machines initially planned for the cycle, the clean solution would have been to program a new supercycle that simply did not contain the obsolete machines. However, because it was not possible to change the current supercycle and transferring the settings from an existing/previous supercycle to a new supercycle was a very cumbersome and error-prone manual process, the clean solution was often avoided and the machines were skipped instead. This was the "easy" way, not the "nice" way, and they would prefer to do it differently in the future if possible.
• Reset
  • It was possible to have supercycles without a reset machine if no ramps were performed, e.g. only machines 1 and 2 (Manip + injection) were necessary. (Apparently machine 2 could ramp (in which case a Reset machine would have been necessary), but did not have to.)
  • The Reset machine did not work correctly if predecessing ramping machines were deactivated (unless the ramping machines had been trimmed to be flat).
• Measuring machines
  • Were used for multiple purposes, e.g. Cooler tuning, starting experiment targets, driving measurement devices into/out of the beam, ...
  • They were also used for configuring the total length of the supercycle and some of it parts: It was important that measuring machines could be used to pre-configure a time that would be available for measuring/experiment. E.g. a guaranteed ten minute time slot in which an experiment could perform its measurements was implemented by e.g. creating a 6 second measuring machine with an execution count of 100. This pre-configuration of the time is absolutely necessary.
  • Devices had no settings in measuring machines! They simply kept their settings from the previous (non-measuring) machine while the beam coasted. (Note: This will be different in the new system, where devices will have settings in all beam processes. AW: Correct?)
    • ESR Modi did not provide any way to change the settings for measuring machine (as the devices had no settings in them.) It was possible to send settings to certain devices from other applications. This would cause the devices to jump to the new value, there was no smooth ramping.
    • The length of each measuring machine could be configured from ESR Modi, probably from one of the Menu entries.
  • Measuring machines had pre-programmed timing (certain events were being played).
• M. Steck described that all the non-manipulation machines of a supercycle always had the same request state, while the manipulation machine had the opposite state - so the request state was apparently used for switching between operation of the manipulation machine and of the rest of the supercycle. For questions regarding the requested state of machines, it was suggested to ask P. Kainberger, as he probably programmed this behaviour.

Open Questions

• AW: Clarify:
  • How/For what exactly was the manipulation machine used?
  • Did it only manipulate the injection/reset of the cycle, or did it do something more?
  • Was the manipulation machine also used for bringing all devices to injection level, and back down at the end?
  • Why was it only used in alternation with the rest of the cycle?
  • Was it used only once, or could it be used repeatedly?
  • What was the difference between using the manipulation machine and stopping & trimming the cycle?
  • Could the manipulation machine be used anywhere, or only between the Reset machine and the Injection machine?
• AW: Clarify: Which machines could/should safely be skipped? Only fully "constant" machines (----) or also machines that simply have the same start/end points (--^--)?
• AW: Clarify: How did the reset machine work? Did it work correctly if predecessing ramping machines were skipped?
• AW: Clarify: Was there a way to freely (not pre-configured) manipulate the beam while it was still circulating in the machine? E.g. during pauses, measuring machines, with the manipulation machine, ...?
• AW: Clarify: What were measuring machines used for? (Could they be replaced by stop points in the new control system?)
• AW: Clarify: How was beam request by ESR handled? Was it related to the request state of the machines in the cycle, or was it something different? (Remember that request state of manip machine and request state of all other machine in the super cycle were always different!)
  • It was suggested to ask P. Kainberger about this.
• AW: Clarify: Was is possible to define the "recipient" of the beam after extraction from ESR, e.g. (a beamline to) an experiment/HITRAP/etc., somewhere within these applications? If so, how was it handled?

Short meeting 28.03.19

C. Hillbricht, M. Steck, S. Litvinov

Q: How was the task 'filling ESR' accomplished in the past?

A: Filling ESR was the first task when doing storage ring operation. There was never done anything with the beam until all required injections have been perfomed.

Q: When and how were manipulations performed?

A: Manipulations were not performed in stopped state when the cycle was over but instead the ESR operator had to pause and then manipulations could be performed. This could be done after each machine theoretically. So the maximum of 'manipulation sessions' was determined by the number of defined virtual machines.

According to a later talk on 01.04.19 with A. Walter, M. Steck, S. Litvinov, C. Hillbricht, this information is incorrect. CH: It remains unclear which operation was available in paused state.

AW: In the talk on 01.04.19, M. Steck and S. Litvinov confirmed the findings from the meeting on 14.02.2019 that manipulations were only performed inbetween cycles, when the machine was at injection level. They were explicitly not performed inbetween machines / in pauses. There was therefore only one possible point in time for (possibly multiple repeated) manipulations.

Identified Functionalities

"Flow definition"

• Define which machines are part of the supercycle and in which order. Required machines (manip/reset) were added automatically.

"Making a supercycle 'resident' "

• ( AW: Correct?) Making a supercycle 'resident' in the facility so that it can be executed.

"Flow control"

• Start/stop supercycle execution.
• Pause/resume supercycle execution.
• "Abort" supercycle execution (fastest way to stop while preserving magnetic history).
• Switch between manipulation machine and "normal" supercycle execution.
• Activate/deactivate machines.
• Change execution counts.
• Skip remaining executions for the machine which is currently executed.
• See which machines are part of the supercycle and their execution counts.
• See which machines are currently requested.
• See which machines are currently activated/deactivated.
• See which machines are currently affected by an interlock.
• See which machine is currently being executed.
• See how many executions remain for the machine which is currently executed.

"Setting modification"

• Modify settings belonging to the various machines in a super cycle. Settings were structured into pages for the machines/"topics".

-- AnnekeWalter - 29 Jan 2019