Instron MiniTower - decide details of how to support host computer

[Tom-Willemsen]

Where?

The new instron IOC needs to be run on a dedicated PC, loaded with manufacturer software, which includes Arby.dll (the DLL we now use for communication) as well as the Instron "Console" application.

Complications:

• The computer is currently an FIT-managed, and rather old, desktop computer
  • It does not currently have enough network ports - at very minimum it needs one for communication to stress rig (dedicated) and one for ISIS network. Scientists have also expressed a preference for at least one spare port.
  • It also needs to communicate via USB to a physical handset. So virtualising it may be difficult.
  • It it not currently set up in our standard way for an instrument-like machine (group policy etc)
  • I feel we should consider moving it to more standard and up-to-date hardware.
  • If we keep the existing hardware, it would benefit from more memory (currently only has 8gb) and also an SSD (it currently has a hard disk) in addition to the extra network cards above.
  • Computer should be assigned a longer DHCP lease
  • Questions over whether we want a standard desktop form factor, NUC form factor, or an all-in-one with touchscreen etc
• The IOC needs to be a 32-bit build as we have to link against a 32-bit DLL. Currently we don't create 32-bit releases (we probably now should create 32-bit releases)
  • We should probably run at least some automated tests against 32-bit builds if they're going to be used to support equipment. Decide what subset of tests we want to run.
  • Decide what our release and manual testing strategy is for 32-bit builds
  • It would be logcal to deploy to this PC at the same time on the schedule as ENGIN-X/ENGINX_SETUP. Eventually this setup may also move to IMAT, consider what happens if e.g. ENGIN-X is on version X but IMAT is on version X-1 or X+1 (maybe put ENGIN-X, IMAT, ENGINX_SETUP, and this PC all in the same release group?)
• Decide whether to run this PC as an "instrument" or "mini-inst"
  • Complication: Instron needs to run alongside ARACCESS which needs a MySQL database up on the same PC. If we want to refactor ARACCESS to be more generic, think about MySQL write permissions setup etc.
  • May be used by either ENGIN-X or ENGINX_SETUP (or maybe IMAT in future). So avoid hard-coding ENGIN-X anywhere.
  • Decide which PV prefix this uses (MO:INSTRON1?)

How?

This issue was spawned by investigations in #7296. Further detail is on that ticket and in the Instron manuals area on the usual share.

Acceptance criteria

• Meeting had with appropriate stakeholders to discuss the points above
• Appropriate tickets have been created for all actions discussed in the meeting

How to Test

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

[Tom-Willemsen]

Meeting provisionally scheduled for 12/09 at 14:30.

[Tom-Willemsen]

Actions:

• @FreddieAkeroyd to discuss details of accounts with relevant people
• Scientists to send project codes to @ChrisM-S to enable purchase of new PC
• @ChrisM-S to draw up a list of what we need to ask FIT for in terms of machine setup (e.g. not sending USB network adapters to sleep)
• @Tom-Willemsen to discuss 32-bit releases and also whether we want to run this machine as an "inst" or "mini-inst" or something else with relevant people.

[Tom-Willemsen]

Follow-up meeting to discuss IBEX setup on Monday 26th - impeded until then.

[Tom-Willemsen]

Meeting had between @Tom-Willemsen and @FreddieAkeroyd , the following was decided:

• This should run under a PV prefix like MO:INSTRON1: or MO:SRIG1:
• Run it as a mini-inst-like machine, running:
  • INSTRONA
  • ARACCESS
  • MySQL
  • Inst archiver (note: this is non-standard for a mini-inst, this might need some extra work to get running properly): ENGIN-X instron: investigate running ARINST in a mini-inst setup #7383
  • Gateways (configured to allow write access from ENGINX & ENGINX_SETUP)
• For releases:
  • Make 32-bit EPICS builds part of our release process (part of ENGIN-X INSTRON: create 32-bit releases #7384)
  • Change the build location of 32-bit EPICS builds from c:\instrument\apps\epics32 to c:\instrument\apps\epics (part of ENGIN-X INSTRON: create 32-bit releases #7384)
  • Attempt to run all IOC tests against 32 bit builds, if this is hard or lots fail then just run INSTRONA tests (part of ENGIN-X INSTRON: test 32 bit builds #7385)
  • Write an automated test to prove that a 64-bit EPICS client can communicate with a 32-bit EPICS gateway (part of ENGIN-X INSTRON: test 32 bit builds #7385)
• For deployment process, deploy the following to instron machine:
  • Python (normal 64-bit) - needed for ARACCESS
  • Java (normal 64-bit) - needed for inst archiver
  • MySQL (normal 64-bit) - needed for ARACCESS & archiver
  • EPICS (32-bit). Should be installed to c:\instrument\apps\epics, NOT c:\instrument\apps\epics32.
  • Client (optionally, but may be useful)
• Modify the deployment script to include a 32-bit option. The script should look at the currently-installed EPICS_HOST_ARCH to help developers choose an appropriate release. For a first-time deploy the developer should be given the option between 32 and 64 bit deploys (with documentation specifying that for most instruments 64-bit is the appropriate build). Part of ENGIN-X INSTRON: create 32-bit releases #7384

To review: check that created issues accurately capture remaining work and have sensible acceptance criteria

[KathrynBaker]

From those notes, those tickets do accurately cover the work to be done.