Add securuity group and extra parameters

[FreddieAkeroyd]

Description of work

Add your own description here

To test

See ISISComputingGroup/IBEX#7821

Acceptance criteria

List the acceptance criteria for the PR

---

Code Review

• A copy of the manual has been placed on the shared drive
• Pertitent information has been stored in the wiki
• Does the IOC conform to IBEX standards?
  • PV naming.
  • Disable records
  • Record simulation
  • Finishing touches
• If an OPI has been modified, does it conform to the style guidelines?
• Do the IOC and support module conform to the new build guidelines
• Have the changes been recorded appropriately in a PR for release notes?
• Is the device's flow control setting correct? For most devices flow control should be OFF.

Functional Tests

• IOC responds correctly in:
  • Devsim mode
  • Recsim mode
  • Real device, if available
• Supplementary IOCs (..._0n where n>1) run correctly
• Log files do not report undefined macros (serach for macLib: macro to find instances of macLib: macro [macro name] is undefined...

Final steps

• Update the IOC submodule in the main EPICS repo. See Git workflow page for details.
• Reviewer has merged the associated PR for the release notes

[rerpha]

everything including the SPs and home/stop buttons are disabled for me - do I need some sort of access control file?

[rerpha]

was being stupid, accessSecurity submodule was out of date

[rerpha]

I can still change OFF, SET, FOFF, CNEN and BDST - probably don't want to do at least the first one?i'm not sure we ever set BDST to anything other than 0.

[FreddieAkeroyd]

We do set BSDT on some Galil systems, in fact SANS2D tank might be one of them, but probably won't set it on a mclennan as it has its own backup steps controller parameter. My concern with protecting OFF/SET is don't reflectometer scientists use it - home to neutrons and then define that as zero? This is more thinking of using this more widely, OFF should ideally be protected on a Mclennan as it is a macro, but we are limited in access control levels so we may need to leave it unprotected. The key things to protect here, and the driver for the ticket, was to avoid confusion when electronics/mechatronics group are trying to fault find a mclennan that doesn't move (properly). So they are likely to try and change ERES/MRES/UEIP/ACCL/VELO etc as part of this so they need to be protected to avoid confusion. I feel they are unlikely to try and change OFF in this case, though in an ideal world we would protect it for a mclennan

[FreddieAkeroyd]

While looking at this is did however make me realise we need to protect the status update button too ISISComputingGroup/IBEX#7837