Skip to content

Script Generator

kjwoodsISIS edited this page Sep 10, 2018 · 20 revisions

The purpose of this page is to collect requirements, ideas, suggestions, etc. for a Script Generator for IBEX. The requirements are listed in no particular order. Some of the requirements, ideas, suggestions may conflict with each other - that's fine, this is just a collection facility. When the time comes to create the Script Generator, we will review these ideas, identify a selection of these ideas to implement and turn them into user stories for implementation. If there are inconsistencies or conflicts, we'll resolve them when we make the selection (Note: resolution may mean reaching a compromise between two inconsistent requirements or dropping one in favour of another).

Script Generator Requirements

  1. Script Generator should be capable of working offline (i.e. stand-alone, remotely from IBEX). This has several advantages:
    1. the Script Generator can be given to visiting scientists to prepare their own scripts ahead of their visit to ISIS. This helps maximise the use of beam time (i.e. there are no delays while users write scripts).
    2. a separate Script Generator does not need to run on the IBEX control PC. This means that the IBEX control PC is not tied up whilst someone is writing scripts.
  2. Script Generator could be integrated with IBEX. This has the advantage of being able to use IBEX configs (to get information about blocks) and local genie_python libraries (to use instrument specific methods).
    1. a tightly integrated Script Generator would not be capable of running stand-alone (conflicts with the above requirement). Perhaps there is a looser degree of integration that could satisfy both requirements.
  3. Implementing the Script Generator as a web application might be one approach to creating a solution that satisfies the two previous requirements.
  4. The Script Generator should be capable of submitting scripts to the IBEX ScriptServer.
    1. this capability should only be available to users in the instrument control cabin (i.e. it should not be possible to submit scripts from remote locations).
    2. once a script has been sent from the Script Generator to the IBEX ScriptServer any modification (e.g. on-the-fly editing of the script, adjusting its position in the queue) should be done via IBEX ScriptServer.
  5. The Script Generator should allow the user to save a script to file.
  6. The Script Generator should allow the user to load a previously saved script.
  7. The Script Generator should allow the user to set a run title
  8. The Script Generator should allow the user to switch between detector & monitor type measurements (is this the same as switching between transmission & reflection measurements?).
  9. The Script Generator should be able to estimate how long it will take to execute a script (maybe this is functionality that really ought to belong to the ScriptServer?).
  10. The following comments apply to Muon instruments:
    1. The vast majority of muon experiments involve looping over temperature and/or magnetic field.

    2. The Muon group are aware that MkScript (the old Script Generator) allows you to create nested loops, but they tend not to use this capability.

    3. Muon group tends to create scripts at the instrument control PC (i.e. they don't work offline)

    4. Muon group often works in the following mode:

      1. start a new run (i.e. BEGIN)
      2. run a script
      3. run another script
      4. ...
      5. stop the run (i.e. END)
    5. The ability to run custom commands is handy. In fact, the following (logical) construction would be useful, if it could be supported:

      my_custom_scan_setup_command()
      for (min < scan_variable < max) {
      set (scan_variable)
      make_measurement()
      next (scan_variable)
      } my_custom_scan_close_command()

    6. It would be nice if the scan loop (above) could be condensed to a single line (i.e. wrapped up in a general scan command).

      1. it could be difficult to unroll the loop inside such a command. Maybe this is acceptable because it could make things easier for end-users (who may lack programming skills).
    7. linear and log/exponential step sizes in scans would be useful. For example:

      • linear: 5, 10, 15, 20, ...
      • log/exponential: 1000, 100, 10, 1, ... or 2, 4, 8, 16, ...
    8. The MACS system allows users to change comments

    9. The MACS system allows users to change "metadata"

    10. The MACS system allows users to select variables from a list of block names (or, at least, their MACS equivalent).

    11. It would be nice if the Script Generator knew a little about device capabilities (e.g. 100K is a ridiculous temperature for a dilution fridge).

Clone this wiki locally