Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Interactive alarm editing proposal

Đang mở
  • Có gì không ổn?
#3,920 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
java, kafka
Lĩnh vực
frontend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
130
Fork
132
Merge trung bình
2 ngày 11 giờ
Pull request đã merge (30 ngày)
19

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ControlSystemStudio/phoebus

Tất cả issue của ControlSystemStudio/phoebus

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.