From bda119ca62b3923e5b03f240b409e57956b5f933 Mon Sep 17 00:00:00 2001 From: Jack Harper Date: Fri, 2 May 2025 10:54:02 +0100 Subject: [PATCH] Improve beckhoff/twincat documentation --- doc/specific_iocs/motors/Beckhoff.md | 12 ++++++--- doc/specific_iocs/motors/beckhoff/tcIOC.md | 30 ---------------------- 2 files changed, 9 insertions(+), 33 deletions(-) delete mode 100644 doc/specific_iocs/motors/beckhoff/tcIOC.md diff --git a/doc/specific_iocs/motors/Beckhoff.md b/doc/specific_iocs/motors/Beckhoff.md index 961dbcfc8..80aeafeb3 100644 --- a/doc/specific_iocs/motors/Beckhoff.md +++ b/doc/specific_iocs/motors/Beckhoff.md @@ -18,7 +18,8 @@ Current Beckhoff installations are: ## Code on the controller -Unlike most other devices (except the Galil) the computing group has some oversight over the PLC code written on the controller. It has been agreed that this code will mostly be written by IDD, with oversight from computing to guide good programming practices, assist in debugging etc. The ISIS first version of this code is stored [here](https://github.com/ISISComputingGroup/BeckhoffPLCCode/) however this is now not used and going forward the code is written in collaboration with the ESS and stored [here](https://bitbucket.org/europeanspallationsource/tc_generic_structure/src/master/). +Unlike most other devices (except the Galil) the computing group has some oversight over the PLC code written on the controller. It has been agreed that this code will mostly be written by IDD, with oversight from computing to guide good programming practices, assist in debugging etc. Code running on the PLC lives [here](https://github.com/ISIS-Motion-Control). + ### Documentation - [Axis and Controller Commissioning Guide](https://stfc365.sharepoint.com/:w:/s/ISISMechatronics/Ee_aMxb5CF1Dlz-NUGW3OVgB0K7vQjXXwZDwSl5DSHN48w?e=GjqNEb&isSPOFile=1) document describing setting up a controller and TwinCAT solution for a new system and configuring real and virtual axes within TwinCAT environment. @@ -32,16 +33,21 @@ See [Beckhoff testing](beckhoff/Beckhoff-testing) see [Beckhoff Commissioning](beckhoff/Beckhoff-commissioning) ## IOC + +```{note} +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).** +``` + ### 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\settings\config\\configurations\twincat\`. +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\\twincat\`. ### Quirks +- The main quirk with the way we interact with Beckhoffs is that we use [`AdsDriver`](https://github.com/ISISComputingGroup/adsDriver) to spin up lots of intermediate PVs, in which our motor record uses with `dbpf` and `dbgf` instead of directly communicating with the device. In the future, we could integrate [`AdsDriver`](https://github.com/ISISComputingGroup/adsDriver) within our motor record for a more standard approach. - The Beckhoff uses whether it has been homed to set `ATHM` in the motor record, rather than just using the raw 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 -- Axes marked with `(V)` are virtual axes. ## Updating diff --git a/doc/specific_iocs/motors/beckhoff/tcIOC.md b/doc/specific_iocs/motors/beckhoff/tcIOC.md deleted file mode 100644 index 36661f7fe..000000000 --- a/doc/specific_iocs/motors/beckhoff/tcIOC.md +++ /dev/null @@ -1,30 +0,0 @@ -# tcIOC - -```{note} -we no longer use 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` in conjunction with `TwincatMotor`.** -``` - -This IOC was originally written at LIGO and is in a stable state. The original version from tcIOC was targeted at the use of Beckhoffs as generic PLCs and had no specific motion support. It constructs db records by examining the built PLC project files and communicates with it using ADS (Beckhoff's own protocol). More detail can be found at https://github.com/ISISComputingGroup/EPICS-tcIoc. - -## Making PLC variables visible - -tcIOC uses OPC tags to know which PLC variables to expose as PVs. These OPC tags must be specified in the structured text code as comments, the format of which is specified in the [Beckhoff documentation](https://infosys.beckhoff.com/english.php?content=../content/1033/tcopcuaserver/117093590390367755.html&id=) (note that tcIOC uses the `*.tpy` TwinCAT 2 style). TwinCAT XAE is very particular about the format of these comments, they must be immediately after the variable and not preceded by any other comments. If you are not sure if they have been added correctly open the built `*.tpy` file and search for `OPC`, which should be next to your variable in the XML structure. As mentioned in the linked documentation specifying a variable as visible in OPC is recursive e.g. if you set something with a complex type as visible all the variables that make up this type will also be visible unless explicitly set to not be in the structure definition. Additionally there are other [OPC properties](https://infosys.beckhoff.com/english.php?content=../content/1033/tf6120_tc3_opcda/80189195.html&id=) that you can set in the structured text. The only one of these we currently use is `OPC_PROP[0005]` to control if something is read/write. Further testing is needed to see which other of these properties could be useful. - -## Motion Support - -![Overview](tcIOC_motor_support.png) - -We added motor support to tcIOC so that we could use it to control motors in the usual way. As a first prototype implementation the motor support is a Model 3 motor driver that has the structured text variables of interest hardcoded into the driver. tcIOC will convert these to PVs and the driver will talk to them over channel access. This was chosen as the basic implementation that would be quickest to implement and works well, however there are a number of improvements that could be made: - -* If tcIOC was converted to an `asyn` driver then the motor could talk to this asyn port rather than communicate across CA -* If the interesting variables in the PLC code change name so must the IOC, we could get around this by tagging in the comments of the PLC code with which variables are the interesting ones -* The number of axes is hardcoded within the IOC this can be solved by tcIOC creating the required number of motor records when it parses the `.tpy` file - -## Releasing the IOC - -Currently the IOC is not in the normal EPICS release build as it requires VS 2010. To deploy it to an instrument you will need to copy from `build_area_on_share\EPICS\newbuildtest\*\EPICS\support\tcIoc\master` and `build_area_on_share\EPICS\newbuildtest\*\EPICS\ioc\master\TWINCAT`. If you're deploying this on CRISP you can test it by running the TWINCAT IOC with appropriate settings (see globals.txt) then confirming that `MOT:MTR0701.RBV` has a realistic value. - -## Troubleshooting - -### The IOC reads from the PLC but does not reliably write -Reduce the scan rate of the IOC, the `tcSetScanRate` command in the IOC is responsible for setting this. It appears that if there are many variables to read the driver will spend all it's time reading and will not get round to writing, it does not produce an error when this happens. \ No newline at end of file