Extending FB_Init Parameters in TwinCAT: Constructors for Derived Classes

Recently, I’ve come across several articles discussing FB_Init. They are generally good, but they miss one very important aspect: the ability to extend FB_Init in derived classes by adding new parameters. This is not exactly a hidden feature, but, for some reason, it is rarely used in practice. So I decided to add my two cents.

💡 The Core Idea

We do not have true constructors, nor do we have method overloading. Instead, we are limited to a single FB_Init method per class — but we can extend its parameter list in derived classes. This is somewhat similar to having a single constructor. However, constructors are meant for object initialization, and in many real-world cases they require external dependencies. In a class hierarchy, derived classes are often more complex than their base classes and therefore require additional initialization data.

⚙️ What the Compiler Actually Allows

The compiler allows us to extend the parameter list of FB_Init in a derived class by appending new parameters to those already defined in the base class. This means we can build a consistent and scalable initialization flow across the entire class hierarchy.

🧩 Example

In the example shown in the image: • A base abstract ‘Device’ class defines a device name via FB_Init. • A derived ‘DigitalInput’ device extends FB_Init with an additional parameter representing its configuration (a structure in my case). Similarly, other derived classes can introduce their own specific initialization parameters.

✅ Result

This approach allows you to construct properly initialized objects across the hierarchy: • explicit dependencies • predictable initialization • cleaner design

If you are interested in real-world examples, you can find them in my TwinCAT.OpenFramework at the following link: TwinCAT.OpenFramework Initialization Concept

#TwinCAT #CoDeSys #OOP #OpenFramework #IndustrialAutomation #StructuredText