Automatic instrumentation through additional tools

At a glance and in detail: The profiler shows exactly which code was actually executed.

© Codesys

If, on the other hand, the measurements are carried out with additional tools at the click of a mouse, they can be carried out regularly during application development. Corresponding tools are not only available for high-level languages such as C++ or C#, but also for IEC 61131-3 code in the Codesys Development System. The Codesys Profiler lives up to its name: it examines the 'case' using various methods and thus provides valuable insights in every project phase without manual effort.

With the simplest method, 'instrumentation', additional code is injected into the modules to be measured - exactly as described, but automatically. The result of the measurement gives the application engineer a detailed picture of the execution time, share of the overall project and call frequency of each block. Because it is immediately visible which blocks are critical for the overall performance, he can concentrate precisely on these objects during optimization. The measurement of the longest cycle time in the observation period provides information about sporadically occurring outliers. With further configuration options, the measurement can be started dynamically via Boolean variables. The first initialization cycle or individual blocks can be deliberately included in or excluded from the measurement, and the proportion of the runtime accounted for by library blocks can also be taken into account.

The snapshot of the processing time and the call frequency is displayed for each module and can be saved for later tracking.

© Codesys

However, such an instrumented measurement is at the expense of the application, i.e. the execution time. In some cases, the additional load can also cause the watchdog to kick in, meaning that the task time monitoring reports an error. However, there is no way around this, especially when it comes to detecting the aforementioned outliers. It has proven to be a good idea to measure the runtime at the end of each working day, for example, to continuously monitor the progress and to immediately examine any sudden changes in individual blocks. When the profiler is switched off after the measurement, the additional code disappears in any case, and with it its effects.

Sampling and code coverage

The Profiler watch list: Precise information for quick measurements in between

© Codesys

Sampling the application is suitable for determining long-term effects with significantly less influence from the measurement code. For this purpose, the profiler intervenes in the program flow at definable intervals from the outside, so to speak, and randomly determines the current call stack, i.e. the block that has just been processed, and by whom it was called. An increasing number of such random samples sharpens the impression of which blocks take more time than others. The longer the measurement runs, the more accurate the statistical average calculated from this becomes.

How can such a measurement be realized in a tool like Codesys? By
Using multicore technology: A sampling task generated by the profiler and the associated measurement code run in their own task group on a separate CPU core. This code samples the execution of the actual application at regular intervals and uses this to measure the runtime. The running application code is not changed, and the resulting interruptions to the application are also minimal. This measurement method will not trigger a watchdog. However, sampling cannot detect outliers.

An additional method in the Codesys Profiler also provides valuable facts about the application: by checking the code coverage, the Profiler displays the lines of code or networks that are traversed during the measurement. The user can jump from the view of the entire project to individual blocks and get an overview of the result in the source code. This information is very helpful when commissioning and testing the application and provides answers to questions such as these:

• Have all operating modes already been run?
• What part of the code is responsible for the runtime of the tested operating mode?
• Which part of the application still needs to be specifically tested or put into operation

Incidentally, the quality assurance of modules can be documented very well with additional tools for test automation such as the Codesys Test Manager.

The application

Roland Wagner is Head of Product Marketing at Codesys.

© Codesys

The Profiler must first be installed so that a measurement can be carried out in the Codesys Development System. A corresponding add-on package is available in the Codesys Store, which is licensed together with four other tools as an annual subscription. For measurement, the application programmer inserts the profiler as an object in the project tree and configures the measurement method and its parameters. The measurement is started automatically when the application is downloaded to the controller. As a result, all executed objects are immediately displayed in different views: Hierarchically according to the call tree, as a list sortable according to different criteria and in an inverted display of the call tree for tracing the call chain. From the list, the user can jump directly to the individual blocks in order to optimize the code there.

An overview with basic information on the measurement is also available. If the measurement result is saved as a snapshot in the project, the programmer can document the runtime behaviour and later trace its progress. This makes it easy to trace or rectify jumps in individual objects and their causes. And because it is sometimes sufficient to monitor just one or more individual blocks, the profiler also provides a kind of 'real-time view': If the user drags a block into the profiler watch list during program execution, he can immediately see its execution time together with statistical information.