Zeugwerk Framework

What it is

Zeugwerk Framework is a compiled OOP framework for TwinCAT 3.1. It provides a clear, consistent architecture - Application, Units, Equipment, State Machines, Sequences - that every project in your organisation can share. You use it to implement your machine logic; the framework handles the boilerplate and infrastructure.

Runs on: TwinCAT 3.1 · CODESYS on request · CtrlX on request

What it gives you

• Application structure - A defined hierarchy: one Application, multiple Units, each Unit owning its Equipment. Clear entry points, clear data ownership.
• State machine - A standard lifecycle (Boot, GoHome, Automatic, Stop, FaultReaction) that every Unit follows. Extend it for your specific needs.
• Sequences - Structured, step-based sequences with Await, Await2, Await3 helpers. No manual polling loops.
• Equipment library - Ready-to-use building blocks: digital I/O, actuators (mono/bistable, with various limit switch configurations), axes (PlcOpen MC, CiA402, vendor drives), serial ports, RFID readers, and more.
• Logging - Structured, per-cycle logging without performance penalty. Log to file, ADS, or custom sinks.
• Simulation - Equipment has built-in simulation modes. Develop and test logic without physical hardware.
• Testing - Unit test infrastructure via ZCore.IUnittest. Integrated with zkbuild for CI.

How it works

Application → Units → Equipment

Every Zeugwerk application has the same top-level shape:

• Application - the container. Manages the boot sequence, runs all units cyclically, provides logging, alarming, and fieldbus handling. Communication and data are kept in a ZGlobal variable list, cleanly separated from logic code.
• Units - manageable pieces of the machine. A unit is a combination of equipment that performs a repeatable sub-task: a transport unit, a handling unit, a camera station. Small machines have one unit; large machines have many.
• Equipment - the hardware objects. Digital I/O, actuators, axes, serial ports, EtherCAT masters. Each equipment type is a tested, reusable building block - instantiated, not reimplemented.

This hierarchy is enforced by the framework’s type system, not by convention. An engineer who has never seen your project before can navigate it from the top.

State machines

Every unit follows a defined lifecycle: Boot → Init → GoHome → Idle → Automatic → Stop → FaultReaction → Fault. The transitions are defined. Operators and other units interact with a unit by requesting state transitions, not by reaching into its internals.

Stop is always Stop. GoHome is always GoHome. The sequence that implements Automatic for a conveyor unit looks structurally identical to the sequence for an axis positioning unit. The business logic differs; the shape does not.

Sequences

Sequences use a REPEAT ... UNTIL step pattern with Await, Await2, and Await3 helpers. Multiple equipment objects can be commanded in parallel and the sequence waits for all of them without polling loops or state variables scattered across the function block. The sequence reads as a list of steps, in order.

Error handling belongs in the supervisor sequence, not inside the subordinate. Errors propagate up. A subsequence aborts with an error ID; the caller decides what to do - retry, skip, escalate.

Equipment library

The framework ships a tested library covering the most common hardware in machine automation:

• Actuators - all permutations of mono/bistable cylinders with one, two, or no limit switches. Each has configurable timeouts, simulation modes, and logging built in.
• Digital and analog I/O - simple wrappers with simulation support and helper methods.
• Axes - a unified OOP API covering Beckhoff NC Motion, EL70xx stepper controllers, and a growing list of CiA402 drives (Lenze, Keba, Servotronix, and others) and vendor protocols (Bosch IndraDrive, Lenze i950, Technosoft).
• EtherCAT - master, slave, and sync unit objects for monitoring and controlling the fieldbus.

Every equipment object supports simulation. Develop and test logic without physical hardware.

Logging

When a machine stops in production, the log tells you what happened. Zeugwerk’s logger writes structured, timestamped entries at millisecond resolution, asynchronously, without performance penalty. On a 1 ms cycle with 25% task utilisation, it handles 20 log entries per cycle - without external tools or C# helper programs.

Log levels follow the Apache Log4j convention: Trace, Debug, Info, Warning, Error, Fatal. Framework internals use Trace and Debug. Info and above are for your application code. Filter a log file and find exactly the events that matter.

Adoption

The most common objection: “We have running code. We cannot rewrite everything.”

You do not have to. The ZApp folder is self-contained. It integrates into an existing TwinCAT solution without modifying surrounding code. You introduce the framework unit by unit - new functionality in the Zeugwerk structure, legacy code untouched. Zeugwerk Creator’s Prepare Zeugwerk option makes this explicit.

Many teams adopt incrementally: the first project is a new unit inside an existing machine. Once it is running, the pattern is understood and the next project goes faster.

Support

Zeugwerk has a focused, specialist user base. You will not find answers on StackOverflow. What you will find, when you have a question, is the engineering team that built the framework. Support is direct and technical.

For teams with volume usage, there is direct roadmap access, training, and development support. At 100+ runtimes you are on the Enterprise tier: the complete framework source code is delivered into your own Git infrastructure on every release - so your investment is never contingent on a single vendor relationship.

Who it is for

• Teams building multiple machines with similar structure who need reusable, tested building blocks.
• Organisations wanting to standardise across engineers and projects.
• Teams migrating from unstructured code who cannot afford a full rewrite (see Adoption above).

Platforms & runtimes

Platform layer

The framework separates application logic (units, equipment behaviour, sequences, state machines) from runtime-specific integration. Most of the codebase is reusable across compatible PLC environments. What changes per target is the platform layer - compiler integration, I/O bindings, fieldbus access, and vendor-specific services. You keep the same architectural shape; we adapt the glue to the toolchain.

TwinCAT 3.1

Zeugwerk Framework ships for TwinCAT 3.1 today. This is our primary target: Creator, DevTools, CI/CD examples, and documentation assume TwinCAT unless stated otherwise.

CODESYS and ctrlX AUTOMATION

Ports to CODESYS-compatible toolchains and to ctrlX AUTOMATION are available on request. Scoping, effort, and timeline depend on your target runtime version, hardware profile, licensing model, and contractual setup. Contact us if you want to evaluate a port for a product line or a strategic migration.

Pricing

Framework is licensed per runtime. Volume discounts apply automatically.

The Enterprise tier - active automatically at 100+ runtimes - means your investment is never held hostage to a single vendor. You receive the complete source on every release and can read, audit, and extend the framework independently.

Getting started is free. Install the Framework directly from Twinpack, the open-source package registry for TwinCAT - search for Zeugwerk and add it to your project right from the IDE. No email, no separate download, no account required. Without a license key the Framework runs fully but displays a license warning - you can evaluate everything before buying.

Activating a license - no reinstall needed. Contact us to purchase a license and receive a key - same binary, same Twinpack package, no reinstall required.

Contact us for a quote →