Br lvs

Currently, we are operating the motor by inputting the target position and velocity into the MoveAbsolute function block. While monitoring the servo motor's actual position (GVL.Axis1.NcToPlc.ModuloActPos) using the Scope function, we noticed a strange behavior: during the initial phase of the movement, the actual position lags behind the target position. However, after a certain point, the actual position starts to lead the target position by approximately 1 degree.

Unlike a standard following error (lagging), it is difficult for us to pinpoint why the motor would move ahead of the target position. Therefore, we are reaching out for your assistance.

To help with your investigation, I have attached the relevant test files. In the attached test_profile.csv file, 'F' represents the velocity and 'U' represents the target position.

We would greatly appreciate your insights into the potential causes of this issue and any recommendations on additional parameters or settings we should inspect.

Additionally, I have provided the PLC code below.

Thank you for your support.

We have a machine with spindle and a 'support' axis. It was programmed to move coupled using MC_CamIn for the main automatic cycle and normal absolute movements for positioning and auxilary movements.

When we position the spindle and/or the support X axis using the normal movements both reach our set/desired velocities i.e. 3000mm/s. 

However when we run the 'main' automatic cycle using MC_CamIn where spindle is the master axis and X is our slave axis (using a table for positions for both) the spindle only reaches 719.36mm/s (always, if the movement is long enough it reaches it fast and caps at this specific value). 

We cannot find how the MC_CamIn is calculating the velocity? From which settings does it get it?

The distance for Spindle is long enough it reaches the velocity in about 2 revolutions, and than runs 8 more revolutions with this specific yet low velocity. Our support axis X only makes small jumps of 1-2mm.

We tried different sets of maximum velocity/ reference velocity / acceleration /deceleration and jerk for both the spindle and x axis from the drive parameters. Even set it up 10x times higher, however the effect is always the same Spindle runs at 719.36 max.

This only occurs with MC_CamIn the normal motion works fine and spindle as well as X axis reach our set velocity i.e. 3000mm/s

Can anyone help with some insider info from where or how does the MC_CamIn calculate its movement velocity? We cannot find any place it would be declared or set. We have our position table for master and slave, the maximal velocity etc from drive parameters, so how can we increase master axis velocity?

Thanks in advance!

 
I’m running into an issue with the Trend Line Chart control in TwinCAT HMI where the element consistently throws a “Range mismatch” error at runtime. The chart loads, but as soon as data is pushed into it, the error appears and the trend fails to display correctly.

I've attached a screenshot of the error.

I’ve already reached out to Beckhoff support, but they weren’t able to identify the cause either.

Has anyone experienced this behaviour before, or found a workaround/fix?
Any insights, examples, or debugging tips would be greatly appreciated.

Many thanks in advance.

Ed

Beckhoff Information System - English

I know that most real project source code is proprietary and can’t be shared publicly — that makes perfect sense. Still, I’m wondering if anyone knows of a publicly available TwinCAT project from a real machine, or if someone would be willing to show a simplified/cleaned-up version of their own project (with company IP removed) to illustrate how OOP is applied in practice (including HMI SCADA integration).

Also — a related question: have you used the SPT framework from Beckhoff USA in your projects? If so, how did it fit into your OOP structure and workflow?

Those examples were "stateless", meaning that the operations depended only on the arguments passed to them (a and b in (a, b) => <expression>). In the real world, however, logic rarely exists in a vacuum. Functions often need context: thresholds, configuration values, or system parameters that aren't part of the function arguments themselves.

#include <iostream>

int main() 
{
    int scale = 10;
    
    // Capture by value (copy)
    auto scaleByValue = (int a, int b) { return (a + b) * scale; };

    // Capture by reference (observes changes)
    auto scaleByRef = (int a, int b) { return (a + b) * scale; };

    scale = 20;

    std::cout << scaleByValue(1, 2) << std::endl; // 30 (uses original scale = 10)
    std::cout << scaleByRef(1, 2) << std::endl;   // 60 (uses updated scale = 20)

    return 0;
}

1. Function blocks with state - storing context as member variables
2. Fluent interfaces - chainable methods that configure and return the function block

The fluent interface approach is particularly elegant, as it allows us to configure operations inline, similar to how we'd use closures in modern languages.

Approach 1: Direct Configuration

