Printing & Converting

How does a printing machinery engineering engagement work?

We engineer the controls, drive-synchronisation and network layer inside printing machinery.

This is for the machine builders, converters and retrofitters whose presses they are. You keep the machine, the brand and the end customer; we take the parts that need a standing specialism:

• coordinated motion and drive synchronisation on PROFINET IRT, POWERLINK or EtherCAT
• sensor-path handling, so a reading is qualified before it is allowed to move an axis
• purpose-built multi-function IO devices, drive interfaces and gateways that replace several off-the-shelf modules at once
• migration off an ageing fieldbus onto real-time Ethernet, carrying your processing logic across without rewriting it
• a second network on an existing control product, so one product line serves plants that expect different interfaces
• obsolescence work and controls retrofit on installed machinery, staged so the press is proven at speed before the old controls come out
• training your engineers on the technology, building the first implementation with them, then third-line support behind their first line

Our team has extensive experience with domain-specific machine vendors in this sector, on new builds and on retrofits. The engagement page sets out the modes and how they are priced.

Why is the controls specialism bought in rather than staffed?

The work arrives in bursts, and the people who do it are hard to keep busy between them.

Coordinated motion on a press is a networking and embedded problem before it is a mechanical one: everything upstream (tension, speed, ink, substrate) arrives at the same two questions, whether the command reaches the drive in time and whether the reading it came from was real. The engineers who answer those well are hard to keep busy inside one machine programme. The same arithmetic covers the rest of this page. Adding POWERLINK alongside PROFINET is weeks of specialist work and then nothing for a year. So is a controller family going end-of-life, or a first custom IO device, or a migration off a fieldbus that has served the machine for fifteen years. Each is a project with a beginning and an end, on a machine that is otherwise yours.

Which slices of the work can you support?

Any one of the parts that decide accuracy at speed: the motion network, the sensor path, the controls generation.

• Coordinated motion on a new machine. The network engineered so the synchronised axes share one isochronous clock phase and setpoints land in a known slot every cycle. Register control, shaftless drive coordination and cross-cutting are all this problem wearing different clothes.
• A lying sensor path. Mark, edge or length-error qualification, so a wrong reading is classified as a fault instead of being chased into a correction that wastes web.
• A cabinet of hardwired IO. Several off-the-shelf modules replaced by one purpose-built multi-function device, cutting the wiring loom back to a network drop.
• A fieldbus that has to be migrated. Migration onto real-time Ethernet, with your processing logic and IP carried across to new sensors, controllers and protocols.
• An end-of-life part. A chip, controller or electronics notice on a press that is still selling, assessed before anything is redesigned.
• A second network on an existing product. The same control product taught to speak PROFINET and POWERLINK, or EtherCAT, so it can be sold into plants that expect different things.
• A controls retrofit on installed machinery. A new drive network and control hardware under an unchanged mechanical machine, commissioned in stages.
• Team bring-up. Your own engineers brought up to speed. Training, then building the first implementation alongside your team, with third-line support behind them afterwards.

How do you design for accuracy at web speed?

We hold the measurement-to-setpoint path inside a jitter budget the correction interval can absorb.

That path decides it, not the drive’s own loop. If its jitter is comparable to the correction interval, the machine corrects against stale positions and hunts. We engineer the network so the coordinated axes share one isochronous clock phase and the correction lands in a known slot every cycle, which is why the synchronisation figure matters more than raw cycle time. On delivered work that means clock synchronisation below 1 µs across the axes, 3 µs worst case, with the correction path inside a jitter budget under 5 µs. Register control is the best-known case, and the same budget governs shaftless drive coordination, cut-to-mark and cross-cutting on a converting line, and any splice or turret sequence tied to machine state.

How do you stop a bad reading from becoming a bad correction?

We handle it at the sensor edge, before a reading is allowed to move an axis.

A ghost mark, a missed mark, a stretched repeat length or a mis-tracked edge all present as a sudden deviation. Readings are qualified against the expected geometry and window before they are allowed to move an axis, so a wrong one is classified as a fault and reported.

