Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Interactive alarm editing proposal

Abierto
  • ¿Algo no está bien?
#3,920 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
java, kafka
Área
frontend

Línea de trabajo

Start by reviewing the existing Phoebus alarm tree tools and the prototype video linked in the issue; the payload does not name source files or tests. Choose one specific improvement to scope before investigating its implementation, and define completion against that improvement, since the issue proposes several changes and leaves them open for discussion.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

codathon discussion

Overview

Currently, the alarm configuration can be edited either by modifying the XML directly or using the tools in Phoebus (the move/duplicate/rename tools in the alarm tree, the configuration menu for alarms/components, and the 'Add PVs to alarm system' button).

At ISIS we are migrating our alarms from valarm to Phoebus. I am writing a conversion script to get us to a good starting point, but we expect a lot of manual tweaking will be needed potentially including frequent large changes like moving groups of alarms to different components. Having an interactive way to do this would be very helpful for us.

Possible improvements

The alarm tree could be improved as follows:

  • Search bar
  • Drag/drop
  • Copy/cut/paste
  • Allow component/alarm settings to be displayed on the right side of the PV tree screen rather than opening in a separate window
  • Keybinds (ctrl-x, ctrl-c, ctr-v, delete)
  • Change the 'Move PV' screen so that it does not create a new Kafka connection each time - currently we need to wait several seconds to move a PV due to this
  • Remove the 'rename item' context menu button and instead add it to the configuration screen

Mirrored alarms

Another possible change which should probably not be implemented but still merits discussion is to allow alarms to appear in more than one component. The reasoning for this is that some alarms logically are split across components. For example, an alarm which is part of a cooling system spanning multiple components could appear in those components and also in a 'cooling system' component. This would not change anything in the alarm table. The obvious problems are that

  • this might lead to situations where an alarm is unintentionally disabled. To continue the example, the cooling system is still running, but one of the components it covers is disabled. Since the disabled component contains the cooling system alarm, this leads to a cooling system alarm being disabled. This isn't necessarily obvious behaviour and operators might not be aware that they have just disabled an alarm which is part of another system.
  • this introduces additional complexity and ambiguity in the UI - e.g. when an alarm is duplicated should the new alarm be mirrored to the old one so any configuration changes apply across both? A visual indicator would also be needed so it is possible to tell that an alarm appears in several locations. (And so on)
  • unlike the other proposed improvements, this would most likely require non-trivial architectural changes to the alarm server

Still, this might be a good starting point for a 'mode switching' system which allows components of an accelerator to be easily disabled without having to maintain an untenable number of mode configurations for each config. For example, at ISIS there are some components which are usually only run for testing during startup. Putting aside the above issues for a moment, a component could be created which contains all of these alarms, and when they are no longer being used an operator could simple right click -> disable all on said component. Mirroring would allow these alarms to exist both under this 'startup testing' component and also under separate components which indicate their physical position in the machine.

Prototype

I have created a prototype which is essentially a more interactive version of the alarm tree to test some ideas. It is slightly rough around the edges and has some bugs but does update the alarm configuration live in Kafka. Here is a video of it so far:

https://github.com/user-attachments/assets/133c50ac-a7e0-41ea-b56e-c757522971ac

As this functionality is needed at ISIS anyway, I plan to implement at least some of the proposed improvements in due course but wanted to put this out there first to gather input. If something useful comes out of it we'd like to contribute.

Lenguaje dominante
Java
Estrellas
130
Forks
132
Merge medio
2 d 11 h
PR fusionados (30 d)
19

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ControlSystemStudio/phoebus

Todos los issues de ControlSystemStudio/phoebus

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.