Textile

How does a textile machinery engineering engagement work?

We engineer the motion, monitoring and embedded control layer inside textile machinery.

This is for the machine builders, integrators and MES providers whose product it is. That means EtherCAT (IEC 61158 Type 12) synchronization across hundreds to thousands of spindle and drive axes, per-spindle fault detection, and the data path the machine presents upward. You keep the machine, the brand and the mill; we take the parts that need a standing specialism:

• deterministic motion networks sized for the axis count the frame actually runs
• the per-spindle acquisition and detection layer, designed into your machine
• purpose-built multi-function IO devices, drive interfaces and gateways
• retrofit kits that bring an installed machine onto the plant network, packaged for your service organisation to fit
• obsolescence work when a controller or component generation ends before the frame does
• training your engineers on the technology, building the first implementation with them, then third-line support behind their first line

We do not install or commission machines in a mill. Where a design has to be integrated and tested, our team works with your engineering team: onshore during integration and test, remotely for the rest. The engagement page sets out the modes and how they are priced.

Why has monitoring become part of what a textile machine sells on?

Mills now buy on quality and uptime, and both are decided at the spindle.

A frame runs continuously with hundreds to thousands of positions. A break or a developing bearing fault costs output until someone finds it. A machine that names the position, and not just the frame, shortens that search. Per-spindle detection has moved from an option to an expectation because of it. The engineering behind it is networking and embedded work, not mechanical work, and it arrives in bursts: a monitoring generation added, a frame moved off an ageing fieldbus, or a controller taken through an end-of-life notice. 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 layers inside the frame: the motion network, the monitoring layer, the IO, the controller generation.

• A motion network that must scale. The segment engineered so the synchronised axes share one clock phase and setpoints land in a known slot, and so adding axes does not step down the control rate for the ones already running.
• A monitoring layer. For a machine that does not have it yet. Per-spindle sensing and embedded detection designed into the frame, with the fault classes and the reporting path defined against your machine.
• A retrofit kit. For the installed base. Edge sensing, a gateway and a calibration pass, packaged so it can be fitted inside a maintenance stop.
• A fieldbus that has to be upgraded. Migration onto real-time Ethernet, with your processing logic and IP carried across to new sensors, controllers and protocols.
• A cabinet of hardwired IO. Several off-the-shelf modules replaced by one purpose-built multi-function device, cutting the loom back to a network drop.
• An end-of-life part. A chip, controller or electronics notice on a frame that is still selling, assessed before anything is redesigned.
• Team bring-up. Your engineering team brought up to speed. Training, then building the first implementation alongside your team, with third-line support behind them.

Which protocols and bus systems turn up on a textile machine?

A textile machine carries more than the motion bus, and rarely all from one generation.

EtherCAT and Sercos III appear where a builder has specified a coordinated motion package, and Sercos in particular tends to arrive as part of a drive vendor’s own offering. Modbus RTU and Modbus TCP are widespread on spindle-level monitoring and basic control, especially on cost-effective machinery from builders outside Europe and North America, and they are not going anywhere. IO-Link covers the sensor layer beneath either. The controller itself is usually programmed in the IEC 61131-3 languages regardless. Most of the work is at the joins: getting a monitoring layer that speaks Modbus and a motion layer that speaks EtherCAT to produce one coherent picture of the machine, and then presenting that upward over OPC UA without disturbing either.

Which spindle-level fault-detection methods can you integrate?

We integrate four signal sources, grouped by what each detects: process faults, machine state and equipment health.

They differ in cost per spindle and in the fault classes they detect reliably. The machine integration decision is yours; our part is the acquisition path and the detection logic around the signals available.

• Traveller speed: process faults. A Hall-effect or proximity sensor measures each traveller’s movement directly. Loss of movement indicates a yarn break, reduced speed indicates slack, and an abnormal speed excursion indicates a tension or traveller anomaly. Comparing positions across a frame of near-identical spindles detects more than any single-position threshold, which makes this the most direct per-spindle channel.
• Drive and controller feedback: machine state. Drive status, actual-speed feedback and fault codes show whether a spindle or frame is running, stopped or starting, and separate a genuine stop from a yarn fault. How fine-grained that is depends on how the drives are organised.
• Motor-current signature: equipment health. The drive is already there, so current is the cheapest channel. It shows motor and drive-train health, start and stop transients and frame-level load anomalies. Whether it can single out one spindle’s yarn fault depends on the drive architecture.
• Vibration and acoustic: equipment health. Vibration trends bearing degradation, imbalance, misalignment and looseness, evaluated against ISO 20816 where it applies. Acoustic sensing adds evidence of friction and impacts.

The engineering decision underneath is the same in all four: sample fast enough that a fault is visible while it develops, and process close to the spindle instead of sending raw signals to a PLC or historian. Onboard signal processing such as FFT-based current-signature analysis or vibration envelope detection means a fault is flagged within a machine cycle rather than on the next batch upload.

How do you design monitoring that can be fitted in a maintenance window?

We make the fitting sequence part of the design, so it does not become a commissioning problem.

Wiring and edge hardware are specified to go in first; the per-spindle baselines then calibrate against the running machine in a short pass afterwards. That keeps the work inside the maintenance stop the mill already schedules, instead of creating a separate downtime event, which is usually what a builder has to promise before a mill will agree to a retrofit at all. Whoever fits it, your service engineers or the integrator, is following a defined sequence, and our team works behind them on the design and the test.

What do you cover on the drive side?

We cover the device layer that feeds motion and the control layer that runs it.

• Encoder integration, which is where a lot of textile motion actually gets its feedback. Our team has integrated optical rotary encoders as small-footprint slaves on real-time Ethernet and fieldbus for an encoder manufacturer whose parts ship into textile machinery alongside packaging, elevators and inkjet printing. That is device-level protocol work rather than a mill installation, and it is the same job whichever machine the encoder ends up in.
• Drive control above it. Our team has designed and integrated motor drive control systems onto specific platforms over real-time Ethernet: the control implementation on the builder’s chosen hardware, on the network the machine runs.
• On Sercos III the boundary is narrower. Slave-side integration is largely kept in-house by the drive vendors, so where we add value is at the edges, in gateways and in making a motion system interoperable with OPC UA instead of in the drive stack itself.

How does textile spindle monitoring on EtherCAT scale with spindle count?

Spindle monitoring scales by segmentation: every spindle added to a segment spends part of the same cycle budget.

Axis count is usually the binding constraint, not any single drive loop. The design question a frame poses is how many segments the monitoring and motion traffic needs, and where the split between them falls. What sets the target is the spindle itself: a ring frame runs up to roughly 20,000–25,000 rpm, so one revolution takes 2.4 to 3 ms, and a cycle under a millisecond gives several samples per revolution, enough to see a break or a developing fault while it happens.

On delivered spindle-monitoring work our team sized EtherCAT segments to hold cycle times in the 250 µs to 1 ms range as node counts scaled into the hundreds, keeping frame length and topology inside that budget so that adding axes never stepped down the control rate for the ones already running. Typically the tight end belongs to smaller segments with a compact process image, and a segment carrying hundreds of nodes sits toward the millisecond end. Past that the traffic is split across segments, and that split is designed before commissioning instead of found during it.

What makes the budget hold is common to any real-time control network: a clock every device in the loop actually shares, a physical topology matching the engineered one, and per-device diagnostics fast enough that a node dropping out is seen on the cycle it fails. The mechanisms differ by protocol and are covered on the real-time Ethernet page.