GUI: IOC for generic python script(s)

[Tom-Willemsen]

As a developer and Riken instrument scientist, I would like an IOC which will run a generic python script.

Use case 1:
The thermoelectric cell on Polaris. Currently, there is an instrument script that writes to generic user PVs. It would be better if this could be launched as a self-contained IOC (which would mean that the scientists could set it up without us needing to get involved).

Use case 2:
A user wishes to call a script from an OPI. This needs a PV to run the script and an IOC backend which will run that script.

Suggested implementations are:

1. PyCASPy IOC which has a macro which sets the script file to load from. The script file specifies the PVs and function(s) to run and provides everything
2. A normal IOC which loads a configured db file and runs a configured script based on a button press.

Acceptance criteria:

1. I can run a script from the instrument script area when a PV is set.
2. I can run a script from the configuration area when a PV is set.
3. I can create a script with custom PVs which I can perform logic on in a script. I.E. set the current in the pv and the script will use this value to perform the measurements.
4. I can click a button on an OPI which will run the script

[DominicOram]

DLS has something that might be useful here http://controls.diamond.ac.uk/downloads/python/pythonSoftIoc/2-11/html/index.html

[FreddieAkeroyd]

Doesn't the DLS one need a bit of DLS infrastructure? I wonder if we could use PCASPY for this, with a wrapper to help the user

[John-Holt-Tessella]

It is possible that we could use this for the reflectometers too; but not necessarily.

[ChrisM-S]

How close would the (user's) python scripts written in this sort of IOC scheme be to (user's) python script written to run in NICOS? Would the level of coding skill and support infrastructure be similar (e.g. handling resource overuse/exception cases, non-terminating loops, debugging etc.?) Would they be broadly doing the same things - e.g. parameterized re-usable jobs like a scan? I guess both would need to be able to set/read PVs for monitoring or plotting of progress?

Might there be a means of providing these facilities within a common framework? So, for example, user code developed in NICOS could easily be promoted to an IOC allowing parallel or continuous operations like foil changes in an IOC or rocking curves (a bit like the ORC). Also, then, possibly NICOS run scripts might naturally be able to provide plot-able PVs straight into the IBEX block or PV plotting infrastructure.

The final $64000 question might be, would/could any of this affect or benefit the architecture of the block server? which seems to be our main example of something like this?

[Tom-Willemsen]

Having spoken with Seb Long (the user doing Thermoelectic cell measurements on POLARIS), his thermoelectric cell equipment is likely to stay around in the medium-to-long term, so it would be good to encapsulate the control script for it in this IOC.

[John-Holt-Tessella]

Use case 1 can now be done with the background script ioc.

[John-Holt-Tessella]

#5410 means use case 1 can be done and since we can read any PV including user PVs 3 can also be done. 4 is ugly but functional so I think this is done

[Tom-Willemsen]

Covered by #5410