-
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 - Changing logging framework
- Parallel building with
make - Deploying individual IOCs
- Visual Studio 2015/2017
- Blockserver Protocol
- Mantid-IBEX Interactions
- Configs trump Globals.txt
- IBEX status board
- Location of SE Equipment
- Script Generator
- Build Synoptics from modules
- Web Dashboard improvements
- Better integration with scheduler
Making instrument\apps\epics read-only on deployment
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)
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.
The IBEX status board that is visible on the big screen in the office currently only displays the status of the blockserver for each instrument. This could be developed further to show additional information for each instrument. Some ideas:
- Is the DAE running?
- Is NICOS running?
- Is the dataweb running?
- What percentage of the blocks are disconnected/alarmed?
- Use a Raspberry Pi from the office to drive it (instead of the screen's built in browser)
Suitable project for graduate/apprentice placements.
There has been interest from the Motors group in regards to a dashboard visualizing the status of all motors in ISIS, similar to the IBEX instrument overview. This would first require clarifying the requirements with the motors group (i.e. what type of events/conditions should be flagged up).
Suitable project for graduate/apprentice placements.
We currently have this document to describe the high level design of the IBEX system. It would be useful (e.g. for the induction of new starters) to make this more accessible by turning it into an interactive application, where you can iteratively add system components starting with the core client/server/CA architecture, and see descriptions of what they are / how they interact with the rest of the system (simulating Dom's Famous Introduction to IBEX Lecture ™).
Suitable project for work experience student or apprentice placements.
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.
In essence, make the management of synoptics more like that of the configurations. One advantage would be the ability to have a common "base" synoptic containing permanent beamline equipment, which could then be included in the synoptics specific to other configurations. This would make editing and updating much simpler should anything change in the base synoptic.
One possibility might be to associate a synoptic component with a configuration component, so that when the overall configuration containing said component is loaded, the sub-section of the synoptic is automatically added to the overall synoptic. e.g. when a Eurotherm component is loaded, the Eurotherm icon is added to the synoptic (but its position can still be altered to suit the instrument's layout).
A suggestion is to have beamline/base equipment on one tab in the synoptic perspective, and SE equipment specific to the loaded configuration on another. Or both tabs or sections could be shown next to each other if space allows and is appropriate to the instrument layout.
There is much scope for improvement in the web dashboard in terms of functionality and presentation. This work could include:
- Using bootstrap to make the dashboard prettier & responsive to different screen sizes with little effort
- Using WebEpics to monitor PVs
- Providing data visualisation (e.g. using Grafana or nivo)
- There is a number of tickets related to the web dashboard in the backlog.
Since performance is an essential requirement, it should be ensured that a low-bandwidth version of the web dashboard remains available.
We could get information about what devices are about to be placed on an instrument from the scheduler. This can be used to give a user some suggestions on which IOCs/configs they probably want to be running.