Jeff Johnson, mechatronics product manager, Beckhoff USA: The relationship becomes much more collaborative and iterative across the board. The controls programmer no longer has to be brought in only after the mechanical design is substantially complete. I’ve found that the most successful machine designs happen when both engineering disciplines can work together to develop the machine concept from the beginning.

A common first instinct is to apply an intelligent transport system to a traditional linear or rotary indexing layout. The stations remain evenly spaced, every product advances simultaneously, and the longest process still establishes the overall machine cycle. That may work, but it leaves many of the technology’s largest benefits unused.

The engineering team should instead begin by examining the duration of every process. How many movers does each station require? Where should products accumulate? Could a longer process be divided or duplicated across two or three stations to shorten the overall cycle? Could the mechanical design of a station be changed to reduce its processing time? Answering these questions requires input from both mechanical and controls engineering.

The mechanical engineer still owns critical decisions involving tooling, product fixturing, payloads and overall mechanics. The tooling may also need to accommodate multiple product formats. The controls engineer takes greater responsibility for mover coordination, traffic management, buffering, station synchronization and recipe-driven motion. However, this should not become a handoff of responsibility from one discipline to the other. It should be a collaboration.

Software-controlled mover spacing can also eliminate many mechanical changeover elements and avoid massive amounts of downtime. Rather than changing various parts to establish a new pitch, XTS or XPlanar can call up new mover positions and motion profiles from a recipe. In one packaging machine application, the XTS-based design eliminated about 100 mechanical parts from the infeed, including chains, flights, pushers and rotation mechanisms.

The best results come when mechanical and controls engineers treat software-defined motion control as a design tool from the outset. 

As industrial motion relies increasingly on software layers, tracking algorithms and centralized data, what new skills do standard field maintenance technicians need to troubleshoot these systems?

Jeff Johnson, mechatronics product manager, Beckhoff USA: The technician’s foundational skills remain extremely important. Maintenance personnel still need to understand the machine’s operating sequences, read electrical drawings, inspect mechanical components, evaluate sensors and actuators and use tools such as a multimeter. What is changing is how quickly they can combine those skills with software- and EtherCAT-based diagnostic information.

Once a machine has completed factory acceptance testing (FAT) and operated successfully in production, an unexpected problem is often caused by a physical condition: loss of power, a damaged sensor, a loose connection, mechanical interference, product debris or a failed component. The software did not suddenly rewrite itself. The first task is to determine what changed on the machine.

Human-machine interfaces (HMIs), event logging and data acquisition tools can make that investigation far more efficient. Instead of opening PLC code and tracing through multiple layers of logic, a technician should be able to begin at the HMI. A well-designed diagnostic interface can show the affected mover, its physical location, the current machine state, associated I/O and the sequence of events leading to the stop.

TwinCAT Scope, for another example, can display real-world I/O signals alongside PLC variables and motion data. TwinCAT EventLogger provides a time-stamped history that helps identify what happened first. EtherCAT diagnostic controls can visualize the network topology and device status, while XTS-specific visualization tools can display the track, individual movers, motor modules and diagnostic conditions.

Technicians should also continue using their eyes and ears. Every machine has a heartbeat. An XTS with 50 or 100 independently moving movers will sound different from a conventional indexer in which everything moves simultaneously, but it still develops a recognizable rhythm. Changes in sound, vibration, flow or product spacing can provide valuable clues.

High-speed intelligent transport and motion systems generate massive amounts of real-time operational data. How should a system integrator architect the edge-computing or PLC infrastructure so this traffic doesn’t bottleneck the primary machine-control loops?

Jeff Johnson, mechatronics product manager, Beckhoff USA: The guiding principle is simple: Data collection must never compromise deterministic machine control. The motion and safety tasks should retain the required CPU time, network bandwidth and task priority under the worst anticipated operating conditions.

That begins with separating control from analytics logically and, where required, physically. Time-critical motion, PLC and machine safety functions should run in deterministic real-time tasks with defined priorities and adequate processing bandwidth. Analytics, database communication, dashboards and cloud connectivity should operate on separate CPU cores or in lower-priority tasks when priorities need to be set.

The next step is to decide what data truly needs to leave the controller. Sending every variable, bit and byte continuously is rarely useful. Some values only need to be transmitted at startup, after a recipe change or when they cross a threshold. Others can be aggregated into cycle times, averages, counts or condition indicators in an edge computer. Critical production data, faults and other urgent events should receive priority rather than competing with a constant stream of low-value data.

There are cases in which full-resolution data is valuable, particularly for intermittent troubleshooting. A practical approach is to record this data locally in a time-synchronized ring buffer. The system continuously retains a defined period—perhaps the preceding hour—and saves that buffer when a fault or trigger condition occurs. This provides detailed before-and-after information without continuously flooding a database or cloud service.

TwinCAT Analytics Logger can acquire process-image and PLC data cycle-synchronously, store it locally on a hard drive or transmit selected data through MQTT. The information can then be analyzed locally, on another computer or in a cloud environment. Once engineers identify the variables and calculations that deliver useful insights, they can reduce the ongoing data stream to the essential values. A message broker also helps decouple the machine from downstream applications. The controller can publish approved data to the broker, while authorized systems subscribe to it without querying the real-time controller directly.

For difficult intermittent problems, synchronized machine vision can add important context. Aligning images with real-world I/O, PLC states and motion data can reveal not just that a fault occurred, but what was physically happening at that moment. There’s also an available Event Video Playback add-on feature that provides an easy-to-use video review of events/alarms as logged events directly from TwinCAT HMI Event Viewer. 

With advanced transport systems making manufacturing processes highly dynamic and recipe-driven, how should the HMI evolve to help operators visualize complex routing, bottlenecks and system errors in real time?

Jeff Johnson, mechatronics product manager, Beckhoff USA: The HMI should evolve from a collection of buttons and alarm lists into a live operational model of the machine. With products moving on dynamic intelligent transport systems, a static screen cannot adequately explain what the system is doing or why.

At the highest level, operators should see the actual transport layout, the location and status of each mover, active product recipes, station conditions and the direction of product flow. Use of color and animation can highlight blocked movers, accumulating queues or stations operating outside their target cycle times. Rather than displaying every available data point, the overview should direct attention to exceptions.

The next level should provide production context. Operators need to see buffer utilization, actual versus target dwell time, station throughput and the distribution of products among parallel processes. If a particular station becomes the constraint, the HMI should make that visible before it stops the machine. On an XPlanar system, the display should also show active routes, unavailable tiles and rerouting decisions (Figure 2).