How do you build one machine for plants that expect different networks?

One control product carries both stacks, and the choice follows what the builder needs to own.

Where one company supplies both the drive and the controller, an open-source stack lets them own that product line end to end without a dependency they did not choose. Where the drive comes from a third party and the plant’s installed base is PROFINET, the certified commercial path is the right one. As an example, the same OEM control our team worked on supports PROFINET and POWERLINK, and on the POWERLINK builds the drives and the measurement systems were both on that network. We also work with third-party stacks a builder has already licensed. The decision is theirs; our part is making the chosen one hold its timing on their hardware.

What happens when the electronics go end-of-life before the press does?

We scope how much of the control system has to move with the obsolete part.

The mechanical machine usually has years left. Sometimes it is a drop-in replacement and a driver change; sometimes the replacement has a different peripheral set and the firmware has to be reworked around it. We assess first, so the decision is scoped engineering. The obsolescence management page covers how that work runs.

Two things matter more here than the part itself:

• Your processing logic. It is your IP and it comes across. The logic on the old controller is accumulated over years of machines, and a migration is a port of it onto new controllers, sensors and protocols. It is not an opportunity to rewrite the machine, and treating it as one is how a scoped job becomes an open one.
• Hardwired IO. A controls generation change is the moment to take it out. The wiring loom is being disturbed anyway. Doing the wiring simplification at the same time costs a fraction of doing it as its own project later, and it is usually the change that shortens commissioning most.

What does a controls retrofit on an installed machine involve?

Replacing the control and network layer without disturbing the machine around it.

New drive network and control hardware, the machine’s own logic re-implemented against them, and commissioning staged so the press is proven at speed before the old controls are removed. The acceptance criterion is the same as on a new build: the machine holds its accuracy at production speed, measured the way it was measured before.

What other press and converting problems can you help solve?

We cover the rest of the press too, and stay with a builder's programme across several of these.

A builder already has their own answer to most of the list below, and where we come in is usually one of them, on their terms.

• Tension control across unwind, process and rewind, where the same synchronisation quality decides whether a thin substrate survives a speed change.
• Shaftless drive coordination, replacing a mechanical line shaft with an electronic one, which is where most retrofits actually start.
• Splice and turret sequencing on running webs, a timing problem tied to machine state rather than to a control loop.
• Cut-to-mark and cross-cutting on converting lines, the same sensor-to-actuator path as register with a knife at the end of it.
• Web guiding and edge tracking, the same qualification discipline applied to a different sensor.
• Inspection and defect logging on the running web, where the reporting path must stay clear of the isochronous one.
• Line data upward to supervisory and MES layers over OPC UA, again without any of it touching the isochronous path underneath.

What has to be true of the network before coordinated motion works?

Three things have to be true: a common clock, a matching topology, and a device description treated as an interface.

All three are settled at commissioning, and not typically by product selection.

1. A common clock. Every device in the control loop has to sit inside its domain. A device that is merely on the same wire but outside the domain will appear to work and will drift. Each protocol gets there differently: EtherCAT distributes a reference time from one clock and each slave corrects itself against it, PROFINET IRT runs a sync domain with a sync master and a scheduled transmission phase, and POWERLINK gives every node its slot in a cycle the managing node polls. Same requirement, three mechanisms, and the commissioning check is the same in all three: is every device that matters actually inside the domain.
2. A physical topology matching the engineered one. Isochronous schedules are computed against a specific wiring layout, so the machine has to be cabled the way the engineering says, and the network has to be able to prove it was.
3. The device description. It is an interface, not a detail. Every protocol has its own form of this file (GSDML on PROFINET, ESI on EtherCAT, XDD on POWERLINK) and it defines how a device’s data is laid out to everything else on the network. Changing that layout is a compatibility event, not a firmware detail: it is how a routine drive replacement turns into a re-commissioning job.

Each protocol implements those three differently, and the mechanisms are covered on the real-time Ethernet page.