make a start

Author: rerpha

doc/specific_iocs/motors/Beckhoff.md

@@ -38,6 +38,8 @@ see [Beckhoff Commissioning](beckhoff/Beckhoff-commissioning)
 we no longer use [tcIOC](https://github.com/ISISComputingGroup/EPICS-tcIoc) for numerous reasons, the most important being the dependence on the unreliable `.tpy` file format which was preventing us from integrating the new motion standard library code. We now use [`AdsDriver`](https://github.com/ISISComputingGroup/adsDriver) in conjunction with [`TwincatMotor`](https://github.com/ISISComputingGroup/EPICS-TwincatMotor).**
 ```
 
+See [Beckhoff IOC Architecture](beckhoff/Beckhoff-architecture) for more information. 
+
 ### Beckhoff config area
 
 The config area contains a directory used for storing `.cmd` files for use with the `TC` IOC (in the same way as a galil or other motor controller). On an instrument it should look like this: `\instrument\apps\EPICS\support\motorExtensions\master\settings\<instname>\twincat\`. 

doc/specific_iocs/motors/beckhoff/Beckhoff-architecture.md

@@ -0,0 +1,8 @@
+# Beckhoff IOC Architecture
+
+We have an EPICS motor record implementation which interfaces some intermediate PVs, spun up by AdsDriver and [The Beckhoff Motor Extensions](https://github.com/ISISComputingGroup/EPICS-motorExtensions/tree/master/beckhoffApp)
+
+This was originally done so we could drop-in [`AdsDriver`](https://github.com/ISISComputingGroup/adsDriver) in place of another ADS EPICS module (`tcIOC`) and debug EPICS to ADS more easily by bypassing the motor modules if we saw a comms issue. In future, we could build [`AdsDriver`](https://github.com/ISISComputingGroup/adsDriver) into our motor module directly so we avoid this extra step. 
+
+This means that the EPICS motor record is essentially doing `dbgf` and `dbpf` to read and write to these PVs respectively, rather than just setting something on a device like a normal motion controller like a [Mclennan] or [Galil]. 
+