As an integrator, Control Works develops software for a wide range of applications. Even though the application code can largely vary, the core foundation of almost every application is the same. Motion axes, alarms, inputs and outputs, and diagnostics are just a few examples.
Library
Beckhoff’s ecosystem makes it easy to wrap all these core foundation pieces into one library. This reduces clutter in an application, creates one central location for documentation, and allows for a versioning system. In addition, source code can be hidden by saving the library as a compiled library.
Control Works has created its own library to take advantage of all of these benefits.
As seen above, Control Works also uses custom libraries such as the SPT Application Framework by Beckhoff and the OSCAT Basic library. To make these well tested and documented libraries fit into Control Works’ application style (consistent method returns, accessibility by TwinCAT HMI, small differences in desired functionality, etc.), it is common to write a small wrapper around the components of these libraries.
Control Works follows the semantic versioning scheme of major, minor, patch. This allows the developer to understand the possible implications of upgrading to different versions of the library.
Unit Testing
The power of software testing is well documented. Reducing the number of bugs, ensuring reliability, and accounting for edge cases all lead to reduced development time. Having peace of mind that the foundation of an application “will just work” makes developing an application much easier and stress-free.
For the Control Works library, each component is unit tested using the TcUnit framework.
Below is a snippet from a motion test. For components such as motion that take multiple scans to complete, a simple sequencer is used to complete the test. As seen below, different scenarios are tested to make sure the axis behaves in the correct way.
These are the results of the testing on the Control Works library. Tests continue to be added as more core components are developed and different edge cases are encountered. You can see that the Event Logger using warnings and errors are part of the tests from the output below as well.
There’s nothing better than seeing “Failed tests: 0”!
The way Control Works thinks about testing is, since testing must be completed anyways, might as well document all the tests that have been completed so they never have to be manually done again. This methodology has saved Control Works countless hours of development and commissioning time onsite at the client.
