Share this article
Continue reading with these related posts
Not every robot is the right robot. Learn how collaborative robots and traditional industrial robots differ in safety requirements, flexibility, programming complexity, and total cost — so you can choose the technology that actually fits your operation.
The robot is only as reliable as the fixture holding the part. Learn how to design jigs and fixtures that present workpieces consistently to your robot — including locating principles, quick-change tooling, sensor integration, and a real case study from our digital print shop.
Most automation projects don't fail because the technology doesn't work — they fail because the process around the technology wasn't ready. Here are the four failure patterns we see most often, and what you can do before you start to avoid them.
In the previous post, we covered the mechanical foundation of a reliable robotic cell — fixtures that locate parts repeatably, quick-change tooling systems, and sensors that catch loading errors before the robot moves. Once the physical cell is solid, the next challenge is connecting the robot to everything else: the conveyors that deliver parts, the machines that process them, the quality systems that inspect them, and the PLCs that coordinate the whole operation.
This is where most automation projects discover their hardest problems. The robot vendor's demo worked perfectly in isolation. But your production environment is not a demo — it is a network of machines from different eras, different manufacturers, and different communication philosophies, all of which need to cooperate in real time. Integrating a robot into that environment requires understanding industrial communication protocols, handshake logic, timing dependencies, and the unique challenges of making modern automation talk to equipment that predates it by twenty years.
The good news: these problems are solvable. The honest news: solving them takes time, planning, and a realistic commissioning budget. This post gives you the conceptual foundation to approach integration systematically rather than improvising under deadline pressure.
Integration Cost Is Often Larger Than Robot Cost
Industry data consistently shows that the robot hardware represents roughly 25–40% of total robotic cell project cost. The majority of budget goes to integration: controls engineering, wiring, safety system design, software development, commissioning, and operator training. A $50,000 cobot can sit inside a $150,000 project. Underestimating integration cost is the single most common budget overrun in automation projects.
Programming a robot to pick, move, and place a part is a contained problem — you control all the variables. Integration is an open-ended problem involving systems you did not design, documentation that may not exist, and behaviour that only reveals itself when you run the full system under production conditions.
Several dynamics make integration consistently difficult. First, existing equipment was not designed with your robot in mind. Machines built in 1998 were designed to operate stand-alone or to interface with other equipment from the same era — not with a modern Ethernet-connected cobot. Adapting them requires understanding their existing control logic, finding interface points, and adding hardware or software to bridge the gap.
Second, timing assumptions break in production. During commissioning you test with cooperative operators, clean parts, and a fresh machine. In production, cycle times vary, parts are occasionally misoriented, machines need clearing, and networks experience intermittent delays. Integration logic that assumes fixed timing fails when reality deviates from the assumption.
Third, failure modes multiply. A standalone robot cell has one control system. A robot cell integrated with a conveyor, a PLC, a vision system, and an ERP has five. Each interface is a potential failure point, and failures at the interface are often the hardest to diagnose because the fault may be visible in one system but caused by another.
Understanding these dynamics is the first step toward building integration that handles the real world rather than the ideal one.
Before you can design the integration between a robot and another machine, you need to understand the communication infrastructure that will carry signals between them.
A PLC is a ruggedised industrial computer designed to execute control logic in real time — reading inputs from sensors and switches, running a control program, and writing outputs to actuators and machines. PLCs form the control backbone of most manufacturing facilities, and they are almost always involved in any robot integration.
PLCs operate on a scan cycle — reading all inputs, executing the control program, writing all outputs, then repeating. Scan cycles typically run at 10–100 ms intervals depending on the PLC and the program size. This is fast enough for most automation tasks but can create challenges when precise timing is required across multiple devices.
Major PLC platforms include Allen-Bradley (Rockwell Automation), Siemens, Mitsubishi, Omron, and Schneider. Each has its own programming environment, network protocols, and I/O ecosystem. When your robot needs to communicate with a PLC, the choice of protocol depends heavily on which PLC platform is present in your facility.
Understanding the most common protocols helps you ask the right questions during project scoping and avoid incompatibility surprises during commissioning.
Discrete I/O — The oldest and most universal method: individual digital signals wired point-to-point. A "robot ready" signal is a 24V digital output from the robot wired to a 24V digital input on the PLC. Simple, robust, hardware-confirmed, and compatible with virtually any equipment regardless of age. The limitation is scalability: ten discrete signals require ten wire pairs. For basic coordination — conveyor start, robot request, machine ready, cycle complete — discrete I/O is often the right choice.
Modbus TCP / Modbus RTU — Originally developed in 1979, Modbus remains one of the most widely supported industrial protocols in the world. Modbus TCP runs over standard Ethernet; Modbus RTU runs over serial (RS-485). Most cobots and industrial robots support Modbus TCP natively, and a very large proportion of PLCs and machines — including equipment from the 1990s and 2000s — have Modbus capability. Modbus is simple, well-documented, and adequate for transferring register data (status words, counters, configuration parameters) between a robot and a controller.
EtherNet/IP — The dominant protocol in Allen-Bradley (Rockwell) environments, EtherNet/IP runs over standard Ethernet hardware but adds a real-time application layer. It supports both explicit messaging (request-response data exchange) and implicit messaging (cyclic data exchange on a fixed schedule). If your facility runs Allen-Bradley PLCs — which is common in North American manufacturing — EtherNet/IP support in your robot is effectively required. Most major robot manufacturers support EtherNet/IP either natively or through an add-on module.
PROFINET — The equivalent of EtherNet/IP in Siemens environments. PROFINET is the standard communication protocol for Siemens PLCs and is common in European manufacturing and increasingly in facilities that standardised on Siemens equipment. Like EtherNet/IP, it supports both cyclic and acyclic data exchange. If you are integrating with a Siemens system, verify PROFINET support in your robot before purchasing.
OPC-UA — A modern, platform-agnostic protocol designed for secure, structured data exchange between industrial systems. OPC-UA is increasingly used for connecting robots and machines to MES and ERP systems, as well as for data collection and analytics pipelines. It is not a real-time control protocol but an excellent choice for supervisory data exchange and integration with higher-level systems.
Match the Protocol to the Use Case
Use discrete I/O for safety-critical interlocks and simple cycle coordination — it is the most reliable and easiest to troubleshoot. Use Modbus TCP or EtherNet/IP for bulk data exchange (recipe parameters, production counts, fault codes). Use OPC-UA for connecting to MES, SCADA, or data historians. Trying to use a single protocol for all three purposes often leads to a design that is complex in every area without being excellent in any.
Communication protocols move data between systems. Timing and synchronisation determine whether that data arrives at the right moment for the action it is supposed to trigger.
The most fundamental integration pattern in robotic cells is the handshake sequence — a structured exchange of signals that ensures each device is ready before the next action begins. A minimal handshake looks like this:
Robot signals "ready to receive." At the end of a cycle or on power-up, the robot asserts a digital output indicating it is in the home position and ready for the next part. The upstream device (conveyor, feeder, or operator) reads this signal before releasing a part into the cell.
Upstream device delivers part and confirms delivery. The conveyor or feeder moves a part into position and, once a sensor confirms arrival, asserts a "part present" signal to the robot. The robot waits for this confirmed signal before initiating its pick motion.
Robot completes its task and signals "cycle complete." After placing the part, the robot asserts a "cycle complete" or "part placed" output. Downstream equipment reads this signal before accepting the part for the next operation.
Downstream device acknowledges and the cycle resets. The downstream machine confirms it has accepted the part, the robot clears its cycle-complete output, and the sequence resets to step 1.
The critical principle embedded in this sequence is: never assume — confirm. The robot does not start moving after a timer expires; it starts moving after a sensor confirms the part is present. The conveyor does not advance after the robot has been stationary for two seconds; it advances after the robot explicitly signals it is ready. Assumptions about timing fail in production. Confirmed states do not.
When more than two devices are coordinated, the handshake architecture expands, and timing conflicts become more likely. A robot cell that pulls parts from a conveyor, processes them in a pneumatic press, and then hands them to a second conveyor involves at least three handshake pairs. Each pair adds latency, and total cycle time is the sum of all the handshake delays plus the actual process time.
Several common timing problems appear in multi-device cells:
Race conditions occur when two devices attempt to act simultaneously based on the same trigger. If both the robot and the conveyor respond to the same sensor signal without a sequencing mechanism between them, they may conflict. The solution is a single arbitrating device — typically the PLC — that reads all sensor states, resolves conflicts, and issues commands in sequence.
Timeout mismatches occur when one device gives up waiting before the other has completed. A robot configured to wait a maximum of five seconds for a "part present" signal will fault if the upstream conveyor takes six seconds to advance due to a momentary load spike. Timeout values need to be set with realistic margin above observed worst-case cycle times, not based on ideal timing.
State desynchronisation occurs when a communication failure or power glitch leaves one device's state register inconsistent with the actual physical state. A robot that believes the press is open when it is actually mid-stroke will crash. The mitigation is physical confirmation — read the press-open sensor directly, not just the PLC's register that says the press should be open.
Never Use Time-Based Interlocks for Safety-Critical Motion
Timer-based interlocks — "wait 3 seconds, then move" — are brittle. Machines run faster or slower depending on temperature, lubrication, load, and maintenance state. A timer that is generous on a new machine may be inadequate on the same machine after two years of wear. Always use physical confirmation (sensor states, limit switches, or safety-rated signals) for any motion that, if it proceeded at the wrong moment, would cause damage or injury.
Modern robots speak Ethernet, run Linux, and support half a dozen industrial protocols out of the box. Equipment from 10–25 years ago might have a serial port and a discrete I/O terminal strip — and nothing else. Making these two eras cooperate is one of the most common and most challenging integration scenarios in real manufacturing environments.
Before you can integrate with a legacy machine, you need to understand what interfaces it actually has. This is often harder than it sounds, because the machine's documentation may be incomplete, lost, or written in another language. Practical steps to characterise a legacy machine's interface:
Locate the control cabinet and identify the PLC or relay-logic panel inside. Note the PLC model and series — even old PLCs often have serial communication capability that is not mentioned in the machine's operator manual. Download the PLC manufacturer's communication reference for that model. Old Allen-Bradley SLC 500 PLCs, for example, support DF1 serial and DH485 networking that can be bridged to Ethernet. Old Siemens S5 PLCs have a serial interface that can be read with the right adapter.
Identify the discrete I/O terminal strip — every PLC has one, even if it also has network capability. Tracing the wiring from the machine's cycle-start input and cycle-complete output to terminal strip labels is often the fastest way to find a usable interface point. You do not always need to communicate over a network; sometimes two wires are sufficient.
Review any existing PLC program if you can access it. The I/O map in the program will show you every signal the machine reads and writes, which is a complete inventory of potential integration points.
When a legacy machine's native interface is genuinely incompatible with your robot, a protocol converter (also called a gateway) bridges the gap. These are small, DIN-rail-mounted devices that translate between two protocol worlds.
Common bridging scenarios:
| Legacy Interface | Robot Interface | Gateway Solution |
|---|---|---|
| Serial Modbus RTU | Modbus TCP / Ethernet | Moxa MB3170, ProSoft MVI46 |
| Allen-Bradley DH+ | EtherNet/IP | Rockwell 1761-NET-ENI |
| Siemens S5 serial | PROFINET | HMS Anybus Communicator |
| Proprietary serial | Discrete I/O | Serial-to-relay converter |
| Discrete I/O only | Any network | Extend directly via wired I/O |
Protocol converters introduce one additional device to configure and maintain, but they are often the most practical solution for legacy compatibility. The alternative — replacing the legacy machine's control system — is dramatically more expensive and carries its own commissioning risks.
Discrete I/O as a Fallback
When a legacy machine has no addressable communication interface, discrete I/O is almost always available. Run wires from the machine's cycle-start input and cycle-complete output to the robot controller's I/O expansion module or to an interposing relay panel connected to the robot. This approach works regardless of protocol incompatibility and is the most reliable fallback when network-level integration is not feasible.
The most effective approach to robot integration is staged rollout — implementing one integration point at a time, testing each fully before adding the next layer. This reduces risk, accelerates learning, and allows the operation to continue producing during the commissioning process.
A practical staging framework looks like this:
Stage 1: Robot in isolation. Program and test the robot's core motion — pick, process, and place — with manual part loading and unloading by an operator. Verify repeatability, cycle time, and end-of-arm tooling performance before any automated interfaces are connected. This stage also trains your operators on the robot's behaviour and emergency stop procedures.
Stage 2: Add the first interface. Connect the highest-priority integration — typically the upstream part feeder or conveyor. Implement the handshake sequence, test all states (normal cycle, part absent, timeout, fault), and run at production rate for at least one full shift before proceeding. Document the wiring, the signal names, and the PLC logic added.
Stage 3: Add downstream interfaces. Connect the robot's output to the next downstream process. Repeat the same rigorous testing protocol: normal cycle, exception states, production-rate validation, and documentation.
Stage 4: Integrate supervisory systems. Connect to the MES, SCADA, or data historian for production counting, fault reporting, and OEE tracking. This layer adds value without affecting core cell function, so it can often be added after the cell is already running production.
Stage 5: Full-system validation. Run the complete integrated system for an extended pilot period — ideally two to four weeks — under real production conditions with real operators. Track cycle time, fault frequency, and fault type. Use this data to identify and fix the remaining integration edge cases before the cell is formally handed over to operations.
Throughout every stage, maintain a manual override capability. Every automated interface should have a way for an operator to bypass the robot and run the machine manually. This is not just a commissioning convenience — it is an essential production continuity measure. If the robot faults or requires maintenance, the line should be able to continue operating manually rather than shutting down entirely.
Do Not Skip the Pilot Period
The most common integration failure mode is declaring the project complete after lab testing and immediately transitioning to full production. Lab testing with cooperative operators and clean parts reveals only a fraction of the failure modes that appear in real production. A two-to-four week supervised pilot period — with engineering support available and an easy rollback plan — is not optional overhead. It is the stage where you discover and fix the edge cases that would otherwise generate maintenance calls for the next two years.
You Can Now Plan a Robot Integration Project
You understand the protocols, handshake patterns, timing pitfalls, legacy compatibility techniques, and implementation sequencing that make robot integration succeed in real production environments. In the next post, we'll move from getting your system running to keeping it running — covering safety systems and risk assessment for automated cells, including light curtains, safety PLCs, and the ISO 12100 risk reduction process.
In the next post, we'll explore safety systems and risk assessment in automated cells — covering ISO 12100 methodology, light curtains, cages, safety PLCs, emergency stop systems, and compliance documentation.