{attribute 'no_explicit_call' := 'calling this function block directly is not allowed'}
FUNCTION_BLOCK FB_SumIfInRangeFunction IMPLEMENTS I_BiFunction
    VAR_INPUT
        nLowerThreshold,
        nUpperThreshold : INT;
    END_VAR

    METHOD Apply : INT
        VAR_INPUT
            nA, nB : INT;
        END_VAR

        // Only add nB if it's within the range
        IF nB >= nLowerThreshold AND nB <= nUpperThreshold THEN
            Apply := nA + nB;
        ELSE
            Apply := nA;
        END_IF
    END_METHOD
END_FUNCTION_BLOCK

Example Usage

PROGRAM P_Example2_Direct
VAR
    arNumbers       : ARRAY OF INT := ;
    fbSum           : FB_SumIfInRangeFunction;
    nFilteredSum    : INT;
END_VAR

// Configure the thresholds
fbSum.nLowerThreshold := 10;
fbSum.nUpperThreshold := 20;

// Apply operation
nFilteredSum := P_Operations.Aggregate(arNumbers, fbSum);
// Result: 15 + 12 + 19 = 46 (8 and 23 are excluded)

Approach 2: Fluent Interface (Method Chaining)

A fluent interface allows us to chain method calls together, configuring the function block inline. The key is that configuration methods return a reference to the function block itself (THIS^), enabling multiple calls to be chained together.

INTERFACE I_GreaterThanCondition
    METHOD AnyGreaterThan : I_BiFunction
        VAR_INPUT
            nThreshold : INT;
        END_VAR
    END_METHOD
END_INTERFACE

INTERFACE I_LessThanCondition
    METHOD AnyLessThan : I_BiFunction
        VAR_INPUT
            nThreshold : INT;
        END_VAR
    END_METHOD
END_INTERFACE

INTERFACE I_InRangeCondition
    METHOD AnyInBetween : I_BiFunction
        VAR_INPUT
            nLowerThreshold, nUpperThreshold : INT;
        END_VAR
    END_METHOD
END_INTERFACE

{attribute 'no_explicit_call' := 'calling this function block directly is not allowed'}
FUNCTION_BLOCK FB_SumFunction 
IMPLEMENTS I_BiFunction, I_GreaterThanCondition, I_LessThanCondition, I_InRangeCondition
    VAR_STAT CONSTANT
        _nMIN_INT : INT := -32768;
        _nMAX_INT : INT := 32767;
    END_VAR
    VAR
        _nLowerThreshold : INT := _nMIN_INT;
        _nUpperThreshold : INT := _nMAX_INT;;
    END_VAR
    
    // Sets the minimum threshold (inclusive)
    // Values must be GREATER THAN OR EQUAL to this threshold
    METHOD AnyGreaterThan : I_BiFunction
        VAR_INPUT
            nThreshold : INT;
        END_VAR
        AnyGreaterThan   := THIS^;

        _nLowerThreshold := nThreshold;
        _nUpperThreshold := _nMAX_INT;
    END_METHOD

    // Sets the maximum threshold (inclusive)
    // Values must be LESS THAN OR EQUAL to this threshold
    METHOD AnyLessThan : I_BiFunction
        VAR_INPUT
            nThreshold : INT;
        END_VAR
        AnyLessThan      := THIS^;

        _nLowerThreshold := _nMIN_INT;
        _nUpperThreshold := nThreshold;
    END_METHOD

    // Sets the lower and upper threshold (inclusive)
    // Values must be BETWEEN these thresholds
    METHOD AnyInBetween : I_BiFunction
        VAR_INPUT
            nLowerThreshold, nUpperThreshold : INT;
        END_VAR
        AnyInBetween     := THIS^;

        _nLowerThreshold := nLowerThreshold;
        _nUpperThreshold := nUpperThreshold;
    END_METHOD

    // Resets the configuration so that all values are allowed
    METHOD Everything : I_BiFunction
        VAR_INPUT
        END_VAR
        Everything := THIS^;

        _nLowerThreshold := _nMIN_INT;
        _nUpperThreshold := _nMAX_INT;
    END_METHOD

    METHOD Apply : INT
        VAR_INPUT
            nA, nB : INT;
        END_VAR
        // Only add nB if it's within the configured range
        IF nB >= _nLowerThreshold AND nB <= _nUpperThreshold THEN 
            Apply := nA + nB;
        ELSE
            Apply := nA;
        END_IF
    END_METHOD
