Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

ISIS alarm improvement work

Ouverte
  • Quelque chose ne va pas ?
#3,995 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Active
Stack technique
java
Domaine
tooling

Piste de recherche

The issue lists alarm tree and configuration work, including related pull requests #3991 and #3988, but does not identify source files or tests. Start by reading those pull requests and locating the alarm tree and configuration entry points in the Java project. The list covers multiple independent changes and open design questions; done would need to be defined for a specific item before implementation.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Following up on the discussions during the monthly meetings and the Codeathon, I have created a more precise list of work I want to do on the alarm system over the next few months.

Thought it best to create a issue so that the alarm work I'm planning is written down somewhere (please let me know if you'd prefer this split up into multiple issues).

I'm not 100% sure on how every work item should be implemented and whether any will cause problems for other facilities, so please let me know any thoughts or if anyone is interested in helping, discussion is very welcome and this issue will likely evolve.

Context

I am an industrial placement student (i.e. senior intern™) working at ISIS Neutron and Muon source until August, focused on alarms.

We are migrating from an old control system (Vista) to EPICS. As part of this work, we are migrating and improving our alarm system. Over the last 2 months I have talked with our control room crew and head of operations to find out the current issues with the alarm system, prototyped some solutions, and gathered feedback and iterated on them. I have discussed most of these work items at the monthly meetings and was present for the alarm discussion at the Codeathon.

Alarm configuration improvements

  • (https://github.com/ControlSystemStudio/phoebus/pull/3991) Add 'editing mode' to alarm tree as discussed in Codeathon
  • Remove configuration dialog box and embed alarm configuration options into a panel on the right side of the alarm tree
    • Panel hidden when not in editing mode
    • Have to click 'save changes' or similar for changes to be sent to Kafka
  • Alarm configuration table improvements
    • Improve UI for tables by allowing drag/drop, copy/paste, adding keybinds, potentially adding a context menu - not 100% sure what this will involve yet
  • Clientside checking for enabling filter
    • Syntax checking to make sure the expression 'compiles'
    • Live checking of whether the expression evaluates to true or false
    • Have not looked into this at all yet - may be technically impractical
  • Drag and drop
    • Allow selected alarms/components to be dragged and dropped
  • Copy/cut/paste
    • Allow selected alarms/components to be copied/cut/pasted with buttons in the context menu
    • Remove 'move item' after both this and drag/drop are implemented
  • Remove 'rename item' and allow the item to be renames in the configuration menu

Prototype:

https://github.com/user-attachments/assets/0b483e32-c550-4fb4-ae2c-e6c2c65720b4

General alarm tree improvements

  • (https://github.com/ControlSystemStudio/phoebus/pull/3988) Add PV search bar to alarm tree
  • Replace alarm tree expand buttons with filter
    • Remove the 'expand to show [active|disabled] alarms' buttons and replace them with a dropdown containing tri-state checkboxes: 'Active alarms', 'Disabled alarms', 'Acknowledged alarms' (is this too convoluted?)
    • This may break workflows, but a filter seems like it would be a more intuitive and useful way to interact with the alarm tree, and having both options seems like a confusing middle ground (any thoughts?)
    • It would be useful to be able to automatically expand nodes to see the leafs when a filter is active, but this would not work well if you set it to e.g. all inactive alarms. Not sure how to handle this yet
  • Alarm tree context menu improvements
    • Collapse guidances into 'N guidances...' if the number of guidances exceeds a threshold, rather than truncating them
    • Collapse screens into 'N screens...' if the number of screens exceeds a threshold, rather than truncating them
    • Change 'Remove selected items' to 'Remove [N] items', and the same for enable/disable (counts components and their children)

Alarm disable improvements

  • Alarm disabling UI improvements
    • Merge 'disable indefinitely' and 'disable until' options into one single dialog box
    • Box lists all PVs/components to be disabled and the number of alarms to be disabled at the top
    • Box would have a radio selection with options 'Indefinitely', 'Custom', and a set of predefined times from settings
    • Predefined times can be relative (5 minutes, 1 century) or absolute (15:00, Monday 16:50) (why absolute? may want to disable alarm until next shift, end of cycle, or similar - addresses common periodic events)
  • Alarm disable reasons
    • Add a 'Disable reason' radio selection to the alarm disable dialog box containing a set of predefined reasons from settings, or 'custom'
    • To make this a non-breaking change, reasons can be null - but add an option to settings.ini to require operators to add a reason
    • Change alarm tree to display disabled reason alongside 'Disabled'
    • Change config dialog box to display disabled reason next to 'Enabled' (enabled checkbox will need to be moved)

Prototype:

Image
Langage dominant
Java
Étoiles
130
Forks
132
Merge moyen
2 j 11 h
PR mergées (30 j)
23

Préparer son environnement

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ControlSystemStudio/phoebus

Toutes les issues de ControlSystemStudio/phoebus

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.