Reflectometry: corrections for DirectParameter

[ThomasLohnert]

As an INTER scientist, I would like to be able to make a correction to a parameter value applied via DirectParameters.

We already have engineering corrections in the Reflectometry server, however these apply at the IocDriver level which DirectParameters circumvent entirely (they are just a thin wrapper around a low level motor PV).

Post tank upgrade, Theta on INTER is now a direct parameter on the measurement angle axis in the Beckhoff. The measurement angle however is 2x the value of theta so we need to add a scaling factor for Theta to have the expected value. If we do not do this it might create unintended knock on effects e.g. reflectometry scripts expect theta to be equal to phi and would break as a result.

Acceptance Criteria

What is the acceptance criteria?
Insert the 2x scaling factor in a suitable place. Suggested possible solutions (choose one):

• Apply the scaling factor in the internal Beckhoff code so that the measurement angle axis reflects Theta exactly. Talk to SC about this
• Give DirectParameter an optional scaling factor which is applied to setpoints and applied in reverse to RBVs (current hotfix solution)
• Make DirectParameter use a dummy version of the whole reflectometry server stack (components, iocdrivers) allowing the addition of Engineering Corrections (this is the same as Reflectometry: Add component for PV Wrapper #4902)
• @rerpha suggested we might be able to do this by adjusting the motor resolution of the Measurement angle axis, however this needs to be confirmed carefully

Extra Information

Why it is needed?

Where required files/links are

How to Test

verbose instructions for reviewer to test changes
(Add before making a PR)

[rerpha]

we could make directparameter take a transformation function (optional, defaulting to None, or even lambda x:x) which takes something like
lambda x: x*2 in the case of the measurement angle

or we could subclass directparameter and call it TransformedParameter

[rerpha]

just realised you'd need the inverse of that as well which i think makes things more complicated than they probably need to be. I think the first option is ideal, but we might need this in general in the future. I guess the engineering correction may not work for this reason either? does it do both ways ie. apply to SP but un-apply to RBV ?

[rerpha]

Refl: ISISComputingGroup/EPICS-refl#50
release notes: #8198

[rerpha]

Will need to patch this over to NDXINTER after deploy as they require it for their bench.

To review check the code, run unit tests and ioctestframework tests as they should cover pretty much everything.

I decided on allowing directparameter take an optional argument which is an engineering correction, in inter's case it'll be a constantcorrection(x) which returns x and adds it to SP + subtracts it from RBVs.

[rerpha]

this is on INTER now - https://control-svcs.isis.cclrc.ac.uk/git/?p=instconfigs/inst.git;a=blob;f=configurations/refl/config_tank.py;h=2873105c138a2f2285c4163900b1e036371f0570;hb=refs/heads/NDXINTER#l189