END_FUNCTION_BLOCK

Example Usage

ROGRAM P_Example2_Fluent
VAR
    arNumbers        : ARRAY OF INT := ;
    fbSum            : FB_SumFunction;
    nFilteredSum1,
    nFilteredSum2,
    nFilteredSum3    : INT;
END_VAR

// Configure and apply operations inline
nFilteredSum1 := P_Operations.Aggregate(arNumbers, fbSum.AnyLessThan(20));
// Result: 15 + 8 + 12 + 19 = 54 (23 is excluded)

nFilteredSum2 := P_Operations.Aggregate(arNumbers, fbSum.AnyGreaterThan(10));
// Result: 15 + 23 + 12 + 19 = 69 (8 is excluded)

nFilteredSum3 := P_Operations.Aggregate(arNumbers, fbSum.AnyInBetween(10, 20));
// Result: 15 + 12 + 19 = 46 (8 and 23 are excluded)

nSum          := P_Operations.Aggregate(arNumbers, fbSum.Everything());
// Result: 15 + 8 + 23 + 12 + 19 = 77 (all values are included)

Benefits of the Fluent Approach

Data Transformation & Mapping

// Transform raw ADC values to engineering units with calibration offset
fCalibratedTemps := P_DataTransform.Map(
    nRawSensorData,
    fbADCToTemp.WithOffset(nZeroOffset).WithGain(fCalibrationGain)
);

Filtering & Selection

// Select production batches exceeding quality threshold
nCount := P_DataFilter.Filter(
    arAllBatches,
    fbQualityCheck
        .AnyGreaterThan(nPremiumThreshold)
        .WithMargin(fSafetyMargin),
    arPremiumBatches
);

// Find active alarms above critical severity
nCount := P_DataFilter.Filter(
    arAlarmList,
    fbAlarmFilter
        .AnyGreaterThan(E_Severity.High)
        .IsActive()
        .NotAcknowledged(),
    arCriticalAlarms
);

Validation & Predicates

// Verify all safety sensors are within safe range
bSystemSafe := P_SafetyCheck.Every(
    arSafetySensors,
    fbSafetyValidator
        .AnyInBetween(nSafeMin, nSafeMax)
        .WithHysteresis(nHysteresisBand)
);

Sorting & Ranking

// Sort machines by efficiency, excluding standby units
P_EquipmentSort.Sort(
    arMachines,
    fbEfficiencyCompare.AnyGreaterThan(nMinEfficiency).ByDescending()
);

// Rank production runs by yield within quality band
P_BatchSort.Sort(
    arProductionRuns,
    fbYieldCompare.AnyInBetween(nMinQuality, nMaxQuality).ByYield()
);

Search & Analysis

