I have those questions:

• how shall the trigger work? So far I have two triggers for every value, one for opening the booster valve, a second for closing. Once the opening trigger is crossed, booster valves open and remain open until all condtions for clossing trigger are met. The idea is to prevent the system for quickly switching from opening to closing and back
• acceleration shall be based on acceleration data, right? Which fields - shall I check angularAcceleration[XYZ]? I am checking angularAcceleration[XYZ] against two triggers, one for closing, second for opening, but that can change
• for the following error, do we want to record with the "following error(s) caused booster valve to open" message (or some similar) ActuatorIDs of FA whose triggered the booster valve? This can be easily retrieved later, as we stor the following error and limit is know, but it will be nice for display (of curse even display can be done in EUI/GUIs..).

Doug NeillFelipe Daruich?

1. Either trigger shall start the booster valves. Both triggers should be needed for closing. We need the booster valves mostly at the beginning and end of the slew when the acceleration is low and the jerk is high.
2. trigger 2 is based on acceleration. Rx Ry and Rz (x,y,z) it needs an on and off trigger as stated above.
3. We should record which trigger is turning them on, however, this is not a warning or an error since this is what they are supposed to do. How about"
   "Accelerations triggered booster valves." and " force following error triggered booster valves.

1. that's how that work. Plus, in engineering mode, a user can trigger the booster valve. Any of the triggers open them (even the user alone is enough), and all must be off to close (including the user trigger). That means if the user wants to keep the booster valves open, they will be opened. If the user wants to close them, they might re-open or stay open if conditions are met. One can still disable the following error and acceleration triggers in config files.
2. I bet we need different values for Rx, Ry and Rz. Any hint about expected ones? This is the current iteration of the config file:

BoosterValveControl:

  FollowingError:

    Enabled: On

    Open: 50

    Close: 45

  Accelerometer:

    Enabled: On

    OpenX: 2.0

    CloseX: 1.0

    OpenY: 2.0

    CloseY: 1.0

    OpenZ: 2.0

    CloseZ: 1.0

I need to adjust to 2 deg/s2 so it works in simulation, I expect a bit lower values for real thing - I can adjust simulator to give me lower accelerometer readouts..

3. We have a record if the user, followingError or accelerometer trigger are on, and the value that is sent to FAs (now plain or of the three). Do we want to record an array of books, one boolean per cylinder, to record which FAs following error is over trigger? E.g. that will allow one to easily read: "following error was triggered by excessive forces on FA 121 primary, 231 secondary, and 423 primary cylinders". Without that, one must access followingError value, check with trigger values (also stored in EFD), and voila, get the list of the "bad" FA with the following error causing the booster valve to open. That can be added later, I believe we don't need that at the moment.

Please see PRs:

https://github.com/lsst-ts/ts_cRIOpy/pull/62
https://github.com/lsst-ts/ts_xml/pull/702
https://github.com/lsst-ts/ts_m1m3support/pull/131

I reviewed the ts_cRIOpy on GitHub.

LGTM