Discussion: Alarm view potentially confusing when compared to blocks

[FreddieAkeroyd]

This was reported by Aidy on RIKENFE. Some blocks have their magenta borders but looking at the alarms tab doesn’t show them and a user might not understand whether or not there is a problem, and certainly not what the problem is.

[FreddieAkeroyd]

[FreddieAkeroyd]

I'm guessing the PV referred to by the block is not listed for inclusion in the alarm view, or maybe the IOC isn't? Maybe when the blockserver configures the alarm view it needs to automatically add block PVs to this view for the IOC? If the block is added to the IOC with its block name then it would be clear to the user which device was in alarm as it may not be clear from the block name.

[John-Holt-Tessella]

The alarm view shows:

The Alarms View displays the alarm state of all devices attached to the instrument control PC. (https://github.com/ISISComputingGroup/ibex_user_manual/wiki/Views#alarms)

Whereas the block alarm may be a disconnected block or something wrong below this. I think in this case the alarm indicates that an IOC is not talking in which case there should be an alarm. We should look into this. They are not the same, I am unsure whether we want them to be.

[FreddieAkeroyd]

The RB2_CURR blocks, which points at IN:RIKENFE:RKNPS_01:RB2:CURR, is currently pointing at a running IOC but is in "link invalid" alarm status. Should this alarm show up in the alarms view or is it more selective on alarm types? It is not a "device disconnected" alarm, but the user only sees a purple border on the block and may expect it to be in the alarms view.

[John-Holt-Tessella]

Sorry I hadn't understood your point. There are two things here:

1. The alarm view does not currently show alarm statis of the blocks it shows alarms an IOC, usually one or two per IOC. We can add alarms status of blocks as a new feature. If we do we would need to associate each block with an IOC. This should be created as a separate ticket if we decide we want it? I don't think it is useful to have the information twice in the GUI, so I would vote no.
2. The alarm view should have an alarm from ther IOC which is generating value for blocks RQ1, Momentum, RB2. I am unsure whether it should be one for each item in the chain or one for the chain to show something is communicating. I think I would prefer one for each item on the chain. This may not be showing up because the alarm view is wrong or the ioc doesn't have an alarmed pv. We should check and fix this.

[FreddieAkeroyd]

We could create a separate subsystem in the alarm view for blocks, with the blockname at the top and the alias PV as the next level, or we could try and put the IOC as a sub level of the blocks. Though this may be duplicating the block alarm, I see the current situation is confusing. You see a block in alarms and on RIKENFE nothing is in the alarms view, but even if it was there it is not immediately clear what a block refers to. It should be possible to know what alarm in the alarms view corresponds to that block, and there should be an alarm in the alarms view if a block is in alarm. When the blockserver is creating the alarm config, it could add all PVs from an IOC that are present as blocks but have not been otherwise added. Alarms can be added in trees, maybe we need to add more alarms but group in trees/subsystem better?

[Tom-Willemsen]

This ticket is just to have a small focused dscussion to decide the approach. The implementation is a different ticket.