Reflectometry: How to handle low-level SP changes

[ThomasLohnert]

One bit of feedback that came out of testing on CRISP was that it is confusing that setting setpoints directly on the motors does not propagate through to top-level parameters. E.g.

1. Reflectometry parameter S1VG is 5
2. Value of 10 is written directly to underlying JAWS1:VGAP:SP PV
3. Going back to the top level s1vg parameter RBV is 10 but SP:RBV is still at last value set via reflectometry parameter (5)
4. Triggering move on beamline reapplies SP:RBV of 5

This may need some further discussion, e.g. what happens if low-level motor values do not form a sensible parameter value, like det_height suggests one theta value and det_rot suggests another

[John-Holt-Tessella]

We did some scanning at the lower levels during the demo because some items were not working as expected (like the detector height). Some items were missing like the angle offset for theta. If we added these in everything should be doable from the top level. Blocks can be pointed at the top level items and we can create opi's that just deal in these top level items. If we update the setpoints on the reflectometry panel based on low level changes then these odd cases occur:

• case 1: Jaws
  1. Northblade is moved.
  2. On the reflectometry panel jaws centre offset is updated and vertical gap is updated
• case 2: Jaw gap
  1. Gap is changed in the gaps table
  2. Reflectometry gap set point readback and setpoint requested are updated.
  3. User loses last gap they set but on clicking move the jaws do not change position
• case 3: Theta
  1. Detector is moved up
  2. Not clear whether detector height offset or theta should be changed
     1. Theta changed detector has not go the correct angle, slits are all in incorrect places
     2. Detector offset change, detector is no longer centred
• case 4: Super mirror
  1. Super mirror angle is altered
  2. Set point for super mirror angle is updated
     1. Either all other setpoints are changed
     2. Alerts are fired for all other components they are no longer aligned

What I think I have convinced myself is that it makes no sense to change low level items. The reflectometry IOC is in charge or it is not.

[KathrynBaker]

I want to see the agreement from the instrument scientists relating to this before accepting the statement “The reflectometry IOC is in charge or it is not.” Whilst I agree with the sentiment, one of the reasons we ended up putting in so much of this checking up and down in SECI is because the scientists asked for it/needed it. They wanted a top level, but they would still look at, and change things, on mid levels (so the jaws layer for example) and the lower levels, and if they failed to notice that the top level didn’t match then it could result in a LTR or a bug report related to that mismatch of statuses. (This isn’t theoretical, it has happened to me in the past.) If there is an agreement from the majority of the scientists who will be using this in the end, great, but I’m not sure it will work out that way…

[John-Holt-Tessella]

In meeting minutes from progress meeting 2019/05/07:

We agreed that set-points are only ever set on the reflectometry IOC they are pushed down to midlevel and low level components. Set-points are not read by the reflectometry IOC and updated. Set-point read-back values in the reflectometry IOC are displayed in the IOC and should be coloured to warn that they are different from the current set-point. This means all blocks should point to the reflectometry IOC. If I set the jaw gap on the mid-level OPI then clicking move on the reflectometry OPI will change the gap just set. We were all happy with this logic.

Document this and close ticket.