-
Notifications
You must be signed in to change notification settings - Fork 2
Beckhoff testing
Wiki > The Backend System > IOCs > Motor IOCs > Beckhoff > Beckhoff testing
Note: you may need to disable some windows features, such as Hyper-V, Windows Hypervisor Platform etc.
For reference, here is a working setup and its features:

Beckhoff code can be run as a simulated system on a developer machine by doing the following:
- Download and install TwinCAT 3 XAE more information can be found about this here (click TwinCAT 3 on the left). If you do not have permission ask IDD. The XAE is really just a Visual Studio plugin.
- Start the Twincat XAE. This can be done by clicking on the TwinCat icon in the system tray.
- Open the Twincat project that you are interested in. For example the PLC_solution here
- Ensure that you have the following toolbars enabled in the XAE (
Tools > Customize...):TwinCAT PLCTwinCAT XAE Base- (optionally)
TwinCAT XAE Remote Manager
- Click the
Activate Configurationbutton- Note you may need to do this if it moans about ticks. You may also need to disable Hyper-V and disable Intel Virtualisation from within BIOS on your machine if this error persists.
To revert this run:Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -Allin an elevated Powershell window. You may also need to executesettick.batintcioc\masteras administrator and reboot. - TwinCAT will ask you to enter a code to get a trial license. You will need to do this once a week.
- If prompted if you wish to start the system in
Run ModeclickOk. Otherwise start run mode using the button next toActivate Configuration - You now have a simulated beckhoff PLC running on your PC. This behaves the same as real hardware and so all development can be done against it. You could now also run an IOC up talking to this local PLC.
- To see what is happening inside this PLC in more detail, and to change values, you can use the login button
Beckhoff PLC code is being developed by people who do not have CI expertise and have their own repository structures yet we want integration into some form of CI to be as easy as possible. This lent itself to the following structure:
- A
BeckhoffTestRunnerrepository that is owned by us and contains the jenkinsfile and other utilities required for CI - Every branch on this repository (apart from master) then pulls a different PLC project down (note each project could be from a different repository or from separate branches on the same repository)
- The jenkinsfile can then do the one or both of the following:
- Build the project (currently assumed to be called
solution.slnat the top of pulled PLC project) - Run any IOCTestFramework tests (currently assumed to be in a
testsfolder at the top of the pulled PLC project) - these will likely be written by us
- Build the project (currently assumed to be called
This means that the workflow for adding new PLC projects into CI is:
- A PLC developer writes their code (making sure the solution is called
solution.sln) - They give us a link to the repo and branch that contains the code
- We create a new branch on
BeckhoffTestRunnerand modify it to point at their repo - At this point they have CI for building their code
- We make a decision about whether the code requires any system tests and if so add some into their repository
To actually run tests we use the Beckhoff automation interface which can do any of the things you can do in the Twincat XAE automatically through DCOM. AC# (Beckhoff do not fully support a Python interface 😢) program (twinCATAutomationTools) has been written to leverage this interface in the following way to write integration tests for the Beckhoff:

- Jenkins will pull a branch of BeckhoffTestRunner.
-
build.batis run to do the following:- Build the
TwincatAutomationToolssolution, twinCATAutomationTools - Use the
twinCATAutomationToolsto import thetest_configinto the generic Twincat Solution and build the PLC code using theautomation interface. This build will also create a*.tpyfile, which outlines how to connect to the PLC and can be used to configure the IOC itself.
- Build the
- The IOC test framework is started. This will use the
TwinCATAutomationToolsprogram to run a local simulated PLC. Then startup and test the Beckhoff twincat in the usual way.
This is currently being run on the ndw1926 node on Jenkins. A quirk of using this DCOM interface is that the Jenkins slave must be run as an interactive user and thus not as a service. To do this there is a bat file that should run on startup inside C:\Users\ibexbuilder\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.
To run a PLC locally you need a license. A trial license can be activated on a developer's machine by manually running through the building and running steps above until you are prompted to supply a captcha phrase to generate a license.
- clone
BeckhoffTestRunnerusinggit clone --recursive https://github.com/ISISComputingGroup/BeckhoffTestRunner.git - Then in
BeckhoffTestRunnerrun:git submodule update --init --recursive --remote - To run tests locally you must build the
twinCATAutomationToolstools then use them to set up a working simulated PLC. This can be done by runningbuild.bat(best done not in an EPICS terminal). - Create an epics terminal, and then run the following command in your
BeckhoffTestRunnerdirectory to begin testing:
python %EPICS_KIT_ROOT%\\support\\IocTestFramework\\master\\run_tests.py -tp ".\\tests"
NB the IOC tests do not stop the PLC at the end of the run, however this isn't a problem as the PLC is restarted when the IOC tests start. If this fails to start the PLC it may be because you do not have a trial license. Debug the issue by manually running through the building and running steps above.