Participants: Aleksey Adonin, Christian Hillbricht


  • C: Hillbricht demonstrated the results of the performance analysis and suggested to change the readout interval from 1hz to 2hz. A real difference between the three tested applications could not be found. A more detailed analysis of the set value performance would benefit from shorter readout intervals.
  • A. Adonin agreed on trying to reduce the readout interval. He will ask P. Kainberger if this is doable and also if this is a load problem for the involved hardware.
  • A. Adonin also mentioned that the Ion Source people are not the most demanding users when it comes to set value acceptance - in contrast to e.g. the UNILAC staff.

Status in Instruments

The basic idea of not displaying a summary status is that displaying relevant common statuses should be sufficient
  • C: Hillbricht asked A. Adonin about the actual workflow when handling bad statuses.
    • All interlocks will turn off a device. For this reason displaying the common interlock status is not necessary.
    • Timing turned on/off is not perceived as an 'error' status.
    • The actual set value must be checked or changed before turning on a device again.
    • The detailed interlocks must be investigated before turning on a device again.
      • For this reason it's not enough to display a popup dialog which just displays a turn on / turn off button.
    • Displaying 2-3 common statuses should be sufficient.
    • C: Hillbricht explained that the currently conceptualized instruments display up to 2 statuses. Three statuses will be evaluated.
    • In some cases (e.g. 'Sputter-Schluss') just pressing the reset button will solve the problem.
    • Reset will not set values to 0.
    • It must be ensured that values remain unchanged when turning them on again.
  • A. Adonin explained that changing the set value using a slider and the power button was displayed inside the instrument in early versions of the previous Ion Source Application. This was moved to the dialog to prevent unintended changed.
  • there a not that many relevant common statuses to display.
  • A: Adonin and C. Hillbricht agreed that the team tries to implement the current approach.
  • C: Hillbricht pointed out that displaying all available common statuses might not be possible. So for the concept to make it work, it is in some cases necessary to not display available common statuses, which are traded as unnecessary.
  • The 'Reset' action is not perceived as a dangerous operation and is placed directly on the instrument for this reason. There is currently no comprehensive documentation of the functionality of the Reset commands for all device types. A. Adonin will collect them in collaboration with the device experts.
  • An additional iteration of this initial approach is thinkable, as both attendees agreed that this is a detail that should be easy to change.
  • A: Adonin invited C: Hillbricht so see the status handling in an actual context of use in the main control room in the near future.

Overall and Dashboard (grid of instruments) layout

  • C: Hillbricht demonstrated a series of ideas how the dashboard layout could be designed.
  • A. Adonin explained that the order of the instruments is the turn on sequence. It starts from the top left and then goes column by column. As a result it's unrealistic to layout the instruments based on the number of contained values. A. Adonin also explained that some instruments have a certain hierarchy or are related. These instruments are usually placed together. Some instruments are unrelated and can be placed more or less anywhere.
  • C: Hillbricht will send a PDF file containing the layout ideas to A. Adonin in a timely manner.
  • A. Adonin and C: Hillbricht that more space is required to display all instruments compared to A. Adonins 'Classic 1' draft.
  • A. Adonin will check if one value is sufficient for some instruments.
  • According to A. Adonin the maximum number instruments and values can be found on the penning source. If the layout fits here, it should fit everywhere else.
  • A. Adonin showed some interest in displaying the details as a tab in the sidebar. He also mentioned that it would be nice to display more than one details dialog at once.
  • C: Hillbricht explained that the top toolbar and the status bar will be displayed in all apps and should therefore be used for injector and context/virt. acc. selection, additional commands and global statuses. He recommended to move the additional commands and global statuses from the sidebar to the top toolbar. The virt. acc. display wasn't discussed in this meeting.

Additional Requirements

Loading existing screenshots a reference

  • There is a collection of references for profile grids, transmission and so on. It would be great if there would be a simple way to load these files based on the currently configured ion species.

Persistent Screenshot storage

  • A. Adonin stressed the need for a permanent storage of screenshots

Time plot for some devices

  • A time plot would be useful for some devices. The instrument dialog could be the right place for it. This feature is still in an early stage.

Replacement for ISO/ISD

  • These applications are used for visualizing data collected (in a 5 seconds interval) in the last 24 hours.
  • It must be tested if the current Archive system and the standard visualization tool 'DAVE' are sufficient.
  • C: Hillbricht pointed out that it should work for plain values, but calculated values require additional effort.

Future Goals

  • A. Adonin also elaborated on the future of Ion Source control solutions. The idea is to use more and more machine learning to reduce manual control.
-- ChristianHillbricht - 06 Oct 2020
Topic revision: r2 - 09 Oct 2020, BenjaminPeter
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback