Beckhoff IOC Architecture

TC is the IOC responsible for communication with Beckhoff PLCs at ISIS.

At IOC startup, it uses a command to get the number of motion axes. Note that this may be more than 8, in which case we have to use some logic to alias MTR0109 to MTR0201 so we can display it in the IBEX GUI’s table of motors.

We have an EPICS motor record implementation which TC uses that interfaces some intermediate PVs, spun up at runtime per-axis by AdsDriver using the Beckhoff Motor Extensions .db files.

This was originally done so we could drop in AdsDriver in place of another ADS EPICS module (tcIOC) and debug EPICS to ADS communications more easily by bypassing the motor modules if we saw an issue. In the future, we could build AdsDriver calls into our motor module directly so we avoid this extra step. We still need to use AdsDriver to spin up extra, instrument-specific PVs - Arbitrary fields

This means that the EPICS motor record is essentially doing dbgf and dbpf as documented in the EPICS IOC Test Facilities respectively to read and write to these PVs, rather than just setting something on a device like a normal motion controller like a McLennan or Galil.

TC also does some things “outside” the motor record such as forwarding the device’s velocities to the motor record. This is because the PLC is commissioned with a sensible velocity in most cases and we don’t want to overwrite this information, and it may change on the PLC due to safety system overloads and so on. We also do the same for axis description (to the .DESC field) - see Fields that aren’t automatically populated.

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\.

Quirks

  • The Beckhoff uses whether it has been homed to set ATHM in the motor record, rather than just using the raw datum switch. This is different to a Galil which uses the datum switch.

  • The “limits” shown on the table of motors summary view are not necessarily actual physical limit switches being engaged - the Beckhoff has more complex rules on whether motors can move back or forwards.

  • The motor record sets UEIP (use encoder if present) to false to avoid using the encoder resolution to scale values. We have no control over whether to use or not use an encoder with a Beckhoff, the internal code handles it. As well as this, we do not retry (.RCNT and .RDBD fields of the motor record) as the motion control loop is handled by the PLC.

  • Some Beckhoff axes are virtual as the PLC can handle kinematics, for example many of the INTER axes. There isn’t currently a way to differentiate real and virtual axes other than marking them with v - in their .DESC fields.