-
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\epics
read-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
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 usecases:
- Taking data until a sufficient signal to noise ratio has been reached in a peak. (useful for POLARIS and express runs)
- 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)
Would it not make more sense if the configuration macros trumped globals.txt?