simatic-ax · christof-ochs · Jun 29, 2026 · Jun 29, 2026 · Jun 29, 2026
diff --git a/CODEOWNERS b/CODEOWNERS
@@ -1,4 +1,4 @@
 # These owners will be the default owners for everything in the repo.
 # Unless a later match takes precedence, the listed user will be
 # requested for review when someone opens a pull request.
-@christof.ochs @KPirmer
+* @simatic-ax/pma-maintainer @christof.ochs @KPirmer
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -19,7 +19,7 @@ There are many ways in which you can contribute, beyond writing code. The goal o
 
 ## Thank You
 
-Your contributions to this open source project - large or small - let´s us create better automation solutions - together! Thank you for being an essential part of this journey.
+Your contributions to this open source project - large or small - let us create better automation solutions - together! Thank you for being an essential part of this journey.
 
 ## Types of contributions
 
@@ -91,6 +91,6 @@ Once all clearings are successful, our admins will create the repository within
 
 ### Siemens employees
 
-In case you are a Siemens employee who likes to propose a new repository for the GitHub community, please the [Siemens contribution process](https://code.siemens.com) for a set of follow along instructions.
+In case you are a Siemens employee who likes to propose a new repository for the GitHub community, please see the [Siemens contribution process](https://code.siemens.com) for a set of follow along instructions.
 
 > For all inquiries, please get in touch via our [Admin Team](https://github.com/orgs/simatic-ax/teams/toa-teamofaxion).
diff --git a/LICENSE.md b/LICENSE.md
diff --git a/README.md b/README.md
@@ -1,7 +1,7 @@
 # Performance Programming Guidelines
 
 This repository serves to provide programming guidelines for users of SIMATIC AX.
-It's primary goal is to address programming related suggestions that impact the runtime performance.
+Its primary goal is to address programming related suggestions that impact the runtime performance.
 
 See the [Overview](./docs/01_Introduction.md) to find the different recommendations.
 
@@ -16,4 +16,4 @@ Furthermore, suggestions for other potential targets of SIMATIC AX (e. g. SINUME
 The [CONTRIBUTING.md](CONTRIBUTING.md) explains how to create an issue in relation to the SIMATIC AX programming guidelines.
 Feedback or requirements regarding SIMATIC AX are out of scope of the programming guidelines.
 
-The programming guidelines are not meant as as substitute for the official documentation and learnings and therefore do not explain basic technial aspects.
+The programming guidelines are not meant as a substitute for the official documentation and learnings and therefore do not explain basic technical aspects.
diff --git a/docs/01_Introduction.md b/docs/01_Introduction.md
@@ -5,7 +5,7 @@ It offers an environment to program a PLC using Structured Text (ST). The ST com
 
 When programming a PLC system, the achievable runtime performance of the user program is of high importance.
 
-SIMATIC AX offers many programming features in combination with SIMATIC, which are not available in TIA Portal (e. g. object-oriented programming) and uses a different data structure.
+SIMATIC AX offers many programming features in combination with SIMATIC, which are not available in TIA Portal (e.g. object-oriented programming) and uses a different data structure.
 Therefore, comparing the (expected) runtime performance of applications from TIA Portal and SIMATIC AX is not straightforward.
 
 ## Objective of the guideline
@@ -21,6 +21,6 @@ This guideline provides tips and suggestions regarding the programming in SIMATI
 5. [R005_FastMath library](R005_FastMath.md)
 6. [R006_Array boundaries](R006_ArrayBoundaries.md)
 7. [R007_Accessing Technology Objects](R007_AccessTO.md)
-8. [R008_Limit string lenght](R008_LimitStringLength.md)
+8. [R008_Limit string length](R008_LimitStringLength.md)
 9. [R009_Pass by reference](R009_PassByReference.md)
 10. [R010_If-else expectation](R010_IfElseExpectation.md)
diff --git a/docs/R001_TempVariables.md b/docs/R001_TempVariables.md
@@ -1,10 +1,10 @@
 # Recommendation R001: Use temporary variables
 
-Use temporary variables (`VAR_TEMP`) as intermediate memory in the current cylce if the calculation results are not required over multiple cycles. The access time for temporary variables is shorter than for static variables.
+Use temporary variables (`VAR_TEMP`) as intermediate memory in the current cycle if the calculation results are not required over multiple cycles. The access time for temporary variables is shorter than for static or global variables.
 
 ## Note
 
-Temporary variables cannot be monitored or modified with the SIMATIC AX online tools.
+Temporary variables cannot be monitored or modified with the SIMATIC AX online tools. But their values can be watched during debugging through log points.
 
 Temporary variables are initialized by the system in every call, therefore big data structures consume more performance than static variables.
 

diff --git a/docs/R002_Dereferencing.md b/docs/R002_Dereferencing.md
@@ -15,8 +15,8 @@ VAR
     x8, x9, x10, x11, x12, x13, x14, x15 : BOOL;
     x16, x17, x18, x19, x20, x21, x22, x23 : BOOL;
     x24, x25, x26, x27, x28, x29, x30, x31 : BOOL;
-END_VAR 
-tempData := data^;  
+END_VAR
+tempData := data^;
 x0 := tempData.%X0;
 x1 := tempData.%X1;
 x2 := tempData.%X2;
@@ -30,7 +30,7 @@ x5 := tempData.%X5;
 
 ## Note
 
-Temporary variables cannot be monitored or modified with the SIMATIC AX online tools.
+Temporary variables cannot be monitored or modified with the SIMATIC AX online tools. Their values can be watched during debugging through log points.
 
 Temporary variables are initialized by the system in every call, therefore big data structures consume more performance than static variables.
 

diff --git a/docs/R003_MultipleArrayAccess.md b/docs/R003_MultipleArrayAccess.md
@@ -1,6 +1,6 @@
-# Recommendation R003: Avoid multiple acces to same array index
+# Recommendation R003: Avoid multiple access to same array index
 
-When accessing an array index with the bracket syntax, internal checks for the validity of the array boundaries are performed. When access to the same index of an array is required (e. g. to access underlying nested elements), use a temporary variable as a cache. Write back the changes to the array (if applicable) once, after the operation is finished.
+When accessing an array index with the bracket syntax, internal checks for the validity of the array boundaries are performed. When access to the same index of an array is required (e.g. to access underlying nested elements), use a temporary variable as a cache. Write back the changes to the array (if applicable) once, after the operation is finished.
 
 ```iecst
 VAR

diff --git a/docs/R004_ControlVariables.md b/docs/R004_ControlVariables.md
@@ -1,7 +1,7 @@
-# Recommendation R004: Declaring control variables as DINT
+# Recommendation R004: Declare control variables as DINT for array index
 
-It is recommended to use the data type `DINT` for control variables used in loops, iterations, and array access.
-There is a slight performance advantage as the least amount of (implicit) type conversion occur when using `DINT`.
+It is recommended to use the data type `DINT` for control variables of loops, if array elements are accessed using this control variable as index. See the variable "iterator" in the example of [R003](./R003_MultipleArrayAccess.md).
+There is a slight performance advantage as the least amount of (implicit) type conversions occur when using `DINT`.
 
 ## Note
 

diff --git a/docs/R005_FastMath.md b/docs/R005_FastMath.md
@@ -1,13 +1,13 @@
-# Recommendation R005: Using the `System.FastMath` library
+# Recommendation R005: Use the `System.FastMath` library
 
 The `System.Math` library contains numerical and arithmetic functionality. The internal implementation is based on algorithms with a higher degree of portability.
 The library `System.FastMath` provides more performant implementations for a number of functions.
 It is recommended to use the `System.FastMath` library for performance optimization.
 
-Regarding the `SQRT`, `SIN`, `COS`, and `TAN` function, the `System.FastMath` provides a substantial performance improvement.
+Regarding the `SQRT`, `SIN`, `COS`, and `TAN` functions, the `System.FastMath` provides a substantial performance improvement.
 
 ## Note
 
-Different targets (i. e. the "1500" and "llvm" target) may behave differently in corner cases in the `System.FastMath` library. More information is found in the individual function documentation.
+Different targets (i.e. the "1500" and "llvm" target) may behave differently in corner cases in the `System.FastMath` library. More information is found in the individual function documentation.
 
 Back to [Overview](./01_Introduction.md)
diff --git a/docs/R006_ArrayBoundaries.md b/docs/R006_ArrayBoundaries.md
@@ -1,8 +1,7 @@
-# Recommendation R006: Passing arrays as formal parameters
+# Recommendation R006: Prefer fixed-length array as formal parameter rather than variable-length array
 
-If an array needs to be passed as a formal parameter, there is an performance impact with regard to the _size specification_ of the array.
-The concrete size and limits of an array of unspecified size (`ARRAY[*]`) need to be evaluated with the system functions `UPPER_BOUND` and `LOWER_BOUND`.
-This creates additional computational demand. Therefore, arrays of specified size (e. g. `ARRAY[0..63]`) are the more performant solution.
+If an array needs to be passed as a formal parameter, there is a performance impact with regard to the _length specification_ of the array.
+Accessing an element of a variable-length array (`ARRAY[*]`) creates additional computational demand compared to the same operation with a fixed length array (e. g. `ARRAY[0..63]`).
 
 ## Note
 

diff --git a/docs/R007_AccessTO.md b/docs/R007_AccessTO.md
@@ -2,7 +2,7 @@
 
 When accessing data from Motion Control Technology Objects (TO) it is recommended to read the data once and store it in temporary or static memory for repeated access. Access to Technology Object data is significantly slower than accessing temporary or static memory in a POU.
 
-This recommendation applies both to the access via the reference to a Technology Object as well as calling the auxiliary functions like `Get<TO>Status`, `<Get<TO>Warnings` and `Get<TO>Warnings`.
+This recommendation applies both to the access via the reference to a Technology Object as well as calling the auxiliary functions like `Get<TO>Status`, `<Get<TO>Warnings` and `Get<TO>Errors`.
 
 ```iecst
 USING Siemens.Simatic.S71500.MotionControl.Native;
@@ -13,7 +13,7 @@ VAR_OUTPUT
     posBasedCalculation : LREAL;
 END_VAR
 VAR_TEMP
-    tempPosition : LREAL;
+    tempPos : LREAL;
 END_VAR
 
 
@@ -28,9 +28,9 @@ END_IF;
 
 It is also recommended to read only the Technology Object data which is required in the user program.
 
-Avoid cyclic evaluation of static configuration data (e. g. the leadscrew pitch of an axis).
+Avoid cyclic evaluation of static configuration data (e.g. the leadscrew pitch of an axis).
 
-Do not read Technology Object data in a higher frequency than the values are actually updated (i. e. MC_Servo cylce).
+Do not read Technology Object data in a higher frequency than the values are actually updated (i. e. MC_Servo cycle).
 
 ## Note
 

diff --git a/docs/R009_PassByReference.md b/docs/R009_PassByReference.md
@@ -4,18 +4,17 @@ SIMATIC AX and the SIMATIC runtime system offer different mechanisms for passing
 _Pass by value_ means that the formal parameter is a copy of the argument value provided when calling the POU.
 _Pass by reference_ means that the formal parameter is a reference to the provided argument.
 
-With some exceptions regarding `ARRAY` and `STRING` parameters, parameter passing in SIMATIC AX follows these general rules:
+For elementary data types (with the exception of strings), parameter passing in SIMATIC AX follows these general rules:
 
 | Section      | Parameter passing   |
 |--------------|---------------------|
 | `VAR_INPUT`  |  _Pass by value_    |
 | `VAR_OUTPUT` |  _Pass by value_    |
 | `VAR_IN_OUT` | _Pass by reference_ |
 
-Regarding performance, _pass by reference_ has benefits for larger groups of formal parameters.
-The performance advantage increases as the count of elements increases.
+For structs, arrays and strings, `VAR_INPUT` parameters of a `FUNCTION`/`METHOD` are compiled as _pass by reference_ to improve performance, while `VAR_INPUT` of `PROGRAM`/`FUNCTION_BLOCK` still requires value copy because the variable is treated as a member of the `PROGRAM`/`FUNCTION_BLOCK`, which shall preserve the status over multiple cycles.
 
-Therefore, it is recommended to group formal parameters into structures and pass these via reference (i. e. in the `VAR_IN_OUT` section of a `FUNCTION_BLOCK`).
+Regarding performance, it is recommended to group formal parameters of elementary types into structures and pass these via reference (i.e. `VAR_INPUT` of `FUNCTION`/`METHOD`, or `VAR_IN_OUT` of `FUNCTION`/`METHOD`/`PROGRAM`/`FUNCTION_BLOCK`). The performance advantage increases as the count of elements increases.
 
 ## Example
 
@@ -42,9 +41,9 @@ TYPE
 END_TYPE
 
 FUNCTION_BLOCK
-VAR_IN_OUT
-    dynamics : dynamicInfo
-END_VAR
+    VAR_IN_OUT
+        dynamics : dynamicInfo;
+    END_VAR
     .
     .
     .
@@ -53,6 +52,6 @@ END_FUNCTION_BLOCK
 
 ### Note
 
-Using this method, the original data may be modified.
+Using `VAR_IN_OUT`, the original data from the caller may be modified by the callee.
 
 Back to [Overview](./01_Introduction.md)
diff --git a/docs/R010_IfElseExpectation.md b/docs/R010_IfElseExpectation.md
@@ -2,7 +2,7 @@
 
 It is recommended to order `IF`/`ELSIF` statements by decreasing likelihood.
 The condition with the highest expectation of being `TRUE` should be placed at the top.
-Ordering the conditions in this way reduces the amount of occurences where less likley conditions need to be check, thereby improving the runtime performance.
+Ordering the conditions in this way reduces the amount of occurences where less likely conditions need to be checked, thereby improving the runtime performance.
 
 ## Example