Motor Status/Enable Bitmasks

[ZLLentz]

Current Behavior

Currently, there are bunch of motor PVs that are largely unused that are a big drain on load time, but if combined in specific ways would contain useful information about directional enables.
After #192, there will be fewer PVs, and equivalently no good way to understand the directional enable logic.

Expected Behavior

Based on #192 (comment) and #192 (comment), we can combine boolean status fields into bitmasks to group them by usage. This has minimal overhead on the total PV count and could give us live insight into why motors may or may not be able to move forward and backward.

This can be combined with plans to address #188 and #185 and to include variables specifically for the PMPS enables logic.

I can imagine three bitmasks being particularly useful, with a fourth of the remaining/leftover information:

• forward enable bitmask
  • bLimitForwardEnable
  • bGantryForwardEnable
  • the EPS forward enable summary
  • the PMPS forward enable status
• reverse enable bitmask
  • bLimitBackwardEnable
  • bGantryBackwardEnable
  • the EPS backward enable summary
  • the PMPS backward enable status
• power enable bitmask
  • the EPS power enable summary
  • bEnable
  • bUserEnable
  • bSafetyReady
  • the PMPS power enable status
• auxiliary info bitmask
  • bBrakeRelease
  • bPowerSelf (if not removed (it should be removed))
  • bGantryAxis
  • bEnableDone
  • bBusy
  • bDone
  • bHomed

Context / environment

#192

Suggested Solution

Add some extra UINT fields to ST_MotionStage and fill them as bitmasks in FB_MotionStage with the appropriate above status information, exposing them as PVs using pytmc pragmas.