Unstructured automation software is an organisational risk: it slows every new project, makes engineer turnover expensive, and makes production incidents harder to triage, explain, and close out.
- Zeugwerk Framework gives every project and every engineer the same proven structure. Engineers onboard in days, not months. Service calls and handovers cost less.
- The framework delivers drive-based motion control: even at 1-10 axes, NCMotion savings alone can outpay the framework license - and it scales to 100+ axes in production on a standard Beckhoff PC.
- One toolchain, one accountable team - tools only, development support, or a complete turnkey machine.
- At 100+ runtimes the full Framework source is delivered to your own Git on every release. No vendor lock-in.
If you want the structural problem solved by people who have already solved it for themselves - Zeugwerk is where to start.
The call nobody wants to receive
“The machine stopped. What’s wrong?”
An engineer opens a remote connection to a live production system. There are no log files. The only diagnostic tool is the TwinCAT online view. Setting a breakpoint is not an option - halting the PLC halts the machine. The engineer starts reading through a sequence function block written by someone who left two years ago, hunting for the specific state the machine was in when it stopped.
This scenario plays out constantly in automation. It is not caused by incompetence. It is caused by the absence of structure.
Why this keeps happening
Automation software was never treated as software engineering. It was treated as wiring.
The mental model that shaped PLC programming - ladder diagrams, direct I/O manipulation, logic that mirrors the physical panel - was designed for a different era of machine complexity. It worked when a machine had thirty I/O points and one engineer who would be there for its entire life. It does not work when a machine has four hundred I/O points, a motion system, a vision system, and a software team that turns over every few years.
The industry knows this. Most automation engineers have felt it. But the toolchain, the training, and the project timelines all push in the same direction: get it running, ship it, move on. The structural debt accumulates invisibly until the machine stops in production and nobody can read the code fast enough to fix it.
Where Zeugwerk comes from
We built Zeugwerk because we were on the receiving end of that problem.
The framework did not start as a product. It started as the internal architecture we developed because we were tired of reimplementing cylinder logic on every project, tired of onboarding engineers who needed months to understand project-specific conventions, and tired of shipping code that worked at commissioning but that nobody - including us - wanted to touch two years later.
The toolchain around it - Creator, Twinpack, DevTools - came from the same place. Each tool exists because we needed it and it did not exist.
That origin matters, because it means the framework was validated on real machines before it was sold to anyone. It is not a consulting firm’s methodology. It is not a framework designed by people who studied automation from the outside. It is the architecture used on the machines we still deliver and maintain today. Meet the team →
What a framework actually changes
A framework is a contract. When every project in your organisation follows the same architecture, engineers can read unfamiliar code, extend existing projects, and onboard in days rather than months.
Zeugwerk Framework gives teams a defined hierarchy - Application, Units, Equipment - enforced by the type system, not by convention. State machines have a defined lifecycle. Sequences read as ordered steps. Equipment is instantiated from tested building blocks, not reimplemented from memory. Logging writes structured, millisecond-resolution entries without external tools or performance penalty.
The most common objection: “We have running code. We cannot rewrite everything.” You do not have to. The framework integrates into an existing TwinCAT solution. You adopt it unit by unit - new functionality in the Zeugwerk structure, legacy code untouched.
Why not just build your own framework?
Some teams do. It takes longer than expected, costs more than planned, and produces something that works for the team that built it and nobody else.
A framework is not a set of base classes. It is a set of decisions - about hierarchy, state machine lifecycle, error propagation, logging, simulation, naming conventions - made consistently and maintained over time. Making those decisions well requires having built enough machines to know which ones matter. Maintaining them requires dedicated effort that competes with project delivery.
The teams that build their own frameworks typically end up with something that solves the immediate problem and creates a new one: a proprietary architecture that new engineers have to learn from scratch, with no documentation, no community, and no one responsible for keeping it current.
Zeugwerk Framework is maintained by the team that uses it on live projects. When a new drive protocol is needed, it gets added. When a pattern turns out to be wrong, it gets fixed.
Why not just hire a TwinCAT contractor?
You can. A contractor will write TwinCAT code. Whether that code will be readable, maintainable, or structurally consistent with the rest of your codebase depends entirely on who you hire and whether you have the internal expertise to evaluate it.
The structural problem in automation software is not a shortage of people who can write PLC code. It is a shortage of shared standards for what good PLC code looks like. A contractor working without a framework will make the same architectural decisions project by project that your own team makes - and the results will be just as inconsistent.
When Zeugwerk delivers software - whether as a standalone engagement or as part of a turnkey machine - it is delivered against a defined architecture that your team can read, extend, and maintain after we leave. That is the difference.
Lower TwinCAT licensing costs
One design goal of the Zeugwerk Framework is to reduce the number of TwinCAT add-on licenses a machine requires. TwinCAT’s strength is its modular licensing model - but that same modularity means costs can accumulate quickly across a large number of runtimes. Where the framework can cover a capability directly, you do not need to license it separately from Beckhoff.
Motion control is the most quantifiable example. TwinCAT NC/PTP (NCMotion) is an add-on license priced per runtime, scaled to axis count and platform level. For machines with higher axis counts or performance tiers, those costs add up quickly. The Zeugwerk Framework license at the 1-25 runtime tier costs 434 € pro Runtime. A single machine with drive-based motion can save more in NCMotion licenses than the entire framework license costs.
The framework ships libraries that control servo drives and EtherCAT stepper terminals directly through their own onboard motion controllers - no NCMotion task involved. Full technical detail →
Hardware costs follow. A wider range of drives and stepper terminals qualifies: not just those paired with NCMotion, and typically at lower unit cost. And because motion computation stays in the drive, the PLC runs on a lower-tier industrial PC.
Zeugwerk has productive machines running more than 100 axes on a single High Performance PC at Platform Level 80 - without a single NCMotion license.
When you need the machine, not just the tools
The framework gives you the building blocks to build better machines. But some projects start with a different question: “Who builds the machine?”
Together with our engineering partners Plötzeneder GmbH and Hinstech GmbH, Zeugwerk delivers complete turnkey machines - mechanical, electrical, and software - from a single source. No handover gaps between disciplines. No finger-pointing when something does not fit. One team that owns the full scope.
What the partnership covers:
- Mechanical engineering and process development - Plötzeneder GmbH has been designing and building special-purpose machines since 1977, with deep experience in pharmaceutical and medtech applications. They own the mechanical scope from the first concept sketch through to finished manufacturing documentation.
- Electrical engineering and CE compliance - Hinstech GmbH covers hardware design, electrical schematics, cabinet engineering, and CE conformity assessment. The delivered machine is safe, documented, and regulatory-ready from day one.
- Automation software - Zeugwerk delivers the PLC application using its own framework. Structured, tested, and documented code. Not throwaway project code - software your service team can maintain and extend after handover.
The three disciplines work from a shared project definition. Mechanical interfaces are defined before electrical routing begins. Electrical topology is known before software I/O lists are written. Changes propagate through one coordinated team, not across three separate inboxes.
As a certified Beckhoff Solution Provider, the software stack sits inside the established Beckhoff ecosystem. Standard licensing. Standard toolchain. No exotic dependencies your service organisation has never seen before.
Talk to us about your project →
What customers have found
Through the introduction of modern software paradigms, cross-team and cross-project software creation became genuinely feasible, opening completely new perspectives for the further development and reuse of every software project.
— Edmund Jenner · Nordfels GmbH
The introduction of the Zeugwerk Framework came at exactly the right time for us. This enabled us to significantly accelerate our cross-location harmonisation efforts. The framework offers invaluable implementation advantages, particularly for the planning of our series machines, which are manufactured from similar machine elements in different variants.
— Josef Unterrainer · Development Department · Durst Group
Why Zeugwerk
The structural problem in automation software is real, well-understood, and largely unsolved - not because the solution is hard to describe, but because it requires sustained investment that most teams cannot justify on a project-by-project basis.
It is not a methodology sold by people who study automation from the outside. It is an architecture maintained by the team that still uses it on live machines, and that still has to live with the consequences when something is wrong.
In short
Most teams arrive with a mix of these needs rather than a single checkbox. If you are unsure where you fit, contact us and we will map it together.
Download the 60-day trial → Read the documentation → See our services → Contact us →