Erdem Ipek
Modbus TCP and EtherNet/IP for welding cobots
Teams building industrial robotics, welding automation, or fieldbus integration eventually need to connect a robot controller to real welding hardware. This article explains, at a practical level, what Modbus TCP and EtherNet/IP mean in that context, and why brands like Kemppi, Fronius, ESAB, and EWM show up in integration work.
Why welding cobots need protocol drivers, not just motion
A cobot arm can move a torch along a path, but the weld quality lives in the power source: current, voltage, waveform, and fault handling. In production, the robot program must command those parameters and read live feedback so the controller can react to arc stability, errors, or process limits. That conversation happens over industrial Ethernet protocols. Two of the most common in this space are Modbus TCP (often register-based) and EtherNet/IP (CIP-based I/O and explicit messaging, depending on the device).
From a software perspective, your team is not only mapping registers. You are designing timeouts, retry policies, state machines for weld phases, and safe shutdown paths when communication drops. That is the difference between a demo script and something a factory will run on a night shift.
Modbus TCP in welding integrations
Modbus TCP is widely used because many welding power sources expose coils and holding registers over Ethernet. The stack is relatively simple to implement, which helps when you are iterating quickly inside a larger robotics stack. The hard part is not the socket: it is reading the vendor manual, aligning register addresses with the weld schedule your process engineer wants, and validating units and scaling so you never command the wrong amperage range.
In Python or similar languages, you typically wrap the low-level read and write calls in a small driver class that your ROS2 nodes or application layer can call. Logging becomes critical. When something fails in the field, you need traces that show exactly which register was written and what the device returned.
EtherNet/IP when the device speaks CIP
EtherNet/IP is common in North American automation lines and appears alongside other industrial gear. Integration work often involves explicit messaging or I/O assemblies, depending on the EDS file and the device profile. Compared to Modbus, the mental model is different: you are working with connection paths, assembly instances, and sometimes safety-rated I/O. For a robotics software engineer, the job is to bridge that model into your robot controller or middleware so the rest of the team sees a clean API: start weld, stop, read status, read faults.
Multiple brands, one integration goal
Kemppi, Fronius, ESAB, and EWM each have different parameter sets, limits, and fault codes. A portfolio that lists these names should mean the engineer has dealt with vendor-specific quirks: different register maps, different sequencing rules, and different ways to acknowledge alarms. Concrete review topics include how faults were surfaced to the operator UI, how the system behaved when Ethernet latency spiked, and how tests were automated in CI or on a hardware bench.
ROS2 and real-time robotics context
In many modern cells, ROS2 nodes handle motion planning, I/O bridges, or supervisory logic. The welding driver might run as a dedicated node or behind a thin RPC layer so non-ROS components can still command the weld. The important design question is not the ROS2 distro name alone, but how messages are synchronized with the fieldbus, how you avoid blocking the control loop, and how you document assumptions for the next engineer on call.