Merge remote-tracking branch 'wiki/master' into docs

Author: Tom-Willemsen

.gitattributes

@@ -0,0 +1,4 @@
+* text=auto
+*.md text
+*.rst text
+*.rest text

.gitignore

@@ -0,0 +1 @@
+.idea/*

2T-3D-Vector-magnet.md

@@ -0,0 +1,69 @@
+> [Wiki](Home) > [The Backend System](The-Backend-System) > [Specific Device IOC](Specific-Device-IOC) > [Cryogenics](Cryogenics) > [2T 3D Vector Magnet](2T-3D-Vector-magnet)
+
+# Scientific Magnetics 2T 3D Vector Magnet
+
+The system comprises: 
+* Temperature controllers (optional Lakeshore 336)
+* Temperature monitor (Cryocon 14, Ethernet device)
+* 3 power supplies (one for each axis)
+* Helium level gauge
+* Rotation stage (controlled separately by a Galil axis)
+* Motorised needle valve (controlled by Galil analogue output, or Thurlby-Thandar EX355P benchtop PSU)
+
+### Large log files
+
+See https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/LabVIEW-errors for mitigations - this is a known labview issue/bug.
+
+### VI
+
+There is a manufacturer supplied VI and our own LVDCOM IOC.  There are two versions of the manufacturer's VI and both are stored in SourceSafe at the following location: `\LabVIEW Modules\Drivers\Scientific Instruments\3D Magnet\Source Code\`.  One VI has been used on LARMOR and ZOOM and uses the TTi PSU for needle valve control, and the other on POLREF when an analogue output from the Galil was used.  See below for more information.
+
+The settings for the manufacturer VI are stored (and can be edited) in the plain text file: `settings.txt`.  The COM ports are defined in the first section of the file, but it shouldn't be necessary to change these.
+
+### Ethernet Switch
+
+The magnet control rack has a small Ethernet switch inside to provide network access to the Lakeshore 336 and MOXA (see below).  This will need to be connected to the ISIS network to enable remote control of the magnet.
+
+### MOXA NPort
+
+The rack has its own dedicated MOXA NPort 5616 due to the number of devices it uses.  When the system is moved between instruments, this MOXA is added to the NPort configuration on the local control machine and its ports assigned to COM101-COM116 (so as not to interfere with common equipment).  The control machine IP address should be added to the "accessible IPs list" of the MOXA via the administration webpage (and subsequently removed when the magnet is finished with).  Currently, the settings of the dedicated MOXA are:
+
+IP address : DHCP reserved and visible on front screen when connected to ISIS network
+
+* Port 1 / COM101 : SMC X PSU
+* Port 2 / COM102 : SMC Y PSU
+* Port 3 / COM103 : SMC Z PSU
+* Port 4 / COM104 : Cryocon 32 temperature controller
+* Port 5 / COM105 : Helium level meter
+* Port 6 / COM106 : TTi EX355P PSU (when required for needle valve control)
+
+### Rotation Stage
+
+Standard unit controlled by a Galil axis on both SECI and IBEX instruments.  Details:
+
+* +- 370 degrees
+* Motor with encoder
+* **_No_** limit switches - Do **not** rotate more than 360 degrees too many times or cables will be damaged.
+* Home position defined by an index pulse on the encoder
+
+When this magnet was last installed on ZOOM, one of the slit axes was used for the rotation stage as there are no spare cables in the sample area.  A batch file exists in the `configurations\galil` directory of the `settings` area to set the required PV values for the axis (edit if different axis is used), and a corresponding batch file in the `user\users\ZOOM` directory of the 'U-drive' will reinstate the settings for the slit axis when the magnet rotation stage is removed.
+
+**NB** There are plans to install additional cabling into the ZOOM sample area to connect extra motion stages, so this _borrowing_ of an axis may not be needed any longer.  Check before altering PV values.
+
+### Needle Valve
+
+This is a motorised valve which is controlled via an analogue output from a Galil on SECI instruments (POLREF at least) and a Thurlby-Thandar Instruments EX355P benchtop PSU on IBEX instruments (LARMOR and ZOOM at least).  There are two front panel VIs for this purpose, one for each scenario: `Vector-control-v16isis.vi` for the TTi-EX355P controlled valve and `Vector-control-v16isis-Galil-Valve.vi` for analogue output controlled valve.  Both are in the SourceSafe location mentioned above: `\LabVIEW Modules\Drivers\Scientific Instruments\3D Magnet\Source Code\`.
+
+If the PSU is to be used, first it will need to be configured via its own setup VI located in `\LabVIEW Modules\Drivers\Thurlby EX355P\TH EX355P - System Functions.llb\TH EX355P - Setup Dialog.vi`, with the port from the `settings.txt` file mentioned above.  It will then be possible to check the communication to the PSU via its own front panel VI here: `\LabVIEW Modules\Drivers\Thurlby EX355P\TH EX355P - System Functions.llb\TH EX355P - Front Panel 1.vi`.  This VI and the main magnet VI cannot be run simultaneously.
+
+### Lakeshore 336 Temperature Controller
+
+The Lakeshore 336 is an Ethernet device and should therefore be connected to the switch in the magnet control rack.  Its hostname can be found in a settings menu accessed from the front panel.  Communications can be checked by pinging the hostname, or more thoroughly by configuring its VI or IOC/OPI.
+
+### Miscellaneous Information
+
+* The system takes approximately 3 days to reach base temperature
+
+### Schematic of system
+
+![Schematic of system](https://github.com/ISISComputingGroup/ibex_developers_manual/blob/master/images/Scientific%20Magnetics%203D%20Vector%20Magnet%20System.png)

3HeFridgeOps.png

@@ -0,0 +1,34 @@
+## ALF Goniometer
+
+The ALF Goniometer is a 6-axis goniometer. There is no specific logic required in controlling it, all that is required is the standard movement across the whole range with appropriate encoder/motor counts, and an ability to home all axes to a known position.
+
+### Axes Conventions
+The numbering of the axes below corresponds to the number of the axes on the [annotated diagram](http://www.facilities.rl.ac.uk/isis/computing/ICPdiscussions/ALF/ALF_Gonio_annotated.png) of the ALF goniometer.
+
+1. `Z-axis`
+1. `theta` (a.k.a. `Rrot`)
+1. `Cy` (according to `galil.ini` for LabVIEW control)
+1. `Cx` (according to `galil.ini` for LabVIEW control)
+1. `Rlower`
+1. `Rupper` 
+
+### Axes & Motors
+The table below defines how the goniometer axes are connected to motors, and the motor setup data needed: 
+
+Axis Name | `Rupper` | `Rlower` | `Cx` | `Cy` | `theta` | `Z`
+------------ | ------------- | ------------- | ------------- | ------------- | ------------- | -------------
+Axis letter (crate) | F | E | D | C | B | A
+Units | deg | deg | mm | mm | deg | mm
+Acceleration | 4000 | 4000 | 4000 | 4000 | 8192 | 2048
+Deceleration | 4000 | 4000 | 4000 | 4000 | 8192 | 2048
+Speed | 700 | 2000 | 2000 | 2000 | 2048 | 4096
+LabVIEW Motor Steps per Unit | 1358 | 1719 | 640 | 640 | 756 | 641
+Motor Type | Reverse<br>Active<br>High | Reverse<br>Active<br>High | Reverse<br>Active<br>High | Forward<br>Active<br>High | Forward<br>Active<br>High | Forward<br>Active<br>High
+Encoder Present | Yes | Yes | Yes | Yes | Yes | Yes
+LabVIEW Encoder Steps per Unit | 842 | 1074 | 400 | 400 | 472 | 400
+Encoder Type | Normal Quadrature | Normal Quadrature | Normal Quadrature | Reverse Quadrature | Normal Quadrature | Reverse Quadrature
+Home Method | Forward<br>Limit | Forward<br>Limit | Forward<br>Limit | Forward<br>Limit | None<br>Available | Reverse<br>Limit
+Home Value | 25.4 | 27.6 | 55.6 | 57.922 | N/A | 0
+Max from Home | 25.4 | 27.6 | 55.6 | 57.5 | N/A | 200
+Min from Home | -25.4 | -27.6 | -55.6 | -57.5 | N/A | 0
+Max Travel | 40 | 80 | 100 | 100 | 360 | 200 

ALF-Goniometer-Axes.md

@@ -0,0 +1,43 @@
+## ALF
+
+This page collects information that will be useful for the implementation of the new control system on ALF.
+
+### Background & Timeline
+The ​ALF web page describes the background to the instrument.
+
+### GUI
+ALF will use the IBEX control system.
+
+### ALF Equipment
+The equipment listed below is used on ALF. Please add new information (e.g. new items of equipment, new notes, information about drivers, etc. to this table). 
+
+Manufacturer | Model | Type | Connection | Driver | Notes
+------------ | ------------- | ------------- | ------------- | ------------- | -------------------------------------------
+ISIS | DAE 2 | Detector Electronics | Ethernet | [#218](https://github.com/ISISComputingGroup/IBEX/issues/218) |[see DAE note](#noteDAE)
+[Galil](http://www.galilmc.com/) | [DMC2280](http://www.galilmc.com/products/dmc-22x0.php) | Motion Controller | Ethernet | EPICS |[see Galil note](#noteGalil)
+ |  | JAWS | | | [#179](https://github.com/ISISComputingGroup/IBEX/issues/179), [#180](https://github.com/ISISComputingGroup/IBEX/issues/180) |[see Jaws note](#noteJaws)
+unknown | 6-axis | Goniometer |  |  |[see Goniometer note](#noteGoniometer)
+
+<a name="noteDAE"></a>
+##### Note: DAE #####
+Location: Screened Room<br>
+DAE-2
+
+<a name="noteGalil"></a>
+##### Note: Galil #####
+Model: [DMC2280](http://www.galilmc.com/products/dmc-22x0.php).<br>
+Photograph of [ALF Galil Crate](http://www.facilities.rl.ac.uk/isis/computing/ICPdiscussions/ALF/ALF_Galil_Crate.jpg).<br>
+Note that GALIL_02 had trouble communicating asynchronously so Freddie switched it to synchronous (done by making the third argument of `GalilCreateController("Galil", "$(GALILADDR02)", 20)` negative in `galil2.cmd`).
+
+<a name="noteJaws"></a>
+##### Note: Jaws #####
+Location: various<br>
+Driven by [Galils](#noteGalil).<br>
+Photograph of [ALF Slits/Jaws](http://www.facilities.rl.ac.uk/isis/computing/ICPdiscussions/ALF/ALF_Slits.jpg).
+
+<a name="noteGoniometer"></a>
+##### Note: Goniometer #####
+Model: 6-axis Goniometer, unknown model & manufacturer.<br>
+Driven by [Galils](#noteGalil).<br>
+See [ALF Goniometer Axes](https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/ALF-Goniometer-Axes) for details of how the Goniometer is set up and configured.<br>
+Photographs of [ALF Goniometer (1)](http://www.facilities.rl.ac.uk/isis/computing/ICPdiscussions/ALF/ALF_Goniometer_1.jpg) and [ALF Goniometer (2)](http://www.facilities.rl.ac.uk/isis/computing/ICPdiscussions/ALF/ALF_Goniometer_2.jpg).

ALF-Instrument-Details.md

@@ -0,0 +1,98 @@
+For asyn based drivers, such as stream device, additional information printing can be enabled on a port via commands from the ioc shell. The commands let you see what bytes are being sent and received, and also the flow of control/logic.
+
+## Print commands and responses to screen
+
+The two commands you need are:
+
+```
+asynSetTraceIOMask("L0", -1, 0x2)
+asynSetTraceMask("L0", -1, 0x9)
+```
+
+Note: if the device's messages are longer than 80 characters, you should increase the buffer size by also running:
+
+```
+asynSetTraceIOTruncateSize("L0", -1, 1024)
+```
+
+Where 1024 is the maximum message length you expect - could be increased if your device requires it.
+
+to turn off use
+```
+asynSetTraceMask("L0", -1, 0x1)
+```
+
+## ASYN trace mask
+
+This determines what you see and is set to 0x1 (ASYN_TRACE_ERROR) by default. The following additional values
+can be ORed together and optionally set:
+
+* `0x1`: ASYN_TRACE_ERROR - Print error messages (default)
+* `0x2`: ASYN_TRACEIO_DEVICE - Device support reports I/O activity.
+* `0x4`: ASYN_TRACEIO_FILTER - Any layer between device support and the low level driver e.g. asyn interpose functions 
+* `0x8`: ASYN_TRACEIO_DRIVER - Low level driver reports I/O activity
+* `0x10`: ASYN_TRACE_FLOW - Report logic flow
+* `0x20`: ASYN_TRACE_WARNING - Report warnings, i.e. conditions between ASYN_TRACE_ERROR and ASYN_TRACE_FLOW
+
+If L0 if your asyn port, then
+
+`asynSetTraceMask("L0",-1,0x9)`
+
+will enable ASYN_TRACE_ERROR and ASYN_TRACEIO_DRIVER for all addresses (-1) on port "L0" which is a good place to start for debugging. You may also want to use ASYN_TRACE_FLOW but this can print a bit too much depending on the driver and you may loose your IO device messages amongst them. If you want to try this separately then e.g. 
+
+`asynSetTraceMask("L0",0,0x11)`
+
+will enable ASYN_TRACE_ERROR and ASYN_TRACE_FLOW on port "L0" but just for address 0.
+
+To see output of interpose functions such as `asynInterposeThrottle` add `0x4`, so `0x9` become `0xD` for example
+
+## ASYN traceIO mask
+
+If  ASYN_TRACEIO_DRIVER  has been enabled, then this mask determines the format of the output produced when reporting I/O. The default is ASYN_TRACEIO_NODATA so the count of bytes transferred is reported, but the bytes themselves are not printed.
+
+* `0x0` (ASYN_TRACEIO_NODATA) - Print count of bytes transferred, but not bytes themselves
+* `0x1`  (ASYN_TRACEIO_ASCII)  - Print bytes with a "%s" style format
+* `0x2`  (ASYN_TRACEIO_ESCAPE) - Calls `epicsStrPrintEscaped()` to display bytes
+* `0x4`  (ASYN_TRACEIO_HEX)    - Print hexadecimal values of each byte with " %2.2x"
+
+So
+
+`asynSetTraceIOMask("L0",-1,0x2)`
+
+would enable ASYN_TRACEIO_ESCAPE style printing of all bytes read/written by the asyn driver via port "L0", which is a good place to start
+
+## Additional trace information
+
+This mask determines the information printed at the start of each message above. The default is `ASYN_TRACEINFO_TIME` which just adds a timestamp, normally this is sufficient but it can be changed by calling  `asynSetTraceInfoMask`  with a combination of flags:
+
+* `0x1`  `(ASYN_TRACEINFO_TIME)`   prints the date and time of the message (default)
+* `0x2`  `(ASYN_TRACEINFO_PORT)`   prints `[port,addr,reason]`, where port is the port name, `addr` is the asyn address, and reason is pasynUser->reason. These are the 3 pieces of "addressing" information in asyn.
+* `0x4`  `(ASYN_TRACEINFO_SOURCE)` prints the file name and line number, i.e. `[__FILE__,__LINE__]` where the asynPrint or asynPrintIO statement occurs.
+* `0x8`  `(ASYN_TRACEINFO_THREAD)`  prints the thread name, thread ID and thread priority, i.e. `[epicsThreadGetNameSelf(), epicsThreadGetIdSelf(), epicsThreadGetPrioritySelf()]`.
+
+e.g. to print time and port details at start of each message
+
+`asynSetTraceInfoMask("L0",-1,0x3)` 
+
+## Logging to file
+
+By default the trace output is sent to the epics error log (which by default echoes to console too), but it can instead be sent to file e.g.
+
+`asynSetTraceFile("L0",-1,"temp.log")`
+
+# Getting (VERY VERBOSE) output from stream device.
+
+In your `st.cmd`, or at the EPICS prompt from a console session, use:
+
+`var streamDebug 1`
+
+This will turn on debug logging from stream device which is very verbose.
+
+# Seeing all channel access put requests to the IOC
+
+In your `st.cmd`, or at the EPICS prompt from a console session, use:
+
+`var caPutLogToConsole 1`
+
+This will log all details of `caput` etc to the ioc to console using the `caPutLog` mechanism.
+