The new PVs are now on i03, we can switch over to using them

To do the i03 + i22 merge:

• We need to change i03 over to use the i22 ones and see what breaks
• If there is specific logic in the i03 ones, move this over (but I don't think there is)
• Run i03 system tests to confirm
• Run hyperion unit tests
• Small job

Blocked on the PVs not being as we expected. Working with controls on this

Sorry, late to the thread.

Currently unsure if the #315 slits can also operate on the same of PVs, @dan-fernandes may be able to comment.

These slits implement a different Ophyd class for each set of slits that have different PV names, American vs British English, etc. (it was to just get stuff working, not very well thought out.)
Then my beamline-agnostic Bluesky plan had a factory method pattern to get the correct ophyd class from a config file.

There are other problems with my slit implementation (such as relying on a class I wrote that is essentially just a Motor, very rudimentary simulator, etc.) so I would be happy to edit my Bluesky plan to use whichever slit implementation you choose.

Happy to talk in person if this doesn't help!

mx-controls say they can make the PV naming consistent during next shutdown (CENTRE over CENTER)

this reappered at i18

also this is relevant
#587

I'd like to comment that in future I would expect all containerised motor IOCs with gap and centre slits to be using the template in the pmac module. So this is what we should be aiming for, or if not then we need to change it to what we want:
https://github.com/DiamondLightSource/pmac/blob/dls-master/pmacApp/Db/gap_and_centre_slits.template