Merge branch 'GRYALL-👋SECI' of https://github.com/IsisComputingGroup/ibex_developers_manual into GRYALL-👋SECI

Author: Tom-Willemsen

doc/processes/instrument_details/MUON-Front-End-Instrument-Details.md

@@ -23,7 +23,3 @@ The system is due on line September 2016.
 {#muonfe_noteMomentumSlits}
 ## Barndoors and Momentum Slits ##
 The barn doors and momentum slits control the muon beam delivered to the 3 muon instruments: HIFI, muSR and EMU.  The control of these devices is described on the [Barndoors & Momentum-Slits](/specific_iocs/motor_extensions/jaws/Barndoors-and-Momentum-Slits-on-MUON-Front-End) page.
-
-{#muonfe_noteMotion}
-##### Note: Motion #####
-There is a project relating to the motion on the South Side Muons in progress, this information may be out of date

doc/processes/instrument_details/POLARIS-Instrument-Details.md

@@ -106,7 +106,3 @@ An evacuated furnace cell for measuring resistivity.  Controlled by Eurotherms a
 {#polaris_noteHVCentreStick}
 ##### Note: CS155 Centre Stick #####
 Not possible to control this device via software.  It connects to the [Spellman](#polaris_noteSpellman) HV-PS.
-
-s currently used on POLARIS here.
-
-## POLARIS Notes ##

doc/processes/instrument_details/SXD-Instrument-Details.md

@@ -65,7 +65,7 @@ See also tickets [#1826](https://github.com/ISISComputingGroup/IBEX/issues/1826)
 
 {#sxd_note-kammrath-and-weiss}
 ##### Note: Kammrath and Weiss #####
-1. The Kammrath-Weiss tensile stress rig is controlled from a dedicated laptop running the manufacturer's software.  IBEX communicates with the PC to send/read values to/from the manufacturer's software using `LVREMOTE`.
+1. The Kammrath-Weiss tensile stress rig is controlled from a dedicated laptop running the manufacturer's software.  IBEX communicates with the PC to send/read values to/from the manufacturer's software using [`LVREMOTE`](https://github.com/ISISComputingGroup/EPICS-LVREMOTE).
 1. [Kammrath and Weiss](https://www.kammrath-weiss.com/en/tensile-compression-modules/).<br>
    * See also ticket [#2681](https://github.com/ISISComputingGroup/IBEX/issues/2681)
 

doc/specific_iocs/cryogenics/Triton.md

@@ -4,7 +4,7 @@
 
 Technically, "Triton" refers to the gas handling apparatus. This is what IBEX talks to. When setting up a triton, scientists may refer to it as a "Kelvinox". This is the technical name for the dilution insert, which is controlled by the triton gas handling apparatus.
 
-To avoid confusion: all dilution fridges currently in use at ISIS are controlled by Triton gas handling systems, with one exception: the ICE fridge used on the muon beamlines.
+To avoid confusion: all dilution fridges currently in use at ISIS are controlled by Triton gas handling systems.
 
 ## Connection
 

doc/specific_iocs/dae/Experimental-Runs.md

@@ -36,9 +36,7 @@ This is from a problem see on IRIS.
 
 ## Experiment stuck in `Waiting` state after beginning a run
 
-There is now a new PV that you can write to from IBEX to force a resync of run control
-
-    caput %MYPVPREFIX%CS:RC:SYNC:SP 1
+There is now a new PV that you can write to from IBEX to [force a resync of run control](system_components/Run-control.html#troubleshooting)
 
 ## Experimental Files not being Archived and so not Appearing in the Journal
 
@@ -51,4 +49,4 @@ If this has failed:
 To archive files end a run.
 Should you have runs ending and read only files, then check on the archive in `INST\instrument\logs\cycle_nn_n`, the log files there will provide some extra information. If the file `exception_copy.log` doesn't exist, or hasn't been updated for a long time, then the script above isn't running the code to clean up old files, or it has hung.
 
-* Problems with the end of run script can be diagnosed by looking at the `post_command_<day>.log'` file in the ICP logs area on the instrument. The ICP log files (in the same area) may also be instructive to check for other issues - for example, if the files are not being set read-only.
+* Problems with the end of run script can be diagnosed by looking at the `post_command_<day>.log` file in the ICP logs area on the instrument. The ICP log files (in the same area) may also be instructive to check for other issues - for example, if the files are not being set read-only.

doc/systems/external/Beam-Status,-Shutter,-accelerator-and-moderator-information.md

@@ -69,7 +69,7 @@ If something does appear to have gone wrong with this service (e.g. values are n
 
 A "Beam current" block may not be showing the accelerator beam current, it may be showing the effective beam current from the DAE. Blocks read from the accelerator will all be referring to global PV names starting AC: and TG: so if the block refers to an IN: it will be something on the local instrument. The DAE:BEAMCURRENT value is the effective DAE beam current, but if the dae is not counting (SETUP, WAITING, PAUSED) then this value will be zero. If the DAE is vetoing this value will vary between 0 and something else depending on what % of frames are being vetoed. If the chopper is being run at a lower frequency, the value will be lower too as the DAE is seeing less pulses and hence a lower effective beam current.    
 
-## Value shows zero in IBEX but non-zero with `db_access` on MERECKX
+## Value shows zero in IBEX but non-zero with `db_access` on MERCKX
 
 If the third column in `params.txt` contains a `z` (e.g. `tz`) then this means that the parameter will be monitored for a stale (non updating) state and if this is detected it will send 0 as the value to IBEX. At time of writing this had only been requested for the decoupled methane, sending 0 when the value is uncertain means they will go into a WAITING state as they run control on methane temperature and it is important that they are not collecting data when a methane charge-change happens. In future the value could be EPICS alarmed, but for SECI instruments we needed to send 0.