Adding abstract StopperVetoable

[KaushikMalapati]

Description

Added an abstract class FB_StopperVetoable (name subject to change) which has a WORD var representing a bitmask and three methods - AddStopper, RemoveStopper, and CheckStoppers. The intention is that instead of manually creating a boolean variable and passing it to VetoArbiters and FFOs, you can make calls like AddStopper(PMPS.K_Stopper.MR1K1_OUT). The bitmask will be evaluated at the same time as their normal veto variables. Finally, this bitmask will be exposed as a PV which allow the pmps gui to display information like which stoppers will affect a specific arbiter or ffo and how, and by extension all the devices they represent.

Motivation and Context

https://jira.slac.stanford.edu/browse/ECS-3702

How Has This Been Tested?

Where Has This Been Documented?

Pre-merge checklist

• Libraries are set to Always Newest version (Library, *)
• Code works interactively
• Code contains descriptive comments
• Test suite passes locally
• Committed with pre-commit or ran pre-commit run --all-files
• Check that BP_IO parameters weren't modified unintentionally

[ZLLentz]

I like this approach
I think as much as possible we should be going in this direction with fixed sets of inspectable veto/fault conditions
I wonder what the best way to test something like this would be...

[ZLLentz]

There are a bunch of cases now where veto logic is implemented with one of the stopper vetos inverted e.g. IN AND NOT OUT or OUT AND NOT IN
https://github.com/pcdshub/lcls-plc-kfe-rix-motion/blob/7bdc8691ee018c9beef580cf8c49adc7d47e7347/plc-kfe-rix-motion/kfe_rix_motion/POUs/PRG_3_PMPS_POST.TcPOU#L16

Is there a simple way to include this concept in a framework like this?

[KaushikMalapati]

I could make an array mapping each stopper to its opposite (if it exists) and check it when adding/removing stoppers. It adds some maintenance, but I think that's unavoidable since not every veto has an inverted veto