Getting a Removal Station in Step with the Line: Hardwired I/O, Modbus TCP or EtherCAT

The largest gap between a machine demo and a line installation is rarely whether the screws come out. It is whether the station keeps step with everything upstream and downstream. Keeping step decomposes into three things: signal handshaking, meaning when I may move and how I tell you I have finished; cycle synchronisation, meaning my motion starts aligned with the line takt; and data upload, meaning the torque, result and timestamp for each screw must be visible to the layer above. These three have completely different technical requirements. Discuss them together and you get mismatches such as using EtherCAT to transmit one pushbutton signal, or polling a servo axis over Modbus.

The simplest and most reliable layer is hardwired I/O. One output asks upstream for release, one input receives part-in-position, one output reports motion complete, plus safety-related signals for emergency stop, safety gate and low air pressure. Its strengths are determinism and immunity: a signal is a voltage level, with no protocol stack, no connection timeout and no version compatibility, and a multimeter is enough to diagnose it. The weakness is that point count grows linearly with function. Every added function means another pair of wires, and every design change means re-terminating, re-numbering and re-validating. Once a station's function is stable, hardwiring is in fact the least troublesome option.

Modbus TCP is the default on many projects because it has almost no barrier to entry: one cable, one IP address, one register table, and PLCs, robots and PCs can all speak it. It belongs on the non-real-time data channel, carrying recipe downloads, parameter switching, status and counter reporting, and alarm text. Placing it in a control loop causes trouble because its timing is not deterministic. Polling period depends on network load and master scan, slave response time is not guaranteed, and a lost packet waits for a timeout and retry. The symptom is occasional motion delay or missed steps. These effects almost never appear in a lab and only surface on a fully loaded line, where diagnosis is expensive.

EtherCAT and Profinet IRT are a different order of magnitude. Cycle times reach 100 microseconds to 1 millisecond with distributed clocks, so slave outputs are aligned by the master. That suits two situations: multiple axes requiring interpolation or strict synchronisation, such as two axes descending together or a rotary axis coordinated with a linear one; and vision that must be hardware-triggered during motion, where the trigger instant has to correspond precisely to position. The price is master licensing, slave conformance, topology and wiring discipline, and the skill level of the people commissioning it. Those costs may not pay off on a single station, but they fall when the whole line shares one architecture, because spares, diagnostic tools and skills are shared.

Four questions settle the selection quickly. First, how many axes need interpolation or synchronisation? With one axis moving, hardwiring plus step and direction, or a simple fieldbus, is enough; with two or more moving together, a real-time bus deserves consideration. Second, is vision taking a static image or triggering during motion? Static imaging works fine with a software trigger; flying capture requires hardware triggering aligned to position. Third, how often does the model change? Several recipe changes a day need a channel that can push parameters quickly, where Modbus TCP or OPC UA is far more reliable than editing an HMI by hand. Fourth, does the upper layer need real-time curves? Results and statistics alone need only ordinary Ethernet; millisecond torque curves must be buffered in the controller and uploaded, not pushed over the network in real time.

Cycle synchronisation itself follows three common patterns, each with its own trap. The first is a line-wide heartbeat, where every station moves on a shared takt signal. It gives tidy takt and easy capacity maths, but one slow station holds the whole line and a lost heartbeat stops everything at once. The second is self-timing after an upstream part-in-position signal. It decouples stations so a single failure does not stop upstream, but accumulated error in the station must be corrected by sensors or it will drift. The third is central scheduling by the line PLC with the station acting as a slave. It gives global optimisation and easy work-in-process management, but concentrates control logic so every PLC change touches all stations. Most real projects mix the second and third: motion is sequenced locally, while release and blocking are managed by the line.

Handshake detail causes more failures than protocol choice. The most common mistake is a single complete signal, raised by the station when removal is done and read by upstream as permission to release. The problem is that complete covers at least three states: success, removal failed and needs manual handling, and station fault stop. Compressed into one bit, upstream can only release everything or wait everything, so either defects travel downstream or the line jams. A safer arrangement is four lines for request, acknowledge, busy and error, plus timeout logic: if no acknowledge arrives within a defined time after a release request, raise an alarm rather than keep waiting. Separately, emergency stop, safety gates and light curtains must never sit on a general-purpose fieldbus. They belong on hardwired safety circuits or a dedicated safety bus. That is not conservatism, it is the standard.

Data upload should be completely separated from real-time control. Never place HTTP requests or database writes inside the control loop, because one network hiccup can stop a mechanism mid-stroke. A workable structure has the controller buffer the most recent records locally while a separate reporting process pushes them to MES or a database in batches, caching during outages and backfilling on recovery. OPC UA suits structured data with a semantic address space, MQTT suits high-frequency small messages over weak networks, and neither belongs in the control loop. This separation matters especially on a station with an automatic vision screw removal machine, because vision results carry an order of magnitude more data than a handful of discrete signals, and mixing them into the control channel stretches the cycle.

In engineering practice the communication scheme is a design input at proposal stage, exactly like the fixture and the frame. It determines what goes in the cabinet, how cable trays run, whether switches and safety modules are needed, and what architecture the host software is written against. Raising the question of line integration after the machine is built usually ends with a gateway doing protocol conversion: the function works, but takt alignment and diagnostics are compromised. When integrating small screw removal equipment into a line, the smoother order is to obtain the line's takt definition and handshake timing diagram first and then define the station architecture, not the reverse.

One final criterion is easily overlooked: diagnosability. Over three years of production, the value of a communication scheme shows up when something breaks. Hardwiring lets you probe point by point with a meter; a fieldbus lets you read slave status words, frame loss counters and topology diagnostics. Compared only on whether it communicates, both pass. Compared on how quickly a fault is fixed, the answers diverge sharply. Stations in the M0.8 to M2.0 range are usually densely packed and individually modest in value, yet a stop affects an entire line segment, which is why the M0.8-M2.0 screw removal solution treats the communication interface as an option rather than a fixed item during standardisation, so one mechanical platform can serve different line architectures.