Increase Guards for Valve Overrides

[slacAWallace]

Should we change the override for valves to just apply to the interlock instead of the OPN_DO?

So this would require a user to activate override mode for the system, activate an override for a valve interlock, and then issue an open command for the valve.

[ghalym]

We can, but why?
I like how it was initially implemented that there is a separate 'Force Open" button to override the valve and apply the 24V.
Otherwise someone might not know/forget that the system is in override and click open, which will then Force the valve open regardless of the interlock.
This way the Open button always work with the interlock permission regardless of the override mode. This way there is no confusion and thus no accidents.

[slacAWallace]

That's a good point. Not mixing function is the correct approach.

I guess the global override mode is what makes me uneasy.

How many clicks is it to override any given gate valve? Two for the first, one for subsequent valves. This makes me a bit nervous.

What would be the impact if we make override mode limited to a single device at a time?

[ghalym]

In the Library there are already two override bits per VGC. One is the Override mode, that is an input to the function block, and the other is the actuation of the valve "Force Open".
It then depends on the various PLC programs how they want to implement it. They can either link all the valves to one Override bit or create multiples.
And because it is an input to the function bock, it can't be changed from the valve's expert screen.
It has to be accessed/written elsewhere.

[slacAdpai]

In the current VGC expert screens, the Override mode should be only readback and not set-able because this bit is constantly being set by an input to the VGC function block.

[slacAdpai]

According to Bill, accessing the omitted PVs is still too easy to override on the expert screens. Therefore he wanted password protection as an added benefit.

[ghalym]

@slacAdpai the override mode should not be set-able from the expert screen. It should be an EpicsSignalRO to only show the status of the override. this should be fixed in the ophyd object.

[ghalym]

And those expert screens, should only be visible to "expert" users. Its not just the override bit that is dangerous. You can still do as much damage by changing the set point to a really high value that will allow you to open the valve.
We made them available now, in order to allow the system's owners to put those set points and commission their systems. Otherwise those expert screens should be password protected too. The devices widget carry all the information a regular user need to operate/read a certain device.

[slacAdpai]

@slacAdpai the override mode should not be set-able from the expert screen. It should be an EpicsSignalRO to only show the status of the override. this should be fixed in the ophyd object.

I'll update this in pcdsdevices

[slacAWallace]

They are expert screens for reasons.

What happens when someone forgets to turn off global override mode? Is there any safe guard against that?

[ghalym]

No, there isn't. Overrides are there in case of a faulty gauge that keeps the valve shut. If we are to put a timeout on an override, this means that the valve can shut again when the override times out, which could be during beam.
We can add the override status to the widget. So it will always be visible and then they can remember to switch it off. We can also add it to the logger so it will send a critical message every certain interval of time as a reminder that it is still on.

[slacAdpai]

I agree the current override timeout should be taken out for Maggie's explanation above.