-
Notifications
You must be signed in to change notification settings - Fork 2
Future Ideas
The purpose of this page is two-fold:
- to collect proposals for strategic ideas - major new features or developments of IBEX
- to collect suggestions, opinions, comments on those ideas
- pros v cons
- risks & benefits
- should we do them sooner or later?
- how might they be implemented?
- are there any pitfalls we need to avoid?, etc.
Please add your contributions to the relevant sections below. If you add a new strategic idea, please also add it to the table of Contents.
- Make
instrument\apps\epicsread-only on deployment - Moving to Eclipse v4
- Changing logging framework
- Parallel building with
make - Deploying individual IOCs
- EPICS 3.15
- Visual Studio 2015/2017
- Blockserver Protocol
- Mantid-IBEX Interactions
- Configs trump Globals.txt
- IBEX status board
- Location of SE Equipment
Making instrument\apps\epics read-only on deployment
We would like to take advantage of new features in CS-Studio 4. However, CS-Studio 4 requires the use of Eclipse v4. The current architecture of the IBEX client is not well-suited to make the process of migrating from Eclipse 3 to Eclipse 4 a straightforward process. We need to consider how best to achieve this migration.
Changing logging framework
Updating dependencies to allowing parallel building with make.
Deploying and updating individual IOCs (so static building of all of EPICS, copying support db files -> ioc)
Plan the migration from EPICS 3.14 -> EPICS 3.15.
- What is new in EPICS 3.15?
- Do we need to make any changes to our code to use EPICS 3.15?
As Visual Studio evolves, we need to keep up with new editions. We should consider moving to Visual Studio 2015, perhaps directly to Visual Studio 2017.
Changing client -> blockserver protocol (is JSON over CA getting a bit restrictive?)
We should work with Mantid and Instrument Scientists to find ways of using scripts to interact with both bits of software. A preliminary meeting came up with the following use cases:
- Taking data until a sufficient signal to noise ratio has been reached in a peak. (useful for POLARIS and express runs)
- Express runs are samples provided by other scientists they are put in the beam for an amount of time then results sent to then. Allowing a signal to noise to be specified would mean that the time taken would be correct sufficient for each sample. Making it either quicker so more samples could be done or making the results more useful by taking more time.
- Taking course scans across a transition then going back to take finer detail around the precise change
- Automating the ALF workflow, (take data and rotate sample until peaks are found). This would probably use 1 to get the data for the peak.
Would it not be helpful for the configuration macros to trump globals.txt? The settings would then be more local to the configuration rather than hidden in globals.txt. If the macros are not configured, look in globals.txt. Configurations could be copied from instrument to instrument, for example, a particular Mclennan rotation stage. I would argue the other way, globals.txt is a place that you put settings you never want to change. The should be shown in the gui but the should trump configurations. We should also answer at the same time whether configurations should trump config-configurations or not. I think it should components should add common settings to a configuration but it is the configuration you are loading.
With the potential of getting a large screen in the new office it would be useful from a support POV to see the status of all IBEX instruments at a glance. IMHO, during cycle, this would be more useful than build status'. Some information that this could show for each instrument (depending on presentability/space constraints):
- Is the Blockserver running?
- Is the DAE running?
- Is NICOS running?
- Is the dataweb running?
- What percentage of the blocks are disconnected/alarmed?
This would be a small project, ideal for a graduate/apprentice placement.
This is very much concept, and much refinement would be needed The idea would be to add some form of registration code to the st.cmd for each IOC that would verify which device was on the other end if at all possible (e.g. via serial numbers or IDs). There would then be a PV in an SE:IDN namespace which would mimic appropriate IN:NAME PVs - potentially where applicable (which is incredibly rare!) allowing write access to certain SE computers. This could also check for the connected device when starting the IOC, and inform SE/Computing that an instrument has tried starting an IOC for that piece of equipment, but it was missing, which would allow for requests to restart the IOC to be generated if the monitoring is vital (e.g. Helium Levels) - where and how this message would be sent is to be confirmed.