// Find first sensor reading exceeding alarm threshold
ipFirstAlarm := P_DataSearch.Find(
    arSensorReadings,
    fbThresholdCheck.AnyGreaterThan(nAlarmThreshold).Confirmed(T#2s)
);

// Identify optimal batch by cost-to-quality ratio
ipBestBatch := P_BatchAnalysis.FindOptimal(
    arBatches,
    fbCostAnalysis.AnyGreaterThan(nMinYield).WithQualityWeight(0.6)
);

Statistical Aggregation

// Calculate weighted average excluding statistical outliers
fWeightedAvg := P_Statistics.Aggregate(
    arMeasurements,
    fbWeightedAvg
        .AnyInBetween(fMean - 3*fStdDev, fMean + 3*fStdDev)
        .WithWeights(arWeights)
);

// Compute RMS vibration in bearing frequency range
fBearingVibration := P_VibrationAnalysis.Aggregate(
    arFFTData,
    fbRMS
        .AnyInBetween(fBearingFreqLow, fBearingFreqHigh)
        .WithHanningWindow()
);

Many modern programming languages, like Rust, Java, Python, or C#, have what is known as first-class functions. These are functions that can be passed around just like variables, meaning they can be assigned to variables, passed as arguments to other functions, or even returned as values from functions. This flexibility allows for more dynamic and reusable code. This is the fundamental concept behind lambdas, closures, and anonymous functions, which are compact ways to define behaviour on the fly without needing to declare a full function or method. By embedding logic directly where it’s needed, they allow developers to write cleaner, more concise, and more modular code.

Here’s an example of an anonymous function in C# that reduces a list of numbers:

using System;
using System.Linq;

int[] numbers = {2, 1, 3, 5, 4};

// Using an anonymous function to sum the array
int sum = numbers.Aggregate((a, b) => a + b);

// Using an anonymous function to get the product of the array
int product = numbers.Aggregate((a, b) => a * b);

// Output: 15
Console.WriteLine(sum);

// Output: 120
Console.WriteLine(product);

In this example, the Aggregate method uses a lambda expression to define how two numbers should be combined, either summing ((a, b) => a + b) or multiplying ((a, b) => a * b) the values. The power here is that the Aggregate method itself is decoupled from the specific operation. It doesn’t care whether you’re summing or multiplying numbers. This makes the logic highly reusable and flexible, allowing the function to process data in different ways based on the behaviour you pass in.

Unfortunately, Structured Text (ST) doesn’t have first-class functions (sort of...), but we can still introduce some of these principles through functional interfaces. Although ST doesn’t support lambdas, closures, or anonymous functions, functional interfaces can give us a way to mimic some of this functionality.

What is a Functional Interface?

A functional interface is an interface that contains exactly one abstract method. This single-method contract allows for a concise and focused interaction between components, making it ideal for situations where you need to define a single behaviour or action. While functional interfaces can have other members like default methods or constants (these aren't supported in ST), they are designed around the core idea of one abstract method, ensuring they remain lightweight and purpose-driven.

Here's an example of a functional interface in Java:

@FunctionalInterface
public interface BiFunction<T, U, R> {
     R apply(T t, U u); 
}

This BiFunction interface represents a function that accepts two arguments (T  and U ) and returns a result (R). The Apply method is the single abstract method that makes this a functional interface.

Here's an example of using this interface:

import java.util.function.BiFunction;

public class Main
{
    public static void main(String[] args) {
        // Define a BiFunction that adds two integers
        BiFunction<Integer, Integer, Integer> foo = (a, b) -> a + b;

        // Invoke the BiFunction to add two integers
        Integer result = foo.apply(2, 3);

        // Output: 5
        System.out.println(result);
    }
}

In this example, we create a BiFunction to add two integers. The lambda expression (a, b) => a + b defines the behaviour, and the apply method calls the function with the specified arguments.

Application in Industrial Automation

In automation systems, functional interfaces can be used to define well-scoped behaviours that can be applied across different components or modules. By encapsulating specific functionality within a clear, single-purpose interface, functional interfaces help make systems easier to maintain, extend, and understand. This modularity also enables greater flexibility when it comes to introducing new behaviours or modifying existing ones without affecting the overall system.

In this section, I’ll walk you through a simple example that demonstrate the use of functional interfaces in Codesys/TwinCAT's implementation of the IEC 61131-3 Structured Text language. I’ll be replicating the aggregate function discussed earlier to perform operations like summing and finding the maximum in an array of numbers.

Define the Functional Interface

First, let's define the I_BiFunction interface that will serve as a blueprint for any function that performs an operation on two integers and returns an integer result:

INTERFACE I_BiFunction
    METHOD Apply : INT 
    VAR_INPUT 
        nA, nB : INT;
    END_VAR 
END_INTERFACE

This interface contains a single method, Apply , which takes two integers as inputs (nA , nB ) and returns an integer result.

Implement a Method that Utilises the Functional Interface

Next, we’ll create the P_Operations  program that contains a method called Aggregate. This method will iterate over an array of integers and apply the operation defined by the I_BiFunction interface to aggregate the values in the supplied array.

{attribute 'no_explicit_call' := 'calling this program directly is not allowed'}
PROGRAM P_Operations
    METHOD Aggregate : INT
    VAR_IN_OUT CONSTANT
        {warning disable C0228}
        arNumbers : ARRAY  OF INT;
    END_VAR
    VAR_INPUT
        ipOperation : I_BiFunction;
    END_VAR
    VAR
        i : __XINT;
    END_VAR

    // Exit the function call if the operation is not supplied.
    IF ipOperation = 0 THEN RETURN; END_IF

    // Initialise the result with the first element of the array.
    Aggregate := arNumbers;

    // Loop through the array and apply the operation defined by the interface.
    FOR i := LOWER_BOUND(arNumbers, 1) + 1 TO UPPER_BOUND(arNumbers, 1) DO
        Aggregate := ipOperation.Apply(Aggregate, arNumbers);
    END_FOR

    END_METHOD
END_PROGRAM

Explanation:

• The ipOperations  input parameter is an instance of the I_BiFunction interface, which defines the operation to be applied (such as summing or multiplying).

• The method initialises the result (Aggregate) with the first element of the array.

• It then iterates through the rest of the array, applying the operation (via ipOperations.Apply(...)) to the running result and each element of the array.

Implementing the Operations

Now, let’s implement specific operations by creating function blocks that implement the I_BiFunction interface. We will use these to perform different actions on the array elements.

Product Operation

{attribute 'no_explicit_call' := 'calling this function block directly is not allowed'}
FUNCTION_BLOCK FB_ProductFunction IMPLEMENTS I_BiFunction
    METHOD Apply : INT
    VAR_INPUT
        nA, nB : INT;
    END_VAR

    // Return the product of two values
    Apply := nA * nB;

    END_METHOD
END_FUNCTION_BLOCK

Maximum Value Operation

{attribute 'no_explicit_call' := 'calling this function block directly is not allowed'}
FUNCTION_BLOCK FB_MaximumValueFunction IMPLEMENTS I_BiFunction
    METHOD Apply : INT
    VAR_INPUT
        nA, nB : INT;
    END_VAR

    // Return the maximum of two values
    Apply := MAX(nA, nB);

    END_METHOD
END_FUNCTION_BLOCK

Example Usage

Now that we've defined the functional interface and its implementations, we can use the P_Operations program to apply different operations to an array of numbers.

PROGRAM P_Example1
VAR
    nProduct, 
    nLargest    : INT;
    arNumbers   : ARRAY OF INT := ;
    fbProduct   : FB_ProductFunction;
    fbLargest   : FB_MaximumValueFunction;
END_VAR

nProduct := P_Operations.Aggregate(arNumbers, fbProduct);
nLargest := P_Operations.Aggregate(arNumbers, fbLargest);

Real World Applications

// Transform sensor data through different conversion functions
fCelsius    := P_DataTransform.Map(nRawSensorData, fbADCToCelsius);
fFahrenheit := P_DataTransform.Map(nRawSensorData, fbADCToFahrenheit);

// Apply different operations to production batches
bAllPassed := P_BatchProcessor.Every(arQualityChecks, fbMeetsStandard);
bAnyFailed := P_BatchProcessor.Some(arQualityChecks, fbBelowThreshold);

// Filter arrays based on different validation criteria
// Filter(<source>, <predicate>, <destination>) -> <Count>
nCount := P_DataFilter.Filter(arSensorData, fbWithinTolerance, arValidReadings);
nCount := P_DataFilter.Filter(arSensorData, fbOutsideExpected, arOutliers);
nCount := P_DataFilter.Filter(arAlarms, fbHighSeverity, arCritical);

// Sort machine data by different criteria
P_DataSort.Sort(arMachines, fbByEfficiency);
P_DataSort.Sort(arMachines, fbByUptime);
P_DataSort.Sort(arMachines, fbByProductionCount);

The key advantage here is that the processing logic (Aggregate, Map, Filter, etc.) remains unchanged while the behaviour is completely customisable through different function block implementations.

Conclusion

Functional interfaces bring a powerful abstraction mechanism to Structured Text programming. While ST lacks first-class functions, lambdas, and closures, functional interfaces allow us to:

1. Decouple algorithms from operations: The Aggregate method doesn't know or care whether it's summing, multiplying, or finding maximums. It just applies the provided operation.

2. Increase code reusability: Write the processing logic once, then reuse it with countless different behaviors by simply implementing new function blocks.

3. Improve testability: Each operation is encapsulated in its own function block, making it easy to test in isolation.

4. Enhance maintainability: Changes to specific operations don't affect the core processing logic, and vice versa.

5. Create more expressive code: The intent becomes clear when you read P_Operations.Aggregate(arNumbers, fbProduct) versus a hardcoded multiplication loop.

While we've focused on simple, stateless operations in this part, functional interfaces become even more powerful when combined with context and state. In Part 2, we'll explore how to add context and capturing to our functional interfaces, allowing operations to carry configuration and state-mimicking the closure behaviour found in modern programming languages.